Разработка сложных программных изделий

РАЗРАБОТКА СЛОЖНЫХ ПРОГРАММНЫХ ИЗДЕЛИЙ

Венчковский Л.Б.

 

Введение......................................................................................................................................................................................... 3

Раздел 1. СТРУКТУРНЫЕ МЕТОДОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ........... 5

Глава 1. Структурные методы в программотехнике................................................................................................... 5

1.1. Эволюция структурных методов.............................................................................................................................. 5

1.2. Основные идеи и принципы структурной методологии..................................................................................... 7

1.3. Принципы программотехники.................................................................................................................................... 8

1.4. Принципы информационной инженерии.................................................................................................................. 8

1.5. Автоматизация проектирования.............................................................................................................................. 9

Глава 2. Структурные методы анализа и проектирования...................................................................................... 9

2.1. Структурный системный анализ............................................................................................................................... 9

2.2. Нисходящее проектирование................................................................................................................................... 10

2.3. Структурное проектирование, управляемое потоками данных.................................................................... 11

2.4. Методы проектирования, управляемые структурами данных...................................................................... 12

Глава 3. Структурные методы программирования.................................................................................................... 13

3.1. Особенности структурных программ.................................................................................................................... 13

3.2. Цели структурного программирования................................................................................................................. 15

3.3. Программирование с использованием пошаговой детализации.................................................................... 15

3.4. Нисходящее и восходящее программирование.................................................................................................... 16

Глава 4. Модульное программирование......................................................................................................................... 16

4.1. Основные понятия и определения............................................................................................................................ 16

4.2. Программные модули и схема модуляризации..................................................................................................... 17

4.3. Оценка качества модульной программы............................................................................................................... 19

Глава 5. Модели разработки программных изделий................................................................................................. 20

5.1. Модель жизненного цикла программного изделия.............................................................................................. 20

5.2. Модель "возрастающей выдачи"............................................................................................................................ 21

5.3. Модель с использованием прототипа................................................................................................................... 21

5.4. Спиральная модель...................................................................................................................................................... 22

Раздел 2. ФАЗЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО ИЗДЕЛИЯ............................................................ 23

Глава 6. Определение требований пользователя и требований к программному изделию.................... 23

6.1. Требования пользователя.......................................................................................................................................... 23

6.2. Требования к программному изделию..................................................................................................................... 24

6.3. Разработка логической модели программного изделия.................................................................................... 24

6.4. Классификация требований к программному изделию..................................................................................... 25

6.5. Атрибуты требований к программному изделию.............................................................................................. 26

6.6. Документ Требования к программному изделию................................................................................................. 26

6.7 Техническое задание на разработку программного изделия............................................................................. 27

Глава 7. Архитектурное проектирование программного изделия...................................................................... 28

7.1. Общее содержание работ фазы.............................................................................................................................. 28

7.2. Виды деятельности..................................................................................................................................................... 29

7.3. Критерии качества архитектурного проекта................................................................................................... 29

Глава 8. Детальное проектирование и изготовление программного изделия.............................................. 30

8.1. Основные виды деятельности.................................................................................................................................. 30

8.2. Кодирование модулей................................................................................................................................................. 31

8.3. Тестирование программного изделия..................................................................................................................... 32

8.4. Документирование работ по проектированию программного изделия....................................................... 32

Глава 9. Отладка программ................................................................................................................................................... 34

9.1. Трудности отладки..................................................................................................................................................... 34

9.2. Средства и методы отладки................................................................................................................................... 35

9.3. Категории ошибок в программном обеспечении................................................................................................ 36

9.4. Рекомендации по отладке......................................................................................................................................... 38

Глава 10. Эксплуатация и сопровождение программного изделия.................................................................. 38

10.1. Передача программного изделия в эксплуатацию........................................................................................... 38

10.2. План испытаний......................................................................................................................................................... 39

10.3. Работы по эксплуатации и сопровождению программного изделия........................................................ 40

10.4. Задачи службы сопровождения программного изделия................................................................................ 40

Раздел 3. УПРАВЛЕНИЕ РАЗРАБОТКОЙ ПРОГРАММНОГО ИЗДЕЛИЯ.......................................................... 41

Глава 11. Управление жизненным циклом программного изделия................................................................... 41

11.1. Виды деятельности, связанные с управлением жизненным циклом программного изделия................. 41

11.2. Измерения в программотехнике............................................................................................................................. 42

11.3. Управление проектированием программного изделия.................................................................................... 43

11.4. Методы получения оценок для проекта программного изделия.................................................................. 45

11.5. Управление рисками.................................................................................................................................................. 48

11.6. Планирование разработки программного изделия.......................................................................................... 49

Глава 12. Управление качеством программного изделия...................................................................................... 50

12.1. Качество программного изделия........................................................................................................................... 50

12.2. Обеспечение качества программного изделия................................................................................................... 51

12.3. Измерение качества программного изделия....................................................................................................... 52

12.4. Управление конфигурацией программного изделия......................................................................................... 53

Литература................................................................................................................................................................................. 55

Введение

 

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

Кардинальные изменения в области создания программного обеспечения были обусловлены и быстрым ростом рыночного про­граммного продукта — той части разработанных программ, кото­рая приобреталась пользователем в виде готовых к эксплуатации пакетов программ различного назначения. Несмотря на то, что зна­чительная часть создаваемого программного обеспечения не дово­дится до коммерческого использования, т.е. не выходит за пределы фирмы-разработчика, она представляет большую ценность для пос­ледующих разработок и для накопления опыта и знаний. Уже к на­чалу 80-х годов только в США было создано программного обес­печения на сотни миллиардов долларов.

Внедрение компьютерных технологий в разнообразные сферы человеческой деятельности привело к возникновению и бурному развитию новой отрасли общественного производства — промыш­ленности обработки данных, суммарный объем продаж продукции в которой быстро оставил позади все традиционные отрасли про­мышленности. Перераспределение числа работающих в сфере мате­риального производства привело к тому, что в наиболее развитых странах более половины работников оказались занятыми обработ­кой информации. В США в 90-е годы этот показатель достиг 80%.

Основа рассматриваемой отрасли в первую очередь — техничес­кое и программное обеспечение систем обработки данных. При этом наиболее наукоемкой остается программная продукция. Есте­ственно, что и в научных исследованиях и в практической деятель­ности постоянно делались попытки перевести изготовление про­граммной продукции на инженерную основу. Так, в 70-х годах возникла новая инженерная дисциплина — программотехни-к а, или инженерия программного обеспечения (Software Engineer­ing).

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

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

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

Программотехника охватывает три ключевых момента создания программной продукции: методы, средства и процедуры.

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

Средства предназначены для создания автоматизированной или полуавтоматизированной поддержки методов. Сегодня сущест­вуют средства практически для каждого из методов. Когда эти средства объединяются в интегрированную среду так, что информа­ция, полученная одним из них, может использоваться другим, со­здается система поддержки разработки программного обеспечения. Система автоматизации разработки программных средств получила название CASE — Computer-aided software engineering.

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

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

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

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

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

2. Программная продукция "не изнашивается". Известно, что кривая надежности (число отказов в единицу времени) для про­мышленных изделий имеет начальный участок высокой интенсив­ности отказов из-за необнаруженных дефектов производства и материалов, затем заметно снижается, оставаясь постоянной до конца срока жизни изделия, когда в результате износа интенсивность от­казов опять резко возрастает-

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

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

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

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

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

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

Принципы программотехники

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

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

Принцип локализации означает группирование логически связан­ных элементов; это относится к данным и этапам выполнения алго­ритмов. Он реализуется через создание как структур данных (мас­сивы, записи), так и программных структур типа отдельных под­программ или процедур.

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

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

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

Нисходящее проектирование

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

Нисходящее проектирование применимо к проектированию сис­тем, программ, отдельного модуля, а также к проектированию структур данных. Как и другие структурные методы, нисходящее проектирование имеет целью:

• систематизировать процесс проектирования;

• создать модульный проект программы;

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

• принимать те решения, которые при разделении проблемы на части обеспечивают наибольшую логическую связность внутри каждой части (подпроблемы);

• при принятии решения обязательно рассматривать альтерна­тивные проекты;

• на каждом шаге принимать как можно меньше решений;

• в первую очередь пытаться выполнять простейшие решения. Для успешного применения метода каждый проектировщик дол­жен следовать следующим основополагающим принципам:

1. Для каждого модуля (на любом уровне иерархии) должны быть определены: функция, его входы и выходы.

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

3. Для описания интерфейсов между модулями данным необхо­димо уделять такое же внимание, как и процедурам обработки.

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

Спиральная модель

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

1.Планирование, включающее определение целей, возможных альтернативных решений и ограничений.

2. Анализ риска, связанный с анализом альтернативных решений и оценкой возможных рисков и путей их преодоления.

3. Инженерная разработка продукта "следующего уровня".

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

 

Планирование

Сбор первичных требований и планирование проекта

Планирование, основанное на замечаниях заказчика

Оценка заказчиком

Оценка заказчиком

Анализ риска
(Анализ, основанный на первоначальных требованиях;
основанный на реакции заказчика)

Разработка

Рис 3. Спиральная модель разработки программного изделия

 

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

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

 

Требования пользователя

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

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

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

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

Все требования пользователей делятся на:

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

2. Требования, определяющие ограничения на способы и пути решения проблемы или на пути достижения поставленной цели.

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

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

Каждое требование пользователя должно описываться следую­щими атрибутами:

1.Идентификатор, позволяющий проследить выпол­нение каждого установленного требования через все фазы ЖЦПИ.

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

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

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

5. Источник возникновения требования должен указывать­ся либо в виде ссылки на конкретный внешний документ, либо на пользователя (группу пользователей), который установил это тре­бование.

6. Проверяемость требования, т.е. каждое требование должно поддаваться проверке выполнения. Это определяет возмож­ность контроля того, что требование включено в проект и может быть реализовано программными средствами и протестировано.

7.Ясность формулировки, означающая определенность и однозначность требования и отсутствие какой-либо неопределен­ности.

Требования к программному изделию

Вторая фаза ЖЦПИ — фаза определения требований к про­граммному изделию, которая является фазой "анализа проблемы". Главной целью этой фазы выступает разработка полной, непроти­воречивой и корректной совокупности требований к программному обеспечению на основе всестороннего изучения требований пользо­вателя. За выработку требований отвечает разработчик. В качестве участников этой фазы должны привлекаться пользователи, инжене­ры-программисты, специалисты по техническим средствам, а также обслуживающий персонал. Ответственным за выполнение работы, как правило, назначается системный аналитик. Руководитель про­екта организует взаимные консультации и обсуждения, поскольку участники обсуждений могут иметь разное представление о конеч­ном продукте, и их взгляды должны синтезироваться в четкие и не­противоречивые формулировки требований.

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

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

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

Документ Требования к программному изделию

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

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

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

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

В документе каждое требование, снабженное идентификатором и атрибутами степени важности и приоритета, имеет ссылку на до­кумент Требования пользователя для облегчения обратной трасси­ровки.

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

6.7 Техническое задание на разработку программного изделия