Контрольные карты по качественным признакам

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

Графическое представление PDPC:

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

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

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

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

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

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

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

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

Билет 24

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

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

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

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

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

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

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

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

Размещено на http: //www.allbest.ru/

Рисунок 1.5 - Разработка ПО с повторным использованием ранее созданных компонентов

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

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

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

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

Билет 25