58
2.2 Разработка проекта автоматизации
2.2.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл разработки программного обеспечения - это метод,
который охватывает все стандарты и процедуры, что влияют на
планирование, сбор и анализ требований, разработку проектов, создание и
внедрение программных систем.
Рассмотрим каскадную модель жизненного цикла разработки ПО. Его
основной характеристикой является расщепление всей разработки на этапы, а
переход от одного этапа к другому происходит только после завершения
работы над текущим (рис. 9).
Рисунок 9. Графическое представление каскадной модели
жизненного цикла разработки ПО
Каждый этап заканчивается разработкой полного комплекта
документации.
Положительные аспекты применения каскадной модели заключаются в
следующем:
1. На каждом этапе формируется полный комплект проектных
документов, который соответствует критериям полноты и
последовательности;
2. Этапы работы выполняются в логической последовательности.
Каскадный подход позволяет сформулировать все требования точно и
59
полностью, чтобы дать разработчикам свободу выбора. Эта категория
включает в себя сложные системы расчета, системы реального времени и
другие подобные задачи. Однако в процессе использования этого подхода
имеется ряд недостатков, вызванный тем, что реальный процесс создания
программного обеспечения несовместим с такой жесткой схемой полностью.
Основным недостатком каскадного подхода является значительная
задержка с получением результатов. Результаты согласовываются с
пользователями только в точках, планирование которых происходит после
завершения каждого этапа работы, требования к программному обеспечению
«заморожены» в виде технического задания в течение всего времени его
создания. Таким образом, пользователи могут делать свои комментарии
только после завершения работы над системой. В случае неточного
представления требований или их изменений в течение длительного периода
разработки программного обеспечения пользователи получают систему,
которая не отвечает их потребностям. Модели (как функциональные, так и
информационные) автоматизированного объекта могут быть устаревшими
одновременно с их утверждением.
В процессе создания ПО постоянно возникает потребность в возврате к
предыдущим этапам и уточнении или пересмотре ранее принятых решений.
В данном случае итерационная модель является наиболее подходящей
для этого. Развитие системы предполагает возвращение к предыдущим
этапам проектирования системы.
Итерационная модель разработки ПО представлена на рисунке 10.
60
Рисунок 10. Графическое представление итерационной модели
жизненного цикла разработки ПО
Итерационную модель применяют в ситуациях, когда требования к ПО
и их реализация очень четко определены и понятны.
Преимущества итерационной модели:
1. Модель хорошо известна потребителям, не связанным с разработкой
программного обеспечения и конечным пользователям.
2. Аккуратность, чтобы справиться со сложностями и хорошо подходит
для проектов, которые достаточно ясны.
3. Она очень легко понятна.
4. Ее легко и удобно использовать, так как процесс развития
осуществляется поэтапно.
5. Ее структура может быть понятна даже плохо обученному в
техническом плане персоналу.
6. Стабильные требования.
7. Она хорошо работает, когда требования к качеству доминируют над
требованиями к стоимости и графику реализации проекта.
8. Способствует осуществлению строгого контроля в управлении
проектами.
9. Облегчает работу менеджера проектов по планированию и
завершению работ.
Итерационная модель функционирует хорошо, когда ее применяют в
циклах разработки программного обеспечения, которое использует
непреложное определение продукта и понятные технические приемы.
Выбор модели жизненного цикла разработки программного
обеспечения является важной вехой. Поэтому выбор модели жизненного
цикла проекта разработки программного обеспечения основывается на
анализе всех требований проекта, характеристике команды разработчиков и
конечных пользователей, а также на типе проекта и рисках.
После подсчета количества ответов, которые были учтены, создана
таблица моделей жизненного цикла с общим баллом (Приложение 1). По
результатам выбрана та модель жизненного цикла, у которой наибольший
суммарный балл (таблица 9).
61
Таблица 10
Определение приемлемой модели ЖЦ
Модель ЖЦ
Вес в баллах
Каскадная модель ЖЦ
5
Итерационная модель ЖЦ
14
В данном случае суммарный балл итерационной модели ЖЦ
наибольший. Таким образом, при реализации проекта разработки ПО
необходимо применить итерационную модель жизненного цикла
программного обеспечения.
Итерационная модель хорошо зарекомендовала себя в построении
информационных систем, которые в начале развития точно и полно
формулируют все требования для того, чтобы дать разработчикам свободу
реализовать их как можно лучше с технической точки зрения.
Она имеет следующие этапы:
1. Определение требований;
2. Спецификация требований;
3. Проектирование;
4. Реализация;
5. Тестирование и отладка;
6. Эксплуатация и сопровождение.
Цель этапа «Определение требований» - формирование требований к
информационной системе.
«Спецификация требований» - определение технических
спецификаций. Стадия делится на подстадии, задачи: определение функций
ИС и стратегии автоматизации, обоснование проектных решений по
техническому, информации и программного обеспечения. Основная
информация - эта документация по техническому заданию.
Цель этапа «Проектирование» - разработка проекта автоматизации и
разработка задач информационной поддержки. Разработка проекта
автоматизации включает в себя разработку схемы, архитектуры проекта,
анализ рисков и оценку стоимости проекта. Разработка информационной
поддержки задачи включает в себя разработку информационной модели,
классификаторов и прототипы экранов. Эффективная информация - это
проектная документация.
Цель этапа «Реализация» - разработка программного обеспечения. Этап
включает в себя подготовку к разработке программного обеспечения и
62
разработку программного обеспечения. Эффективная информация - это
документация программного обеспечения.
Цель этапа «Тестирование и отладка» включает в себя установку
элементов ИС и технической поддержки, а также тестирование и устранение
выявленных ошибок.
Цель этапа «Эксплуатация и обслуживание» - мониторинг и
обслуживание программных и аппаратных средств, а также работа с
пользователями.
В данном случае итерационная модель является наиболее подходящей
для этого. Развитие системы предполагает возвращение к предыдущим
этапам проектирования системы.
Современные информационные системы являются достаточно
сложными и комплексными решениями и их реализация, как правило,
требует значительных затрат со стороны предприятия. Перечислим
некоторые типичные причины рисков в реализации ИТ-проектов:
1.Недоступность топ-менеджмента к изменениям бизнес-процессов и
организационной структуры.
2.Незаинтересованность руководителей основных департаментов и их
непосредственных подчиненных.
3.Изменение в ходе проекта.
4.Отсутствие квалифицированного менеджера проекта и ответственных
исполнителей.
5.Отсутствие четких и точных методологических основ этого процесса.
Исходя из этих факторов, проект по управлению рисками для
внедрения информационных технологий (ИТ-проектов) должен заранее
определить все возможные риски и проводить комплексные
профилактические меры, с тем, чтобы избежать серьезных проблем в ходе
реализации проекта.
Управление рисками в современных организациях является тщательно
спланированным процессом. Процесс управления рисками не
рассматривается как свободно стоящая проблема, которая должна быть
решена, но как часть изменений в общей системе корпоративного
управления.
Управление рисками ИТ-проектов - определение, оценка и мониторинг
воздействия, внутренние и внешние факторы, которые могут негативно
повлиять на цену и процесс внедрения новых информационных технологий в
63
компании. Анализ исследований в области риска ИТ-проектов для
удовлетворения требований современной экономики управления позволяет
нам определить основные принципы управления:
1. Разбить крупные проекты на более мелкие (принцип «Дельфины
вместо кита»). И должен быть один человек (как правило, директор
программы), который одновременно управляет всеми проектами и ищет пути
успеха и реализации общего решения.
2. Привлечение специалистов по управлению проектами, а не доверять
это узким и техническим специалистам. Эти эксперты видят проект в первую
очередь с его технической точки зрения и забывают о других компонентах
управления.
3. Привлекать независимых (не включенных в состав команды проекта)
экспертов для оценки рисков. Если все решения о рисках проекта будут
принимать только люди, которые изначально мотивированы на успех
проекта, многие из технических и технологических трудностей они могут
невольно рассматривать как несущественные.
Рассмотрим риски, связанные с организационной составляющей
проекта.
Таблица 11
Факторы риска
Тип
(категория
риска)
Риск
Последствия
Меры по
предотвращению
Вероятность
свершения
риска
Экономический
Повышение
стоимости
продукции
Снижение
уровня
доходности от
работы
магазина или
увеличение
стоимости
товара для
покупателей,
что снижает
объемы продаж
Заключение
длительного
договора с
поставщиками,
постоянный
мониторинг рынка,
наем на условиях
аутсорсинга
профессиональног
о специалиста по
рекламе
11-20%
Экономический
Активация и
демпинг
прямых
конкурентов
Неравномерное
распределение
покупателей
между
аналогичным
товаром,
снижение
доходности
Разработка
уникального
торгового
предложения,
постоянное
качество,
дополнительные
акции и
инновационные
технологии
6%
64
Тип
(категория
риска)
Риск
Последствия
Меры по
предотвращению
Вероятность
свершения
риска
Технологическ
ий
Слабый
интерфейс
приложения и
ограниченная
функциональн
ость
Снижение
доходности и
недополученна
я прибыль от
медленной
обработки
заказов
Разработка
приложения для
обработки заказов
клиентов и
поставки от
поставщиков
продукции
8%
Для успешной реализации проекта требует большое количество
согласований и формальностей. Систему организации и записи совещаний в
рамках проекта следует рассмотреть в деталях, согласование документов,
принятие результатов, обучение пользователей и т.д.
2.2.2 Характеристика нормативно-справочной, входной и
оперативной информации
В процессе функционирования ИС должны использоваться документы
утвержденной формы, классификаторы, используемые в сфере
предоставления услуг. Также должны использоваться программные и
технические средства с учетом удобства их применения в рамках ИС.
К нормативно-справочной информации, использующейся при работе
информационной системы, относятся:
1. Законодательство РФ;
2. Справочник «Каталог услуг»;
3. Информация о клиенте.
Входная информация заносится в справочники и таблицы оперативного
учета на основании входных документов
Входная информация разделяется на условно-постоянную и
оперативно-учетную информацию. Условно-постоянная информация
включает в себя справочные данные о услуге, а также об авторизации.
Оперативно-учетная информация содержит в себе данные оперативного
учета, включает в себя данные об услугах, клиентах и отзывах клиентов.
Реквизитный состав приведен в таблицах 12-15.
65
Таблица 12
Клиент
Заголовок поля
Идентификатор поля
Ключ
Тип поля
Длина
1
Код клиента
Код_Клиента
+
Числовой
11
2
Клиент
Имя_Клиента
Текстовый
255
3
Счет клиента
Счет
Текстовый
255
Таблица 13
Реализация
Заголовок поля
Идентификатор поля
Ключ
Тип поля
Длина
1
№ карты
№_Карты
Числовой
11
2
Шифр услуги
Шифр
+
Числовой
11
3
Код клиента
Клиент
+
Числовой
11
4
Дата реализации
Дата_Реализации
Дата/Время
Таблица 14
Отзыв клиента
Заголовок поля
Идентификатор
поля
Ключ
Тип поля
Длина
1
Шифр_отзыва
Шифр_Отзыва
Числовой
11
2
Код клиента
Клиент
+
Числовой
11
3
Отзыв об услуге
Отзыв
Текстовый
255
Таблица 15
Услуга
Заголовок поля
Идентификатор
поля
Ключ
Тип поля
Длина
1
Шифр_услуги
Шифр_Услуги
Числовой
11
2
Код услуги
Услуга
+
Числовой
11
3
Стоимость услуги
Стоимость
Числовой
11
2.2.3 Характеристика результатной информации
Оперируя соответствующей информацией из справочников и таблиц, с
помощью ИС можно сформировать необходимые выходные документы.
Выходные документы представлены в таблицах 16,17.
Таблица 16
Отчет о клиенте
Код
клие
нта
Фамилия
Имя
Отчество
Номер
телефо
на
Почта
Номер счета
1
Иванов
Иван
Иванович
8-915-
123-32-
43
IvanovIva@
mail.ru
6000
6512
4154
0000
2
Петров
Петр
Петрович
8-916-
453-90-
64
PetrovPetr@
mail.ru
3222
1612
0606
1234
66
3
Семенов
Семен
Семенович
8-909-
783-39-
56
SemenovSe
men@
mail.ru
8877
1612
8745
0112
Таблица 17
Отчет о реализации
Номер
карты
Код клиента
Шифр услуги
Дата реализации
1
1
111
24.11.2018
2
2
111
26.11.2018
1
1
125
24.11.2018
Документы формируются как результаты запросов к базе данных по
различным критериям.
Отчеты могут просматриваться средствами информационной системы
и выводиться во внешнее приложение.
На всех документах обязательно должна быть подпись руководителя
организации или его заместителя. Все напечатанные документы
предоставляются в 2-х экземплярах – менеджеру по работе с клиентами и в
бухгалтерию.
67
2.3 Программное обеспечение задачи
2.3.1 Общие положения (дерево функций и сценарий диалога)
Целевая функция - это работа информационной системы. Основные
функции отражают ориентацию системы и представляют собой набор
макрофункций, реализованных системой. Основные функции - обеспечивают
условия для выполнения целевой функции (прием, передача, хранение,
доставка).
На рисунке 15 представлено дерево функций ИС.
Рисунок 15. Дерево функций