Развитие инкрементального подхода. XP-процессы.

- экстремальное программирование XP (Кент Бек, 1999). Оно ориентировано на очень малые приращения функциональности.

- модель быстрой разработки приложений RAD (Rapid Application Development). RAD-модель обеспечивает эстремально короткий цикл разработки. Быстрая разработка достигается за счет использования компонентно ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD- процесс позволяет группе создать полностью функциональную систему за 60-90 дней.

Выделяют следующие этапы:

- бизнес-моделирование. Моделируются информационные потоки между бзнесм-функциями.

- моделирование данных. Информационный поток отображается в набор объектов данных.

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

- генерация приложения. Используются языки программирования 4-го поколения, готовые компоненты, для конструирования утилиты автоматизации.

- тестирование и объединение. Применение повторно используемых компонентов уменьшает время тестирования.

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

Недостатки применения RAD:

1. Для больших проектов требуются значительные людские ресурсы для создания групп.

2. Модель применима только для тех систем, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной.

3. Не применима в условиях высоких технических рисков, т.е. при использовании новой технологии.

В современной программной инженерии выделяют два семейства процессов разработки:

- прогнозирующие (predictive) или тяжеловесные (heavyweight) процессы - прогнозируется весь объем работ, большой объем документации, строгий порядок разработки, фиксированные требования и многочисленная группа разработчиков разной квалификации.

- подвижные (agile) или облегченные (lightweight) процессы- учитывают особенности современного заказчика, т.е. частые изменения его требований, привлекательны отсутствием бюрократизма. Необходима малочисленная группа высоко квалифицированных разработчиков и грамотный заказчик, согласный участвовать в разработке.

Экстремальное программирование - это облегченный процесс (Кент Бек, 1999). Он ориентирован на группы малого и среднего размера, работающие в условиях неопределенных и быстро изменяющихся требований. В группу входит до 10 сотрудников, работающих в одном помещении.

На всем протяжении итерационного цикла требования постоянно меняются, причем цикл состоит из очень коротких итераций.

Базовые действия на каждой итерации: кодирование, тестирование, выслушивание заказчика, проектирование.

Динамизм обеспечивается следующими характеристиками:

- непрерывная связь с заказчиком;

- простота (всегда выбирается минимальное решение)

- быстрая обратная связь (модульное и функциональное тестирование)

- смелость в проведении профилактики возможных проблем.

Базис XP образуют 12 методов:

1. Игра планирования - Локальный заказчик обеспечивает набор "истории", которые описывают требуемую функциональность. К каждой новой версии в текущий набор "историй" вносятся наиболее важные истории.

2. Частая смена версий новые версии каждые 2 недели.

3. Метафора -вся разработка проводится на основе простой общедоступной истории о том как работает система. Истории обеспечивают заказчики.

4. Простое проектирование

5. Тестирование - непрерывное написание тестов для модулей. Входным критерием для написания кода является отказавший тестовый вариант. Заказчики участвуют в тестировании.

6. Реорганизация - система реструктуризируется, но ее поведение не меняется. Цель упростить систему, улучшить взаимодействие или добавить в нее гибкость.

7. Парное программирование -весь код пишется двумя программистами, работающими на одном компьютере.. Оно приводит к повышению качества и уменьшению времени цикла на 40-50%, при увеличении затрат на ресурсы на 15%

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

9. Непрерывная интеграция -интегрирование системы несколько раз в день по мере завершения каждой задачи.

10. 40-часовая неделя -нельзя работать сверхурочно.

11. Локальный заказчик - в группе все время должен находиться представитель заказчика, готовый отвечать на все вопросы.

12. Стандарты кодирования - правила, обеспечивающие одинаковое представление программного кода.

 

9. Международные стандарты проектирования, разработки, оформления документации, пользовательского интерфейса ПИ.

К таким стандартам относятся следующие:

- стандарт проектирования;

- стандарт оформления проектной документации;

- стандарт пользовательского интерфейса.

Над данными стандартами работает ISO/IEС JTC1/SC7 - международный технический комитет стандартов под контролем ИСО (ISO - Международная организация по стандартизации) и МЭК (IEС - Международная электротехническая комиссия).

Стандарт проектирования устанавливает (ISO/IEC 2382-20: 1990, Information technology ~ Vocabulary - Part 20: Systems development. (Разработка систем).):

- набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

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

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

- механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д.

Стандарт оформления проектной документации устанавливает (ИСО 6592:1985, Обработка информации. Руководящие указания по документированию автоматизированных прикладных систем.):

- комплектность, состав и структуру документации на каждой стадии проектирования;

- требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),

- правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;

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

- требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя устанавливает (ИСО 6385:1981, Эргономические принципы проектирования рабочих систем):

- правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

- правила использования клавиатуры и мыши;

- правила оформления текстов помощи;

- перечень стандартных сообщений;

- правила обработки реакции пользователя.