Лекция 03.05.2011

Международные стандарты на разработку ПО

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

wwwcdl.bmstu.ru – сайт кафедры РК-6. В разделе «дистанционное облучение» и «учебныеметодические материалы». Авторы: Волосатова Тамара Михайловна (заместитель зав.каф. РК-6), Родионов С.В., Романова Т.Н. (Адрес сайта написан без опечаток).

«Требования к документации: выдать пользователю все UML-диаграммы, выдать все, что угодно, кроме того, что надо» - неправильное. Эта лекция посвящена тому, чего давать, а чего нет.

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

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

o должна отражать все разрабатываемые объекты и процессы жизненного цикла прикладных программ и данных.

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

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

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

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

Эксплуатационная документация (ниже)

Исследовательская документация (ниже)

Профиль стандартов документирования объектов

Это группа стандартов, которая должна определять:

1.Логическую структуру (по стандарту еспд) программных и информационных компонентов и баз данных компонента.

2.Профиль стандартов должен содержать спецификации (т.е. подробные описания) на внутренние межмодульные интерфейсы между компонентами системы и интерфейсы с внешней средой.

3.Язык и правило программирования. Обосновываем выбор языка, описание используемых библиотек.

4.Комментарии текстов программ, описание данных.

5.Структуру и содержание исходных и отчетных документов по этапам разработки (проектирования) и тестирование, которое было проведено в рамказ создания. SNN.

6.Критерии оценки качества – это отвечает заявленным в ТЗ характеристикам, которые замеряются секундомером, эти характеристики должны вписываться в стандарты качества.

Стандарт SMM (уровни):

1. Команда работает впервые. Самый нижний уровень

2. ..

3. ..

4. ..

5. Сертификаты IBM, Microsoft и т.п.

Эксплуатационная документация

Напр., требуется в аутсорсниговую компанию переслать.

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

Не следует передавать слишком много информации. Ее пользователю и передаем.

Эксплуатационная документация должна содержать следующие элементы:

1.Краткую (однозначная!) аннотацию и описание решаемых задач и алгоритмов.

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

3.Описание пользовательских (внешних) интерфейсов.

4.Описание входных и выходных данных. Если входных таблиц много, то идет все в приложении, а в ТЗ ссылка на них.

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

Исследовательская документация

Она имеет экспериментальны характер, зависящий от возможных целей исследования.

Мы решаем систему диф.ур. ДисТокса. Система слишком сложна для аналитического решения.

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

В исследовательской документации следует указать:

Физический процесс.

Математическая постановка задачи.

Тестирование

Вобщем, это все, что касается тестирования и моделей: информационной, и еще двух каких-то.

Пользовательская документация

В дипломе должна быть: инструкция для администратора и инструкция для пользователя. Там пишут:

Как инсталлировать

Как работать

Особые моменты (рестарт, устранение неполадок)

Ограничения, которые следует иметь в виду. Номера стандартов, которые регламентируют Это:

1.ISO 6592:1985.ОИ.Руководство по документации для вычислительных систем.

2.ISO 9294:1990-ТО.ИТ.Руководство по управлению документированием ПО.

3.ISO 9127:1988.СОИ.Пользовательская документация на ПС.

Книга Липаева… это один из ведущих людей, который принимает участие в разработке ГОСТов. Дело в том, что международные ГОСТы не согласуются с российскими. Выписки из его книги:

1.ISO 12207:1995 (ГостР-1999). ИТ.Процессы жизненного цикла программных средств. Этот стандарт регламентирует жизненные циклы, которые мы знаем.

2.ГОСТ 51904 – 2002. Программное обеспечение встроенных систем. Общие требования к разработке и документарованию.

3.ISO 9126:1991 (ГостР – 1993).ИТ.Оценка программного продукта (не системы, не вычислительной системы, не информационной и т.п., а именно продукта). Характеристики качества и руководство по их применению.

У этого стандарта есть несколько частей.

ISO 9126-1–4:1991.ИТ.Качество ПС. Часть1. Модель качества

Часть2. Внешние метрики (которые оценивают качество) Часть3. Внутренние метрики

Часть4. Метрики качества в использовании применительно к системам.

4.ISO 14102:1995. Оценка и выбор CASE-средств.

5.ISO 14471:1995. Руководство по адаптации CASE-средств.

6.ISO 15910:1999. (ГостР – 2002) ИТ. Пользовательская документация.

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

Стандарты, регламентирующие сопровождение и управление конфигурацией сложных программных средств.

При сопровождении мы должны фиксировать:

Анализ и фиксация дефектов.

Реализация модификаций системы состоит из следующих задач:

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

Персонал должен записать критерии оценки при тестировании и оценить

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

Процесс управления конфигурацией:

oСоставляется план управления конфигурацией (в какие сроки, какую версию, что эта версия делать будет)

oИдентификация и запись запросов на изменение (Т.е. что требовалось в новой версии изменить, анализ оценки изменений), а также оценка изменений.

o Ликвидация дефектов в программе.