книги / Надежность программного обеспечения систем обработки данных

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

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

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

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

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

191

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

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

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

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

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

10.2. Иерархия документа

192

детализации. На рисунке схематически показан поиск детальной информации некоторой специфической функ­ ции F.

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

10.2. СТРУКТУРА ДОКУМЕНТАЦИИ

Несмотря на наличие определенной системы стандар­ тизации, нельзя не отметить, что в настоящее время не существует единого взгляда на состав комплекта доку­ ментации, сопровождающей разрабатываемую систему ПО Применительно к ЕС ЭВМ система документации Изложена в работе (5].

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

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

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

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

193

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

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

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

1) обязанности персонала, эксплуатирующего ПО;

2)доступное н недостающее оборудование;

3)объем и частота ввода и вывода информации;

4)недостатки и ограничения существующей системы;

5)ориентировочные оценки предполагаемой стоимо­

сти,

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

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

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

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

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

194

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

1) изменения в способе выполнения действий,

2)воздействия окружающей среды,

3)взаимосвязь с другим программным обеспечением,

4)планируемые изменения и улучшения

Эти требования определяют понятие гибкости изме­ нения ПО.

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

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

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

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

Секция Основная информация включает краткое опи­ сание, обобщающее природу ПО, для которого опреде­

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

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

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

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

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

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

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

3)приемники Определить назначенные приемники входных данных,

4)носители выходных данных и устройства вывода. Определить носители и аппаратные устройства, предназнаменные для воспроизведения выходных данных при­ емнику,

196

5)критическое значение Одно значение или область значений могут иметь особое Значение для получателя,

иэто должно быть специфицировано,

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

8) частота''корректировки и обработки. Определить ожидаемую частоту изменений дВиных и ожидаемую чйСтоту’Обработки входйы* данных Если входные данfflife наступают случайно, то средний частота и некоторая (Лера вариации должны быть определены

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

В разделе процедур даются Специальные инструкции для процедур сбора данных Необходимо аключить подроб­ ные формать!, где они применимы, ожидаемые носители срязи данных

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

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

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

Секция Основная информация содержит такую же ин­ формацию. как и предыдущие документы

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

197

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

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

1)процессор и емкость основной памяти;

2)память, периферийные устройства, носители И т. д.1

3)устройства ввода по их типам;

4)устройства передачи данных.

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

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

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

В секции Требования к составляемым программам

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

1)описание требований к программе;

2)описание условий работы;

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

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

19В

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

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

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

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

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

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

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

1)загрловок и признаки;

2)формат и типы данных, размещение записи;

3)критерий истинности;

4)изменчивость и частота;

5)средства ввода;

6)описание исходного модуля и его специальный интерфейс;

7)гарантия обеспечения безопасности.

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

>99