72
Track), "упрощенный подход", подходящий в случае не больших проектов и
способности скорее прототипировать приложения.
Rational Unified Process (RUP) показывает итеративную модель
создания, эта модель состоит из 4 фаз: начало, изучение, возведение и
внедрение. Любая фаза имеет возможность разбиться на этапы (итерации), в
итоге выпускается версия для внутреннего или же внешнего применения.
Применение 4-х фаз - именуется циклом разработки, любой цикл
завершается генерацией версии системы. Если после этого деятельность над
проектом не заканчивается, то приобретенный продукт продолжает
совершенствоваться и вновь минует те же фазы. Сущность работы в рамках
RUP заключается в разработке и сопровождении моделей, а еще бумажных
документов, в следствии этого, данный процесс привязан к применению
определенных средств моделирования (UML), и так же определенной
технологии создания и разработки.
Microsoft Solution Framework (MSF) аналогична с RUP, тоже
подразумевает 4 фазы: исследование, проектирование, разработка,
стабилизация, считается итерационной, подразумевает внедрение объектно-
ориентированного моделирования. MSF в сопоставлении с RUP, в большей
степени, нацелена на создание бизнес-приложений.
Extreme Programming (XP). Экстремальное программирование
считается наиболее свежим между рассмотренных методов. Создана в 1995 г.
В базе метода командная деятельность, действенная коммуникация между
заказчиком и исполнителем в течение всего плана по созданию ИС, а
разработка проводится с внедрением поочередно дорабатываемых
прототипов.
Ведущими аспектами для выбора стандарта ЖЦ станут:
актуальность и современность применяемых способов контроля
разработки
разработка в итерационном режиме с вероятностью держать под
контролем риски.
73
выполнения самого проекта на каких то контрольных точках,
отсутствие добавочных требований по моделированию процесса разработки
и внедрения.
Резюмируя описание стандартов выше, итерационными из них
считаются четыре стандарта: MSF, RUP, COBIT, XP .
Стандарт COBIT мне не подходит, потому что главной целью его
применения является проведения аудита и стратегического планирования ИС
и IT инфраструктуры в целом.
Стандарт XP мне также не подходит, он не имеет полноценных этапов
ЖЦ, таких как выработка концепции, планирование, создание, стабилизация,
внедрение.
Следовательно, перед выбором стоит Rup и MSF. Оба стандарта
считаются юными и поддерживающими все свежие технологии
продуктивной разработки и контроля их выполнения
По ней возможно судить, собственно что Rational Unified Process
считается отлично сбалансированным решением для средних по объемам
коллективов создателей, работающих с использованием продуктов и
технологий фирмы Rational. Сопровождение разработки системы и самой
системы регламентируется методологией RUP, впрочем предоставленная
разработка довольно сильно нацелена на внутрифирменные
инструментальные способы.
Extreme Programming отлично применяется в проектных группах не
большого объема и для не больших систем с зачастую изменяемыми
требованиями. Главный минус XP - сопровождение. В случае текучки
сотрудников в коллективе создателей важная доля проектной информации
может быть утеряна по причине буквально отсутствующей документации. В
таблице ниже представлены главные характеристики стандартов
Жизненного цикла ИС.
74
Технологии MSF, RUP и XP
Технология
Оптимальная
команда
Соответствие
стандартам
Допустимые
технологии и
инструменты
Удобство
модификации и
сопровождения
Rational
Unified
Process
10 - 40 чел.
стандарты
Rational
UML и
продукты
Rational
Удобно (RUP)
Microsoft
Solutions
Framework
3 - 20 чел.
адаптируема
любые
Удобно
(MSF+MOF)
XP
2 - 10 чел.
стандарты
отсутствуют
любые
Сложно
(зависимость от
конкретных
участников
коллектива)
Таблица 5. Главные характеристики стандартов Жизненного цикла ИС.
Microsoft Solutions Framework считается более равновесной
технологией, направленной на проектные группы небольших и средних
объемов. MSF не накладывает практически никаких ограничений на
применяемы инструментарий и имеет рекомендации весьма общего
характера. Впрочем, данные рекомендации имеют все шансы на применение
для построения определенного процесса, соответственного необходимостям
коллектива создателей.
Наш проект считается не большим и содержит в себе трех человек и
этапы разработки и испытания ведутся в среде разработки Python. Не считая
того главным плюсом MSF считается итерационная модель в одно и тоже
время с уточняющими вехами (аналог каскадной модели). Следовательно,
75
осуществление MSF пробовала совместить каскадную и итерационную
модель создания и внедрения ПО.
По раскрытым выше превосходствам, я выбрал стандарт MSF как более
гибкий и благоприятный для реализации моего проекта.
Одним из плюсов данного стандарта считается вероятность управлять в
одно и тоже время и проектом созданием приложения и внедрением
инфраструктуры.
В итоге, в идеологии MSF есть пять стадий жизненного цикла ИС, эти
стадии в понятии MSF именуют фазами. Первая из них это Фаза разработки
концепции.
Задача этой фазы в создании и объединении проектной группы на
основании выработки общего видения. Проектная группа обязана строго
представить себе, чего она хочет делать для клиента и вывести свои задачи.
Заказчиком в моем случае выступаем мы лично и целый холдинг
единовременно.
В идеологии MSF команда проекта распределяется на шесть членов,
каждый из них содержит собственную роль в проекте, наделён прямыми
обязанностями и содержит собственную зону ответственности. Данные роли
MSF именовал кластерами, за любым может быть закреплён не один человек,
так вот они: Управление продуктом, Управление программой, Создание,
Удовлетворение клиента, Проверка, Управление выпуском. В любой фазе,
для любого серьезного лица, закреплённого за кластером, закрепляются
конкретные цели.
Цели в фазе выработки концепций.
1. Управление продуктом регулирует:
концептуальный и закономерный дизайн;
активная спецификация;
сводный план и сводный календарный график плана;
бюджет.
2. Управление программой создают:
76
цели дизайна,
концепцию заключения,
структуру плана.
3. Разработка отвечает за:
оценку технологий;
закономерный и физический дизайн;
план и календарный график разработки;
смета разработки.
4. Удовлетворения клиента рассматривает:
сценарии/примеры применения,
пользовательские запросы,
запросы локализации и общедоступности (accessibility);
пользовательская документация/план обучения/график
испытания удобства эксплуатации;
изучение.
5. Испытание создает:
оценку дизайна;
запросы анализа;
план и календарный график испытания.
6. Управление выпуском делает следующее:
оценка дизайна;
эксплуатационные требования;
план и календарный график плотного и конечного внедрения.
К огорчения или к счастью, в рамках планирования и внедрения
нашего плана силами работников ИТ департамента, брать шеть и больше
человек для фоновой задачи, бюджет которого ограничен только премией в
высшей степени бессмысленно. Я совместил задачи кластеров и создал из
них три серьезных человека, они и буду являться командой проекта.
77
1) Разработчик программного обеспечения, на которого возложено
надлежащее:
управление программой,
создание
удовлетворение пользователей
2) Менеджер проекта, внедряет и тестирует, на него возложено
надлежащее:
управление продуктом,
испытание
управление выпуском.
Выходной информацией и итогами представленной Фазы считается
подбор претендентов и назначение более оптимальны из них к требуемым
задачам на применение 2-х ролей, то есть создание команды, не обращая
внимания на то, в нее входит всего лишь 2 человека. В моем проекте на
представленном этапе будут определены состав и роли членов команды.
Разработана смета по времени и планирование бюджета этого плана.
Грядущим этапом ЖХ ИС будет Фаза планирования. Ведущей её целью
считается создание планов проекта. В нее входят подготовка проектной
группой активной спецификации, разработка дизайнов, подготовка планов,
оценка проектных издержек и сроков разработки всевозможных элементов
проекта.
Процесс проектирования – это регулярный метод продвижения от
абстрактных концепций к определенным техническим составным частям.
Итогами фазы планирования считаются: активная спецификация,
Описание вероятных рисков, Сводный план и сводный календарный график
плана, развернутые Среды разработки и испытания.
От разработчика программного обеспечения на представленном этапе
потребуется обзор и выбор языка программирования, на котором будет
реализовываться заключение, плюс календарный проект по срокам и
графикам создания. Менеджер проекта на данном этапе продумывает всю
78
архитектуру ИС, охватывая взаимодействие почтового сервера, веб-сервера,
Субд, деятельность пользователей и инженеров в грядущей системе.
Грядущим этапом идет Фаза разработки. На данной фазе проектная
группа фокусируется на разработке составляющего заключения. Впрочем,
кое-какая доля этой работы имеет возможность длиться еще и на фазе
стабилизации, в случае, если эта необходимость появилась в процессе
испытания. Эта фаза еще подразумевает под собой создание
инфраструктуры.
Нужно направить внимание, собственно что, активность проектной
команды на представленном этапе не входит в рамки написанного
разработчиками кода – любые ролевые кластеры принимают инициативную
роль в создании и анализе решения.
Итогами фазы создания считаются: Исходный и исполнимый код
приложений, Скрипты установки и конфигурирования, Конечное описание
функционала создаваемого заключения, Материалы поддержки заключения,
сценарии тестов. В моем случае от разработчика программного обеспечения
на представленном этапе потребуется показать программу заказчик для
работы Инженеров ИТ и написание абсолютной документации к ней. От
начальника проекта потребуется сделать работоспособную среду, раскрытую
в предыдущем этапе.
Грядущим этапом ЖЦ идёт Фаза стабилизации
При фазе стабилизации выполняется анализ созданного решения. В
таком случае внимание концентрируется на его применение в ближайшей к
реальности модели производственной среды. Проектная группа занимается
приоритезацией и уничтожением ошибок, а еще подготовкой заключения к
выходу.
Чаще всего, на начальной стадии фазы стабилизации скорость
выявления промахов командой испытания превосходит скорость, с которой
эти промахи имеют все шансы устраняться командой создателей. Нельзя
предугадать, сколько промахов выявится и сколько по времени потребуется
79
на их уничтожение. Впрочем, есть 2 статистических признака,
способствующих проектной группе оценить степень стабилизации решения.
Это точка конвергенции. В точке конвергенции становится заметен
немаловажный прогресс в удалении промахов, т.е. скорость уничтожения
промахов начинает превосходить скорость их нахождения. Потому что
численность найденных, но не устраненных промахов имеет возможность
колебаться в том числе и впоследствии того, когда оно начало устранять,
конвергенция имеет возможность исследоваться больше как тенденция, чем
фиксированный момент во времени. Следом за данной вехой численность
активных промахов будет убывать, до самой точки достижения нулевой
отметки. Точка конвергенции выделяет проектной группе возможность
понять, что процесс испытания приближается к завершению.
Итогами фазы стабилизации считаются:
1. Конечный продукт (golden release),
2. Документация выпуска (release notes),
3. Материалы помощи решения,
4. Итоги и инструментарий испытания,
5. Исходный и исполнимый код приложений,
6. Проектная документация.
В нашем проекте на представленном этапе разработчиком
программного обеспечения корректируются ошибки в разработанной им
программе, компилируется версия релиз кандидат и впоследствии отсутствия
критичных ошибок по всем веткам перечня возможностей программы
создается окончательная сборка исполняемого кода, вместе с этим
дополняется документация к деятельности с программой. Управляющим
проекта на данном этапе набирается группу тестирования из двух или трех
инженеров, которые воспользуются данной программой и проанализируют
все ветки перечня возможностей по разработанным раньше сценариям и
создадут дополнения, которые возможно будет воплотить в надлежащей
версии.
80
Грядущим этапом станет Фаза внедрения
На этой фазе проектная группа вводит технологии и элементы
решения, выравнивает внедренное решение, отдает работу персоналу
поддержки и сопровождения и получает от клиента окончательное
поощрение итогов проекта. По окончанию внедрения проектная группа
проводят тестирование выполненной работы и удовлетворенности клиента.
На этой фазе по ходу перенесения компонент решения из среды
испытания в производственную среду могут длиться меры по стабилизации
заключения.
Итоги фазы внедрения подразумевают:
Информационные системы эксплуатации и помощи,
Процедуры и процессы,
Базы знаний, доклады, журналы протоколов,
Массивы данных и программный код, созданные во время
проекта.
Отчет об окончании проекта,
Показатели удовлетворенности клиента и покупателей,
Описание дальнейших шагов.
На этом этапе начальник окончательно вводит систему в
использование, уточняет программный продукт на компьютерах Инженеров
ИТ, распечатывает им руководство по работе с ней или же проводит
обучение по её методу работы. Дальше Пользователем отправляется свежий
регламент работы ИТ отдела и информацию о новой логике обработки
заказов с просьбой за неделю ответить об увиденных изменениях в
обслуживании службой ИТ.
Внедрение считается совокупным мнением и для него есть различные
стратегии реализации, которые находятся в зависимости от срока
выполнения и свойства ИС, полученной на выходе. Есть 4 главные стратегии
внедрения системы:
81
Параллельная стратегия – когда, в одно и то же время работают
старая и новая система, затем их выходные документы сопоставляются. В
случае если они согласуются долго, выполняется переход на другую систему.
"Скачок" - это быстрый переход от ручной системы к новой без
добавочных проверок и с абсолютным отказом от старой системы.
"Пилотный проект" это более часто применяемая стратегия.
Данная стратегия "скачка", но применяемая к определенному количеству
процессов. Область использования стратегии - маленький участок
функционирования. Подобный подход уменьшает риск и более надежен.
"Узкое место" - это небольшая доля производственного процесса.
При применении подхода "узкое место" план внедрения производится лишь
для "узкого места" и для людей, трудящихся в нем.
В этом дипломе будет использоваться стратегия “Пилотный проект”. Я
буду проводить абсолютный переход к автоматической системе для
процессов регистрации и обработки заказов. Областью использования
внедрения станет отдел горячей линии, состоящий из пяти операторов.
Подобный расклад не затронет работу всей ИС, лишь автоматизирует
рутинную часть. Надежность этого внедрения обоснована строгим
соотношением порядка регистрации и обработки заказа регламенту горячей
линии.
Дальше начинается период эксплуатации созданного программного
продукта. В согласовании с написанной инструкцией к использованию,
работу этой программы нужно отслеживать программы каждые два, четыре
часа, так как программа может остановиться или же обработать не все
письма, отправленные на почтовый ящик горячей линии из-за недоступности
логики обработки представленного вида заявки. В данном случае письмо
возвратится на почтовый ящик горячей линии с отметкой в теме сообщения
"Не обработано". Представленного рода риск следует разбирать один раз в
месяц и принимать решение о надобности доработки логики программы,
собственно что в рамках поддержки программы первые 6 месяцев