47
II Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл разработки программного обеспечения является методом,
который охватывает все стандарты и процедуры, которые влияют на
планирование, сбор требований и анализ, проект развития, создания и внедрения
программного обеспечения системы. Для каждого проекта можно применять
отдельную модель жизненного цикла.
В данном случае итерационная модель является наиболее подходящей для
этого. Развитие системы предполагает возвращение к предыдущим этапам
проектирования системы.
Графическое представление итерационной модели ИС представлено на
рисунке 2.1.
Рисунок 2.1 – Графическое представление итерационной модели ИС
Итерационная модель хорошо зарекомендовала себя в построении
информационных систем, которые в начале развития точно и полно формулируют
все требования для того, чтобы дать разработчикам свободу реализовать их как
можно лучше с технической точки зрения.
Применение итерационного модели характерно для ситуаций, когда
48
требования и их реализация в максимально возможной степени четко определены
и понятны.
Преимущества итерационной модели:
Модель хорошо известна потребителям, не связанным с разработкой
программного обеспечения и конечным пользователям.
Аккуратность, чтобы справиться со сложностями и хорошо подходит
для проектов, которые достаточно ясны.
Она очень легко понятна.
Ее легко и удобно использовать, так как процесс развития
осуществляется поэтапно.
Ее структура может быть понятна даже плохо обученному в
техническом плане персоналу.
Стабильные требования.
Она хорошо работает, когда требования к качеству доминируют над
требованиями к стоимости и графику реализации проекта.
Способствует осуществлению строгого контроля в управлении
проектами.
Облегчает работу менеджера проектов по планированию и
завершению работ.
Итерационная модель функционирует хорошо, когда ее применяют в
циклах разработки программного обеспечения, которое использует непреложное
определение продукта и понятные технические приемы.
Выбор модели жизненного цикла разработки программного обеспечения
является важной вехой. Поэтому выбор модели жизненного цикла проекта
разработки программного обеспечения был основан на анализе требований
проекта, характеристики команды разработчиков и конечных пользователей, а
также на типе проекта и рисках. Данные представлены в Приложении А.
Путем подсчета количества ответов, которые были выделены, создана
таблица моделей жизненного цикла с общим баллом. По результатам выбирается
та модель жизненного цикла, у которой наибольший суммарный балл (таблица
2.1).
49
Таблица 2.1
Определение приемлемой модели ЖЦ
Модель ЖЦ
Вес в баллах
Каскадная модель ЖЦ
5
Итерационная модель ЖЦ
14
В данном случае суммарный балл итерационной модели ЖЦ наибольший.
Это означает, что для реализации проекта целесообразно применить
итерационную модель жизненного цикла программного обеспечения.
Она имеет следующие этапы:
определение требований;
спецификация требований;
проектирование;
реализация;
тестирование и отладка;
эксплуатация и сопровождение.
Цель этапа «Определение требований» - формирование требований к
информационной системе.
«Спецификация требований» - определение технических спецификаций.
Стадия делится на подстадии, задачи: определение функций ИС и стратегии
автоматизации, обоснование проектных решений по техническому, информации
и программного обеспечения. Основная информация - эта документация по
техническому заданию.
Цель этапа «Проектирование» - разработка проекта автоматизации и
разработка задач информационной поддержки. Разработка проекта
автоматизации включает в себя разработку схемы, архитектуры проекта, анализ
рисков и оценку стоимости проекта. Разработка информационной поддержки
задачи включает в себя разработку информационной модели, классификаторов и
прототипы экранов. Эффективная информация - это проектная документация.
Цель этапа «Реализация» - разработка программного обеспечения. Этап
включает в себя подготовку к разработке программного обеспечения и разработку
программного обеспечения. Эффективная информация - это документация
50
программного обеспечения.
Цель этапа «Тестирование и отладка» включает в себя установку
элементов ИС и технической поддержки, а также тестирование и устранение
выявленных ошибок.
Цель этапа «Эксплуатация и обслуживание» - мониторинг и
обслуживание программных и аппаратных средств, а также работа с
пользователями.
Есть несколько способов начать использовать новую систему:
1) параллельная стратегия - для случая, когда старую информационную
систему необходимо заменить на новую. В то же время, старая (ручная) и новая
система работают, и их выходные документы сравниваются. Если они совпадают
длительное время, можно перейти на новую систему. Проблема заключается в
том, что большинство предприятий, внедряющих ИС, заменяют программное
обеспечение неавтоматизированным вариантом, а не частью другого
программного обеспечения;
2) «скачок». Эта стратегия привлекательна, но рискованная. «Скачок»
означает, что в пятницу мы работали в старой системе, и в понедельник мы начали
работать в новой системе. Некоторые считают, что эта позиция заставляет всех
«тонуть и плавать» в понедельник. Но на самом деле все может утонуть.
3) «пилотный проект» является тактикой «прыжка», но применяется к
ограниченному числу программных продуктов. Масштабы стратегии - небольшая
область деятельности. Такой подход является наиболее надежным, он снижает
риск, и сегодня почти все фирмы применяют эту тактику.
4) «узкое место» является наиболее важной малой частью
производственного процесса. При внедрении узкого места план реализации
реализуется только для узких мест и для работающих в нем людей. Точность
данных увеличивается только для продуктов в этом «узком месте»;
Переподготовка - только для работающих в нем людей. Анализ затрат-эффектов
производится только для него и т. д.
Благодаря стратегии «узких мест» объем работ значительно сокращается,
51
и с учетом имеющихся ресурсов узкое место может быть выполнено на всей
фирме. Свойство этой стратегии - сосредоточение внимания на «узком месте» в
производственном процессе. Группа из 10-12 человек может сосредоточиться на
внедрении новой системы в одном сегменте бизнеса.
«Узкое место» служит полигоном для дальнейшей работы. Это может
быть успешным примером. Опыт показывает, что во многих случаях можно
«расширить узкое место» в течение 3-5 месяцев и быстро достичь намеченных
результатов.
Поэтому поскольку автоматизируется учет деятельности только
монтажных бригад, можно выбрать стратегию внедрения «узкое место».
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание.
Современные информационные системы являются достаточно сложными
и комплексными решениями и их реализация, как правило, требует значительных
затрат со стороны предприятия. IT-система - это набор программных и
аппаратных средств, которые используются для анализа, хранения и обработки
данных. Инструменты анализа, которые включены в ИТ-системы, позволяют
выполнять высокоскоростную обработку огромных объемов данных, и на основе
этих результатов предполагают корректирующие действия в соответствии с
ситуацией.
Перечислим некоторые типичные причины рисков в реализации ИТ-
проектов [19]:
Недоступность топ-менеджмента к изменениям бизнес-процессов и
организационной структуры.
Незаинтересованность руководителей основных департаментов и их
непосредственных подчиненных.
Изменение в ходе проекта.
Отсутствие квалифицированного менеджера проекта и ответственных
исполнителей.
Отсутствие четких и точных методологических основ этого процесса.
Исходя из этих факторов, проект по управлению рисками для внедрения
информационных технологий (ИТ-проектов) должен заранее определить все
52
возможные риски и проводить комплексные профилактические меры, с тем,
чтобы избежать серьезных проблем в ходе реализации проекта.
Проекты в конкретных предметных областях, таких как ИТ или проекты,
осуществляемые с использованием узкоспециализированных технологических
процессов для вертикальных рынков (таких как здравоохранение, высшее
образование, государственные структуры, банковские услуги и пр.), а также
проекты с конкретными конечными продуктами могут содержать риски,
уникальные для этой области. Например, в области банковской деятельности,
существуют риски, связанные с кражей, потерей или искажением информации в
результате злоумышленных действий или случайного события. При работе над
проектами в области классификации полезно расширить существующие риски
общего назначения.
Выбор классификации риска зависит от ИТ-проекта и предпочтений
профессионального менеджера проекта. В целом, риски любого проекта можно
классифицировать следующим образом:
Технические риски. Практически, есть риски для любого проекта
связанные с оборудованием (неисправности и сбои в работе оборудования,
ошибки в установке, и т.д.).
Риска расчета времени выполнения проекта. Для большинства ИТ-
проектов (особенно в проектах по разработке и внедрению программного
обеспечения) являются типичными ошибки в сроках оценки проектных работ.
Интеграционные риски. Интеграционные риски в ИТ-проектах, особенно
в крупных компаниях, всегда высоки, потому что любое ИТ-решение должно
быть интегрировано в существующую инфраструктуру. Наиболее характерны для
переходных рисков для новой системы те, которые включают в себя стоимость
проекта реализации ИТ-решений, обучение персонала и т.д.
Риски не принятия пользователем проекта продукта. Любой проект, в том
числе в области ИТ - это, в первую очередь, технология смены работы.
Техническая составляющая любого проекта, безусловно, важна, но не менее
важной частью является организация работы.
Коммерческие риски. Это риски, связанные с выбором технологий и
53
поставщиков. Необходимо оценить успех технологии на рынке, ее актуальность
на протяжении всего жизненного цикла ИТ-проекта, наличие необходимого
оборудования и программного обеспечения, его качество, уровень модернизации.
Риски несоблюдения технологии. Эти риски возникают, если
руководитель проекта имеет исключительное право на решение задач рисков
(идентификация, анализ, метод выбора ответа). Чем больше и сложнее проект, тем
выше риск.
Говоря о реализации проектов в области ИТ, следует отметить, что любая
новая технология, реализованная в условиях высокой неопределенности и
негативного воздействия на окружающую среду, имеет свои риски. Это связано с
тем, что реализация большинства ИТ-проектов, особенно крупных, происходит в
среде, где трудно применять стандартные методы управления. Уникальность
проекта и отсутствие такой практики в компании создает неопределенность по
поводу выбора новых технологий, методов идентификации и средства для
достижения этой цели, принятие методологии.
Управление рисками в современных организациях является тщательно
спланированным процессом. Процесс управления рисками не рассматривается
как свободно стоящая проблема, которая должна быть решена, но как часть
изменений в общей системе корпоративного управления. Цель управления
рисками, в конечном счете, заключается в повышении эффективности бизнеса
путем контроля за деятельностью компании и получения максимальной отдачи от
используемой методологии.
Управление рисками ИТ-проектов - определение, оценка и мониторинг
воздействия, внутренние и внешние факторы, которые могут негативно повлиять
на цену и процесс внедрения новых информационных технологий в компании.
Анализ исследований в области риска ИТ-проектов для удовлетворения
требований современной экономики управления позволяет нам определить
основные принципы управления:
Разбить крупные проекты на более мелкие (принцип «Дельфины вместо
кита»). И должен быть один человек (как правило, директор программы), который
одновременно управляет всеми проектами и ищет пути успеха и реализации
54
общего решения.
Привлечение специалистов по управлению проектами, а не доверять это
узким и техническим специалистам. Эти эксперты видят проект в первую очередь
с его технической точки зрения и забывают о других компонентах управления.
Привлекать независимых (не включенных в состав команды проекта)
экспертов для оценки рисков. Если все решения о рисках проекта будут
принимать только люди, которые изначально мотивированы на успех проекта,
многие из технических и технологических трудностей они могут невольно
рассматривать как несущественные.
Рассмотрим риски, связанные с организационной составляющей проекта.
Для успешной реализации проекта требует большое количество согласований и
формальностей. Систему организации и записи совещаний в рамках проекта
следует рассмотреть в деталях, согласование документов, принятие результатов,
обучение пользователей и т.д.
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Программа должна работать без прерываний при возникновении
критических ошибок, даже тех, которые возникают по вине пользователя или из-
за ошибок во входных данных. В случае возникновения ошибки после выдачи
соответствующего предупреждения программа должна продолжить свою работу.
Программа должна обеспечить физическую и логическую целостность базы
данных. При изменении или удалении данных программа должна поддерживать
ссылочную целостность информации в базе данных.
Программист должен выполнять следующие задачи:
˗ задача поддержания работоспособности технических средств;
˗ задача поддержания работоспособности системных программных
средств - операционной системы и драйверов;
˗ задача поддержания работоспособности программы ИС.
55
Информационная
система
СоставЗаказа
Поставщику
Заказы
Поставщику
МатЦенности
Работы
ПоЗаказу
МатЦенности
ПоЗаказу
Статусы
Работники
Менеджеры
Заказы
Специализации
Реквизиты
Прейскурант
Клиенты
Менеджер
Ведение
справочников
Обработка
заказов
клиентов
Формирование
отчетов
МатЦенности*
Статусы*
Работники*
Менеджеры*
Специализации* Реквизиты*Прейскурант*
Клиенты*
Бланк заказа
Акт
выполненных
работ
Счет Счет-фактурв
Менеджер
Рисунок 2.2 – Информационная модель системы
2.2.2 Характеристика нормативно-справочной, входной и оперативной
информации
В процессе функционирования АИС должны использоваться документы
утвержденной формы, классификаторы, используемые в товароведении. Также
должны использоваться программные и технические средства с учетом удобства
56
их применения в рамках АИС.
При автоматизированной обработке учетной информации широко
используются различные классификаторы, которые позволяют улучшить
организацию и качество бухгалтерского учета.
Классификаторы построены на определенной системе кодирования.
Маркировка позиции классификатора производится с помощью условной
характеристики - кода. Системы кодирования - буквенные и числовые и буквенно-
цифровые (для автоматизации учета работы наиболее целесообразно
использовать цифровую). На практике, наиболее широко используется система
кодирования следующим образом: порядковая, последовательная, десятичная,
шахматная и комбинированные.
Порядковая используется для малопозиционных стабильных номенклатур
(должностям назначены серийные номера). В такой системе, код присваивается
категории сотрудников, складов и т.д. Недостатком здесь является то, что
добавление новых позиций номенклатуры приводит к нарушению
первоначального набора кодов классификации. Кроме того, при удалении
некоторых продуктов нарушается порядок шифров.
Непрерывная обеспечивает шифрование отдельных элементов в пределах
числового ряда, выделенных для различных групп (продукции), номера
зарезервированы для расширения номенклатуры. Ее, например, можно
использовать для создания кодовых имен (серии номеров, выделенных каждому
магазину), типы платежей и отчислений (одна серия номеров для платежей и
вторая - для проводок).
Система непрерывной классификации до недавнего времени был одной из
самых популярных, благодаря своей эффективности и легкости. Ряд чисел, как
правило, должен заканчиваться цифрой 9 (для лучшего запоминания). К
недостаткам можно отнести сложность хранения шифр шифрования
многопризначных номенклатур, что также значительно расширяет серию
свободных номеров.
Десятичная (позиционная) система кодирования используется, если
необходимо, чтобы зашифровать несколько признаков номенклатуры. Тогда