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

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

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

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

2. Создание программного обеспечения. Разработка и создание ПО согласно спецификации на него.

3. Аттестация программного обеспечения. Созданное ПО должно пройти аттестацию для подтверждения соответствия требованиям заказчика.

4. Совершенствование (модернизация) программного обеспечения. ПО должно быть таким, чтобы его можно было модернизировать согласно измененным требованиям потребителя.

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

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

 

Модель процесса создания ПО

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

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

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

Опишем кратко типы моделей технологического процесса создания программного обеспечения.

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

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

 

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

Рассмотрим следующие модели создания программного обеспечения.

1. Каскадная модель. Основные базовые виды деятельности, выполняемые в процессе создания ПО (такие, как разработка спецификации, проектирование и производство, аттестация и модернизация ПО), представляются как отдельные этапы этого процесса.

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

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

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

Каскадная и эволюционная модели разработки широко используются на практике. Модель формальной разработки систем успешно применялась во многих проектах [219, 239, 8 *, 18 *], но количество организаций-разработчиков, постоянно используют этот метод, невелика. Использование готовых системных компонентов практикуется повсеместно, но большинство организаций не соблюдают в точности модели разработки ПО на основе ранее созданных компонентов. Вместе с тем этот метод должен получить широкое распространение в XXI веке, поскольку составление систем из готовых или ранее использованных компонентов значительно ускоряет разработку ПО.

 

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

Это первая модель процесса создания ПО, порожденная моделями других инженерных процессов [300]. Она показана на рис. 3.1. Эту модель также иногда называют моделью жизненного цикла программного обеспечения *. Основные принципиальные этапы (стадии) этой модели отражают все базовые виды деятельности, необходимые для создания ПО.

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

 

 

 

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

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

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

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

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

 

Рис. 1. Жизненный цикл программного обеспечения

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

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

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

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

 

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

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

Наиболее известным примером метода формальных преобразований является метод "чистой комнаты" (Cleanroom), разработанный компанией IBM [239, 310, 219, 284]. Об этом говорит сайт https://intellect.icu . Этот метод предусматривает пошаговую разработку ПО, когда на каждом шагу применяется формальные преобразования. Это позволяет отказаться от тестирования отдельных программных модулей, а тестирование всей системы происходит после ее сборки. Этот подход более подробно рассмотрены в главе 19.

Как метод "чистой комнаты", так и другие методы формальных преобразований основываются на В-методе [348]. Все эти методы имеют несколько "врожденных" недостатков, а стоимость разработки ПО с помощью этих методов не намного отличается от стоимости разработок другими методами. Методы формальных преобразований обычно применяют для разработки систем, которые должны удовлетворять строгим требованиям надежности, безотказности и безопасности, так как они гарантируют соответствие созданных систем их спецификациям.

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

Разработка на основе ранее созданных компонентов

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

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

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

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

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

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

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

4. Разработка и сборка системы. Это этап непосредственного создания системы. В рамках рассматриваемого подхода сборка системы является скорее частью разработки системы, чем отдельным этапом.

 

 

 

Рис. 5. Разработка с повторным использованием ранее созданных компонентов

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

 

Итерационные модели разработки ПО

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

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

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

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

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

 

 

Рис. 6. Модель пошаговой разработки

 
 

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

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

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

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

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

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

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

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

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

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

 

  
В настоящее время предложен метод так называемого экстремального программирования (extreme programming), который устраняет некоторые недостатки метода пошаговой разработки. Этот метод основан на пошаговой разработке малых программных компонентов, реализующих небольшие функциональные требования, постоянном привлечении заказчика в процесс разработки и обезличенном программировании (см. Главу 23). В статье [31] описан метод экстремального программирования и приведены несколько отчетов о его успешном применении, однако подобные отчеты можно привести для всех основных методов разработки ПО.

 

Спиральная модель разработки

 
Спиральная модель процесса создания программного обеспечения (рис. 3.7) была впервые предложена в статье [47] и в настоящее время получила широкую известность. В отличие от рассмотренных ранее моделей, где процесс создания ПО представлен в виде последовательности отдельных процессов с возможной обратной связью между ними, здесь процесс разработки представлен в виде спирали. Каждый виток спирали соответствует одной стадии (итерации) процесса создания ПО. Так, самый внутренний виток спирали соответствует стадии принятия решения о создании ПО, на следующем витке определяются системные требования, далее идет стадия (виток спирали) проектирование системы и т.д.

 

 

 

Каждый виток спирали разбит на 4 сектора.

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

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

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

4. Планирование. Здесь просматривается проект и принимается решение о том, начинать следующий виток спирали. Если принимается решение о продолжении проекта, разрабатывается план на следующую стадию проекта.

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

 

Рис. 7 Спиральная модель создания ПО (© +1988 IEЕЕ)

 

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

 

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

 

 

Формальная разработка систем

 

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

 

Рис. 3.3. Модель формальной разработки ПО

 

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

 

1. Здесь спецификация системных требований имеет вид детализированной формальной спецификации, записанной с помощью специальной математической нотации.

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

 

Рис. 3.4. Процесс формальных преобразований

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

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

Наиболее известным примером метода формальных преобразований является метод "чистой комнаты" (Cleanroom), разработанный компанией IBM [239, 310, 219, 284]. Этот метод предполагает пошаговую разработку ПО, когда на каждом шаге применяется формальные преобразования. Это позволяет отказаться от тестирования отдельных программных модулей, а тестирование всей системы происходит после ее сборки. Этот подход более подробно рассмотрен в главе 19.

Как метод "чистой комнаты", так и другие методы формальных преобразований основываются на В-методе [348]. Все эти методы имеют несколько "врожденных" недостатков, а стоимость разработки ПО с помощью этих методов не намного отличается от стоимости разработок другими методами. Методы формальных преобразований обычно применяют для разработки систем, которые должны удовлетворять строгим требованиям надежности, безотказности и безопасности, так как они гарантируют соответствие созданных систем их спецификациям.

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

 

Методы инженерии ПО

 
Методы инженерии ПО - это эвристические методы (heuristic methods), формальные методы (formal methods) и методы прототипирования (prototyping methods).

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

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

- Языка и нотации спецификации (specification languages ​​and notations), ориентированные на модель, свойства и поведение;

- Уточнение спецификации (refinement specification) путем трансформации в конечный результат, близкий к конечному программного продукта выполняется;

- Методы верификации / доказывания (verification / proving properties), которые используют утверждение (теоремы), пред- и постусловия, формально описываются и применяются для установления правильности спецификации программ. Методы доказательства применялись в основном в теоретических экспериментах. Более 25 лет их применение было ограничено из-за трудоемкости и экономической невыгодности. В 2005г. Проблема верификации вновь обрела актуальность в предложенном новом международном проекте «Целостный автоматизированный набор инструментов для проверки корректности ПС» (Т. Хоара, «Открытые системы», 2006, № 6), который поставил следующие перспективные задачи:

- Разработка единой теории построения и анализа программ;

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

- Создание репозитария формальных спецификаций, верифицированных программных объектов разных типов и видов.

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

Методы прототипирования (Prototyping Methods) основаны на использовании прототипа ПО для моделирования на нем задач новой системы и базируются на:

- Стилях прототипирования, олицетворяющих продолжительность использования прототипов, например, стиль создания временно используемых прототипов (throw away),

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

- Техниках оценки / исследования (evaluation) результатов прототипирования.

 

Инструменты инженерии ПО

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

Инструменты работы с требованиями (Software Requirements Tools) - это:

- Инструменты разработки (Requirement Development) и управления требованиями (Requirement Management), ориентированные на анализ, сбор, специфицирования и проверку требований;

- Инструменты трассировки требований (Requirement traceability tools) являются неотъемлемой частью работы с требованиями, их функциональное содержание зависит от сложности проектов и уровня зрелости процессов.

Инструменты проектирования (Software Design Tools) - это инструменты для создания ПО с применением базовых нотаций (структурной SADT / IDEF, моделирования UML и т.п.).

Инструменты конструирования ПО (Software Construction Tools) - это инструменты для трансляции и объединения программ. К ним относятся:

- Редакторы программ (program editors) и программы редактирования общего назначения;

- Компиляторы и генераторы кода (compilers and code generators) как самостоятельные средства объединения программных компонентов в интегрированной среде для получения исходного продукта с использованием препроцессоров, сборщиков, загрузчиков и др .;

- Интерпретаторы (interpreters), которые обеспечивают контролируемое выполнение программ по их описанием. Наметилась тенденция слияния интерпретаторов и компиляторов (например, Java, в .NET);

- Отладчик (debuggers), предназначенные для проверки правильности описания исходных программ и устранения ошибок;

- Интегрированная среда разработки (IDE - integrated development environment) и библиотеки компонентов (libraries components), что образуют среду выполнения процесса разработки ПО;

- Программные платформы (Java, J2EE и Microsoft .NET) и платформы для распределенных вычислений (CORBA и WebServices и т.д.).

Инструменты тестирования (Software Testing Tools) - это:

- Генераторы тестов (test generators), помогающие в разработке сценариев тестирования;

- Средства выполнения тестов (test execution frameworks), которые обеспечивают выполнение тестовых сценариев и отслеживают поведение объектов тестирования;

- Инструменты оценки тестов (test evaluation tools), которые поддерживают оценивания результатов выполнения тестов и степени соответствия поведения тестируемого объекта ожидаемой поведения;

- Средства управления тестами (test management tools), которые обеспечивают инженерное управление процессом тестирования ПО;

- Инструменты анализа производительности (performance analysis tools), количественной ее оценки и оценки поведения программ в процессе выполнения.

Инструменты сопровождения (Software Maintenance Tools) включают в себя:

- Инструменты облегчения понимания (comprehension tools) программ, например, различные средства визуализации;

- Инструменты реинженерии (reengineering tools) поддерживают деятельность по преобразованию программ и обратной инженерии (reverse engineering) для восстановления (артефактов, спецификации, архитектуры) устаревшего ПО или генерации нового продукта.

Инструменты конфигурационного управления (Software Configuration Management Tools) - это:

- Инструменты отслеживания (tracking) дефектов;

- Инструменты управления версиями;

- Инструменты управления сборкой, выпуском версии (конфигурации) продукта и его инсталляции.

Инструменты управления инженерной деятельностью (Software Engineering Management Tools) подразделяются на:

- Инструменты планирования и отслеживания хода проектов, количественной оценки усилий и стоимости работ по проекту (например, Microsoft Project 2003);

 

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

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

Инструменты поддержки процессов (Software Engineering Process Tools) разделены на:

- Инструменты моделирования и описания моделей ПО (например, UML и его инструменты)

- Инструменты управления программными проектами (например, Microsoft Project)

- Инструменты управления конфигурацией для поддержки версий и всех артефактов проекта.

Инструменты обеспечения качества (Software Quality Tools) делятся на две категории:

- Инструменты инспектирования для поддержки просмотра (review) и аудита;

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

Дополнительные аспекты инструментального обеспечения (Miscellaneous Tool Issues) касаются:

- Техники интеграции инструментов (платформ, представлений, процессов, данных) для их естественного сообщения в интегрированной среде;

- Метаинструментив для генерации других инструментов для ПО;

- Оценки инструментов при их эволюции.

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