STD_02_Методология_разработкиx

STD 02
ВНУТРЕННИЕ СТАНДАРТЫ
Методология разработки.
Версия 0.0
От 29.11.11
ТАБЛИЦА ИЗМЕНЕНИЙ И СОГЛАСОВАНИЙ
* Д – добавлено, И – изменено, У - удалено
Номер Дата
версии
0.0
Объект
изменения
29.11.2011 все
Д* Название
или
краткое Дата запроса на
И описание изменения (автор изменение
У изменений)
(автор запроса)
Первичная
разработка
Д
документа (Драчёв Д.В.)
2
Оглавление
1
Введение............................................................................................................................................... 4
1.1
Цель .............................................................................................................................................. 4
1.2
Границы применения .................................................................................................................. 4
1.3
Ссылки .......................................................................................................................................... 4
2. Наша методолгоия................................................................................................................................... 5
2.1 Суть итерационного подхода ........................................................................................................... 5
2.2 Основные этапы................................................................................................................................. 6
2.3 Общие сведения ................................................................................................................................ 6
3
1
1.1
ВВЕДЕНИЕ
Цель
Настоящий документ описывает процесс разработки и реализации проекта.
1.2
Границы применения
Настоящий документ обязателен к применению всеми сотрудниками предприятия.
1.3
Ссылки
1. STD_01_Стандарты_на_документацию
2. STD_03_Формальные_инспекции
3. STD_04_Стандарт_на_производство
4
2. НАША МЕТОДОЛГОИЯ
2.1 Суть итерационного подхода
Итеративная разработка предполагает разработку маленького
накручивается остальная функциональность.
ядра,
на
которое
Итеративный подход (iteration — повторение) практикует выполнение работ параллельно
с непрерывным анализом полученных результатов и корректировкой предыдущих этапов
работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл:
Планирование — Реализация — Проверка — Оценка (plan-do-check-act cycle).
Суть итеративной практики может быть лучше всего пояснена визуально:
Рис. 1
Как видно, в результате продукт проходит как бы несколько жизненных циклов
разработки (обработки требований, разработки, кодирования и тестирования) с
применением модели "Водопада". Синей линией показана величина риска провала
проекта. Разбиение на подсистемы давно использовалось в процессе разработки для
снижения сложности отдельно разрабатываемого модуля. Однако в данном случае суть
состоит в том, чтобы не только разбить задач у структурно на модули, но и сам процесс
проектирования во времени.
Итеративная модель разработки:
Рис. 2
5
В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда
должна достичь запланированных на данную итерацию целей, создать или доработать
проектные артефакты и получить промежуточную, но функциональную версию конечного
продукта.
2.2 Основные этапы
Взяв за основу методологию Rational Unified Process, мы внесли в нее изменения,
связанные с особенностями нашего проекта.
Выделяются следующие этапы:
1) Постановка задачи (концепция) и её анализ.
На данном этапе происходит анализ предметной области, формулировка общей
задачи, общая оценка ресурсов и затрат. Формируются видение и границы проекта.
Определяются основные требования, ограничения и ключевая функциональность
продукта. Создается базовая версия модели прецедентов.
2) Формализация задачи.
На данном этапе происходит доработка задачи, доработка анализа, составление
спецификаций, составление строгого плана работ, составление требований,
производится анализ предметной области и построение исполняемой архитектуры.
Документирование требований включает в себя детальное описание для большинства
прецедентов.
3) Реализация.
Во время этого этапа происходит реализация большей части функциональности
продукта. На данном этапе происходит реализация кода, начальное тестирование,
исправление критических ошибок, конечная оценка функционала.
4) Отладка.
На данном этапе происходит тестирование, исправление накопившихся ошибок,
валидация, верификация, оценка и доработка интерфейсов.
На каждой итерации последовательно проходятся все эти этапы.
2.3 Общие сведения
Задание имеют право выдавать:
1. Менеджер проекта имеет право давать задание любому члену группы на любом
этапе.
2. Главы групп имеют право выдавать задание членам своих групп на любом этапе.
3. Во время первого этапа любой член группы аналитиков может выдать задание
любому члену другой группы.
6
4. Во время второго этапа глава группы документаторов может выдать задание
любому члену другой группы.
5. Во время третьего и четвертого этапа глава группы разработчиков может выдать
задание любому члену другой группы.
Задание может быть не связано с направленностью группы, в которой работает его
исполнитель. О выданном задании обязательно должен быть извещен менеджер, глава
группы исполнителя задания.
При постановке задания обязательно указание срока выполнения, степени важности.
Задание выдается в письменной форме. Работник, получивший задание должен
подтвердить его получение в письменной форме.
Если работник не согласен с целесообразностью выданного задания, он может его
оспорить. Подобные спорные вопросы решает менеджер проекта. Менеджер может
отменить поставленное задание или подтвердить его.
Система оценивания заданий: за выполнение задания можно получить оценку в баллах от
1 до 4, учитывается качество и полнота выполнения задания. Если исполнитель не
приступил к выполнению задания или не предъявил никаких результатов к сроку
выполнения задания, задание оценивается в 0 балов. Оценку за выполнение ставит
выдавший задание работник или менеджер. Если исполнитель не согласен с оценкой, то
он может обратиться к менеджеру проекта. Менеджер может изменить оценку за
выполнение того или иного задания. Оценка заносится в «План работ», сумма оценок за
семестр определяет уровень успешности ученика.
Оценку за задание так же имеет право выставить формальная инспекция, которая
проводится в соответствии со стандартом «STD_03_Формальные_инспекции».
Формальная инспекция может быть проведена в связи с инициативой линейного
руководства, по указанию менеджера.
К сроку выполнения задания работник обязан представить отчет и предъявить
выполненную работу для проверки. Если работа выполнена не полностью в силу
уважительной причины (болезнь), то работнику может быть предоставлено
дополнительное время для ее выполнения. Данный вопрос требует согласования с
менеджером проекта и линейным руководителем.
Задание может быть передано для выполнения другому работнику, в случае если
подтверждение получения задания отсутствует в течение трех дней после его выдачи.
Считается, что работник не приступил к выполнению данного задания и в «План работ»
заносится оценка 0. Следующее задание выдается этому работнику только после того, как
истечет срок выполнения задания, к работе над которым, он не приступил.
Обязанности групп:
В обязанности группы аналитиков входит общение с заказчиком, написание концепции
проекта, совместная работа с группой документалистов над пользовательскими
7
требованиями, спецификацией программных требований, спецификацией проектных
требований.
В обязанности группы документалистов помимо выше упомянутого, входит составление
внутренних стандартов предприятия, к данной работе могут привлекаться главы групп для
консультаций.
В обязанности группы разработчиков входит написание кода, тестирование кода.
В обязанности менеджера входит контроль выполнения работ, постановка общих заданий
группам, разрешение спорных ситуаций.
8