Материал: DO178 Учебное пособие_в183

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

1 Основание для проведения ОКР

2 Исполнитель ОКР

3 Цель выполнения ОКР

4 Назначение продукции

5 Технические требования к программе или программному комплексу

5.1 Состав продукции

5.2 Требования к функциональным характеристикам

5.2.1 Требования к составу выполняемых функций

5.2.2 Требования к организации входных данных

5.2.3 Требования к организации выходных данных

5.2.4 Требования к временным характеристикам

5.3 Требования к надёжности

5.4 Условия эксплуатации

5.4.1 Климатические условия эксплуатации

5.4.2 Требования к видам обслуживания

5.4.3 Требования к численности и квалификации персонала

5.5 Требования к составу и параметрам технических средств

5.6 Требования к информационной и программной совместимости

5.7 Требования к упаковке и маркировке

5.7.1 Требования к упаковке

5.7.2 Требования к маркировке

5.8 Требования к транспортированию и хранению

5.9 Требования по стандартизации и унификации

6 Требования к документации

7 Специальные требования

7.1 Требования к испытаниям

7.2 Требования к работам, выполняемым с участием иностранных партнёров

8 Технико-экономические показатели

8.1 Основные технико-экономические требования

8.2 Требования к достижению программных индикаторов и показателей

9 Требования к патентной чистоте и патентоспособности

10 Перечень, содержание, сроки выполнения и стоимость этапов

10.1 Наименование этапов и выполняемые работы

Этап 1. Техническое предложение

Этап 2. Эскизный проект

Этап 3. Технический проект

Этап 4. Разработка рабочей программной документации

Этап 5. Изготовление опытного образца и проведение предварительных испытаний

10.2 Сроки исполнения и финансирование по этапам

11 Порядок выполнения и приемки этапов ОКР

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

Приложение 2. Технико-экономическое обоснование проекта

Характерно, что собственно разработка исходного программы в терминах ТЗ рассматривается как изготовление рабочей программной документации (Этап 4) в разделе 10.1, и поставляемыми рабочими продуктами являются текст программы и другие сопроводительные документы.

    1. Примерная форма еженедельного отчета

Обычно еженедельный отчет о ходе проекта (project weekly status report) составляется каждым участником проекта и рассылается по электронной почте в установленный день, например, среда до конца рабочего дня (в исключительных случаях – на следующий день до начала рабочего дня) по установленному списку адресатов. В этот список, как правило, входят руководитель проекта, непосредственный руководитель, коллеги автора по проекту, заказчик, представитель группы качества. В поле такого «Тема» электронного письма указывается акроним проекта и «Еженедельный отчет» и дата отчета. Привычный шрифт текста – Ариэль, длина строки не должны превышать 65 символов, общая длина отчета – 1 или 1,5 страницы.

<Уровень секретности>

<Название подразделения>

<Акроним проекта> Еженедельный отчет о ходе проекта <должность> <ФИО>

<Дата отчета в формате дд-МММ-гггг>

----------------------------------------------------------------------------------------------------------------------------

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

** Красные флажки – проблемы

·····

** Главные проблемы заказчика

·····

** Новости продукта

·····

** «Разведка донесла»

·····

** Прочее

·····

ОБЗОР ПРОДУКТА:

<описание>

НОВЫЕ ПРОБЛЕМЫ и МЕРЫ ПО НИМ:

1) Проблема: …

Флажок: <красный/желтый>

Области воздействия и последствия: <описание>

Предложенные действия: <описание>

2) ...

НОВЫЕ РИСКИ И УПРАВЛЕНИЕ РИСКАМИ:

1) РИСК: <описание>

Серьезность риска: <высокая/средняя/низкая>

Триггер: <событие и его срок>

Действие: <описание>

2) ...

СВОДКА О ПРОДВИЖЕНИИ В ПРОЕКТЕ:

<описание>

СОСТОЯНИЕ ГЛАВНЫХ ЭТАПОВ (только жесткие этапы, не более 20):

Описание Срок : Фактич.

---------------------------------------------------------------------- ----------------------

1) <описание> <дата>:<дата>

2) …

СОСТОЯНИЕ ГРАФИКА РАБОТ: <+/–> <количество дней>

ПОПРАВОЧНЫЕ ДЕЙСТВИЯ ПО СНИЖЕНИЮ ОТСТАВАНИЯ:

<описание>

ОБЕСПЕЧЕННОСТЬ КАДРАМИ:

По плану: <количество человек>

По факту: <количество человек>

В стандартной «шапке» отчета указывается уровень секретности данного документа (например, «Только для внутреннего использования в данной организации»), название подразделения, акроним проекта, должность и имя автора и дата составления отчета. В качестве напоминания всем читателям отчета в шапке стоит стандартная фраза: «Приветствуются любые замечания, вопросы, проблемы или действия» (Any comments, questions, issues, or action items would be appreciated).

Далее перечисляются так называемые «красные флажки» (red flags) – проблемы в проекте, с которыми автор не может справиться самостоятельно в пределах выделенных ему ресурсов, и ему нужна помощь или иная форма поддержки.

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

В разделе «ОБЗОР ПРОДУКТА» (PRODUCT OVERVIEW) приводится аннотация разрабатываемого программного продукта и его краткий обзор – обычно 1-2 абзаца, которые, как правило, не меняются в течение всей разработки.

В следующем разделе «НОВЫЕ ПРОБЛЕМЫ и МЕРЫ ПО НИМ» (NEW ISSUES and ISSUE MANAGEMENT) перечисляются выявленные ранее риски, которые за истекшую неделю стали проблемами, и новые проблемы, возникшие в течение этой недели: название проблемы, последствия, области воздействия, воздействие на будущие этапы проекта и предложенные действия для «красных проблем».

В разделе «НОВЫЕ РИСКИ и УПРАВЛЕНИЕ РИСКАМИ» (NEW RISKS and RISK MANAGEMENT) указывается название нового риска, выявленного в течение истекшей недели, ожидаемое время наступления этого риска, области его воздействия, триггер и действия в случае срабатывания триггера для рисков, имеющих серьезность «высокая».

В разделе «СВОДКА О ПРОДВИЖЕНИИ В ПРОЕКТЕ» (SUMMARY OF PROGRESS) кратко перечисляются достижения автора в проекте за истекшую неделю.

В следующей таблице «СОСТОЯНИЕ ГЛАВНЫХ ЭТАПОВ» (KEY MILESTONE STATUS) перечисляются основные этапы проекта, по аналогии с «жестким реальным временем», называемые «жесткими», т.е., срок которых не может быть изменен, и к которым в той или иной степени имеет отношение автор отчета.

В позиции «СОСТОЯНИЕ ГРАФИКА РАБОТ» (SCHEDULE STATUS) указывается максимальное отставание от графика из числа текущих заданий и работ по проекту, за которые отвечает автор; если же все работы выполнены в срок или с опережением графика, то указывается минимальное из всех опережение. Данные указываются в календарных днях или неделях со знаком «+» для опережения или «–» для отставания. Если работы идут строго по графику, то обычно пишут «ОК». При наличии отставания, в следующем разделе «ПОПРАВОЧНЫЕ ДЕЙСТВИЯ ПО СНИЖЕНИЮ ОТСТАВАНИЯ» (CORRECTIVE ACTIONS TAKEN FOR SLIPPAGE) перечисляются меры, которые автор принимает для снижения или преодоления этого отставания (включая пересмотр графика работ).

Раздел «ОБЕСПЕЧЕННОСТЬ КАДРАМИ» (STAFFING) присутствует в отчетах руководителя проекта или какой-либо группы сотрудников, в нем указывается количество сотрудников по плану (Estimated) и по факту (Actual), которые планировались к работам по проекту и фактически участвовали в них в течение прошедшей недели.

    1. Примерная форма презентации на ежемесячном операционном обзоре

На Рис. 63 приведен пример ежемесячного одностраничного отчета о ходе проекта АСС, рассчитанного на 12 месяцев, по состоянию на 21.05.2001 г.

Состояние на 21.05.01

График этапов

Повторн.использование

Проект

Руководитель

Отв.исп.

Заказчик

Продукт

АСС

А.Н.Домарацкий

А.Н.Домарацкий

ЗАО «ИДУ»

Система, описание

Этапы

План

Факт

Ключ.раб.

План

Факт

Режимы защиты инф.

Привязка АСС к индивид. календарям

2-я редакция книги

Перенос БД

Модель оценок ПИ

Реализация модели

25.01.01

26.04.01

30.08.01

06.11.01

30.11.01

28.12.01

25.01.01

26.04.01

План

Требования

Проект

Код

Тесты

0,1

0,1

0

0,2

0,4

0,1

0,1

Аннотация

Автоматизированная систе-ма управления разработкой программных изделий (ПИ) АСС предназначена для ре-шения задач оценки харак-теристик программного проекта, планирования и отслеживания его хода. Система включает АРМ рук.предриятия, АРМ руко-водителя проекта и АРМ разработчика. Реализуется в среде MS Office на языке Visual Basic for Applications.

Недель отставания/опережения

«Бычий глаз»

Штат (человек)

Стоимость (в тыс.долларов)

Состояние

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

Обеспечена возможность настройки АСС на работы в сетевом или автономном режиме.

Изменена генерация месячных отчетов (вклю-чена страница выбора этапов).

Рис. 63. Пример одностраничного ежемесячного отчета о ходе проекта

Отчет генерируется автоматически средствами MS Excel по данным из БД проекта на запрошенную текущую дату. Из этого отчета сразу видно, что проект пока идет по плану, однако уже образовалось превышение запланированного бюджета, что требует анализа и принятия мер по исправлению ситуации. Очевидной причиной является превышение запланированного штата (диаграмма «Штат») в 4-м месяце (апреле) на 1 человека. На диаграмме «Бычий глаз» видны периодические отставания до 1 недели, однако два плановых этапа («Режимы защиты информации» и «Привязка АСС к индивидуальным календарям») завершены в срок, по-видимому, за счет этого превышения штата.

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

Рис. 64. Пример регулярного метрического отчета о ходе проекта

Диаграммы строятся автоматически по данным из ежедневных сводных отчетов участников проекта (Табл. 12). Так, видим, что размер кода уже почти достиг запланированной величины, тогда как объем документации еще значительно меньше плана. В то же время число разность между оценкой числа дефектов (90) и числом найденных дефектов (28), будучи приведенной к размеру кода (130 KAELOC), дает оценку числа невыявленных дефектов 0,47 дефекта/KAELOC, что соответствуют качеству чуть выше 4-сигма. При этом 4 дефекта из этих 28 еще открыты.

Источник: https://studfile.net/preview/16431019/