Модуль IV. Разработка программного обеспечения асоиу

17.Современные технологии разработки программного обеспечения асоиу. Rup. Msf. Xp.

Современные технологии проектирования и разработки программного обеспечения АСОИУ.

Технология проектирования ПО АСОИУ определяется как совокупность трех составляющих [28]: пошаговой процедуры, определяющей последовательность технологических операций проектирования; критериев и правил, используемых для оценки результатов выполнения технологических операций; нотаций (графических и текстовых средств), используемых для описания проектируемой системы.

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

Технология проектирования, разработки и сопровождения ПО АСОИУ должна удовлетворять следующим общим требованиям:

1. технология должна поддерживать полный ЖЦ ПО;

2. технология должна обеспечивать гарантированное достижение целей разработки ПО АСОИУ с заданным качеством и в установленное время;

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

4. технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек).

5. технология должна обеспечивать минимальное время получения работоспособной ИС.

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

7. технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ПО АСОИУ (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);

8. технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.

Реальное применение любой технологии проектирования, разработки и сопровождения ПО АСОИУ в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся следующие:

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

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

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

Критерии, применяемые для оценки технологии создания ПО АСОИУ представлены в таблице.

Таблица Критерии, применяемые для оценки технологии создания АС

Критерий	Определение
Минимум трудоемкости создания ПО	Количество человеко-месяцев, затрачиваемых на создание ПО
Максимум продуктивности	Объем работы (измеряемый в количестве строк кода или функциональных точек), приходящийся на единицу трудоемкости (человеко-месяц)
Максимум качества создаваемого ПО	Количество дефектов в рабочих продуктах
Возврат инвестиций	(Доход от использования ПО - Затраты на создание и сопровождение ПО) / (Затраты на создание и сопровождение ПО)

Ведущей методологией, в которой инструментально поддерживаются все этапы жизненного цикла разработки ПО, является методология Rational Unified Process (RUP), созданная компанией Rational Software [29].

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

Жизненный цикл разработки RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта. Полный жизненный цикл разработки продукта состоит из четырех фаз, каждая из которых включает в себя одну или несколько итераций. Дисциплина (discipline) соответствует понятию технологического процесса и представляет собой последовательность действий, приводящую к получению значимого результата. В рамках RUP определены шесть основных дисциплин: построение бизнес-моделей; определение требований; анализ и проектирование; реализация; тестирование; развертывание; и три вспомогательных: управление конфигурацией и изменениями; управление проектом; создание инфраструктуры.

Методология создания программных решений Microsoft Solutions Framework (MSF). Microsoft Solutions Framework представляет собой согласованный набор концепций, моделей и правил [30]. В последней версии MSF 3.0 были обновлены модели проектной группы (Team Model) и процессов (Process Model), а также добавлены: три новые дисциплины — управление проектами, управление рисками и управление подготовкой (Readiness Management); новые руководства, примеры шаблонов документов для проекта MSF; новый очный курс 1846A MSF Essentials. На официальном сайте компании Microsoft представленные переводы документов, входящих в MSF (перевод компании eLine Software) [31].

Экстремальное программирование (Extreme Programming), часто обозначаемое аббревиатурой ХР, — это дисциплина разработки программного обеспечения и ведения бизнеса в области создания программных продуктов, которая фокусирует усилия обеих сторон (программистов и бизнесменов) на общих, вполне достижимых целях [32, 33, 34]. Команды, использующие ХР, производят качественное программное обеспечение с весьма большой скоростью.

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