58
регламентирует последовательность процессов в каждом этапе, что позволяет
самостоятельно выбирать подходящие для себя процессы. Во-вторых, стандарт
охватывает все этапы более полно, нежели остальные стандарты. В-третьих, ISO
12207-99 не указывает на этапы, а лишь регламентирует их, что позволит
разработчику самостоятельно управлять жизненным циклом.
Стандарт ISO 12207 включает всего 16 процессов, которые объединяются в
3 группы (рисунок 2.1).
3.1 Управление 3.2 Создание инфраструктуры
3.3 Усовершенствование 3.4 Обучение
1.1 Заказ
1.2 Поставка
1.4 Эксплуатация
1.3 Разработка
1.5
Сопровождение
2.1 Документирование
2.2 Управление конфигурацией
2.3 Обеспечение качества
2.4 Верификация
2.5 Совместный анализ
2.6 Аудит
2.7 Решение проблем
1. Основные процессы жизненного
цикла
3. Организационные процессы жизненного цикла
2. Вспомогательные процессы
жизненного цикла
Рисунок 2.1 Структура стандарта ISO 12207-99
Процессы состоят из отдельных видов деятельности. Всего стандартом
определенно 74 вида деятельности, связанной с разработкой и поддержкой ПО.
Каждый вид деятельности в свою очередь нацелен на выполнение одной или
нескольких задач.
Основной процесс жизненного цикла состоит из пяти видов деятельности:
1) Заказ;
2) Поставка;
3) Разработка;
4) Эксплуатация;
5) Сопровождение.
59
Каждый процесс определяет основного исполнителя и действия, которые
необходимо выполнить в назначенные сроки. Процесс заказа – основной
исполнитель организация заказчик информационной системе. На данном этапе
определяется потребность заказчика в информационной системе, происходит
выбор поставщика / разработчика и непосредственно управление заказом вплоть
до приемки готовой системы.
Процесс поставки – исполнитель организация поставщик. Этап начинается
с подписания договора на поставку системы, продолжается определением
процедур и ресурсов, необходимых для обеспечения выполнения проекта. И
заканчивается поставкой готовой системы и подписанием актов.
За процесс разработки отвечает организация разработчик. Процесс
включает в себя работы по анализу требований, проектированию,
программированию, сборке, тестированию и вводу в действия программного
продукта.
Процесс эксплуатации определяет задачи оператора. Он охватывает
эксплуатацию программного продукта и поддержку пользователей в процессе его
использования.
Процесс сопровождения состоит из задач и работы персонала,
ответственного за сопровождение программного продукта. Этот процесс
реализуется при модификациях программного продукта и документации к нему,
вызванных изменениями в связи с улучшением или устранением ошибок. Целью
процесса является изменение существующего программного продукта при
сохранении его целостности.
Согласно выбранному стандарту следует выделить следующие этапы:
Подготовка проекта
• Анализ деятельности
• Проведение предпроектного обследования
• Разработка плана проекта
Разработка
• Создание таблиц и связей БД
• Создание шаблонов отчетных файлов
• Создание процедур по сбору, обработке и хранению информации
60
• Создание процедур фильтрации
• Разработка пользовательского интерфейса
Тестирование настроек системы
• Настройка словарей и справочников
• Тестирование работоспособности системы
• Корректировка системы по результатам тестирования
• Подготовка документации для внедрения
• План эксплуатации
• Документация по установки и настройки ПО
• Подготовка плана внедрения
Внедрение
• Установка на сервер СУБД
• Установка серверных компонентов системы учета продаж
• Установка клиентских приложений системы учета продаж
• Настройка серверной и клиентских частей
• Тестирование работоспособности
• Демонстрация работы системы
• Подготовка плана по обучению пользователей
• Проведение семинара по обучению работе с системой
• Обучение службы эксплуатации
Эксплуатация
• Подготовка плана по эксплуатации
• Ввод системы в опытную эксплуатацию
• По результатам опытной эксплуатации перевод системы в
промышленную эксплуатацию
• Поддержка пользователей
• Проведение обучающих лекция для пользователей
• Подготовка отчетов о работе системы
Сопровождение
• Анализ ошибок и их устранение
• Подготовка отчетов по модификациям и изменениям
• Обновление функционирующих систем
61
На первоначальном этапе после проведения анализа деятельности
организации, необходимо поставить цели и задачи автоматизации и разработать
план проекта. После документального оформления начинается непосредственно
сам процесс разработки. Создается база данных, отчетные формы, пишется
программный код по сбору, обработке и хранению информации, создаются
процедуры фильтрации. После разработки системы, проходит этап тестирования.
По завершению тестирования готовится план эксплуатации и документация для
внедрения, а так же различная пользовательская документация. Процесс будет
происходить следующим образом. Так как в организации уже существует ЛВС и
стабильно функционирует, в ее наладке нет необходимости. Первоначально
устанавливается серверная часть системы учета продаж, далее на рабочие места
проходит установка и настройка клиентских приложений системы учета продаж
и СУБД. Тестируется работоспособность, проводится демонстрация работы
системы для руководства и персонала. Последней стадией будет проведение
семинаров для сотрудников компании. Необходимо связать всех сотрудников,
отвечающих за обработку документов в единую информационную сеть. Для этого
клиентские приложения будут устанавливаться в четкой последовательности по
определенным отделам
За эксплуатацию готовой системы, будет отвечать оператор. В его задачу
будет входить:
1. Разработка плана эксплуатации и определения набора стандартов
эксплуатации.
2. Получение и документирование сведений о возникающих проблемах, их
решение и контроль за возникновением, обеспечение обратной связи с
пользователями.
3. Тестирование системе в эксплуатационной среде, кооперация со службой
сопровождения для устранения возникших проблем и модернизации системы.
4. Поддержка и консультация пользователей.
В соответствии с выбранной моделью основными этапами разработки
будут являться:
Формирование требований
Проектирование
62
Реализация
Тестирование
Ввод в действие
Эксплуатация и сопровождение.
Существует 4 основных способа начала использования новой системы
Параллельная стратегия;
Скачок;
Узкое место;
Опытная эксплуатация "пилотного проекта.
Параллельная стратегия не подходит , так как компания не располагает
достаточными ресурсами для ведения учета одновременно в автоматизированном
и ручном вариантах. Стратегия Скачек не позволяет плавно перейти на
использование разработки, узкое место больше подходит для использования в
крупных компаниях. Поэтому в качестве стратегии внедрения ИС была выбрана
«Опытная эксплуатация пилотного проекта».
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Разработка программного обеспечения — это деятельность, которая
использует различные технологические достижения и требует высокого уровня
знаний. Из-за этих и других факторов каждый проект разработки программного
обеспечения содержит элементы неопределенности. Это называется рисками
проекта. Успех проекта разработки программного обеспечения в значительной
степени зависит от степени риска, который соответствует каждой деятельности
проекта. Как руководитель проекта, недостаточно просто осознавать риски.
Чтобы достичь успешного результата, руководство проекта должно определить,
оценить, расставить приоритеты и управлять всеми основными рисками.
Цель большинства проектов по разработке программного обеспечения
состоит в том, чтобы отличаться - часто за счет новых функций, большей
эффективности или использования достижений в разработке программного
обеспечения. Любой руководитель проекта программного обеспечения
согласится с тем, что поиск таких возможностей не может продвигаться без риска.
63
Поскольку риски чрезвычайно реальны и довольно распространены во всех
программных проектах, крайне необходимо, чтобы заинтересованные стороны
усердно работали над выявлением, пониманием и смягчением любых рисков,
которые могут угрожать успеху проекта. Для проектов, имеющих ограничения по
времени и затратам, успешные усилия по разработке программного обеспечения
— это те, в которых снижение рисков является центральным управленческим
действием.
При проектировании информационной системы обязательно необходимо
задумываться о рисках, которые могут возникнуть на всех этапах её
существования. В этой части работы я опишу возможные риски и шаги, которые
можно предпринять для уменьшения величины каждого конкретного риска. Риски
разбиты по типам для улучшения восприятия.
Этап проектирования проекта:
1. Риски, связанные с сотрудниками
Список рисков этого типа:
• Недостаточный опыт сотрудников, привлекаемых в проект
• Плохо мотивированные сотрудники
• Плохое понимание персоналам конечной цели проекта
• Плохая коммуникация внутри коллектива
Способы снижения рисков:
• Налаживание процесса обчуения новых разработчиков более опытными
• Персональный подход начальников к своим подчинённым
• Мотивационные бонусы
• Чёткое разделение обязанностей сотрудников
2. Риски, связанные с принятием неправильных решений
Список рисков этого типа:
• Ошибочная оценка ресурсов, необходимых для проекта
• Появление лишнего функционала
• Неправильный выбор технологического стека
• Невыполнение технического задания заказчика
Способы снижения рисков:
• Хорошо поставленный процесс разработки
64
• Своевременное предоставление ресурсов, необходимых проету
• Неизменяемость границ проекта в течение его развития
• Принятие решения должно проходить в несколько этапов и согласований
3. Риски при планировании проекта
Список рисков этого типа:
• Плохо проработанный план развёртывания системы
• Неправильно определённые сроки разработки
Способы снижения рисков:
• Проведение независимых исследований
• Своевременное создание документации, доступной для всех сотрудников,
участвующих в проекте
Этап разработки
4. Риски, связанные с сотрудниками
Список рисков этого типа:
• Уход ключевых сотрудников
• Плохо мотивированные сотрудники
• Плохое понимание персоналам конечной цели проекта
• Плохая коммуникация внутри коллектива
• Утечка корпоративных данных
• Плохие отношения внутри коллектива
Способы снижения рисков:
• Тщательный отбор персонала
• Чётко разграниченные роли
• Мотивационные бонусы
• Хорошо выстроенная система безопасности проекта
• Совместные мероприятия и тим-билды
5. Риски, связанные со сбоями в системе
Список рисков этого типа:
• Отказ компонентов системы
• Неправильная работа системы после внесения в неё изменений
Способы снижения рисков:
• Качественный мониторинг системы
65
• Создание резервных копий
• Использование проверенных решений при разработке
• Своевременное изменение ресурсов при увеличение нагрузки
• Периодические исследования на выявление слабых мест системы с
последующим их устранением
Этап внедрения
6. Риски, связанные с сотрудниками
Список рисков этого типа:
• Плохая коммуникация между разработчиками и специалистами по
внедрению
• Недостаток знаний сотрудников после перехода на новую систему
Способы предотвращения:
• Проведение обучающих занятий для сотрудников заказчика
• Создание плана по внедрению новой системы
• Обоснование необходимости автоматизации персоналу
7. Технические риски
Список рисков этого типа:
• Утеря данных при внедрение новой системы
Способы предотвращения:
• Привлечение квалифицированного и опытного персонала
Этап эксплуатации и сопровождения
8. Технические риски
Список рисков этого типа:
• Ошибки в работе системы
• Некорректная работа старого функционала после обновления
• Некорректная эксплуатация оборудования
• Устаревшая документация
Способы предотвращения:
• Своевременные исправление ошибок системы
• Тщательно выстроенная система тестирования нового функционала и
регрессионное тестирование старого
• Своевременное обновление документации.
66
В типичном проекте можно выделить следующие основные риски на
каждом этапе разработки (таблица 2.1).
Таблица 2.1
Основные риски на этапах реализации системы
Этап
Риск
Мероприятия
Предпроектное
исследование
Несоответствие
выделенного бюджета
масштабу проекта
Переговоры по
увеличению бюджета
или отказ от участия в
проекте
Неформализуемая
задача (невозможно
автоматизировать те или
иные бизнес-процессы
или стоимость такой
автоматизации превысит
ожидаемую выгоду)
Пересмотреть
область действия проекта
с целью выделения
отдельных задач,
поддающихся
автоматизации.
Провести
детальный анализ
бизнес-процессов и
предложить комплекс
мероприятий по их
реорганизации.
Проектирование
базы данных и
приложения
- неправильное
определение рамок и
масштабов проекта;
- проектирование
ошибочных функций и
интерфейсов будущей
системы;
- выбор
неправильных
технологий и методов
решения поставленных
задач;
- несоблюдение
требований заказчика при
проектирование будущей
системы или постоянное
изменение требований.
- обеспечение
стабильности границ
проекта, определенных
на начальном этапе,
вплоть до окончания
проекта;
- качественное
планирование работ;
- своевременная
идентификация
проектных рисков и
разработка
рекомендаций по
снижению рисков;
- обеспечение
проекта необходимыми
ресурсами;
- обязательное
утверждение и
согласование по
проектным решениям;
67
Этап
Риск
Мероприятия
Разработка базы
данных и приложения
Недостаточно
ресурсов для выполнения
комплексного и
нагрузочного
тестирования
Увеличить
количество
привлекаемых
специалистов
Недостаточно
опыта у персонала
заказчика, который будет
эксплуатировать систему
Предоставить
заказчику услуги
собственного
специалиста для
первоначального
сопровождения системы
и постепенного обучения
персонала заказчика.
Внедрение
- увеличение
нагрузки на персонал;
-
несогласованность
действий персонала
исполнителя и
сотрудников предметных
областей;
- трудности с
обучением персонала
заказчика из-за
нежелания работать
сновой системой;
- отсутствие
поддержки внедрения ИС
со стороны отдельных
ключевыхучастников
проекта;
- неучастие
руководителей высшего
звена в проекте.
- проведение
обучения персонала
заказчика работы с
системой;
- составление
плана внедрения ИС;
- доведение до
персонала заказчика
смысла внедрения
автоматизированной
системы;
- активное
вовлечение высшего
руководства в проект,
активное взаимодействие
с ним в ходе проекта и
своевременное принятие
решений, необходимых
для нормальной
реализации проекта.
Чтобы уменьшить величину данных типов рисков необходимо иметь
достаточно компетентных и квалифицированных сотрудников, имеющих большой
опыт работы в соответствующей области и при этом взаимозаменяемых на
сотрудников, не менее соответствующих данным характеристикам (таблица 2.2).
Таблица 2.2
Характеристики дефектов программного продукта