Добавлен: 25.10.2018
Просмотров: 6985
Скачиваний: 27
по приемке ПО.
Аттестация, так же как и верификация, может осуществляться с различными
степенями независимости. Если процесс аттестации выполняется организацией, не
зависящей от поставщика, разработчика, оператора или службы сопровождения, то
он называется процессом независимой аттестации.
Процесс совместной оценки предназначен для оценки состояния работ по
проекту и ПО. Он сосредоточен в основном на контроле планирования и
управления ресурсами, персоналом, аппаратурой и инструментальными средствами
проекта.
Оценка применяется как на уровне управления проектом, так и на уровне
технической реализации проекта и проводится в течение всего срока договора.
Данный процесс может выполняться двумя любыми сторонами, участвующими в
договоре, при этом одна сторона проверяет другую.
Процесс совместной оценки включает действия:
подготовительную работу;
оценку управления проектом;
техническую оценку.
Процесс аудита представляет собой определение соответствия требованиям,
планам и условиям договора. Аудит может выполняться двумя любыми сторонами,
участвующими в договоре, когда одна сторона проверяет другую.
Аудит – это ревизия (проверка), проводимая компетентным органом (лицом) в
целях обеспечения независимой оценки степени соответствия ПО или процессов
установленным требованиям. Аудит служит для установления соответствия
реальных работ и отчетов требованиям, планам и контракту. Аудиторы не должны
иметь прямой зависимости от разработчиков ПО. Они определяют состояние работ,
использование ресурсов, соответствие документации требованиям и стандартам,
корректность тестирования.
Процесс разрешения проблем предусматривает анализ и решение проблем
(включая обнаруженные несоответствия) независимо от их происхождения или
источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения
или других процессов. Каждая обнаруженная проблема должна быть
идентифицирована, описана, проанализирована и разрешена.
ОРГАНИЗАЦИОННЫЕ ПРОЦЕССЫ ЖЦ ПО
Процесс управления состоит из действий и задач, которые могут
выполняться любой стороной, управляющей своими ресурсами. Данная сторона
(менеджер) отвечает за управление выпуском продукта, управление проектом и
управление задачами соответствующих процессов, таких, как приобретение,
поставка, разработка, эксплуатация, сопровождение и т.д.
Процесс управления включает следующие действия:
инициирование о определение области управления. Менеджер должен
убедиться, что необходимые для управления ресурсы (персонал,
оборудование и технология) имеются в его распоряжении в достаточном
количестве;
планирование подразумевает выполнение, как минимум, следующих
задач:
составление графиков выполнения работ;
оценку затрат;
выделение требуемых ресурсов;
распределение ответственности;
оценку рисков, связанных с конкретными задачами;
создание инфраструктуры управления.
Процесс создания инфраструктуры охватывает выбор и поддержку
(сопровождение технологии), стандартов и инструментальных средств, выбор и
установку аппаратных и программных средств, используемых для разработки,
эксплуатации или сопровождения ПО. Инфраструктура должна модифицироваться
и сопровождаться в соответствии с изменениями требований к соответствующим
процессам. Инфраструктура, в свою очередь, является одним из объектов
управления конфигурацией.
Процесс усовершенствования предусматривает оценку, измерение, контроль
и усовершенствование процессов ЖЦ ПО.
Процесс обучения охватывает первоначальное обучение и последующее
постоянное повышение квалификации персонала.
СВЯЗЬ МЕЖДУ ПРОЦЕССАМИ ЖЦ ПО
Процессы ЖЦ ПО, регламентированные стандартом ISO/IEC 12207, могут
использоваться различными организациями в конкретных проектах самым
различным образом. Тем не менее, стандарт предлагает некоторый базовый набор
взаимосвязей между процессами с различных точек зрения (рис.1). Такими
аспектами являются:
договорный аспект;
аспект управления;
аспект эксплуатации;
инженерный аспект;
аспект поддержки.
В договорном аспекте заказчик и поставщик вступают в договорные
отношения и реализуют соответственно процессы приобретения и поставки. В
аспекте управления заказчик, поставщик, разработчик, оператор, служба
сопровождения и другие участвующие в ЖЦ ПО стороны управляют выполнением
своих процессов. В аспекте эксплуатации оператор, эксплуатирующий систему,
предоставляет необходимые услуги пользователям. В инженерном аспекте
разработчик или служба сопровождения решают соответствующие технические
задачи, разрабатывая или модифицируя программные продукты. В аспекте
поддержки службы, реализующие вспомогательные процессы, предоставляют
необходимые услуги всем остальным участникам работ.
Взаимосвязи между процессами, описанные в стандарте, носят статистический
характер. Более важные динамические связи между процессами и реализующими
их сторонами устанавливаются в реальных проектах.
Тема 4. МОДЕЛИ И СТАДИИ ЖЦ ПО
Понятие модели ЖЦ ПО (каскадная, спиральная). Стадии: формирование
требований к ПО; проектирование; реализация; тестирование; ввод в действие;
эксплуатация и сопровождение; снятие с эксплуатации. Подход RAD. Модели
качества процессов проектирования.
Под
моделью
ЖЦ
ПО
понимается
структура,
определяющая
последовательность выполнения и взаимосвязи процессов, действий, задач на
протяжении ЖЦ. Модель ЖЦ зависит от специфики, масштаба и сложности
проекта и специфики условий, в которых система создается и функционирует.
Международный стандарт ISO/IEC 12207: 1995 не предлагает конкретную
модель ЖЦ и методы разработки ПО. Его положения являются общими для любых
моделей ЖЦ, методов и технологий разработки ПО. Стандарт описывает структуру
процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать и выполнить
действия и задачи, включенные в эти процессы.
Модель ЖЦ любого конкретного ПО ЭИС определяет характер процесса его
создания, который представляет собой совокупность упорядоченных во времени,
взаимосвязанных и объединенных в стадии работ, выполнение которых
необходимо и достаточно для создания ПО, соответствующего заданным
требованиям.
Под стадией создания ПО понимается часть процесса создания ПО,
ограниченная некоторыми временными рамками, и заканчивающаяся выпуском
какого-то конкретного продукта (моделей ПО, программных компонентов,
документации), определяемого заданными для этой стадии требованиями. Стадии
создания ПО выделяются по соображениям рационального планирования и
организации работ, заканчивающихся заданными результатами. В состав ЖЦ ПО
обычно включают следующие стации:
1. Формирование требований к ПО.
2. Проектирование.
3. Реализация.
4. Тестирование.
5. Ввод в действие.
6. Эксплуатация и сопровождение.
7. Снятие с эксплуатации.
Формирование требований к ПО является одной из важнейших, поскольку
определяет успех всего проекта. Данная стадия включает этапы:
Планирование работ, предваряющее работы над проектом. Основными
задачами являются:
определение целей разработки;
предварительная экономическая оценка проекта;
построение плана – графика выполнения работ;
создание и обучение совместной рабочей группы.
Проведение обследования деятельности автоматизируемого объекта
(организации), в рамках которого осуществляются:
предварительное выявление требований к будущей системе;
определение структуры организации;
определение перечня целевых функций организации;
анализ распределения функций по подразделениям и сотрудникам;
выявление функциональных взаимодействий между подразделениями,
информационных потоков внутри подразделений и между ними, внешних по
отношению к организации объектов и внешних информационных
взаимодействий;
анализ
существующих
средств
автоматизации
деятельности
организации.
Построение моделей деятельности организаций, предусматривающее
обработку материалов обследования и построение двух видов моделей:
модели “AS-IS” («как есть»), отражающей существующее на момент
обследования положение дел в организации и позволяющее понять, каким
образом функционирует данная организация, а также выявить узкие места и
сформулировать предложения по улучшению ситуации;
модели “TO-BE” («как должно быть»), отражающей представление
о новых технологиях работы организации.
Каждая из моделей включает в себя полную функциональную и
информационную модель деятельности организации, а также, в случае
необходимости, модель, описывающую динамику поведения организации.
Переход от модели “AS-IS” к модели “TO-BE” может выполняться двумя
способами:
совершенствованием существующих технологий на основе оценки их
эффективности;
радикальным изменением технологий и перепроектированием бизнес-
процессов (реинжиниринг бизнес-процессов).
Построенные модели имеют самостоятельное практическое значение.
Например, модель “AS-IS” позволяет выявить узкие места в существующих
технологиях и предлагать рекомендации по решению проблем независимо от того,
предполагается на данном этапе дальнейшая разработка ЭИС или нет. Кроме того,
модель облегчает обучение сотрудников конкретным направлениям деятельности
организации за счет использования наглядных диаграмм (известно, что «одна
картинка стоит тысячи слов»).
Стадия проектирования включает этапы:
Разработка системного проекта. На этом этапе дается ответ на вопрос: «Что
должна делать будущая система?», а именно: определяются архитектура системы,
ее функции, внешние условия функционирования, интерфейсы и распределение
функций между пользователями и системой, требования к программным и
информационным компонентам, состав исполнителей и сроки разработки. Основу
системного проекта составляют модели проектируемой ЭИС, которые строятся на
основе модели “TO-BE” . Документальным результатом является техническое
задание.
Разработка технического проекта. На этом этапе на основе системного
проекта осуществляется собственно проектирование системы, включающее
проектирование архитектуры системы и детальное проектирование. Таким образом,
дается ответ на вопрос: «Как построить систему, чтобы она удовлетворяла
предъявленным к ней требованиям?». Модели проектируемой ЭИС при этом
уточняются и детализируются до необходимого уровня.
К настоящему времени наибольшее распространение получили следующие
две модели ЖЦ ПО: каскадная (1970-1985) и спиральная (1986-1990).
Принципиальной особенностью каскадного подхода (рис.1) является: переход
на следующую стадию осуществляется только после того, как будет
полностью завершена работа на текущей стадии, и возвратов на пройденные
стадии не предусматривается. Каждая стадия заканчивается получением
некоторых результатов, которые служат в качестве исходных данных для
следующей стадии.
Рис.1. Каскадная модель
Каждая стадия завершается выпуском комплекта документации, достаточной
для того, чтобы разработка могла быть продолжена другой командой
разработчиков. Критерием качества разработки при таком подходе является
точность выполнения спецификаций технического задания.
Преимущества применения каскадного способа:
на каждой стадии формируется законченный набор проектной
документации, отвечающий требованиям полноты и согласованности;
Формирование
требований
Проектирова-
ние
Реализация
Тестирование
Ввод в действие
Эксплуатация и
сопровождение