52
Требования к программным средствам, используемым программой.
Системные программные средства, используемые программой, должны быть
представлены лицензионной локализованной версией операционной системы
Windows 2000 Server или Windows 2003 и Microsoft SQL Server 2000.
Предварительный состав программной документации. Состав
программной документации должен включать в себя:
1. техническое задание;
2. программу и методики испытаний;
3. руководство оператора;
3.3. Этапы реализации проекта
Для удобства клиентов организация старается максимально подробно
планировать работу по внедрению программного продукта. Индивидуальный
план-график реализации проекта позволяет клиенту не только ознакомиться с
ходом внедрения и текущим состоянием разработки, но и непосредственно
участвовать в процессе создания программного решения в течение всего
периода внедрения. С особым вниманием относимся к идеям заказчиков,
понимая их неоспоримую компетенцию в бизнес-процессах своей
организации. [31, с. 32]
1. Проектирование и планирование.
В рамках проведения предпроектного обследования, как правило,
готовится техническое задание (ТЗ). Оно может быть составлено клиентом
самостоятельно или же написано совместно со специалистами. Во втором
случае мы проводим интервью со специалистами компании-клиента,
понимающими бизнес-сторону автоматизируемых процессов, их показатели,
технические аспекты. После получения и обобщения данных мы, предлагаем
желаемое решение. Есть у нас и схема работы без технического задания.
Обычно это происходит при реализации «прорывных» идей клиента, создании
новых продуктов, не имеющих аналогов. В таких случаях время крайне
53
ограниченно, а изменений при реализации проекта множество, так как на
входе была только идея.
Длительность этапа: 2 - 6 недель.
2. Настройка технических параметров клиента.
Этот этап для клиента начинается со знакомства с его персональным
менеджером (представителем компании) и установкой у клиента технических
и программных средств, которые позволят ему видеть прототип
разрабатываемого программного продукта. Наблюдая за ходом работ и
анализируя версии продукта, специалисты компании находят возможности
улучшения первоначального замысла и изменения технического задания или
проекта продукта.
Длительность этапа: 1 день - 1 неделя.
3. Реализация и настройка функциональности продукта.
Этот этап реализуется нашими специалистами, которые как минимум
еженедельно сообщают клиенту о ходе работы, проводят совместные
конференции по согласованному графику. По мере необходимости к решению
появляющихся вопросов привлекаются специалисты компании-клиента.
Длительность этапа зависит от масштабности задачи, поставленной клиентом
перед нами, и наличия готовых, типовых решений. Например, разработка
электронной торговой площадки на базе существующего решения занимает
около 1-2 месяцев, а реализация крупного уникального решения – до
нескольких лет.
4. Тестирование.
Команда обеспечения качества подключается к проекту на ранних
стадиях и ведётся одновременно с разработкой. Составляется план,
выбираются необходимые методы тестирования. В большинстве наших
проектов мы используем несколько подходов к тестированию, включая
проведение автоматизированных модульных и функциональных тестов и,
конечно, ручное тестирование. Далее производится установка тестовой версии
программного продукта на тестовую площадку, где его испытывают будущие
54
пользователи нового ПО. Очень важным на этом этапе является участие
представителей компании-клиента — это позволяет учесть пожелания
реальных пользователей перед вводом продукта в промышленную
эксплуатацию.
Длительность этапа зависит от времени выполнения проекта.
Тестирование происходит поэтапно.
5. Перенос и развертывание продукта на площадке клиента.
После завершения всех этапов тестирования продукт признается
стабильным и допускается в эксплуатацию. Производится развёртывание
продукта на площадке клиента и начинается опытная эксплуатация. Это может
быть оформлено процедурой приёмо-сдаточных испытаний и разработкой
соответствующей методики.
Длительность этапа: 1 день - 1 неделя.
6. Документирование.
Стандартные документы, которые мы разрабатываем это Руководство
пользователя и Руководство администратора. По желанию клиента, мы можем
подготовить подробную видео инструкцию пользования продуктом и другие
материалы.
Длительность этапа: 1 день - 1 неделя.
7.Опытная эксплуатация.
Клиент начинает полноценную работу с разработанным решением.
Совместно с клиентом высказываемые замечания, пожелания, предложения от
конечных пользователей, анализируем и согласовываем с клиентом что
необходимо, а что будет лишним. По завершении этапа продукт готов к
промышленной эксплуатации.
Длительность этапа: по договоренности с клиентом.
8.Промышленная эксплуатация.
Все этапы выше призваны обеспечить комфортную работу клиента с
продуктом. Оперативно поддерживаем работу клиента. Сначала в рамках
гарантии, а затем в рамках договора сопровождения.
55
Длительность этапа зависит от времени сопровождения.
3.3.1. Разработка и описание проекта автоматизации, плана-графика
автоматизации и сетевой модели задач
Основное содержание работ по созданию проекта автоматизации:
1. Анализ требований к системе;
2. Проектирование системной архитектуры;
3. Разработка структуры базы данных;
4. Разработка инфологической модели информационной системы;
5. Разработка алгоритма обработки запросов;
6. Разработка текста программ;
7. Разработка выходных документов системы;
8. Разработка форм, отвечающего за взаимодействие с
пользователем (интерфейса программы);
9. Тестирование системы;
10. Разработка руководства пользователя.
В таблице 6 приведен перечень событий и работ, имеющих место при
разработке информационной системы инженера отдела АСУ. [32, с. 2]
Для заполнения столбцов “Трудоемкость” таблицы воспользовались
помощью экспертных оценок. Ожидаемая продолжительность работ
вычисляется по формуле (1), где ожидаемая продолжительность работы
рассчитывается как математическое ожидание для - распределения.
Общие затраты труда на разработку и внедрение изделия
(проекта) Q
p
определяются по формуле:
Q
p
=t
1
+t
2
+t
i
+…+t
10
, (1)
где t
i
- затраты труда на выполнение i -го этапа проекта.
Таблица 6- Перечень событий по автоматизации учета аппаратного
обеспечения
№
Трудоемкость
Исп
56
Этап
t
i
Содержание
работы
(чел-час)
(чел-
ни)
t
min
t
max
t
ож
t
ож
1
1
Анализ
требований к
системе
6
12
8,4
1,05
2
2
2
Проектирование
системной
архитектуры
12
23
16,4
2,05
2
3
3
Разработка
структуры базы
данных
8
24
14,4
1,8
1
4
4
Разработка
инфологической
модели
16
48
28,8
3,6
1
5
5
Разработка
алгоритма
обработки
запросов
32
80
51,2
6,4
2
6
6
Написание текста
программ
24
80
46,4
5,8
1
7
7
Разработка
механизма
логического
вывода системы
56
80
65,6
8,2
1
Продолжение таблицы 6
8
8
Разработка
модуля,
отвечающего за
взаимодействие с
пользователем
40
64
49,6
6,2
1
9
9
Общее
тестирование
системы
16
40
25,6
3,2
1
10
Тестирование
механизма
распознавания
16
40
25,6
3,2
1
57
11
Тестирование
интерфейса
пользователя
16
40
25,6
3,2
2
10
12
Разработка
руководства
пользователя
12
23
16,4
2,05
1
Итог
46,75
Полный перечень работ с разделением их по этапам выполнения проекта
приведен в таблице 3.1. В данном случае общие затраты труда на разработку
Q
p
= 46,75 человеко-дней.
Средняя численность исполнителей при реализации проекта разработки
и внедрения ПО определяется отношением :
N=Q
p
/F (2)
где Q
p
- затраты труда на выполнение проекта (разработка и внедрение),
F - фонд рабочего времени.
Величина фонда рабочего времени определяется соотношением:
F=T*F
M
(3)
где Т - время выполнения проекта в месяцах, F
M
- фонд времени в
текущем месяце, который рассчитывается из учета общества числа дней в
году, числа выходных и праздничных дней:
F
M
=t
p
*(D
k
-D
b
-D
n
)/12 , (4)
где t
p
- продолжительность рабочего дня,
D
K
- общее число дней в году, D
B
- число выходных дней в году,
D
П
- число праздничных дней в году.
Тогда фонд времени в текущем месяце F
M
= 8*(365-104-10)/12= 168
часов.
Фонд рабочего времени F 2 168 = 324 часов.
Средняя численность исполнителей N=46*8/324=1,13.
Таким образом, есть необходимость использовать двух исполнителей на
отдельных работах. Продолжительность отдельных работ при одновременном
58
выполнении их несколькими исполнителями (t
i
) определяется из
соотношения:
t
i
= t
pp
/ W
исп*
К
Н
(5)
где t
pp
- расчетная продолжительность работы,
W
исп
- количество исполнителей,
К
Н
- коэффициент выполнения нормы.
Продолжительность работ рассчитывается исходя из того, что одной
работой занят один исполнитель, а коэффициент выполнения нормы равен
единице. Полученные затраты труда по отдельным работам отображены в
таблице 6.
В сетевой модели выделяют события и работы. В качестве событий,
например, принимают факты начала проекта, окончания разработки
отдельных модулей, интерфейсов, выполнения отладки и т.п. Все события
нумеруются по порядку от исходного к завершающему. [33, с. 2]
В процессе достижения каждого события реализуется определенная
последовательность работ. Конечным событием является выполнение всего
проекта по разработке ПО. Каждой работе присваивается "Код работы",
состоящий из номера наступившего события и номера того события, которое
достигается в результате выполнения данной работы, например, если 0 -
начало проекта, а 1 -событие "разработка структуры данных завершена", то 0-
1 - определяет работу по разработке структуры данных. В качестве работы
может выступать и "фиктивная работа", которая определяет ожидание
окончания связанных работ и длительность которой равна 0 чел.-дней.
Кодовые номера работ каждого этапа указываются в соответствующем блоке
строк, относящегося к этому этапу. В таблице 7 представлены основные
события и работы проекта.
Таблица 7- Основные события и работы проекта
№
Событие
Код
работы
Работа
t
чел.-
часы
чел.-
дни
59
0
Начало работ
0-1
Анализ требований к
системе
8,4
1,05
1
Проанализированы
требования к системе
1-2
Проектирование
системной
архитектуры
16,4
2,05
2
Завершено проектирование
системной архитектуры
2-3
Разработка структуры
базы данных
14,4
1,8
3
Завершена разработка
структуры базы данных
3-4
Разработка
инфологической
модели
28,8
3,6
4
Завершена разработка
общего алгоритма работы
системы
4-5
Разработка алгоритма
обработки запросов
51,2
6,4
5
Завершена разработка
алгоритма обработки
запросов
5-6
Разработка программ
46,4
5,8
6
Завершена разработка
алгоритма работы системы
6-7
Разработка механизма
логического вывода
системы
65,6
8,2
7
Завершена разработка
механизма логического
вывода системы
Разработка
интерфейса
49,6
6,2
8
Завершена разработка
модуля, отвечающего за
взаимодействие с
пользователем
8-9
Общее тестирование
системы
25,6
3,2
8-9
Тестирование
выходных документов
25,6
3,2
8-9
Тестирование
интерфейса
пользователя
25,6
3,2
Продолжение таблицы 7
9
Завершено тестирование
системы
9-10
Разработка
руководства
пользователя
16,4
2,05
10
Завершена разработка
руководства пользователя
60
Графическое отображение сетевой модели. Графическое отображение
сетевой модели (сетевой график) содержит окружности, отображающие
основные события проекта, и векторы, соединяющие эти окружности и
определяющие необходимость выполнения соответствующих работ. Реальные
работы изображаются сплошной линией, фиктивные - штриховой, а работы,
лежащие на критическом пути - линией двойной толщины.
Окружности разделены на четыре сектора, в каждом из которых
показаны номер данного события (в нижнем секторе), значение раннего срока
наступления текущего события (в левом секторе), значение резерва времени
текущего события (в верхнем секторе) и значение позднего срока наступления
события (в правом секторе). [34, с. 10]
В соответствии с содержанием таблицы основных событий и работ
проекта строится графическая модель сетевого графика. На соответствующих
сегментах окружностей записываются номера событий, а на векторах -
продолжительность работ, показанных в столбце человеко-дни таблицы
основных событий и работ проекта (таблица 7).
После построения графической модели следует рассчитать оставшиеся
параметры элементов сети: сроки наступления событий, резервы времени,
полный и свободный резервы времени.
Обозначение основных элементов сетевого графика: N
i
, N
j
- номер
события, T
i
P
- ранний срок наступления события i, T
i
п
- поздний срок
наступления события i, R
i
- резерв времени события i, t
i,j
- продолжительность
работы i-j, R
ij
п
- полный резерв времени работы i-j, R
ij
c
- свободный резерв
времени работы i-j. [35, с. 2]
Ранний срок совершения события определяет минимальное время,
необходимое для выполнения всех работ, предшествующих данному событию
и равен продолжительности наибольшего из путей, ведущих от исходного
события (0) к рассматриваемому и рассчитывается по соотношению:
T
p
j
=max(T
p
j+
t
i-j
) (6)
61
Критический путь - максимальный путь от исходного события (0) до
завершения проекта. Его определение позволяет обратить внимание на
перечень событий, совокупность которых имеет нулевой резерв времени.
Все события в сети, не принадлежащие критическому пути, имеют
резерв времени R
i
, показывающий, на какой предельный срок можно
задержать наступление этого события, не увеличивая сроки окончания работ.
Поздний срок совершения события - максимально допустимое время
наступления данного события, при котором сохраняется возможность
соблюдения ранних сроков наступления последующих событий. Поздние
сроки вычисляются, начиная с последнего события - завершения проекта, по
критическому пути (т.е. справа налево по графику). Они равны разности
между поздним сроком совершения j-го события и продолжительностью i-j
работы. Поздний срок определяется соотношением:
T
n
i
= min (T
n
j –
t
i-j
) (7)
Резерв времени события определяется следующим образом:
R
i
=T
n
i -
T
p
i
(8)
Полный резерв времени работы определяется, используя соотношение
R
n
i-j
= T
n
j
- T
p
i
- t
i-j
(9)
Свободный резерв времени можно определить, применяя соотношение
R
c
i-j
= T
p
j
- T
p
i
- t
i-j
(10)
В результате исследования определяется критический путь на сетевом
графике - путь, имеющий наибольшую суммарную длительность работ. В
данной разработке критический путь проходит через вершины: 0-1-2-3-4-5-6-
7-8-9-10 и имеет длину T
кр
=91 рабочих дня.
Кроме достаточного условия того, является ли данный путь
критическим, существует также необходимое условие – критический путь
всегда проходит через события с нулевым резервом. Так как в
рассматриваемом графике существует только один путь, проходящий через
события с нулевым резервом, этот путь можно считать критическим без
дополнительного анализа достаточного условия. [40, с. 2]