57
используется другими компаниями для отслеживания проектов, не связанных с
созданием ПО);
• Она логичнее справляется со сложностями и отлично показывает
себя в тех проектах, где все достаточно понятно, но все равно трудно
разрешимо;
• Она вполне доступна для понимания, поскольку преследует
простую цель — реализовать нужные действия;
• Она удобна и проста в использовании, поскольку сам процесс
разработки реализован поэтапно;
Но в случае применения каскадной модели для проекта, который нельзя
назвать подходящим для нее, выявляются некоторые недостатки:
• Модель основана на последовательной линейной структуре,
поэтому каждая попытка возврата на одну или две фазы назад для исправления
какой-либо проблемы или недостатка приводит к серьезному увеличению затрат
и сбою в графике;
• Модель не предотвращает возникновение итераций между фазами,
часто встречающиеся в процессе создания ПО, т.к. сама модель разрабатывается
согласно обычному циклу аппаратного инжиниринга;
• Модель не показывает главное свойство создания ПО, направленное
на решение задач. Отдельные фазы жестко связаны с конкретными действиями,
что входит в разрез с реальной работой персонала или коллективов;
• Модель создает ошибочное впечатление о работе над проектом.
Понятие типа "25% выполнено" не имеет никакого смысла и не может являться
показателем для менеджера проекта.
Ввиду недостатков каскадной модели ее использование ограничено
ситуациями, в которых требования и их реализация максимально четко
прописаны и понятны.
Каскадная модель замечательно функционирует при ее использовании в
циклах разработки ПО, в которых применяется неизменяемое определение
продукта и четко понятны технические методики.
58
V-образная модель создается для поддержки работающей над проектом
команды в планировании с реализацией дальнейшей возможности проверки
системы. В этой модели главное значение придается действиям, направленным
на подтверждение и проверку продукта. Она отражает, что проверка продукта
обсуждается, конкретизируется и планируется еще на ранних стадиях ЖЦ
разработки. План приемки продукта заказчиком пишется на этапе планирования,
а само испытание системы - на фазах разработки и анализа проекта и т.д. Такой
процесс создания планов испытания выделен пунктирной линией между
прямоугольниками V-образной модели
В процессе применения V-образной модели при создании проекта, для
которого она оптимально подходит, реализуется несколько преимуществ:
• Модель придает особое значение придается планированию,
направленному на подтверждения и проверки создаваемого ПО еще на
начальных стадиях его разработки. Этап модульного тестирования подтверждает
правильность детализированного проектирования. Этапы внедрения и проверки
описывают архитектурное проектирование или проектирование на высоком
уровне. Этап проверки системы подтверждает правильность выполнения этапа
требований к продукту и его параметров;
• Модель предусматривает аттестацию и подтверждение всех
внешних и внутренних полученных данных, а не только исходного ПО;
• V-образной модель выполняет определение требований перед
началом разработки проекта системы, а само проектирование ПО проходит
перед созданием компонентов;
• Модель определяет продукты, полученные в результате процесса
разработки, и все полученные данные подвергаются тестированию;
В процессе применения V-образной модели в работе над проектом, для
которого она не совсем подходит и недостаточно приемлема, проявляются ее
недостатки:
• Этой модели непросто справиться с параллельными событиями;
• В ней не учитываются итерации между фазами;
59
• В ней нет внесенных требований динамических изменений на
разных этапах ЖЦ;
• Проверка требований в ЖЦ реализуется слишком поздно, поэтому
невозможно внести корректировки, не повлияв при этом на сроки выполнения
проекта;
• Модель не включает действия, направленные на анализ рисков.
Как и каскадная модель, V-образная модель также лучше срабатывает
тогда, когда вся информация о требованиях заранее известна.
Общераспространенная модификация V-образной модели, направленная на
преодоление ее недостатков, включает в себя внесение итерационных циклов
для разрешения изменения в требованиях за рамками фазы анализа.
Применение модели эффективно тогда, когда доступными являются
данные о методе разработки решения и технология, а персонал обладает всеми
умениями и опытом в работе с используемой технологией.
Отличительной чертой RAD становится короткое время перехода от
выявления требований до разработки полной системы. Метод базируется на
совокупности итераций эволюционной системы или прототипов, критический
анализ которых утверждается у заказчика. Во время такого анализа
составляются требования к продукту.
Создание каждого внедренного продукта ограничивается четко
выделенным периодом времени, который обычно составляет 60 дней и носит
название «временной блок».
Инкрементная разработка включает в себя процесс частичного создания
всей системы и неторопливого наращивания функциональных возможностей.
Подобный подход дает возможность минимизировать затраты, понесенные до
момента достижения уровня установленной производительности. При помощи
такой модели убыстряется процесс разработки действующей системы. Этому
способствует используемый принцип сочетания из стандартных блоков, который
позволяет обеспечить контроль над процессом внедрения указанных требований.
Спиральная модель включает в себя положительные стороны каскадной
модели. При этом она также включает анализ рисков, может управлять ими, а
60
также имеет процессы поддержки и менеджмента. В ней также предусмотрено
создание программного продукта при помощи метода прототипирования или
быстрой разработки приложений с применением языков программирования и
средств разработки 4 поколения и выше.
Стандарт ISO/IEC серии 15288
В связи с небольшим объемом разрабатываемой автоматизированной
системы, ее назначением, характером необходимо использовать именно этот
стандарт. Для создаваемой системы перечень стадий, участники этапов,
требования к входной информации и основные результаты, которые должны
быть достигнуты к моменту их завершения, приведены в таблице 2.1.
61
Таблица 2.1
Стадии создания автоматизированной системы (в соответствии с ISO/IEC 15288)
№ п/п
Стадия
Ключевые участники
Требования к входной
информации
Результаты
1
Формирование
концепции
Разработчик, начальник
отдела ИТ, программист
Описание бизнес—
процессов организации, форм
входных и выходных
документов, общие
требования к системе
Анализ потребностей,
выбор концепции и
проектных решений
2
Разработка
Начальник отдела ИТ,
разработчик, программист
Требуемые функции
системы
Проект системы
3
Реализация
программист
Проект системы,
требования к программному,
информационному и
техническому обеспечению
Готовая информационная
система, комплект
документации
4
Эксплуатация
Администратор системы,
пользователи
Руководство
администратора и
пользователя системы
Ввод в эксплуатацию и
использование системы
5
Поддержка
Администратор системы,
разработчик
Статистика отказов,
ошибок в работе
информационной системы
Обеспечение
функционирования системы
6
Снятие с
эксплуатации
Начальник отдела ИТ
Обоснование
прекращения использования
системы
Прекращение
использования, демонтаж,
архивирование системы
62
Задача внедрения информационной системы включает в себя создание
(адаптацию) и запуск в продуктивную эксплуатацию элементов
информационной системы. Так как разработка информационной системы будет
осуществляться своими силами, то и внедрение будет происходить без
привлечения посторонних специалистов.
Этап внедрения планируется разбить на следующие подэтапы:
1. Предпроектное обследование. В ходе обследования выявляются
основные информационные потоки на предприятии и сверяется база основной
нормативно—справочной документации. Главным требованием в данном случае
является наличие всех необходимых для функционирования корпоративных
информационных систем справочников и классификаторов и соответствие
принципових организации требованиям системы. В ходе выполнения этапа
обязательно должны быть проанализированы на полноту корпоративные
стандарты учета и отчетности. На данном этапе также производится
диагностирование проблем, которые могут возникнуть при внедрении,
разрабатывается и согласовывается настройка справочников и классификаторов
системы в соответствии с сформулированными требованиями. При
необходимости, принимаются решения об изменении существующих практик
учета или функциональных моделей. По результатам этапа формируется
подписываемый всеми участниками проекта внедрения документ, который
описывает все выявленные проблемы и намечает пути их ликвидации.
2. Построение информационно—функциональной модели деятельности
предприятия, описание и оптимизация процессов, подвергающихся
автоматизации. Моделирование должно проводиться хорошо обученными
сотрудниками рассматриваемого предприятия с привлечением
высококвалифицированных консультантов и с привязкой созданной модели к
стандартам бизнеса и к будущей системе.
3. Адаптация ИС на предприятии. В ходе этапа производится настройка
системы тестирование отдельных модулей и функций группой внедрения. На
данном этапе также очень важно наличие корпоративных стандартов, так как
именно они являются основой настроек системы.
63
4. Опытная эксплуатация информационной системы. Осуществляется для
тестирования полного соответствия функциональности, полученной в
результате настройки системы, требованиям предприятия. На этом этапе
сохраняется двойной ввод данных в старую и новую системы. В ходе опытной
эксплуатации: генерируются стандартные отчеты (с помощью ИС и обычными
способами) и производится верификация данных; система постепенно вводится
в эксплуатацию, по отдельным участкам учета; документируются инструкции по
ведению рабочих мест и корректируются должностные инструкции участников
учетного процесса. В отдельных подразделениях предприятия в систему
вводятся фактические данные (в ограниченном объеме) и последовательно
тестируются бизнес—функции путем моделирования реальных ситуаций
деятельности предприятия (в условиях, максимально приближенных к
действительности). Отрабатывается взаимная работа подразделений на основе
тестовых пилотных примеров. Конечные пользователи (сотрудники отдела ИТ)
обучаются работе с настроенной системой непосредственно на своих рабочих
местах. После обучения конечных пользователей отрабатывается
интегрированный пилотный пример и полностью моделируется деятельность
предприятия. На основе результатов выполнения пилотного примера
руководством предприятия принимается решение о переводе ИС в
промышленную эксплуатацию.
Этап эксплуатации подразумевает под собой непосредственное
использование информационной системы для выполнения ею тех функций, для
которых она предназначена.
Работы, ожидаемые на этапе эксплуатации, можно разделить на две
группы: плановые и неплановые.
К плановым работам будут относятся такие работы, как:
инсталляция программного обеспечения;
базовая настройка и проверка работоспособности компонентов
устанавливаемой системы;
устранение недостатков в конфигурации системы;
проверка надежности работы системы;
64
окончательная донастройка.
Данные работы будут проводиться той же группой, что и на ранних
этапах. В состав этой группы входят сотрудники технического отдела —
технические специалисты и системные администраторы, сотрудники ИТ отдела.
Существует несколько различных стратегии внедрения системы:
1) Стратегия “Параллельное использование” предполагает параллельное
выполнение старой и новой технологии решения задачи, их результаты
сравниваются. Если результаты сравниваются длительное время, то реализуется
переход на новую технологию.
Положительные стороны:
• Отсутствие риска ошибок в виде новых технологий;
• Внедрением ИС можно заниматься независимо от обычного
операционного планирования фирмы.
Негативные стороны:
• Сильная загрузка персонала;
• Необходимость удвоения мощности серверов;
• Необходимость сверки результатов деятельности двух технологий.
2) Стратегия “Скачек” – это не новая технология, и работает она до
определенного момента, затем реализуется внедрение новой технологии, а затем
уже используется только новая технология.
Положительные стороны:
• Почти незаметный переходный период;
• Отсутствие двойных затрат на деятельность компании;
• Новые процессы более оптимальны поскольку нет переходного
периода.
Негативные стороны:
• Повышенный риск несоответствия качества ИС требованиям
предприятия;
• Повышенные требования к процессу планирования перехода на
обновленную технологию;
65
3) Стратегия “Пилотный проект” применяет тактику скачка к некоторому
числу процессов, областью применения зачастую становится небольшой
участок.
Положительные стороны:
• Отсутствии риска выбора неверного решения, приводящего к
длительному простою всего предприятия;
• Доступность изменения планируемой технологии в процессе
установки ИС на участке;
• Отсутствие двойных затрат на реализацию проекта.
Негативные стороны:
• Запутанное объединение информационных потоков, составляемых
по старой и новой технологии;
• Одновременное управление и старой, и новой ИС.
4) Стратегия “Узкое место” автоматизирует малую часть
производственного процесса, который зачастую выбирается по критериям
эффективности, приводящих к увеличению качества внедрения процессов
только выделенном узком месте.
Положительные стороны:
• После окончания автоматизации каждого узкого места можно
прервать автоматизацию;
• Невысокие требования к уровню планирования внедренческих
работ.
Негативные стороны:
• Проведение полного цикла планирования на каждом из узких мест –
имея возможность прерывания автоматизации, сам процесс может никогда не
закончится;
• Независимость автоматизации узких мест приводит к созданию
лишнего множества программно-аппаратных решений.
Выбираем стратегию «Узкое место».
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
66
При разработке и внедрении ИС существует много причин, приводящих к
возникновению рисков: ошибки в выборе стратегии проекта, нечетко
поставленные цели и задачи, изменение внешних и внутренних требований,
низкая квалификация персонала и т. д.
Основные риски, которые могут возникнуть в ходе жизненного цикла
разрабатываемой информационной системы, а также меры по их устранению,
приведены в таблице 2.1.