Материал: Исследование и разработка информационной системы сервисного обслуживания клиентов на примере ООО «Лаборатория ремонта»
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
55
Жизненный цикл программного средства представлен каскадной моделью
и базируется на стандарте ГОСТ 34.601-90 Информационная технология.
Комплекс стандартов на автоматизированные системы. Автоматизированные
системы. Стадии создания:
– определение требований к разработке ИС, влияет пользователь
Заказчик и Проектировщик;
– разработка технического задания, влияет Проектировщик;
– проектный эскиз, влияет Проектировщик;
– программирование ИС, влияет Программист;
– отладка компонентов, влияет Программист и Заказчик;
– ввод в действие, влияет Программист и Заказчик.
Для каждой стадии построим соответствующую диаграмму. На рисунке
2.2 представлено описание «Определение требований к разработке ИС»
35
.
Рис. 2.2 Определение требований к разработке ИС
Диаграмма для следующей стадии представлена на рисунке 2.3.
разработка технического задания является одним из важнейших этапов
построения информационных систем, данный документ является руководством к
35
Избачков, Ю. Информационные системы / Ю. Избачков, В. Петров. - Москва: Наука, 2014. – С. 356.
56
действию и инструкцией для разработчиков информационных систем.
Тщательно, четко составленное техническое задание позволяет избегать
путаницы и дает возможность создания качественного программного продукта.
Рис. 2.3 Разработка технического задания
На рисунке 2.4 представлен процесс «Разработка проекта».
Рис. 2.4 Разработка проекта ИС
57
На рисунке 2.5 представлен процесс «Программирование ИС».
Рис. 2.5 Программирование ИС
На рисунке 2.6 представлен процесс «Отладка компонентов».
Рис. 2.6 Отладка компонентов
58
На рисунке 2.7 представлен процесс «Ввод в действие».
Рис. 2.7 Ввод в действие
Следование представленным стадиям, позволит создать качественный,
функциональный программный продукт.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их
описание
Определим риски на каждом этапе жизненного цикла
36
.
Стадия 1. Определение требований к разработке ИС, на данной стадии
возможны следующие риски:
– риск несогласованности – возможно, что требования, которые
формулирует заказчик не учтены в полной мере разработчиком, реагирование на
данный риск, уточнение и дальнейшее согласование требований;
36
Андреева, В.И. Делопроизводство. Требования к документообороту фирмы (на основе ГОСТов РФ) /
В.И. Андреева. - М.: Бизнес-школа Интел-Синтез; Издание 2-е, перераб. и доп., 2016. – С. 77-81.
59
– риск не понимания – возможно, что заказчик и разработчик говорят об
одном и том, же, однако их формулировки значительно разнятся, что может
привести к неоднозначности интерпретации требований. Реагирование на
данный риск, уточнение, упрощение формулировок, переход к стандартным
определениям, которые не допускают двузначности;
Стадия 2. Разработка технического задания может содержать следующие
риски:
– некорректно составленное техническое задание – может привести к
тому, что разработчик выполнит не совсем тот функционал информационной
системы, который ожидает заказчик. Реагирование на данный вид риска будет
следующий – привлечение сторонних экспертов, которые позволяет разъяснить
заказчику пункты технического задания или самому скорректировать структуру
данного документа;
Стадия 3. Проектный эскиз может содержать следующие риски:
– непонятность составленных моделей, описаний проектных решений,
алгоритмов, по которым работает информационная система. Реагирование на
данный риск следующий – построение моделей с помощью CASE средств,
использование ГОСТа при обозначении основных узлов;
– проект может иметь необоснованные данные или сроки. Реагирование
на данный вид риска сводится к тому, что при формировании проекта помимо
проектировщика должен принимать участие и программист;
Стадия 4. Программирование ИС может содержать следующие риски:
– не выполнение в установленный срок. Реагирование на данный вид
риска – адекватное распределение между программистами задания, привлечение
в случае необходимости сторонних исполнителей;
Стадия 5. Отладка компонентов имеет следующий вид риска:
– не нахождения ошибок. Реагирование на данный вид риска –
привлечение сторонних тестировщиков, которые имеют опыт по тестированию
программного обеспечения;
Стадия 6. Ввод в действие имеет следующий вид риска:
Источник: https://baza.diplomsite.ru/previewfile/8716