Учебное пособие 1438

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

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

8.3. Документирование программ

Документация должна полностью соответствовать создаваемым и распространяемым программам, обеспечивать познаваемость ПС персоналом, обеспечивать развитие и модернизацию для увеличения ЖЦ ПС. Документация составляется в соответствии со стандартами ЕСПД - ГОСТ 19.001-87 и ГОСТ 19.105-88. Документация включает титульный лист, информационную и основную части.

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

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

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

163

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

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

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

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

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

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

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

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

Контрольные вопросы

164

1.Какая документация составляется при испытаниях ПС?

2.Какая информация должна присутствовать в документации к ПС?

3.Что отражается в руководстве пользователя?

9.УПРАВЛЕНИЕ РАЗРАБОТКОЙ ПРОГРАММНЫХ

СИСТЕМ

9.1. Примерная последовательность действий при разработке ПС

Следующую последовательность действий можно применить при разработке ПС.

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

Определить структуру ПС, модулей; используя CASEтехнологии, построить модель проектируемой ПС, оценить производительность и память.

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

165

Разработать спецификации на модули и группы про-

грамм.

Закодировать и отладить модули в статике (спланировать отладку, протестировать модули, локализовать ошибки, откорректировать модули).

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

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

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

Испытать ПС на полноту и надежность функционирования, обработать результаты испытаний и разработать сертификат.

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

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

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

2.Организация технологии процесса разра-

ботки.

3.Обслуживание.

4.Создание документации.

5.Испытание.

6.Поддержка.

166

7.Сопровождение.

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

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

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

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

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

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

167

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

9.2. Трудоемкость разработки ПС

Чтобы спланировать все работы [1, 11, 15], необходимо определить срок разработки и составить календарный план. Для этого необходимо воспользоваться одной из моделей жизненного цикла программного обеспечения.

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

по количеству строк; метод аналогии; нормативный метод; метод экспертных оценок;

проект без определения конкретной стои-

мости.

1. По количеству строк – Line of Code (LOC). По статистическим данным, норма составляет 10 строк программы в день. Это число увеличивается или уменьшается в зависимости от сложности программы. Эти 10 строк включают в себя проектирование, кодирование, отладку, тестирование.

Для определения общей трудоемкости принято распределение затрат :

20 % времени на анализ требований;

20 % на проектирование;

20 % на кодирование;

40 % на отладку, тестирование.

168

Основная проблема – неопределенность числа строк всей программы.

2.Разрабатываемая программная система сравнивается с существующим аналогом, и время разработки аналога корректируется в соответствии с конкретным приложением системы.

3.Этот метод похож на метод аналогии, но в качестве аналогов берутся типовые программные средства. Существует норма времени на разработку программных средств вычислительной техники (Москва, ГОСКОМТРУД, 1996г.).

4.Метод экспертных оценок применяется для новых, нетиповых разработок.

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

9.3. Организация коллективной разработки

При разработке программных средств происходит дифференциация коллектива программистов [1, 3, 11, 15]: разработка частей проекта различной сложности возлагается на программистов различной квалификации. Различают:

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

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

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

гда 1 человек в состоянии охватить детали всего проекта, можно использовать метод бригады главного программиста. Бригада состоит из 7 человек: главного программиста; помощника главного программиста; библиотекаря; программистов.

169

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

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

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

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

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

2.Разработчики выполняют работы на отдельных этапах. Состав меняется от этапа к этапу.

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

инаучные вопросы. Занят на всех этапах.

4.Библиотекарь проекта ведет весь архив.

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

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

170

на каждом этапе руководителем является наиболее квалифицированный специалист.

Контрольные вопросы

1.Как составляется план разработки ПС?

2.Как организовать коллективную разработку ПС?

3.Как оценить трудоемкость разработки ПС?

10.ПОКАЗАТЕЛИ КАЧЕСТВА ПРОГРАММНОЙ

СИСТЕМЫ 10.1. Оценка качества программных средств

Для оценки качества программного средства применяют функциональные и конструктивные критерии качества [1, 3, 11].

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

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

Кфункциональным критериям относят функциональную корректность (отсутствие ошибок в структуре программы,

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

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

171

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

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

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

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

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

В 1991 г. разработан стандарт ISO / ЕС 9126; рекомендуется применять 21 показатель для оценки программных свойств.

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

Аналогичные показатели записаны в ГОСТ 28.195-89.

10.2 Надежность функционирования программных систем

Выделяют два понятия: отказ и сбой (нарушения работоспособности программы).

172