38
Rational Unified Process (RUP) - это методология разработки
программного обеспечения, созданная и распространяемая
корпорацией Rational Software. Она описывает упорядоченный
подход к распределению задач и обязанностей в организации-
разработчике.
Microsoft Solution Framework (MSF) это - набор принципов и правил
деятельности, в некоторой степени ориентированный на проекты
разработки программного обеспечения и развития информационной
инфраструктуры.
Extreme Programming (XP). методология содержит совершенно иные
базовые принципы, нежели RUP. Основными чертами являются
определение точных кратковременных планов (как правило,
недельных), постоянное перепланирование, тесное общение с
заказчиком. Эта методология больше подходит для
полуисследовательских и инновационных проектов.
Главными критериями выбора стандарта для жизн енного цикла будут
современность и актуальность используемых методов управления
разработкой, разработка в итерат ивном режиме с возможностью контроля
рисков и самого проекта в опре деленных контрольных точках, а также
отсутствие дополн ительных требований для модел ирование процесса
разработки и внедрения.
Стандарт XP нам тоже не подходит, так как он не содержит
полноценных этапов ЖЦ, таких как выработка концепции, планирование,
разработка, стабилизация, внедрение.
Следовательно, перед выбором стоит RUP и MSF. Обе методологии
молоды и поддерживают все новые технологии для продуктивного
развития и мониторинга их внедрения.
39
В таблице 10 представлены основные показатели стандартов
Жизненного цикла ИС.
Extreme Programming хорошо подходит для небольших групп
разработчиков и небольших систем с часто меняющимися требованиями.
Основная проблема с XP - это обслуживание. В случае текучести кадров в
команде разработчиков значительная часть информации о проекте может
быть потеряна из-за практически отсутствия документации.
Таблица 10
Технологии MSF, RUP и XP
Технология
Оптимальная
команда
Соответствие
стандартам
Допустимые
технологии
и
инструменты
Удобство
модификации и
сопровождения
RUP
10 - 40 чел.
стандарты
Rational
UML и
продукты
Rational
Удобно (RUP)
MSF
3 - 20 чел.
адаптируема
любые
Удобно (MSF и
MOF)
XP
2 - 10 чел.
стандарты
отсутствуют
любые
Сложно
(зависимость от
конкретных
участников
коллектива)
Microsoft Solutions Framework является наибо лее сбалансированной
технологией, ориентированной на проектные группы малых и средних
размеров. MSF не накладывает никаких ограничений на используемый
инструментарий и со держит рекомендации весьма общего характера.
Наш проект является небольшим, включает в себя 3 чело века и
этапы разработки и тестирования про водятся в среде разработки Xcode.
Кроме того о сновным преимущество м MSF является итерационная
модель одно временно с уточняющими вехами. Таким образом, реализация
MSF по пыталась объединить каскадную и итерационную
модельразрабо тки и внедрения ПО.
40
По оп исанным выше преимуществам, мною был выбран стандарт
MSF как наиболее гибкий и удобный для реализации моего проекта.
Одним из преимуществ этого стандарта является возмож ность управлять
одновременно и проектом разработкой приложения и внедрением
инфраструктуры. В идеологии MSF существует 5 стадий жизнен ного
цикла ИС, которые в понятии MSF называют фазами. Пер вый из них это
Фаза выработки концепции.
Цель этого этапа - создать и сплотить команду проекта,
основанную на выработке общего видения. Команда проекта должна четко
представлять, что она хочет сделать для клиента, и сформулировать свою
цель. Клиент в нашем случае - это мы сами и весь холдинг одновременно.
В идеологии MSF команда проекта разделена на 6 участников, каждый из
которых играет свою роль в проекте, наделен обязанностями и имеет свою
зону ответственности. MSF назвала эти роли кластерами, каждый из
которых может быть назначен более чем одному человеку, поэтому они
здесь: Управление продуктами, Управление программами, Разработка,
Удовлетворенность клиентов, Тестирование, Управление релизами. На
каждом этапе каждому ответственному лицу, назначенному в кластер,
назначаются определенные задачи. Вот задачи, поставленные на этапе
разработки концепции:
Управление продуктом - управляет концептуальным и логическим
дизайном, функциональной спецификацией, сводным планом и
сводным графиком проекта.
Управление программой - формирует цели проектирования,
концепцию решения, структуру проекта.
Разработка - отвечает за оценку технологий, логический и
физический дизайн, план и график разработки.
41
Удовлетворения потребителя - рассматривает сценарии/примеры
использования, требования пользователей, требования к
локализации и общедоступности, пользовательская
документация/план обучения/график тестирования удобства
эксплуатации, обучение.
Тестирования - формирует оценку проекта, требования
тестированию, план и график тестирования.
Управление релизом - выполняет функции оценки проекта,
эксплуатационные требования, плана и графика пилотного и
окончательного внедрения.
Я объединил задачи кластеров и сформировал из них 3
ответственных лица, они же и есть команда проекта
1) Программисты со следующими кластерами:
Программный менеджмент
Разработка
Удовлетворение пользователей
2) Менеджер проекта, он реализатор, он тестировщик, у него есть
следующие кластеры:
Управление продуктом
Тестирование
Управление релизом
Результатом этого этапа является отбор кандидатов и назначение
наиболее подходящих из них для выполнения требуемых задач для
выполнения двух ролей, то есть формирования команды, несмотря на то,
что она состоит только из двух людей. В нашем проекте на данном этапе
будет определен состав и роли участников. Будет выполнена оценка
времени и бюджетное планирование для этого проекта.
42
Следующим этапом СК ЛЦ является этап планирования. Его
главная цель - составить планы проекта. Он включает в себя подготовку
командой проекта функциональной спецификации, разработку проектов,
подготовку рабочих планов, оценку стоимости проекта и сроков
разработки различных компонентов проекта.
Следующим этапом следует этап разработки. На этапе разработки
проектная команда проекта фокусируется на создании компонентов
решения. Тем не менее, некоторые из этих работ также могут
продолжаться на этапе стабилизации, если такая необходимость будет
выявлена в процессе тестирования. Этот этап также включает развитие
инфраструктуры.
Следует отметить, что деятельность команды проекта на этом этапе
не ограничивается написанием кода разработчиками - все ролевые
кластеры принимают активное участие в создании и тестировании
решения.
Следующим этапом ЖЦ является этап стабилизации. На этапе
стабилизации разработанное решение испытывается. В то же время
внимание сосредоточено на его работе в реалистичной модели
производственной среды.
Как правило в начале этапа стаби лизации скорость нахождения
ошибок тестировщиками превосходит скорость, с которой эти ошибки
могут устраняться мною. Нево зможно предсказать, сколько ошибок будет
найдено и как много времени понадобится на их устранение. Однако
существует два статис тических признака, помогающих оценить уровень
стабилизации решения. Это точка конвер генции. В точке конвергенции
становится, заметен сущест венный прогресс в устранении ошибок, то есть
скорость устра нения ошибок начинает превосходить скорость их
обнаружения. Поскольку количество найденных, но не устраненных
ошибок может колебаться даже после того, как оно начало убывать,
43
конвергенция может рассматр иваться скорее как тенденция, нежели как
фиксир ованный момент во времени. Вслед за этой вехой количество
активных ошибок должно продолжать убывать, вплоть до точки
достижения нуля. Точка конв ергенции дает проектной группе
возможность понять, что процесс тестир ования близится к концу.
Таблица 11 описывает основные задачи и сферы ответственности
каждого из ролевых кластеров проектной группы во время фазы
стабилизации.
Таблица 11
Ответственность участников в фазе стабилизации.
Ролевой кластер
Фокус
Управление продуктом
Ожидания заказчика
Управление программой
Управление функциональной
спецификацией, мониторинг проекта,
доработка планов
Разработка
Разработка программного кода и
инфраструктуры, документирование
конфигураций
Удовлетворение потребителя
Обучение, доработка плана
обучения, тестирование удобства,
графический дизайн
Тестирование
Функциональное тестирование,
выявление проблем, тестирование
документации, доработка плана
тестирования
Управление выпуском
Доработка планов внедрения
(включая пилотное внедрение)
Следующим этапом будет этап внедрение. На этом этапе команда
проекта внедряет технологию и компоненты решения, стабилизирует
внедренное решение, передает работу персоналу поддержки и поддержки
и получает окончательное утверждение результатов проекта от заказчика.
По завершению внедрения проектная команда анализирует выполненную
работу и удовлетворенность клиента.
На этом этапе наряду с переносом компонентов решения из
тестовой среды в производственную среду могут быть приняты меры для
44
стабилизации решения. Таблица 12 описывает основные задачи и сферы
ответственности каждого из ролевых кластеров проектной группы во
время фазы внедрения. На данном этапе Адмистратор окончательно
вводит систему в эксплуатацию, устанавливает приложение на
смартфонах Инженеров ИТ, объясняет основные требования к
тестирования.
Таблица 12
Ответственность участников в фазе разработки.
Ролевой кластер
Фокус
Управление продуктом
Концептуальный дизайн, анализ бизнес-
требований, коммуникационный план
Управление программой
Концептуальный и логический дизайн,
функциональная спецификация, сводный
план и сводный календарный график
проекта
Разработка
Оценка технологий, логический и
физический дизайн, план и календарный
график разработки
Удовлетворение потребителя
Сценарии/примеры использования,
пользовательские требования, требования
локализации и общедоступности,
пользовательская документация/план
обучения/график тестирования удобства
эксплуатации, обучение
Тестирование
Оценка дизайна, требования тестирования,
план и календарный график тестирования
Управление выпуском
Оценка дизайна, эксплуатационные
требования, план и календарный график
пилотного и окончательного внедрения
Существует четыре способа внедрения новой системы:
Параллельная стратегия
"Скачок"
"Пилотный проект"
"Узкое место"
Метод «скачка» предусматривает полный отказ от работающей
системы и моментальный и безусловный переход на новую
информационную систему.
45
Метод «узкого места» является принципиально неприемлемым для
разрабатываемого проекта, так как предполагает внедрение
информационной системы в наиболее критический участок работы
предприятия.
Таким образом, наиболее приемлемыми представляются два
варианта технологии внедрения информационной системы – параллельная
стратегия и стратегия пилотного проекта.
Я выбрал стратегию «Пилотный проект». Мы осуществим полный
переход на автоматизированную систему продажи билетов. Сферой
реализации станет приложение «Лекция». Такой подход не повлияет на
работу всего IP, а только автоматизирует рутинную часть.
Модель жизненного цикла — структура, определяющая
последовательность выполнения и взаимосвязи стадий и этапов,
выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ПО и
специфики условий, в которых последняя создается и функционирует.
Следующая часть будет описывать выбор модели ЖЦ.
В современное время наиболее распространенными моделями являются:
Задачная модель;
Каскадная модель;
Спиральная модель.
При использовании задачной модели разработка происходит
снизу-вверх от индивидуальных целей к общей системе. С таким
подходом теряется целостный подход к разработке, и появляются
проблемы с отдельными частями системы.
При использовании каскадной модели идет разбиение разработки
на несколько четких этапов.
Положительные стороны применения каскадного подхода
заключаются в следующем:
46
1. на каждом этапе формируется полный комплект проектной
документации, который отвечает критериям полноты и
согласованности;
2. этапы работ, выполняемые в логичной последовательности
позволяют планировать соответствующие затраты и сроки
завершения всех работ.
На рисунке 7 представлена схема каскадной модели разработки.
Рисунок 7. Каскадная схема разработки
Каскадная модель. Каждая стадия заканчивается получением
некоторых результатов, которые служат в качестве исходных данных для
следующей стадии. Каждая стадия завершается релизом полного
комплекта докум ентации, достаточной для того, чтобы разработка могла
быть продолжена следующей командой разработчиков. В результате
модель выглядела так, как отображено на рисунке 8.
Преимущества применения каскадной модели в следующем:
на каждом стадии формируется доделанный набор проектной
документации, отвечающий всем критериям полноты и
согласованности;
47
выполняемые в логичной последовательности стадии работ
позволяют планировать сроки завершения всех работ и
соответствующие затраты.
Рисунок 8. Реальный процесс разработки ПО по каскадной
схеме
Недостатки каскадной модели жизненного цикла - риск неверного
изложения требований заказчиком, длительность, сильное запаздывание с
извлечением результатов и большая цена разработки.
В этой модели цикл разработки разбит на небольшие участки.
Каждый участок представляет собой водопадный процесс, в котором
выполняются обзор требований, обновление документации и некоторая
разработка кода. Результат текущей итерации является входным
значением для следующей. При этом программная система создается по
частям с использованием метода прототипирования. На рисунке 9
представлена схема спиральной модели разработки.