Современные технологии анализа

08.02.10

Лекция 1. Введение в программную инженерию

Программная инженерия – это применение определенного систематического измеримого подхода при разработке эксплуатации и поддержки программного обеспечения.

В 2004 году было создано руководство к своду знаний по программной инженерии.

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

{Здесь могли быть ваши комментарии}

1. Software requirements – программные требования

2. Software design

3. Software construction

4. Software testing

5. Software maintenance

6. Software configuration management

7. Software engineering management

8. Software engineering process

9. Software engineering tools and methods

10. Software …

При анализе разработки десятков тысяч проектов, связанных с разработкой ПО, выяснилось:

• 35% проектов завершились в срок, не превысили бюджет, реализовали все требуемые функции

• 46% проектов – завершились с опозданием, расходы превысили бюджет, требуемые функции не реализовались в полном объеме

• Среднее превышение сроков – 120%

• Среднее превышение затрат – 100%

• 19% проектов – полностью провалилось

Кто виноват? Как правило, никто…

Эволюция подходов к управлению программными проектами.

За 50 лет развития программной инженерии накопилось большое количество моделей разработки ПО, но мы среди этого большинства моделей можем выделить главные:

1. Подход «как получится»

• Разомкнутая система управления

• Полное доверие техническим лидерам

• Представители бизнеса практически не участвуют в проекте

• Планирование неформальное и словесное

• Время и бюджет, как правило, не контролируются

2. Подход «водопад» или «каскадная модель»

   • Жесткая последовательная схема управления, переход на каждый следующий этап только после завершения предыдущего

   • Лучше предыдущего, но не эффективно

3. «Гибкое управление»

• Создание опорного базового проекта, включающего основные требования, изменения отклонений, новый расчет

• Гибкие методы позволяют учитывать внесение изменений и добавлений в программную реализацию

«ГОСТы»

По ГОСТам разработка производится по этапам, каждый из которых предполагает выполнение строго определенного набора работ – «каскадная модель».

«RUP» – Rational Unified Process – унифицированный процесс, разработанный сотрудниками компании Rational Software в качестве дополнения к языку UML.

Модель RUP описывает стандартный общий процесс, на основе которого проектная команда должна создать конкретный специализированный проект, ориентированный на конечного потребителя.

Выбор модели процесса

1. Тяжелые процессы (каскадная модель)

ПЛЮСЫ:

• Рассчитаны на среднюю квалификацию исполнителей

• Большая специализация исполнителей

• Низкие требования к стабильности команды

МИНУСЫ:

• Требуют существенной управленческой надстройки

• Более длительные стадии анализа и проектирования

• Более формализованные коммуникации (большое количество документации, которое передается от одного человека к другому)

2. Легкие модели

ПЛЮСЫ:

• Меньше непроизводительных расходов, связанных с управлением проектом, рисками, изменениями, конфигурацией

• Упрощенные стадии анализа и проектирования

• Основной упор на разработку функциональности, совмещение ролей

• Неформальные коммуникации

НЕДОСТАТКИ:

• Эффективность разработки сильно зависит от индивидуальных способностей, требуют более квалифицированной, универсальной и стабильной команды

• Объемы и сложность выполняемых объектов ограничены

Успешность проекта

Для успешности программного проекта необходимо:

• Четко ставить цели

• Определять способ достижения целей

• Контролировать и управлять реализацией

• Анализировать угрозы и противодействовать им

• Создавать команду

Существует тест программного проекта на выживание. Так называемый check-лист из 33 пунктов. Каждый пункт этого теста оценивается от 0 до 3, применяются поправочные компоненты: для малых проектов 1,5 , для средних (от 5 до 20 человек) – 1,25.

Организация проектной команды

Роли и ответственности участников типового проекта разработки ПО можно условно разделить на 5 групп:

1. АНАЛИЗ

Извлечение, документирование и сопровождение требований к продукту.

Группа анализа включает следующие роли:

• Бизнес-аналитик (построение модели предметной области)

• Бизнес-архитектор (разработка бизнес-концепции системы, определение общего видения продукта, его интерфейсы, поведение и ограничение)

• Системный аналитик (отвечает за перевод требований к продукту в функциональные требования к ПО)

• Специалист по требованиям (документирование и сопровождение требований к продукту)

• Менеджер продукта/функциональный заказчик (представляет интересы пользователей к продукту)