ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.docx

ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Важнейшим понятием в технологии разработки программного обеспечения является жизненный цикл программы.

6.1.  Жизненный цикл программы

созданной, программа входит в цикл, включающий ее использование и модификацию; продолжительность этого цикла рас- пространяется на все время жизни программы. Такая картина характерна и для многих промышленных изделий. Отличие заключается лишь в том, что для таких изделий фазу модификации точнее было бы назвать ремонтом или техническим об- служиванием, поскольку они модифицируются по мере износа их частей.

Однако программы не подвержены износу. Поэтому они проходят фазу модификации из-за обнаружения ошибок, воз- никновения изменений в области их применения, требующих внесения соответствующих корректировок в программы, или из-за того, что прежняя модификация вызвала появление проблем в других частях программы. Например, изменения в нало- говом законодательстве могут потребовать внесения корректировок в программы подготовки платежных ведомостей, свя- занные с расчетом удерживаемого налога. Однако внесенные изменения, в свою очередь, могут неблагоприятно повлиять на другие части программы, причем это может быть замечено не сразу.

Независимо от того, почему программа модифицируется, необходимо, чтобы некто (как правило, не автор ее исходной версии) изучил и понял программу и ее документацию; если не всю программу, то хотя бы ту часть, которая относится к де- лу. Любая модификация алгоритма программы может вызвать намного больше проблем, чем она предназначена решить. Достижение необходимой степени понимания является сложной задачей, даже если программа правильно разработана и до- кументирована. Фактически именно на этой стадии отдельные фрагменты программного обеспечения просто отбрасывают, исхо- дя из утверждений (часто вполне справедливых), что проще разработать новую систему с нуля, чем успешно модифицировать уже существующий пакет.

Опыт показывает, что незначительные дополнительные усилия, затраченные при разработке программы, впоследствии могут существенно изменить ситуацию, когда потребуется внести в нее изменения. Например, при обсуждении операторов описания данных в главе 5 было показано, как вместо безличного числового значения 645 в программе может использовать- ся символическое имя AirportAlt. В дальнейшем обсуждении разъяснялось, что, если возникнет необходимость в изменени- ях, гораздо легче изменить значение, связанное с некоторым символическим именем, чем осуществить поиск и изменение множества вхождений безличного арифметического значения 645. Как следствие, большая часть исследований в области технологии разработки программного обеспечения концентрирует свое внимание именно на фазе разработки в жизненном цикле программы. Их задача – найти способы эффективного использования тех преимуществ, которые достигаются за счет дополнительных усилий на данной стадии, понимаемых как выгодное средство достижения цели.

Традиционные этапы разработки программ. Фаза разработки в жизненном цикле программы традиционно включает следующие этапы: анализ, проектирование, реализацию и тестирование (рис. 6.2).

Фаза разработки в жизненном цикле программы начинается с анализа, основная задача которого состоит в определении нужд пользователей предлагаемой системы. Если система должна быть продуктом общего назначения, продаваемым на рынке в условиях свободной конкуренции, анализ, вероятно, будет включать широкомасштабные исследования в целях оп- ределения потребностей потенциальных пользователей. Однако если система разрабатывается для нужд конкретного поль- зователя, исследования будут носить более целенаправленный характер.

По мере того как выясняются потребности потенциального пользователя, они преобразуются в ряд требований, кото- рым должна удовлетворять новая система. Эти требования формулируются в терминах, принятых в сфере приложения, без использования специальной терминологии, принятой среди специалистов по обработке данных. Одно из требований может состоять в том, что доступ к данным должен предоставляться только зарегистрированным пользователям. Другое требование может заключаться в том, чтобы данные отражали текущее состояние товарных запасов на конец последнего рабочего дня или чтобы организация данных на экране компьютера соответствовала формату используемых в настоящее время бумажных документов.

6.2.  Фаза разработки в жизненном цикле программного обеспечения

После того как требования к создаваемой системе будут определены, их преобразуют в систему спецификаций, имею- щих более технически организованный вид. Например, разрешение доступа к данным, только зарегистрированным в системе пользователям, должно быть представлено отдельным пунктом спецификаций; в нем указывается, что система не должна отвечать на какие-либо запросы, пока с клавиатуры не будет введен соответствующий пароль из восьми цифр, или же дан- ные будут отображаться на экране в закодированной форме и примут осмысленный вид только после обработки некоторой стандартной программой, имя которой должно быть известно лишь зарегистрированным пользователям.

В то время как анализ определяет, что должна делать предлагаемая система, проектирование определяет, как она будет выполнять эти задачи. Именно на этом этапе определяется структура системы программного обеспечения.

Не вызывает сомнения то, что наилучшей структурой для крупной системы программного обеспечения является мо- дульная. Именно благодаря разбиению больших систем на модули становится возможной их практическая реализация. Без этого разбиения технические детали, необходимые при реализации большой системы, превысили бы возможности человече- ского восприятия. При использовании модульной конструкции разработчик может ограничиться изучением только тех дета- лей, которые относятся к рассматриваемому модулю. Модульная конструкция также удобна при дальнейшем сопровождении программы, поскольку позволяет вносить изменения на модульной основе. (Если изменение нужно внести в способ выпол- нения расчетов по больничным листам работников, то потребуется рассматривать только те модули, которые непосредст- венно связаны с оплатой больничных листов.)

Однако понятие модуля может трактоваться по-разному. Если подходить к задаче конструирования, используя пара- дигму традиционного императивного программирования, то модули будут состоять из отдельных процедур и разработка модульной структуры примет форму выявления различных заданий, которые создаваемая система должна будет выполнять. В противоположность этому, если предполагается использовать объектно-ориентированный подход, то в качестве модулей будут выступать отдельные объекты, а процесс конструирования модульной структуры превратится в процесс выявления имеющихся в предметной области сущностей (объектов) и определения их поведения в предлагаемой системе.

Следующим этапом является реализация. Он включает собственно написание программ, создание файлов данных и разра- ботку баз данных.

Тестирование тесно связано с реализацией, так как каждый модуль системы, как правило, должен подвергаться тести- рованию, как только он будет написан. Действительно, в правильно сконструированной системе каждый модуль может и должен быть проверен либо независимо от других модулей, либо с использованием упрощенных версий других модулей, называемых заглушками (stub). Назначение заглушек состоит в том, чтобы имитировать взаимодействие тестируемых моду- лей и остальной части системы. Аналогичным образом можно тестировать и систему в целом, по мере завершения создания отдельных модулей и их объединения в единое целое.

К сожалению, этап тестирования и устранения обнаруженных в системе неполадок чрезвычайно сложно довести до ус- пешного завершения. Опыт показывает, что большие системы программного обеспечения могут содержать множество оши-

бок даже после продолжительного тестирования. Многие из этих ошибок могут оставаться незамеченными на протяжении всего жизненного цикла системы, в то время как другие могут стать причиной весьма опасных ошибок. Устранение таких ошибок является одной из важнейших задач технологии разработки программных систем. Тот факт, что количество обнару- живаемых ошибок все еще весьма значительно, говорит о том, что исследования в этой области необходимо продолжать.

Современные тенденции. Ранние подходы к проектированию программного обеспечения предполагали строго после- довательное выполнение этапов анализа, проектирования, реализации и тестирования. Предполагалось, что риск, связанный с использованием метода проб и ошибок при разработке больших систем программного обеспечения, слишком велик. В ре- зультате разработчики программного обеспечения настаивали на полном завершении общего анализа системы до начала ее проектирования. Точно так же необходимо полностью завершить этап проектирования системы до начала ее реализации. Подобная схема процесса разработки получила название модели водопада (по аналогии с движением потока падающей воды, поскольку процесс разработки должен был двигаться только в одном направлении).

Можно отметить сходство между четырьмя этапами решения задач, определенными математиком Полиа (см. раздел 4.3), и этапами анализа, проектирования, реализации и тестирования, входящими в фазу разработки программного обеспече- ния. В конце концов, разработать большую систему программного обеспечения действительно означает решить сложную задачу. Однако традиционный подход к разработке программного обеспечения, соответствующий модели водопада, полно- стью противоположен свободно развивающемуся методу проб и ошибок, присущему творческому решению задач. В то вре- мя как подход, соответствующий модели водопада, стремится к организации четко структурированной среды, в которой раз- работка программного обеспечения будет происходить в строгой последовательности, творческий подход к решению задач предполагает неструктурированную среду, в которой можно отказаться от работы по предварительно намеченному плану, следуя интуиции, не требующей пояснения, почему это происходит.

Разработка программных систем в реальном мире. Следующий сценарий типичен в отношении тех задач, с кото- рыми сталкиваются разработчики программного обеспечения в реальности. Допустим, компания XYZ заказывает фир- ме, занимающейся созданием программного обеспечения, разработать и установить интегрированную систему про- граммного обеспечения для обработки данных в масштабах этой компании. При развертывании этой системы каждому работнику выделяется персональный компьютер, подключенный к сети, общей для всей компании. Эти персональные компьютеры не только обеспечивают доступ к установленной в компании системе обработки данных, но и могут ис- пользоваться в качестве некоторого настраиваемого инструмента, с помощью которого каждый работник компании стремится повысить производительность своего труда. Например, какой-либо работник разрабатывает электронную таблицу, упрощающую или ускоряющую выполнение стоящих перед ним задач. К сожалению, подобные разработан- ные пользователями приложения очень часто оказываются неправильно спроектированными и недостаточно тщательно протестированными, а также включают функции, работа которых была понята работником неправильно или же лишь частично. Со временем эти самодельные приложения включаются в процедуры производственной деятельности компа- нии. В результате то, что исходно представляло собой правильно спроектированную систему, оказывается погребенным под беспорядочным нагромождением из плохо спроектированных, недокументированных, содержащих множество ошибок приложений.

С недавних пор в методах проектирования программного обеспечения стало учитываться это основополагающее проти- воречие, что выразилось в появлении пошаговой модели разработки программного обеспечения. В соответствии с этой мо- делью требуемая система программного обеспечения создается поэтапно. Первый вариант является некоторой упрощенной версией требуемой системы с ограниченным набором функций. После того как эта версия будет протестирована и, возмож- но, оценена будущим пользователем, к ней последовательно добавляют и тестируют другие функции, и так до тех пор, пока система не приобретет законченный вид. Например, если разрабатываемая система является приложением для ведения лич- ных дел студентов, предназначенным для секретаря университета, то ее первое приближение может включать только функ- цию просмотра личных дел студентов. После того как эта версия окажется работоспособной, в ней поэтапно будут реализо- ваны дополнительные функции, такие, как добавление новых записей и обновление уже существующих.

Пошаговая модель является примером использования в технологии разработки программного обеспечения метода соз-

дания прототипов (prototyping) или макетирования, который заключается в создании и последующей оценке неполных вер- сий разрабатываемой системы, называемых прототипами (prototypes). В пошаговой модели прототип развивается в конеч- ную версию системы, поэтому данный вариант метода создания прототипов именуется эволюционным макетированием (evo- lution prototyping). В других случаях прототипы могут отбрасываться, уступая место новым реализациям конечного проекта. Такой вариант метода создания прототипов называется методом с временным макетированием (throwaway prototyping). Примером использования этого варианта может служить быстрое создание прототипов, при котором на ранних стадиях раз- работки очень быстро создается серия упрощенных вариантов разрабатываемой системы. Такой прототип может состоять всего лишь из нескольких эскизов компоновки экрана, показывающих, как система будет взаимодействовать с пользовате- лем и каковы будут ее возможности. В данном случае задача состоит не в создании рабочей версии продукта, а в получении средства демонстрации, предназначенного для углубления взаимопонимания между участвующими в разработке сторонами. В частности, метод быстрого создания прототипов доказал свою эффективность в отношении систематизации требований к системе, выдвинутых на этапе анализа, а также в качестве средства для проведения презентаций возможностей системы ее потенциальным заказчикам.

Другое усовершенствование методов проектирования программных систем предусматривает применение компьютер- ных технологий к самому процессу разработки программного обеспечения, что привело к появлению CASE-технологий (CASE – Computed-Aided Software Engineering). Эти компьютеризованные системы, известные как CASE-инструменты, включают средства планирования проекта (предназначенные для оценки стоимости календарного планирования и распреде- ления исполнителей), средства управления проектом (для контроля за процессом разработки проекта), средства документи- рования (для написания и систематизации проектной документации), средства создания прототипов и имитации (для созда- ния прототипов), средства разработки интерфейсов (для разработки графических интерфейсов пользователя), а также сред- ства программирования (для написания и отладки программ). Некоторые из этих инструментов немногим отличаются от

обычных текстовых редакторов, приложений электронных таблиц и систем электронной почты, используемых в других при- ложениях. Однако другие представляют собой достаточно сложные пакеты, предназначенные преимущественно для исполь- зования при разработке систем программного обеспечения. Например, некоторые CASE-инструменты включают генераторы кода, которые по заданной спецификации на некоторую часть системы генерируют программу на языке высокого уровня, представляющую собой реализацию этой части системы.

Вопросы для самопроверки

1.  В чем состоит отличие между требованиями к системе и спецификацией на систему?

2.  Кратко охарактеризуйте каждый из четырех этапов (анализ, проектирование, реализация и тестирование) фазы разра- ботки в жизненном цикле программного обеспечения.

3.  Охарактеризуйте различия между традиционной моделью разработки программного обеспечения (модель водопада) и новым подходом, предусматривающим создание прототипов.