zabika.ru 1


STD 02

ВНУТРЕННИЕ СТАНДАРТЫ

Методология разработки.

Версия 0.0

От 29.11.11
ТАБЛИЦА ИЗМЕНЕНИЙ И СОГЛАСОВАНИЙ

* Д – добавлено, И – изменено, У - удалено

Номер версии

Дата

Объект изменения

Д*

И

У


Название или краткое описание изменения (автор изменений)

Дата запроса на изменение (автор запроса)

0.0

29.11.2011

все

Д

Первичная разработка документа (Драчёв Д.В.)





Оглавление


1Введение 6

1.1Цель 6

1.2Границы применения 6

1.3Ссылки 6

2. Наша методолгоия 7


1Введение

1.1Цель


Настоящий документ описывает процесс разработки и реализации проекта.

1.2Границы применения


Настоящий документ обязателен к применению всеми сотрудниками предприятия.

1.3Ссылки


1. STD_01_Стандарты_на_документацию

2. Наша методолгоия


2.1 Суть итерационного подхода

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


Итеративный подход (iteration — повторение) практикует выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка (plan-do-check-act cycle).

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

Рис. 1

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

Итеративная модель разработки:

Рис. 2

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

2.2 Проблемы при разработке ПО

Рассмотрим наиболее часто встречающиеся симптомы и причины проблем, приводящих к срыву выполнения проекта (см. табл. 1).

Перечислим некоторые причины проблем:


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


  • Субъективное определение статуса проекта известно, как правило "90% сделано, и еще 90% осталось". Другими словами, разработчики полагают, что сделано 90% работы, но ее завершение требует такого же количества ресурсов и времени для достижения 100% готовности.

2.3 Плюсы итерационного подхода

Преимущества итеративного процесса разработки:

  • снижение воздействия серьезных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;

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

  • акцент усилий на наиболее важные и критичные направления проекта;

  • непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;

  • раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;

  • более равномерная загрузка участников проекта;

  • эффективное использование накопленного опыта;

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

  • затраты распределяются по всему проекту, а не группируются в его конце.

Пример реализации итеративного подхода – методология RUP.

2.4 Основные этапы

Взяв за основу методологию Rational Unified Process, мы внесли в нее изменения, связанные с особенностями нашего проекта.

Выделяются следующие этапы:

  1. Постановка задачи (концепция) и её анализ.

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

  1. Формализация задачи.


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

  1. Реализация.

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

  1. Отладка.

На данном этапе происходит тестирование, исправление накопившихся ошибок, валидация, верификация, оценка и доработка интерфейсов.

На каждой итерации последовательно проходятся все эти этапы.

3. Лучшие практики

Только устранив источники проблем, можно достичь стабильного улучшения ситуации в эффективности разработки ПО.

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

Рис. 2

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

3.1 Практика № 1. Управление требованиями

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

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


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

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

3.2 Практика № 2. Использование компонентной архитектуры

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

Согласно авторам Software Architecture in Practice: "архитектура ПО - это такая составляющая результатов разработки, которая дает наивысшую отдачу от вложений".

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


3.3 Практика № 3. Визуальное моделирование

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

Использование стандартного языка моделирования (UML) дает возможность всем членам команды использовать в процессе обмена информацией сложные и, тем не менее, достаточно точные и краткие элементы визуального моделирования. В методологии Rational UML используется для специфицирования, визуализации, конструирования и документирования всех артефактов процесса разработки ПО. (Здесь артефакт - какой либо результат действия: документ, модель, исходные коды).

Совместно с итерационным подходом визуальное моделирование позволяет эффективно отслеживать и распространять внутри коллектива разработчиков "межитерационные" изменения в проектируемом приложении. Многие коллективы пытались осуществить подобное и ранее, но объемы работы по отображению в моделях неизбежных изменений, в архитектуре и дизайне (вносимых на этапах реализации и тестирования), оказывались слишком велики. Только использование инструмента, осуществляющего прямое и обратное преобразование модель<->код, позволяет снизить объем трудозатрат при этих операциях.

Использование диаграмм прецедентов (use-cases) позволяет в наглядной форме отобразить требования к поведению системы в терминах актеров и целей. В процессе моделирования могут быть легко выявлены такие недостатки архитектуры системы, как отсутствие модульности и гибкости.

3.4 Практика № 4. Контроль качества

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


Во многих организациях тестирование отнимает 30- 50% ресурсов на разработку. Тем не менее, количество ошибок в ПО, выявляемых заказчиком, свидетельствует о том, что ПО недостаточно тестируется до его поставки.

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

Данные, полученные в результате автоматизации процесса тестирования у реального заказчика, следующие: до автоматизации выполнялось 13000 тестов с помощью шести человек за две недели, после автоматизации были выполнены те же тесты за 6 часов с помощью одного человека.

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

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

3.5 Практика № 5. Управление изменениями

Одним из ключевых и сложных понятий в области разработки ПО является парадигма "Управления изменениями". Основные проблемы:

  • одновременное изменение (когда два или более процессов изменяют один тот же артефакт - последний, вносящий изменение, разрушает изменения другого);


  • ограниченное уведомление (недостаточная гибкость уведомления о произошедших изменениях);

  • множество версий (при разработке достаточно часто существует множество версий одного и того же артефакта с разной степенью готовности).

Можно выделить следующие основные компоненты управления изменениями.

Управление запросами на изменение (Change Request Management) соответствует инфраструктуре, необходимой для контроля над влиянием на стоимость и сроки от запрошенных изменений для существующего продукта.

Управление конфигурацией (Configuration Management) представляет собой деятельность по определению конфигураций, построению, маркировке и хранению версий артефактов.

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

3.6 Выводы

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