- •СОДЕРЖАНИЕ
- •1.1. Основные понятия и определения
- •1.2. Жизненный цикл программных средств
- •2.1. Стратегии разработки программных средств и систем
- •2.1.1. Базовые стратегии разработки программных средств и систем
- •2.1.2. Каскадная стратегия разработки программных средств и систем
- •2.1.3. Инкрементная стратегия разработки программных средств и систем
- •2.1.4. Эволюционная стратегия разработки программных средств и систем
- •2.2.1. Общие сведения о каскадных моделях
- •2.2.2. Классическая каскадная модель
- •2.2.3. Каскадная модель с обратными связями
- •2.2.5. V-образная модель
- •2.3.1. Базовая RAD-модель
- •2.4.1. Общие сведения об инкрементных моделях
- •2.4.2. Инкрементная модель с уточнением требований на начальных этапах разработки
- •2.5.1. Общие сведения об эволюционных моделях
- •2.5.3. Структурная эволюционная модель быстрого прототипирования
- •2.5.5. Спиральная модель Боэма
- •2.5.6. Упрощенные варианты спиральной модели
- •3.1. Классификация проектов по разработке программных средств и систем
- •3.2. Процедура выбора модели жизненного цикла разработки программных средств и систем
- •3.3. Адаптация модели жизненного цикла разработки ПС и систем к условиям конкретного проекта
- •4.1. Модульное проектирование программ
- •4.2. Метод нисходящего проектирования
- •4.2.1. Пошаговое уточнение
- •4.2.2. Кодирование программы с помощью псевдокода и управляющих конструкций структурного программирования
- •4.2.3. Использование комментариев для описания обработки данных
- •4.2.4. Анализ сообщений
- •4.3. Метод восходящего проектирования
- •4.4. Метод иерархического проектирования модулей (метод Джексона)
- •4.4.1. Основные конструкции построения структур данных
- •4.4.2. Построение структур данных
- •4.4.3. Проектирование структур программ
- •4.4.4. Этапы конструирования программы
- •4.5.1. Связность модуля
- •4.5.2. Сцепление модулей
- •5.1. Общие сведения о CASE-технологиях
- •5.2. Методология структурного анализа и проектирования SADT
- •5.2.2. Основные понятия IDEF0-модели
- •5.2.3. Синтаксис диаграмм
- •5.2.4. Синтаксис моделей
- •5.2.6. Процесс моделирования в IDEF0
- •5.3. Информационное моделирование
- •5.3.1. Сущности
- •5.3.2. Атрибуты
- •5.3.3. Способы представления сущностей с атрибутами
- •5.3.4. Классификация атрибутов
- •5.3.5. Правила атрибутов
- •5.3.6. Связи
- •5.3.7. Безусловные связи
- •5.3.8. Условные формы связи
- •5.3.9. Формализация связи
- •5.3.10. Подтипы и супертипы
- •5.3.11. Рабочие продукты информационного моделирования
- •6.1. Эволюция Case-средств
- •6.2. Концептуальные основы Case–средств
- •6.3.1. Поддержка графических моделей
- •6.3.2. Контроль ошибок
- •6.3.3. Организация и поддержка репозитория
- •6.3.4. Поддержка процесса проектирования и разработки
- •6.4. Классификация CASE–средств
- •6.4.1. Классификация по типам
- •6.4.2. Классификация по категориям
- •6.4.3. Классификация по уровням
- •6.5. Инструментальные средства компании Telelogic, предназначенные для автоматизации жизненного цикла программных средств и систем
- •6.5.1. Telelogic DOORS
- •6.5.2. Telelogic TAU
- •6.5.3. Telelogic SYNERGY
- •6.5.4. Telelogic DocExpress
- •6.5.5. Telelogic TAU Logiscope
- •7.2. Реализация процесса документирования в соответствии со стандартом ISO/IEC 15910:1999
- •7.2.2. Выполнение процесса документирования
- •7.2.3. Содержание плана документирования
- •7.2.4. Требования к содержанию спецификации стиля документации
- •ЛИТЕРАТУРА
7. |
Тиражирование |
и |
распространение |
в |
соответствии |
|||
с планом документирования |
|
|
|
|
|
|||
Тиражирование и распространение документации(седьмая работа, см. |
|
|||||||
рисунок |
7.2) производится |
документатором в |
соответствии с |
плано |
||||
документирования. |
|
|
|
|
определеныконтроль |
|
||
В |
плане |
документирования должны |
быть |
|
||||
изменений |
и |
сопровождение |
документации. При |
этом |
|
должны |
быть |
|
предусмотрены четыре типа изменений документации:
·функциональные изменения данной версии– изменения функции программного средства, внесенные при разработке документации и отраженные в опубликованной документации;
·функциональные изменения последующей версии – изменения функции программного средства, внесенные при разработке документации и не отраженные в опубликованной документации, но подлежащие учету в последующей редакции документов;
·изменения программного средства после публикации– изменения функций программного средства после издания данной документации;
· изменения |
документа |
после |
публикации– изменения |
в |
||
опубликованной |
документации, |
обусловленные |
изменениями |
|||
программного средства или обнаружением погрешностей в данной
документации. |
|
|
|
Необходимо |
выполнять |
проектирование |
документации , чтобытак |
допустить внесение в нее изменений всех четырех видов. Для этого необходимо предусмотреть процедуру внесения в документ каждого типа изменений.
7.2.3. Содержание плана документирования
План документирования должен охватывать следующие вопросы (но не ограничиваться ими):
· рабочее наименование, назначение, область применения и ограничения по использованию планируемой документации;
·спецификация стиля;
·определение аудитории пользователей;
·целевое назначение планируемой документации;
· содержание (план-проспект) документации с оценкой постраничного объема и соответствующие уточнения для других машинных носителей документации;
·номенклатура поставки – число печатных копий, наличие электронных копий, форматы дисков и файлов(включая версии программных средств);
173
·установление собственника авторских прав на документацию и любых других прав собственности;
· обеспечение |
перевода |
документации |
на |
другие (приязыки |
необходимости); |
|
|
|
|
·уровни (грифы) секретности и конфиденциальности документации (при необходимости);
·процедуры и проверки, могущие влиять на процесс разработки
документации, включая (при необходимости) хранение, поиск, резервирование, передачу и оценку качества документации;
·методы и средства производства (тиражирования) документации;
·структура коллектива разработчиков документации и, возможно, план выбора данной структуры;
·взаимосвязи проекта документации;
·почасовая загрузка и зарплата разработчиков документации;
· |
требования к проектным ресурсам(включая информационные |
и |
||||
|
прочие |
ресурсы, |
предоставляемые |
заказчиком) и |
срокам |
их |
|
представления; |
|
|
|
|
|
· |
метод |
передачи |
документатору |
информации |
об |
измене |
|
программного средства в процессе его разработки; |
|
|
|||
·планы контроля изменений и сопровождения документации(при необходимости);
·планы проверки документации после ее создания;
·календарное планирование (графики) документирования по контрольным точкам, включая (при необходимости):
·утверждение плана документирования;
· подготовку, проверку |
и |
корректировку |
проекта |
каждого |
документа; |
|
|
|
|
·тестирование на практичность;
·подготовку оригинала фотошаблонов;
·распечатку, переплетение и распространение документации.
При необходимости каждый из пунктов плана должен быть описан для каждого элемента документации.
В стандарте ИСО/МЭК 15910 представлен образец плана документирования, содержащий следующие разделы: область применения и ограничения, оформление и стиль описания, аудитория, проект содержания документации, номенклатура поставки, авторские права, транспортирование, процесс разработки и контроль, тиражирование, коллектив разработчиков документации, ресурсы, тестирование на практичность, график работ.
174