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

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

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

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

3. Приоритет, указывающий некоторый порядок очеред­ности при планировании работ и при проектировании изделия.

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

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

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

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

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

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

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

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

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

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

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

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

·

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

·         должны быть созданы структурные средства и методы, кото­рые обеспечивают полное и точное понимание пользователем его действий;

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

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

 

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

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

• создание высококачественных программ с предсказуемым по­ведением;

• создание программ, которые просто модифицировать;

• упрощение структуры программы и процесса их разработки;

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

• сокращение сроков разработки и снижение стоимости разра­ботки программных систем.

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

1. Улучшить удобочитаемость программ:

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

• уменьшить сложность программы за счет упрощения путей уп­равления в программе;

• обеспечить возможность чтения программы от начала дс конца без "скачков" в управлении программой. 2. Повысить эффективность программ:

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

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

3. Повысить надежность программ:

• конструировать программы так, чтобы отпадала или уменьша­лась необходимость отладки;

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

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

• ввести более высокий уровень точности в программировании.

4. Создать дисциплину программирования:

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

• повысить целостность программной системы;

• заставить программиста думать.

5. Уменьшить стоимость программирования:

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

• упростить программисту управление большими объемами кодов программы.

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

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

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

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

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

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

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

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

8.4.1. Детальный проект программного изделия

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

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

Часть 2 документа постепенно расширяется по мере разработки проекта. Структура этой части документа и идентификация разде­лов полностью соответствует программным компонентам про­граммного изделия.

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

8.4.2. Руководство пользователя программного изделия

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

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

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

В руководство целесообразно включать иллюстрации в виде эк­ранов с описанием особенностей манипуляций на клавиатуре.

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

Руководство пользователя содержит следующие разделы:

• общие сведения;

• описание применения;

• требования к процедурам.

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

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


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

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

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

Затем должны быть описаны требования, предъявляемые к каж­дому выходному документу или экрану, указаны: способ использо­вания и частота выдачи, способ представления (носитель), инструк-

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

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

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

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

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

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

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

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

Тщательная систематизация статистической информации позво­ляет выявить причины появления ошибок. Это может быть:

• неполнота или ошибочность спецификаций;

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

• умышленное отклонение от спецификаций;

• нарушение стандартов программирования;

• ошибки в представлении данных;

• несовместимые интерфейсы между модулями;

• ошибки в логике проектных решений;

• неполное или ошибочное тестирование;

• неточная или неполная документация;

• неоднозначность и противоречивость человеко-машинного ин­терфейса.

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

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

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

• общее число модулей в архитектурном проекте;

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

• число элементов базы данных, включая объекты и их атрибу­ты;

• общее число уникальных элементов базы данных;

• число различных типов записей в базе данных;

• число модулей с единственным входом и выходом-

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

Другой стандарт — индекс завершенности программного изде­лия

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

Индекс завершенности определяется по формуле

SMI= [ Ml - ( Fa + Fc + Fd)} I Ml,

где Ml — число модулей в текущей версии;

Fc — число измененных модулей в текущей версии;

Fa — число добавленных модулей в текущей версии;

Fd —

число модулей предыдущей версии, исключенных из теку­щей версии.

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

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

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

• определить или показать качество продукции;

• установить производительность труда персонала, занятого раз­работкой;

• оценить выгоды (прибыль или доход), которые могут быть по­лучены в результате разработки новых программных средств;

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

• получить данные для обоснования требований на дополни­тельные средства на обучение и т.п.

Принято различать два вида измерений: прямые и косвенные. Прямые измерения процесса разработки и сопровождения про­граммного изделия включают трудозатраты и стоимость. Непосред­ственные измерения программного продукта охватывают число строк кода (LOC — lines-of-code), размер требуемой памяти, ско­рость выполнения программы, число ошибок (дефектов), обнару­женных за определенный период времени. Косвенные измерения программного продукта включают его функциональные возмож­ности, показатели качества (надежность, эффективность, пригод­ность к сопровождению и т.п.).

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

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

Во-вторых, выделяют группы метрик по их ориентации:

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

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

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

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

• общие трудозатраты (в человеко-месяцах — ЧМ);

• объем программного изделия (в тысячах строк исходного кода — KLOC);

• стоимость разработки (в тыс. рублей или в у.е.);

• объем документации (в страницах документов — СД);

• ошибки, обнаруженные в течение года эксплуатации (число ошибок — 40);

• число людей, работавших над изделием (человек);

• срок разработки (в календарных месяцах).

На основе этих данных обычно подсчитываются простые метри­ки для оценки производительности труда (KLOC/4M) и качества изделия (40/KLOC).

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

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

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

• число входов пользователя;

• число выходов пользователя;

• число запросов пользователя;

• число файлов базы данных;

• число внешних интерфейсов.

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

На основе большого числа программных разработок было уста­новлено соотношение между обеими метриками для разных языков программирования. Усредненные данные имеют вид:

Язык программирования

Ассемблер

Кобол

Фортран

Паскаль

Ада

Объектно-ориентированные языки

Языки 4-го поколения

Генераторы кода

LOC/FP

300 100 100 90 70 30 20 15

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

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

Ситуация, получившая название кризиса в программировании, была обусловлена тем, что стало трудно проектировать, писать, тестировать и особенно понимать и сопровождать сложные про­граммные комплексы. Для преодоления возникших осложнений не­обходимо было создать технологию разработки программ. В ре­зультате работ Вирта, Дейкстры, Иодана, Хоара и др. в 70-е годы постепенно сложилась методология, получившая название струк­турного программирования. Это понятие впервые ввел Дейкстра в 1970 г., и вначале оно касалось только формы программы и процес­са ее кодирования. Был принят ряд соглашений, регламентировав­ших создание структурных программ:

1. Полное или частичное исключение операторов

GO TO.

2. Программирование только с использованием трех базовых структур: последовательности, выбора и цикла.

3. Применение соглашений структурного кодирования при на­писании программ на конкретном языке программирования.

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

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

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

Структурная теорема и работы, появившиеся в данной области в 70—80-е годы, расширили понимание структурного подхода. Если рассмотреть развитие структурных методов в программотехнике, то можно выделить несколько этапов.

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

Модульное программирование —

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

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


Появи­ лись работы Джексона, Йодана, Уорнье, Орра и др., посвященные структурным методам проектирования программных изделий на ос­нове потоков данных и структур данных.

В конце 70-х годов было установлено, что большинство про­блем при разработке программного обеспечения возникают из-за неточных и неполных исходных требований заказчика, а также из-за неправильного их понимания программистом-разработчиком. Для решения этих проблем была предложена структурная методо­логия анализа потоков данных в создаваемой автоматизированной системе, на основе которой удалось более точно и полно описывать требования к программному изделию и более строго и формализо­вано описывать требования пользователя. Было разработано не­сколько подходов к анализу, наиболее известный из них представ­лен в работах Гейна и Сарсона. Одновременно начали развиваться структурные методы, связанные с использованием технологии баз данных, пришедшей на смену файловой технологии обработки дан­ных. Структурные методы легли в основу моделирования структур баз данных; многие идеи были заложены в работах Кодда по нор­мализации реляционных баз данных.

Начало 80-х годов ознаменовалось переходом к автоматизиро­ванным методам проектирования программ и появлением языков программирования непроцедурного типа (четвертого поколения). В конце 80-х годов появилось новое направление в информатике, по­лучившее название CASE-технологии, т.е. автоматизированное про­ектирование систем. Постепенно отдельные разработки, обеспечи­вающие автоматизацию отдельных процессов в создании программ­ного обеспечения, объединились в интегральную среду поддержки работы программиста. Широкое распространение персональных компьютеров позволило создать автоматизированное рабочее место программиста, оснащенное разнообразными CASE-средствами, предназначенными для реализации различных структурных мето­дов.

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

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

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

Структурные методы —

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

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

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

В приведенном определении существенными являются следую­щие три момента:

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

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

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

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

Факторы, влияющие на качество изделия, классифицируются по трем аспектам программного продукта:

• рабочие характеристики;

• приспособленность к внесению изменений;

• приспособленность к изменению окружающей обстановки. К первой группе можно отнести следующие характеристики:

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

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

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

4. Удобство и простота использования

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

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

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

• повышение производительности труда при эксплуатации про­граммного изделия пользователем средней квалификации;

• субъективную оценку отношения пользователя к системе.

5. Целостность определяет степень, с которой может быть про­контролирован несанкционированный доступ к данным и програм­мам.

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

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

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

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

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

2. Удобство и простота тестирования

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

Третья группа характеристик — возможности использования программного изделия в новых окружающих условиях, включает:

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

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

3. Совместимость определяет возможность взаимодействия с другими программными продуктами.

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

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

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

Ошибки можно систематизировать по этапам разработки про­граммного продукта.

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

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

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

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

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

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

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

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

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

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

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

Количественные требования нецелесообразно фиксировать в виде качественных характеристик типа "быстрый ответ", а следует записывать, например, в виде "время ответа должно быть не более Х сек", или вместо "в большинстве случаев" указывать "для Y% случаев среднее время ответа должно быть менее Z сек" и т. п.

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

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

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

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

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

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

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

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

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

9. Требования к надежности определяются либо значением допустимого среднего времени между отказами, либо значением минимального времени между отказами-

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

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

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

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

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

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

• представления комментариев в программах;

• наименования программ, подпрограмм, файлов, переменных;

• ограничения размеров модулей;

• использования библиотек;

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

• обработки ошибок и т.п.

Каждый модуль должен иметь заголовок, оформленный по стандарту, который включается в "шапку" модуля.

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

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

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

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

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

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

Простота формы достигается в результате:

• минимизации "сцепления" между компонентами;

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

• согласования программного обеспечения со структурами дан­ных;

• максимизации числа компонент, использующих данную ком­поненту;

• ограничения числа подчиненных компонент;

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

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

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

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

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

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

Литература

1.

Martin J., McClure C. Structured Techniques: The Basis for CASE. Englewood Cliffs: Prentice Hall,

1988.

2. Mazza C„ Fairclouch J., Melton B. Software Engineering Stand­ards. N.Y.: Prentice Hall, 1994.

3. Software Engineering: A Practioner's Approach.

3 ed. by ed. R.S. Pressman. N.Y.: McGraw Hill, 1992.

4. Экономика, разработка и использование программного обес­печения ЭВМ: Учебник / В.А.

Благодатских, М.А. Енгибарян и др. — М,: Финансы и статистика, 1992.

5. Боэм Б.У. Инженерное проектирование программного обес­печения. — М.: Радио и связь, 1985.

6. Гейн К., Сарсон Т. Структурный системный анализ: средства

и методы. — М.: "Эйтекс", 1993.

7. Липаев В.В. Проектирование программных средств. — М.:

Высшая школа, 1990.

УДК 681.3 ББК32.973-018я73 В29

Автор

канд. техн. наук. доц. Вснчковский Лев Борисович

Ответственный редактор

зав. кафедрой «Компьютерные технологии», канд. экон. наук. доц. Машурцсв Владимир Адамович

Рецензенты:

канд. техн. наук. проф. Васильев Ростислав Романович (Московский институт стали и сплавов (технический университет));

канд. техн. наук, доц. Маран Михксль Михкелевич (Московский энергетический институт (технический университет))

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

В29    Разработка сложных программных изделий: Учеб. пособие для вузов / Под ред. В.А. Машурцева; ГУУ. — М.: ЗАО «Фин-статинформ», 1999. — 109 с.

ISBN

5-7866-0103-Х

Учебное пособие предназначено для студентов заочного обучения ГУУ всех специальностей.

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

УДК 681.3 ББК

32.973-018я73

ISBN 5-7866-0103-Х

| Государственный университет управления, 1999 | Оформление. ЗАО «Финстатинформ». 1999

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

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

Очевидно, что оценка трудозатрат на разработку изделия опре­деляется производительностью труда разработчиков, на которую влияет следующая совокупность факторов:

1. Человеческий фактор, связанный с размером и опытом орга­низации — разработчика программного обеспечения.

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

3. Факторы технологии разработки, которые могут быть оха­рактеризованы используемыми методами анализа и проектирова­ния, имеющимися средствами CASE и средствами контроля и т.п.

4. Факторы, связанные с разрабатываемым продуктом и опреде­ляющиеся его характеристиками (качества, надежности и т.д.).

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

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

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

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

1. Откладывайте оценку на более поздний срок.

2. Используйте для оценки простые методы декомпозиции.

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

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

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

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


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

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

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

11.4.1. Методы функциональной декомпозиции

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

На практике широко используются оценки, основанные на раз­мере программного продукта — числе строк кода. (LOC — lines of code.) Данные о числе строк кода при оценке проекта программно­го изделия используются:

• как оценочные переменные для разрабатываемого проекта ("размер" его отдельных элементов);

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

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


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

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

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

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

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

Полученные оценки стоимости и усилий целесообразно срав­нить с оценками, полученными на основе размерных характеристик продукта (числа строк кода). Оценки в обоих случаях должны быть достаточно близкими (различия в пределах 10%).


Значительные рас­хождения в оценках могут быть из-за:

• неадекватного понимания сферы применения проекта или не­правильной интерпретации границ его использования;

• неправильных или устаревших данных о производительности труда в LOC-методе или их несоответствия прикладной области.

В этом случае необходимо выявить причину расхождения оце­нок и провести повторные расчеты.

 

11.4.2. Эмпирические оценочные модели

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

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

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

Одной из наиболее распространенных и используемых на прак­тике является Конструктивная модель стоимости — СОСОМО (Constructive Cost Model). Эта модель применима к трем типам про­граммных систем:

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

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

3. Встроенный тип — когда проект разрабатывается внутри очень строгих ограничений и требований.

Конструктивная модель стоимости представлена иерархией мо­делей:

1. Базовая модель — основная — это статическая модель с одной переменной.


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

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

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

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

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

Для оценки стоимости и затрат усилий на разработку исполь­зуются следующие уравнения базовой модели СОСОМО:

Е = а • (KLOC) • ехр (Ь);

D = с - (Е) • exp (d),

где Е —

требуемые усилия (в человеко-месяцах);

D — хронологическое время разработки (в месяцах);

а, Ь, с, d — коэффициенты, представленные в табл. 11.1.

Таблица 11.1

Тип программного проекта	а	b	с	d
1. Изолированный 2. Полуизолированный 3. Встроенный	2,4 3,0 3,6	1,05 1,12 1.20	2,5 2.5 2.5	0,38 0,35 0,32

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

1. Атрибуты программного продукта:

• требуемая надежность;

• размер прикладной базы данных;

• сложность программного продукта.

2. Атрибуты технических средств:

• ограничения на время прогона программы;

• ограничения на объем памяти;

• требуемое время цикла обработки.

3. Атрибуты персонала разработчиков:

• квалификация системного аналитика;

• опыт в данной прикладной области;

• опыт работы с принятой в проекте средой разработки.

4. Атрибуты среды проектирования:

• применение современных методов программотехники;

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

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

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

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

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

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

Процесс проектирования по Джексону состоит из 4-х последова­тельных шагов.

1. Шаг данных — каждый входной и выходной потоки данных описываются в виде иерархических структур типа файл — за­пись — агрегат — элемент. Для графического представления ис­пользуются так называемые схемы Джексона.

2. Шаг программы характеризуется тем, что все структуры дан­ных, определенные на 1-м шаге, объединяются в иерархическую структуру программы.

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

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

Методология Джексона использует три средства для докумен­тирования проекта программы:

1. Общая сетевая схема потоков данных в системе.

2. Схемы иерархической структуры для представления програм­мы и данных.

3. Структурный текст.

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

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

Методология Уорнье — Орра

предлагает выводить структуру программы и структуру входных данных, исходя из структуры вы­ходных данных. Выход программы полностью и абсолютно опреде­ляет структуру программы. Эту методологию иногда называют "'проектированием, ориентированным на выходные данные", и пра­вильность проекта зависит от полноты понимания структуры вы­ходных данных.

Процедура проектирования включает следующие 6 шагов.

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

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

3. Выполнение анализа событий.

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

4. Разработка физической базы данных. Определяются физические файлы, необходимые для входных данных.

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

6. Проектирование физических процессов.

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

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

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

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

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

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

1. Прототип на бумаге или модель, реализованная на ПЭВМ для отображения человеко-машинного взаимодействия в форме, по­нятной заказчику.

2. Функционирующий прототип, который реализует некоторое подмножество функций, требуемых от изделия.

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

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

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

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

• отдельные функции программного изделия могут потребовать­ся раньше, а функциональные возможности системы — наращи­ваться постепенно;

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

• финансирование разработки позволяет выделять ограниченные средства, но в течение ряда лет.

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

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

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

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

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

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

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

Архитектурное проектирование

Детальное проектирование

Передача в эксплуатацию

Эксплуатация, сопровождение

Рис. 2. Модель жизненного цикла программного изделия

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

Модель ЖЦПИ содержит шесть фаз разработки, для которых в стандартах определены содержание работ, виды деятельности, входные и выходные документы:

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

2. Определение требований к программному обеспечению.

3. Архитектурное проектирование.

4. Детальное проектирование и программирование.

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

6. Эксплуатация и сопровождение.

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

В соответствии со структурой ЖЦПИ при планировании работ и при контроле за сроками их выполнения имеется, по крайней мере, шесть событий, которые характеризуют переход к следующей фазе:

1. Рассмотрение и одобрение требований пользователя.

2. Рассмотрение и одобрение требований к программному изде­лию.

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

4. Рассмотрение и одобрение детального проекта программного изделия, руководства пользователя, программ и утверждение акта о готовности их к приемному тестированию.

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

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

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

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

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

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

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

Метод восходящего программирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассматриваемая фаза ЖЦПИ заканчивается формальным ут­верждением документа Архитектурный проект после всестороннего его рассмотрения и критического обзора.

Работы на этой фазе выполняются в соответствии с планами, разработанными на предыдущей фазе, и направлены на создание и документирование архитектурного проекта- Сюда входят:

• конструирование физической модели программного изделия;

• описание требований к архитектурному проекту;

• выбор языка программирования;

• обзор проекта.

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

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

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

Три фактора оказывают влияние на сцепление модулей:

1. Число элементов данных, передаваемых между ними (чем больше передается данных, тем сильнее сцепление).

2. Количество управляющих данных, передаваемых между моду­лями.

3. Число глобальных элементов данных, которые совместно ис­пользуются модулями.

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

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

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

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

 

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

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

Основными принципами структурной методологии являются:

1. Принцип абстракции.

2. Принцип формальности.

3. Принцип "разделяй и властвуй" (побеждай).

4. Принцип иерархического упорядочения.

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

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

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

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

Принцип абстракции лежит в основе стратегии нисходящего и восходящего программирования.

Принцип формальности.

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

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

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



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

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

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

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

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

1. Декомпозиция программы на независимые фрагменты — мо­дули, которые могут быть в дальнейшем реализованы в виде от­дельных процедур или функций, либо в виде модулей (unit), являю­щихся конструкциями конкретного языка программирования.

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

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

Модульное программирование — это организация программы в \.\\:\е небольших независимых блоков, называемых модулями, струк-, \ ра и поведение которых определяется некоторой совокупностью ,:равил.

Таким образом, модуль — основной строительный блок струк-\рной программы. Каждый модуль должен соответствовать одной ; .роблемно-ориентированной задаче.

Достоинства модульного программирования:

1. Модульная программа проще для понимания, поскольку есть возможность в каждый момент времени рассматривать один мо­дуль.

2. Упрощено тестирование программы.

3. Упрощен процесс обнаружения и исправления ошибок.

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

5. Упрощен процесс повышения эффективности программы.

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

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

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

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

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

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

Детальное проектирование и изготовление программного изде­лия базируются на следующих трех принципах:

• нисходящая декомпозиция;

• структурное программирование;

• одновременное изготовление и документирование.

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

Нисходящая декомпозиция жизненно важна для управления сложностью и для реализации принципа "сокрытия информации".

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

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

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

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

• начинаем с функциональной спецификации и спецификации интерфейсов;

• концентрируем внимание на потоках управления;

• откладываем объявление данных до фазы кодирования;

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

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

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

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

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

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

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

• простая стандартная структура управления;

• единые требования к документированию программы;

• соглашения! о стиле кодирования.

Рассмотрим перечисленные характеристики подробнее.

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

Базовый набюр управляющих структур ограничен тремя базовы­ми конструкциями: последовательность, выбор, повторение (цикл). Для расширения! возможности принятия многоальтернативных ре­шений базовый набор дополнен в большинстве языков программи­рования оператсором многоальтернативного выбора.
В структурных программах допускается использование оператора перехода (GO TO), но толгько для перехода в точку выхода данного модуля.

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

• общий обзор программы;

• организация программы;

• операторы программы.

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

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

1. Краткое описание общей функции программы, определяющее ее основные компоненты.

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

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

4. Ссылки на предшествующую документацию, проектные доку­менты и материалы.

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

Элементы блока комментариев для каждого модуля содержат:

• назначение модуля (в одном — двух предложениях);

• алгоритмические особенности, ограничения;

• описание интерфейсов модуля (передаваемые параметры);

• реакция на ошибки и процедуры восстановления при ошибках;

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

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


Вместо комментариев зачастую используют­ся:

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

• типовые управляющие конструкции и процедуры;

• последовательный, строгий стиль кодирования.

Стандартизация стиля кодирования предполагает выполнение следующих правил.

1. На каждой строке записывается один оператор. Если для за­писи требуется более одной строки, то на следующих строках дела­ются отступы.

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

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

4. В структуре выбора не допускается более трех уровней вло­женности: большей вложенности циклов следует избегать.

5. Комментарии пролога программы должны отделяться от опе­раторов пустой строкой.

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

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

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

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

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

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

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

План испытаний

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

Документ содержит:

• общие сведения;

• план испытаний;

• технические требования и оценку результатов;

• описание испытаний.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

в основе которой лежат определенные принципы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пошаговая детализация отличается следующими особенностя­ми:

1. Процесс выполняется в виде последовательности отдельных шагов.

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

3. Множества задач и данных каждого шага детализируют мно­жества, полученные на предыдущем шаге детализации.

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

5. На каждом шаге решение о детализации принимается после рассмотрения альтернативных вариантов.

Для описания процесса детализации Дейкстра ввел понятие уровней абстракции. Самый верхний уровень описания программы представляет ее в самой абстрактной форме, а самый нижний — в терминах компонент программной обстановки, которые легко могут быть оттранслированы в программный код. Каждый уровень абстракции формируется из компонент трех типов:

• множество структур данных;

• множество инструкций;

• алгоритм, выраженный в терминах данных и инструкций, со­зданных на рассматриваемом уровне.

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

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

Модуль — это какая-либо процедура или функция, написанная '.етствии с определенными правилами. Модуль разрабатыва-• последовательность   [ораторов, ограниченных точкой '[кой выхода.'icpHoro ящика", которая

"Черный ящик" — ,[, выходы и функция, :                                    льно, как реализован

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

Модуль должен обладать следующими свойствами:

1. Каждый модуль представляет одну логическую задачу.

2. Модуль замкнутый и простой.

3. Модуль дискретен и обозрим.

4. Модуль отдельно тестируется и отлаживается.

5. Каждый модуль реализуется применительно к одной незави­симой функции программы.

6. Каждый модуль имеет одну точку входа и одну точку выхода.

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

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

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

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

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

3. Конструкция модуля стандартизуется в соответствии с тради­ционными правилами модуляризации, а в качестве составных бло­ков в модуле должны использоваться только последовательность, выбор и повторение (цикл). Оператор безусловного перехода GO TO целесообразно использовать только для перехода непосред­ственно в точку выхода.

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

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

Мера сложности модуля также играет важную роль. Существует несколько подходов к количественной оценке сложности. Одна из наиболее удобных и распространенных — оценка с помощью так называемого цикломатического числа, равного числу путей выпол­нения программы. Таким образом, сложность программы или мо­дуля равна числу операторов IF + 1. Если в условном операторе используется сложное логическое выражение, то подсчитывается число простых операций сравнения-

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

1-й уровень иерархии

2-й уровень иерархии

3-й уровень иерархии

Модуль А вызывает модули В, С, D

Модуль А является родительским по отношению к модулям В, С, D, которые являются дочерними по отношению к А

Рис. 1.

Схема модуляризации

Естественное требование модульного программирования — ие­рархическое упорядочение модулей.


Иерархическая организация модулей определяется следующим образом (см. рис. I):

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

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

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

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

Между модулями существуют отношения активизации, т.е. один модуль может вызывать другой. Так, если модуль А вызывает мо­дуль В, то это означает, что управление передается от модуля А к модулю В. Модуль А называется вызывающим, или родительским, а модуль В — вызываемым, или дочерним. Иногда их называют со­ответственно "отец — сын". В структурной программе существуют следующие правила для потока управления:

1. Выполнение программы начинается с корневого модуля.

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

3. Дочерний модуль не может вызывать родительский и не может вызывать сам себя.

4. Управление программой должно входить в модуль в точку входа и покидать модуль в точке выхода.

5. Управление всегда возвращается к вызывающему модулю, когда вызванный модуль выполнит свою функцию.

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

7. Каждая ветвь иерархической схемы модуляризации заканчи­вается терминальным модулем.

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

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

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

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

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

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

Сопровождение программного обеспечения связано с внесением изменений в течение всего времени использования программного изделия. К причинам, определяющим необходимость внесения из­менений в изделии, относятся:

• наличие ошибок в используемом программном продукте;

• изменение требований пользователя (расширение или модифи­кация);

• появление более совершенных общесистемных программных средств или технических устройств;

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

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

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

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

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

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

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

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

Логическая модель должна удовлетворять следующим прави­лам:

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

2. Функции соответствуют уровню иерархии, на котором они представлены в модели.

3. Связи между функциями (функциональными блоками модели) минимизируют.

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

5. В модели не должна присутствовать информация, связанная с последующей реализацией изделия, например, такие понятия, как модуль, файл, запись и т.п.

6. Для каждой функции приводятся входные данные.

7. Каждой функции соответствует список выходных данных (вы­ходных отчетов).

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

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

Для упорядочения процесса тестирования собирайте и анализи­руйте информацию:

• об особенностях и статистике ошибок;

• о специфике исходных данных и последовательности измене­ния переменных в программе и их взаимном влиянии;

• о структуре алгоритма и особенностях его программной реа­лизации.

2. В каждый момент времени определяйте местоположение одной ошибки.

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

4. Тщательно изучайте полученные выходные данные и сравни­вайте их с ожидаемыми, заранее просчитанными результатами.

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

6. Используйте совместный анализ потоков данных и потоков управления для проверки корректности в установлении областей определения данных для разных маршрутов выполнения програм­мы.

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

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

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

10. Дл»1 повышения опыта и тренировки в отладке программ ис­пользуйте программы с искусственно помещенными в них ошибка­ми. После определенного периода отладки программисту следует указать на. оставшиеся необнаруженные ошибки.

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

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

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

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

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

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

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

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

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

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

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

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

Анализ риска

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

основанный на реакции заказчика)

Разработка

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

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

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

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

Отладка начинается после обнаружения ошибки. Существуют следующие средства обнаружения причины ошибки и ее локализа­ции:

1. Листинг исходного кода.

2. Подробная спецификация программы.

3. Детальный алгоритм программы, представленный в виде блок-схемы, схемы действий, таблицы решений и т.п.

4. Выходной листинг.

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

6. Отслеживание обращений к подпрограммам.

7. Дампы памяти.

Эти средства предполагают проведение внимательного анализа программы за столом.

Существенную помощь в отладке оказывают инструментальные средства:

• отладочные компиляторы применительно к языку программи­рования;

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

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

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

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

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

• пакеты словарей/справочников данных, позволяющие контро­лировать имена и типы данных и их использование разными моду­лями программы;

• CASE-средства для построения схем потоков данных, моделей данных, схем алгоритмов и т.п.;

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

Для отладки применяется ряд методов, которые можно укруп-ненно представить в виде следующих групп.

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

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

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

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

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


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

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

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

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

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

Структурное проектирование

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

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

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

Шаг 1. Представление схемы потоков данных.

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

Шаг 2. Изображение структурной схемы проекта.

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

• анализ преобразований;

• анализ транзакций.

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

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

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

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

Процесс проектирования здесь состоит из четырех шагов:

• идентификация источников транзакций;

• установление центра транзакций в СПД;

• идентификация модулей обработки транзакций в СПД и со­здание высокоуровневой структурной схемы программы;

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

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

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

Шаг 3. Оценка проекта.

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

Шаг 4. Подготовка проекта для реализации.

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

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

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

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

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

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

Информация о программной системе (системная спецификация), полученная в результате анализа, должна включать описания:

§

выходных отчетов;

§         структур данных и базы данных;

§         внешних файлов и внутренних массивов;

§         функциональных компонент с разной степенью детализации и связей между ними.

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

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

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

1.      Нисходящая иерархическая организация модели системы.

2.      "Разделяй и побеждай".

3.      Графические средства общения и документирования.

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

Структурный системный анализ обеспечивает описание специ­фикаций системы, объединяя:

§         схемы потоков данных;

§         словарь данных;

§         описания процессов обработки данных.

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

§         источников (приемников) данных;

§         процессов обработки данных;

§         потоков данных;

§         хранилищ данных.

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

Словарь данных

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

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

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

 

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

Этапы разработки требований пользователя и требований к программному изделию в практике разработки программных изде­лий в нашей стране рассматриваются в схеме ЖЦПИ как стадия разработки Технического задания.

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

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

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

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

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

Таким образом, первые три пункта описывают проблему авто­матизации.

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

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

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

7. Описание данных — схем потоков данных, всех структур дан­ных и взаимосвязей между ними.

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

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

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

10. Детальное описание функциональных блоков, ориентиро­ванное на программиста-разработчика.


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

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

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

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

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

13. Технические и программные средства, на базе которых должно работать программное изделие. Здесь указываются тип и требуемые ресурсы ЭВМ, а также — в среде каких программных средств должно функционировать разрабатываемое изделие.

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

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

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

Процесс тестирования проходит несколько этапов: поблочное, комплексное и системное.

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

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

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

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

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

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

Системное тестирование — процесс тестирования интегрированного программного изделия.
Оно осуществляется в процессе разработки или в условиях моделирования эксплуатации. Системное тестирование должно подтверждать соответствие разра­ботанного программного изделия целям, установленным в докумен­те Требования пользователя.

Системное тестирование включает:

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

• прогон тестов с целью проверки выполнения требований поль­зователя;

• стрессовое тестирование для верификации предельных харак­теристик программного изделия;

• предварительную оценку надежности и пригодности к сопро­вождению;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

• обнаружения ошибки в программе;

• установления местонахождения ошибки;

• подтверждения правильности работы программы после прове­денной корректировки.

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

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

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

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

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

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

1. Компилятор не выдает сообщений об ошибках, но программа не компилируется.

2. Программа откомпилирована, но при выполнении не выдает никаких результатов.

3. Программа откомпилирована, но при выполнении происхо­дит преждевременный останов. '

4. Программа зацикливается.

5. Программа выдает неверные результаты.

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

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

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

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

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

• компьютерные программы (в форме исходного или исполняе­мого кода);

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

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

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

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

2. Спецификацию требований к программному изделию.

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

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

5. Предварительное руководство пользователя.

6. Спецификацию проекта:

а) описание архитектурного проекта;

б) описание проекта данных;

в) описание проектов отдельных модулей.

7. Документированные листинга исходных кодов.

8. Материалы тестирования:

а) план и процедура тестирования;

б) тестовые наборы и результаты тестирования. 9- Операционные руководства и руководство по вводу в дейст­вие.

10. Рабочие программы (исполнимые модули и модули связей).

11. Описание базы данных:

а) схема базы и структуры файлов;

б) первоначальное содержание.

12. Документы по сопровождению программного изделия.

13. Стандарты и процедуры, определяющие порядок выполне­ния работ.

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

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

При создании изделия изменения происходят в процессе работы постоянно, по мере накопления разработчиками опыта и информа­ции.

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

• идентификации и документирования физических и функцио­нальных характеристик элементов конфигурации;

• контроля за изменением этих характеристик;

• регистрации, обработки и документирования изменений и ус­тановления статуса реализации;

• проверки согласованности проводимых действий с установлен­ными требованиями.

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

• ревизионном контроле;

• идентификационном контроле;

• управлении распространением.

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



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

предполагают разные условия работы, версии

обеспечивают разные свойства, а редакции

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

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

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

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

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

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

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

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

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

Основные факторы, оказывающие влияние на степень риска:

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

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

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

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

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

• описание ресурса;

• информация о наличии ресурса;

• хронологическое время появления потребности в ресурсе;

• продолжительность использования ресурса.

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

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



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

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

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

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

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

Важным моментом при планировании является анализ риска. Примерами областей возможного риска служат:

• качество и стабильность требований пользователя;

• стабильность и полнота описания внешних интерфейсов;

• опыт и квалификация кадров;

• техническая новизна проекта и т.п.

Анализ риска включает четыре разных вида деятельности:

1. Идентификация риска.

2. Описание риска.

3. Оценка риска.

4. Управление риском.

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

• риск проектирования;

• технический риск;

• бизнес-риск (деловой риск).

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

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

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

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

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

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

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

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

• определить причины текучести (оплата, условия работы);

• наметить действия, смягчающие эти причины;

• постоянно контролировать ситуацию;

• подготовить дублеров по критическим специальностям;

• организовать рабочие бригады и т.д.

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

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

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

7.2.1. Конструирование физической модели

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

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

7.2.2. Декомпозиция программного изделия на компоненты

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

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

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

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

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

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

К задачам управления относят планирование, контроль за ис­пользованием финансовых и трудовых ресурсов, нормирование труда и учет затрат.

Для управления разработкой программного изделия разраба­тываются планы:

• управления проектированием программного изделия;

• управления конфигурацией программного изделия;

• верификации и аттестации программного изделия;

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

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

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

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

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

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

х годов появились первые признаки

В конце 60-х — начале 70- х годов появились первые признаки кризиса в области программирования — колоссальные успехи в об­ласти развития средств вычислительной техники пришли в проти­воречие с низкой производительностью труда программистов и низкими темпами ее роста. В связи с усложнением программных систем стало очевидным, что их трудно проектировать, кодировать, тестировать и особенно трудно понимать, когда возникает необхо­димость их модификации в процессе сопровождения. Появилась жизненная потребность в создании технологии разработки про­граммных средств и инженерных методов их проектирования для существенного улучшения производительности труда разработчи­ков.
Кардинальные изменения в области создания программного обеспечения были обусловлены и быстрым ростом рыночного про­граммного продукта — той части разработанных программ, кото­рая приобреталась пользователем в виде готовых к эксплуатации пакетов программ различного назначения. Несмотря на то, что зна­чительная часть создаваемого программного обеспечения не дово­дится до коммерческого использования, т.е. не выходит за пределы фирмы-разработчика, она представляет большую ценность для пос­ледующих разработок и для накопления опыта и знаний. Уже к на­чалу 80-х годов только в США было создано программного обес­печения на сотни миллиардов долларов.
Внедрение компьютерных технологий в разнообразные сферы человеческой деятельности привело к возникновению и бурному развитию новой отрасли общественного производства — промыш­ленности обработки данных, суммарный объем продаж продукции в которой быстро оставил позади все традиционные отрасли про­мышленности. Перераспределение числа работающих в сфере мате­риального производства привело к тому, что в наиболее развитых странах более половины работников оказались занятыми обработ­кой информации. В США в 90-е годы этот показатель достиг 80%.
Основа рассматриваемой отрасли в первую очередь — техничес­кое и программное обеспечение систем обработки данных.
При этом наиболее наукоемкой остается программная продукция. Есте­ственно, что и в научных исследованиях и в практической деятель­ности постоянно делались попытки перевести изготовление про­граммной продукции на инженерную основу. Так, в 70-х годах возникла новая инженерная дисциплина — программотехни-к а, или инженерия программного обеспечения (Software Engineer­ing).
Программотехника охватывает все виды деятельности по проек­тированию и разработке программного обеспечения.
Программное обеспечение (software) —
это программы, выпол­няемые вычислительной системой. Здесь подразумевается как одна, так и несколько программ, которые может выполнять ЭВМ. Разли­чают системное программное обеспечение, которое нацелено на по­вышение эффективности работы вычислительной системы и являю­щееся дополнением к техническим средствам, а также прикладные программы, обеспечивающие выполнение конкретных задач поль­зователей.
Становлению программотехники способствовало расширение рынка программной продукции, появление мощных фирм, занятых производством исключительно этой продукции, и невиданный рост числа пользователей программных изделий. Под программным изде­лием понимают программы, которые при выполнении на ЭВМ реа­лизуют требуемые функции и характеристики; данные, которые по­зволяют программам адекватно обрабатывать и выдавать информа­цию; документация, описывающая работу и использование про­грамм и организацию их сопровождения. Таким образом, про­граммное изделие включает как программы, так и процедуры и правила их использования, а также всю документацию, необходи­мую для автоматизированной обработки данных. Программное из­делие может быть частью более крупной системы или самостоятель­ной системой.
Программотехника охватывает три ключевых момента создания программной продукции: методы, средства и процедуры.
Методы позволяют ответить на вопрос, как создать про­граммное изделие, и охватывают круг задач, связанных с планиро­ванием разработки, оценкой сроков и затрат, с анализом требова­ний, проектированием, кодированием и тестированием программ, с сопровождением программного изделия.


Средства предназначены для создания автоматизированной или полуавтоматизированной поддержки методов. Сегодня сущест­вуют средства практически для каждого из методов. Когда эти средства объединяются в интегрированную среду так, что информа­ция, полученная одним из них, может использоваться другим, со­здается система поддержки разработки программного обеспечения. Система автоматизации разработки программных средств получила название CASE — Computer-aided software engineering.
Процедуры программотехники объединяют в единый тех­нологический процесс методы и средства, позволяя наиболее раци­онально и эффективно вести разработку программной продукции. Процедуры устанавливают последовательность применения мето­дов, специфику представления требуемых документов, форм и отче­тов, последовательность выполнения контрольных и управляющих действий.
Программное изделие разрабатывается в четкой последователь­ности определенных шагов. Последовательность и содержание этих шагов характеризуют модель (парадигму) разработки программно­го изделия. В программотехнике существует несколько моделей, выбор той или иной из них зависит прежде всего от типа проекта и области приложения.
Наибольшее распространение в практике разработки программ­ных средств получила модель жизненного цикла программного изде­лия (ЖЦПИ).
ЖЦПИ — это многошаговый процесс, в котором все программные изделия проходят последовательно через ряд фаз, ус­тановленных соответствующими регламентирующими документа­ми.
Трудности разработки и внедрения технологии создания про­граммных изделий во многом определяются особенностями про­граммной продукции как предмета производства. Действительно, программные изделия имеют ряд существенных отличий от других видов продукции, создаваемой в результате человеческой деятель­ности.
1. В отличие от технического обеспечения, или аппаратных средств (hardware), которые являются физическими объектами, про­граммы представляют собой "неосязаемые" объекты.


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


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

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

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

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

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

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

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

5. Контроль правильности всех корректировок, вносимых в из­делие, и проверка качества измененных программ.

6. Доведение до пользователя информации о внесенных измене­ниях.

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

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

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

---

---