56
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл системы понимается как непрерывный процесс, который
начинается с момента принятия решения о необходимости создания системы и
заканчивается в момент ее полного завершения эксплуатации.
Продолжительность ЖЦ для ИС нашего времени сильно превышает
временные рамки и составляет около 10 лет. Это не является хорошим сроком
для морального и физического старения технического и системного ПО, которое
используют при построении системы. Поэтому в процессе жизненного цикла
системы модернизируется ее техническая и программная база. В этом случае
прикладное программное обеспечение системы следует хранить и передавать на
обновленную аппаратную и программную платформы.
Методология проектирования информационных систем описывает
процесс создания и поддержания систем в виде жизненного цикла (ЖЦ)
информационной системы, представляет ее как определенную
последовательность этапов и процессов, осуществляемых на них. Для каждой
стадии определяются состав и последовательность выполненных работ,
полученные результаты, методы и средства, необходимые для выполнения
работы, роли и обязанности участников и тому подобное. Такое формальное
описание жизненного цикла ИС позволяет планировать и организовывать
процесс коллективного развития и обеспечивать управление этим процессом.
Жизненный цикл ИС можно представить в виде серии событий,
происходящих с системой в процессе ее создания и использования.
Модель жизненного цикла отражает различные состояния системы,
начиная с момента, когда возникает необходимость для данной ИС, и заканчивая
моментом, когда она полностью вышла из употребления. Модель жизненного
цикла - это структура, содержащая процессы, действия и задачи, которые
выполняются при разработке, эксплуатации и обслуживании программного
продукта в течение всей жизни системы, от определения требований до
завершения его использования.
57
В настоящее время известны и используются следующие модели
жизненного цикла:
• Каскадная модель предполагает последовательное выполнение всех
этапов проекта в строго фиксированном порядке. Переход к следующему этапу
означает полное завершение работы на предыдущем этапе.
• Поэтапная модель с промежуточным контролем. Развитие ИС
проводится итерациями с циклами обратной связи между этапами.
Корректировки между этапами позволяют учитывать фактически существующее
взаимное влияние результатов развития на разных этапах, время жизни каждого
из этапов растягивается на весь период развития.
• Спиральная модель. На каждом витке спирали создается следующая
версия продукта, определяются требования проекта, определяется его качество,
планируется следующий виток. Особое внимание уделяется начальным этапам
разработки - анализ и проектирование, где целесообразность различных
технических решений проверяется и обосновывается средствами
прототипирования.
Каскадный подход зарекомендовал себя в построении относительно
простых интегральных схем, когда в самом начале разработки все требования к
системе можно точно и полностью сформулировать. Главным недостатком этого
подхода является то, что фактический процесс создания системы никогда
полностью не вписывается в такую жесткую схему; всегда существует
потребность вернуться на предыдущие этапы и уточнить или пересмотреть ранее
принятые решения. В результате реальный процесс создания ИС является
соответствующей фазовой моделью с промежуточным контролем. Однако эти
недостатки не могут быть решающими в разработке необходимой системы
резервирования и учета клиентов библиотеки, поэтому мы ее выбираем.
Каждый из этапов создания системы предусматривает выполнение
определенного объема работ, которые представлены в виде процессов
жизненного цикла. Процесс определяется как набор взаимосвязанных действий,
которые превращают входные данные в выходные данные. Описание каждого
процесса включает список задач, исходных данных и результатов.
58
Существует ряд стандартов, регулирующих жизненный цикл
программного обеспечения, а в некоторых случаях и процессы развития.
Среди наиболее известных стандартов следующие:
• ГОСТ 34.601-90 - применяется к автоматизированным системам и
устанавливает этапы их создания. Кроме того, данный стандарт содержит
описание содержания работы на каждом этапе. Этапы работы, закрепленные в
стандарте, в большей степени соответствуют каскадной модели жизненного
цикла.
• ISO / IEC 12207: 1995 - стандарт для процессов и организации
жизненного цикла. Применяется для всех типов специального программного
обеспечения. Стандарт не содержит описаний фаз, стадий и этапов.
• CustomDevelopmentMethod (методология Oracle) для разработки
прикладных информационных систем - технологических материалов,
детализированных до уровня проектных документов заготовок,
предназначенных для использования в проектах с использованием Oracle. CDM
используется для классической модели жизненного цикла (все работы / задачи и
шаги предусмотрены), а также для технологий «быстрого развития» (FastTrack)
или «легкого подхода», рекомендованных для малых проектов.
• RationalUnified Process (RUP) предлагает итеративную модель развития,
которая включает четыре этапа: начало, исследование, построение и внедрение.
Каждую фазу можно разделить на этапы (итерации), в результате которых
выпускается версия для внутреннего или внешнего использования. Переход
через четыре основные фазы называется циклом разработки, каждый цикл
заканчивается генерацией версии системы. Суть работы в рамках RUP состоит в
создании и обслуживании моделей на базе UML.
• Microsoft SolutionFramework (MSF) похож на RUP, также включает в
себя четыре этапа: анализ, проектирование, разработка, стабилизация, является
итерационным, предусматривает использование объектно-ориентированного
моделирования. MSF по сравнению с RUP больше ориентирована на разработку
бизнес-приложений.
59
• ExtremeProgramming (XP). Экстремальное программирование (новое
среди рассмотренных методологий) был сформирован в 1996 году. Методология
базируется на коллективной работе, эффективной коммуникации между
заказчиком и подрядчиком в течение всего проекта по развитию ИС, а
разработка осуществляется с помощью последовательно разработанного
прототипа.
• Стандарт ISO / IEC 15288
Благодаря малому объему разработанной автоматизированной системы, ее
назначению, характера, необходимо использовать этот стандарт. Для созданной
системы, перечень стадий, участников этапов, требований к входной
информации и основных результатов, которые должны быть достигнуты до
момента их завершения, приведены в таблице 2.1.
60
Таблица 0.1
Стадии создания автоматизированной системы (в соответствии с ISO/IEC 15288)
№
п/п
Стадия
Ключевые участники
Требования к входной
информации
Результаты
1
Формирование
концепции
Разработчик, начальник
отдела ИТ, программист
Описание бизнес—процессов
организации, форм входных и
выходных документов, общие
требования к системе
Анализ потребностей,
выбор концепции и
проектных решений
2
Разработка
Начальник отдела ИТ,
разработчик, программист
Требуемые функции системы
Проект системы
3
Реализация
программист
Проект системы, требования к
программному, информационному и
техническому обеспечению
Готовая информационная
система, комплект
документации
4
Эксплуатация
Администратор
системы, пользователи
Руководство администратора и
пользователя системы
Ввод в эксплуатацию и
использование системы
5
Поддержка
Администратор
системы, разработчик
Статистика отказов, ошибок в
работе информационной системы
Обеспечение
функционирования системы
6
Снятие с
эксплуатации
Начальник отдела ИТ
Обоснование прекращения
использования системы
Прекращение
использования, демонтаж,
архивирование системы
61
Задача внедрения информационной системы заключается в создании
(адаптации) и запуске в продуктивной работы элементов информационной
системы. Поскольку разработка информационной системы будет осуществляться
сама по себе, то реализация будет происходить без привлечения внешних
специалистов.
Фаза внедрения планируется разделить на следующие подэтапы:
1. Предпроектное обследование. Обследование определяет основные
информационные потоки на предприятии и проверяет основу основной
нормативно-справочной документации. Основным требованием в этом случае
является наличие всех каталогов и классификаторов, необходимых для
функционирования корпоративных информационных систем и соответствие
принципов их организации требованиям системы. Во время этапа внедрения
корпоративные стандарты бухгалтерского учета необходимо анализировать на
предмет их полноты. На этом этапе также диагностируются проблемы, которые
могут возникнуть при внедрении; разработка и согласование создания
системных справочников и классификаторов в соответствии со
сформулированными требованиями. При необходимости принимаются решения
об изменении существующих методов учета или функциональных моделей.
Согласно результатам этапа, документ подписывают все участники проекта
внедрения, в котором описываются все выявленные проблемы и определяются
пути их устранения.
2. Построение информационно-функциональной модели предприятия,
описание и оптимизация процессов, проходящих автоматизацию.
Моделирование должно осуществляться хорошо подготовленными работниками
данного предприятия с привлечением высококвалифицированных консультантов
и со ссылкой на созданную модель для бизнес-стандартов и будущей системы.
3. Адаптация ИС на предприятии. На этапе система настроена для
тестирования отдельных модулей и функций командой внедрения. На этом этапе
очень важно также наличие корпоративных стандартов, поскольку они являются
основой системных настроек.
62
4. Пробное функционирования информационной системы. Проводится
проверка полного соответствия функциональности, полученной в результате
настройки системы, требованиям предприятия. На этом этапе поддерживается
двойной ввод данных в старые и новые системы. Во время пробной
эксплуатации: генерируются стандартные отчеты (с помощью IP и обычных
методов), данные проверяются; система постепенно вводится в эксплуатацию,
для отдельных разделов счета; задокументированы инструкции по содержанию
рабочих мест и скорректированы должностные инструкции участников процесса
учета. В отдельных подразделениях предприятия фактические данные вводятся в
систему (в ограниченном объеме), а бизнес-функции постоянно проверяются
путем моделирования реальных ситуаций деятельности предприятия (в
условиях, максимально приближенных к реальности). На основе тестовых
экспериментальных примеров разрабатывается совместная работа
подразделений. Конечные пользователи (ИТ-персонал) учатся работать с
настроенной системой непосредственно на своих рабочих местах. После
обучения конечных пользователей разрабатывается интегрированный
экспериментальный пример и полностью моделируется деятельность
предприятия. На основе результатов экспериментального примера руководство
предприятия принимает решение о передаче ИС в коммерческую эксплуатацию.
Фаза операции предусматривает непосредственное использование
информационной системы для выполнения функций, для которых она
предназначена.
Работы, ожидаемые на стадии эксплуатации, можно разделить на две
группы: плановые и неплановые.
Плановые работы будут включать такие работы, как:
• установка программного обеспечения;
• базовую конфигурацию и проверку производительности компонентов
установленной системы;
• устранение недостатков в конфигурации системы;
• проверка надежности системы;
• окончательная настройка.
63
Эти работы будут выполняться той же группой, что и на ранних стадиях.
В состав этой группы входят работники технического отдела - технические
специалисты и системные администраторы, сотрудники ИТ-отдела.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
При разработке и внедрении ИС существует множество причин риска:
ошибки в выборе стратегии проекта, неоднозначные цели и задачи, изменение во
внешних и внутренних требованиях, низкая квалификация персонала.
Основные риски, которые могут возникнуть в течение жизненного цикла
разработанной информационной системы, а также корректирующие меры,
приведенные в таблице 2.1.
64
Таблица 0.2
Описание рисков, которые могут возникнуть при разработке информационной системы бронирования и учета клиентов
Виды
рисков
Снижение видов риска
Допущение риска
(для крупных
проектов, как
правило, не
срабатывает)
Распределение риска
Снижение вероятности
возникновения риска
Риски,
связанные с
масштабом
проекта
Детальный анализ
каждого этапа работ,
взаимодействия
участников, организации
работ
Увеличение
трудоемкости работ
и стоимости проекта
Разделение проекта на
несколько подпроектов,
выделение пилотного проекта
по подсистемам (ограниченного
масштаба)
Детально проработанная
программа качества,
отработанное управление
конфигурацией проекта,
специальные процедуры
взаимодействия участников
Риски,
связанные с
недостаточны
м опытом в
сфере ИТ
Проведение обучения
пользователей, включая
руководство, соблюдение
технологий работы
Увеличение
трудоемкости работ
и стоимости проекта
Согласование с заказчиком
большинства проектных
документов, согласование всех
изменений в функциональности
системы
Разработка и утверждение
концепции проекта на
возможно более ранней его
стадии
65
Технические
риски проекта
Строгий отбор проектной
команды по
квалификационным
критериям. Обучение
участников проекта
технологии проектных
работ, инструментальным
средствам
Увеличение
трудоемкости работ
и стоимости проекта
Документально
зафиксированная персональная
ответственность участников
проекта, документальное
фиксирование всех изменений в
процессе проекта
Использование стандартов
предприятия на проектные
работы, разработка
стандартов проекта
Организацио
нные риски
проекта
Обучение участников
проекта (курс "управление
проектом"), тренинги
команды, как можно более
полная формализация
деятельности
Увеличение
трудоемкости работ
и стоимости проекта
Включение представителей
заказчика в рабочие группы
Включение в команду
администратора проекта,
детальное распределение
ролей в проекте
Операционн
ые риски
проекта
Многократное
тестирование созданных
продуктов, тщательная
экспертиза документов
Увеличение
трудоемкости работ
и стоимости проекта
Акт сдачи заказчику любого
документа. Фиксирование
отсутствия претензий заказчика
по каждому этапу работы
Строгое выполнение
процедур программы
качества