7. Этапы жизненного цикла ПО. Каскадная модель жизненного цикла ПО.

Понятие жизненный цикл является отражением системного подхода к разработке ПО. В соответствии с международным стандартом ISO /IEC 12207 «информационные технологии – Процессы жизненного цикла ПО» стандартом США MILSTD-498

“Разработка ПО …”, российских стандартов ГОСТ 19.102-77 (ЕСПД) процесс разработки ПО содержит следующие этапы жизненного цикла ПО:

1)анализ системных требований и области применения;

2)проектирование архитектуры системы;

3)анализ требований к ПО (спецификации, внешниеинтерфейсы, требований к квалификации);

4)проектирование архитектуры ПО;

5)детальное проектирование каждой единицы ПО;

6)кодирование ПО (программирование)

7)тестирование единиц ПО;

8)интеграция (объединение ПО) и тестирование совокупности единиц ПО;

9)квалификационные испытания ПО (комплексное тестирование);

10)интеграция системы единицы структуры ПО должны быть объединены с единицами аппаратных средств;

11)квалификационные испытания системы;

12)установка ПО.

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

После этапов разработки в жизненном цикле ПО следует этап эксплуатации ПО и его сопровождения при эксплуатации.

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

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

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

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

10

8. Конструирование ПО

Термином конструирование программного обеспечения (software construction) охватываются этапы жизненного цикла создания ПО: разработки архитектуры, детального проектирования ПО, кодирования, верификации (проверки), модульного тестирования – автономной отладки, интеграционного тестирования и отладки(кроме независимого тестирования). Термин конструирование ПО не трактуется стандартами разработки ПО, как этап разработки ПО, и имеет различное толкование у различных авторов. Этот термин появился в документе SWЕBOK(Software Engineering Body of Knolidge), подготовленном международным комитетом SWESS. Назначение этого документа – определение необходимого набора знаний и учебных программ для образовательных стандартов, в объединении знаний по разработке ПО ( инженерии ПО).

Польза от его появления и употребления связана с тем, что с ним связаны некоторые процессы и операции разработки и внутренние характеристики качества ПО (характеристики качества не пользователя, а разработчика), отсутствующие в стандарте ИСО/МЭК 9126.

Действительно, основы конструирования программного обеспечения включают требования к следующим внутренним характеристикам качества программного проекта:

Минимизации сложности.

Сокрытию информации между частями ПО по принципу «нет необходимости знать».

Ожиданию изменений и готовность к безпроблемному их проведению.

Конструированию с возможностью удобной проверки(тестированию)–контролепригодность.

Использованию стандартных приемов в конструировании, которые позволяют снизить сложность и избежать ряд характерных ошибок ПО.

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

Конструирование ПО - группа процессов, которая выполняется во всех случаях и во всех технологиях разработки.

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

Взависимости от размера программного проекта на конструирование уходит 30-80% от общей трудоемкости. Главной целью конструирования ПО должна быть минимизация его сложности.

[Введите текст]

9. Стандарты по разработке ПО. Виды и значение стандартов, требования стандартов

Создание сложных систем ПО в промышленных масштабах немыслимо без стандартов. Промышленные стандарты и в частности стандарты на ПО бывают двух видов:

стандарты процессов разработки, устанавливающие единые и обязательные общие требования к процессам разработки ПО( ГОСТ Р ИСО/МЭК 12207),

стандарты, устанавливающие требования качества самого ПО (ГОСТ Р ИСО/МЭК 9126)..

Если говорить о инженерии программного обеспечения, то идея реализации высокого и всеобъемлюще-

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

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

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

Известный стандарт ЕСПД ГОСТ 19.102-77 претерпел мало изменений с момента его создания, пережил несколько поколений ЭВМ, изменений технологий разработки ПО. Это говорит о том, что стандарт содержал базовые «вечные» понятия и требования, не сдерживающие технические новации. В настоящее время он, конечно, устарел.

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

10. Три группы процессов создания ПО

Вслед за стандартом ГОСТ Р ИСО/МЭК 12207 разделим все процессы создания ПО на три группы: основные, вспомогательные и организационные.

Группа основных процессов включает в себя процессы:

приобретения(заказа) – это работы, действия и задачи заказчика, приобретающего программное средство, связанные с формулированием требований к нему, выбору поставщика, проведению договорной работы и т.п.

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

разработки – это работы, действия и задачи разработчика программного продукта в соответствии с уже рассмотренными этапами жизненного цикла ПО,

12

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

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

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

Группа вспомогательных процессов включает в себя процессы, обеспечивающие выполнение основных процессов:

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

управления конфигурацией – это набор административных и технических процедур для определения состояния компонентов ПО в системе и для управления его модификациями,

обеспечения качества ПО о чем говорилось выше,

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

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

аудита – это оценка соответствия требований к ПО планам и условиям договора, соответствия графика работ утвержденным планам

К организационным процессам жизненного цикла относятся:

управление разработкой,

создания инфраструктуры - обеспечения разработчиков инструментальными средствами, методиками,

обучения - планирования и проведение работ по созданию квалификации персонала, необходимого для проведения процессов жизненного цикла уровня.

[Введите текст]