
- •А. М. Минитаева разработка и стандартизация программных средств и информационных технологий
- •Isbn 978-5-8149-1063-9 введение
- •1.2. Какова структура нормативной базы предприятия и как ее выбрать?
- •1.3. Цели, задачи и состав нормативно-методического обеспечения
- •Все ли надо стандартизировать?
- •1.4. Нужно ли пользоваться международными стандартами или разрабатывать свои, российские?
- •Состав и статус дополнительных стандартов.
- •P.S. Кто должен разрабатывать стандарты?
- •1.5. Почему возрастает роль технологии при разработке программного обеспечения?
- •1.6. Стандартизация в области технологии разработки по
- •2. Общие положения о стандартах
- •2.1. Нормативные документы по стандартизации и виды стандартов
- •2.2. Стандарты в области программного обеспечения
- •2.3. Международные организации, разрабатывающие стандарты
- •2.4. Национальные организации, разрабатывающие стандарты
- •2.5. Внутрифирменные (внутрикорпоративные) стандарты
- •2.6. Организация разработки внутрифирменных стандартов
- •2.7. Хранение аналитической информации
- •3. Стандартизация разработки программных средств
- •3.1. Характеристики процессов жц пс согласно гост р исо/мэк 12207
- •3.2. Основные процессы жизненного цикла программного продукта
- •3.3. Вспомогательные (поддерживающие) процессы жизненного цикла программного продукта
- •3.4. Организационные процессы жизненного цикла программного продукта
- •3.5. Взаимосвязь между процессами жизненного цикла программного продукта
- •3.6. Технология разработки программного обеспечения
- •4. Жизненный цикл программного продукта
- •4.1. Общие принципы стандартизации жизненного цикла программных средств
- •4.2. Понятие жизненного цикла программного продукта
- •5. Модели жизненного цикла разработки программного продукта
- •5.1. Общие принципы моделирования жизненного цикла программных средств
- •5.2. Понятие модели жизненного цикла разработки программного продукта
- •5.3. Классическая каскадная, или «водопадная» модель
- •5.4. Модифицированная каскадная, или модель «водоворота»
- •5.5. Модель «сделал-исправил»
- •5.6. Прототипирование
- •5.7. Спиральная модель жц пс
- •5.8. Другие модели жц пс
- •5.9. Модель быстрой разработки приложений (rad-модель)
- •5.10. Многопроходная модель
- •6. Проектирование программного продукта
- •6.1. Общая характеристика и компоненты проектирования
- •6.2. Эволюция разработки программного продукта
- •6.3. Структурное программирование
- •6.4. Объектно-ориентированное проектирование
- •7. Основные этапы работы по созданию программного продукта
- •7.1. Длительность основных этапов
- •7.2. Характеристика основных этапов
- •Библиографический список
5.3. Классическая каскадная, или «водопадная» модель
В однородных информационных системах 1970-х и 1980-х годов прикладные ПП представляли собой единое целое. Для разработки такого типа ПП применялась классическая каскадная, или «водопадная» модель ЖЦ ПС (по-английски waterfall model, рисунок 5.1). Создана по образу и подобию методик, наработанных в других инженерных областях, где существует стандартная практика поэтапного создания продукта, начиная с составления технического задания (спецификаций) и заканчивая поставкой заказчику. Такая модель реализует, по сути, принцип однократного выполнения каждого вида деятельности в виде заранее ограниченных и однозначно упорядоченных во времени стадий, этапов или фаз проекта, осуществляемых как бы в их естественных границах, например, как показано на рисунке 5.1.
Преимущества каскадного способа: на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; выполняемые в логичной последовательности стадии работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Рис. 5.1. Каскадная модель
Каскадный подход хорошо зарекомендовал себя при построении информационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования с целью предоставить разработчикам свободу реализовать их технически как можно лучше. В эту категорию попадают сложные системы с большим числом задач вычислительного характера, системы реального времени и др.
В то же время данный подход обладает рядом существенных недостатков, обусловленных прежде всего тем, что реальный процесс разработки ПП никогда не укладывается и такую жесткую схему. Этот процесс носит, как правило, итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних стадиях. Таким образом, постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс разработки принимает иной вид (см. рис. 5.2).
5.4. Модифицированная каскадная, или модель «водоворота»
Более реальной и близкой к практике программирования представляется модифицированная каскадная модель, или модель «водоворота», изображенная на рисунке 5.2.
В отличие от классической, данная модель допускает параллельное выполнение отдельных работ (их перекрытие), а также возвраты назад, в том числе и на несколько фаз, в случае обнаружения ошибок. Таким образом, в данных моделях есть место проверкам и аттестации.
Заметим, что процессы сопровождения и эксплуатации обычно реализуют после процесса разработки. Процессы же заказа, поставки, а также вспомогательные и организационные процессы обычно выполняют параллельно с процессом разработки.
Данная модель ЖЦ стандартизована Министерством обороны США (DOD STD 2167A) для ПС военного назначения и является документально управляемой, т.е. каждая фаза такой модели считается окончательно завершенной только в том случае, если оформлены все оговоренные для нее стандартом документы.
Модифицированная каскадная модель ЖЦ является наиболее подходящей для промышленной разработки относительно больших ПС с заранее четко определенными функциями и требованиями к качеству. Такая ситуация обычно имеет место при разработке систем военного назначения, аэрокосмических систем или систем управления технологическими процессами в реальном времени, а также других критических систем. Однако и у такой модели ЖЦ есть свои недостатки, проявляющиеся особенно ярко при разработке ПС в условиях неопределенности исходных требований, что часто имеет место при проектировании информационных систем, например, экономического характера. В такой ситуации огромное значение приобретает этап формулирования требований, составления спецификаций и создания плана проекта. Системные аналитики несут личную ответственность за все последующие изменения проектных решений. Поэтому объем документации исчисляется тысячами страниц, а количество утверждающих заседаний, отнимающих рабочее время многих людей, просто огромно. И очень важным становится момент принятия окончательного решения о передаче проекта в разработку, потому что необходимость что-либо изменить впоследствии может оказаться фатальной для чьей-нибудь карьеры. Именно по этой причине многие проекты при использовании каскадной модели ЖЦ ПС так никогда и не покинули фазу планирования, впав в так называемый «паралич анализа» [3].