ОБЩИЙ ПЕРЕЧЕНЬ РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ Основная

1. Фараонов В. В. Delphi. Программирование на языке высокого уровня: Учебник

для вузов. – СПб., 2003. – 640 с.

Дополнительная

2.Агафонов В. Н. Спецификация программ: понятийные средства и их организация. – Новосибирск, 1987. – 190 с.

3.Бейбер Роберт Лоренс. Программное обеспечение без ошибок: Приемы и секреты создания правильных программ. – М., 1996. – 171 с.

4.Жоголев. Е. А. Лекции по технологии программирования. - М., 2002. – 151 с.

5.Защита программного обеспечения / Гроувер Д. и др. – М., 1992. – 286 с.

6.Йодан Э. Структурное проектирование и конструирование программ / Пер. с англ. под ред. Л. Н. Королева. – М., 1979. – 415 с.

8.Лукьянова Л.М. Технология программирования. МУ к лабораторным работам при подготовке специалистов по направлению 654600 – Информатика и вычислительная техника. – Калининград, КГТУ, 2003 /электронный вариант.

9.Лукьянова Л. М. Технология программирования. Лабораторный практикум по логическому программированию. МУ по выполнению лаб. работ при подготовке бакалавров по направлению: 552800 – Информатика и ВТ. – Калининград, КГТУ, 2000. – 98 с.

10.Лукьянова Л.М. Системный анализ: Уч. пособие.– Калининград, 2001. –234 с.

11.Лукьянова Л. М. Средства взаимодействия человека с ВС. Инженернопсихологическое проектирование интерфейса взаимодействия пользователя с ВС. МР для студентов вузов по спец. 22.02 – АСОИУ. – Калининград, 1997. – 80 с.

12.Лукьянова Л. М. Средства взаимодействия человека с вычислительной системой. Ч. 2. Средства организации диалога. МР для студентов вузов по спец. 22.02

–АСОИУ. – Калининград, 1997. – 90 с.

13.Пальчун Б. П., Юсупов Р. М. Оценка надежности программного обеспечения.

–СПб., 1994. – 84 с.

14.Пономарев В.Ф. Дискретная математика: Учебн. пособие. – Калининград., 1997. – 160 с.

15.Построение экспертных систем: Пер. с англ. / Под ред. Ф.Хейеса-Рота, Д. Уотермана, Д. Лената. – М., 1987. – 441с.

16.Правовая охрана программ для ЭВМ и баз данных. В кн.: РФ. Законы. – М.,

ВНИИПИ, 1998. – 15 с.

17.Сурков Д. А., Сурков К. А., Вальвачев А. Н. Программирование в среде

Borland Pascal для Windows. Справочное пособие. – Минск, 1996. – 432 с.

18.Хармон Э. Разработка Com-приложений в среде Delphi: Учебн. пособие: Пер.

с англ. – М., 2000. – 464 с.

19.Шумаков В. П. Delphi 3 и соэдание баз данных. – М., 1998. – 704 с.

20.ГОСТ Р8195-89. Оценка качества программных средств. Общие положения.

21.ГОСТ 21829-76. Система “человек-машина”. Кодирование зрительной информации. Общие эргономические требования.

22.Criteria for evaluation of software.– ISO TC97/SC7 #367 (Supersedes Doc-t

#327).

23.Revised version of DP9126 - Criteria of the evaluation of software quality characteristics. - ISO TC97/SC7 #610. Part 6.

24.ГОСТ 19. Программные документы.

1. Методические указания к разделу 1 –

"РАЗРАБОТКА ВНЕШНЕГО ОПИСАНИЯ ПРОГРАММНОГО СРЕДСТВА"

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

При внешнем описании ПС, которое в нотации Бэкуса-Наура можно представить как

<внешнее описание ПС> ::= <определение требований к ПС> <спецификация качества ПС> <функциональная спецификация ПС>

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

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

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

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

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

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

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

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

Определение требований к ПС может осуществляться в рамках разработки:

–управляемой пользователем;

–контролируемой пользователем;

–независимой от пользователя.

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

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

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

Необходимой частью системных требований ПС и его архитектуры являются соглашения о его интерфейсах: пользовательских и внешних (для стыковки с другими компонентами и приложениями). Чем позже будут определены соглашения об интерфейсах, тем больше вероятность того, что систему придется заново проектировать, программировать и тестировать. Для построения пользовательского интерфейса современная технология программирования рекомендует использовать RAD(быстрой разработки приложений)-системы, лучшей из которых на сегодняшний день является Delphi. При этом пользовательский интерфейс, как и остальные внешние и внутренние (межмодульные) интерфейсы, надо полностью определить, согласовать с заказчиком, и утвердить до начала этапа проектирования. Описание пользовательского интерфейса должно быть включено в спецификацию ПС на уровне определения каждого экранного поля, элемента ввода-вывода и средств навигации между содержащими их формами/окнами/экранами. Правильность интерфейса проверяет и утверждает реальный пользователь каждого рабочего места из организации-заказчика. К внешнему интерфейсу встраиваемой системы готовятся отдельные требования.

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

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

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

Чтобы добиться высокого качества, отслеживают причины возникновения ошибок в ПС, контролируют реальные источники ошибок, от которых непосредственно зависит эффективность его работы. Источники ошибок: неверно

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

Устранять ошибки необходимо по мере их возникновения. Каждый случай обнаружения и устранения ошибки надо обязательно документировать. Учет ошибок удобнее всего вести в нормализованном виде – в расчете на единицу объема, например на тысячу строк кода, так как с ростом проекта норма ошибок в нем увеличивается согласно принципу снежного кома. Целесообразно также контролировать среднее и максимальное время устранения ошибки, время от внесения ошибки до ее устранения на каждом этапе создания ПС и в течение первого года его эксплуатации.

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

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

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

Функциональная спецификация включает три описания:

–внешней информационной среды, в которой должен использоваться разрабатываемый ПС;

–функций ПС, определенных на множестве состояний этой информационной среды (такие функции называют внешними функциями ПС);

–исключительных ситуаций, которые могут возникнуть при выполнении ПС, и его реакций на эти ситуации.

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

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

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

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

Алгебраический подход базируется на использовании равенств вида:

Ln=Rn,

где Li и Ri, i=1, …, n, некоторые выражения, содержащие предопределенные операции, константы, переменные, от которых зависят определяемые функции (формальные параметры этих функций), и вхождения самих этих функций. Семантика определяемых функций извлекается в результате интерпретации (1.1). Интерпретация может базироваться на разных системах правил, формирующих, например, операционную, денотационную и аксиоматическую семантики.

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

РАВНО(L1, R1),

… (1.1)

РАВНО(Ln, Rn),

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

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

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

Функциональная спецификация оформляется согласованным с руководителем КР документом свободной формы, приводимом в приложении к ПЗ или в отдельном пункте ПЗ.

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

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

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

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

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

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

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

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

Протокол проверки правильности внешнего описания ПС (спецификации качества и функциональной спецификации) оформляется в виде табл.1.1, приводимой в приложении к ПЗ на КР.

В качестве объекта контроля при проверке правильности спецификации качества выступает тот или иной специфицированный критерий качества ПС, а при проверке правильности функциональной спецификации – та или иная функция ПС. В качестве уровней контроля следует использовать: 1 – пользовательский (самый верхний); 3 – архитектурный (соответствующий нижележащей согласно рис. 1 страте); 4 – структурный; 5 – модульный; 6 – тестовый (самый нижний). Вносимые изменения следует маркировать буквой алфавита (от “а” до “я”), за которой без пробела при определении внешнего описания следует номер уровня (1, 3-6), и датой внесения поправки. Если изменения при сопровождении ПС превысят принятый в коллективе разработчиков допустимый уровень, выпускается новая версия внешнего описания, и соответственно, ПС.

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

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

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

Фунциональность ПС на уровне пользовательского интерфейса: поддержка разработки внешнего описания; поддержка разработки архитектуры; поддержка разработки структуры ПС; редактирование блок-схем алгоритмов; поддержка разработки сетевого графика выполнения и защиты КР; поддержка документирования состояния ПС.

Реализуемая функция – поддержка разработки сетевого графика выполнения и защиты КР.

На рис.1.1.1 приведен пример Delphi-реализации пользовательского интерфейса разрабатываемого ПС.

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

Первый шаг в построении сетевого графика – определение перечня работ. Поэтому вначале заполняют 1, 2–4 графы таблицы вида 5.1. Затем определяют наиболее ранний и поздний моменты наступления событий и заполняют соответственно графы 5 и 6 таблицы, рассчитывают резервы времени на события (см. графу 7) каждого события. Рассчитывают полный, свободный, независимый и гарантированный резервы времени на каждую работу. После расчетов становится известным директивный срок выполнения всего комплекса работ, а также критические работы (имеющие нулевые резервы времени. Таким образом, данные для построения сетевого графика подготовлены.

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

1.1.1. Разработка требований к ПС. Так как пользователями ПС являются студенты, выработку исходных требований целесообразно проводить в рамках разработки, контролируемой пользователем. Выберем представителя пользователей – <имярек>, с которым будем согласовывать внешнее описание ПС.

Требования функциональной полноты на уровне пользовательского интерфейса,

определяют главное меню с основными пунктами: “Редактор внешнего описания”, “Редактор архитектуры”, “Редактор структуры”, “Редактор блок-схем”, “Редактор сетевого графика”, “Редактор состояния ПС”. Для обеспечения информативности ПС (выполнения одного из общих требований к ПС, определенных выше) введем в

главное меню дополнительные пункты: “Помощь” и “О программе”. Назначение первых четырех пунктов позволяет сгруппировать их в единую группу ” Редакторы ”, а последних двух – в “Справка”, разгрузив, таким образом, главное меню.

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

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

Качество реализации F, выражаемое в относительных единицах ≥ 0,4.

Используем системный подход, и будем рассматривать будущий ПС как систему, группу ”Редакторы” как подсистему первого уровня, а “Редактор сетевого графика” как подсистему второго уровня.

а)

б)

Рис. 1.1.1

Поскольку решаемая ПС задача относится к классу хорошо структурированных расчетных задач, достаточно легко последовательно сформировать системное представление программного компонента “Редактор сетевого графика” в виде:

S1 = <_, _, целостность> → S2 = <целое, свойства целого> или

S2 = < части, отношения, свойства целого и частей целого>..

Рассматривая системное представление “Редактора сетевого графика” S1, мы имеем определенную заказчиком ПС реализуемую функцию F, с требуемым качеством ее реализации.

Рассмотрим системное представление “Редактора сетевого графика” S2 в виде наиболее простой модели – модели “входы-выходы”. В этом случае:

S2= < A, >,

где A – несущее множество модели, А= {X, Y}; X – входы модели, Х={Xk}|k=1,…,4; Y – выходы модели, Y = {Yi}|i=1,…,11;

– обобщающее отношение пересечения, такое что S2 X x Y или S2 X∩ Y;

Другое также обобщенное, но более богатое системное представление “Редактора сетевого графика” S2 – в виде модели “черного ящика”, выделенного из окружающей среды (будущего ПС и, в частности, его редакторов), представлено на рис. 1.1.1.

Рис. 1.1.1.1

В этом случае:

S2= < A, , C >,

где C – свойства “Редактора сетевого графика” как обобщенного целого, определенного на своих частях: функции F, входах X и выходах Y, на а также свойства частей.

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

Определим выходы (Y) и входы (X) для реализации заданной функции F в соответствии с требуемым качеством ПС. Выходы Yi (i=1,…,11) – это массивы значений из i-х граф табл. 5.1, (5-11)-я из которых – рассчитываемые. Сведем данные об Yi в отдельные таблицы вида 1.1.1 и 1.1.2. Предусмотрим для представления

результатов вычислений видеограммы двух типов: 1 – табличная форма, членимая на относительно самостоятельные части для удобства вывода на экран и работы с ними (в виде табл. 1.1.1 и 1.1.2), и 2 – соответствующая графическая форма, в которой события будем изображать кружками, работы - стрелками, фиктивные работы – пунктирными линиями, критический путь красными жирными стрелками. Предусмотрим также сохранение в файле с именем T_SCHEME.TXT видеограммы результатов работы ПС в табличной форме и в файле с именем G_SCHEME.BMP видеограммы результатов работы ПС в графической форме.

Входы Xk (k=1,…,4) – это массивы значений из k-х граф табл. 5.1. Сведем для удобства пользователя данные о них в отдельную таблицу вида 1.4, отметив пересекаемость выходных данных с входными, Xi=Yi, i=1,…,4. Для ввода входных данных ПС будем использовать видеограмму в виде табл. 1.1.3.

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

Таблица 1.1.3

Видеограмма входных данных: пример

Определим окружающую среду ПС. При создании ПС будем ориентироваться на имеющуюся у пользователей вычислительную систему – объединенные в локальную сеть IBM PC-совместимые рабочие станции стандартной конфигурации с параметрами: CPU не ниже 133 МГц, RAM не менее 32 Мбайт, видеокартой, обеспечивающей разрешение 1024х768 и режим True Colour. На выделенной станции преподаватель должен иметь возможность проверить текущее состояние разработки в

Выделенные курсивом группы требований к разрабатываемому ПС сведем в документ “Исходные требования к ПС “Поддержка выполнения КР по технологии программирования ””.

1.1.2. Спецификация качества ПС. При оценке качества ПС будем использовать следующие критерии оценки качества программной реализации “Редактора сетевого графика”: функциональность, надежность, легкость использования, сопровождаемость и эффективность, – из которых как основные выберем первые четыре. Определим эти критерии на основе соответствующих примитивов качества, для которых пользователь определил соответствующие весовые коэффициенты: информативность (весовой коэффициент 0,2), понятность (весовой коэффициент 0,2), коммуникабельность (весовой коэффициент 0,1), точность (весовой коэффициент 0,2), удобочитаемость (весовой коэффициент 0,1), документированность (весовой коэффициент 0,2).

Функциональность будем определять полнотой реализуемых на уровне пользовательского интерфейса функций, соответствующими пунктам главного меню: “Редакторы”, “Состояние ПС”, “Справка”.

Надежность будем определять:

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

модулями) “Редактора сетевых графиков”, надежной работой всех модулей данной структуры;

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

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

–точностью. В случае данных вещественного типа определим точность представления е=10 –2;

–защищенностью от изменения сторонними пользователями посредством паролирования (с возможностью изменения пароля), а значит недоступностъю пунктов меню: “Добавить”, “Удалить”, “Изменить”; защищенностью от случайного изменения “своим” пользователем - сохранение цепочки предыдущих изменений, резервирование в виде *.BAK-файла, создание архивной копии по завершении каждого сеанса работы с ПС.

Легкость использования. Во внемашинном документе “Инструкция пользователя” приведем все выдаваемые ПС видеограммы (пример видеограммы логотипа см. на рис. 1.1,а, а видеограммы главного окна редактора сетевых графиков

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

Сопровождаемость будем определять:

–изучаемостью, для чего предусмотрена разработка документов: “Исходные

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

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

Эффективность будем определять: временной эффективностью, эффективностью по памяти и эффективностью по устройствам. Для определения эффективности подготовим контрольный тест с тремя, все более расширяемыми наборами входных данных: для 50, 150 и 250 работ. Если построить по результатам работы “расчетной” и “графической” частей редактора графики в координатах, приведенных на рис. 1.1.2.1 для ОЗУ: 32, 64 и 128 K и различных по быстродействию процессоров и устройств вывода, полученная зависимость t=t(N) выражает временную эффективность ПС на конкретной конфигурации устройств и служит мерой при оценке t для реальных условий. На рис. 1.1.2.1 приведен условный