Контрольные вопросы

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

2. Назовите причины появления проектов типа «death march».

3. Что называется жизненным циклом программного обеспечения? Дайте характеристику этапов жизненного цикла ПО.

4. Охарактеризуйте особенности современной методологии разработки прикладных программ.

5. Какие направления деятельности регламентирует ГОСТ Р ИСО/МЭК 12207?

6. Как в стандарте ГОСТ Р ИСО/МЭК 12207 отражены вопросы качества и надежности программного изделия?

7. Сравните недостатки и преимущества двух моделей жизненного цикла ПИ: каскадной и спиральной.

6 Стадии разработки ппп

6.1 Виды работ и трудоемкости

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

К ак уже отмечалось выше (п. 5.2), процессы, происходящие в каждой фазе, регламентирует стандарт ISO/IEC 12207 . Рассмотрим более подробно содержание фазы разработки, которую в соответствии как с каскадной, так и со спиральной моделью, можно представить состоящую из следующих этапов (рис.6.2).

1. Формирование требований к ППП:

1. концептуализация проекта;

2. планирование работ;

3. разработка требований.

2. Проектирование:

1. разработка внешних спецификаций (или высокоуровневое, функциональное проектирование);

2. разработка внутренних спецификаций (или низкоуровневое, техническое проектирование).

3. Программирование (кодирование) модулей.

4. Тестирование:

1. модульное (автономное) тестирование;

2. комплексное (интеграционное) тестирование;

3. системное тестирование.

6.2 Формирование требований к ппп

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

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

Заказчики заинтересованы в наличии строго определенного регламента на все процессы выполнения заказа. Для этого, как минимум, необходимы:

• критерии оценки трудоемкости и длительности проекта;

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

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

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

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

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

1) Концептуализация проекта:

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

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

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

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

• разработать концепцию проектирования (выбрать модель ЖЦ ПО, технологию и стандарты проектирования и соответствующие программные средства).

2) Планирование работ:

• оценить трудовые и стоимостные затраты, сроки выполнения предстоящей работы;

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

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

3) Разработка детальных требований к ППП:

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

• описать требования к надежности функционирования ППП (защита информации, уровень обеспечения безопасности при сбоях в работе, возможности восстановления работоспособности);

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

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

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

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

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

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

• достаточным для просмотра и утверждения руководством заказчика и разработчика на основе его реализуемости в соответствии с выбранными критериями.