35
Глава 2. Проектная часть
2.1 Разработка проекта автоматизации
Моделью жизненного цикла является структура, которая содержит в себе
процессы, действия и задачи, исполняющаяся в ходе разработки,
функционирования и сопровождения программного продукта в течение всего
существования системы, от определения требований до завершения ее
использования.
В современном мире есть немного моделей и стандартов, в той или иной
степени регламентирующих жизненный цикл, многие из которых имеют
отношения к заказному программному обеспечению и кроме непосредственно
ЖЦ регламентируют также и процессы разработки:
На автоматические системы распространяется и устанавливает стадии и
этапы их создания. В стандарте, не считая этого, должно быть описание
содержания работ на каждой стадии. Стадии и этапы работы, которые
закреплены в установленном стандарте, в большинстве случаев соответствуют
каскадной модели жизненного цикла.
Стандартом на процессы и организацию жизненного цикла является
ISO/IEC 12207:1995. Данный стандарт распространяется на все виды заказного
ПО. В стандарте отсутствуют описания фаз, стадий этапов.
Custom Development по разработке прикладных информационных систем
под заказ является конкретным материалом, который разработан до уровня
заготовок проектных документов, которые в свою очередь рассчитаны на
применение в проектах с использованием Oracle.
Степень адаптивности Custom Development ограничивают тремя
моделями жизненного цикла: "классическая", "быстрая разработка",
"облегченный подход", которого рекомендуют в случае малых проектов и
способности быстро реализовать приложения.
Rational Unified Process имеет итеративную модель разработки, которая
36
включает в себя четыре фазы: начало, исследование, построение и внедрение.
Любая из этих фаз разбивается на этапы, в результате чего создается версия для
внутреннего или внешнего пользования.
Прохождение через четыре главные фазы называется циклом разработки.
Каждый из этих циклов имеет завершение генерацией версии системы. В случае
если после этого работа над проектом продолжается, то полученный продукт
продолжает развиваться и заново проходит те же фазы.
Смысл работы в рамках Rational Unified Process заключается в создание и
сопровождение моделей, а не бумажных документов, в связи с этим данный
процесс привязан к использованию определенных средств моделирования
(UML), а также определенной технологии проектирования и разработки.
Microsoft Solution Framework имеет сходства с Rational Unified Process.
Она так же имеет четыре фазы: анализ, проектирование, разработка,
стабилизация, которая является итерационной, предполагает использование
объектно-ориентированного моделирования. Если сравнивать Microsoft Solution
Framework с Rational Unified Process, то можно сказать, что она в большей
степени ориентируется на создание бизнес-приложений.
Extreme Programming является экстремальным программированием среди
рассматриваемых методологий является самым новым. Extreme Programming был
создан в 1996 году. В основе него лежит командная работа, качественная связь
между заказчиком и исполнителем в течение всего проекта по разработке
информационной системы, а разработка ведется с применением последовательно
дорабатываемых прототипов.
К главным пунктам для выбора стандарта жизненного цикла относятся:
—актуальность и современность применяемых методик контроля
разработки;
—разработка в итерационном режиме со способностью уметь
контролировать риски;
—исполнения проекта на определенных контрольных точках;
—отсутствие наличия дополнительных требований по моделированию
37
процесса разработки и внедрения.
Собрав все описание стандартов выше похожими из них являются четыре
стандарта: MSF, RUP, COBIT, XP .
Стандарт COBIT нам не подходит, так как главной целью его применения
“является проведения аудита и стратегического планирования информационных
систем и IT инфраструктуры в общем”.
Стандарт Extreme Programming также является не подходящим
стандартом, так как в нем отсутствуют полноценные этапы жизненного цикла,
такие как выработка концепции, разработка, планирование, стабилизация,
внедрение.
В соответствие с этим, остается выбор между Rational Unified Process и
Microsoft Solution Framework. Данные стандарты являются одними из самых
новых и которые поддерживают абсолютно все современные технологии
продуктивной разработки и контроля их исполнения.
Главные особенности MSF, RUP и XP предоставлены в таблице 5. В
данной таблице можно увидеть, что стандарт Rational Unified Processм является
хорошим сбалансированным решением для применения в средних по размерам
коллективов разработчиков, которые работают с использованием продуктов и
технологий компании Rational.
Обслуживание разработки системы и самой системы регламентируется
методологией Rational Unified Process, однако эта технология очень сильно
направлена на внутрифирменные инструментальные средства.
Методология Extreme Programming отлично подходит для проектных
групп небольшого размера и для малых систем с часто меняющимися
требованиями.
Главной проблемой Extreme Programming является обслуживание
системы. Во время текучки работников в коллективе разработчиков большая
часть проектной информации в следствие может быть утеряна практически из-за
полного отсутствия документации. Таблица 5 показывает главные показатели
стандартов жизненного цикла информационной системы.
38
Таблица 5
Технологии 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 является наиболее сбалансированной
технологии, которая ориентирована на малые и средние проектные группы.
Система Microsoft Solution Framework не имеет ограничений на используемые
инструменты и имеет рекомендации весьма общего характера.
В связи с этим, рекомендации могут быть использованы для создания
определенного процесса, который будет соответствовать нуждам коллектива
разработчиков.
Наш проект является малым и включает в себя около двух человек и
стадии разработки и тестирования проводятся в области создания Python.
Помимо этого, главным плюсом Microsoft Solution Framework является
итерационная модель, которая одновременно уточняет подобные сервисы
каскадной модели. В соответствие с этим, реализация Microsoft Solution
Framework попыталась соединить в себе, как каскадную, так и итерационную
модель создания и внедрения программного обеспечения.
По вышеописанным преимуществам стандарта, был выбран стандарт
Microsoft Solution Framework, как в наибольшей степени гибкий и удобный, в
сравнение с остальными, для создания моего проекта.
Одним из главных плюсов Microsoft Solution Framework является
способность управления в одно и то же время, как и проектом разработкой
39
приложения, так и внедрением инфраструктуры.
Стандарт Microsoft Solution Framework имеет пять степеней жизненного
цикла информационной системы, которые в MSF принято называть фазами.
Первой степенью Microsoft Solution Framework является Фаза выработки
концепции.
Целью данной фазы является создание и сплочение проектной группы на
базе выработки общего видения. Проектная группа четко должна продумать, что
она в действительности хочет сделать для заказчика и сформулировать
поставленную цель. В нашем случае мы сами являемся Заказчиками.
В понимание Microsoft Solution Framework, команда проекта должна
разделится на шесть участников, у каждого из них присутствует своя роль в
проекте, каждый обладает своими обязанностями и имеет свою зону
ответственности.
Данные роли Microsoft Solution Framework называются кластерами, за
каждым из них может быть закреплено несколько человек. К кластерам
относятся: управление продуктом, управление программой, разработка,
удовлетворение потребителя, тестирование, управление выпуском. В каждой
фазе для каждого назначенного ответственного лица, который закреплен за
определенным кластером прикрепляются определённые задачи.
К задачам в фазе выработки концепций относятся:
— управление продуктом — регулирует концептуальный и логический
дизайн, функциональную спецификацию, сводный план и сводный календарный
график проекта, бюджет;
— управление программой — формирует цели дизайна, концепцию
решения, структуру проекта;
— разработка — отвечает за оценку технологий; логический и
физический дизайн; план и календарный график разработки; смета разработки;
— удовлетворения потребителя — рассматривает сценарии или примеры
использования, пользовательские требования, требования локализации и
общедоступности, пользовательскую документацию, план обучения, график
40
тестирования удобства эксплуатации, обучение;
— тестирование формирует оценку дизайна, требования тестирования,
план и календарный график тестирования;
— управление выпуском — выполняет функции оценки дизайна,
эксплуатационные требования, план и календарный график пилотного и
окончательного внедрения.
В рамках создания и внедрения данного проекта с помощью сотрудников
ИТ отдела, использовать более шести человек для фоновой задачи, бюджет
ограничивающийся всего лишь премией является вполне невыгодным.
Объединение задачей кластеров и процесс формирования из них трех
ответственных лиц, которое в дальнейшем называется командой было моим
решением.
На программиста были возложены следующие кластеры:
— управление программой;
— разработка;
— удовлетворение пользователей.
На менеджера проекта были возложен такие кластеры как:
— управление продуктом;
— тестирование;
— управление выпуском.
Полученной информацией и результатами данной фазы стал подбор
кандидатов и назначение самых подходящих из них к нужным задачам на
выполнение двух ролей, то есть создание команды, несмотря на то, что она
состоит всего из двух человек.
В данном проекте на этой стадии будут созданы составы и роли
участников, будет создана смета по времени и планирование бюджета проекта.
Другим этапом жизненного цикла информационной системы является
Фаза планирования. Главной целью данного этапа является составление планов
проекта.
Фаза включает в себя подготовку проектной группой функциональной
41
спецификации, разработку дизайнов, подготовку рабочих планов, оценку
проектных расходов и сроков разработки различных предметов для составления
проекта.
Процессом проектирования называется систематический способ
продвижения от абстрактных концепций к определенным техническим деталям.
Описание всех обязанностей кластеров содержаться в Приложении таблице №3.
Конечными результатами фазы планирования являются: описание
возможных рисков, функциональная спецификация, сводный план и сводный
календарный график проекта, развернутые среды разработки и тестирования.
Программист на данной стадии должен сделать обзор и выбрать язык
программирования, с помощью которого будет реализовано решение, также
создать календарный план по срокам и графикам разработки.
Менеджер проекта на данной стадии обязан полностью тщательно
продумать всю архитектуру ИС, которая будет включать взаимодействие
почтового сервера, веб сервера, СУБД, работу пользователей в будущей системе.
Следующим этапом в разработке проекта является Фаза разработки. На
данной фазе проектная группа фокусируется на создании компонента решения,
которая будет включать в себя, как документацию, так и программный код.
Но несмотря на это, определенная часть этой работы может также
продолжаться на фазе стабилизации, если в этом есть необходимость,
выявленная в процессе тестирования. В данной фазе также присутствует
создание инфраструктуры.
Большое внимание необходимо обратить на то, что деятельность команды
по созданию проекта, на данной стадии не ограничивается созданием
разработчиками кода, все ролевые кластеры принимают активное участие в
создании и тестировании решения.
Таблица 5 включает в себя ведущие задачи и сферы ответственности
каждого из ролевых кластеров проектной группы во время фазы разработки.
К итогам фазы разработки обычно относят: исходный и исполнимый код
приложений, скрипты установки и конфигурирования, окончательное описание
42
функционала разрабатываемого решения, материалы поддержки решения,
сценарии тестов.
В процессе создание нашего проекта от программиста на данной стадии
требуется предоставление программы для клиента для работы инженеров ИТ и
составление к ней полного пакета документации. Руководителем данного
проекта должна быть создана работоспособная среду, которая была описана в
прошлом этапе.
Следующим этапом жизненного цикла является Фаза стабилизации.
Во время данной стабилизации производится тестирование уже ранее
созданного решения. При этом внимание фокусируется на его работе в
реалистичной модели производственной среды. Проектная группа занимается
установкой приоритетов и устранением ошибок, а также подготовкой решения к
выпуску.
В начале фазы стабилизации скорость нахождения ошибок командой
тестирования обычно всегда превосходит скорость, с которой эти ошибки могут
исчезать с помощью командой разработчиков.
Сколько ошибок будет найдено с помощью команды тестирования и как
много времени займет их устранение обычно невозможно знать наперед. Но
несмотря на это имеются два статистических признака, которые помогают
проектной группе точно оценивать уровень стабилизации решения.
Точка конвергенции является этим признаком. Данная точка указывает на
существенный прогресс в устранении ошибок, то есть скорость устранения
ошибок начинает превосходить скорость обнаружения ошибок.
Так как количество найденных ошибок, которые еще не устранены может
колебаться даже после того, как оно начало убывать, конвергенция может
рассматриваться скорее, как тенденция, нежели как фиксированный момент во
времени.
Вслед за этой вехой количество активных ошибок должно продолжать
уменьшаться, вплоть до полного исчезновения. Точка конвергенции дает команде
возможность понять, что процесс тестирования подходит к концу.
43
В таблице 5 описываются главные задачи и сферы ответственности
каждого из ролевых кластеров проектной группы во время фазы стабилизации.
Результатами фазы стабилизации являются: окончательный продукт,
документация выпуска, материалы поддержки решения, результаты и
инструментарий тестирования, исходный и исполнимый код приложений,
проектная документация.
В создаваемом мною проекте на данной стадии, программистом
редактируются ошибки в создаваемой им программе, компилируется версия
релиз кандидат и после отсутствия наличия в проекте критических ошибок по
всем веткам функционала программы выпускается конечная сборка
исполняемого кода, параллельно с этим дополняется документация к работе с
программой.
Руководитель проекта на данной стадии разработки проекта создает
группу тестирования из двух или трех инженеров, которые будут в дальнейшем
использовать эту программу каждый день и тестировать все ветки функционала
по разработанным ранее сценариям и создает дополнения, которые можно будет
реализовать в следующей версии.
Следующей стадией в создание проекта является Фаза внедрения.
Во время использования данной фазы проектная группа вводит
технологии и компоненты решения, устанавливает внедренное решение,
передает работу персоналу поддержки и сопровождения и получает от заказчика
заключительное разрешение результатов проекта. По окончанию ввода
проектная группа делает анализ выполненной работы и удовлетворенности
заказчика.
Во время Фазы внедрения по ходу переноса компонент решения из среды
тестирования в производственную среду могут продолжаться меры по
установлению решения. В таблице 6 можно увидеть главные задачи и сферы
ответственности каждого из ролевых кластеров проектной группы во время фазы
ввода данного проекта.
Результатами фазы внедрения являются информационные системы
44
эксплуатации и поддержки, процедуры и процессы, базы знаний, отчеты,
журналы протоколов, массивы данных и программный код, которые были
разработаны во время проекта, отчет о завершении проекта, показатели
удовлетворенности заказчика и потребителей, описание последующих шагов.
На данной стадии руководитель окончательно вводит систему в
использование, устанавливает программный продукт на компьютерах инженеров
информационно-технического отдела, распечатывает им инструкцию по работе с
системой или отправляет на обучение по её алгоритму работы.
Затем пользователем отправляется новый регламент работы
информационно-технического отдела, и информация о новой логике обработки
заявок с просьбой в течение недели ответить о замеченных изменениях в
обслуживании службой информационно-технического отдела.
Ввод системы является основным понятием и для него существуют
разные стратегии реализации, которые напрямую зависят от срока исполнения и
качества информационной системы, которая получается в результате.
Существуют четыре главные стратегии ввода системы в эксплуатацию:
— Параллельной стратегией является одновременная работа старая и
новая системы, и их выходные документы сравнивают. Если они имеют схожесть
длительное время, осуществляется переход на новую систему.
— "Скачок", так называется резкий переход от старой системы к новой
без дополнительных проверок и с полным отказом от старой системы.
— "Пилотный проект", так называется более часто используемая
стратегия.
"Пилотным проектом" является тактика "скачка", но её можно применять
лишь к определенному числу процессов. Областью использования этой
стратегии является маленький участок деятельности. Такой подход понижает
риск и является более надежным.
— "Узкое место" – это так называемая самая малая часть всего
производственного процесса. При использовании данного подхода план ввода
системы используется только для "узкого места" и для людей, которые работают