Организационные процессы жизненного цикла

1) Управление

2) Создание инфраструктуры

3) Усовершенствование

4) Обучение

Ответ прошлых лет (Ден)

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

Функции процесса управления: прогнозирование, планирование...

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

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

Этапы управления:

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

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

Основные процессы ЖЦ по ГОСТ’ам

Заказ – Acqusition

Поставка – Supply

Разработка – Development

Эксплуатация – Operation

Сопровождение – Maintenance

Инфраструктура проекта ???

28. Проектная документация [J]

№	Билет №	Формулировка ответа	Преподаватель	Кто делает ответ	Состояние
	7.3., 20.2.	Проектная документация. Основные документы жизненного цикла ПО по ГОСТ Р 51904-2002: документы процесса планирования. Требования к их содержанию.	Маятин Александр Владимирович	Дина Чубарева	Готовый ответ Дины

Готовый ответ Дины

ГОСТ 51904-2002

12.1 – 12.8. – основное. Плюс Разделы 6.3, Таблица А1.

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

Цели:

1. Определить конкретные модели виды работ

2. Определить модели жизненного цикла (ЖЦ) ПО

3. Выбрать среду поддержки ЖЦ

4. Определить стандарты разработки

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

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

Типы планов (док-ты) и разделы, которые они должны в себя включать

· П.сертификации в части ПО

× обзор системы,

× обзор ПО,

× вопросы сертификации,

× ЖЦ ПО (модель),

× документы ЖЦ ПО (которые нужно будет разработать),

× план-график,

× доп.вопросы

· П. разработки ПО

× идентификация стандартов на разработку,

× описание процессов ЖЦ ПО,

× обоснование среды разработки

· П. верификации ПО

× орг.ответственность внутри процесса верификации,

× методы верификации,

× среда верификации - оборудование для тестирования,

× критерии перехода к процессу верификации,

× проверка разбиения на части,

× допустимость использования компилятора,

× руководство по повторной верификации,

× ранее разработанное ПО,

× версионное ПО

· П. квалификационного тестирования ПО

× Идентификация – перечень и используемы версии ПО

× Идентификация – перечень и используемы виды аппаратных средств

× Права собственности и лицензирование

× Задействованные организации

· П. упр-я конфигурацией ПО

× Среда

× Состав работ

× Идентификация конфигурации

× Базовая линия и трассируемость (??!)

× Отчетность о дефектах

× Контроль изменений

× Просмотр изменений

× Отчет о состоянии конфигурации

× Архивирование

× Контроль загрузки ПО

× Конторль среды ЖЦ ПО

× Контроль док-в ЖЦ ПО

× Критерии перехода

× Док-ты упр-я конфигурациями

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

· П. обеспечения качества ПО

× Среда

× Полномочия

× Состав работ (методы, сами работы и их описание)

· П. установки ПО

× Перечень пользовательских мест

× Запланированные сроки

× Методы установки

× Орг.сведения

× Технические средства поддержки

× Орг-ция процесса обучения

· П. передачи ПО

× Краткий обзор док-в и системы

× Описание ресурсов, необходимых для поддержки

× Рекомендуемые мероприятия

× Описание процесса подготовки персонала

× Област изменений передаваемого ПО

× Порядок передачи ПО

29. Проектная документация [J]

№	Билет №	Формулировка ответа	Преподаватель	Кто делает ответ	Состояние
	8.3., 21.2.	Проектная документация. Основные документы жизненного цикла ПО по ГОСТ Р 51904-2002: документы процесса определения требований. Требования к их содержанию.	Маятин Александр Владимирович	Оля Дмитрова	готовый ответ Ани

Готовый ответ Ани

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

Примечание: ЭКПО – элемент конфигурации ПО

30. Проектная документация [J]

№	Билет №	Формулировка ответа	Преподаватель	Кто делает ответ	Состояние
	9.3., 22.2., 39.3.	Проектная документация. Основные документы жизненного цикла ПО по ГОСТ Р 51904-2002: документы процессов проектирования и кодирования. Требования к их содержанию.	Маятин Александр Владимирович	Тоня Аркуша	Ответ Тони

Ответ Тони

Гост Р 51904-2002

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

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

· План сертификации в части ПО;

· Указатель конфигурации ПО;

· Итоговый документ разработки ПО.

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

· Спецификация требований к ПО;

· Описание проекта ПО;

· Исходный код ПО;

· Исполняемый объектный код ПО;

· Указатель конфигурации ПО;

· Итоговый документ разработки ПО.

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

Характеристики документов ЖЦ По являются:

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

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

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

-согласованность, если не существует противоречий внутри информации.

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

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

Дополнительные требования:

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

Проектирование системы

Документ «Описание проекта системы/подсистемы»

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

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

- проект архитектуры системы, содержащий идентификацию компонентов системы, их назначение, статус/тип разработки, аппаратные ресурсы;

- компетенцию совместного функционирования компонентов, описание их динамических связей;

- описание интерфейсов между компонентами;

- анализ трассируемости проекта системы к системным требованиям.

Документ содержит обоснование выбора конкретной системы с учетом требований интерфейса, заданных характеристик ввода/вывода, физической модели системы.

Процесс кодирования

Документ Исходный код По

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

Документ Исполняемый программный код

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

31. Проектная документация [J]

№	Билет №	Формулировка ответа	Преподаватель	Кто делает ответ	Состояние
	10.3., 23.2.	Проектная документация. Основные документы жизненного цикла ПО по ГОСТ Р 51904-2002: документы процесса верификации и документы для поддержки пользователей системы (руководства). Требования к их содержанию.	Маятин Александр Владимирович	Лена Карпова	готовый ответ Лены

Готовый ответ Лены

КУСОК ИЗ ГОСТА СВЕРХУ

- План верификации ПО

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

а) Организация: организационная ответственность внутри процесса верификации ПО и ин­терфейсы с другими процессами жизненного цикла ПО.

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

в) Методы верификации: описание методов верификации, которые будут использованы на каждом этапе процесса верификации ПО:

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

2 методы анализа, включающие в себя методы анализа трассируемости и оценки полноты покрытия;

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

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

д) Критерии перехода: критерии перехода к процессу верификации ПО, определяемому в этом плане.

е) Проверка разбиения: если используют разбиение на части, то описывают метод верифика­ции целостности.

ж) Допустимость использования компилятора: описание соглашений относительно коррект­ности применения компилятора, редактора связей или загрузчика (6.4.2).

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

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

к) Многоверсионное ПО: при использовании многоверсионного ПО необходимо описание работ процесса верификации для него.

- План квалификационного тестирования ПО

План квалификационного тестирования ПО содержит информацию для проведения квалифи­кационного тестирования (испытаний) систем и подсистем ПО, описание тестовой среды, которая будет использована при тестировании, идентифицирует выполняемые тесты и указывает план-гра­фик выполнения тестирования.

Для каждой предполагаемой тестовой установки должны быть указаны:

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

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

- права собственности и лицензирование;

- организации, принимающие участие в квалификационном тестировании, их роли и ответст­венность.

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

Допускается включение перечисленной в настоящем подразделе информации в документ «План верификации ПО>> (см. 12.3), если заказчик не требует разработки отдельного документа, описывающего план квалификационного тестирования.

- Спецификация системы/подсистемы

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

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

Должны быть описаны требования:

- к режимам работы;

- к производительности системы;

- к внешнему интерфейсу системы;

- к внутреннему интерфейсу системы;

- к внутренним данным системы;

- по адаптации;

- по безопасности;

- по обеспечению защиты и секретности;

- к системному окружению (среде);

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

- по ограничениям проекта;

- по обучению персонала.

Должны быть также определены:

- относительная важность и критичность требований;

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