Недостатки эволюционной модели

· Не оправдана для систем, требования к которым ясны изначально.

· Сложности с привлечением средств и персонала на длительный срок.

 

Развитием этой модели является модель эволюционного прототипирования в рамках всего ЖЦ разработки. В литературе она часто называется моделью быстрой разработки приложений RAD (Rapid Application Development).

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

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

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

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

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

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

 

 

Применение моделей

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

 

Основные факторы влияющие на выбор модели:

· Четкость определения требований.

 

· Возможность изменений требований по ходу выполнения проекта.

 

· Возможность разбиения системы на независимые инкременты.

 

· Наличие прототипов.

 

· Финансовые и организационные ресурсы.

 

· Наличие квалифицированных кадров.

 

· Возможность ситуации прекращения проекта, если в ходе выполнения выясняется его неэффективность.

 

Перейдем к теме «Проектирование программного обеспечения».

Ранее, в Лекции 1 были рассмотрены вопросы, связанные с требованиями к программным системам.

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

    Классический пример - неудачные стандарты и технологии разработки операционной системы ОС ЕС ЭВМ, приведшие к полной утрате отечественной вычислительной техники.

Яркий пример – безобразная работа "Почты России". После «компьютеризации» и установки АСУ, необученные сотрудники (печатают двумя пальцами, причем это более продвинутые, остальные - одним). Постоянно слышны крики вроде "компьютер завис, программа выпала...".

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

Вот замечательный пример снижения эффективности при большом уровне затрат. Система живёт своей, отдельной жизнью. Скверное настроение сотрудников от взаимодействия с системой в полной мере отсылается клиентам при помощи грубого общения. И это на Центральном почтамте.

Те же проблемы и в налоговой инспекции и в сбербанке.

Другой пример, компания «Ультра Стар» (системы безопасности, мобильные средства спецсвязи) в 2005 году сменила софт и на весь квартал, пока его настраивала, вынуждена была закрыть представительство в Москве, потому что клиентуру растеряла полностью.

На сайте «Новости ВПК» можно было прочитать буквально следующее.

«Уже 10 лет ведется разработка Единой системы управления тактического звена, начатая по распоряжению В.В. Путина в 2000 году.

Известна разработка АСУ воздушно-десантной дивизии (ОКР «Полет-К»), начатая еще в начале 90-х. Прошло 20 лет, а спросить не с кого. Ни в чеченских компаниях, ни в грузино-российском конфликте АСУВ даже не пахло, и на учениях 2009 года («Осень-2009», «Запад-2009» и другие) они не получили удовлетворительной оценки.

Это результат десятилетних ОКР с постоянным ростом объемов финансирования и продлением сроков.

Последние 20 лет эти и другие АСУВ жили «своей жизнью», и то, что сегодня что-то изменилось – иллюзия (2010 г.).

Справедливости ради, следует отметить, в настоящее время ситуация меняется в лучшую сторону. Это началось после радикальной смены руководства МО РФ.

В качестве положительного примера применения современных подходов к проектированию сложных программных систем приведем успешное внедрение и использование инструментов IBM Rational в системном инжиниринге на фирме «Ульяновское конструкторское бюро приборостроения».

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

«Ульяновское конструкторское бюро приборостроения» (УКБП) - одно из ведущих предприятий авиаприборостроения РФ, основная деятельность которого сосредоточена в области разработки, изготовления и внедрения:

· авиационных систем электронной индикации и сигнализации самолетов и вертолетов;

· систем управления самолетным оборудованием;

· интегрированных систем измерения и вычисления воздушных параметров и лётных ограничений;

· наземных автоматизированных систем контроля и диагностики авиационного оборудования.

Оборудование УКБП установлено на самолётах и вертолётах Президента и Правительства РФ, а также на бортах авиакомпаний Российской Федерации и зарубежных стран.

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

Рис.2.6. Месторасположение приборов, названия авиакомпаний и городов, где производится установка.

Проект стартовал в 2007 году. Тогда компания закупила 10 лицензий Rational DOORS для управления требованиями, 6 лицензий Rational Change для управления изменениями данных жизненного цикла и 10 лицензий Rational Synergy для управления версиями исходного и исполняемого кодов программного обеспечения разрабатываемых систем и приборов.

По мере необходимости приобретались дополнительные лицензии. Например, инструменты Rational DOORS, Change и Synergy применялись Ульяновским конструкторским бюро приборостроения при разработке блока-концентратора данных для нового пассажирского самолета Сухой Superjet 100.

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

 

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

DOORS и Synergy, обеспечивались с помощью Change.

Инструменты Rational позволили обеспечить конфигурационное управление данных жизненного цикла системных процессов и процессов разработки программного обеспечения в соответствии с требованиями международных стандартов. В настоящее время DOORS, Change и Synergy широко применяются для разработки требований и управления данными жизненного цикла в проектных работах по созданию авиационных систем новых самолетов ТУ-204СМ, МС-21.

 Эти продукты применяются также для разработки систем и оборудования перспективных вертолетов, разрабатываемых компаниями ОАО «МВЗ им. М.Л. Миля», ОАО «Камов» и ОАО «Казанский вертолетный завод».

Вернемся к инженерии.

Итак, после того, как требования сформулированы, отточены и согласованы, необходимо переходить к следующему этапу программной инженерии – проектированию ПО.

Данная лекция посвящена этому этапу.

Проектирование играет важную роль в процессах жизненного цикла создания программного обеспечения, поэтому созданы соответствующие стандарты IEEE и ISO/ IEC, ГОСТ Р ИСО.МЭК и др. По мере необходимости будем ссылаться на них.   

Проектирование это процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы.   

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

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

Результат проектирования программных систем состоит из двух частей:

· Высокоуровневый дизайн (или архитектура) – описание высокоуровневой структуры и организации компонентов системы.

· Детализированная архитектура – описывает каждый компонент в объеме необходимом для конструирования.

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

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

Естественно, проектирование ПО не включает все сущности или понятия, связанные со словами «дизайн» или «архитектура» в общем.

В 1999 году Де Марко предложил терминологическое разделение различных видов дизайна:

 D-дизайн (D-design, decomposition design) – декомпозиция структуры программного обеспечения в виде набора фрагментов или компонентов.

 FP-дизайн (FP-design, family pattern design) – семейство архитектурных представлений, базирующихся на шаблонах.

 I-дизайн (I-design, invention) – создание                    высокоуровневой концепции, видения того, что из себя будет представлять программная система.

Эти термины используются до сих пор.

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

Далее будем обсуждать каждый блок в соответствии с рис.2.7.

 

 

 

Рис. 2.7. Область знаний «Проектирование ПО»