РАЗРАБОТКА И СТАНДАРТИЗАЦИЯ ПРОГРАММНЫХ СРЕДСТВ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

ЛЕКЦИЯ 2 ТЕМА: МЕТОДЫ И ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ПО

Спиральный тип модели ЖЦ

В середине 1980-х годов Барри Боэм предложил свой вариант итерационной модели под названием «спиральная модель» (spiral model), когда ПО создается не сразу, как в каскадной модели, а по частям, методом прототипирования.

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

1 - начальный сбор требований и планирование проекта; 2 - та же работа, но на основе рекомендаций заказчика; 3 - анализ риска на основе начальных требований; 4 - анализ риска на основе реакции заказчика; 5 - переход к комплексной системе; 6 – начальный макет системы; 7 - следующий уровень макета; 8 - сконструированная система; 9 - оценивание заказчиком.

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

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

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

Подход RAD Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ т.н. быстрой разработки приложений, или RAD (Rapid Application Development).

RAD предусматривает наличие трех составляющих: · небольших групп разработчиков (3-7 чел.), выполняющих работы по проектированию отдельных подсистем ПО (максимальная управляемость); · короткого, но тщательно проработанного графика (до 3 месяцев); · повторяющегося цикла, при котором разработчики по мере того как приложение начинает приобретать форму, запрашивают и реализуют в продукте требования, полученные в результате взаимодействия с заказчиком.

ЖЦ ПО при подходе RAD состоит из 4 стадий: 1. Анализ и планирование требований Предусматривает действия: определение функций, которые должна выполнять система; выделение приоритетных функций, требующих проработки в первую очередь; описание информационных потребностей.

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

2. Проектирование. На этой стадии часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. Для быстрого получения работающих прототипов приложений используются соответствующие инструментальные средства (CASE-средства).

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

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

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

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

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

Тестирование системы осуществляется в процессе разработки. Реализация системы завершается выполнением работ: Осуществляется анализ использования данных и определяется необходимость их распределения. Производится физическое проектирование БД. Формируются требования к аппаратным ресурсам. Устанавливаются способы увеличения производительности. Завершается разработка документации проекта.

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

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

Итак, перечислим основные принципы подхода RAD: Разработка приложений итерациями. Необязательность полного завершения работ на каждой стадии ЖЦ ПО. Обязательность вовлечения пользователей в процесс разработки ЭИС. Целесообразность применения CASE-средств, обеспечивающих целостность проекта и генерацию кода приложений. Целесообразность применения средств управления конфигурацией, облегчающих внесение изменений и сопровождение готовой системы. Использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности пользователей. Тестирование и развитие проекта, осуществляемые одновременно с разработкой. Ведение разработки немногочисленной хорошо управляемой командой профессионалов. Грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.

Модели качества процессов конструирования В условиях жесткой конкуренции очень важно гарантировать высокое качество процесса конструирования ПО. Такую гарантию дает сертификат качества процесса, подтверждающий его соответствие принятым международным стандартам. Каждый такой стандарт фиксирует свою модель обеспечения качества. Наиболее авторитетны модели стандартов ISO 9001:2000, ISO / IЕС и модель зрелости процесса конструирования ПО (Capability Maturity Model - СММ) Института программной инженерии при американском университете Карнеги-Меллон.

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

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

Пять уровней зрелости модели СММ

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

ПОНЯТИЯ МЕТОДА И ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ПО Метод проектирования ПО представляет собой организованную совокупность процессов создания ряда моделей, которые описывают различные аспекты разрабатываемой системы с использованием четко определенной нотации. На более формальном уровне метод определяется как совокупность составляющих, в том числе: концепций (теоретических основ), нотаций и процедур. В качестве концепций (теоретических основ) могут выступать структурный и объектно- ориентированный подходы.

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

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

Требования к технологии Современная технология проектирования должна обеспечивать: 1. Соответствие стандарту ISO / IEC 12207: Гарантированное достижение целей разработки ЭИС в рамках установленного бюджета, с заданным качеством и в установленное время. 3. Возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности (3-7 чел.), с последующей интеграцией составных частей.

4. Минимальное время получения работоспособного ПО ЭИС. Речь идет не о сроках готовности всей ЭИС, а о сроках реализации отдельных подсистем. Практика показывает, что даже при наличии полностью завершенного проекта внедрение ЭИС идет последовательно, по отдельным подсистемам. 5. Независимость получаемых проектных решений от средств реализации ЭИС (СУБД, ОС, языков и систем программирования). 6. Поддержка комплексом согласованных CASE- средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ ПО.

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

должен устанавливать: Набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации. Правила фиксации проектных решений на диаграммах. В том числе правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм (включая требования к форме и размерам объектов) и т.д. Требования к конфигурации рабочих мест разработчиков, включая настройки ОС, настройки CASE -средств и т.д. Стандарт проектирования

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

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

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

Ресурсы для ЖЦ сложных ПС Общее понятие - доступные ресурсы жизненного цикла ПС - включает в себя финансовые, временные, кадровые и аппаратурные ограничения, в условиях которых происходит создание и совершенствование ПО.

Одной из основных задач при системном проектировании ПС является экономический анализ и определение необходимых ресурсов для создания и для всего ЖЦ программных средств в соответствии с требованиями контракта и ТЗ.

Наиболее общим видом ресурсов, используемых в ЖЦ ПС, являются допустимые финансово-экономические затраты или эквивалентные им величины трудоемкости соответствующих работ.

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

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

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

Обобщенными ресурсами проекта ПС являются: доступные по стоимости совокупные трудовые, временные и материальные затраты, необходимые для приобретения, создания, модификации и эксплуатации компонентов и всего комплекса программ.

При экономическом анализе проектов ПС возможны два сценария: создание и весь ЖЦ комплекса программ и/или БД ориентируется разработчиком на массовое тиражирование и распространение на рынке, для заранее неизвестных покупателей и пользователей в различных сферах применения, при этом отсутствует приоритетный внешний потребитель-заказчик, который определяет и диктует основные требования, а также финансирует проект; разработка проекта ПС и/или БД предполагается поставщиком или разработчиком для конкретного потребителя-заказчика, который его финансирует, с определенным, необходимым ему тиражом и известной, ограниченной областью применения результатов разработки.

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