14. «Тяжелые и легкие» технологии разработки ПО. Экстремальное (ХР) программирование

Существует направление «Быстрых технологий» разработки ПО (Agile Software Development), дающее идеологическое обоснование этим взглядам. Эти технологии базируются на четырех идеях:

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

работающее ПО важнее наличия документации на него,

сотрудничество с заказчиком важнее формальных договоров с ним,

быстрое реагирование на внешние изменения важнее строгого следования намеченным планам.

Правильность этих принципов в определенной мере (разработку ПО ведет небольшое количество квалифицированных программистов - «фанатов», не нуждающихся в контроле и дополнительной мотивации) для разработки ПО оспаривать трудно. Однако, Agile технологии и это признают их идеологи применимы в программных проектах определенного класса и масштаба, так же как и вообще спиральная модель ЖЦ, а именно там, где ошибки ПО приводят к некоторым неудобствам либо потерям возместимых средств и там где требования к ПО постоянно меняются, собственно заранее плохо определены, и требуется быстрая адаптация к этим изменениям.

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

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

Примером Agile технологий является «Экстремальное программирование» (ХР). Итерации в ХР очень короткие и состоят из четырех операций: кодирования, тестирования, выслушивание заказчика, проектирование. Принципы ХР – минимальность, простота, участие заказчика, короткий цикл, тесные взаимодействия разработчиков – они должны сидеть в одной комнате, ежедневных оперативных совещаний совместно с заказчиком представляются разумными и давно применяются не только в быстрых технологиях, но в ХР они доведены до экстремальных значений.

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

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

18

Принято считать проект с количеством участников до 6 малым, с количеством участников 6-20 средним и с количеством участников более 20 большим. В больших коллективах разработчиков проблема управления – выходит на передний план.

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

саму возможность их создания.

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

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

«Поддерживай порядок и он поддержит тебя».

Мы в нашем курсе рассматриваем полномасштабную технологию разработки ПО с каскадной моделью ЖЦ.

Компонентно - ориентированная модель жизненного цикла ПО является развитием спиральной модели ПО и основывается на эволюционной стратегии разработки ПО. В этой модели на стадиях проектирования и реализации определяется возможность использования ранее разработанных программных компонент и производится их поиск в библиотеках. Если компонента присутствует в библиотеке – она используется, если отсутствует, то разрабатывается таким образом, чтобы её можно было поместить в библиотеку.

Ключевой момент технологии – наличие достаточно полных библиотек компонент. Данная технология по некоторым оценкам уменьшает время разработки на 30% и соответственно уменьшает стоимость разработки ПО.

Технологическая основа классификации ПО

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

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

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

Классификацию ПО можно сделать более продуктивной, вводя в рассмотрение понятия:

Информационные системы,

[Введите текст]

Автоматические системы «реального времени»

Критические системы,

Распределенные системы,

Системы реального времени изучаются интенсивно в специальных курсах. Но с точки зрения ПО - это ПО, ориентированное на управление в технических системах. Тогда как в информационных системах – работа ПО ориентирована на хранение передачу и обработку данных. Основной характеристикой информационных систем кроме характеристик по хранению, поиску и управлению транзакциями является характеристики человекомашинного интерфейса. Разработка программ реального времени приводит к особенностям технологии - необходимо при разработке учитывать и подсчитывать время работы ПО, результат работы, которого нужен не вообще, а к определенному моменту функционирования системы. Так с запозданием определенный автомобильным компьютером сигнал в систему АBS в лучшем случае бесполезен.

Для встроенного ПО, которое практически всегда ПО реального времени, человеко -машинный интерфейс ограничен и ограничивается использованием его при наладке системы и отладке ПО .

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

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

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

15.Три вида программных разработок с точки зрения технологии их создания

иэксплуатации

Разделим программы на три вида.

1)Индивидуально создаваемые программы для решения частных задач: бизнес системы, интернет сайты, системы управления материально-техническим снабжением, небольщие исследовательские задачи (работают вне реального времени, в интерактивном режиме),

2)Сложные программы типа информационно поисковых систем и систем управления базами данных, офисных систем, бухгалтерских систем, систем редактирования и т. п.

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

20

Технологии создания программ этих видов отличаются друг от друга, соответственно отличается удельная трудоемкость или обратная ей величина - количество операторов (слов), разрабатываемых одним человеком в 1 день (примерно в 5-10 раз).

В жизненном цикле создания ПО 3-го вида процесс непосредственно программирования составляет незначительную часть от общей трудоемкости работ (< 10%). Для программ первого вида - наоборот 60 - 80%. Это связано с тем, что для этих программ часто отсутствует выделенный этап проектирования, который перемешан с этапом программирования, программы выпускаются без документации. Отлаживаются они не удовлетворительно, отсутствуют документы по отладке, четкий план отладки с контролем на ее полноту. Ошибки в данном случае не носят катастрофического характера и устраняются по мере их проявления. Специальных средств отладки не требуется или они стандартны и ограничены средствами, представляемыми универсальной системой программирования типа Дельфи, Еxcel, C++ и т.п.

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

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

Для программ 3-го вида требуются специальные средства проектирования и отладки в виде моделирующих сред. Программы третьего вида как правило специализированы и разрабатываются под конкретные системы и относятся к большим программным проектам. Для них необходима тщательная отладка и ЭТД. Большинство ПО критических систем относится к данному виду ПО.

Программные разработки третьего вида «отягощены» реальным временем, что требует определенной организации вычислительного процесса ЦВМ и накладывает жесткие ограничения на время исполнения программ.

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

Технология создания таких программ наиболее сложна, требует моделирования работы системы и ПО в системе и соответствующих инструментальных средств. В результате стоимость одной строки ПО КА Шаттл составляет 1000$, тогда как стоимость строки коммерческого ПО первого вида в среднем 5$ за строку.

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

Таблица1

[Введите текст]