Глава 2. Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Типичный жизненный цикл проекта состоит из четырех фаз - начальная фаза (концепция), фаза разработки, фаза реализации и фаза завершения.
Начальная фаза - посвящена разработке концепции проекта и включает в себя: сбор исходных данных и анализ существующего состояния (предварительное обследование), выявление потребности в изменениях (в проекте). Определение проекта:
цели, задачи и результаты применительно к задаче автоматизации подписных изданий
основные требования, ограничительные условия, критерии;
уровень риска;
окружение проекта, потенциальные участники;
требуемое время, ресурсы, средства и др.
На этом этапе происходит формулировка задачи автоматизации учета подписных изданий, построение и оценка альтернатив решения этой задачи, а также их экспертиза и утверждение концепции.
Фаза разработки проекта – в процессе которой разрабатываются основные компоненты проекта и осуществляется подготовка к его реализации. Основные работы этой фазы: назначение руководителя проекта и формирование команды проекта, в первую очередь ключевых членов команды: изучение целей, мотивации и требований заказчика и владельца проекта, а также других ключевых участников.
На этом же этапе осуществляется структурное планирование, в том числе декомпозиция проекта, верстаются календарные планы и укрупненные графики работ, смета и бюджет проекта, определяются потребности в ресурсах и методы контроля реализации проекта, осуществляется определение и распределение рисков. В процессе реализации этого этапа осуществляется организация и проведение торгов, заключение субконтрактов с основными исполнителями, организуется выполнение базовых проектных и опытно-конструкторских работ по проекту и осуществляется представление проектной разработки заказчику.
Применительно к рассматриваемой в дипломном проекте задаче автоматизации подписных изданий на этом этапе выбирается подходящая система документооборота и осуществляется ее приобретение.
Фаза реализации – в процессе которой осуществляется полный ввод в действие разработанной системы. На этом этапе происходит ввод в действие средств и способов коммуникации и связи участников проекта, ввод в действие системы стимулирования участников проекта, осуществляется детальное проектирование и определяются технические спецификации, производится оперативное планирование работ.
Применительно к рассматриваемой задаче автоматизации подписных изданий на этом этапе проводится обучение персонала, внедрение в технологию работы приобретаемой информационной системы.
Завершающая фаза или окончание проекта – в процессе которой достигаются конечные цели проекта и подводятся итоги. К основным работам этой фазы относятся - эксплутационные испытания окончательного продукта проекта, подготовка кадров для эксплуатации созданного объекта, подготовка документации, сдача объекта заказчику и ввод в эксплуатацию.
Жизненный цикл программного обеспечения
Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/TEC 12207 (ISO -International Organization of Standardization Международная организация по стандартизации, EEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.
Структура ЖЦ ПО по стандарту ISO/TEC 12207 базируется на трех группах процессов:
основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);
вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Разработка охватывает все работы по созданию ПО и его компонентов (анализ, проектирование и программирование) в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и качества программных продуктов, материалов, необходимых для организации обучения персонала, и т.д.
Эксплуатация включает в себя работы по внедрению компонентов ПО, в том числе конфигурирование базы данных и рабочих мест пользователей, обеспечение эксплуатационной документацией, проведение обучения персонала и т.д., и непосредственно эксплуатацию, в том числе локализацию проблем и устранение причин их возникновения, модификацию ПО в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы.
Модели жизненного цикла ПО
Стандарт ISO/TEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологии разработки. Стандарт ISO/TEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.
Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых система создается и функционирует. К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ: каскадная модель (1970 - 1985 гг.) и спиральная модель (1986 - 1990 гг.).
В изначально существовавших однородных ИС приложения представляли собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем.
Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Преимущества применения каскадного способа заключаются в следующем:
на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования с тем, чтобы предоставить разработчикам свободу реализовать их технически как можно лучше. В эту категорию попадают сложные расчетные системы, системы реального времени и др.
Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ, в которой делается упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Главная задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Для разрабатываемой ИС подходит спиральная модель жизненного цикла. Данная модель ЖЦ является основным для выбранного нами стандарта ISO/TEC 12207 и является более эффективным по сравнению с другими, что позволяет получить на выходе более качественный продукт при небольшом количестве задействованного персонала и относительно коротким графиком проектирования. Спиральная модель позволяет наращивать програмное обеспечение путем создания новых версий.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
При осуществлении любого проекта всегда возникает ситуация, связанная с неопределенностью, неполнотой или неточностью информации об условиях реализации проекта и связанных с ними затратах и результатах. Все участники проекта заинтересованы в том, чтобы исключить возможность провала проекта из-за таких неопределенных ситуаций. Для того чтобы снизить потери от возможных просчетов и избежать провала проекта в целом, методология управления проектами предусматривает специальные процедуры, помогающие учесть факторы неопределенности и риска на всех фазах и этапах проекта.
Зная виды и значимость рисков, можно на них воздействовать, снижая их отрицательное влияние на эффективность проекта. Следовательно, создается реальная возможность управлять ими. Факторы риска и неопределенности подлежат учету в расчетах эффективности, если при разных возможных условиях реализации затраты и результаты по проекту различны.
Этап подготовки проекта
Риск персонала
Риски:
Привлечение неопытного персонала к выполнению проекта.
Включение в состав разработчиков «случайных» сотрудников, а не ключевых участников автоматизируемых бизнес процессов
Отсутствие единой стратегии автоматизации
Отсутствие единой цели и задачи проекта
Отсутствие мотивации сотрудников
Негативное отношение персонала к проекту
Необдуманный план ведения работ
Способы предотвращения:
Активное взаимодействие с руководством в ходе проекта и своевременное принятие решений.
Участие в проекте ведущих специалистов и профессиональных консультантов
Четко сформулированные цели проекта
Проработка общей стратегии автоматизации организации
Стабильный состав рабочей группы в течение всего проекта
Риск ведения проекта
Риски:
Неверное определение рамок и масштаба проекта
Проектирование ошибочных функций системы
Выбор неправильных технологий и методов решений задач
Не соблюдение требования заказчика
Способы предотвращения:
Обеспечение стабильности границ проекта, которые определяются на начальном этапе и остаются неизменными вплоть до окончания проекта.
Качественное планирование выполняемых работ
Обеспечение проекта необходимыми ресурсами
Утверждение и согласование проектного решения
Установление высокого порога принятия изменений
Риск неверного планирования
Риски:
Неэффективный организационный план внедрения системы
Срыв сроков выполнения работ по этапам
Способы предотвращения:
На ранних стадиях проекта проведение аудита, организация командной работы, распределение ролей и стимулирование.
Документирование всех работ и обеспечение доступа к данным всем участникам проекта
Этап разработки
4. Риск персонала
Риски:
Увольнение ключевых сотрудников, ответственных за проведение разработки
Недопонимание между участниками проекта из-за отсутствия налаженной системы коммуникации
Неверное понимание задачи проектирования
Отбор программистов без опыта работы с подобными системами
Способы предотвращения:
Тщательный подбор сотрудников, участвующих в проекте
Налаженная система коммуникации между сотрудниками, постоянное документирование изменений системы
5. Технические риски
Риски:
Приостановка разработки из-за ошибок в используемом программном обеспечение.
Пользовательская документация охватывает не все функции системы
Способы предотвращения:
Использование только проверенного лицензионного ПО, проведение регулярного резервного копирования данных
Проверка документации на полноту сведений
Этап внедрения
6. Риск персонала
Риски:
Несогласованность действий разработчика и специалистов предметной области
Нежелание сотрудников работать с новой системой и связанные с этим трудности их обучения
Неучастие руководства в проекте
Способы предотвращения:
Обучения сотрудников заказчика работе с системой
Составление плана внедрения системы
Обоснование необходимости автоматизации персоналу
Вовлечение руководства в проект и активное взаимодействие с ним в ходе всего проекта.
7. Технические риски
Риски:
Потеря данных при внедрение системы
Способы предотвращения:
Привлечение квалифицированных сотрудников, имеющих опыт в подобных проектах
Этап эксплуатации и сопровождения
8. Технические риски
Риски:
Ошибки в программе, приводящие к невозможности ее использования
Некорректная эксплуатация оборудования
Несоответствие функционального набора системы из-за реорганизации компании.
Способы предотвращения:
Тщательное тестирование и модификации во время разработки системы
Документирование технических условий и их согласование
Применительно к внедряемой системе документооборота следует отметить следующие риски: нарушение конфиденциальности информации; нарушение целостности информации; нарушение доступности информации.
Таблица 2.1
Перечень рисков для данной операции и требования по ее защищенности.
Создание электронного документа
|
Угрозы
|
Требования
|
Методы нападения
|
Конфиденциальности
|
Целостности
|
Доступности
|
Преднамеренное искажение информации оператором при ее вводе
|
|
+
|
+
|
3
|
Случайное искажение информации оператором при ее вводе
|
|
+
|
+
|
4
|
Ввод оператором фиктивного документа
|
|
+
|
+
|
3
|
Несанкционированное уничтожение оператором подлинного документа.
|
|
+
|
+
|
3
|
Несанкционированное копирование информации при ее хранении в памяти ПЭВМ, на магнитных носителях (жесткий диск, дискеты).
|
+
|
|
|
3
|
Несанкционированный доступ к базе данных из внешней сети по каналу связи.
|
|
+
|
+
|
2
|
Несанкционированное изменение программного обеспечения.
|
+
|
+
|
+
|
3
|
Несанкционированное изменение аппаратных средств.
|
+
|
+
|
+
|
2
|
Несанкционированный доступ к базе данных (превышение полномочий оператором).
|
+
|
+
|
+
|
3
|
Хищение магнитных носителей.
|
+
|
+
|
+
|
3
|
Внедрение аппаратных и программных “закладок” и “скрытых каналов доступа”.
|
+
|
+
|
+
|
2
|
Съем конфиденциальной информации визуальным методом, например с экрана монитора или с оставленных без присмотра первичных бумажных документов.
|
+
|
|
|
2
|
Съем информации по электромагнитным каналам.
|
+
|
|
|
1
|
Съем информации по акустическим каналам.
|
+
|
|
|
1
|
Аппаратные сбои
|
+
|
+
|
+
|
4
|
Установка подслушивающих устройств
|
+
|
|
|
1
|
Перехват информации при ее передаче по соединительным линиям либо по общей шине ЛВС.
|
+
|
|
|
3
|
Градацию требований к защищенности документов, обрабатываемых в компьютерной системе в ходе выполнения различных операций: нет требований; низкие; средние; высокие.
1. Создание электронного документа:
ввод поручения в отделении почтамта;
работа с атрибутами счетов;
ввод внешних документов;
работа с информацией о денежных средствах;
работа с системными справочниками;
работа с журналами прав доступа;
В качестве объекта нападения в данном случае может выступать оператор рабочего места, обслуживающий персонал, рабочая станция (рабочее место), локальная сеть, база данных.
Воздействие на объекты, в соответствии с принятой моделью нарушителя, может быть непосредственным (несанкционированное чтение документа, кража носителя и т.п.) и опосредованным (например, из внешней сети с целью нарушения целостности создаваемого документа или внедрение программной закладки). Программная закладка может быть внедрена лицом из обслуживающего персонала.
Таблица 2.2
Перечень рисков при выполнении поручений
Выполнение поручений
|
Угрозы
|
Требования
|
Методы нападения
|
Конфиденциальности
|
Целостности
|
Доступности
|
Несанкционированный запуск поручения на исполнение
|
|
|
+
|
3
|
Преднамеренное искажение (изменение состояния) поручения
|
|
+
|
+
|
3
|
Случайное искажение (изменение состояния) поручения
|
|
+
|
+
|
4
|
Несанкционированное разглашение поручения
|
+
|
|
|
3
|
Несанкционированное копирование поручения
|
+
|
|
|
3
|
Выполнение поручений:
изменение состояния поручений (электронного документа);
формирование электронных документов в базах данных;
формирование бинарных файлов (их промежуточное хранение);
сцепка заявок;
В дополнении к выше приведенным угрозам отметим следующие риски (табл.2.3)
Исходящие электронные документы:
формирование текстов почтовых файлов;
передача сообщений объекту, учитывающему исходящую корреспонденцию (серверу приложений) и его отправка;
прямая передача сообщений между в одной локальной сети, или по выделенному телекоммуникационному каналу, обеспечивающему on-line соединение;
передача информации участнику на удаленный терминал
|
