Программное обеспечение и его разработка
Шрифт:
Разработка программного обеспечения проходит следящие шесть этапов: определение требований, проектирование, написание команд, компоновка, тестирование и документирование.
Разработка больших систем программного обеспечения часто зависит от наличной аппаратуры.
Любой процесс может быть выражен несколькими различными «правильными» последовательностями команд.
Программное обеспечение носит абстрактный характер, что усложняет процесс его разработки.
Основным инструментом создания нового программного обеспечения являются вычислительная машина и ее программное обеспечение.
При разработке программного обеспечения основную трудность обычно представляет собой не та функция, которую должна выполнять
Некоторые виды программного обеспечения можно разрабатывать теми же методами, что и аппаратуру, другие же так разрабатывать нельзя.
Правильное программное обеспечение не подвержено никаким сбоям. Термин «поддержка» по отношению к программному обеспечению является, следовательно, неправильным.
Разработка больших программ — это весьма многогранная деятельность, отнюдь не связанная только с работой на вычислительной машине.
Большая система программного обеспечения никогда не может быть отлажена до конца, даже после нескольких лет тестирования и использования.
Разработка программного обеспечения часто весьма трудоемкий и дорогостоящий процесс.
Программное обеспечение это не цель, а средство.
Развитие программного обеспечения происходит одновременно в двух противоположных направлениях. В середине 30-х гг. XX столетия английский математик Ален Тьюринг доказал, что любой процесс, который можно описать каким-либо алгоритмом, может быть реализован с помощью простейшей машины, которая выполняет всего шесть различных команд, хотя это может занимать весьма значительное время. Из этого принципа логически следует тот факт, что вычислительная машина — любая вычислительная машина общего назначения — может выполнить все, что только может быть описано с помощью алгоритма. Современное программное обеспечение становится все более сложным, находит все более широкие и сложные приложения и в то же время делается «обыкновенной» продукцией повседневного пользования обывателей.
Огромный прогресс технологии производства интегральных схем драматически понизил цены на аппаратуру, и этот процесс будет еще продолжаться. То, что казалось недоступным еще несколько лет назад из-за цены или нехватки времени, вполне достижимо сегодня.
Одновременное уменьшение стоимости и увеличение мощности машин расширили область применения ЭВМ сразу на верхнем и нижнем уровнях.
На верхнем уровне, связанном с широкомасштабными усилиями, вычислительные машины получают возможность выполнять задачи за требуемое время, и эти задачи стали теперь решаться. А на нижнем уровне простые машины с невысоким быстродействием становятся такими дешевыми, что их теперь экономически выгодно использовать для автоматизации тех процессов, которые еще год или два тому назад не имело смысла автоматизировать.
Это развитие вычислительной техники в двух направлениях вроде бы не должно никого удивлять и смущать, но иногда это происходит. Программное обеспечение для верхнего уровня становится все более сложным, для нижнего же уровня программы постоянно упрощаются.
Программное обеспечение состоит из множества программ различных типов. Программы делают все, что только можно; они бывают маленькими и тривиальными, но бывают также большими и сложными, весьма дорогостоящими. Говорить о программном обеспечении можно только употребляя при этом по крайней мере одно уточняющее слово. О чем мы говорим — о «программном обеспечении проекта» или о «программном обеспечении как продукции»? О «реальном времени» или о «пакете»? А может быть о «диалоге»? Что мы имеем в виду: «помехозащищенность», «помехобезопасность» или просто надежность? О каком программном обеспечении идет речь — о «инструментальном», «системном» или «прикладном»? О «крупномасштабном» или «мелкомасштабном» программном обеспечении?
Жизнь программы делится на три фазы. Слишком часто разработчики программ фокусируют свое внимание только на фазе разработки, иногда еще и на фазе использования и очень редко на фазе сопровождения или продолжающейся разработки к большему ущербу для последней. Кое-что можно и нужно делать во время разработки для облегчения других фаз. Большинство разработчиков этот аспект игнорируют. Во многих книгах, посвященных разработке и использованию программ, игнорируется тот факт, что эти три фазы существуют отдельно друг от друга, имеют различные цели и часто к тому же проводятся под разным руководством (см. рис. 1.1).
Разработка программного обеспечения состоит из шести фаз: определение требований, проектирование, написание команд, компоновка, тестирование и документирование. Простейшее в этом списке — написание команд. Очень трудно проектировать оптимальное или хотя бы правильное взаимодействие большого числа программ. Для больших систем труднее всего сформулировать требования пользователей, а следовательно, и самих этих систем. И все же большинство учебных курсов и книг в основном делает упор именно на написание команд. Как мы увидим в дальнейшем, особое внимание надо уделять определению требований и проектированию.
Разработка программного обеспечения для больших систем часто зависит от аппаратуры. Большие системы обычно требуют, чтобы аппаратура в них использовалась оптимальным образом в целях экономии и увеличения производительности.
Особенно важно правильно спланировать загрузку центрального процессора (ЦП) и определить все требования к памяти. Все это заставляет разработчиков при проектировании программ учитывать параметры и характеристики аппаратуры системы. В случае разработки маленьких программ дело обстоит совсем иначе.
Производительность системы — т. е. способность вычислительной машины выполнить задание за определенный промежуток времени — в большой степени зависит от используемой аппаратуры, ее мощности и состава. Если аппаратура плохо подходит для решения поставленной задачи, вся тяжесть достижения необходимых пределов производительности ложится на плечи разработчиков программного обеспечения, и в особенности на тех, кто занимается проектированием. Это основная причина того, что иногда разработчики больших систем или систем реального времени вынуждены отказываться от использования языков высокого уровня. Мы увидим еще несколько примеров того, как требование достижения высокой производительности усложняет разработку.
Любой процесс может быть описан несколькими различными «правильными» последовательностями команд. Сотня программистов смогла бы написать сто различных программ платежной ведомости, каждая из которых будет выполнять то, что от нее требуется. Небольшое количество среди них будет оптимальным. Важные характеристики каждой программы порой конфликтуют друг с другом, подобно тому как при конструировании самолетов размеры вступают в конфликт со скоростью. Прочитав гл.5, вы узнаете, что каждая программа имеет по крайней мере 12 характеристик и некоторые из них, находя воплощение в одной программе, могут вступать с другими в противоречие. Множественность возможных решений является серьезным препятствием для правильного управления процессом разработки программного обеспечения.