Неправильный перевод информации как причина ошибок в программных средствах

    3.3. Что  такое сопровождение ПС!

    3.4. Что  такое качество ПС!

    3.5. Что  такое смежный контроль!

    Не переходи мост, пока не дошёл до него. Народная пословица

    Глава 4

    ВНЕШНЕЕ ОПИСАНИЕ ПРОГРАММНОГО

    СРЕДСТВА

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

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

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

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

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

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

    Исходным  документом для разработки внешнего описания ПС является определение требований к ПС. Через этот документ передается от заказчика (пользователя) к разработчику основная информация относительно требуемого ПС, поэтому формирование этого документа представляет собой довольно длительный и трудный итерационный процесс взаимодействия между заказчиком и разработчиком. Трудности, возникающие в этом процессе, связаны с тем, что пользователи часто плохо представляют, что им на самом деле нужно: использование компьютера в "узких" местах деятельности пользователей может на самом деле потребовать принципиального изменения всей технологии этой деятельности (о чем пользователи, как правило, и не догадываются). Кроме того, проблемы, которые необходимо отразить в определении требований, могут не иметь определённой формулировки [65], что приводит к постепенному изменению понимания разработчиками этих проблем. В связи с этим определению требований часто предшествует процесс системного анализа, в котором выясняется, насколько целесообразно и реализуемо "заказываемое" ПС, как повлияет такое ПС на деятельность пользователей и какими особенностями оно должно обладать. Иногда бывает полезным разработка упрощенной версии требуемого ПС, называемую прототипом ПС. Анализ "пробного" применения прототипа позволяет выявить действительные потребности пользователей и существенно уточнить требования к ПС.

    В определении  внешнего описания сразу бросаются  в глаза две самостоятельные его части. Описание поведения ПС определяет функции, которые должна выполнять ПС, и потому его называют функциональной спецификацией ПС. Функциональная спецификация определяет допустимые фрагменты программ, реализующих декларированные функции. Требования к качеству ПС должны быть сформулированы так, чтобы разработчику были ясны цели [35], которые он должен стремиться достигнуть при разработке этого ПС. Эту часть внешнего описания будем называть спецификацией качества ПС (ее часто называют нефункциональной спецификацией [65], но в этом случае она включает и требования к технологическим процессам). Она, в отличие от функцио-

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

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

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

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

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

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

    Неправильное  понимание требований заказчиком, пользователями и разработчиками связано обычно с различными взглядами на роль требуемого ПС в среде его использования [65]. Поэтому важной задачей при создании определения требований является установление контекста использования ПС, включающего связи между этим ПС, аппаратурой и людьми. Лучше всего этот контекст в определении требований представить в графической форме (в виде диаграмм) с добавлением описаний сущностей используемых объектов (блоков ПС, компонент аппаратуры, персонала и т. п.) и характеристики связей между ними.

    Известны  три способа разработки определения  требований к ПС [35]:

    •   управляемая пользователем разработка,

    •    контролируемая пользователем разработка,

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

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

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

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

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

    С точки  зрения обеспечения надёжности ПС наиболее предпочтительным является контролируемая пользователем разработка.

    4.3. Спецификация качества программного средства

    Разработка  спецификации качества сводится, по существу, к построению своеобразной модели качества требуемого ПС [22, 35]. В этой модели должен быть перечень всех тех свойств, которые  необходимо обеспечить в этом ПС и  которые в совокупности образуют приемлемое для пользователя качество ПС. При этом каждое из этих свойств должно быть в достаточной мере конкретизировано с учётом определения требований к ПС, а также с учётом возможности оценки его наличия у разработанного ПС или оценки степени, в которой ПС обладает этим свойством.

    Для конкретизации  качества ПС по каждому из критериев  используется стандартизованный набор достаточно простых свойств ПС, разработанных ISO [7, 22, 59, 63], однозначно интерпретируемых разработчиками. Такие свойства мы будем называть примитивами качества ПС. Некоторые из примитивов могут использоваться по нескольким критериям. Ниже приводится зависимость критериев качества от примитивов качества ПС.

    Функциональность: завершённость.

    Надёжность: завершённость, точность, автономность, устойчивость, защищённость.

    Лёгкость  применения: П-документированность, информативность (применительно к документации по применению), коммуникабельность, устойчивость, защищённость.

    Эффективность: временная эффективность, эффективность по ресурсам (по памяти), эффективность по устройствам.

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

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

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

    Модифицируемость: расширяемость, лёгкость изменения, структурированность, модульность.

    Мобильность: независимость от устройств, автономность, структурированность, модульность.

    Ниже  определяются используемые примитивы  качества ПС [22, 59, 63]. Здесь приводится достаточно большой список, состоящий из 19 примитивов качества, которые следует рассматривать как независимые (самостоятельные) понятия. Некоторые их комбинации образуют более крупные понятия - критерии и подкритерии качества. Такие комбинации можно рассматривать как определённые системы. Но ни одна из этих комбинаций не содержит более шести примитивов (см. выше), так что правило, сформулированное в п. 2.1, здесь не нарушается.

    Завершённость {completeness) ПС - свойство, характеризующее степень обладания ПС всеми необходимыми частями и чертами, требующимися для выполнения своих явных и неявных функций.

    Точность {accuracy) ПС - мера, характеризующая приемлемость величины погрешности в выдаваемых программами ПС результатах с точки зрения предполагаемого их использования.

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