Организационные процессы жизненного цикла программных средств

7. 
   Организационные процессы жизненного цикла программных средств.
   

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

7. 
   Модели жизненных циклов программных средств. Стратегии конструирования ПС.
   

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

каскадная модель (70-85 г.г.);

спиральная модель (86-90 г.г.).

В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 1.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Положительные стороны применения каскадного подхода заключаются в следующем [2]:

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

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



Рис. 1.1. Каскадная схема разработки ПО

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



Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 1.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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



Рис 1.3. Спиральная модель ЖЦ

Методологии и технологии проектирования ИС

Общие требования к методологии и технологии

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

Технология проектирования определяется как совокупность трех составляющих:

пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис. 1.4);

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

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



Рис. 1.4. Представление технологической операции проектирования

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

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

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

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

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

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

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

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

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

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

7. 
   Основные понятия инженерии программного обеспечения.
   

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

В конечном итоге, продаются не программы, а программные продукты, которые бывают двух типов: коробочные продукты (generic products or shrink-wrapped software) и заказные продукты (bespoke or customized products). Важная разница между ними заключается в том, кто ставит задачу (пишет спецификацию).

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

В этом определении есть две важные части:

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

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

Программные инженеры применяют систематичные и организованные подходы к работе для достижения максимальной эффективности и качества ПО. Общепринято мнение, что неправильно выбранный подход должен отрицательно сказаться на качестве и сроках сдачи системы. Но подход надо выбирать с умом — во многих случаях неформальные, "легкие" процессы могут оказаться значительно эффективнее (например, в таких задачах, как написание web-based applications или e-commerce systems).

Разница между программной инженерией (software engineering) и информатикой (computer science) заключается в следующем. Информатика занимается теорией и методами компьютерных и программных систем, в то время как программная инженерия занимается практическими проблемами создания ПО. Естественно, инженер-программист обязан в каком-то объеме знать информатику (точно так же, как инженер-электрик должен в каком-то объеме знать физику).

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

Разница между программной инженерией (software engineering) и системной инженерией (systems engineering) заключается в следующем. Системная инженерия (а точнее — компьютерная системная инженерия, computer-based systems engineering, CBSE) занимается всеми аспектами создания и эволюции комплексных систем, в которых ПО играет заметную роль. Таким образом, программная инженерия является частью системной инженерии, наряду с созданием аппаратных платформ, созданием архитектуры, системной интеграцией и т.п. В системной инженерии основной упор приходится именно на системные вопросы, а не на составные части системы.

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

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

Выделим четыре основных фазы программного процесса:

Создание спецификации ПО

Разработка ПО

Тестирование ПО (включает в себя validation и verification)

Развитие или эволюция ПО (software evolution)

Модель программного процесса — это упрощенное описание программного процесса, представленное с некоторой точки зрения. Модели всегда являются упрощениями: all models are wrong; some models are useful (E. Deming).

Некоторые типы моделей программного процесса:

Модель технологического процесса (workflow model) — показывает последовательность действий, наряду со входами, выходами и зависимостями. Действия в этой модели представляют собой действия людей.

Модель потоков данных (data flow or activity model) — представляет процесс в виде набора действий, каждый из которых выполняет некоторое преобразование данных. В этой модели действия могут быть более низкого уровня, чем в предыдущей модели (например, какие-то действия может выполнять компьютер).

Модель роль/действие (role/action model) — показывает роли людей, участвующих в программном процессе, а также действия, за которые они отвечают.

Традиционные модели разработки ПС:

Каскадная модель

Эволюционное развитие (в двух вариантах — с доработкой прототипа и с выбрасыванием, т.е. переписыванием)

Формальные преобразования — основана на создании математических моделей системы с их дальнейшим преобразованиями, сохраняющими корректность

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

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



Чем больше система и чем выше ее критичность, тем больший процент стоимости определяется фазой тестирования.

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

Стоимость эволюции системы очень сильно варьируется в зависимости от размера системы и срока ее жизни. Во многих случаях стоимость сопровождения превосходит стоимость разработки в 3–4 раза.

Наконец, при создании коробочных продуктов стоимость создания спецификации исчезающе мала (около 5%), на разработку (обычно эволюционным способом) уходит около 30-35% времени проекта, а все остальное — тестирование системы на всевозможных конфигурациях. Для коробочных продуктов особенно трудно оценить стоимость эволюции — обычно процесс создания новой версии не имеет четко выраженного начала, и, кроме того, чаще всего из маркетинговых соображений новая версия подается не как модифицированный продукт, уже купленный пользователем, а как продукт абсолютно новый (хотя и совместимый со старыми).

Метод программной инженерии — это структурный подход к созданию ПО, нацеленный на создание эффективного продукта наиболее прибыльным (рентабельным, cost-effective) путем.

Тема развивается с 1970х: структурный анализ Тома ДеМарко (1978), JSD Джексона (1983). Эти и другие методы тех времен были ориентированы на идентификацию основных функций системы; функционально-ориентированные методы до сих пор популярны. Очень часто их применяют неосознанно.

В 1980х гг. эти методы были дополнены объектно-ориентированным подходом: Буч (1994), Рамбо (1991). Со временем эти методы были объединены в UML (опубликован с 1997 г).

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

Описание моделей системы и их нотаций (например, объектные модели, конечно-автоматные модели и т.д.)

Правила, накладывающие ограничения на использование моделей в системе (например, "поймают-обругают" в REAL)

Рекомендации — эвристики, характеризующие хорошие приемы проектирования в данном методе (скажем, рекомендация о том, что ни у одного объекта не должно быть больше семи подобъектов)

Руководство к действию (наставление, process guidance) — описание действий, которым можно следовать во время создания моделей и последующего их использования (все атрибуты должны быть документированы до определения операций, связанных с этим объектом)

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

Понятие CASE (Computer-Aided Software Engineering) включает в себя широкий комплекс программ, предназначенных для поддержки процессов создания программного продукта, включая анализ требований, моделирование, отладку и тестирование. Большинство современных методов поддерживаются соответствующими CASE-средствами.

Любопытное разделение: CASE-средства, поддерживающие анализ и проектирование, иногда называют CASE-средствами верхнего уровня (upper-CASE tools), а средства, поддерживающие реализацию и тестирование, такие как отладчики, средства анализа системы, генераторы тестов и редакторы программ, называют средствами нижнего уровня (lower-CASE tools).

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

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

Характеристики качества программных средств (ISO 9126:1991)

Характеристика продукта	Описание
Функциональная пригодность (functional suitable)	Функциональная пригодность подразумевает: - пригодность для применения, - точность, - защищенность, - способность к взаимодействию, - согласованность со стандартами и правилами проектирования.
Надежность (dependability)	Надежность характеризуется: - отсутствием ошибок, - устойчивостью к ошибкам, - перезапускаемостью. Надежное ПО не должно приводить к физическому или экономическому ущербу в случае сбоя системы.
Применимость (employability)	Применимость подразумевает: - понятность, - обучаемость, - простоту использования.
Эффективность (efficiency)	Эффективность включает в себя: - ресурсная экономичность, - временная экономичность. ПО не должно впустую тратить системные ресурсы, такие как память или процессорное время. Поэтому эффективность зависит от времени отклика, утилизации памяти и т.п.
Сопровождаемость (maintainability)	Сопровождаемость характеризуется: - удобством для анализа, - изменяемостью, - стабильностью, - тестируемостью. Система должна быть написана с расчетом на дальнейшее развитие. Это критическое свойство системы, т.к. изменения ПС неизбежны вследствие изменения бизнеса.
Переносимость (substituability)	Переносимость включает в себя: - адаптируемость, - структурированность, - замещаемость, - внедряемость.
Удобство использования (usability)	ПО должно быть легким в использовании, причем именно тем типом пользователей, на которых рассчитано приложение. Удобство использования обеспечивается: - интерфейсом пользователя, - адекватной документацией.

Основные трудности, стоящие перед программной инженерией:

Устаревшие системы (legacy challenge)

Работа в гетерогенной среде (heterogeneity challenge)

Недостаток времени, отводимого на разработку программных продуктов (delivery challenge)

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

10. Процесс создания систем. Основные требования и этапы

Накопленный к настоящему времени опыт создания систем ПО показывает, что это сложная и трудоемкая работа, требующая высокой квалификации участвующих в ней специалистов. Однако до настоящего времени создание таких систем нередко выполняется на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ПО. По данным Института программной инженерии (Software Engineering Institute, SEI) в последние годы до 80% всего эксплуатируемого ПО разрабатывалось вообще без использования какой-либо дисциплины проектирования, методом "code and fix" (кодирования и исправления ошибок).

Проблемы создания ПО следуют из его свойств. Еще в 1975 г. Фредерик Брукс, проанализировав свой уникальный по тем временам опыт руководства крупнейшим проектом разработки операционной системы OS/360, определил перечень неотъемлемых свойств ПО: сложность, согласованность, изменяемость и незримость [1]. Что же касается современных крупномасштабных проектов ПО, то они характеризуются, как правило, следующими особенностями:

Характеристики объекта внедрения:

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

Технические характеристики проектов создания ПО:

• 
  различная степень унифицированности проектных решений в рамках одного проекта;
  
• 
  высокая техническая сложность, определяемая наличием совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (транзакционных приложений, предъявляющих повышенные требования к надежности, безопасности и производительности, и приложений аналитической обработки (систем поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема);
  
• 
  отсутствие полных аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем, высокая доля вновь разрабатываемого ПО;
  
• 
  большое количество и высокая стоимость унаследованных приложений (существующего прикладного ПО), функционирующих в различной среде (персональные компьютеры, миникомпьютеры, мэйнфреймы), необходимость интеграции унаследованных и вновь разрабатываемых приложений;
  
• 
  большое количество локальных объектов внедрения, территориально распределенная и неоднородная среда функционирования (СУБД, операционные системы, аппаратные платформы);
  
• 
  большое количество внешних взаимодействующих систем различных организаций с различными форматами обмена информацией (налоговая служба, налоговая полиция, Госстандарт, Госкомстат, Министерство финансов, МВД, местная администрация).
  

Организационные характеристики проектов создания ПО:

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

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

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

В то же время, попытки чрезмерной формализации процесса, а также прямого заимствования идей и методов из других областей инженерной деятельности (строительства, производства) привели к ряду серьезных проблем. После двух десятилетий напрасных ожиданий повышения продуктивности процессов создания ПО, возлагаемых на новые методы и технологии, специалисты в индустрии ПО пришли к пониманию, что фундаментальная проблема в этой области - неспособность эффективного управления проектами создания ПО. Невозможно достичь удовлетворительных результатов от применения даже самых совершенных технологий и инструментальных средств, если они применяются бессистемно, разработчики не обладают необходимой квалификацией для работы с ними, и сам проект выполняется и управляется хаотически, в режиме "тушения пожара". Бессистемное применение технологий создания ПО (ТС ПО), в свою очередь, порождает разочарование в используемых методах и средствах (анализ мнений разработчиков показывает, что среди факторов, влияющих на эффективность создания ПО, используемым методам и средствам придается гораздо меньшее значение, чем квалификации и опыту разработчиков). Если в таких условиях отдельные проекты завершаются успешно, то этот успех достигается за счет героических усилий фанатично настроенного коллектива разработчиков. Постоянное повышение качества создаваемого ПО и снижение его стоимости может быть обеспечено только при условии достижения организацией необходимой технологической зрелости, создании эффективной инфраструктуры как в сфере разработки ПО, так и в управлении проектами. В соответствии с моделью SEI СММ (Capability Maturity Model), в хорошо подготовленной (зрелой) организации персонал обладает технологией и инструментарием оценки качества процессов создания ПО на протяжении всего жизненного цикла ПО и на уровне всей организации.

Одна из причин распространенности "хаотического" процесса создания ПО - стремление сэкономить на стадии разработки, не затрачивая времени и средств на обучение разработчиков и внедрение технологического процесса создания ПО. Эти затраты до недавнего времени были довольно значительными и составляли, по различным оценкам (в частности, Gartner Group), более $100 тыс. и около трех лет на внедрение развитой ТС ПО, охватывающей большинство процессов жизненного цикла ПО, в многочисленной команде разработчиков (до 100 чел.). Причина - в "тяжести" технологических процессов. "Тяжелый" процесс обладает следующими особенностями:

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

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

11. Современные тенденции в программной инженерии. CALS-технология.

В начале 2001 года ряд ведущих специалистов в области программной инженерии (Алистер Коберн, Мартин Фаулер, Джим Хайсмит, Кент Бек и другие) сформировали группу под названием Agile Alliance. Слово agile [’ædзaıl] (подвижный, быстрый, ловкий, стремительный) отражало в целом их подход к разработке ПО, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Этот подход под названием "Быстрая разработка ПО" (Agile software development) [10] базируется на четырех идеях, сформулированных ими в документе "Манифест быстрой разработки ПО" (Agile Alliance's Manifesto) и заключающихся в следующем:

индивидуумы и взаимодействия между ними ценятся выше процессов и инструментов;

работающее ПО ценится выше всеобъемлющей документации;

сотрудничество с заказчиками ценится выше формальных договоров;

реагирование на изменения ценится выше строгого следования плану.

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

когда она позволяет людям легче выразить свои мысли;

когда она выполняет задачи, невыполнимые вручную;

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

когда она облегчает общение между людьми;

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

При этом следует четко понимать: при всех достоинствах быстрой разработки ПО этот подход не является универсальным и применим только в проектах определенного класса. Для характеристики таких проектов Алистер Коберн ввел два параметра - критичность и масштаб.

Критичность определяется последствиями, вызываемыми дефектами в ПО, ее уровень может иметь одно из четырех значений:

C - дефекты вызывают потерю удобства;

D - дефекты вызывают потерю возместимых средств (материальных или финансовых);

E - дефекты вызывают потерю невозместимых средств;

L - дефекты создают угрозу человеческой жизни.

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

от 1 до 6 человек - малый масштаб;

от 6 до 20 человек - средний масштаб;

свыше 20 человек - большой масштаб.

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

интерактивное общение лицом к лицу - это самый дешевый и быстрый способ обмена информацией;

избыточная "тяжесть" технологии стоит дорого;

более многочисленные команды требуют более "тяжелых" и формальных технологий;

большая формальность подходит для проектов с большей критичностью;

возрастание обратной связи и коммуникации сокращает потребность в промежуточных и конечных продуктах;

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

потеря эффективности в некритических видах деятельности вполне допустима.

Одним из наиболее известных примеров практической реализации подхода быстрой разработки ПО является "Экстремальное программирование" (Extreme Programming - XP) [10]. Этот метод предназначен для небольших компактных команд, нацеленных на получение как можно более высокого качества и продуктивности, и достигает этого посредством насыщенной, неформальной коммуникации, придания на персональном уровне особого значения умению и навыкам, дисциплине и пониманию, сводя к минимуму все промежуточные рабочие продукты.

Одним из путей достижения поставленных целей является создание информационных систем, поддерживающих жизненный цикл (ЖЦ) продукции, получивший обозначение CALS - концепция "непрерывной информационной поддержки поставок и жизненного цикла". Впервые работы в области CALS были начаты в оборонном комплексе США. Новая концепция стала инструментом совершенствования управления материально-техническим обеспечением армии США. Реализация этой концепции позволила сократить затраты на организацию информационного взаимодействия государственных учреждений с частными фирмами в процессах формализации требований, заказа, поставок, и эксплуатации военной техники.
Сегодня термин CALS означает совокупность принципов и технологий информационной поддержки жизненного цикла продукции на всех стадиях. Русско-язычный аналог понятия CALS -" Информационная Поддержка жизненного цикла Изделия (ИПИ)".
Революционный характер базовой идеи внедрения CALS определяется тем, что оно предполагает отказ от "бумажной" технологии оформления технической документации, базирующейся на сотнях стандартов ЕСКД, ЕСТД, СРПП; а так же замену многочисленных автономных систем автоматизированного проектирования, подготовки производства и т.д., которые не решают проблем информационного обмена между различными участниками жизненного цикла изделия (заказчиков, разработчиков, производителей, эксплуатантов) на интегрированную информационную среду.
Суть информационной интеграции состоит в том, что все автоматизированные системы, применяемые на различных стадиях ЖЦ, оперируют не с традиционными документами и даже не с их электронными отображениями (например, отсканированными чертежами), а с формализованными информационными моделями, описывающими изделие, технологии его производства и использования.
Неотъемлемой составляющей информационной поддержки жизненного цикла изделия является "Интегрированная логистическая поддержка(ИЛП)" - как комплекс управленческих технологий, ориентированных на оптимизацию затрат, связанных преимущественно с послепродажными стадиями ЖЦ сложного наукоемкого изделия: эксплуатацией, техническим обслуживанием, ремонтом и материально-техническим обеспечением этих процессов.

12. 
    Тяжеловесные и облегченные процессы создания систем. Экстремальное программирование.
    

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

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

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