Дипломная работа: Автоматизация процесса ведения документации и отчетности в ОАО «Бобруйсктранс»
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
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) возможность возникновения
оттягивания решения трудных
проблем на поздние
инкременты, что может
нарушить график работ или
снизить качество
программного продукта.
Источник: https://baza.diplomsite.ru/previewfile/2041