Подходы к проектированию информационных систем, страница 3

•  Использование водопадной модели для реализации окончательного прототипа

•  Оценка результатов по завершении каждой итерации и планирование следующей итерации

•  Завершение проекта при нецелесообразности его продолжения

Виды прототипов

•  Прототип пользовательского интерфейса

•  Функциональный прототип

•  Исследовательский прототип

Недостаток

•  Отсутствие чётких фаз выполнения работ, что может привести к выходу проекта из под контроля

Достоинства и недостатки спиральной модели

Достоинства

•  Ускорение разработки (раннее получение результата за счёт прототипирования)

•  Постоянное участие заказчика в процессе разработки

•  Разбиение большого объёма работы на небольшие части

•  Снижение риска (повышение вероятности предсказуемого поведения системы)

Проблемы

•  Сложность планирования (определения количества и длительности итераций, оценки затрат и рисков)

•  Сложность применения модели с точки зрения менеджеров и заказчиков

•  Напряжённый режим работы для разработчиков

Сопоставление водопадной и спиральной моделей

Подход RAD

•  RAD – Rapid Application Development (быстрая разработка приложений) – набор технологий и средств быстрого поэтапного построения систем, разработан James Martin, IBM, середина 80-х годов

•  Небольшие группы разработчиков (от 3 до 7 человек), выполняющих работы по проектированию отдельных подсистем ПО (максимальная управляемость коллектива)

•  Короткий, но тщательно проработанный производственный график (до 3 месяцев)

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

Основные принципы RAD

•  Разработка приложений итерациями

•  Необязательность полного завершения работ на каждой стадии ЖЦ ПО

•  Обязательность вовлечения пользователей в процесс разработки

•  Использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности пользователей

•  Тестирование и развитие проекта одновременно с разработкой

•  Немногочисленная, хорошо управляемая команда профессионалов

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

Microsoft Solution Framework

Основные особенности MSF

•  Начальная разработка концепции, постановки видения (vision statement), выбор возможностей и определение их приоритетов на основе запросов пользователей

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

•  Много небольших команд разработчиков (3-8 человек), параллельно работающих над продуктом

•  Частая синхронизация изменений

•  Полная сборка очередного решения (release) к конце дня с помощью средств управления конфигурацией (daily build)

•  Немедленная фиксация дефектов в каждом решении и их устранение

•  Непрерывное тестирование в процессе разработки

•  Всесторонне внутреннее и внешнее тестирование (альфа и бета тестирование)

•  3 или 4 контрольные точки стабилизации продукта в течение цикла разработки

Результат - создание "good enough" продукта для массового рынка с последующим совершенствованием и поставкой новых версий (updates)

Rational Unified Process

Цикл итерации RUP

Особенности RUP

•  Rational Unified Process – это методология создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, снабжённой поисковой системой

•  Язык моделирования в общей базе знаний – Unified Modeling Language (UML)

•  Система описывается не документами, а моделями UML

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

Extreme Programming

•  XP – Extreme Programming – экстремальное программирование

•  Проектирование, анализ и планирование осуществляются в процессе разработки

•  Определяются функциональные возможности и стоимость их реализации – истории (story)

•  Заказчик выбирает наиболее важные истории

Правила XP

•  Этап планирования (planning game) – определяется функционал и сроки исполнения

•  Частая смена версий (small releases) – внедрение до окончания проекта, версии каждый месяц

•  Метафора (metaphor) – используются метафоры для понимания между заказчиком и программистами

•  Простой проект (simple design) – в системе нет ни одного лишнего метода

•  Тесты (tests) – постоянно используются тесты для модулей (unit tests) и функциональные тесты (functional tests)

•  Переработка системы (refactoring) - архитектура системы постоянно эволюционирует, при этом выполняются все тесты

•  Программирование в паре (pair programming)

•  Непрерывная интеграция (continuous integration)

•  Коллективное владение (collective ownership)

•  Заказчик с постоянным участием (on-site customer)

•  40-часовая неделя (40-hour weeks)

•  Открытое рабочее пространство (open workspace)

•  Не более чем правила (just rules)