61
ГЛАВА 2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
В Республике Беларусь создание программного обеспечения,
регламентированы небольшой группой стандартов ГОСТ ЕСПД, которые
отстают от мирового уровня на 5–8 лет. В данных документах создание и
сопровождение программных средств отражены недостаточно, а также часть
положений этих документов устарела. Поэтому в современных разработках в
Беларуси широко применяются международные стандарты.
Наиболее распространенным документом стандартизации ЖЦ ПО
является стандарт ISO/IEC 12207 – Information Technology – Software Life Cycle
Processes [1]. В 2003 г. он был принят как «СТБ ИСО/МЭК 12207–2003.
Информационные технологии. Процессы жизненного цикла программных
средств» [2].
Основными характеристиками стандарта ISO/IEC 12207 являются:
единая терминологии по разработке и применению ПО;
разделение понятий ЖЦ ПО и модели ЖЦ ПО: ЖЦ ПО в стандарте
вводится как полная совокупность всех процессов и действий по созданию и
применению ПО, а модель ЖЦ – конкретный вариант организации ЖЦ,
обоснованно (разумно) выбранный для каждого конкретного случая;
описание организации ЖЦ и его структуры (процессов);
выделение процесса адаптации стандарта для построения
конкретных моделей ЖЦ.
В стандарте ISO/IEC 12207 дается ряд определений.
Программный продукт (software product) – набор машинных программ,
процедур и, возможно, связанных с ними документации и данных.
Жизненный цикл программного продукта (software life cycle) – это
непрерывный процесс, который начинается с момента принятия решения о
необходимости его создания и заканчивается в момент его полного изъятия из
эксплуатации
62
Процесс (process) – набор взаимосвязанных работ, которые преобразуют
исходные данные в выходные результаты.
Стандарт определяет организацию ЖЦ программного продукта как
совокупность процессов, каждый из которых разбит на действия, состоящие из
отдельных задач. Устанавливает структуру (архитектуру) ЖЦ программного
продукта в виде перечня процессов, действий и задач.
В стандарте ISO/IEC 12207 модель жизненного цикла (life cycle model)
определяется как структура, состоящая из процессов, работ и задач,
включающих в себя разработку, эксплуатацию и сопровождение программного
продукта, охватывающая жизнь системы от установления требований к ней до
прекращения ее использования.
Стандарт СТБ ИСО/МЭК 12207–2003, являющийся основным
стандартом в области ЖЦ ПС и систем в Республике Беларусь, оговаривает, что
выбор модели ЖЦ должен осуществляться в начале разработки программного
средства или системы. Выбранная модель адаптируется к особенностям
разрабатываемого проекта и к требованиям действующих стандартов. На
адаптацию модели ЖЦ ПО влияют характеристики проекта, определенные в
стандартах СТБ ИСО/МЭК 12207–2003 и ГОСТ Р ИСО/МЭК ТО 15271–2002 [3].
Для проектирования и реализации подсистемы, дополняющую основную
информационную систему ведения документации и отчетности на предприятии
ОАО «Бобруйсктранс» выбран СТБ ИСО/МЭК 12207–2003, принятый на
территории Республики Беларусь и являющимся адаптированным стандартом,
созданным на основе международного документа ISO/IEC 12207 – Information
Technology – Software Life Cycle Processes.
В настоящее время существуют три базовые стратегии разработки
программного обеспечения:
каскадная;
инкрементная;
эволюционная.
Каскадная стратегия представляет собой однократный проход этапов
разработки. Данная стратегия основана на полном определении всех требований
к разрабатываемому программному средству в начале процесса разработки.
63
Каждый последующий этап начинается после окончания предыдущего этапа.
Отсутствует промежуточные версии программного средства.
Представителями моделей, реализующих каскадную стратегию,
являются каскадная и V-образная модели.
Инкрементная стратегия представляет собой многократный проход
этапов разработки с запланированным улучшением результата. Данная стратегия
основана на полном определении всех требований к разрабатываемому
программному средству в начале процесса разработки. Однако полный набор
требований реализуется постепенно в соответствии с планом в
последовательных циклах разработки. Результат каждого цикла представляет
собой версию программного средства. Особенностью инкрементной стратегии
является большое количество циклов разработки при их небольшой
продолжительности.
Инкрементная стратегия обычно основана на объединении элементов
каскадной модели и прототипирования.
Эволюционная стратегия представляет собой многократный проход
этапов разработки. Данная стратегия основана на частичном определении
требований к разрабатываемому программному средству в начале процесса
разработки. Требования постепенно уточняются в последовательных этапах
разработки. Результат каждого цикла разработки обычно представляет собой
версию программного средства. Для эволюционной стратегии характерно
меньшее количество циклов разработки при большей их продолжительности по
сравнению с инкрементной стратегией. При этом результат каждого цикла
разработки существенно отличается от результата предыдущего цикла.
Представителями моделей, реализующих эволюционную стратегию,
являются, например, спиральные модели [18. стр. 121].
Каждая из стратегий разработки имеет как достоинства, так и
недостатки, описанные в таблице 2.1.
64
Таблица 2.1
Достоинства и недостатки стратегий разработки программных средств и систем
Стратегия
разработки
программных
средств и
систем
Достоинства
Недостатки
1
2
3
Каскадная
1) стабильность требований в
течение ЖЦ разработки;
2) простоту применения
стратегии, так как
необходимо только один раз
проходить каждый этап
разработки;
3) простота планирования,
контроля и управления
проектом;
4) доступность для
понимания заказчиками.
1) сложность полного
формулирования требований в
начале процесса разработки и
невозможность их
динамического изменения на
протяжении ЖЦ;
2) линейность структуры
процесса разработки, в
результате чего могут
возникнуть проблемы с
увеличением финансовых
затрат и нарушению графика
работ;
3) непригодность
промежуточных продуктов
для использования;
4) недостаточное участие
пользователя в процессе
разработки ПС, что приводит к
невозможности
предварительной оценки
пользователем качества
программного средства или
системы.
65
Продолжение таблицы 2.1
1
2
3
Инкрементная
1) возможность получения
функционального продукта
после реализации каждого
инкремента;
2) короткая
продолжительность создания
инкремента;
3) предотвращение
реализации громоздких
спецификаций требований;
стабильность требований во
время создания
определенного инкремента;
возможность учета
изменившихся требований;
4) снижение рисков по
сравнению с каскадной
стратегией;
5) включение в процесс
пользователей.
1) необходимость полного
функционального определения
системы или программного
средства в начале ЖЦ;
2) возможность текущего
изменения требований к
системе или программному
средству, которые уже
реализованы в предыдущих
инкрементах;
3) сложность планирования и
распределения работ;
4) возможность возникновения
оттягивания решения трудных
проблем на поздние
инкременты, что может
нарушить график работ или
снизить качество
программного продукта.
66
Продолжение таблицы 2.1
1
2
3
Эволюционная
1) возможность уточнения и
внесения новых требований в
процессе разработки;
2) пригодность
промежуточного продукта
для использования;
3) возможность управления
рисками;
4) обеспечение широкого
участия пользователя в
проекте, начиная с ранних
этапов;
5) реализация преимуществ
каскадной и инкрементной
стратегий.
1) неизвестность точного
количества необходимых
итераций и сложность
определения критериев для
продолжения процесса
разработки на следующей
итерации;
2) сложность планирования и
управления проектом;
3) необходимость активного
участия пользователей в
проекте, что реально не всегда
осуществимо;
4) необходимость в мощных
инструментальных средствах и
методах прототипирования;
5) возможность отодвигания
решения трудных проблем на
последующие циклы.
Использование каждой из стратегий наиболее эффективно в следующих
случаях [18. стр. 135]:
Каскадная стратегия
1) при разработке проектов с четкими, неизменяемыми в течение ЖЦ
требованиями и понятной реализацией;
2) при разработке проектов невысокой сложности, например:
создание программного средства или системы такого же типа, как уже
разрабатывались разработчиками;
создание новой версии уже существующего программного средства
или системы;
67
перенос уже существующего продукта на новую платформу;
3) при выполнении больших проектов в качестве составной части
моделей ЖЦ, реализующих другие стратегии разработки.
Инкрементная
1) используется при разработке проектов, в которых большинство
требований можно сформулировать заранее, но часть из них может быть
уточнена через определенный период времени;
2) используется при разработке сложных проектов с заранее
сформулированными требованиями; для них разработка системы или
программного средства основана на полном определении всех требований к
разрабатываемому программному средству или системе в начале процесса
разработки. Однако полный набор требований реализуется постепенно в
соответствии с планом в последовательных циклах разработки. При
инкрементной стратегии часто используется прототипирование. Инкрементная
стратегия имеет достоинства и недостатки, определяемые правильностью
выбора данной стратегии по отношению к конкретному проекту.
Эволюционная
1) при разработке проектов, для которых требования слишком сложны,
неизвестны заранее, непостоянны или требуют уточнения;
2) при разработке сложных проектов, в том числе:
больших долгосрочных проектов;
проектов по созданию новых, не имеющих аналогов ПС или систем;
проектов со средней и высокой степенью рисков;
проектов, для которых нужна проверка концепции, демонстрация
технической осуществимости или промежуточных продуктов;
3) при разработке проектов, использующих новые технологии.
Три базовые стратегии могут быть реализованы с помощью различных
моделей жизненного цикла.
Анализируя достоинства и недостатки каждой из представленных
стратегий жизненного цикла программного обеспечения, а также сферы их
наиболее благоприятного применения выбрана для реализации подсистемы,
решающей задачу учета принтеров и МФУ предприятия ОАО «Бобруйсктранс»,
68
V-образная модель жизненного цикла, которая относится к каскадной стратегии.
В процессе выбора были учтены особенности разрабатываемого программного
средства, требования к нему, участие в работе заказчика.
V-образная модель предполагает предварительное формирование
требований. В классической V-образной модели каждый шаг начинается после
завершения предыдущего шага. Отличием V-образной модели от каскадной
является то, что в ней выделены связи между шагами, предшествующими
программированию, и соответствующими видами тестирования и испытаний.
V-образной модель ЖЦ программного обеспечения представлена на рисунке 2.1.
Рис. 2.1 V-образная модель жизненного цикла
При использовании V-образная модели планирование тестирования и
испытаний производиться на ранних стадиях разработки программного средства,
упрощена оценка промежуточных результатов разработки, облегчен процесс
управления и контроля за ходом разработки [18. стр. 141].
69
Процесс разработки состоит следующих этапов, выполняемых
разработчиком.
Данный процесс содержит тринадцать работ:
1) подготовка процесса разработки;
2) анализ требований к системе;
3) проектирование системы;
4) проектирование программных средств;
5) программирование и тестирование программных средств;
6) сборка и квалификационные испытания программных средств;
7) сборка и квалификационные испытания системы;
8) ввод в действие и обеспечение приемки программных средств;
9) эксплуатация и сопровождение.
При выполнении этапа «Подготовка процесса разработки» выбрана
модель жизненного цикла программного средства. Приняты решения о
применяемых методах, инструментальных средства разработки и языках
программирования.
На этапе «Анализ требований к системе» проанализирована область
применения подсистемы и определены требования к ней. Оговорен план
разработки, ввода в действие и обеспечения приемки проекта.
В процессе этапа «Проектирование системы» определены общая,
техническая и программная архитектуры проекта. Проанализировано назначение
программного средства и, на основании выполненного анализа, уточнены
требования к нему. Также на данном этапе оговорены планы сборки и
квалификационных испытаний системы.
В результате выполнения этапа «Проектирование программных средств»
требования к программному средству преобразованы в его архитектуру,
осуществлено детальное проектирование программного средства. Произведено
распределение технических требований к компонентам между программными
модулями.
70
При выполнении этапа «Программирование и тестирование
программных средств» осуществляется кодирование и тестирование
программных модулей, а также оценка полученных результатов.
На этапе «Сборка и квалификационные испытания программных
средств» производится сборка и тестирование промежуточных и конечных
результатов разработанных программных модулей и компонентов.
Анализируются результаты тестирования программного средства с
моделируемыми исходными данными.
В процессе этапа «Сборка и квалификационные испытания системы»
осуществлена сборка программных модулей, технической конфигурации, и
ручных операций в единую подсистему. Проведено тестирование и оценка
качества собранной подсистемы с моделируемыми исходными данными.
В результате выполнения этапа «Ввод в действие и обеспечение приемки
программных средств» разработанный проект введен в действие в среде
эксплуатации, проведено заказчиком приемочных испытаний с целью проверки
пользователем соответствия системы исходным требованиям.
На этапе «Эксплуатация и сопровождение» определяются недоработки и
согласованность работы всех компонентов. При выявлении недоработок
определяются перечень указаний для исправлений разработчиком.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Разработка подсистемы, автоматизирующей задачу учета принтеров и
МФУ, для предприятия ОАО «Бобруйсктранс», может быть связана с
возможными рисками, возникающими на различных этапах жизненного цикла.
На этапе «Подготовка процесса разработки» возможно возникновение
следующих рисков:
Недальновидный анализ сроков проекта;
Некачественный анализ бюджета проекта;
Неправильно подобран состав разработчиков, отсутствие
командной работы.