Практическая работа №4
Стандарты жизненного цикла программных средств
Цель работы:
· Изучение и закрепление знаний по теме «Стандарты жизненного цикла программных средств».
Теория:
- Понятие жизненного цикла ПО
В основе деятельности по созданию и использованию программного обеспечения лежит понятие жизненного цикла. В общем случае различают понятия жизненного цикла программного обеспечения и технологического процесса его разработки. Более четко различия между данными понятиями просматривается в отношении программных средств.
Жизненный цикл (ЖЦ) ПС — это период времени, который начинается с момента принятия решения о необходимости создания ПС и заканчивается в момент его полного изъятия из эксплуатации.
Существует несколько опубликованных моделей ЖЦ ПО.
Модель жизненного цикла программного обеспечения — структура, содержащая процессы действия и задачи, которые осуществляются в ходе разработки, использования и сопровождения программного продукта.
Модель ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
Модель ЖЦ любого конкретного ПО определяет характер процесса его создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ, выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям.
Под стадией создания ПО понимается часть процесса создания ПО, ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта (моделей ПО, программных компонентов, документации), определяемого заданными для данной стадии требованиями. Стадии создания ПО выделяются по соображениям рационального планирования и организации работ, заканчивающихся заданными результатами.
|
|
В состав жизненного цикла ПО обычно включаются следующие стадии:
· Формирование требований к ПО.
· Проектирование.
· Реализация.
· Тестирование.
· Ввод в действие.
· Эксплуатация и сопровождение.
· Снятие с эксплуатации.
Стадия формирования требований к ПО. Она является одной из важнейших, поскольку определяет успех всего проекта. Данная стадия включает следующие этапы:
· планирование работ, предваряющее работы над проектом.
Основными задачами этапа являются:
o определение целей разработки,
o предварительная экономическая оценка проекта,
o построение плана-графика выполнения работ,
o создание и обучение совместной рабочей группы;
· проведение обследования деятельности автоматизируемого объекта (организации) (для случая разработки ИС), в рамках которого осуществляются:
o предварительное выявление требований к будущей системе:
o определение структуры организации;
o определение перечня целевых функций организации;
o анализ распределения функций по подразделениям и сотрудникам;
o выявление функциональных взаимодействий между подразделениями, информационных потоков внутри подразделений и между ними, внешних по отношению к организации объектов и внешних информационных взаимодействий;
o анализ существующих средств автоматизации деятельности организации;
· построение моделей деятельности организации, предусматривающее обработку материалов обследования и построение двух видов моделей:
|
|
o модели «AS-IS» («как есть»), отражающей существующее на момент обследования положение дел в организации и позволяющей понять, каким образом функционирует данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации;
o – модели «ТО-ВЕ» («как должно быть»), отражающей представление о новых технологиях работы организации.
Построенные модели имеют самостоятельное практическое значение. Например, модель «AS-IS» позволяет выявлять узкие места в существующих технологиях и предлагать рекомендации по решению проблем независимо от того, предполагается на данном этапе дальнейшая разработка электронной информационной системы (ЭИС) или нет. Кроме того, модель облегчает обучение сотрудников конкретным направлениям деятельности организации за счет использования наглядных диаграмм.
Стадия проектирования. Она, как правило, включает следующие этапы:
· разработка системного проекта. На этом этапе дается ответ на вопрос: «Что должна делать будущая система?», а именно: определяются архитектура системы, ее функции, внешние условия функционирования, интерфейсы и распределение функций между пользователями и системой, требования к программным и информационным компонентам, состав исполнителей и сроки разработки. Основу системного проекта составляют модели проектируемой ЭИС, которые строятся на основе модели «ТО-ВЕ». Документальным результатом этапа является техническое задание;
· разработка технического проекта. На этом этапе на основе системного проекта осуществляется собственно проектирование системы, включающее проектирование архитектуры системы и детальное проектирование. Таким образом, дается ответ на вопрос: «Как построить систему, чтобы она удовлетворяла предъявленным к ней требованиям?».
|
|
Содержание последующих стадий совпадает в основном с соответствующими процессами ЖЦ ПО.
К настоящему времени наибольшее распространение получили следующие модели ЖЦ ПО:
1. Каскадная модель (1970 -1985 гг.)
В однородных ЭИС 70-х и 80-х гг. прикладное ПО представляло собой единое целое. Для разработки такого типа ПО применялся КАСКАДНЫЙ ПОДХОД (или «водопад») (рис.1)
Рис. 1 Каскадная схема разработки ПО
Принципиальной особенностью каскадного подхода является следующее: переход на следующую стадию осуществляется только после того, как будет полностью завершена работа на текущей стадии, и возвратов на пройденные стадии не предусматривается.
Каждая стадия заканчивается получением некоторых результатов, которые служат в качестве исходных данных для следующей стадии.
Требования к разрабатываемому ПО, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является точность выполнения спецификаций технического задания.
\
При этом основное внимание разработчиков сосредоточивается на достижении оптимальных значений технических характеристик разрабатываемого ПО: производительности, объема занимаемой памяти и др.
Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта.
Когда использовать каскадную методологию?
· Только тогда, когда требования известны, понятны и зафиксированы. Противоречивых требований не имеется.
· Нет проблем с доступностью программистов нужной квалификации.
· В относительно небольших проектах.
Преимущества применения каскадного способа заключаются в следующем:
· на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
· выполняемые в логичной последовательности стадии работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
· Последовательное выполнение этапов проекта в строгом фиксированном порядке
· Позволяет оценивать качество продукта на каждом этапе
Каскадный подход хорошо зарекомендовал себя при построении ЭИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их технически как можно лучше. В эту категорию попадают сложные системы с большим количеством задач вычислительного характера, системы реального времени и др. В то же время этот подход обладает рядом недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. Процесс создания ПО носит, как правило, итерационный характер: результаты очередной стадии часто вызывают изменения в проектных решениях, выработанных на более ранних стадиях. Таким образом, постоянно возникает потребность в возврате к предыдущим стадиям и уточнении или пересмотре ранее принятых решений.
итерация — возврат на предыдущие шаги технологического процесса. При программировании, например, может обнаружиться, что реализация некоторой функции очень громоздка, неэффективна и вступает в противоречие с требуемой от системы производительностью. В этом случае требуется перепроектирование, а может быть, и переделка спецификаций. При разработке больших нетрадиционных систем необходимость в итерациях возникает регулярно на любом этапе жизненного цикла как из-за допущенных на предыдущих шагах ошибок и неточностей, так и из-за изменений внешних требований к условиям эксплуатации системы.
В результате реальный процесс создания ПО принимает иной вид (рис. 2).
Рис. 2. Реальный процесс разработки ПО
Изображенную на рис.2 схему часто относят к отдельной модели, так называемой модели с промежуточным контролем, в которой межстадийные корректировки обеспечивают большую надежность по сравнению с каскадной моделью, хотя и увеличивают весь период разработки.
Основным недостатком каскадного подхода являются: существенное запаздывание с получением результатов и, как следствие, достаточно высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователей.
Практика показывает, что на начальной стадии проекта полностью и точно сформулировать все требования к будущей системе не удается. Это объясняется двумя причинами: 1) пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки; 2) за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе.
В рамках каскадного подхода требования к ЭИС фиксируются в виде технического задания на все время ее создания, а согласование получаемых результатов с пользователями производится только в точках, планируемых после завершения каждой стадии (при этом возможна корректировка результатов по замечаниям пользователей, если они не затрагивают требования, изложенные в техническом задании). Таким образом, пользователи могут внести существенные замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО пользователи получают систему, не удовлетворяющую их потребностям. В результате приходится начинать новый проект, который может постигнуть та же участь.
2. Спиральная модель (1986 – 1990 гг.).
Для преодоления перечисленных проблем в середине 80-х гг. была предложена СПИРАЛЬНАЯ МОДЕЛЬ ЖЦ (рис. 3).
Ее принципиальной особенностью является следующее: прикладное ПО создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования.
Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО.
Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, степень полноты и точности понимания требований к системе, а также целесообразность прекращения проекта. Спиральная модель избавляет пользователей и разработчиков ПО от необходимости полного и точного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.
Рис. 3. Спиральная модель
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждой стадии позволяет переходить на следующую стадию, не дожидаясь полного завершения работы на текущей. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача – как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Спиральная модель не исключает использования каскадного подхода на завершающих стадиях проекта в тех случаях, когда требования к системе оказываются полностью определенными.
Основная проблема спирального цикла – определение момента перехода на следующую стадию. Для ее решения необходимо ввести временные ограничения на каждую из стадий жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Преимущества:
· Быстрое получение результата
· Повышение конкурентоспособности
· Изменяющиеся требования — не проблема
Недостатки:
· Отсутствие регламентации стадий
Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.
Эта модель не подойдет для малых проектов, она резонна для сложных и дорогих, например, таких, как разработка системы документооборота для банка, когда каждый следующий шаг требует большего анализа для оценки последствий, чем программирование.
Сравнение каскадной и спиральной моделей разработки:
Задание:
1. Изучить теоретически положения и результаты кратко законспектировать в тетрадь.
2. Сопоставить стадии жизненного цикла ПО со стадиями разработки по ГОСТ 19.102-70, стадиями и этапами разработки АС по ГОСТ 34.601-90 и процессами ЖЦ ПО по ГОСТ Р ИСО/МЭК 12207-2010. Результаты записать в тетрадь (например, в виде таблицы)
| Стадии ЖЦ ПО: | Стадии работ по ГОСТ 19.102 | Стадии работ по ГОСТ 34.601 | Процессы ЖЦ ПО по ГОСТ Р ИСО/МЭК 12207 |
| Формирование требований к ПО | |||
| Проектирование | |||
| Реализация | |||
| Тестирование | |||
| Ввод в действие | |||
| Эксплуатация и сопровождение | |||
| Снятие с эксплуатации |
3. Ответить на вопросы и результаты записать в тетрадь:
Какие модели ЖЦ ПС реализованы в стандартах ГОСТ 19.102-70, ГОСТ 34.601-90, ГОСТ Р ИСО/МЭК 12207-2010?