Стандарты, регламентирующие ЖЦ ПО

⇐ ПредыдущаяСтр 2 из 6Следующая ⇒

Международные организации, такие как

• IEEE — читается «ай-трипл-и», Institute of Electrical and Electronic Engineers, Институт инженеров по электротехнике и электронике;

• ISO — International Standards Organization, Международная организация по стандартизации;

• EIA — Electronic Industry Association, Ассоциация электронной промышленности;

• IEC — International Electrotechnical Commission, Международная комиссия по электротехнике.

• ANSI — American National Standards Institute, Американский национальный институт стандартов;

• SEI — Software Engineering Institute, Институт программной инженерии;

• ECMA — European Computer Manufactures Association, Европейская ассоциация производителей компьютерного оборудования.

Стандарт ISO/IEC 12207 (Information Technology - Software Life Cycle Processes) и его практическое применение.

ISO/IEC 12207 Standard for Information Technology — Software Life Cycle Processes(есть российский аналог ГОСТ Р-1999) - Определяет общую структуру жизненного цикла ПО в виде 3-х ступенчатой модели, состоящей из процессов, видов деятельности и задач.

Самыми крупными элементами являются процессы жизненного цикла ПО:

Основные процессы (Приобретение ПО; Передача ПО в использование; Разработка ПО; Эксплуатация ПО; Поддержка ПО),

Поддерживающие процессы (Документирование; Управление конфигурациями; Обеспечение качества; Совместные экспертизы),

Организационные процессы (Управление проектом; Управление инфраструктурой; Усовершенствование процессов; Управление персоналом),

Адаптация (Адаптация описываемых стандартом процессов под нужды конкретного проекта).

1. 11 Процессы разработки ПО.

Модели ЖЦ ПО: Каскадная, итеративная, спиральная, инкрементальная

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

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

Итеративна: Процессы, в которых водопадная схема применяется многократно. Разновидности итеративных процессов – спиральные и инкрементальные процессы.

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

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

12 Процессы разработки ПО.

Впервые предложен в 1999 г.

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

Начальные итерации – предварительные (подготовительные) взаимодействия с группой заинтересованных лиц.

Итерации проектирования – задают ключевую техническую цель в выборе и утверждении (принятии) архитектуры.

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

Итерации перехода – подготовка приложения к выпуску (отправке заказчику).

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

Унифицированный процесс разработки RUP.

Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.

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

Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта.

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

Экстремальное программирование (Extreme Programming, XP)

Экстремальное программирование (Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения

12 основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:

Короткий цикл обратной связи: (Разработка через тестирование, Игра в планирование, Заказчик всегда рядом, Парное программирование

Непрерывный, а не пакетный процесс: Непрерывная интеграция, Рефакторинг, Частые небольшие релизы

Понимание, разделяемое всеми: Простота, Метафора системы, Коллективное владение кодом или выбранными шаблонами проектирования, Стандарт кодирования

Социальная защищенность программиста: 40-часовая рабочая неделя

Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код. «Заказчик» в XP — это не тот, кто оплачивает счета, а тот, кто на самом деле использует систему.

Стандарты документации

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

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

SQAP -План контроля качества программного обеспечения

SCMP - План управления программным проектом

SRS -Спецификация требований к программному обеспечению

SDD -Проектная документация программного обеспечения

STD -Документация по тестированию программного обеспечения

⇐ Предыдущая 123 4 5 6 Следующая ⇒

Последнее изменение этой страницы: 2018-05-27; просмотров: 197.

stydopedya.ru не претендует на авторское право материалов, которые вылажены, но предоставляет бесплатный доступ к ним. В случае нарушения авторского права или персональных данных напишите сюда...