Дипломная работа: Автоматизация приема и анализа заявок технической поддержки в школе «Интеграл»
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
50
Rational
Unified
Process
10 - 40 чел.
стандарты
Rational
UML и
продукты
Rational
Удобно (RUP)
Microsoft
Solutions
Framework
3 - 20 чел.
адаптируема
любые
Удобно
(MSF+MOF)
XP
2 - 10 чел.
стандарты
отсутствуют
любые
Сложно
(зависимость от
конкретных
участников
коллектива)
Microsoft Solutions Framework является наиболее сбалансированной
технологией, ориентированной на проектные группы малых и средних
размеров.
Рассматриваемая в работе ИС автоматизации поддержки считается
небольшой, и к ней возможно применение подхода MSF. Помимо этого
важным преимуществом MSF считается итерационная модель одновременно
с уточняющими вехами (аналог каскадной модели). То есть, в реализация
MSF предпринята попытка совместить каскадную и итерационную модель
разработки и внедрения ПО.
По описанным выше преимуществам, был выбран стандарт MSF как
наиболее гибкий и удобный для реализации ИС.
Одним из преимуществ данного стандарта считается возможность
управлять сразу и проектом разработки приложения, и внедрением
инфраструктуры.
Учет преимуществ Каскадной модели (Agile) важен в методологии
жизненного цикла по следующим причинам.
51
Дело в том, что не все проекты создания систем могут быть
структурированы таким образом, чтобы быть реализованными по
классическому проектному подходу. Это связано с неопределенностями,
которые не могут быть устранены (прояснены) в ходе периода планирования
и проектирования. В таком случае, в проекте необходимо предусматривать
наличие в будущем отдельных маленьких «подпроектов», в которых будет
производиться «дополнительное планирование».
Таким образом, инициация и верхнеуровневое планирование
проводятся для всего проекта, а последующие этапы: разработка,
тестирование и прочие проводятся для каждого мини-проекта отдельно. Это
позволяет передавать результаты этих мини-проектов, так называемые,
инкременты, быстрее, а приступая к новому подпроекту (итарации) в него
можно внести изменения без больших затрат и влияния на остальные части
проекта.
Идея каскадной (итеративной) разработки не нова. Своё нынешнее
название семейство гибких методологий получило в 2001 с публикации
Манифеста Agile (Agile Manifesto), закрепившем основные ценности и
принципы гибкой разработки программного обеспечения, в основе которых –
командная работа и адаптация, даже «любовь» к изменениям.
Самое главное достоинство Agile – его гибкость и адаптивность. Он
может подстроиться под практически любые условия и процессы
организации. Именно это обуславливает его нынешнюю популярность и то,
сколько систем для различных областей было создано на его основе.
Один из принципов Agile: «Реакция на изменения важнее следования
плану». Именно быстрая и относительно безболезненная реакция на
изменения является причиной тому, что многие крупные компании стремятся
сделать свои процессы более гибкими. Кроме того, Agile отлично подходит
для проектов с «открытым концом» — например, запуску сервиса или блога.
Эффективная предметная область Agile – разработка новых,
52
инновационных продуктов. В проектах по разработке таких продуктов
высока доля неопределённости, а информация о продукте раскрывается по
ходу проекта. В таких условиях реализовывать проект по «водопаду»
становится невозможно– нет информации для планирования.
Хотя в последние годы довольно часто говорится о том, что
классический водопадный подход устарел, его позиции достаточно сильны.
Большим плюсом данного подхода является то, что он требует от Заказчика и
руководства компании определить, что же они хотят получить, уже на
первом этапе проекта. Раннее включение привносит определённую
стабильность в работу проекта, а планирование позволяет упорядочить
реализацию проекта. Кроме того, этот подход подразумевает мониторинг
показателей и тестирование, что совершенно необходимо для реальных
проектов различного масштаба.
Потенциально, классический подход позволяет избежать стрессов
ввиду наличия запасного времени на каждом этапе, заложенного на случай
каких-либо осложнений и реализации рисков. Кроме того, с правильно
проведённым этапом планирования, руководитель проектов всегда знает,
какими ресурсами он обладает. Даже если эта оценка не всегда точная.
Методология MSF следует подходам классического менеджмента, с
элементами каскадного.
5 этапов традиционного менеджмента:
Этап 1. Инициация. Руководитель проекта и команда определяют
требования к проекту. На данном этапе часто проводятся совещания и
«мозговые штурмы», на которых определяется что же должен представлять
из себя продукт проекта. Такой этап обязательно должен быть проведен в
Школе.
Этап 2. Планирование. На данном этапе команда решает, как она будет
достигать цели, поставленной на предыдущем этапе. На данном этапе
53
команда уточняет и детализует цели и результаты проекта, а также состав
работ по нему. На основании данной информации команда формирует
календарный план и бюджет, оценивает риски и выявляет заинтересованные
стороны.
Этап 3. Разработка (доработка). Данная стадия реализуется не для всех
проектов — как правило она является частью фазы планирования. В фазе
разработки, характерной для технологических проектов, определяется
конфигурация будущего проекта и/или продукта и технические способы его
достижения. Например в ИТ-проектах на данном этапе выбирается язык
программирования.
Этап 4. Реализация и тестирование. На этой фазе происходит
собственно основная работа по проекту – написание кода, возведение здания
и тому подобное. Следуя разработанным планам начинает создаваться
содержание проекта, определённое ранее, проводится контроль по
выбранным метрикам. Во второй части данной фазы происходит
тестирование продукта, он проверяется на соответствие требованиям
Заказчика и заинтересованных сторон. В части тестирования выявляются и
исправляются недостатки продукта.
Этап 5. Мониторинг и завершение проекта. В зависимости от проекта
данная фаза может состоять из простой передачи Заказчику результатов
проекта или же из длительного процесса взаимодействия с клиентами по
улучшению проекта и повышению их удовлетворённости, и поддержке
результатов проекта. Последнее относится к проектам в области клиентского
сервиса и программного обеспечения.
Благодаря тому, что классический проектный менеджмент строго
привязан ко времени исполнения задач, как правило, заранее определённому
на этапе планирования, для реализации проектов в рамках данного подхода
отлично подходят инструменты календарно-сетевого планирования. Самым
54
распространённым инструментом календарно-сетевого планирования
является уже упомянутая ранее диаграмма Гантта.
Можно сделать предположение, что в рамках данного небольшого
проекта построения информационной системы можно предусмотреть все
неясные и неопределенные вопросы на начальных этапах (планирования и
проектирования), поэтому нет необходимости выбирать исключительно из
числа гибких методологий жизненного цикла.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
В фазе формирования концепции имеют все шансы возникнуть
последующие риски:
Недальновидный анализ сроков проекта и его бюджета
Для ликвидации подобного рода рисков необходимо более подробно
изучать задачи и цели проекта, установить больше контрольных точек.
Неправильно выбранный проектный состав исполнителей
способен спровоцировать полное отсутствие командной работы
Данный риск снижается более кропотливым выбором профессионалов
в проектную группу.
На фазе планирования возможно появление следующих рисков:
Неправильно либо не совсем верно сформирована структура
выбираемого решения
Возможность возникновения данного риска находится в зависимости
от компетенции управляющего проектом, на котором лежит принятие
решение о выборе архитектуры разрабатываемого решения
В фазе разработки вероятны последующие риски:
Неправильное понимание технического задания, и как результат
некорректное программирование архитектуры и сдвиг сроков.
Минимизацией этого риска является более точное написание
технического задания, понятного программисту и интегратору
Источник: https://baza.diplomsite.ru/previewfile/1960