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


1. Процесс создания ПО

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

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

2. Проектирование и реализация ПО.

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

4. Эволюция ПО. Доработка с новыми требованиями.

2. Модели создания ПО.

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

Существуют следующие модели создания ПО:

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

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

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

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

 

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

Определение требований
Проектирование системы и ПО
Кодирование и тестирование программных моделей
Сборка и тестирование системы
Эксплуатация и сопровождение

 


Эту модель также называют моделью жизненного цикла ПО.

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

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

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

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

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

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

4. Эволюционная модель.

5) Начальная версия
 
 
2, 3, 4 – параллельные

6) Промежуточные версии
2) Специфицирование
1) Эскизное описание
процессы

7) Конечная версия
3) Разработка
4) Аттестация

 

 


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

Различают два подхода к реализации эволюционного метода разработки:

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

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

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

- многие этапы процесса создания ПО недокументированны;

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

- система часто получается плохо структурированной;

Постоянные изменения в требованиях приводят к ошибкам и упущениями в структуре ПО. Со временем внесение изменений в систему становится все более сложным и затратным.

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

Это вызвано необходимостью быстрой разработки версии программного продукта.

Формальная модель

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

 
 
 

 


Модель:

1. Определение требований;

2. Формальная спецификация (набор требований);

3. Формальные преобразования;

4. Сборка и тестирование системы.

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

Недостаток: большинство систем с трудом поддаются методу формальной спецификации

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

 


1. Спецификация требований;

2. Анализ компонента;

3. Модификация требований;

4. Проектирование системы

5. Разработка и сборка;

6. Аттестация системы.

 

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

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

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

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

Достоинства: - экономия времени; - уменьшение стоимости.

Недостатки: - неизбежные компромиссы при определении требований ; - при проведении модернизации системе отсутствует возможность влияния на появление новых версий компонентов, используемых в системе.



Дата добавления: 2016-07-27; просмотров: 6904;


Поиск по сайту:

Воспользовавшись поиском можно найти нужную информацию на сайте.

Поделитесь с друзьями:

Считаете данную информацию полезной, тогда расскажите друзьям в соц. сетях.
Poznayka.org - Познайка.Орг - 2016-2024 год. Материал предоставляется для ознакомительных и учебных целей.
Генерация страницы за: 0.011 сек.