Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ГОСы / Shpory_pris.docx
Скачиваний:
16
Добавлен:
04.01.2020
Размер:
3.44 Mб
Скачать
  1. Модель по методу "хирургическая бригада"

Харлан Миллз предложил организацию команды разработчиков в виде бригады хирургов. При этом лишь несколько человек занято проектированием, а остальные работники находятся на подхвате. 

  • Хирург: главный программист. Определяет технические условия на функциональность и эксплуатационные характеристики программы.

Назначается из числа наиболее опытных и талантливых специалистов. Он сам разрабатывает, пишет и отлаживает программу, полностью и единолично несет ответственность за конечный результат. В совершенстве владеет языком программирования и имеет неограниченный доступ к ЭВМ.

  • Второй пилот: второе «я» хирурга, может выполнять любую работу хирурга, но менее опытен. 

Ведет параллельную разработку той же программы, знает ее до тонкостей. Принимает участие в дискуссиях, может давать советы, однако "хирург" решает, следует ли их принимать. В случае несчастья с "хирургом" второй пилот способен повести дальнейшее дело сам, дополнительной подготовки ему для этого не потребуется.

  • Администратор:  обеспечивает связь менеджмента с хирургом. 

Занимается административными и коммерческими вопросами проекта. Но ключевые решения из этой сферы принимает сам "хирург", он же несет за них ответственность.

  • Редактор: правка записей хирурга.

  • Секретари: помогают администратору и редактору.

  • Делопроизводитель: отвечает за регистрацию всех технических данных бригады в библиотеке программного продукта.

  • Инструментальщик: разрабатывает вспомогательное ПО.

  • Отладчик: разрабатывает тесты и тестирует ПО.

  • Языковед: специалист по языку, на котором ведётся разработка.

Организация по типу хирургических бригад с главным программистом предлагает способ достижения целостности продукта благодаря его проектированию в нескольких головах и общей продуктивности благодаря наличию многочисленных помощников при радикально сокращенном обмене информацией.

  1. Спиральная модель жц

Спиральная модель – классический пример применения эволюционной стратегии конструирования. Модель (автор Б. Боэм, 1988) базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент – анализ риска, отсутствующий в этих парадигмах. Модель определяет четыре действия, представляемые четырьмя квадрантами спирали.

  1. Планирование – определение целей, вариантов и ограничений. 2. Анализ риска – анализ вариантов и распознавание/выбор риска. 3. Конструирование – разработка продукта следующего уровня. 4. Оценивание – оценка заказчиком текущих результатов конструирования.

В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование, используемое в квадранте конструирования.

Достоинства спиральной модели: наиболее реально (в виде эволюции) отображает разработку программного обеспечения; позволяет явно учитывать риск на каждом витке эволюции разработки; включает шаг системного подхода в итерационную структуру разработки; использует моделирование для уменьшения риска и совершенствования программного изделия.

Недостатки спиральной модели: сравнительная новизна (отсутствует достаточная статистика эффективности модели); повышенные требования к заказчику; трудности контроля и управления временем разработки.

Модель спирального процесса разработки является наиболее распространенной в настоящее время. Самыми известными ее вариантами являются RUP (Rational Unified Process) от фирмы Rational и MSF (Microsoft Solution Framework). Создание системы предполагается проводить итерационно, двигаясь по спирали и, проходя через одни и те же стадии, на каждом витке уточнять характеристики будущего продукта.