Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования. Существует несколько моделей и стандартов, в той или иной степени регламентирующих жизненный цикл, большинство из них относятся к заказному ПО (автоматизированным системам АС, и др.) и кроме непосредственно ЖЦ регламентируют также и процессы разработки:[18]
ГОСТ 34.601-90 распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла [2].
ISO/IEC 12207:1995 стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий этапов.[3]
Custom Development Method (и, методика Oracle) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Степень адаптивности CDM ограничивается тремя моделями ЖЦ: "классическая" (предусмотрены все работы/задачи и этапы), "быстрая разработка" (Fast Track), "облегченный подход", рекомендуемый в случае малых проектов и возможности быстро прототипировать приложения.
Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы [3]. Суть работы в рамках RUP - это создание и сопровождение моделей, а не бумажных документов, поэтому этот процесс привязан к использованию конкретных средств моделирования (UML), а так же конкретной технологии проектирования и разработки (объектно-ориентированный анализ, object-oriented analysis, OOA, объектно-ориентированное программирование, object-oriented programming, OOP).
Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. [8]. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.
Extreme Programming (XP). Экстремальное программирование является самым новым среди рассматриваемых методологий, сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.
Основными критериями для выбора стандарта ЖЦ будут:
актуальность и современность используемых методик контроля разработки
разработка в итерационном режиме с возможностью контролировать риски
и выполнения самого проекта на неких контрольных точках, отсутствие дополнительных требований по моделированию процесса разработки и внедрения.
Резюмируя описание стандартов выше итерационными из них являются 4 стандарта: MSF, RUP, COBIT, XP.
Стандарт COBIT мне не подходит, потому что основной целью его использования “является проведения аудита и стратегического планирования ИС и IT инфраструктуры в целом”[18]
Стандарт XP мне тоже не подходит, так как он не содержит полноценных этапов ЖЦ, таких как выработка концепции, планирование, разработка, стабилизация, внедрение.
Следовательно, перед выбором стоит Rup и MSF. Оба стандарта являются молодыми и поддерживающими всё новые технологии продуктивной разработки и контроля их выполнения
Основные особенности MSF, RUP и XP сведены в таблицу 10. По ней можно судить, что Rational Unified Process является хорошо сбалансированным решением для средних по размерам коллективов разработчиков, работающих с применением продуктов и технологий компании Rational. Сопровождение разработки системы и самой системы регламентируется методологией RUP, однако данная технология достаточно сильно ориентирована на внутрифирменные инструментальные средства.
Extreme Programming хорошо подходит для проектных групп малого размера и для небольших систем с часто изменяемыми требованиями. Основная проблема XP - сопровождение. В случае текучки кадров в коллективе разработчиков значительная часть проектной информации может быть утеряна из-за практически отсутствующей документации. В таблицк № 12 представлены основные показатели стандартов Жизненного цикла ИС
| Таблица 12. Технологии MSF, RUP и XP | ||||
| Технология | Оптимальная команда | Соответствие стандартам | Допустимые технологии и инструменты | Удобство модификации и сопровождения |
| Rational Unified Process | 10 - 40 чел. | стандарты Rational | UML и продукты Rational | Удобно (RUP) |
| Microsoft Solutions Framework | 3 - 20 чел. | адаптируема | любые | Удобно (MSF+MOF) |
| XP | 2 - 10 чел. | стандарты отсутствуют | любые | Сложно (зависимость от конкретных участников коллектива) |
Microsoft Solutions Framework является наиболее сбалансированной технологией, ориентированной на проектные группы малых и средних размеров. MSF не накладывает никаких ограничений на используемый инструментарий и содержит рекомендации весьма общего характера. Однако, эти рекомендации могут быть использованы для построения конкретного процесса, соответствующего потребностям коллектива разработчиков.[23]
Наш проект является небольшим, включает в себя 3 человека и этапы разработки и тестирования проводятся в среде разработки Python. Кроме того основным преимуществом MSF является итерационная модель одновременно с уточняющими вехами (аналог каскадной модели). Таким образом, реализация MSF попыталась объединить каскадную и итерационную модель разработки и внедрения ПО[18]
По описанным выше преимуществам, мною был выбран стандарт MSF как наиболее гибкий и удобный для реализации моего проекта.
Одним из преимуществ этого стандарта является возможность управлять одновременно и проектом разработкой приложения и внедрением инфраструктуры.
Итак, в идеологии MSF существует 5 стадий жизненного цикла ИС, которые в понятии MSF называют фазами. Первый из них это Фаза выработки концепции.
Цель данной фазы в создании и сплочении проектной группы на основе выработки единого видения. Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель. Заказчиком в нашем случае выступаем мы сами и весь холдниг единовременно.
В идеологии MSF команда проекта делиться на 6 участников, каждый из которых имеет свою роль в проекте, наделён обязанностями и имеет свою зону ответственности. эти роли MSF назвала кластерами, за каждым из которых может быть закреплён не один человек, итак вот они: Управление продуктом, Управление программой, Разработка, Удовлетворение потребителя, Тестирование, Управление выпуском. В каждой фазе для каждого ответственного лица, закреплённого за кластером закрепляются определённые задачи.
Вот какие задачи ставятся в фазе выработки концепций. Управление продуктом регулирует Концептуальный и логический дизайн; функциональная спецификация; сводный план и сводный календарный график проекта; бюджет.. Кластер Управление программой формирует цели дизайна, концепцию решения, структуру проекта. Кластер Разработка отвечает за Оценка технологий; логический и физический дизайн; план и календарный график разработки; смета разработки.
Кластер удовлетворения потребителя рассматривает Сценарии/примеры использования, пользовательские требования, требования локализации и общедоступности (accessibility); пользовательская документация/план обучения/график тестирования удобства эксплуатации; обучение.
Кластер Тестирования формирует Оценка дизайна; требования тестирования; план и календарный график тестирования.. Кластер управление выпуском выполняет функции Оценка дизайна; эксплуатационные требования; план и календарный график пилотного и окончательного внедрения. К сожалению или к счастью, но в рамках создания и внедрения моего проекта силами сотрудников ИТ департамента, использовать 6 и более человек для фоновой задачи, бюджет которого ограничен лишь премией крайне нецелесообразно. Я объединил задачи кластеров и сформировал из них 3 ответственных лица, они же и есть команда проекта
1)Программист на которого возложены следующие кластеры:
· Управление программой,
· Разработка
· удовлетворение пользователей
2) менеджер проекта, он же внедренец, он же тестировщик, на него возложены следующие кластеры:
· Управление продуктом,
· Тестирование
· управление выпуском.
Выходной информацией и результатами данной Фазы является подбор кандидатов и назначение наиболее подходящих из них к требуемым задачам на исполнение двух ролей, то есть формирование команды, несмотря на то, что она состоит всего из двух человек. В нашем проекте на данном этапе будут определены состав и роли участников Составлена смета по времени и планирование бюджета данного проекта.
Следующим этапом ЖХ ИС идёт Фаза планирования. Основной её целью является составлению планов проекта. Она включает в себя подготовку проектной группой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта.
Процесс проектирования – это систематический способ продвижения от абстрактных концепций к конкретным техническим деталям. Описание обязанностей каждого из кластеров содержаться в Приложении таблице №3.
Результатами фазы планирования являются: функциональная спецификация, Описание возможных рисков, Сводный план и сводный календарный график проекта, развернутые Среды разработки и тестирования. От программиста на данном этапе требуется обзор и выбор я языка программирования, на котором будет реализовано решение, + календарный план по срокам и графикам разработки. Менеджер проекта на данном этапе продумывает всю архитектуру ИС, включая взаимодействие почтового сервера, веб сервера, Субд, работу пользователей и инженеров в будущей системе.
Следующим этапом следует Фаза разработки. На фазе разработки проектная группа фокусируется на создании компонент решения (включая как документацию, так и программный код). Однако некоторая часть этой работы может продолжаться также на фазе стабилизации, если такая необходимость выявлена в процессе тестирования. Данная фаза также включает в себя разработку инфраструктуры.
Следует обратить внимание, что активность проектной команды на этом этапе не ограничивается написанием разработчиками кода – все ролевые кластеры принимают деятельное участие в создании и тестировании решения. Таблица № 11 описывает основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы разработки. Данная таблица представлена в Приложении №1
Результатами фазы разработки являются: Исходный и исполнимый код приложений, Скрипты установки и конфигурирования, Окончательное описание функционала разарабатываемого решения, Материалы поддержки решения, сценарии тестов. В нашем случае от программиста на данном этабе требуется предоставить программу клиент для работы Инженеров ИТ и написание полной документации к ней. От руководителя проекта требуется создать работоспособную среду описанную в предыдущем этапе.
Следующим этапом ЖЦ идёт Фаза стабилизации
Во время фазы стабилизации производится тестирование разработанного решения. При этом внимание фокусируется на его эксплуатации в реалистичной модели производственной среды. Проектная группа занимается приоритезацией и устранением ошибок, а также подготовкой решения к выпуску.
Обычно в начале фазы стабилизации скорость выявления ошибок командой тестирования превосходит скорость, с которой эти ошибки могут устраняться командой разработчиков. Невозможно предсказать, сколько ошибок будет найдено и как много времени понадобится на их устранение. Однако существует два статистических признака, помогающих проектной группе оценить уровень стабилизации решения. Это точка конвергенции (bug convergence).В точке конвергенции (bug convergence) становится заметен существенный прогресс в устранении ошибок, то есть скорость устранения ошибок начинает превосходить скорость их обнаружения. Поскольку количество найденных, но не устраненных ошибок может колебаться даже после того, как оно начало убывать, конвергенция может рассматриваться скорее как тенденция, нежели как фиксированный момент во времени. Вслед за этой вехой количество активных ошибок должно продолжать убывать, вплоть до точки достижения нуля. Точка конвергенции дает проектной группе возможность понять, что процесс тестирования близится к концу.
Таблица № 12 описывает основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы стабилизации. Данная таблица представлена в Приложении №1.
Результатами фазы стабилизации являются: Окончательный продукт (golden release), Документация выпуска (release notes), Материалы поддержки решения, Результаты и инструментарий тестирования, Исходный и исполнимый код приложений, Проектная документация. В моём проекте на данном этапе Программистом корректируются ошибки в разрабатываемой им программе, компилируется версия релиз кандидат и после отсутствия критических ошибок по всем веткам функционала программы выпускается окончательная сборка исполняемого кода, параллельно с этим дополняется документация к работе с программой. Руководителем проекта на данном этапе набирает группу тестирования из 2-3 инженеров, которые будут пользоваться этой программой каждый день и тестирует все ветки функционала по разработанным ранее сценариям и формирует дополнения, которые можно будет реализовать в следующей версии.
Следующим этапом будет Фаза внедрения
Во время этой фазы проектная группа внедряет технологии и компоненты решения, стабилизирует внедренное решение, передает работу персоналу поддержки и сопровождения и получает со стороны заказчика окончательное одобрение результатов проекта. По завершению внедрения проектная группа производит анализ выполненной работы и удовлетворенности заказчика.
Во время этой фазы по ходу переноса компонент решения из среды тестирования в производственную среду могут продолжаться меры по стабилизации решения. таблица № 13 описывает основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы внедрения. Данная таблица представлена в Приложении №1. Результаты фазы внедрения включают в себя: Информационные системы эксплуатации и поддержки, Процедуры и процессы, Базы знаний, отчеты, журналы протоколов, Массивы данных и программный код, разработанные во время проекта. Отчет о завершении проекта, Показатели удовлетворенности заказчика и потребителей, Описание последующих шагов. На этом этапе Руководитель окончательно внедряет систему в эксплуатацию, устанавливает программный продукт на компьютерах Инженеров ИТ, распечатывает им инструкцию по работе с ней или проводит обучение по её алгоритму работы. Далее Пользователем высылается новый регламент работы ИТ отдела и информацию о новой логике обработки заявок с просьбой в течение недели ответить о замеченных изменениях в обслуживании службой ИТ.
Внедрение является общим понятием и для него существуют разные стратегии реализации, которые напрямую зависят от срока исполнения и качества ис, получаемой на выходе. Существуют четыре основные стратегии внедрения системы:
· Параллельная стратегия - когда одновременно работают старая (ручная) и новая система, и их выходные документы сравниваются. Если они согласуются длительное время, осуществляется переход на новую систему.
· "Скачок" - это резкий переход от старой системы к новой без дополнительных проверок и с полным отказом от старой системы.
· "Пилотный проект" это наиболее часто используемая стратегия. "Пилотный проект" - это тактика "скачка", но применяемая к ограниченному числу процессов. Область применения стратегии - небольшой участок деятельности. Такой подход снижает риск и наиболее надежен.
· "Узкое место" - это малая часть производственного процесса. При использовании подхода "узкое место" план внедрения выполняется только для "узкого места" и для людей, работающих в нем.
В данном дипломной проекте будет применена стратегия “Пилотный проект”. Мы будем проводить полный переход к автоматизированной системе для процессов регистрации и обработки заявок Областью применения внедрения будет отдел горячей линии, состоящий из 5 операторов. Такой подход не затронет работу всей ИС, а лишь автоматизирует рутинную часть. Надежность данного внедрения обусловлена четким соответствием порядка регистрации и обработки заявки регламенту горячей линии.
В данном дипломном проекте охарактеризовать стратегию внедрения можно как стратегию узкого места, так как данный проект автоматизирует процесс, связанный с работой операторов горячей линии, и узким местом является скорость ручной обработки писем, согласования их и детального уточнения.
Далее наступает этап эксплуатации разработанного программного продукта. В соответствии с написанной инструкции к применению, работу данной программы следует отслеживать работу программы каждые 2-4 часа, ведь программа может зависнуть или обработать не все письма, пришедшие на почтовый ящик горячей линии из за отсутствии логики обработки данного типа заявки, в данном случае письмо будет возвращено (переслано) на почтовый ящик горячей линии с пометкой в теме письма "Не обработано". Данного рода риска следует анализировать 1 раз в месяц и принимать решение о необходимости доработки логики программы, что в рамках поддержки программы первые пол года эксплуатации будет выполняться бесплатно программистом, реализовавшим описанную логику работы.
Под моделью жизненного цикла понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики информационной системы и специфики условий, в которых последняя создается и функционирует
К настоящему времени наибольшее распространение получили следующие основные модели жизненного цикла:
1. Задачная модель;
2. каскадная модель (или системная) (70-85 г.г.);
3. спиральная модель (настоящее время).
Задачная модель: при разработке системы "снизу-вверх" от отдельных задач ко всей системе (задачная модель) единый поход к разработке неизбежно теряется, возникают проблемы при информационной стыковке отдельных компонентов. Как правило, по мере увеличения количества задач трудности нарастают, приходится постоянно изменять уже существующие программы и структуры данных. Скорость развития системы замедляется, что тормозит и развитие самой организации. Однако в отдельных случаях такая технология может оказаться целесообразной:
· Крайняя срочность (надо чтобы хоть как-то задачи решались; потом придется все сделать заново)
· Эксперимент и адаптация заказчика (не ясны алгоритмы, решения нащупываются методом проб и ошибок).
Общий вывод: достаточно большую эффективность информационной системы таким способом создать невозможно.
Каскадная модель: в ранних, не очень больших по объему однородных информационных системах каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. № 8). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем:
· на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
· выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Рисунок № 8. Каскадная схема разработки
Каскадный подход хорошо зарекомендовал себя при построении информационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания систем никогда полностью не укладывался в такую жесткую схему. В процессе создания постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания программного обеспечения принимал следующий вид (рисунок № 9):
Рис. 9. Реальный процесс разработки ПО по каскадной схеме
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к информационным системам "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания программного обеспечения, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Сущность системного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. Таким образом, данная модель основным достоинством имеет системность разработки, а основные недостатки - медленно и дорого.
Спиральная модель: Для преодоления перечисленных проблем была предложена спиральная модель жизненного цикла (рис. 3), делающая упор на начальные этапы жизненного цикла: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. На рисунке № 10 представлено графическое изображение спиральной модели жизненного цикла ИС.
Рис 10. Спиральная модель ЖЦ ИС
Наиболее оптимально считаю спиральную модель, так как в ней были учтены все недостатки каскадной и задачной модели. В рамках доработки уже существующей ИС частенько возникают новые замечания от пользователей которые можно реализовать на новом витке спиральное модели.