Главная Случайная страница


Полезное:

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


Категории:

АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника






Гибкие технологии и экстремальное программирование





 

Гибкие технологии

 

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

Ключевыми постулатами гибкой разработки являются

● Люди и их взаимодействие

● Создание работающего программного обеспечения

● Сотрудничество с заказчиком

● Реакция на изменение.

Ключевые правила поведения сводятся к следующему.

● Уважение мнения каждого участника команды

● Правдивость при любом общении

● Прозрачность всех данных, действий и решений

● Уверенность, что каждый участник поддержит команду

● Приверженность команде и её целям

Принципы гибкой методологии

1) Высшим приоритетом следует считать удовлетворение пожеланий заказчика

2) Не игнорировать изменения требований

3) Частое создание новых работающих версий ПО

4) Заказчики и разработчики должны работать совместно

5) Проекты должны воплощать в жизнь целеустремленные люди

6) Эффективный метод передачи информации – разговор лицом к лицу

7) Работающая программа – основной показатель прогресса в проекте

8) Гибкие процессы способствуют долгосрочной разработке

9) Непрестанное внимание к качественному проектированию

10) Простота

11) Самые лучшие решения выдают самоорганизующиеся команды

12) Команда должна регулярно задумываться над тем, как стать ещё более эффективной

 

Примеры реализации гибких методологий

 
 

 

Одним из прогрессивных направлений в гибких технологиях считается экстремальное программирование – e X treme P rogramming). Его основные особенности перечислены в следующих таблицах.

 
 

 

 
 

Базис XP

 

1)Игра планирования (Planning game)

2)Частая смена версий (Small releases)

3)Метафора (Metaphor)

4)Простое проектирование

5)Тестирование (TDD - Test Driven Development)

6)Реорганизация (Refactoring)

7)Парное программирование

8)Коллективное владение кодом

9)Непрерывная интеграция.

10)40-часовая неделя.

11)Локальный заказчик.

 
 

12)Стандарты кодирования

Рис. 7

 

Scrum

 

Scrum — методология управления разработкой информационных систем для гибкой разработки программного обеспечения. Scrum делает упор на качественный контроль процесса разработки. Кроме управления проектами по разработке ПО Scrum может также использоваться в работе команд поддержки программного обеспечения (software support teams), или как подход управления разработкой и сопровождением программ: Scrum of Scrums. Особенности рассматриваемой методологии иллюстрируют рис. 7 и 8.

 
 

 

Рис.8

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

Резерв проекта — это список требований к функциональности, упорядоченный по степени их важности, подлежащих реализации. Элементы этого списка называются «пожеланиями пользователя» (user story) или элементами резерва (backlog items). Резерв проекта открыт для редактирования для всех участников скрам процесса.

 

 
 

Пример характеристик СКРАМ приведен на рис. 9.

 

Scrum (роли)

 

По методике Scrum в производственном процессе есть определенные роли, разбитые на 2 группы «свиней» и «кур».

Свиньи:

● Скрам-мастер (ScrumMaster)

● Владелец проекта (Product Owner)

● Скрам-команда (Scrum Team).

 

Куры:

● Пользователи (Users)

● Клиенты, Продавцы (Stakeholders)

● Управляющие (Managers)

● Эксперты-консультанты (Consulting Experts).

 

 
 

План работы по методологии Scrum состоит из трех позиций:

1) Нужно сделать;

2) Делается;

3) Сделано.

Пример плана приведен на рис. 10

 

Нужно сделать Делается Сделано

 
 

Рис. 10

 


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

 

Это – важный этап разработки программного обеспечения.

Организации, занимающиеся разработкой требований к документам

● ГОСТ – российские государственные стандарты

● IEEE – Институт инженеров по электротехнике и радиоэлектронике (www.ieee.org)

● ISO – международная организация по стандартизации

● SEI – Институт технологий разработки программного обеспечения

● OMG – консорциум по технологии манипулирования объектами (www.omg.org)

 

 
 

Документация по IEEE предполагает разработку на каждом этапе следующих документов.

 

План управления программным проектом Software Project Management Plan

 

План включает в себя следующие процессы.

1)Постановка задачи;

2)Организация проекта;

3)Управляющий процесс;

4)Технический процесс;

5)Распределение работ;

6)Дополнение.

 

Спецификация требований к программному обеспечению Software Requirements Specifications содержит следующие разделы.

1)Введение;

2)Общее описание;

3)Детальные требования;

4)Дополнительная информация.

 

Отечественный подход

 

Регламентирует следующие исходные данные и документацию на жизненный цикл (ЖЦ) программных систем (ПС).

● Стандарты и нормативные документы на ЖЦ ПС

● Стратегия и план документирования процессов и объектов ЖЦ ПС

● Ресурсы для документирования программ и данных

● Инструментальные средства и процессы для автоматизации документирования

 

Технологическая документация включает в себя.

● Документацию этапов и результатов проектирования ПС

● Документацию тестирования и испытаний ПС

● Документацию конфигурационного управления и совершенствования версий ПС

● Документацию управления и оценивания качества ПС

● Документацию гарантирования сохранности продуктов и документов ПС

● Комплект руководств и инструкций поддержки технологии ЖЦ ПС.

 

Эксплуатационная документация

● Документация администрирования при применении ПС

● Документация операторов-пользователей при применении ПС

● Документация обучения специалистов применению ПС.

 

 
 

Основным является ГОСТ 19 / ЕСПД. Его структура приведена в таблице.

 

ГОСТ 19.001-77 ЕСПД. Общие положения.

ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов.

ГОСТ 19.102-77 ЕСПД. Стадии разработки.

ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов.

ГОСТ 19.104-78 ЕСПД. Основные надписи.

ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам.

ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом.

ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.

ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению.

ГОСТ 19.301-79 ЕСПД. Порядок и методика испытаний.

ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению.

ГОСТ 19.402-78 ЕСПД. Описание программы.

ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию

ГОСТ 19 / ЕСПД и оформлению.

ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению.

ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению.

ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению.

ГОСТ 19.504-79 ЕСПД. Руководство программиста.

ГОСТ 19.505-79 ЕСПД. Руководство оператора.

ГОСТ 19.506-79 ЕСПД. Описание языка.

ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.

ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом.

ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.

ГОСТ 19.781-90. Обеспечение систем обработки информации программное.

 

Структура технического задания (ТЗ)

 

● введение;

● основания для разработки;

● назначение разработки;

● требования к программе или программному изделию;

● требования к программной документации;

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

● стадии и этапы разработки;

● порядок контроля и приемки;

● в техническое задание допускается включать приложения.

 

ГОСТ 34

 

Наиболее популярными можно считать стандарты:

● ГОСТ 34.601-90 (Стадии создания АС);

● ГОСТ 34.602-89 (ТЗ на создание АС);

● РД 50-34.698-90 (Требования к содержанию документов).

 
 

 
 

ISO/IEC 12207:1995-08-01 предусматривает 5 основных процессов ЖЦ ПО:

● Процесс приобретения;

● Процесс поставки;

● Процесс разработки;

● Процесс функционирования;

● Процесс сопровождения.

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

● решения проблем;

● документирования;

● управления конфигурацией;

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

1.Процесс верификации;

2.Процесс аттестации;

3.Процесс совместной оценки;

4.Процесс аудита.

Четыре организационных процесса:

● Процесс управления;

● Процесс создания инфраструктуры;

● Процесс усовершенствования;

● Процесс обучения.

 

Date: 2016-07-18; view: 491; Нарушение авторских прав; Помощь в написании работы --> СЮДА...



mydocx.ru - 2015-2024 year. (0.005 sec.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав - Пожаловаться на публикацию