Вопрос 2. Жизненный цикл программного обеспечения. Модели жизненного цикла на примере разработки программного обеспечения " Microsoft Word ".

Вопрос 2. Жизненный цикл программного обеспечения. Модели жизненного цикла на примере разработки программного обеспечения “ Microsoft Word ”.

В основе деятельности по созданию и использованию ПО лежит понятие его жизненного цикла (ЖЦ).

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

Длительность ЖЦ для различных ПП неодинакова и для большинства современных ПП измеряется в годах (2-3 года). Хотя достаточно часто встречаются на компьютерах и давно снятые с производства ПП.

Стандарт определяет структуру ЖЦ , содержащую процессы, действия и задачи, которые должны быть выполнены во время создания и использования ПО . В России создание ПО первоначально, в 70-е гг., регламентировалось стандартами серии ГОСТ 19.ХХХ - Единая система программной документации ( ЕСПД ) и ГОСТ 34.ХХХ - Комплекс стандартов на АС. Однако создание, сопровождение и развитие современного прикладного ПО высокого качества в этих стандартах отражено недостаточно, а отдельные их положения устарели. Эти стандарты вынуждены использовать предприятия, выполняющие государ­с­т­венные заказы при создании ПО для внутреннего применения. Однако в экс­по­р­т­ных заказах зарубежные клиенты требуют соответствия технологии проек­тиро­ва­ния, производства и качества продукции современным международным стандартам.

Основным зарубежным нормативным документом, наиболее полно и подро­б­но регламентирующим ЖЦ ПО , является международный стандарт ISO/IEC 12207 . ( ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике.)

Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ ПО .

Модель ЖЦ зависит от специфики ПО и специфики условий, в которых оно создается и функционирует. Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО . Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО , но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ любого конкретного ПО определяет характер процесса его создания. Процесс создания ПО представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в этапы работ , выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям. Под этапом создания ПО понимается часть процесса создания ПО , огра­ниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта (моделей ПО, программных ком­понентов, документации), определяемого заданными для данной стадии требованиями. Этапы создания ПО выделяются по сообра­жениям рационального планирования и организации работ, закан­чивающихся заданными результатами. В состав ЖЦ ПО обычно включаются следующие этапы: 1. Формирование требований, предъявляемых к ПО. 2. Проектирование структуры ПО. 3. Реализация. 4. Тестирование. 5. Ввод в действие. 6. Эксплуатация и сопровождение. 7. Снятие с эксплуатации.

На каждом этапе могут выполняться несколько процессов, оп­ределенных в стандарте 1SO/IEC 12207, и, наоборот, один и тот же процесс может выполняться на различных этапах.

Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. К настоящему времени наибольшее распространение получили следующие три основные модели ЖЦ : 1) Каскадная модель (70-80 гг.) - предполагает переход на следующий этап после полного завершения работ предыдущего этапа. 2) Поэтапная модель с промежуточным контролем (80-85 гг.) - итерационная модель разработки ПО с циклами обратной связи между этапами. 3) Спиральная модель (86-90 гг.) - делает упор на начальные этапы ЖЦ (анализ требований, проектирование спецификаций , предварительное и детальное проектирование).

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

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

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

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

Спиральная модель ЖЦ (см. рис), делающая упор на начальные этапы ЖЦ: анализ требований, определение спецификаций и проектирование (предварительное и детальное) .

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

Под прототипом обычно понимают набор программ, моделирующих (изображающих, эмулирующих) работу готовой системы. Цель прототипирования - более ясно представить себе будущую систему, предугадать ее недостатки на этапе проектирования, внести необходимые коррективы в техническое задание и технический проект, если он уже готов. Прототип системы удобно демонстрировать сотрудникам предприятия-заказчика, чтобы они могли понять, насколько удобно им будет пользоваться системой, какие функции следует добавить или исключить. Каждый виток спирали соответствует созданию фрагмента или версии ПО , на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта. Разработка итерациями отражает объективно существующий спиральный цикл создания ПО . Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем этапе. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача - как можно быстрее показать пользователям работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований, исправления ошибок, обусловленных неопределенностью или некорректностью технических заданий и спецификаций требований. Спиральная модель не исключает использования каскадного подхода на завершающих стадиях проекта в тех случаях, когда тре­бования к системе оказываются полностью определенными. Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов ЖЦ. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Другими недостатками спиральной модели являются: трудоемкость внесения изменений; большой объем документации по проекту, затрудняющий программирование; сложность переноса на другие платформы.

Пример: при разработке “ Microsoft Word ” на этапе формирования требований к ПО, были выдвинуты функциональные требования к ПО (ввод, редактирование текста, проверка орфографии, применение различных стилей печати текста, распечатка, сохранение текста и т.д.). Было утверждено ТЗ, после его утверждения, вносить изменения нельзя. Поэтому, к аскадный подход хорошо зарекомендовал себя при разработке не сложного ПО, когда каждая программа представляет собой единое целое и не подходит для разработки такого ПО как “ Microsoft Word ”. При построении несложного ПО в самом начале разработки можно достаточно точно и полно сформул-ть все треб-ия , с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения.