44
большой разрыв между временем внесения ошибки (например, на этапе
проектирования) и временем ее обнаружения (при сопровождении), что приводит к
большой переделке ПС.
Каскадную модель можно рассматривать как модель ЖЦ, пригодную для создания
первой версии ПО с целью проверки реализованных в ней функций. При сопровождении и
эксплуатации могут быть обнаружены разного рода ошибки, исправление которых
потребует повторного выполнения всех процессов, начиная с уточнения требований.
Для данной модели ЖЦ подходит применение стандарта разработки ISO/IEC
15288. ISO/IEC 15288 - это стандарт на процессы и организацию жизненного цикла. Он
распространяется на все виды заказного ПО. Данный стандарт подходит лучше всего,так
как не содержит описания фаз, стадий и этапов.
Стадии создания системы, предусмотренные в стандарте ISO/IEC 15288, несколько
отличаются от рассмотренных выше. Перечень стадий и основные результаты, которые
должны быть достигнуты к моменту их завершения, приведены таблице 2.1.
Таблица 2.1. Стадии создания систем (ISO/IEC 15288)
№ п/п
Стадия
Описание
1
Формирование
концепции
Анализ потребностей, выбор концепции и проектных решений
2
Разработка
Проектирование системы
3
Реализация
Изготовление системы
4
Эксплуатация
Ввод в эксплуатацию и использование системы
5
Поддержка
Обеспечение функционирования системы
6
Снятие с эксплуатации
Прекращение использования, демонтаж, архивирование системы
В рамках данного жизненного цикла был составлен сетевой график для первой
версии и выделены основные этапы разработки(таблица 2.2):
, что также надо учитывать,
45
Таблица 2.2. Перечень событий и работ
Шифр
события
Содержани
е события
Шифр
работы
Содержа
ние
работы
Трудоёмкос
ть работы,
чел.×час
Число
исполнителе
й,
чел
Продолжительность
работы,
Час
1
С1
1-2
Р1
24
1
24
2
С2
2-3
Р2
16
1
16
2
С2
2-4
Р3
8
1
8
3
С3
3-5
Р4
8
1
8
4
С4
4-6
Р5
12
1
12
5
С5
5-6
Р6
0
0
0
6
С6
6-7
Р7
4
1
4
6
С6
6-8
Р8
12
1
12
6
С6
6-10
Р9
3
1
3
7
С7
7-9
Р10
2
1
2
8
С8
8-11
Р11
40
2
20
9
С9
9-11
Р12
0
0
0
10
С10
10-11
Р12
0
0
0
11
С11
11-12
Р13
3
1
3
12
С12
12-13
Р14
32
1
32
12
С12
12-14
Р16
24
1
24
12
С12
12-15
Р15
40
1
40
13
С13
13-15
Р17
0
0
0
14
С14
14-15
Р17
0
0
0
15
С15
15-16
Р18
48
3
16
16
С16
16-17
Р19
3
1
3
17
С17
17-18
Р20
64
2
32
17
С17
17-19
Р21
48
2
24
18
С18
18-20
Р23
0
0
0
19
С19
19-20
Р22
32
2
16
20
С20
20-21
Р24
32
2
16
21
С21
21-22
Р25
16
1
16
46
22
С22
Расшифровка:
С1 – получение задания
С2 – основные аспекты предметной области изучены
С3 – исходные материалы проанализированы
С4 – выявлены требования к разрабатываемому программному продукту
С5 – «узкие места» изученной области выделены
С6 – проанализированы существующие программные продукты
С7 – структура меню проработана
С8 – смоделирована структура данных
С9 – меню запрограммировано
С10 – единая точка входа создана
С11 – схема данных реализована
С12 – профиль администратора создан
С13 – обработка данных об олимпиадах запрограммирована
С14 – функции обработки сведений об аудиториях запрограммированы
С15 – функции обработки данных о дежурных реализованы
С16 – функция распределения дежурных по аудиториям на основании собранных данных
создана
С17 – права пользователей распределены
С18 – документация на программный продукт составлена
С19 – отладка приложения завершена
С20 – тестирование завершено
С21 – пробная эксплуатация проведена
С22 –внедрение приложения произведено
Р1 – изучение предметной области
Р2 – анализ исходных материалов
, что также надо учитывать,
47
Р3 – выявление требований к программному продукту
Р4 – выделение проблемных участков изученной области
Р5 – анализ и сравнение существующих программных продуктов
Р6 – ожидание завершения анализа существующих программных продуктов
Р7 – проработка структуры меню
Р8 – моделирование схемы данных
Р9 – создание единой точки входа
Р10 – программирование меню
Р11 – реализация схемы данных
Р12 – ожидание реализации схемы данных
Р13 – создание профиля администратора
Р14 – программирование обработки данных об олимпиадах
Р15 – реализация функций обработки данных о дежурных
Р16 – программирование функций обработки сведений об аудиториях
Р17 – ожидание завершения реализации обработки данных о дежурных
Р18 – создание функции распределения дежурных по аудиториям на основании
полученных данных
Р19 – распределение прав в зависимости от статуса пользователя
Р20 – составление документации
Р21 – отладка приложения
Р22 – тестирование реализованного программного продукта
Р23 – ожидание завершения тестирования
Р24 – пробная эксплуатация
Р25 – внедрение приложения у конечного заказчика
Критический путь:
2 4 1 2 1 6 2 3 8 3 5 0 5 6 1 2 6 8
2 0 8 1 1 3 1 1 1 2 4 0 1 2 1 5 1 6 1 5 16 3 1 6 17
2 4(1 7 1 9 ) 1 6 (19 2 0 ) 0 1 8 2 0 1 6 20 2 1 16 2 1 2 2 2 14 ч а с о в
, что также надо учитывать,
, что также надо учитывать,
, что также надо учитывать,
48
С учетом 40-ка часовой рабочей недели, необходимое минимальное время
разработки составляет 38 дней.
Сетевой график работ представлен ниже на рис. 2.2.
1
2
3 4
5 6
24 (1)
16 (1)
8 (1)
8 (1) 12 (1)
0 (0)
7 8
10
12 (1)
4 (1)
3 (1)
9 11
2 (1) 20 (1)
12
13 15 14
17
32 (1)
24 (1)
40 (1)
1918
20
24 (2)
32 (2)
0 (0)
16 (2)
21 22
16 (2) 16 (1)
3 (1)
0 (0)
0 (0)
0 (0)0 (0)
16
16 (3)
3 (1)
Рис. 2.2 Сетевой график
Расчет параметров сетевого графа табличным методом представлен в таблице 2.3.
Таблица 2.3. Табличный метод расчета параметров сетевого графа
i
j
t
ij
T
i
p
t
ij
po
T
j
p
T
i
п
t
ij
пн
T
j
п
R
j
R
ij
ч
R
ij
п
q
ij
1
2
24
0
24
24
0
0
24
0
0
0
1
2
3
16
24
40
40
24
24
40
0
0
0
1
2
4
8
24
32
32
24
28
36
4
0
4
1
3
5
8
40
48
48
40
40
48
0
0
0
1
4
6
12
32
44
48
36
36
48
0
4
4
1
49
5
6
0
48
48
48
48
48
48
0
0
0
0
6
7
4
48
52
52
48
74
78
26
0
26
1
6
8
12
48
60
60
48
48
60
0
0
0
1
6
10
3
48
51
51
48
77
80
29
0
29
1
7
9
2
52
54
54
78
78
80
26
0
26
1
8
11
20
60
80
80
60
60
80
0
0
0
2
9
11
0
54
54
80
80
80
80
0
26
26
0
10
11
0
51
51
80
80
80
80
0
29
29
0
11
12
3
80
83
83
80
80
83
0
0
0
1
12
13
32
83
115
115
83
91
123
8
0
8
1
12
14
24
83
107
107
83
99
123
16
0
16
1
12
15
40
83
123
123
83
83
123
0
0
0
1
13
15
0
115
115
123
123
123
123
0
8
8
0
14
15
0
107
107
123
123
123
123
0
16
16
0
15
16
16
123
139
139
123
123
139
0
0
0
3
16
17
3
139
142
142
139
139
142
0
0
0
1
17
18
32
142
174
174
142
150
182
8
0
8
2
17
19
24
142
166
166
142
142
166
0
0
0
2
18
20
0
174
174
182
182
182
182
0
8
8
0
19
20
16
166
182
182
166
166
182
0
0
0
2
20
21
16
182
198
198
182
182
198
0
0
0
2
21
22
16
198
214
214
198
198
214
0
0
0
1
50
Рисунок 2.3 График исполнителей
Что касается внедрения системы, то существуют следующие основные стратегии
внедрения системы:
1) Стратегия «Параллельное использование». Параллельное использование -
параллельно выполняются старая и новая технология решения задачи, их результаты
, что также надо учитывать,
51
сравниваются. Если результаты согласуются длительное время, то осуществляется
переход на новую технологию.
Плюсы:
- минимальный риск ошибок в виде новых технологий;
- управления внедрения ИС может осуществлять независимо от обычного операционного
планирования компании.
Минусы:
- двойная загрузка персонала;
- потребности в удвоенных мощностях серверов;
- необходимость постоянной сверки результатов работы 2х технологий.
2) Стратегия «Скачек». Скачек - старая технология работает до определенного
момента, затем осуществляется внедрение новой технологии, а после внедрения
реализуется только новая технология
Плюсы:
- минимальная длительность переходного периода;
- нет двойных затрат на деятельность компании;
- новые процессы являются наиболее оптимальными в виду отсутствия переходного
периода.
Минусы:
- высокие риски несоответствия качества ИС требованиям компании;
- высокие требования к процессу планирования перехода на новую технологию;
3) Стратегия «Пилотный проект». Пилотный проект - тактика скачка применяема
к ограниченному числу процессов, областью применения обычно является небольшой
участок.
, что также надо учитывать,
52
Плюсы:
- минимальный риск выбора неверного решения, которое не приводит к длительному
простою всего предприятия;
- возможность изменения планируемой технологии в процессе внедрения ИС на участке;
- отсутствие 2х затрат на реализацию технологии.
Минусы:
- сложность интеграции информационных потоков формируемых по старой и новой
технологии;
- необходимость управления старой и новой ИС одновременно.
4) Стратегия «Узкое место». Узкое место - автоматизация малой части
производственного процесса, который обычно выбирается по критериям, их
эффективности приводящих к повышению качества реализации процессов только в
определенном узком месте.
Плюсы:
- после автоматизации каждого узкого места имеется возможность прервать
автоматизацию;
- минимальные требования к уровню планирования работ внедрения.
Минусы:
- выполнение полного цикла планирования на каждом из узких мест - ввиду возможности
прерывания автоматизации процесс может, не закончится некогда;
- независимость автоматизации узких мест может привести к формированию избыточного
множества программно-аппаратных решений.
В данном случае, мною было выбрано стратегия «Узкое место».
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
При осуществлении любого проекта возникают ситуации, связанные с
неполнотой, неопределенностью или неточностью информации об услоиях реализации
проекта и связанных с ним результатом и затрат. Все участники проекта должны быть
, что также надо учитывать,
, что также надо учитывать,
53
заинтересованы в том, чтобы исключить возможность провала проекта из-за таких
ситуаций. Для того чтобы сократить количество просчетов и избежать недоведения
проекта до конечного результата в целом, методология управления проектами
предусматривает специальные процедуры, помогающие учесть факторы
неопределенности и риска на всех фазах и этапах проекта.
Зная виды и значимость рисков, можно на них воздействовать, снижая их
отрицательное влияние на эффективность проекта. Следовательно, создается реальная
возможность управлять ими.
Этап подготовки проекта
1. Риск персонала
Риски:
Привлечение неопытного персонала к выполнению проекта.
Отсутствие единой цели и задачи проекта
Отсутствие мотивации сотрудников
Негативное отношение персонала к проекту
Необдуманный план ведения работ
Способы предотвращения:
Активное взаимодействие с руководством в ходе проекта и своевременное
принятие решений.
Участие в проекте ведущих специалистов и профессиональных консультантов
Четко сформулированные цели проекта
Проработка общей стратегии автоматизации организации
Стабильный состав рабочей группы в течение всего проекта
2. Риск ведения проекта
Риски:
Неверное определение рамок и масштаба проекта
Проектирование ошибочных функций системы
Способы предотвращения:
Обеспечение стабильности границ проекта, которые определяются на начальном
этапе и остаются неизменными вплоть до окончания проекта.
Качественное планирование выполняемых работ
, что также надо учитывать,
, что также надо учитывать,