Процессы жизненного цикла
ГОСТ 19.102-77. ЕСПД. Стадии разработки. (1)
Стадии |
Этапы работ |
Содержание работ |
1. Техническое |
Обоснование |
Постановка задачи. Сбор исходных материалов. Выбор и |
задание |
необходимости разработки |
обоснование критериев эффективности и качества |
|
программы |
разрабатываемой программы. Обоснование необходимости |
|
|
проведения научно-исследовательских работ |
|
Научно-исследовательские |
Определение структуры входных и выходных данных. |
|
работы |
Предварительный выбор методов решения задач. Обоснование |
|
|
целесообразности применения ранее разработанных программ. |
|
|
Определение требований к техническим средствам. Обоснование |
|
|
принципиальной возможности решения поставленной задачи |
|
Разработка и утверждение |
Определение требований к программе. Разработка технико- |
|
технического задания |
экономического обоснования разработки программы. |
|
|
Определение стадий, этапов и сроков разработки программы и |
|
|
документации на нее. Выбор языков программирования. |
|
|
Определение необходимости проведения научно- |
|
|
исследовательских работ на последующих стадиях. Согласование |
|
|
и утверждение технического задания |
2. Эскизный |
Разработка эскизного |
Предварительная разработка структуры входных и выходных |
проект |
проекта |
данных. Уточнение методов решения задачи. Разработка общего |
|
|
описания алгоритма решения задачи. Разработка технико- |
|
|
экономического обоснования |
|
Утверждение эскизного |
Разработка пояснительной записки. Согласование и утверждение |
|
проекта |
эскизного проекта |
© 2005, В.В.Хашковский, Д.П.Калачев. |
21 |
Процессы жизненного цикла
ГОСТ 19.102-77. ЕСПД. Стадии разработки. (2)
Стадии |
Этапы работ |
Содержание работ |
3. Технический |
Разработка технического |
Уточнение структуры входных и выходных данных. Разработка |
проект |
проекта |
алгоритма решения задачи. Определение формы представления |
|
|
входных и выходных данных. Определение семантики и |
|
|
синтаксиса языка. Разработка структуры программы. |
|
|
Окончательное определение конфигурации технических средств |
|
Утверждение технического |
Разработка плана мероприятий по разработке и внедрению |
|
проекта |
программ. Разработка пояснительной записки. Согласование и |
|
|
утверждение технического проекта |
4. Рабочий проект |
Разработка программы |
Программирование и отладка программы |
|
Разработка программной |
Разработка программных документов в соответствии с ГОСТ |
|
документации |
19.101-77 |
|
Испытания программы |
Разработка, согласование и утверждение программы и методики |
|
|
испытаний |
|
Испытания программы |
Проведение предварительных государственных, |
|
|
межведомственных, приемосдаточных и других видов испытаний. |
|
|
Корректировка программы и программной документации по |
|
|
результатам испытаний |
© 2005, В.В.Хашковский, Д.П.Калачев. |
22 |
Процессы жизненного цикла
ГОСТ 19.102-77. ЕСПД. Стадии разработки. (3)
Стадии |
Этапы работ |
Содержание работ |
5. Внедрение |
Подготовка и передача |
Подготовка и передача программы и программной документации |
|
программы |
для сопровождения и (или) изготовления. Оформление и |
|
|
утверждение акта о передаче программы на сопровождение и |
|
|
(или) изготовление. Передача программ в фонд алгоритмов и |
|
|
программ |
Стадии эскизного и технического проектов могут быть исключены по согласованию с заказчиком. Кроме этого, допускается вводить другие этапы работ, если это технически обосновано.
© 2005, В.В.Хашковский, Д.П.Калачев. |
23 |
Процессы жизненного цикла
Rational Unified Process.
Итерация - это законченный цикл разработки, приводящий к выпуску выполнимого изделия (внутренней или внешней версии) или подмножества конечного изделия, которое возрастает от итерации к итерации, чтобы стать законченной системой.
© 2005, В.В.Хашковский, Д.П.Калачев. |
24 |
Процессы жизненного цикла
Rational Unified Process.
© 2005, В.В.Хашковский, Д.П.Калачев. |
25 |
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
(Software engineering)
Учебный курс
очного обучения по специальностям 230105 «Программное обеспечение вычислительной техники и автоматизированных систем»
010503 «Математическое обеспечение и администрирование информационных систем»
кафедры МОП ЭВМ
Л Е К Ц И Я 8 семестр
1.3
Модели
разработки
программных систем.
В.В.Хашковский, к.т.н., доц. каф. МОП ЭВМ ТРТУ
Д.П.Калачев, доц., к.т.н., доц. каф. МОП ЭВМ
ТРТУ
Традиционные модели разработки
Водопадная модель. При таком подходе разработка ПС состоит из цепочки
этапов. На каждом этапе создаются документы, используемые на последующем этапе. В исходном документе фиксируются требования к ПС. В конце этой цепочки создаются программы, включаемые в ПС.
Эволюционное развитие (прототипирование), в двух вариантах — с доработкой прототипа и с выбрасыванием, т.е. переписыванием.
Подход предполагает быструю (насколько это возможно) реализацию рабочих версий программ ПС, выполняющих лишь в первом приближении требуемые функции. После экспериментального применения реализованных программ производится их модификация с целью сделать их более полезными для пользователей. Этот процесс повторяется до тех пор, пока ПС не будет достаточно приемлемо для пользователей. Возможно в дальнейшем должна последовать разработка ПС по установленным
требованиям в рамках какого-либо другого подхода (например, водопадного).
Формальные преобразования. Основан на создании математических моделей системы и их дальнейшим преобразованиями, сохраняющими корректность
Сборка из повторно используемых компонент. Подход предполагает, что
ПС конструируется, главным образом, из компонент, которые уже существуют. Должно быть некоторое хранилище (библиотека) таких компонент, каждая из которых может
многократно использоваться в разных ПС. Такие компоненты называются повторно используемыми (reusable). Процесс разработки ПС при данном подходе состоит скорее
из сборки программ из компонент, чем из их программирования.
© 2005, В.В.Хашковский, Д.П.Калачев. |
27 |
Модели разработки
Waterfall Model. Водопадная модель
Системный |
Requirements |
|
|
|
|
анализ |
|
|
|
||
Description |
|
|
|
||
|
(внешнее описание ) |
|
|
|
|
Анализ |
Specification, |
|
|
|
|
требований |
Software project management plan. |
||||
|
|
(спецификации требований) |
|
||
|
Проектирование Design Docs |
Проблема? |
|||
Verify |
|
(спецификации архитектуры) |
|||
|
|
|
original model didn |
||
output of stages |
Кодирование |
|
let you go back! |
||
|
|
Product |
|
||
|
|
& Тестирование |
|
||
|
|
Использование |
Снятие с |
||
© 2005, В.В.Хашковский, Д.П.Калачев. |
Сопровождение |
эксплуатации |
|||
|
|
|
|
||
Модели разработки
Waterfall Model. Основные этапы
Системный анализ задает роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Результат – внешнее описание.
Анализ требований относится к программному обеспечению. Уточняются и детализируются функции, характеристики и интерфейс. Результат – спецификации требований.
Проектирование состоит в создании представлений: архитектуры, модульной структуры, алгоритмической структуры, структуры данных, входного и выходного интерфейса. Результат – спецификации структуры продукта и компонентов.
Кодирование состоит в переводе результатов проектирования в текст на языке программирования. Результат – предварительная версия продукта.
Тестирование – выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта. Результат – тесты, оценка, продукт.
Сопровождение – внесение изменений в эксплуатируемое ПО. Цель: исправление© 2005, В.В.Хашковский,ошибок,Д.П.Калачев.адаптация к изменениям внешней среды, 29
усовершенствование по требованиям заказчика (пользователя).
Модели разработки
Waterfall Model. Другой взгляд
В рамках водопадного подхода часто различают следующие стадии жизненного цикла ПС:
•разработку ПС,
•производство |
|
|
Стадия производства |
|
|
||||
|
|
программных изделий |
||
программных |
Стадия разработки ПС |
|
|
Стадия эксплуатации |
изделий (ПИ) и |
|
|
|
ПС |
•эксплуатацию ПС. |
|
|
|
Фаза применения ПС |
|
|
|
|
|
|
Этап внешнего |
|
|
Фаза сопровождения ПС |
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
описания ПС |
|
|
Этап аттестации |
|
|
|
|
|
|
|
|
|
ПС |
|
Этап конструи- |
|
|
Этап кодирования |
|
рования ПС |
|
|
|
|
|
|
ПС |
|
|
|
|
|
|
© 2005, В.В.Хашковский, Д.П.Калачев. |
30 |
|
|
|
|
|
|
Стадия производства |
||
|
|
|
|
|
||||
Модели разработки |
|
|
|
программных изделий |
||||
Стадия разработки ПС |
|
|
|
Стадия эксплуатации |
||||
Waterfall Model. Стадия разработки |
|
|
|
|||||
|
|
|
ПС |
|||||
|
|
|
Фаза применения ПС |
|
||||
|
|
|
|
|
|
|
|
|
Стадия разработки (development) ПС состоит из |
|
|
|
|
|
|||
|
|
|
Фаза сопровождения ПС |
|||||
|
|
|
Этап внешнего |
|
|
|
||
|
|
|
|
|
|
|
|
|
нескольких этапов (см. ниже). Всем этим этапам |
|
|
|
|
|
|||
сопутствуют процессы документирования и описания ПС |
|
|
|
Этап аттестации |
||||
управления (management) ПС. |
Этап конструи- |
|
|
|
ПС |
|||
Этап |
внешнего описания |
|
|
|
|
|
|
|
|
ПС включает процессы, |
|
|
|
|
|
||
приводящие к созданию некоторого документа,рования ПС |
Этап кодирования |
ПС |
который называют внешним описанием (requirements document) ПС. Этот документ является описанием поведения ПС с точки зрения внешнего по отношению к нему наблюдателя с фиксацией требований относительно его качества. Внешнее описание ПС начинается с анализа и определения требований к ПС со стороны пользователей (заказчика), а также включает процессы спецификации этих требований.
Конструирование (design) ПС охватывает процессы: разработку архитектуры ПС, разработку структур программ ПС и их детальную спецификацию. Кодирование (coding) ПС включает процессы создания текстов программ на языках программирование, их отладку с тестированием ПС. Этапы
конструирования и кодирования часто перекрываются, иногда довольно сильно. Это означает, что кодирование некоторых частей программного средства может быть начато до завершения этапа конструирования
На этапе аттестации (acceptance) ПС производится оценка качества ПС. Если эта оценка оказывается приемлемой для практического использования ПС, то
разработка ПС считается законченной. Это обычно оформляется в виде 31
© 2005, В.В.Хашковский, Д.П.Калачев.
некоторого документа, фиксирующего решение комиссии, проводящей