63
Технологии 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 - самая сбалансированная технология, которая
сориентирована на небольшие проектные группы и не накладывает ограничений на
инструментарий, включает общие рекомендации. Рекомендации могут быть
использованы с целью построения конкретного процесса, который в полной мере
соответствует потребностям коллектива разработчиков.[23]
Наш проект небольшой, включает 3 человек, и этапы разработки и тестирования
осуществляются в среде Python. Преимущество MSF и в итерационной модели
одновременно с уточняющими вехами. И реализация MSF способна объединить в
себе итерационную и каскадную модели разработки и внедрения программного
обеспечения[18]
Одно из преимуществ стандарта в возможности управлять проектом приложения и
внедрением инфраструктуры.
64
Итак, в идеологии MSF пять разных стадий жизненного цикла ИС, которые
принято называть фазами. Первая из них - это фаза выработки концепции.
Цель этой фазы заключается в создании и сплочении проектной группы на основе
выработки единого видения.
В идеологии MSF команда проекта подразделяется на шесть участников, каждый
из которых имеет свою собственную роль в проекте и наделён определенными
обязанностями, а также имеет свою зону ответственности. Эти роли называются
кластерами, за каждым может быть закреплён не один человек. Вот эти кластеры:
Управление продуктом, Управление программой, Разработка, Удовлетворение
потребителей, Осуществление тестирования, Управление выпуском. В каждой из
фазе для каждого ответственного существуют свои задачи.
Данные задачи ставятся на фазе осуществления выработки концепций. Управление
продуктом регулирует логический и концептуальный дизайн; функциональная
спецификация; сводный план и календарный график проекта; бюджет. Кластер
Разработка отвечает за оценка технологий; физический и логический дизайн; план
и календарный график разработки; смету разработки. Кластер удовлетворения
потребителей рассматривает пользовательские требования, сценарии/примеры
использования, требования общедоступности, план обучения/график тестирования.
Кластер Тестирования формирует оценка дизайна; требования тестирования; план
и график осуществления тестирования. Кластер Управление программой
формирует структуру проекта, концепцию решения, цели дизайна. Кластер
управления производством продукции выполняет функции Оценка дизайна;
эксплуатационные требования; план и график пилотного и окончательного
внедрения.В рамках создания и внедрения моего проекта силами сотрудников
отдела IT, использовать 6 и больше человек для фоновой задачи с небольшим
бюджетом не представляется целесообразным. Я объединил различные задачи
кластеров и сформировал 3 ответственных лица, ь команду данного проекта
1)Программист на которого возлагаются кластеры :
65
● управление программой,
● удовлетворение пользователей;
● разработка.
2) менеджер проекта, внедренец и тестировщик в одном лице, на него возлагаются
такие кластеры:
● управление выпуском;
● управление продуктом,
● осуществление тестирования
Выходной информацией и результатами этой Фазы является подбор подходящих
кандидатов и назначение их для выполнения различных задач, то есть создание
команды, несмотря на то, что она включает в себя всего 2 человек. В нашем
проекте на этом этапе определяются состав и роли каждого из участников
Составляется смета по времени и планирование бюджета проекта.
Следующий этап ЖХ ИС - это Фаза планирования. Основная её цель состоит в
составлении планов проекта. Она включает составление рабочих планов,
разработку дизайна, подготовку проектной группой функциональной
спецификации, оценку проектных затрат и сроков разработки отдельных частей
проекта.
Процесс проектирования представляет собой систематический способ
продвижения, начиная от первоначальных абстрактных концепций и заканчивая
конкретными техническими деталями. Описание обязанностей каждого кластера
дано в Приложении в табл. 3.
Результатами фазы планирования являются следующие результаты: Сводный план
и календарный график проекта, Описание вероятных рисков, функциональная
спецификация, развернутые Среды разработки и проведения тестирования. От
программиста требуется на указанном этапе осуществление обзора и выбор языка
программирования, составление календарного плана по срокам и графикам
осуществления разработки. Менеджер проект продумывает на этом этапе
66
архитектуру ИС, включая в том числе взаимодействие между собой почтового
сервера, веб сервера, Субд, работу инженеров и пользователей в будущей системе.
Следующий этап - Фаза разработки. Проектная группа на этой фазе фокусируется
на создании компонент решения (включая и документацию, и программный код).
Некоторая часть данной работы может продолжаться в том числе на фазе
стабилизации, если такая необходимость появляется в ходе тестирования. Эта фаза
включает в себя также разработку инфраструктуры.
Нужно обратить внимание на то, что активность проектной команды на этом этапе
не ограничена написанием разработчиками кода – различные ролевые кластеры
принимают свое деятельное участие в создании и тестировании принимаемого
решения. В табл. 11 описываются основные задачи и сферы ответственности
каждого ролевого кластера проектной группы во время осуществления разработки.
Таблица дана в Прилож. 1
Результатами фазы разработки являются следующие результаты: Скрипты
установки и конфигурирования, Исходный и исполнимый коды приложений,
Окончательное описание функционала решения, сценарии тестов, материалы
поддержки решения. В нашем конкретном случае от программиста здесь требуется
предоставить программу клиент для работы инженеров, написание документации
для нее. От руководителя требуется создание работоспособной среды, которая
описана на предыдущем этапе.
На следующем этапе ЖЦ происходит Фаза стабилизации
Во время фазы стабилизации тестируется разработанное решения. Проектная
группа занимается приоритезацией и осуществляет устранение допущенных
ошибок, готовит решение к выпуску. Внимание фокусируется в этом случае на
эксплуатации в реальной модели производственной среды.
Как правило, в начале фазы стабилизации скорость выявления ошибок командой
тестирования превосходит скорость, с которой данные ошибки могут устраняться
разработчиками. Невозможно предсказать, сколько именно ошибок будет найдено
67
и насколько много времени потребуется для обеспечения их устранения. Но есть 2
статистических признака, которые помогают проектной группе дать оценку уровня
стабилизации решения. Это точка конвергенции. В ней точке заметен прогресс в
устранении имеющихся ошибок, то есть скорость устранения ошибок превосходит
скорость их обнаружения. На практике конвергенция может рассматриваться как
тенденция, а не как фиксированный момент во времени. Вслед за этой вехой число
активных ошибок должно продолжать снижаться, вплоть до нуля. Точка
конвергенции дает проектной группе возможность понять то, что процесс
тестирования приближается к завершению.
Табл. 12 описывает сферы ответственности и задачи каждого из ролевых кластеров
проектной группы во время стабилизации. Таблица дана в Прилож. 1.
Результатами фазы стабилизации являются следующие результаты: получение
окончательного продукта, Материалы поддержки решения, Проектная
документация, Документация выпуска, Исходный и исполнимый код приложений,
Результаты и инструменты осуществления тестирования. В моём проекте на этом
этапе Программист корректирует допущенные ошибки в разрабатываемой
программе, компилирует версию релиз кандидат и после отсутствия каких-либо
критических ошибок по всем веткам функционала программы выпускает
окончательную сборку исполняемого кода, вместе с тем дополняет документацию
к работе с программой. Руководитель проекта набирает на этом этапе группу
тестирования, которая состоит из 2 или 3 инженеров, которые будут пользоваться
программой ежедневно, проводит тестирование всех веток функционала по ранее
разработанным сценариям, формирует необходимые дополнения, которые можно
реализовать в будущем, в очередной версии.
Следующий этап - это Фаза внедрения
Во время нее проектной группой внедряются технологии и компоненты решения,
стабилизируется определенное внедренное решение, передается работа персоналу
поддержки. Со стороны заказчика должно быть получено одобрение полученных
68
результатов проекта. По завершению внедрения проектная группа анализирует всю
работу и узнает, насколько доволен работой заказчик.
Во время данной фазы по ходу переноса компонент решения из среды
тестирования в производственную могут предприниматься меры по стабилизации
решения. В таблице 13 описаны главные задачи, а также сферы ответственности
каждого ролевого кластера проектной группы во время фазы внедрения. Эта
таблица представлена в Прилож. 1. Результаты фазы внедрения включают:
Массивы данных и программный код, Информационные системы эксплуатации и
поддержки, Базы знаний, отчеты, журналы протоколов, Процедуры и процессы,
которые были разработаны во время проекта. Составляется также отчет о
завершении проекта, даются показатели удовлетворенности заказчика, а также
потребителей, дается описание последующих шагов. На данном этапе
руководителем система окончательно внедряется в эксплуатацию. Им
устанавливается данный программный продукт на ПК Инженеров ИТ,
распечатывается инструкция по работе. Затем Пользователь высылает новый
регламент работы департамента IT и информацию о новой логике обработки
заявок.
Внедрение представляет собой общее понятие и для него есть разные стратегии
практической реализации, которые зависят от сроков выполнения и качества ис,
которая получается на выходе. Есть 4 разных основных стратегии внедрения
системы:
· "Скачок" представляет собой довольно резкий переход от прежней системы
без осуществления при этом дополнительных проверок и с отказом от прежде
существовавшей системы.
· Параллельная стратегия - в этом случае одновременно функционирует
прежняя система, а также новая, при этом сравниваются их выходные документы.
Если они на протяжении долгого времени согласуются между собой, то тогда
происходит переход на новую систему.
69
· "Узкое место" представляет собой небольшую часть производственного
процесса. При применении данного подхода план внедрения выполняется лишь для
"узкого места", а также для людей, которые в нем работают.
· "Пилотный проект" представляет собой стратегию, которая на практике
применяется наиболее часто. Она предполагает тактику "скачка", но применяется
при этом не ко всем процессам, а только к некоторым из них. Сфера применения
указанной стратегии - определенный небольшой участок деятельности. Подобный
подход способствует снижению рисков и является самым надежным.
В дипломной проекте используется на практике стратегия “Пилотный проект”. Мы
будем проводить переход к автоматизированной системе для регистрации и
осуществления обработки заявок. Сфера применения внедрения - отдел горячей
линии, который состоит из пяти операторов. Подобный подход не затронет работу
ИС полностью, а позволит автоматизировать рутинную часть. Надежность
внедрения связана с соответствием порядка регистрации и обработки заявки
регламенту горячей линии предприятия.
В дипломном проекте охарактеризовать стратегию внедрения можно как стратегию
узкого места, поскольку проект автоматизирует процесс, который связан с
деятельностью операторов горячей линии, и узким местом является скорость
обработки писем вручную, согласования их и осуществления детального
уточнения.
Затем наступает этап эксплуатации программного продукта. Согласно инструкции,
работу программы отслеживать нужно через каждые примерно три часа, так как
она может зависнуть или обработать не все поступившие на почту письма по
причине отсутствия логики обработки данного типа заявки, и письмо будет
возвращено (переслано) на почтовый ящик с пометкой "Не обработано". Такие
риски нужно анализировать раз в месяц и принимать решение о необходимости
доработки логики программы.
70
Под моделью жизненного цикла понимают структуру, которая определяет
последовательность выполнения и взаимосвязи процессов, задач и действий,
которые выполняются в течение всего жизненного цикла. Модель жизненного
цикла зависит от специфики информационной системы и от условий, в которых
последняя создается и действует.
Сейчас самое большое распространение получили такие модели жизненного цикла:
Задачная модель;
каскадная модель(70-85 г.г.);
спиральная модель (используется в настоящее время)
Задачная модель: при создании системы "снизу-вверх" от различных отдельных
задач ко всей системе (задачная модель) единый подход к разработке утрачивается
и появляются проблемы при информационной стыковке составных компонентов.
Обычно по мере роста числа задач сложности нарастают и тогда приходится все
время менять программы и структуры данных. Скорость развития системы в итоге
замедляется, что тормозит развитие организации. Но в ряде случаев подобная
технология может быть целесообразной:
● Эксперимент и адаптация заказчика (не вполне ясны алгоритмы, решения
нащупываются за счет проб и ошибок).
● Крайняя срочность (требуется, чтобы задачи хоть как-то решались; потом
придется все делать снова).
Общий вывод: эффективность информационной системы таким способом создать
невона практике нельзя.
Каскадная модель: в ранних, не особенно больших по своему объему
информационных системах каждое приложение представляло единое целое. Для
разработки приложений применялся на практике каскадный способ. Его основная
характеристика состоит в разбиении разработки на отдельные составные этапы,
при этом осуществление перехода между ними происходит лишь тогда, когда будет
71
полностью завершена работа на текущем этапе (см. рис. 8). Каждый из этапов
завершается выпуском комплекта документации, которая вполне достаточна,
чтобы разработка могла быть продолжена другой командой разработчиков.
Положительные стороны использования каскадного подхода состоят на практике в
следующем
● выполняемые последовательно этапы позволяют планировать сроки
завершения всех работ и затраты, которые приходится нести.
● на каждом из этапов формируется законченный набор проектной
документации, который отвечает критериям полноты и согласованности;
Рис. 8. Каскадная схема разработки
Каскадный подход смог отлично себя зарекомендовать при построении
информационных систем, для которых в начале разработки можно полно и точно
сформулировать требования, чтобы предоставить разработчикам свободу
реализации их как можно лучше с технической стороны. В данную категорию
попадают достаточно сложные расчетные системы, системы реального времени и
прочие задачи. В процессе использования данного подхода обнаружился ряд
недостатков, которые вызваны в первую очередь тем, что реальный процесс
создания систем полностью ни разу не укладывался в жесткую схему. В процессе
создания появлялась постоянно потребность в возврате к предыдущим этапам и в
осуществлении уточнения или пересмотра тех решений, которые были приняты
72
раньше. В итоге реальный процесс создания программного обеспечения принимал
такой вид (рис. 9):
Рис. 9. Процесс разработки программного обеспечения по каскадной схеме
Основной недостаток применения данного подхода состоит в большом
запаздывании с получением итоговых результатов. Согласование результатов с
пользователями н практике осущетсвляется лишь в точках, которые планируются
по окончании каждого из существующих этапов работ, требования к
информационным системам "заморожены" в виде технического задания на все
время создания. Пользователи могут внести замечания после того, как работа
окажется завершена. При неточном изложении требований или их изменении,
пользователи получают систему, которая не способна полностью удовлетворить их
потребностям. Модели (и функциональные, и информационные) объекта могут
устареть в том числе и вместе с их утверждением. Сущность системного подхода к
созданию ИС состоит в осуществлении декомпозиции на несколько разных
автоматизируемых функций: систему разбивают на несколько функциональных
подсистем, которые делятся на подфункции, которые также подразделяются на
задачи. Процесс декомпозиции продолжается до конкретных процедур.
Автоматизируемая система в то же время сохраняет целостное представление, в
котором отдельные компоненты в ее составе являются взаимоувязанными.
Спиральная модель: С целью преодоления проблем предложена спиральная модель
(см. рис. 3), в которой основной упор делается в первую очередь на
первоначальные этапы жизненного цикла: осуществление анализа и