Процесс создания программного обеспечения

2. Процесс создания программного обеспечения Цели Цель настоящей главы – представить основные идеи, лежащие в основе процесса создания программного обеспечения. Прочитав эту главу, вы должны: • знать основные концепции, лежащие в основе процесса создания ПО и моделей этого процесса; • иметь представление об основных моделях процесса создания ПО и понимать, когда какую из них использовать; • знать схему построения моделей процесса формирования требований к ПО, его разработки, тестирования и модернизации; • иметь понятие о CASE-технологиях, предназначенных для поддержки процесса создания ПО. Как отмечалось ранее, процесс создания программного обеспечения – это множество взаимосвязанных процессов и результатов их выполнения, которые ведут к созданию программного продукта. Процесс создания ПО может начинаться с разработки программной системы "с нуля", но чаще новое ПО разрабатывается на основе существующих программных систем путем их модификации. Процесс создания ПО, как и любая другая интеллектуальная деятельность, основан на человеческих суждениях и умозаключениях, т.е. является творческим. Вследствие этого все попытки автоматизировать процесс создания ПО имеют лишь ограниченный успех. CASE-средства могут помочь в реализации некоторых этапов процесса разработки ПО, но по крайней мере в ближайшие несколько лет не стоит ожидать от них существенного продвижения в автоматизации тех этапов создания ПО, где существенен фактор творческого подхода к разработке ПО. Одна из причин ограниченного применения автоматизированных средств к процессу создания ПО – огромное многообразие видов деятельности, связанных с разработкой программных продуктов. Кроме того, организации-разработчики используют разные подходы к разработке ПО. Также различаются характеристики и возможности создаваемых систем, что требует особого внимания к определенным сторонам процесса разработки. Поэтому даже в одной организации при создании разных программных систем могут использоваться различные подходы и технологии. Несмотря на то что наблюдается огромное многообразие подходов, методов и технологий создания ПО, существуют фундаментальные базовые процессы, без реализации которых не может обойтись ни одна технология разработки программных продуктов. Перечислим эти процессы. 1. Разработка спецификации ПО. Это фундамент любой программной системы. Спецификация определяет все функции и действия, которые будет выполнять разрабатываемая система. 2. Проектирование и реализация (производство) ПО. Это процесс непосредственного создания ПО на основе спецификации. 3. Аттестация ПО. Разработанное программное обеспечение должно быть аттестовано на соответствие требованиям заказчика. 4. Эволюция ПО. Любые программные системы должны модифицироваться в соответствии с изменениями требований заказчика. В данной лекции приведен обзор этих процессов, более подробно они рассматриваются далее. Хотя не существует "идеального" процесса создания ПО, во многих организациях-разработчиках пытаются его усовершенствовать, поскольку он может опираться на устаревшие технологии и не включать лучших методов современной инженерии программного обеспечения. Кроме того, многие организации постоянно используют одни и те же технологии (когда-то ранее хорошо себя зарекомендовавшие) и им также необходимы методы современной инженерии ПО. Совершенствовать процесс создания программных систем можно разными путями. Например, путем стандартизации, которая уменьшит разнородность используемых в данной организации технологий. Это, в свою очередь, приведет к совершенствованию внутренних коммуникаций в организации, уменьшению времени обучения персонала и сделает экономически выгодным процесс автоматизации разработок. Стандартизация обычно является первым шагом к внедрению новых методов и технологий инженерии ПО. 2.1. Модели процесса создания ПО Как отмечалось раньше, модель процесса создания программного обеспечения – это общее абстрактное представление данного процесса. Каждая такая модель представляет процесс создания ПО в каком-то своем "разрезе", используя только определенную часть всей информации о процессе. В настоящем разделе представлены обобщенные модели, основанные на архитектурном подходе. В этом случае можно увидеть всю структуру процесса создания ПО, абстрагируясь от частных деталей отдельных составляющих его этапов. Эти обобщенные модели не содержат точного описания всех стадий процесса создания ПО. Напротив, они являются полезными абстракциями, помогающими "приложить" различные подходы и технологии к процессу разработки. Кроме того, очевидно, что процесс создания больших систем не является единым, а состоит из множества различных процессов, ведущих к созданию отдельных частей большой системы. В этой лекции рассматриваются следующие модели создания программного обеспечения. 1. Каскадная модель. Основные базовые виды деятельности, выполняемые в процессе создания ПО (такие, как разработка спецификации, проектирование и производство, аттестация и модернизация ПО), представляются как отдельные этапы этого процесса. 2. Эволюционная модель разработки ПО. Здесь последовательно перемежаются этапы формирования требований, разработки ПО и его аттестации. Первоначальная программная система быстро разрабатывается на основе некоторых абстрактных общих требований. Затем они уточняются и детализируются в соответствии с требованиями заказчика. Далее система дорабатывается и аттестуется в соответствии с новыми уточненными требованиями. 3. Модель формальной разработки систем. Основана на разработке формальной математической спецификации программной системы и преобразовании этой спецификации посредством специальных математических методов в исполняемые программы. Проверка соответствия спецификации и системных компонентов также выполняется математическими методами. 4. Модель разработки ПО на основе ранее созданных компонентов. Предполагает, что отдельные составные части программной системы уже существуют, т.е. созданы ранее. В этом случае технологический процесс создания ПО основное внимание уделяет интеграции отдельных компонентов в общее целое, а не их созданию. Каскадная и эволюционная модели разработки широко используются на практике. Модель формальной разработки систем успешно применялась во многих проектах, но количество организаций-разработчиков, постоянно использующих этот метод, невелико. Использование готовых системных компонентов практикуется повсеместно, но большинство организаций не придерживаются в точности модели разработки ПО на основе ранее созданных компонентов. Вместе с тем этот метод должен получить широкое распространение в XXI столетии, поскольку сборка систем из готовых или ранее использованных компонентов значительно ускоряет разработку ПО. 2.1.1. Каскадная модель Это первая модель процесса создания ПО, порожденная моделями других инженерных процессов. Она показана на рис. 2.1. Эту модель также иногда называют моделью жизненного цикла программного обеспечения*. Основные принципиальные этапы (стадии) этой модели отражают все базовые виды деятельности, необходимые для создания ПО. * Жизненный цикл программного обеспечения - это совокупность процессов, протекающих в период от момента принятия решения о создании ПО до его полного вывода из эксплуатации. Таким образом, "жизненный цикл ПО" является более широким понятием, чем модель процесса создания ПО. Вместе с тем каскадную модель можно рассматривать как одну из моделей жизненного цикла ПО. 1. Анализ и формирование требований. Путем консультаций с заказчиком ПО определяются функциональные возможности, ограничения и цели создаваемой программной системы. 2. Проектирование системы и программного обеспечения. Процесс проектирования системы разбивает системные требования на требования, предъявляемые к аппаратным средствам, и требования к программному обеспечению системы. Разрабатывается общая архитектура системы. Проектирование ПО предполагает определение и описание основных программных компонентов и их взаимосвязей. 3. Кодирование и тестирование программных модулей. На этой стадии архитектура ПО реализуется в виде множества программ или программных модулей. Тестирование каждого модуля включает проверку его соответствия требованиям к данному модулю. 4. Сборка и тестирование системы. Отдельные программы и программные модули интегрируются и тестируются в виде целостной системы. Проверяется, соответствует ли система своей спецификации. 5. Эксплуатация и сопровождение системы. Обычно (хотя и не всегда) это самая длительная фаза жизненного цикла ПО. Система инсталлируется, и начинается период ее эксплуатации. Сопровождение системы включает исправление ошибок, которые не были обнаружены на более ранних этапах жизненного цикла, совершенствование системных компонентов и "подгонку" функциональных возможностей системы к новым требованиям. Рис. 2.1. Жизненный цикл программного обеспечения В принципе результат каждого этапа должен утверждаться документально (это как бы сигнал об окончании этапа). Тогда следующий этап не может начаться до завершения предыдущего. Однако на практике этапы могут перекрываться с постоянным перетеканием информации от одного этапа к другому. Например, на этапе проектирования может возникнуть необходимость уточнить системные требования либо на этапе кодирования могут выявиться проблемы, которые можно решить лишь на этапе проектирования, и т.д. Процесс создания ПО нельзя описать простой линейной моделью, так как он неизбежно содержит последовательность повторяющихся процессов. Поскольку на каждом этапе проводятся определенные работы и оформляется сопутствующая документация, повторение этапов приводит к повторным работам и значительным расходам. Поэтому после небольшого числа повторений обычно "замораживается" часть этапов создания ПО, например этап определения требований, но продолжается выполнение последующих этапов. Возникающие проблемы, решение которых требует возврата к "замороженным" этапам, игнорируются либо делаются попытки решить их программно. "Замораживание" этапа определения требований может привести к тому, что разработанная система не будет удовлетворять всем требованиям заказчика. Это также может привести к появлению плохо структурированной системы, если упущения этапа проектирования исправляются только с помощью программистских хитростей. Последний этап жизненного цикла ПО (эксплуатация и сопровождение) – это "полноценное" использование программной системы. На этом этапе могут обнаружиться ошибки, допущенные, например, на первом этапе формирования требований. Могут также проявиться ошибки проектирования и кодирования, что может потребовать определения новых функциональных возможностей системы. С другой стороны, система постоянно должна оставаться работоспособной. Внесение необходимых изменений в программную систему может потребовать повторения некоторых или даже всех этапов процесса создания ПО. К недостаткам каскадной модели можно отнести негибкое разбиение процесса создания ПО на отдельные фиксированные этапы. В этой модели определяющие систему решения принимаются на ранних этапах и затем их трудно отменить или изменить, особенно это относится к формированию системных требований. Поэтому каскадная модель применяется тогда, когда требования формализованы достаточно четко и корректно. Вместе с тем каскадная модель хорошо отражает практику создания ПО. Технологии создания ПО, основанные на данной модели, используются повсеместно, в частности для разработки систем, входящих в состав больших инженерных проектов. 2.1.2. Эволюционная модель разработки Эта модель основана на следующей идее: разрабатывается первоначальная версия программного продукта, которая передается на испытание пользователям, затем она дорабатывается с учетом мнения пользователей, получается промежуточная версия продукта, которая также проходит "испытание пользователем", снова дорабатывается и так несколько раз, пока не будет получен необходимый программный продукт (рис. 2.2). Отличительной чертой данной модели является то, что процессы специфицирования, разработки и аттестации ПО выполняются параллельно при постоянном обмене информацией между ними. Различают два подхода к реализации эволюционного метода разработки. 1. Подход пробных разработок. Здесь большую роль играет постоянная работа с заказчиком (или пользователями) для того, чтобы определить полную систему требований к ПО, необходимую для разработки конечной версии продукта. В рамках этого подхода вначале разрабатываются те части системы, которые очевидны или хорошо специфицированы. Система эволюционирует (дорабатывается) путем добавления новых средств по мере их предложения заказчиком. 2. Прототипирование. Здесь целью процесса эволюционной разработки ПО является поэтапное уточнение требований заказчика и, следовательно, получение законченной спецификации, определяющей разрабатываемую систему. Прототип* обычно строится для экспериментирования с той частью требований заказчика, которые сформированы нечетко или с внутренними противоречиями. * Под прототипом обычно понимается действующий программный модуль, реализующий отдельные функции создаваемого ПО. Рис. 2.2. Эволюционная модель разработки Эволюционный подход часто более эффективен, чем подход, построенный на основе каскадной модели, особенно если требования заказчика могут меняться в процессе разработки системы. Достоинством процесса создания ПО, построенного на основе эволюционного подхода, является то, что здесь спецификация может разрабатываться постепенно, по мере того как заказчик (или пользователи) осознает и сформулирует те задачи, которые должно решать программное обеспечение. Вместе с тем данный подход имеет и некоторые недостатки. 1. Многие этапы процесса создания ПО не документированы. Менеджерам проекта создания ПО необходимо регулярно документально отслеживать выполнение работ. Но если система разрабатывается быстро, то экономически не выгодно документировать каждую версию системы. 2. Система часто получается плохо структурированной. Постоянные изменения в требованиях приводят к ошибкам и упущениям в структуре ПО. Со временем внесение изменений в систему становится все более сложным и затратным. 3. Часто требуются специальные средства и технологии разработки ПО. Это вызвано необходимостью быстрой разработки версий программного продукта. Но, с другой стороны, это может привести к несовместимости некоторых применяемых средств и технологий, что, в свою очередь, требует наличия в команде разработчиков специалистов высокого уровня. Считается, что эволюционный подход наиболее приемлем для разработки небольших программных систем (до 100 000 строк кода) и систем среднего размера (до 500 000 строк кода) с относительно коротким сроком жизни. На больших долгоживущих системах слишком заметно проявляются недостатки этого подхода. Для таких систем я рекомендую смешанный подход к созданию ПО, который вобрал бы в себя лучшие черты каскадной и эволюционной моделей разработки. При таком смешанном подходе для прояснения "темных мест" в системной спецификации можно использовать прототипирование. Часть системных компонентов, для которых полностью определены требования, может создаваться на основе каскадной модели. Другие системные компоненты, которые трудно поддаются специфицированию, например пользовательский интерфейс, могут разрабатываться с использованием прототипирования. 2.1.3. Формальная разработка систем Этот подход к созданию ПО имеет много черт, сходных с каскадной моделью, но построен на основе формальных математических преобразований системной спецификации в исполняемую программу. Процесс создания программного обеспечения в соответствии с этим подходом показан на рис. 2.3. Здесь для упрощения не указаны обратные связи между этапами процесса. Рис. 2.3. Модель формальной разработки ПО Между данным подходом и каскадной моделью существуют следующие кардинальные отличия. 1. Здесь спецификация системных требований имеет вид детализированной формальной спецификации, записанной с помощью специальной математической нотации. 2. Процессы проектирования, написания программного кода и тестирования системных модулей заменяются процессом, в котором формальная спецификация путем последовательных формальных преобразований трансформируется в исполняемую программу. Этот процесс показан на рис. 2.4. Рис. 2.4. Процесс формальных преобразований В процессе преобразования формальное математическое представление системы последовательно и математически корректно трансформируется в программный код, постепенно все более детализированный. Эти преобразования выполняются до тех пор, пока все позиции формальной спецификации не будут трансформированы в эквивалентную программу. Преобразования выполняются математически корректно – здесь не существует проблемы проверки соответствия спецификации и программы. Преимущество метода формальных преобразований, которое заключается в точном соответствии конечной программы спецификации, обеспечивается тем, что дистанция между последовательными преобразованиями значительно меньше дистанции между спецификацией и программой. Доказательство корректности программного кода для больших масштабируемых систем обычно очень длительно, а часто просто не выполнимо. В этом отношении метод формальных преобразований, состоящий из последовательности небольших формальных шагов, весьма привлекателен. Однако выбор для применения соответствующих формальных преобразований сложен и неочевиден. Наиболее известным примером метода формальных преобразований является метод "чистой комнаты" (Cleanroom), разработанный компанией IBM. Этот метод предполагает пошаговую разработку ПО, когда на каждом шаге применяется формальные преобразования. Это позволяет отказаться от тестирования отдельных программных модулей, а тестирование всей системы происходит после ее сборки. Как метод "чистой комнаты", так и другие методы формальных преобразований основываются на В методе. Все эти методы имеют несколько "врожденных" недостатков, а стоимость разработки ПО с помощью этих методов не намного отличается от стоимости разработок другими методами. Методы формальных преобразований обычно применяют для разработки систем, которые должны удовлетворять строгим требованиям надежности, безотказности и безопасности, так как они гарантируют соответствие созданных систем их спецификациям. Кроме разработки указанного типа систем, методы формальных преобразований не нашли широкого применения, поскольку требуют специальных знаний и опыта использования. Кроме того, для большинства систем эти методы не дают существенного выигрыша в стоимости или качестве по сравнению с другими методами разработки ПО. Основная причина заключается в том, что функционирование большинства систем с трудом поддается описанию методом формальных спецификаций, – при создании большинства программных систем большая часть усилий разработчиков уходит именно на создание спецификаций. 2.1.4. Разработка ПО на основе ранее созданных компонентов В большинстве программных проектов применяется повторное использование некоторых программных модулей. Это обычно случается там, где разработчики проекта знают о ранее созданных программных продуктах, в составе которых есть компоненты, приблизительно удовлетворяющие требованиям разрабатываемых компонентов. Эти компоненты модифицируются в соответствии с новыми требованиями и затем включается в состав новой системы. В эволюционной модели разработки, описанной в разделе 2.1.2, для ускорения процесса создания ПО повторное использование ранее созданных компонентов применяется достаточно часто. Неформальное решение о повторном использовании ранее созданных программных компонентов обычно принимается независимо от общего процесса создания ПО. Вместе с тем на протяжении нескольких последних лет все более широко применяется подход к созданию ПО, основанный именно на повторном использовании ранее созданных программных модулей. Этот подход основан на наличии большой базы существующих программных компонентов, которые можно интегрировать в создаваемую новую систему. Часто такими компонентами являются свободно продаваемые на рынке программные продукты, которые можно использовать для выполнения определенных специальных функций, таких как форматирование текста, числовые вычисления и т.п. Общая модель процесса разработки ПО с повторным использованием ранее созданных компонентов показана на рис. 2.5. В этом подходе начальный этап специфицирования требований и этап аттестации такие же, как и в других моделях процесса создания ПО. А этапы, расположенные между ними, имеют следующий смысл. 1. Анализ компонентов. Имея спецификацию требований, на этом этапе осуществляется поиск компонентов, которые могли бы удовлетворить сформулированным требованиям. Обычно невозможно точно сопоставить функции, реализуемые готовыми компонентами, и функции, определенные спецификацией требований. 2. Модификация требований. На этой стадии анализируются требования с учетом информации о компонентах, полученной на предыдущем этапе. Требования модифицируются таким образом, чтобы максимально использовать возможности отобранных компонентов. Если изменение требований невозможно, повторно выполняется анализ компонентов для того, чтобы найти какое-либо альтернативное решение. 3. Проектирование системы. На данном этапе проектируется структура системы либо модифицируется существующая структура повторно используемой системы. Проектирование должно учитывать отобранные программные компоненты и строить структуру в соответствии с их функциональными возможностями. Если некоторые готовые программные компоненты недоступны, проектируется новое ПО. 4. Разработка и сборка системы. Это этап непосредственного создания системы. В рамках рассматриваемого подхода сборка системы является скорее частью разработки системы, чем отдельным этапом. Рис. 2.5. Разработка ПО с повторным использованием ранее созданных компонентов Основные достоинства описываемой модели процесса разработки ПО с повторным использованием ранее созданных компонентов заключаются в том, что сокращается количество непосредственно разрабатываемых компонентов и уменьшается общая стоимость создаваемой системы. Вместе с тем при использовании этого подхода неизбежны компромиссы при определении требований; это может привести к тому, что законченная система не будет удовлетворять всем требованиям заказчика. Кроме того, при проведении модернизации системы (т.е. при создании ее новой версии) отсутствует возможность влиять на появление новых версий компонентов, используемых в системе, что значительно затрудняет сам процесс модернизации. 2.2. Итерационные модели разработки ПО Описанные модели процесса создания ПО имеют свои достоинства и недостатки. При создании больших систем, как правило, приходится использовать различные подходы к разработке разных частей системы, т.е. в целом к разработке системы применяются гибридные (смешанные) модели. Поэтому важную роль играет возможность выполнять отдельные процессы разработки подсистем и весь процесс создания ПО итерационно, когда в ответ на изменения требований повторно выполняются определенные этапы создания системы (чаще всего этапы проектирования и кодирования). В этом разделе я представлю две гибридные итерационные модели, сочетающие несколько различных подходов к разработке ПО и разработанные специально для поддержки итерационного способа создания ПО. 1. Модель пошаговой разработки, где процессы специфицирования требований, проектирования и написания кода разбиваются на последовательность небольших шагов, которые ведут к созданию ПО. 2. Спиральная модель разработки, в которой весь процесс создания ПО, от начального эскиза системы до ее конечной реализации, разворачивается по спирали. Существенным отличием итерационных моделей является то, что здесь процесс разработки спецификации протекает параллельно с разработкой самой программной системы. Более того, в модели пошаговой разработки полную системную спецификацию можно получить только после завершения самого последнего шага процесса создания ПО. Очевидно, что такой подход входит в противоречие с моделью приобретения ПО, когда полная системная спецификация является составной частью контракта на разработку системы. Поэтому, чтобы применять итерационные модели для разработки больших систем, которые заказываются "серьезными" организациями, например государственными агентствами, необходимо менять форму контракта, на что такие организации идут с большим трудом. 2.2.1. Модель пошаговой разработки В каскадной модели создания ПО определение требований осуществляется совместно с заказчиком до начала проектирования системы, точно так же системная архитектура должна быть создана до начала непосредственной реализации (кодирования) системы. Изменения в требованиях, сделанные на этапе написания кода, ведут к необходимости выполнения повторных работ по проектированию и кодированию системы. Вместе с тем к достоинствам каскадной модели можно отнести простоту управления процессом создания ПО (в рамках данной модели), а также наличие отдельных этапов проектирования и реализации, что приводит к созданию вполне работоспособных систем, в которых учтены все изменения в спецификации, сделанные уже во время самого процесса разработки ПО. В отличие от каскадной, в эволюционной модели можно отложить принятие окончательных решений о спецификации и структуре системы, однако это может привести к созданию плохо структурированной системы, которая будет также трудна в сопровождении. Модель пошаговой разработки находится где-то между этими моделями и объединяет их достоинства. Эта модель (рис. 2.6) была предложена Миллсом (Mills) как попытка уменьшить количество повторно выполняемых работ в процессе создания ПО и увеличить для заказчика временной период окончательного принятия решения обо всех деталях системных требований. Рис. 2.6. Модель пошаговой разработки В процессе пошаговой разработки заказчик сначала в общих чертах определяет те сервисы (функциональные возможности), которые должны присутствовать у создаваемой системы. При этом устанавливаются приоритеты, т.е. определяется, какие сервисы более важны, а какие – менее. Также определяется количество шагов разработки, причем на каждом шаге должен быть получен системный компонент, реализующий определенное подмножество системных функций. Распределение реализации системных сервисов по шагам разработки зависит от их приоритетов. Сервисы с более высокими приоритетами реализуются первыми. Последовательность шагов разработки определяется заранее до начала их выполнения. На первых шагах детализируются требования для сервисов, затем для их реализации (на последующих шагах) используется один из подходящих способов разработки ПО. В ходе их реализации анализируются и детализируются требования для компонентов, которые будут разрабатываться на более поздних шагах, причем изменение требований для тех компонентов, которые уже находятся в процессе разработки, не допускается. После завершения шага разработки получаем программный компонент, который передается заказчику для интегрирования в подсистему, реализующую определенный системный сервис. Заказчик может экспериментировать с готовыми подсистемами и компонентами для того, чтобы уточнить требования, предъявляемые к следующим версиям уже готовых компонентов или к компонентам, разрабатываемым на последующих шагах. По завершении очередного шага разработки полученный компонент интегрируется с ранее произведенными компонентами; таким образом, после каждого шага разработки система приобретает все большую функциональную завершенность. Общесистемные функции в этом процессе могут реализоваться сразу или постепенно, по мере разработки необходимых компонентов. В описываемой модели не предполагается, что на каждом шаге используется один и тот же подход к процессу разработки компонентов. Если создаваемый компонент имеет хорошо разработанную спецификацию, то для его создания можно применить каскадную модель. Если же требования определены нечетко, можно использовать эволюционную модель разработки. Процесс пошаговой разработки имеет целый ряд достоинств. 1. Заказчику нет необходимости ждать полного завершения разработки системы, чтобы получить о ней представление. Компоненты, полученные на первых шагах разработки, удовлетворяют наиболее критическим требованиям (так как имеют наибольший приоритет) и их можно оценить на самой ранней стадии создания системы. 2. Заказчик может использовать компоненты, полученные на первых шагах разработки, как прототипы и провести с ними эксперименты для уточнения требований к тем компонентам, которые будут разрабатываться позднее. 3. Данный подход уменьшает риск общесистемных ошибок. Хотя в разработке отдельных компонентов возможны ошибки, но эти компоненты должны пройти соответствующее тестирование и аттестацию, прежде чем их передадут заказчику. 4. Поскольку системные сервисы с высоким приоритетом разрабатываются первыми, а все последующие компоненты интегрируются с ними, неизбежно получается так, что наиболее важные подсистемы подвергаются более тщательному всестороннему тестированию и проверке. Это значительно снижает вероятность программных ошибок в особо важных частях системы. Вместе с тем при реализации пошаговой разработки могут возникнуть определенные проблемы. Компоненты, получаемые на каждом шаге разработки, имеют относительно небольшой размер (обычно не более 20 000 строк кода), но должны реализовать какую-либо системную функцию. Отобразить множество системных требований к компонентам нужного размера довольно сложно. Более того, многие системы должны обладать набором базовых системных свойств, которые реализуются совместно различными частями системы. Поскольку требования детально не определены до тех пор, пока не будут разработаны все компоненты, бывает весьма сложно распределить общесистемные функции по компонентам. В настоящее время предложен метод так называемого экстремального программирования (extreme programming), который устраняет некоторые недостатки метода пошаговой разработки. Этот метод основан на пошаговой разработке малых программных компонентов, реализующих небольшие функциональные требования, постоянном вовлечении заказчика в процесс разработки и обезличенном программировании. Имеются описания метода экстремального программирования и приведено несколько отчетов о его успешном применении, однако подобные отчеты можно привести для всех основных методов разработки ПО. 2.2.2. Спиральная модель разработки Спиральная модель процесса создания программного обеспечения (рис. 2.7) в настоящее время получила широкую известность и популярность. В отличие от рассмотренных ранее моделей, где процесс создания ПО представлен в виде последовательности отдельных процессов с возможной обратной связью между ними, здесь процесс разработки представлен в виде спирали. Каждый виток спирали соответствует одной стадии (итерации) процесса создания ПО. Так, самый внутренний виток спирали соответствует стадии принятия решения о создании ПО, на следующем витке определяются системные требования, далее следует стадия (виток спирали) проектирования системы и т.д. Каждый виток спирали разбит на четыре сектора. 1. Определение целей. Определяются цели каждой итерации проекта. Кроме того, устанавливаются ограничения на процесс создания ПО и на сам программный продукт, уточняются планы производства компонентов. Определяются проектные риски (например, риск превышения сроков или риск превышения стоимости проекта). В зависимости от "проявленных" рисков, могут планироваться альтернативные стратегии разработки ПО. 2. Оценка и разрешение рисков. Для каждого определенного проектного риска проводится его детальный анализ. Планируются мероприятия для уменьшения (разрешения) рисков. Например, если существует риск, что системные требования определены неверно, планируется разработать прототип системы. 3. Разработка и тестирование. После оценки рисков выбирается модель процесса создания системы. Например, если доминируют риски, связанные с разработкой интерфейсов, наиболее подходящей будет эволюционная модель разработки ПО с прототипированием. Если основные риски связаны с соответствием системы и спецификации, скорее всего, следует применить модель формальных преобразований. Каскадная модель может быть применена в том случае, если основные риски определены как ошибки, которые могут проявиться на этапе сборки системы. 4. Планирование. Здесь пересматривается проект и принимается решение о том, начинать ли следующий виток спирали. Если принимается решение о продолжении проекта, разрабатывается план на следующую стадию проекта. Существенное отличие спиральной модели от других моделей процесса создания ПО заключается в точном определении и оценивании рисков. Если говорить неформально, то риск – это те неприятности, которые могут случиться в процессе разработки системы. Например, если при написании программного кода используется новый язык программирования, то риск может заключаться в том, что компилятор этого языка может быть ненадежным или что результирующий код может быть не достаточно эффективным. Риски могут также заключаться в превышении сроков или стоимости проекта. Таким образом, уменьшение (разрешение) рисков – важный элемент управления системным проектом. В следующей лекции, посвященной управлению программными проектами, возможные риски и способы их разрешения рассматриваются более детально. Рис. 2.7. Спиральная модель создания ПО (© 1988 IEЕЕ) Первая итерация создания ПО в спиральной модели начинается с тщательной проработки системных показателей (целей системы), таких как эксплуатационные показатели и функциональные возможности системы. Конечно, альтернативных путей достижения этих показателей или целей можно сформировать бесконечно много. Но каждая альтернатива должна оценивать стоимость достижения каждой сформулированной цели. Результаты анализа возможных альтернатив служат источником оценки проектного риска. Это происходит на следующей стадии спиральной модели, где для оценки рисков используются более детальный анализ альтернатив, прототипирование, имитационное моделирование и т.п. С учетом полученных оценок рисков выбирается тот или иной подход к разработке системных компонентов, далее он реализуется, затем осуществляется планирование следующего этапа процесса создания ПО. В спиральной модели нет фиксированных этапов, таких как разработка спецификации или проектирование. Эта модель может включать в себя любые другие модели разработки систем. Например, на одном витке спирали может использоваться прототипирование для более четкого определения требований (и, следовательно, для уменьшения соответствующих рисков). Но на следующем витке может применяться каскадная модель. Если требования четко сформулированы, может применяться метод формальных преобразований. 2.3. Спецификация программного обеспечения В этом разделе, а также в трех последующих, рассматриваются основные базовые процессы создания ПО: формирование спецификации, разработка, аттестация и модернизация программных систем. Первый из этих процессов, формирование спецификации, предназначен для определения сервисов, которыми будет обладать проектируемое ПО, а также ограничений, накладываемых на функциональные возможности и разработку программной системы. Этот процесс в настоящее время обычно называют "разработка требований" (requirements engineering). Разработка требований часто является критическим этапом в создании ПО, поскольку ошибки, допущенные на этом этапе, ведут к возникновению проблем на этапах проектирования и разработки. Схема процесса разработки требований показана на рис. 2.8. Результатом его выполнения является разработка документации, формализующей требования, предъявляемые к системе, т.е. создание системной спецификации. В этой документации требования обычно представлены на двух уровнях детализации. На самом верхнем уровне представлены требования, определяемые конечными пользователями или заказчиками ПО; но для разработчиков необходима более детализированная системная спецификация. Рис. 2.8. Процесс разработки требований Процесс разработки требований включает четыре основных этапа. 1. Предварительные исследования. Оценивается степень удовлетворенности пользователей существующими программными продуктами и аппаратными средствами, а также экономическая эффективность будущей системы и возможность уложиться в существующие бюджетные ограничения при ее разработке. Этот этап должен быть по возможности коротким и дешевым. 2. Формирование и анализ требований. Формируются системные требования путем изучения существующих аналогичных систем, обсуждения будущей системы с потенциальными пользователями и заказчиками, анализа задач, которые должна решать система, и т.п. Этот этап может включать разработку нескольких моделей системы и ее прототипов, что помогает сформировать функциональные требования к системе. 3. Специфицирование требований. Осуществляется перевод всей совокупности информации, собранной на предыдущем этапе, в документ, определяющий множество требований. Этот документ обычно содержит два типа требований: пользовательские – обобщенные представления заказчиков и конечных пользователей о системе; системные – детальное описание функциональных показателей системы. 4. Утверждение требований. Проверяется выполнимость, согласованность и полнота множества требований. В процессе формирования ограничений неизбежно возникновение каких-либо ошибок. На этом этапе они должны быть по возможности выявлены и устранены. Конечно, процесс разработки требований трудно уложить в описанную последовательность этапов. Например, анализ требований выполняется на протяжении всего процесса их разработки, поэтому внесение новых или изменение уже сформулированных требований возможно на любом этапе. Как правило, этапы разработки требований перекрываются во времени. 2.4. Проектирование и реализация ПО Реализация программного обеспечения – это процесс перевода системной спецификации в работоспособную систему. Этап реализации всегда включает процессы проектирования и программирования, но если для разработки ПО применяется эволюционный подход, этап реализации также может включать процесс внесения изменений в системную спецификацию. На этапе проектирования ПО определяется его структура, данные, которые являются частью системы, интерфейсы взаимодействия системных компонентов и иногда используемые алгоритмы. Проектировщики сразу никогда не получают законченный результат – процесс проектирования обычно проходит через разработку нескольких промежуточных версий ПО. Проектирование предполагает последовательную формализацию и детализацию создаваемого ПО с возможностью внесения изменений в решения, принятые на более ранних стадиях проектирования. Процесс проектирования может включать разработку нескольких моделей системы различных уровней обобщения. Поскольку проектирование – это процесс декомпозиции, такие модели помогают выявить ошибки, допущенные на ранних стадиях проектирования, а следовательно, позволяют внести изменения в ранее созданные модели. На рис. 2.9 показана схема процесса проектирования ПО с указанием результата каждого этапа проектирования. Эта схема построена в предположении, что все этапы процесса проектирования выполняются последовательно. На практике эти этапы перекрываются вследствие неизбежных обратных связей от одного этапа к предыдущему и повторного выполнения некоторых проектных работ. Результатом каждого этапа проектирования является спецификация, необходимая для выполнения следующего этапа. Эта спецификация может быть абстрактной и формальной, т.е. такой, какая необходима для детализации системных требований; но она может быть и частью разрабатываемой системы. Так как процесс проектирования непрерывен, спецификации постепенно становятся все более детализированными. Конечными результатами процесса проектирования являются точные спецификации на алгоритмы и структуры данных, которые будут реализованы на следующем этапе создания ПО. Ниже перечислены отдельные этапы процесса проектирования. 1. Архитектурное проектирование. Определяются и документируются подсистемы и взаимосвязи между ними. 2. Обобщенная спецификация. Для каждой подсистемы разрабатывается обобщенная спецификация на ее сервисы и ограничения. 3. Проектирование интерфейсов. Для каждой подсистемы определяется и документируется ее интерфейс. Спецификации на эти интерфейсы должны быть точно выраженными и однозначными, чтобы использование подсистем не требовало знаний о том, как они реализуют свои функции. На этом этапе можно применить методы формальных спецификаций, рассмотренные в главе 9. 4. Компонентное проектирование. Проводится распределение системных функций (сервисов) по различным компонентам и их интерфейсам. 5. Проектирование структур данных. Детально разрабатываются структуры данных, необходимые для реализации программной системы. 6. Проектирование алгоритмов. Детально разрабатываются алгоритмы, предназначенные для реализации системных сервисов. Результаты проектирования Рис. 2.9. Обобщенная схема процесса проектирования Описанная схема процесса проектирования является достаточно общей и на практике может (и должна) адаптироваться применительно к разработке конкретного программного продукта. Например, два последних этапа, проектирование структур данных и алгоритмов, могут быть как составными частями процесса проектирования, так и входить в процесс реализации ПО. Если для создания программной системы используются некоторые уже готовые компоненты, это может наложить ограничения на архитектуру системы и интерфейсы системных модулей. Это означает, что количество компонентов, требующих проектирования, значительно уменьшится. Если в процессе проектирования используется метод проб и ошибок, то системные интерфейсы могут разрабатываться после определения структур данных. 2.4.1. Методы проектирования Во многих проектах разработки ПО процесс проектирования выполняется с помощью специально подобранных методов. Отталкиваясь от множества требований, обычно записанных естественным языком, сначала выполняется неформальное проектирование. Комментарии к программному коду и промежуточные спецификации могут изменяться в процессе реализации системы. После завершения стадии реализации (т.е. программирования и отладки системы) в проектную документацию также вносятся изменения, призванные устранить ошибки и неполноту описания системы в первоначальной спецификации. Наиболее разработанным подходом к проектированию ПО обладают так называемые структурные методы, которые предлагают множество формализованных нотаций и нормативных руководств для проектирования программных продуктов. В качестве примера этих методов можно назвать структурное проектирование, структурный анализ систем, разработку систем Джексона (Jackson), а также разнообразные методы, основанные на объектно-ориентированном подходе. Применение структурных методов обычно приводит к созданию графических моделей системы и большому объему проектной документации. CASE-средства предназначены для поддержки именно таких методов. Структурные методы успешно применялись во многих программных проектах. Они значительно снижают стоимость разработки, поскольку используют стандартные нотации для получения стандартной проектной документации. Ни об одном из этих методов нельзя сказать, что он лучше или хуже других. Успешное или неуспешное применение того или иного метода часто зависит от типа разрабатываемого ПО. Каждый структурный метод включает такие компоненты, как модель процесса проектирования, стандартизованные нотации для представления структуры системы, форматы отчетов, правила и нормативные указания по проектированию. Хотя разработано большое количество таких методов, они имеют нечто общее. Структурные методы поддерживают все или по крайней мере некоторые из перечисленных ниже моделей систем. 1. Модель потоков данных, где система моделируется в виде потока данных, преобразуемых в этой системе. 2. Модель "сущность-связь", которая применяется для описания сущностей (объектов программной системы) и связей между ними. Эта модель часто используется при проектировании структур баз данных. 3. Структурная модель, предназначенная для документирования системных компонентов и их взаимосвязей. 4. Объектно-ориентированные методы, с помощью которых получают иерархическую модель системы, модели статических и динамических отношений между объектами и модель взаимодействия объектов во время работы системы. Некоторые структурные методы дополняются другими системными моделями, такими как диаграммы переходов (из одного состояния в другое) или сценарии жизни сущностей, которые показывают последовательность преобразований для каждой сущности. Многие методы предполагают наличие централизованных хранилищ (репозиториев) для системной информации или словарей используемых данных. На практике методы представляют нормативные руководства неформально, так что различные проектировщики могут реализовать разные пути проектирования. Фактически эти "методы" являются набором стандартных нотаций и просто отображают успешную практику проектирования. Следуя этим методам и их нормативным руководствам, можно прийти к рациональному и разумному процессу проектирования. Вместе с тем творчество проектировщиков должно проявиться в способе декомпозиции системы, адекватно отображающей системные требования. С другой стороны, проведенные исследования труда проектировщиков показали, что чаще всего они просто слепо следуют этим методам. Да и сами методы они выбирают в зависимости от частных обстоятельств, а не в соответствии с их достоинствами или недостатками. 2.4.2. Программирование и отладка Процесс программирования (написания программного кода, кодирования) обычно следует непосредственно за процессом проектирования. Но для некоторых классов программ, например критических по надежности систем, последняя стадия проектирования (детальное проектирование) и начало кодирования могут перекрываться. В процессе проектирования могут использоваться CASEсредства, которые позволяют получить скелетную программу. Такая программа содержит код для определения и реализации интерфейсов, и во многих случаях программисту остается только добавить код, реализующий некоторые детали функционирования программного компонента. Программирование – индивидуальный процесс, здесь не существует общих правил, которым необходимо следовать при написании программного кода. Некоторые программисты начинают кодирование с компонентов, которые они хорошо понимают, оставляя напоследок кодирование компонентов, которые являются для них "темными". Другие применяют противоположный подход, оставляя простые для них компоненты на потом. Обычно программисты сами тестируют написанный ими программный код для обнаружения возможных ошибок и программных дефектов. Этот процесс называется отладкой программы. В принципе тестирование и отладка являются разными процессами. При тестировании устанавливается наличие программных ошибок. В ходе отладки устанавливается местоположение ошибок, затем они устраняются. На рис. 2.10 показан возможный процесс отладки программы. Отладка может быть частью как процесса разработки, так и процесса тестирования ПО. Проводящий отладку программист должен сгенерировать такие режимы работы системы, которые помогут обнаружить программные ошибки по аномальному поведению системы. Локализация ошибок может потребовать проведения ручной трассировки кода программы. В процессе тестирования и отладки могут помочь отладочные средства, показывающие значения программных переменных и выполняющие трассировку исполняемых операторов. Рис. 2.10. Процесс отладки 2.5. Аттестация программных систем Аттестация ПО, или более обобщенно – верификация и аттестация, предназначена показать соответствие системы ее спецификации, а также ожиданиям и требованиям заказчика и пользователей. К процессу аттестации также можно отнести элементы контроля, такие как инспекция и оценивание, которые выполняются на каждом этапе создания ПО – от формирования общих требований до кодирования программ. Но все-таки основные действия по аттестации выполняются после завершения реализации на этапе тестирования законченной системы. За исключением небольших программ, программные системы невозможно протестировать как единый цельный программный элемент. Большие системы строятся на основе подсистем, которые, в свою очередь, строятся из модулей, модули же компонуются из программ-процедур и программ функций. Для таких систем процесс тестирования выполняется постепенно, по мере реализации системы. Рис. 2.11. Процесс тестирования На рис. 2.11 показан пятиэтапный процесс тестирования, где сначала тестируются отдельные программные компоненты и подсистемы, затем собранная система и наконец система с данными, предоставляемыми заказчиком. В идеале ошибки в программных компонентах должны обнаруживаться и исправляться еще в процессе их кодирования, а ошибки и упущения в интерфейсах – во время сборки системы. Но, поскольку после обнаружения любых программных ошибок необходимо выполнить отладку программы, это приводит к необходимости повторения некоторых этапов тестирования. Например, если программная ошибка проявилась на этапе сборки системы, необходимо повторить процесс тестирования того программного компонента, в котором обнаружена эта ошибка. Поэтому процесс тестирования итерационный, с обратной передачей информации с последующих этапов на предыдущие. Процесс тестирования состоит из нескольких этапов. 1. Тестирование компонентов. Тестируются отдельные компоненты для проверки правильности их функционирования. Каждый компонент тестируется независимо от других. 2. Тестирование модулей. Программный модуль – это совокупность зависимых компонентов, таких как описание класса объектов, декларирование абстрактных типов данных и набор процедур и функций. Каждый модуль тестируется независимо от других системных модулей. 3. Тестирование подсистем. Тестируются наборы модулей, которые составляют отдельные подсистемы. Основная проблема, которая часто проявляется на этом этапе, – несогласованность модульных интерфейсов. Поэтому при тестировании подсистем основное внимание уделяется обнаружению ошибок в модульных интерфейсах путем прогона их через все возможные режимы. 4. Тестирование системы. Из подсистем собирается конечная система. На этом этапе основное внимание уделяется совместимости интерфейсов подсистем и обнаружению программных ошибок, которые проявляются в виде непредсказуемого взаимодействия между подсистемами. Здесь также проводится аттестация системы, т.е. проверяется соответствие системной спецификации ее функциональных и нефункциональных показателей, а также оцениваются интеграционные характеристики системы. 5. Приемочные испытания. Это конечный этап процесса тестирования, после которого система принимается к эксплуатации. Здесь система тестируется с привлечением данных, предоставляемых заказчиком системы, а не на основе тестовых данных, как было на предыдущем этапе. На этом этапе могут проявиться ошибки, допущенные еще на этапе определения системных требований, поскольку испытания с реальными данными могут дать иной результат, чем тестирование со специально подобранными тестовыми данными. Приемочные испытания могут также выявить другие проблемы в системных требованиях, если реальные системные характеристики не отвечают потребностям заказчика или система функционирует непредвиденным образом. Тестирование программных компонентов и модулей обычно выполняется тем программистом, который их разрабатывал. Программисты имеют собственные наборы тестовых данных и тестируют программный код постепенно, по мере его создания. Такой подход к тестированию отдельных компонентов и модулей вполне оправдан, поскольку никто лучше программиста, разработавшего программный компонент, его не знает, и поэтому он может подобрать наилучшие тестовые данные. Тестирование программных элементов можно рассматривать как часть процесса их создания, поэтому мы вправе ожидать точного соответствия этих элементов и их спецификаций. Последние этапы тестирования выполняются в процессе сборки системы, к которой привлекается несколько программистов. Поэтому эти работы должны быть спланированы заранее. Если тестирование выполняет независимая команда испытателей, планы проведения тестирования должны быть согласованы с этапами разработки спецификации и проектирования. На рис. 2.12 показано, как планы тестирования могут быть связаны с другими процессами разработки ПО. Рис. 2.12. Этапы тестирования в процессе разработки ПО Приемочные испытания иногда называют альфа-тестированием. Сделанные на заказ системы предназначены для одного заказчика. Для таких систем процесс альфа-тестирования продолжается до тех пор. пока разработчики и заказчик не удостоверятся в том, что разработанная система полностью соответствует системным требованиям. Если система разрабатывается для продажи на рынке программных продуктов, используется так называемое бета-тестирование. Для бета-тестирования система рассылается большому числу потенциальных пользователей и заказчиков. Они отсылают разработчикам отчеты о выявленных проблемах в эксплуатации системы. Бета-тестирование позволяет проверить систему в реальных условиях эксплуатации и найти ошибки, пропущенные разработчиками. После получения отчетов об испытаниях система модернизируется и снова передается на бета-тестирование либо сразу поступает в продажу. 2.6. Эволюция программных систем Одна из основных причин того, что в настоящее время в большие сложные системы все шире внедряется программное обеспечение, заключается в гибкости программных систем. После принятия решения о разработке и производстве аппаратных компонентов системы внесение в них изменений становится весьма дорогостоящим. С другой стороны, в программное обеспечение можно вносить изменения в течение всего процесса разработки системы. Эти изменения также могут быть крайне дорогостоящими, но все-таки они значительно дешевле изменений в аппаратном оборудовании системы. Исторически сложилось так, что существует четкая "демаркационная линия" между процессом разработки системы и процессом ее совершенствования, точнее, процессом сопровождения системы. Разработка системы рассматривается как творческий процесс, начиная с этапа выработки общей концепции системы и заканчивая получением работающего программного продукта. Сопровождение системы – это внесение изменений в систему, которая уже находится в эксплуатации. И хотя стоимость сопровождения может в несколько раз превышать стоимость разработки, все равно процесс сопровождения считается менее творческим и ответственным, чем процесс первоначального создания системы. В настоящее время упомянутая демаркационная линия между процессами разработки и сопровождения постепенно стирается. Только немногие вновь созданные программные системы можно назвать полностью новыми. Поэтому имеет смысл рассматривать процесс сопровождения как непрерывное продолжение процесса разработки. Вместо двух отдельных процессов рациональнее принять эволюционный подход инженерии программного обеспечения, где программные продукты в течение своего жизненного цикла непрерывно изменяются (эволюционируют) в ответ на изменения в системных требованиях и потребностях пользователей. Схема этого эволюционного процесса программных систем показана на рис. 2.13. Рис. 2.13. Эволюция систем 2.7. Автоматизированные средства разработки ПО Аббревиатура CASE (Computer-aided Software Engineering – автоматизированная разработка ПО) обозначает специальный тип программного обеспечения, предназначенного для поддержки таких процессов создания ПО, как разработка требований, проектирование, кодирование и тестирование программ. Поэтому к CASE-средствам относятся редакторы проектов, словари данных, компиляторы, отладчики, средства построения систем и т.п. CASE-технологии предлагают поддержку процесса создания ПО путем автоматизации некоторых этапов разработки, а также создания и предоставления информации, необходимой для разработки. Приведем примеры тех процессов, которые можно автоматизировать с помощью CASE-средств. 1. Разработка графических моделей системы на этапах создания спецификации и проектирования. 2. Проектирование структуры ПО с использованием словарей данных, хранящих информацию об объектах структуры и связях между ними. 3. Генерирование пользовательских интерфейсов на основе графического описания интерфейса, создаваемого в диалоговом режиме. 4. Отладка программ на основе информации, получаемой в ходе выполнения программы. 5. Автоматическая трансляция программ, написанных на устаревших языках программирования (например, COBOL), в программы, написанные на современных языках. В настоящее время подходящие CASE-технологии существуют для большинства процессов, выполняемых в ходе разработки ПО. Это ведет к определенному улучшению качества создаваемых программ и повышению производительности труда разработчиков программного обеспечения. Вместе с тем эти достижения значительно уступают тем ожиданиям, которые присутствовали при зарождении CASE-технологии. Тогда считалось, что стоит только внедрить CASE-средства – и можно получить весьма значительное повышение и качества программ, и производительности труда. Фактически это повышение составляет примерно 40%. Хотя и это повышение весьма значительно, CASE-технологии не совершили революции в инженерии программного обеспечения, как ожидалось. Расширение применения CASE-технологии ограничивают два фактора. 1. Создание ПО, особенно этап проектирования, во многом является творческим процессом. Существующие CASE-средства автоматизируют рутинные процессы, попытки привлечь их к решению интеллектуальных и творческих задач проектирования особым успехом не увенчались. 2. Во многих организациях-разработчиках создание ПО – результат работы команды специалистов по программному обеспечению. При этом много времени тратится на "пустое" общение между членами команды разработчиков. В этой ситуации CASE-технологии не могут предложить ничего такого, что способно повысить производительность труда разработчиков. Отомрут ли эти факторы в будущем, пока неясно. Я считаю маловероятным появление CASE-технологии, поддерживающих творческие элементы процесса проектирования систем и коллективный труд команды разработчиков. Однако системы поддержки общего процесса проектирования и групповой работы существуют и используются в процессе создания ПО. В настоящее время сложилась развитая индустрия CASE-средств, круг возможных поставщиков и разработчиков этих программных продуктов очень широк. Вместо того чтобы детально рассматривать отдельные CASE-продукты, здесь будет сделан их обзор 3.7.1. Классификация CASE-средств Классификация CASE-средств помогает понять их основные типы и роль, которую они играют в поддержке процессов создания программного обеспечения. Существует несколько различных классификаций CASE-средств, и каждая предлагает свой взгляд на эти программные продукты. В этом разделе рассматриваются следующие классификации. 1. Классификация по выполняемым функциям. 2. Классификация по типам процессов разработки, которые они поддерживают. 3. Классификация по категориям, где CASE-средства классифицируются по степени интеграции программных модулей, поддерживающих различные процессы разработки. В табл. 2.1 представлена классификация по выполняемым функциям с примерами соответствующих CASE-средств. Это неполный список типов CASE-средств, в частности здесь не представлены средства поддержки повторного использования программных компонентов. В табл. 2.2 представлена другая классификация CASE-средств. Классификация по типам показывает, какие процессы создания ПО поддерживаются теми или иными CASE-средствами. Средства планирования и оценивания, редактирования текстов, подготовки документации и управления конфигурацией можно использовать на всех этапах разработки ПО. Таблица 2.1. Классификация CASE-средств по выполняемым функциям Средства планирования Средства редактирования Средства управления изменениями Средства управления конфигурацией** Средства прототипирования Средства, ориентированные на поддержку определенных методов Средства, ориентированные на определенные языки программирования Средства анализа программ Средства тестирования Средства отладки Средства документирования Средства модернизации ПО Средства системы PERT*, средства оценивания, электронные таблицы Текстовые редакторы, редакторы диаграмм, тестовые процессоры Средства оперативного контроля за требованиями, системы управления изменениями Системы управления версиями ПО, средства построения систем Языки программирования самого высокого уровня, генераторы пользовательских интерфейсов Редакторы системных структур, словари данных, генераторы программного кода Компиляторы, интерпретаторы Генераторы перекрестных ссылок, статические и динамические анализаторы программ Генераторы тестовых данных, компараторы*** файлов Интерактивные средства отладки Программы разметки страниц, редакторы изображений, генераторы отчетов Системы создания перекрестных ссылок, системы модернизации * PERT (Program Evaluation and Review Technique) - известная система планирования и руководства разработками программных систем. ** Конфигурацией ПО называется совокупность его функциональных характеристик и физических показателей, зафиксированная в системной спецификации. *** Компараторы - специальные программы сравнения каких-либо объектов. В данном случае имеются в виду программы сравнения файлов, содержащих программный код. Таблица 2.2. Классификация CASE-средств по типам поддерживаемых ими процессов разработки Специфицирование Проектирование Реализация Аттестация Средства модернизации ПО • Средства тестирования • • Средства отладки • • Средства анализа программ • • Средства, ориентированные на определенные языки программирования • • Средства, ориентированные на поддержку определенных методов • • Средства протопипирования • • Средства управления конфигурацией • • Средства управления изменениями • • • • Средства документирования • • • • Средства редактирования • • • • Другая классификация CASE-средств строится на основе широты охвата процессов разработки ПО, поддерживаемых данным средством. Еще одна классификация, содержащая следующие три категории*. * В литературе по CASE-технологиям можно встретить и другую классификацию CASE-средств по категориям: вспомогательные программы (tools), инструментальные пакеты разработчика (toolkits) и автоматизированные рабочие места разработчика (workbenches). По существу, эта классификация совпадает с приведенной, различия только в названиях категорий. 1. Вспомогательные программы (tools) поддерживают отдельные процессы разработки ПО, такие как проверка непротиворечивости архитектуры системы, компиляция программ, сравнение результатов тестов и т.п. Вспомогательные программы могут быть универсальными функционально-законченными средствами (например, текстовой процессор) или могут входить в состав инструментальных средств. 2. Инструментальные средства (workbenches) поддерживают определенные процессы разработки ПО, например создание спецификации, проектирование и т.д. Обычно инструментальные средства являются набором вспомогательных программ, которые в большей или меньшей степени интегрированы. 3. Рабочие среды разработчика (environments) поддерживают все или большинство процессов разработки ПО. Рабочие среды обычно включают несколько различных интегрированных инструментальных средств. Рис. 2.14. Классификация CASE-средств по категориям На рис. 2.14 схематично представлена классификация по категориям с примерами CASE-средств разных категорий. Разумеется, на одной схеме невозможно показать все типы вспомогательных программ и инструментальных средств, многие из них здесь не представлены. Необходимые отдельные вспомогательные программы выбираются разработчиком ПО обычно по своему усмотрению. Инструментальные средства, как правило, поддерживают определенные методы разработки в соответствии с некоторой моделью процесса создания ПО и содержат наборы правил и нормативных указаний, которыми следует руководствоваться в процессе разработки. Рабочие среды разработчика я разделил на интегрированные и экспертные. Интегрированные рабочие среды предоставляют инфраструктуру поддержки для данных, управления и интеграции системных представлений. Экспертные рабочие среды более интеллектуальны. Они включают базу знаний о процессах создания ПО и механизм, который в соответствии с выбранной моделью процесса создания ПО предлагает разработчику для применения те или иные вспомогательные программы и инструментальные средства. На практике границы между CASE-средствами разных категорий размыты. Вспомогательную программу можно приобрести как отдельный продукт, но она может использоваться для поддержки различных процессов разработки. Например, большинство текстовых процессоров в настоящее время располагают встроенными редакторами диаграмм; или инструментальные CASE-средства для проектирования все чаще предлагают поддержку процессам программирования и тестирования, тем самым приближаясь к рабочим средам. Поэтому не всегда можно легко позиционировать какой-либо CASE-продукт по категориям в соответствии с этой классификацией. Вместе с тем классификация по категориям полезна для понимания того, насколько широк диапазон процессов разработки, которые могут быть поддержаны тем или иным CASE-средством. КЛЮЧЕВЫЕ ПОНЯТИЯ • Процесс создания программного обеспечения – это совокупность процессов, выполняемых при разработке программных продуктов. Модели процесса создания ПО – абстрактные представления этих процессов. • Любой процесс создания программного обеспечения включает этапы разработки системной спецификации, проектирования и реализации, аттестации и модернизации ПО. • Обобщенные модели создания ПО описывают организацию процесса разработки программных систем. К таким моделям относятся: каскадная модель, эволюционная модель разработки, модель формальной разработки систем и модель разработки ПО на основе ранее созданных компонентов. • Итерационные модели разработки ПО представляют процесс создания программных систем в виде повторяющихся циклов определенных этапов разработки. Достоинством данного подхода является возможность избежать преждевременного и до конца не продуманного утверждения системной спецификации и результатов проектирования. Примерами итерационных моделей служат модель пошаговой разработки и спиральная модель. • Определение требований – это процесс разработки системной спецификации. • Проектирование и реализация – это процессы преобразования системной спецификации в систему исполняемых программ. • Аттестация программного обеспечения – процесс проверки соответствия разработанной системы ее спецификации и потребностям пользователей. • Эволюция программного обеспечения – это модернизация существующих программных систем в соответствии с новыми требованиями. В настоящее время этот процесс становится одним из этапов разработки небольших и среднего размера программных систем. • CASE-технологии обеспечивают автоматизированную поддержку процессов создания ПО. Взспомогательные CASE-программы поддерживают отдельные процессы разработки; инструментальные CASE-средства поддерживают некоторое множество взаимосвязанных процессов разработки; рабочие CASE-среды обеспечивают поддержку всех или большинства процессов, выполняемых при создании ПО.