45
Стандарт COBIT выбирать нецелесообразно, т.к. ключевой целью его
применения является осуществление аудита и стратегического планирования
ИС и ИТ-инфраструктуры в целом [9, c.24].
Стандарт XP также не является оптимальным, поскольку он не имеет
полноценных этапов жизненных циклов, таких, как определение концепции,
планирование, проектирование, стабилизация, внедрение.
Соответственно, остается RUP и MSF. Оба стандарта современные и
поддерживают комплекс технологий эффективной разработки и контроля их
реализации.
Ключевые особенности MSF, RUP и XP отражены в таблице 1.12. В
данном случае можно сказать о том, что RUP представляет собой достаточно
сбалансированное решение для средних по размерам коллективов
разработчиков, ведущих деятельность с использованием продуктов и
технологий фирмы Rational. Сопровождение проектирования системы и самой
системы определяется методологией RUP, но эта технология достаточно сильно
направлена на внутрифирменные инструментальные средства.
Extreme Programming целесообразно использовать для проектных групп
небольшого размера и для систем с нередко обновляемыми требованиями.
Ключевая проблема XP - сопровождение. При текучке кадров в штате
разработчиков существенная доля проектной информации может потеряться
ввиду почти отсутствующей документации [10, c.64]. В таблице 2.1 отражены
ключевые характеристики стандартов жизненного цикла ИС.
Таблица 2.1
Технологии MSF, RUP и XP
Технология
Оптимальная
команда
Соответствие
стандартам
Допустимые
технологии и
инструменты
Удобство
модификации
и
сопровождения
RUP
10 - 40 чел.
стандарты
Rational
UML и
продукты
Rational
Удобно (RUP)
MSF
3 - 20 чел.
адаптируема
любые
Удобно
(MSF+MOF)
46
XP
2 - 10 чел.
стандарты
отсутствуют
любые
Сложно
(зависимость от
конкретных
участников
коллектива)
MSF представляет собой максимально сбалансированную технологию,
направленную на проектные группы малых и средних размеров. MSF не
накладывает рамок на применяемый инструментарий и имеет рекомендации
достаточно общего характера [8, c.66]. Но данные рекомендации можно
применить для создания определенного процесса, отвечающего потребностям
коллектива разработчиков.
Проектируемый проект небольшой, состоящий из трех человек, а стадии
проектирования и тестирования реализуются в среде разработки Python.
Помимо всего прочего, ключевым достоинством MSF является итерационная
модель вместе с уточняющими вехами (аналог каскадной модели).
Соответственно, исполнение MSF стремится к объединению каскадной и
итерационной модели проектирования и эксплуатации ПО.
По исследованным достоинствам был выбран стандарт MSF как самый
гибкий и удобный для выполнения проекта.
Одним из достоинств данного стандарта является опция управления
одновременно и проектом, и разработкой приложения, и внедрением
инфраструктуры.
Таким образом, в идеологии MSF есть 5 стадий жизненного цикла ИС,
которые в MSF именуются фазами. Первая из них - фаза выработки концепции.
Цель этой фазы состоит в образовании и сплочении проектной группы на
базе создания единого видения. Проектная группа должна четко понимать, что
нужно сделать для заказчика и поставить цель. Клиентом в данном случае
является оператор мобильной связи «Билайн».
47
В идеологии MSF команда проекта разбивается на шесть участников,
каждому из которых отводится свое значение в проекте, обязанности и
ответственности. Данные роли в MSF именуются кластерами, за каждым из
которых может стоять не один человек. В каждой фазе для каждого
ответственного лица, закреплённого за кластером, фиксируются установленные
задачи.
Рассмотрим задачи, выполняются при разработке концепций. Управление
продуктом регулирует концептуальный и логический дизайн; функциональная
спецификация; сводный план и сводный календарный график проекта; бюджет
[14, c.65]. Кластер «Управление программой» определяет цели дизайна,
концепцию решения, структуру проекта. Кластер «Разработка» оценивает
технологии; логический и физический дизайн; план и календарный график
разработки; смету разработки.
Кластер «Удовлетворение потребителя» анализирует сценарии и
примеры применения, пользовательские требования, требования локализации и
общедоступности; пользовательскую документацию и план обучения.
Кластер «Тестирование» оценивает дизайн; требования тестирования;
план и календарный график тестирования. Кластер «Управление выпуском»
изучает эксплуатационные требования; план и календарный график пилотного и
финишного внедрения. Так или иначе, в рамках разработки и эксплуатации
проекта силами ИТ-штата использовать шесть и более человек для фоновой
задачи, бюджет которого ограничен только премией, совсем нецелесообразно.
Ввиду этого задачи кластеров объединяются, и из них выделяются два
ответственных лица, составляющих команду проекта: программист и менеджер
проекта.
Выходными данными и результатами этой фазы является подбор
кандидатов и определение самых подходящих из них к установленным задачам
на исполнение двух ролей, т.е. создание команды, несмотря на то, что включает
только двух человек. В данном проекте на этом этапе устанавливается состав и
48
роли участников. Помимо всего прочего, составлена смета по времени и
планирование бюджета этого проекта. _________________________________
Дальше идет фаза планирования. Ключевой её целью является составлени
е планов проекта. Она включает подготовку проектной группой функциональной
спецификации, создание дизайнов, рабочих планов, оценку проектных затрат и
сроков проектирования разнообразных компонентов проекта. ______________
Процесс проектирования – это систематический метод продвижения от
абстрактных концепций к определенным техническим деталям. ___________
Результатами фазы планирования являются: функциональная
спецификация, описание вероятных рисков, сводный план и календарный
график проекта, развернутые среды проектирования и тестирования. От
программиста здесь необходим обзор и выбор языка программирования, на
котором будет выполнение решение, а также календарный план по срокам и
графикам проектирования [13, c.24]. Менеджер проекта здесь разрабатывает
всю архитектуру ИС, а также взаимодействие почтового сервера, web-сервера,
СУБД, работу пользователей и менеджеров в проектируемой системе.
Далее идет фаза разработки. Здесь проектная группа сосредоточена на
формировании компонента решения (как документацию, так и программный
код). Но определенная часть данной деятельности может продолжаться и на
фазе стабилизации, но, если такую потребность определили в ходе
тестирования. Также здесь разрабатывается инфраструктура [14, c.12].
Необходимо сказать о том, что активность проектной команды здесь не
ограничивается написанием кода – все ролевые кластеры участвуют в
проектировании и тестировании решения. _______________________________
Результатами на данной фазе являются: исходный и исполнимый код
приложений, скрипты установки и конфигурирования, окончательное описание
функционала выполняемого решения, материалы поддержки решения, сценарии
тестов. В данной ситуации программисту нужно разработать программу-клиент
для деятельности ИТ-менеджеров, а также написать полную программу к ней.
Руководителю проекта нужно сформировать работоспособную среду.
49
Далее идет фаза стабилизации. Здесь осуществляется тестирование
проектируемого решения. В данном случае внимание сосредоточено на его
применении в реалистичной модели производственной среды. Проектная группа
занимается приоритезацией и ликвидацией ошибок, а также подготовкой
решения к выпуску. ________________________________________________
Чаще всего в начале данной фазы скорость идентификации ошибок
командой тестирования быстрее скорости их устранения командой. Нельзя
точно предположить то, сколько будет найдено ошибок, а также то время, за
которое их получится устранить. Но есть 2 статистических признака,
помогающих проектной группе понять уровень стабилизации решения. Это
точка конвергенции. В ней виден существенный прогресс в ликвидации ошибок,
т.е. скорость их устранения становится быстрее скорости идентификации. Т.к.
число найденных, но не ликвидированных ошибок способно меняться даже
после своего уменьшения, конвергенция представляет собой все же тенденцию,
а не установленный временной промежуток [41]. Следуя за этой вехой, число
активных ошибок должно уменьшаться и далее, дойдя до нуля. Точка
конвергенции позволяет проектной группе установить, что процесс
тестирования скоро завершится.
Результатами данной фазы являются: окончательный продукт,
документация выпуска, материалы поддержки решения, результаты и
инструментарий тестирования, исходный и исполнимый код приложений,
проектная документация. На этой стадии программистом исправляются ошибки
в создаваемой им программе, компилируется версия «релиз-кандидат» и после
отсутствия критических ошибок по всем веткам работы программы
формируется итоговая сборка реализуемого кода, вместе с этим дополняется
документация к работе с программой. Руководитель здесь набирает группу
тестирования, которые будут использовать эту программу ежедневно и
тестирует все ветки работы по созданным ранее сценариям и создает
дополнения, которые можно будет выполнить в следующей версии.
_________________________________
50
Далее идет фаза внедрения. Здесь проектная группа внедряет технологии
и элементы решения, стабилизирует его, передает работу персоналу поддержки
и сопровождения и получает согласование проекта клиентом. По окончании
данной фазы проектная группа осуществляет анализ осуществленной
деятельности и удовлетворенности клиента. _____________________________
В течение данной фазы по ходу переноса элемента решения из среды
тестирования в производственную среду могут идти меры по стабилизации
решения. _______________________________________________________
Результаты данной фазы: ИС эксплуатации и поддержки, процедуры и
процессы, базы знаний, отчеты, журналы протоколов, массивы информации и
программный код, созданные в процессе проекта. Здесь руководитель
окончательно внедряет систему в работу, устанавливает программный продукт
на ПК, обучает сотрудников работе с системой [16, c.61]. Затем пользователем
высылается новый регламент деятельности ИТ-отдела и данные о новой логике
анализа заказов с просьбой за 7 дней дать ответ об установленных изменениях в
ИТ-сервисе. ____________________________________________________
Внедрение является общим понятием и для него есть различные стратегии
реализации, которые находятся в зависимости от срока исполнения и качества
итоговой ИС. Есть 4 ключевые стратегии внедрения системы:
- параллельная стратегия – в данном случае единовременно
функционируют старая (ручная) и новая система, а их выходные документы
сопоставляются. Если они долго согласовываются, то реализуется переход на
новую систему; _____________________________________________________
- скачок – резкий переход от старой системы к новой без каких-либо
проверок. Тут реализуется полный отказ от старой системы;
- пилотный проект – самая популярная стратегия. Это тактика скачка, но
используемая при ограниченном количестве процессов. Сфера использования
стратегии – небольшой участок деятельности. Данный подход уменьшает риск и
обладает максимальной надежностью;
51
- узкое место – малая часть производственного процесса. В данном случае
план внедрения реализуется только для такого места, а также для людей,
работающих в нем [43]. _______________________________________________
В работе выбрана стратегия «Пилотный проект». Будет осуществляться
полный переход к автоматизированной системе для процессов регистрации и
анализа заказов. Сферой использования внедрения будет отдел, состоящий из 5
менеджеров. Данный подход не повлияет на работу всей ИС, а только
автоматизирует рутинную часть. Надежность такого внедрения
аргументирована четким соответствием порядка регистрации и анализа заказа
установленному регламенту.
______________________________________________________
В работе охарактеризовать стратегию внедрения можно как стратегию
узкого места, поскольку этот проект автоматизирует процесс, связанный с
работой менеджеров, а узким местом является скорость ручной обработки
заказов, согласования их и подробного уточнения.
Затем идет этап эксплуатации разработанного программного продукта. По
инструкции такой программы нужно отслеживать ее работу каждые 2 часа,
поскольку она способна зависнуть или обработать не все заказы по e-mail ввиду
отсутствия логики анализа такого типа заявки, в такой ситуации письмо
вернется обратно на почтовый ящик с пометкой в теме письма «Не обработано»
. Такой риск нужно анализировать ежемесячно и выносить решение о
необходимости доработки логики программы.
______________________________________
Под моделью жизненного цикла понимается структура,
устанавливающая алгоритм реализации и взаимосвязи процессов, операций и
задач, реализуемых в ходе жизненного цикла. Данная модель находится в
зависимости от особенной ИС и условий, в которых она проектируется и
работает [38, c.73]. -0928498124098720398470912837409827340987
Сейчас самыми популярными является такие модели жизненного цикла,
как: 214098274098712039487да _ да _да _да
52
- задачная;
- каскадная (системная);
- спиральная.
Задачная модель: при проектировании системы «снизу-вверх» от
отдельных задач ко всей системе общий поход к проектированию так или
иначе теряется, образуются проблемы при информационной стыковке
отдельных элементов. Чаще всего, в процессе увеличения числа задач
сложности нарастают, и нужно непрерывно видоизменять текущие
программы и структуры данных.
Скорость развития системы, как и развитие самой компании,
существенно замедляется. Но иногда данная технология вполне уместна:
__________________________________________________________
- крайняя срочность (нужно хоть как-то выполнить задачи, иначе нужно
будет все делать снова);
- эксперимент и адаптация клиента (непонятны алгоритмы, решения
выбираются методом проб и ошибок).
Итог: существенную эффективность ИС таким образом реализовать
нельзя. ______________________________________________________
Каскадная модель: в ранних, малых по объему однородных ИС всякое
приложение являлось единым целым. Для создания данного типа приложений
использовался каскадный способ. Его ключевым свойством является
разделение всей разработки на стадии, причем переход с одной стадии на
другую может произойти только тогда, когда завершены все работы на
предыдущей стадии (рисунок 2.1). Каждая стадия завершается выпуском
полного комплекта документации, необходимой для того, чтобы разработку
могла продолжить другая команда. _______________________________
Достоинства использования каскадного подхода состоят в следующем:
- на каждой стадии появляется законченный набор проектной
документации, соответствующий критериям полноты и согласованности;
53
- реализуемые последовательно стадии дают возможность планировать
сроки окончания работ и определенные затраты.
Рисунок 2.1 - Каскадная схема разработки
Каскадный подход целесообразно использовать при создании ИС, для
которых определены конечные требования к системе. Как правило каскадная
модель используется в случае необходимости разработки сложных систем. В
данную категорию входят сложные расчетные системы, системы реального
времени и иные аналогичные задачи [5, c.44]. Как и любая модель разработки
данная модель имеет и свои недостатки. Можно выделить две ключевые
проблемы, как итог это затраченное время от начала старта проетка и до сдачи
системы в промышленную эксплуатацию, и вторая это в случае не учитывание
всех требований к системе. В данной модели если заказчик выдвигает новое
требование, которое требует координальных изменений в логике системы, то
процесс создания и согласования начинается заново.
Но в ходе применения данного подхода выявляются его недостатки
, возникшие, прежде всего, ввиду того, что реальный процесс проектирования
систем никогда целиком не укладывался в такую жесткую схему. В ходе
проектирования постоянно нужно было возвращаться к предыдущим
стадиями и уточнять или изменять решения, которые были приняты ранее. Как
итог, действительный процесс создания ПО выглядел так, как это показано
на рисунке 2.2.
54
Рисунок 2.2 - Реальный процесс разработки ПО по каскадной схеме
Ключевым недостатком данного подхода является значительное
запаздывание с получением результатов. Согласование результатов с
пользователями осуществляется лишь в точках, определяемых по окончании
каждой стадии, требования к ИС остановлены в форме технического задания
на все время ее проектирования [14, c.56]. Соответственно, пользователи
могут представить свои замечания только после реализации всех этапов
работы. При неполном изложении требований или их корректировке в ходе
длительного периода проектирования ПО, пользователи получают систему,
которая не соответствует их пожеланиям. Модели автоматизируемого объекта
могут устареть вместе с их утверждением. Суть системного подхода к
проектированию ИС состоит в ее декомпозиции (разбиении) на
автоматизируемые функции: система делится на функциональные
подсистемы, которые делятся на подфункции, подразделяемые на задачи и
т.д. Процесс деления идет до определенных процедур. Здесь
автоматизируемая система сохраняет общее представление, где все элементы
взаимозависимы. Соответственно, такая модель ключевым преимуществом
имеет системность разработки, а недостатком – медленную скорость и
дороговизну.
Спиральная модель: для устранения указанных проблем разработана
спиральная модель жизненного цикла (рис. 1.17), акцентирующая внимание
на начальных этапах жизненного цикла: анализе и проектировании. Здесь
выполнение технических решений проверяется с помощью создания