Стандарты, регламентирующие создание ПО

Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО является Международный стандарт ISO/IEC 12207:95. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

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

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

В соответствие с этим стандартом все процессы ЖЦ ПО разделены на три группы:

- Основные процессы:

1. Приобретение.

2. Поставка.

3. Разработка.

4. Эксплуатация.

5. Сопровождение.

- Вспомогательные процессы:

1. Документирование.

2. Управление конфигурацией.

3.Обеспечение качества.

4. Верификация.

5. Аттестация.

6. Совместная оценка.

7. Аудит.

8. Разрешение проблем.

- Организационные процессы:

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

2. Усовершенствование.

3. создание инфраструктуры.

4. Обучение.

Основные процессы и задачи, решаемые в них

Вспомогательные процессы и задачи, решаемые в них

Организационные процессы и выполняемые в них задачи

СТАДИИ ЖЦ ПО

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

В состав ЖЦ ПО обычно включаются следующие стадии:

1) Формирование требований к ПО: иначе эту стадию называют планирование и анализ требований, либо предпроектная стадия. Она является одной из важнейших, поскольку определяет успех всего проекта.

Этапы:

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

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

-построение модели деятельности организации – модель AS-IS и TO-BE.

Результатом данной стадии является технико-экономическое обоснование.

2) Стадия проектирования:

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

- разработка технического проекта – здесь дается ответ на вопрос, как построить систему, чтобы она удовлетворяла предъявленным к ней требованиям. Здесь выполняется проектирование системы, включающее в себя архитектуру системы и детальное проектирование. Результатом данного этапа является технический проект.

3) Стадия реализации:

4) Стадия внедрения:

5) Стадия эксплуатации:

Иногда 2 и 3 стадии объединяют в одну, она называется технорабочее проектирование, либо системный синтез.

На каждой стадии может выполняться несколько процессов (из 1 вопроса) и, наоборот, один и тот же процесс может выполняться на различных стадиях.

МОДЕЛИ ЖЦ ПО

Модель ЖЦ – это структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач процессов на протяжении всего ЖЦ. Модель ЖЦ зависит от специфики, масштаба и сложности проекта, а также специфики условий, в которых система создается и функционирует. Стандарт ISO/IEC 12207:95 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях как реализовать или выполнить эти процессы, поэтому данные процессы являются общими для всех моделей ЖЦ. Модель ЖЦ любого ПО определяет характер процесса его создания.

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

КАСКАДНАЯ МОДЕЛЬ

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

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

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

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

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

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

СПИРАЛЬНАЯ МОДЕЛЬ

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

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

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

Date: 2016-07-25; view: 905; Нарушение авторских прав