Дипломная работа: Автоматизация процесса ведения документации и отчетности в ОАО «Бобруйсктранс»

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