Аналитик и Тестировщик в одном лице – путь к качеству (Максим Цепков, SQA Day...CUSTIS
Выступление Максима Цепкова, нашего главного архитектора дирекции по развитию решений, на конференции Software Quality Assurance Days (2–3 декабря 2011 года, Москва).
Управление изменениями и релизами: один или два процесса?Cleverics
1. Взаимодействие разработки и эксплуатации
2. Управление релизами — кто владелец?
3. Управление релизами в составе управления изменениями?
4. Место политики управления релизами в системе управления
Презентация содержит подробное описание продукта Serena Dimensions RM и Serena Business Manager, которые решают задачи автоматизации процессов управления требованиями, включая управленческую и инженерную составляющие.
Позднее в 2012 году Serena представила свое интегрированное решение на базе этих двух продуктов - Serena Requirements Manager.
Роль аналитика в негибких методологиях разработкиDevDay
В ходе доклада обсудим:
— Какие методологии сейчас используют чаще всего.
— Как типы разработки влияют на решение: взять аналитика в команду или нет.
— В чем суть негибкого процесса. Этапы и поставки аналитических работ.
— Нужен ли аналитик в негибком проекте продуктовой разработки - все за и против.
Ромуальд Здебский, Обеспечение качества через интегрированное управление прое...SQADays_2009_Piter
Ромуальд Здебский, Microsoft, Санкт-Петербург, Россия
Обеспечение качества через интегрированное управление проектами разработки ПО - настоящее и будущее
Это последняя лекция в серии для очень начинающих аналитиков. Она о высоком: о творчестве, о познании, о сложных задачах, которые тоже являются частью работы аналитика. Об этой стороне редко говорят, считая ее трудно формализуемой, необязательной или считают, что это "не для всех". Но останавливаясь только на обязательных, формальных и рутинных частях работы аналитика, мы сами убиваем любовь к собственной профессии, превращая ее в колесо для белки. Так вот: учитесь видеть в своей профессии творчество!
Управление требованиями. Сбор требований. Характеристики хороших требований. Анализ требований. Управление изменениями требованиями. Курс для бизнес-аналитиков. Основы бизнес-анализа для начинающих
Аналитик и Тестировщик в одном лице – путь к качеству (Максим Цепков, SQA Day...CUSTIS
Выступление Максима Цепкова, нашего главного архитектора дирекции по развитию решений, на конференции Software Quality Assurance Days (2–3 декабря 2011 года, Москва).
Управление изменениями и релизами: один или два процесса?Cleverics
1. Взаимодействие разработки и эксплуатации
2. Управление релизами — кто владелец?
3. Управление релизами в составе управления изменениями?
4. Место политики управления релизами в системе управления
Презентация содержит подробное описание продукта Serena Dimensions RM и Serena Business Manager, которые решают задачи автоматизации процессов управления требованиями, включая управленческую и инженерную составляющие.
Позднее в 2012 году Serena представила свое интегрированное решение на базе этих двух продуктов - Serena Requirements Manager.
Роль аналитика в негибких методологиях разработкиDevDay
В ходе доклада обсудим:
— Какие методологии сейчас используют чаще всего.
— Как типы разработки влияют на решение: взять аналитика в команду или нет.
— В чем суть негибкого процесса. Этапы и поставки аналитических работ.
— Нужен ли аналитик в негибком проекте продуктовой разработки - все за и против.
Ромуальд Здебский, Обеспечение качества через интегрированное управление прое...SQADays_2009_Piter
Ромуальд Здебский, Microsoft, Санкт-Петербург, Россия
Обеспечение качества через интегрированное управление проектами разработки ПО - настоящее и будущее
Это последняя лекция в серии для очень начинающих аналитиков. Она о высоком: о творчестве, о познании, о сложных задачах, которые тоже являются частью работы аналитика. Об этой стороне редко говорят, считая ее трудно формализуемой, необязательной или считают, что это "не для всех". Но останавливаясь только на обязательных, формальных и рутинных частях работы аналитика, мы сами убиваем любовь к собственной профессии, превращая ее в колесо для белки. Так вот: учитесь видеть в своей профессии творчество!
Управление требованиями. Сбор требований. Характеристики хороших требований. Анализ требований. Управление изменениями требованиями. Курс для бизнес-аналитиков. Основы бизнес-анализа для начинающих
Семинары и тренинги по делопроизводству, документообороту и архиву предприятияProfi-Cariera
http://www.seminarna.ru/
Семинары по делопроизводству проводят ведущие специалисты ВНИИДАД ведущего центра подготовки специалистов в области документоведения.
ВНИИДАД Всероссийский научно-исследовательский институт документоведения и архивного дела.
ВНИИДАД является единственным в России учреждением, занимающимся вопросами документационного обеспечения управления.
Целевая аудитория
Сотрудники службы ДОУ, офис-менеджеры, делопроизводители, секретари, архивариус
Презентация на конференции Software People 2009. Предлагается простой и практичный метод оценки трудозатрат в проектах разработки ПО, позволяющий количественно учесть риски в сроках работ, оперировать прогнозами в условиях высокой неопределенности, а также дающий инструменты проверки достоверности прогноза при помощи метрик.
Презентация к моему докладу на конференции SWP'11
- Цель управления как выполнение скоординиваронного и целенаправленного командного действия
- Понятие "трения", как основного отличия плана на бумаге от практического действия.
- "Тактика миссии" (Auftragstaktik) как философия управления, необходимая для преодоления "трения".
- 5-paragraph order и процесс планирования корпуса морской пехоты США, как пример системы, реализующий принцип тактики миссии.
- "Трение" в различных типах оргструктур в компаниях разработчиках ПО, и их совместимость с "тактикой миссии"
PMBOK Extension for Software Projects (in Russian)IAMCP MENTORING
The content of this presentation deals with species of software projects' management. The Extension strikes the specific features of software projects, team management, motivation, main project phases.
One of the main features is an attempt to combine waterfall and adaptive project management techniques.
Презентация семинаров по деловой переписке с клиентамиProfi-Cariera
Пройдите курс по деловой переписке и превратите всех клиентов в лояльных Вашей организации. Деловая переписка - это Ваш имидж. Как научиться аргументированно и структурированно писать, грамотно оформлять письма, пользоваться речевыми клише? Все это узнаете на наших курсах. 15 лет помогаем лучшим бизнесам России стать еще эффективнее.
Лицензированный центр "Профи-Карьера" проводит корпоративное обучение по различным тематикам. для сотрудников российских и международных компаний. Курсы повышения квалификации, семинары и тренинги, дистанционное обучение по управлению персоналом, секретариату, делопроизводству, бизнес-процессам, сервису и обслуживанию клиентов, телефонному общению. Звоните: +7 495 150 18 17, info@seminarna.ru, www.seminarna.ru
Управление бизнес-процессами (BPM) для банков на примере автоматизации процесса рассмотрения заявки организаций на предоставление кредита или гарантии на платформе Serena Business Manager
Достоинства и ограничения проектных моделей водопада и гибких подходов: скрам, аджайл (scrum, agile).
Как на основе специфичных характеристик проекта подобрать модели планирования и управления ИТ проектом
Тренинг "Анализ, проектирование и разработка корпоративных информационных сис...ph.d. Dmitry Stepanov
в тренинге рассматриваются типовые этапы внедрения корпоративных информационных систем: жизненный цикл системы, жизненный цикл проекта внедрения системы, методологии внедрения систем, этап подготовки, этап проектирования, этап реализации, этап подготовки к опытно-промышленной эксплуатации / опытной эксплуатации, этап ОПЭ/ОЭ, этап перехода к промышленной эксплуатации, этап ПЭ, отличие этапов, декомпозиция и вариация этапов, внедрение с нуля, тиражирование, пилотный проект, PMBoK, типовые этапы внедрения систем.
Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool /...Ontico
РИТ++ 2017, Web-scale IT Сonference
Зал Владивосток, 6 июня, 17:00
Тезисы:
http://webscaleconf.ru/2017/abstracts/2553.html
Платформа виртуализации данных на основе Tarantool - система, созданная в Mail.Ru Group в прошлом году. Cовместно с АТ Consulting было создано и запущено в production решение для хранения 100 млн. профилей абонентов компании Beeline, выдерживающее значительные нагрузки.
...
Трудно себе представить ПО, созданное для решения реальных задач, которое не меняется в процессе жизненного цикла. Желания ("аппетиты") заказчиков растут во время использования ПО. Меняются бизнес процессы заказчика, адаптируясь к внешним условиям. Меняются сами эти условия в форме законов, стандартов, рыночных условий В ходе реализации требований обнаруживаются ошибки в самих требованиях к ПО. Разработчики - любезные люди и им часто трудно отказать симпатичному «юзеру» и не сделать программу более удобной. Сильно увеличивает поток изменений следование принципам "Клиент всегда прав" и "Чего изволите...".
ЛОВУШКА . Часто неправильно толкуется принцип "изменяемости" требований. Что является поводом отказа от выявления требований до начала программирования ("все равно они будут изменяться"). Принцип "изменяемости" не отменяет принцип "выявления ” требований до начала программирования, отказ от которого лишает разработку целенаправленности. Верным признаком отсутствия ясно сформулированных требований является включение некоторой функциональности в продукт, затем ее исключение, а затем снова включение ("тасование").
Подготовленная в процессе определения требований и утвержденная СТПО представляет базовую версии требований ( baseline ). Все ее изменения считаются незапланированными. Чем слабее базовая версия, тем больше будет расти объем проекта. Люди не любят говорить или слышать слова "Нет!". Поэтому, в ходе разработки легко собрать большой пакет изменений. Их принятие приводит в долговременной перспективе к срыву сроков, снижению качества продукта. Создается ощущение, что проект никогда не будет завершен. При этом, размываются обязательства, возникают споры, стресс у разработчиков и неудовлетворенность того же клиента. Основные методы борьбы с этим - более полное и точное выявление базовых требований и включение предлагаемых изменений в версию продукта для следующего проекта. В работе с изменениями важнейшим качеством разработчиков является умение отказать клиенту. Лучшей формой отказа является фраза "Конечно да, но не сейчас...". В идеале все требования собираются и "замораживаются" до начала разработки (модель разработки типа "водопад"). Но на практике так не бывает, и изменения происходят. Но если в какой-то момент требования не "заморозить", то результата не будет вовсе. Здесь нужно искать золотую середину!
В процессе формирования требований и приступая к разработке необходимо позаботиться об управлении изменениями в предположении, что потребуется: оценка влияния изменения на бизнес и проект, согласование с другими требованиями, взвешенное одобрение, включение изменения в СТПО и доведение изменения до сведения участников проекта Каждое изменение имеет цену. Любое изменение требований влияет как на бизнес, так и на проект. Влияние на бизнес обычно положительное (преимущества, удобства), а влияние на проект - отрицательное (сроки, стоимость). В частном случае она может быть отрицательной если предлагаемое изменения сокращает срок или стоимость разработки. Оценить влияние изменений может только человек (developer sapiens!). Новые изменения могут вступать в противоречие с ранее утвержденными требованиями. В этом случае потребуется разрешать конфликты.
Одобрение изменения должно осуществляться ответственным лицом (лучше всего коллегиальным органом), в обязанности которого входит разрешение конфликтов требований, а также проверка проектной оценки изменения и соотнесение оценки его влияния на бизнес с бизнес целями проекта. СТПО всегда должна представлять актуальное представление о продукте. Ценность не актуальной СТПО быстро снижается и команда начинает работать, как будто вообще нет никакой спецификации («Зря на нее потратились!»). Если вносить изменения сразу в код, описание продукта становиться не точным, а изменяемый код - более уязвимым ("хрупким"). Так, спецификация становиться дезинформацией, процесс тестирования не полным, становится возможным дублирование кода. Итог - снижение эффективности работы команды. ЛОВУШКА . Наивно полагать, что проект будет успешным, если в продукт постоянно включается все больше функциональности, а проект ограничен сроками, кадрами, бюджетом и требованиями к качеству.
Изменения происходят под управлением определенного процесса протекающего в соответствии с принципами, указанными на слайде. Заказчикам процесс контроля за изменениями не нравиться. Однако, правильно организованный процесс контроля является не препятствием, а средством фильтрации и накопления полезной информации и обеспечивает внесение наиболее ценных изменений, откладывая менее ценные "на потом". Процесс контроля позволяет руководителю проекта принимать правильные проектные решения, взвешивая коммерческую (бизнес) ценность продукта и затраты, и делает разработку более управляемой. ЛОВУШКА . Часто заказчик обращается с просьбой об изменении к высшему руководству компании разработчика или непосредственно к программисту, минуя руководителя, отвечающего за проект ("Он, слишком часто говорит: Нет!"). Это прямой путь к потере контроля над проектом.
Полезно включить следующие четыре компонента во все процедуры и описания процесса : входной критерий — условия , которые должны быть удовлетворены до выполнения процесса или процедуры ; различные задачи , задействованные в процессе или процедуре , участник проекта , отвечающий за выполнение каждой задачи , и другие лица , принимающие участие в выполнении задачи ; последовательные действия для подтверждения того , что задачи были выполнены правильно ; выходной критерий — условия , указывающие , когда процесс или процедура считаются успешно завершенными . 1. Введение Во введении описывается назначение процесса и определяются организационные границы , в которых он применяется . Если этот процесс затрагивает только изменения в определенных продуктах , их следует определить здесь . Также укажите , существуют ли какие - то специальные виды изменений , которые не подлежат контролю , например изменения в промежуточных или служебных продуктах , созданных в ходе проекта . В разделе 1.3 определите все термины , необходимые для понимания остальной информации . 2. Роли и ответственности Перечислите членов команды — по ролям , не по именам , которые участвуют в процессе контроля изменений , и опишите их обязанности , в табл . далее приведены некоторые типичные роли ; адаптируйте их в соответствии с конкретной ситуацией . Каждый человек может выполнять несколько ролей . Например , председатель совета по управлению изменениями также может получать подаваемые запросы на изменения . В небольших проектах несколько , а возможно , и все роли выполняются одним человеком . 3. Состояние запроса на изменение Запрос на изменение проходит через определенные стадии на протяжении жизненного цикла , причем на каждой стадии он имеет различные статусы . Вы можете представить эти изменения состояния , используя диаграмму перехода состояний , как показано на рис . 19-2. Обновляйте состояние запроса , только когда удовлетворяются определенные критерии . 4. Входной критерий Основным входным критерием для процесса контроля изменений является действительный запрос на изменение , полученный по утвержденным каналам . Все потенциальные инициаторы запросов должны знать , как подавать запросы на изменение , независимо от того , отправляют они его , заполняя бумажную форму или Web -форму , отправляя сообщение по электронной почте или используя средство контроля изменений . Назначьте каждому запросу на изменение уникальный идентификатор и направьте их всех к единой точке контакта — получателю запроса .
5. Задачи Следующий шаг — это оценка запроса на предмет технической выполнимости , затрат и соответствия бизнес - требованиям проекта и ограничениям ресурсов . Председатель совета по управлению изменениями может назначить сотрудника для оценки влияния изменения , анализа риска , анализа опасности и др . Анализ позволяет убедиться , что вероятные последствия изменения ясны . Тот , кому поручена оценка , и члены совета по управлению изменениями должны также рассмотреть коммерческие и технические последствия отклонения изменения . Затем уполномоченные члены совета по управлению изменениями решают , утвердить или отклонить запрошенное изменение . Совет по управлению изменениями присваивает каждому одобренному изменению уровень приоритета , или назначает дату реализации , или назначает это изменение определенной сборке или номеру версии . Далее совет по управлению изменениями оповещает о решении , обновляя состояние запроса или уведомляя всех членов команды , которые занимаются модификацией . После этого необходимо обновить : документацию требований , описание дизайна и моделей , компоненты пользовательского интерфейса , код , документацию тестирования , экраны справки и руководства для пользователей . Тот , кто вносит изменения , делает это установленным путем . 6. Проверка Изменения требования , как правило , проверяют с помощью экспертной оценки , чтобы убедиться , что измененные требования , варианты использования и модели соответствующим образом отражают все аспекты изменения . Информация о трассируемости поможет вам найти все части системы , которые это изменение затрагивает и которые , как следствие , необходимо проверить . Поручите нескольким членам команды проверить изменения с помощью тестирования или экспертизы . После этих процедур тот , кто занимается проверкой , устанавливает обновленные продукты , сделав их доступными остальным членам команды , и переопределяет базовую версию , в которой учтены изменения . 7. Выходной критерий Все перечисленные далее выходные критерии должны быть удовлетворены , чтобы должным образом завершить процесс управления изменениями : 1 состояние запроса : Rejected (Отклонено ), Closed (Закрыто ) или Canceled (Отменено ); 1 все изменения записаны в соответствующих разделах ; 1 инициатор запроса , председатель совета по управлению изменениями , менеджер проекта и другие значимые участники проекта оповещены о деталях изменения и текущем состоянии запроса на изменение ; I матрица связей требований обновлена . ( В главе 20 о трассируемости требований рассказано более подробно .) 8. Отчет о состоянии управления изменения Определите графики и отчеты , которые вы будет использовать при обобщении содержимого базы данных контроля изменений . Обычно на этих графиках показано количество запросов на изменение в каждой категории состояния как функция времени . Опишите процедуры создания графиков и отчетов . Менеджер проекта использует эти отчеты при контроле состояния проекта . Приложение . Элементы данных , сохраненные для каждого запроса В табл . 19-2 перечислены некоторые элементы данных , которые можно сохранить для каждого запросе на изменение . После определения своего собственного списка , укажите , какие элементы следует сохранять обязательно , а какие нет . Также укажите , устанавливается ли значение для каждого элемента автоматически средством контроля изменений или вручную одним из участников процесса управления изменениями .
Председатель совета , по управлению измене ниями Возглавляет совет по управлению изменениями ; как правило обладает правом принятия окончательного решения , если совет не приходит к согласию ; выбирает тех , кто оценивает и вносит изменения для каждого запроса на изменение Совет по управлению изменениями Группа , принимающее решение утвердить или отклонить каждое предложенное изменение для определенного прооекта Тот , кто оценивает изменение Человек , которого председатель совета просит проанализировать влияние предложенного изменения ; это может быть сотрудник технического отдела , клиент , маркетолог или сотрудник , занимающийся всем этим понемногу Тот , кто вносит изменение Отвечает за внесение изменений в продукт , когда запрос на изменение утвержден Тот , кто инициирует запрос Некто , подающий новый запрос на изменение Получатель запроса Лицо , которому передаются новые запросы на изменение Тот , кто проверяет изменение Человек , определяющий , корректно ли выполнено изменение
Процесс контроля изменений желательно описать, утвердить и донести до каждого разработчика. Описание процесса контроля включает: Определение области действия. Процесс контроля не обязательно должен быть всеобъемлющим. Он может касаться некоторой части продукта, отдельного проекта, подразделения или всей организации. Он может также распространяться на определенные этапы жизненного цикла ПО. Категории изменений. Процесс контроля могут проходить абсолютно все изменения, изменения после утверждения базовой версии требований, только изменения предлагаемые пользователями. Определить категорию изменений можно исключением (например, "кроме служебных программ"). Роли исполнителей. Для того, чтобы процесс работал, необходимо определить персонально, кто в нем участвует и в какой роли. Примеры ролей: Ответственный за процесс, Регистратор запросов, Оценивающий влияние, Вносящий изменения и т.п.
Шаблоны документов. Поскольку процесс контроля изменений является чисто человеческой деятельностью, то полезно определить форму и содержание документов его сопровождающих. К таким документам относятся: «Запрос на изменение», «Отчет об анализе влияния» и т.п. Состояние запроса. «Запрос на изменение» является основным обязательным документом, сопровождающим процесс контроля. В своем жизненном цикле он может иметь следующий набор состояний: «Получен», «Оценен», «Отклонен», «Одобрен», «Внесен в требования».
Основным инструментом в процессе контроля за изменениями является документ, обычно называемый "Запрос на изменение" ( change request ). Основной минимальный набор атрибутов запроса на изменение следующий: Автор - кто инициировал запрос (запрос не может быть анонимным) Дата - когда запрос подан (это важно при разборках типа «почему не выполнен») Описание - описание сути предлагаемого изменения. Требования к описанию сути изменения такие же, как и для отдельного требования. В качестве дополнительных атрибутов запрос на изменение может иметь: Идентификатор или номер (для точных формальных ссылок). Краткое название изменения (для содержательных ссылок). Объект изменения – идентификатор требования, продукта или его части.
Тип запроса : «добавление», «исправление», «исключение требования» (для анализа проекта) Важность изменения с точки зрения автора (для определения приоритетов) Дата обновления , если исходный запрос в процессе анализа был скорректирован Источник – категория и имя автора (клиент, маркетолог, разработчик ...) Контактная информация автора (для больших проектов).
После прохождения процедуры анализа влияния и рассмотрения у запроса возникают другие атрибуты: Результат анализа влияния изменения на бизнес и проект Резолюция – решение ответственного органа (лица) по данному запросу Приоритет реализации запроса Ответственный за внесение изменения в СТПО и его доведение до исполнителей Состояние запроса по результатам рассмотрения Значения дополнительным атрибутам присваивается лицом, исполняющим роль Регистратора запросов. В процессе контроля изменений в команде проекта эта роль может выполняться любым членом команды разработчиков (но обязательно одним), который координирует обработку изменений. Для обработки запросов хорошо использовать базу данных, которая облегчает его заполнение, прохождение и распространение.
Каждый запрос должен проходить экспертизу, обычно называемую Анализом влияния , в целях выяснения возможных последствий принятия или непринятия предлагаемого изменения. При этом нужно учитывать что: - проверка технической осуществимости может потребовать проведение экспериментов; - изменение может не соответствовать бизнес целям, а иметь новую для него ценность. - масштаб влияния изменения включает не только изменение отдельного программного элемент, но и СТПО, моделей, тестов, документации и т.п.; - стоимость выполнения изменения может включать изменение сроков проекта, стоимость приобретения дополнительного оборудования или ПО, привлечения дополнительных ресурсов и т.п.; - отклонение запроса на изменение может оказать негативное влияние на бизнес;
В общем случае, влияние изменения на проект может иметь и положительное влияние («отрицательную» стоимость), если его принятие сокращает сроки разработки, снижает потребность проекта в ресурсах (люди, оборудование, ПО). В процессе Анализа влияния выявляются компоненты, которые нужно создать или изменить и оцениваются затраты на это. Одно изменение может вызвать лавину переделок, включение новых функций может снизить производительность и т.п. Для анализа последствий принятия изменений полезно использовать список контрольных вопросов. На следующем слайде приведен пример контрольного списка вопросов для анализа влияния изменений.
Список контрольных вопросов нужно адаптировать к условиям разработки с учетом особенностей разрабатываемого ПО и используемых технологий.
Простые на первый взгляд изменения часто оказываются более сложными. При этом, чем выше уровень изменяемых требований, тем масштабней влияние изменения. ЛОВУШКА1 . Часто в затраты включают только время на кодирование, забывая о тестировании, документировании и управлении проектом. Список рабочих продуктов для модификации или разработки нужно готовить в виде документа с указанием трудоемкость реализации каждого элемента. Результаты оценки влияния отдельного изменения можно представить в виде таблицы (см. слайд). Список элементов может оказаться не полным или не точным, но его наличие все равно лучше, чем отсутствие, так как он объективизирует масштаб изменений. ЛОВУШКА2 . Разработчики - в основном оптимисты и часто не могут сделать реалистичные расчеты затрат. Всегда хочется показать свою "крутизну": "это пара пустяков!". Возможно, это в меньшей степени относится к работе на повременной основе (без явного определения проекта).
В этой связи для оценки трудоемкости лучше использовать некоторые «нормативы», основанные на опыте конкретной организации, команды проекта или отдельного разработчика. Используя списки рабочих продуктов с оценкой трудозатрат можно сравнивать реальные затраты с запланированными и вырабатывать соответствующие «нормативы». Такая информация создает почву для более адекватного планирования в будущем.
Если одновременно анализируется влияние нескольких изменений, то сводные результаты оценки трудозатрат на выполнение нескольких изменений можно представить в виде другой таблицы с колонками: “ Изменение” - код и название предлагаемого изменения; “ Формы” - трудозатраты на разработку или модификацию экранных форм; “ Отчеты” - трудозатраты на разработку или модификацию отчетов; “ Процедуры” трудозатраты на разработку или модификацию процедур или классов и т.п. тестировании, документировании и управлении проектом.
Анализа влияния изменения может потребовать от несколько часов до нескольких дней. Альтернативой Анализу влияния являются несколько минут размышлений и резолюции типа "Нет проблем", "И так все ясно", "Думаю, это не займет много времени". Правильные расчеты являются основой управления ожиданиями заказчиков, а неправильные расчеты ведут к потере его доверия. Долго ожидая быстро обещанных результатов, он может вообще отказаться от изменений и, соответственно, их оплаты.
В качестве организационного инструмента Управления изменениями предлагается использовать "Совет по управлению изменениями" (Change Control Board, CCB). Совет представляет собой орган, который уполномочен принимать решения об утверждении предлагаемых изменений. В его же функции входит утверждение на начальном этапе проекта базовой версии спецификаций требований. Состав, структура и полномочия Совета определяются принятым в проекте процессом контроля изменений. Функции Совета может выполнять одно лицо (например, руководитель проекта) или комитет, возглавляемый председателем, в который могут входить менеджеры, аналитики, представители заказчика, а так же различные категории разработчиков. Совет действует в интересах заказчика и руководителя проекта и создает основу для пересмотра обязательств сторон в условиях изменения требований. Даже если обязательства формально не пересматриваются, Совета обеспечивает объективные свидетельства о ходе проекта, которые в случае разбирательств могут объяснить причину неудачи.
Основным артефактом при работе Совета является «Запрос на изменения». После одобрения запроса ему назначается приоритет, он вносится в спецификацию требований, если нужно, корректируется план, и соответствующая информация доводится до исполнителей. Даже если проект реализует один человек, контроль изменений остается полезным. В этом случае говорят о не о совете, а о "Точке управления изменениями" (есть даже такой термин Change Control Рoint, CCP), которая присутствует в творческом процессе разработчика. При этом в упрощенном виде сохраняются все процедуры и артефакты процесса контроля (запрос на изменение, результаты анализа влияния и т.п.). ЛОВУШКА. Чем меньше коллегиальность принятия решений об изменениях требований, тем выше риски неудачи проекта.
Успех проекта по разработке ПО определяет баланс четырех основных переменных: «Время», «Затраты», «Качество» и «Объем» работ. Если значения этих переменных выбраны правильно, то проект считается успешным («качественно и в срок имеющимися ресурсами реализован запланированный объем работ»). Проблема изменений состоит в том, что все переменные проекта исходно зафиксированы, и изменения требований в ходе проекта увеличивает объем работ и нарушает исходно установленный баланс. В задачи Совета входит организация анализа влияния изменений, и принятие решения о судьбе изменения путем «взвешивания» всех преимуществ изменения (экономия средств, увеличение дохода, удовлетворение клиента, конкурентные преимущества ...) и отрицательных последствий для проекта (затраты на разработку, задержка поставки). По результатам анализа влияния Совет должен принять сбалансированное решение, результатом которого может стать осознанное увеличение сроков или затрат, снижение качества продукта или уменьшение функциональности.
Заказчик может остаться недовольным как в случае отказа от предлагаемого им изменения, так и в случае его принятия, при условии, что поставка продукта задержится или, что он, например, будет меньше тестироваться. Находить сбалансированные решения по предлагаемым изменениям с учетом интересов всех заинтересованных сторон и является основной целью «Совета по управлению изменениями».
Реализация изменение требования может потребовать изменения других требований и элементов ПО (рабочих продуктов). Как при анализе влияния выяснить, каких? Для этого нужно иметь информацию о том, с какими другими требованиями или рабочими продуктами (компонентами дизайна, модулями исходного кода, вариантами тестирования, файлами с документацией) связано данное требование. Такая информация о связях, зафиксированная в явном виде называется трассировкой требований. Она помогает отслеживать связи требований в направлениях от источника к реализации и наоборот. На слайде показаны возможные варианты трассировки. Потребности заказчика отслеживаются в требованиях, чтобы можно было определить, какие требования затрагиваются при изменении потребностей. Такие связи обеспечивают уверенность в том, что спецификация требований отражает все потребности заказчика и что каждое требование обосновано.
По мере разработки ПО трассировка позволяет отслеживать связи между отдельными требованиями и рабочими продуктами, чтобы можно было определить, какие элементы затрагиваются при изменении потребностей. Такие связи обеспечивают уверенность в том, что каждое требование реализуется определенным набором рабочих продуктов и, что среди последних нет таких, которые не соответствуют ни одному из заданных требований.
Трассировка представляет потребности и требования в виде ориентированного ацикличного графа, по которому можно прослеживать связи потребностей и требований (сверху вниз и снизу вверх). Трассировка имеет дело с функциональными требованиями и обычно не затрагивает характеристики качества ПО и ограничения, если им не соответствуют определенные функциональные требования. Для выполнения трассировки: - требования дробятся на мелкие фрагменты (одна функция - одно требование). - требования и элементы конфигурации уникально идентифицируются, чтобы на них можно было ссылаться. - для каждого требования (элемента конфигурации) указывается источник.
Трассировка требований к рабочим продуктам определяет связь между требованиями и реализующими их элементами ПО. Наличие трассировки позволяет проверить полноту реализации требований и наличие рабочих продуктов не соответствующих никаким требованиям ("код-сироту"). Часто наличие таких элементов ПО говорит о том, что некоторое требование просто не зафиксировано. Трассировка требований к рабочим продуктам помогает контролировать продвижение проекта, снижает риск неполноты реализации требований и помогает выполнять анализ влияния изменения требований. Нефункциональные требования (производительность и другие свойства) не всегда прослеживаются до элементов продукта. Производительность часто связана с архитектурой, оборудованием, структурой БД. Перемещаемость часто связана с выбором языка, ограничениями на использование библиотек. Но некоторые нефункциональные требования активизируют создание производных функциональных требований.
Уникальная идентификация требований является необходимым условием трассировки. Наиболее простой способ идентификации требований и рабочих продуктов учитывает наличие нескольких уровней требований и категорий рабочих продуктов. При таком подходе для каждой категории требований и рабочих продуктов вводится краткое обозначение, которое используется в идентификаторе в качестве индекса. В пределах одной категории требования нумеруются последовательно. Номер, присвоенный однажды некоторому требованию, не используется при удалении этого требования. Для упоминания рабочих продуктов вместо последовательного номера можно использовать обозначения соответствующих диаграмм (DFD, SADT, ER D ), тестов, документов. На программные элементы обычно ссылаются по их именам.
Если требования имеют явно выраженную иерархическую структуру, то последовательные номера требований более низкого уровня также индексируются номерами требований более высокого уровня.
В зависимости от создаваемых в ходе проекта типов рабочих продуктов трассировка может отражать различные типы связей. В общем случае эти связи могут быть "многие ко многим". При разработке ПО могут создаваться различные категории требований и рабочих продуктов. Но не обязательно все связи определять явно. В каждом проекте можно ограничить набор отслеживаемых связей, определив какие связи следует фиксировать явно (например, только функциональные требования и рабочие продукты).
Обычно информация о трассировке фиксируется в документе «Матрица трассировки» (варианты названия: «Матрица отслеживания», «Таблица трассировки»). Пример такого документа с простейшей структуры показан на слайде. Такой документ создается после утверждения базового варианта требований. При этом в ней заполняются первые две колонки. По завершении разработки каждого элемента ПО конфигурации (не по мере планирования!) информация о нем заносится в третью колонку. Это позволяет фиксировать связи требований с рабочими продуктами и, дополнительно, отслеживать продвижение проекта.
Трассировку можно представить в виде матрицы, определяющий связи между требованиями и рабочими продуктами ("Функциональные требования - программные элементы", "Функциональные требования-Варианты тестирования" ...). Если программных элементов значительно больше чем требований, то эту матрицу можно развернуть на 90 градусов.
Трассировка требует хорошей организации работ и дисциплины. При этом, нужно учитывать, что регулярно обновлять информацию трассировки не сложно, восстанавливать по мере продвижения к завершению проекта очень сложно. Поэтому, трассировку нужно либо делать регулярно, либо не делать вовсе. Разработчик держит информацию о связях в голове и может обойтись без документирования трассировки. Но эта информация также нужна руководителю проекта. Решение состоит в том, что за трассировку должны отвечать другие лица (менеджер проекта, руководитель группы, аналитик) запрашивая информацию у разработчиков, которые, могут препятствовать ее предоставлению, если им не объяснить всю ценность такой информации. Для выполнения трассировки необходимо явно определить соответствующую проектную процедуру (см. слайд).
Трассировка дает долгосрочные выгоды. Она увеличивает затраты на управление, но эти затраты по сути являются инвестициями, которые возвратятся на в процессе сопровождения и развития системы. Трассировка обеспечивает ряд преимуществ при выполнении других работ: Анализ влияния - позволяет выполнить более точный расчет трудозатрат Контроль проекта - отслеживает реализацию потребностей и требований Разработка - выявляет места внесения изменений при адаптации продукта Сопровождение - повышает качество внесения изменений на этапе использования ПО Проектирование - выявляет пакеты связанных требований и элементов ПО Управление рисками - наличие трассировки снижает риск ухода разработчика
Тестирование - позволяет более целенаправленно вести тестирование Демонстрация - облегчение демонстрации реализации исходных требований Применять трассировку или нет, тратить ли драгоценное время? - вопрос сопоставления преимуществ и затрат. Для принятия правильного решения, вспомните сколько ошибок в проектах было сделано из-за отсутствия информации о связях. Правильный путь - попробовать трассировать 10-20 требованиях для сложной части ПО и затем постепенно расширять масштаб.
При использовании документального способа хранения требований на бумаге или в файлах: - трудно синхронизировать изменение различных представлений требований и рабочих продуктов. - трудно доводить информацию при изменении этих документов многим участникам проекта, особенно при их географическом удалении; - трудно отслеживать состояние требований; - трудно распределять требования по версиям продукта. При переносе требования в следующий выпуск, приходится перемещать его из одной спецификации в другую. Альтернативой документального хранения требований и изменений является использование специализированных инструментальных средств на базе данных.
Для управления изменениями требований существуют специальные инструментальные средства, которые автоматизируют многие процессы работы с требованиями (см. слайд). Инструменты позволяют более гибко управлять требованиями и их изменениями, делают процесс контроля более прозрачным и простым. Они облегчают скучную и рутинную работу по трассировки требований. Инструменты позволяют достоверно измерять активность изменений и анализировать ход проекта, а не на основе субъективных впечатлений и неясных воспоминаний, зависящих скорее от уровня оптимизма и пессимизма разработчиков и заказчиков. По активности изменений можно оценивать работу аналитика (качество требований) и постепенно совершенствовать процесс определения требований. Высокая частота изменений в течение длительного времени - верный признак приближения провала проекта. ЛОВУШКА . Инструменты обеспечивают удобную работу с отдельными требованиями и изменениями, облегчают их модификацию, но ограничивают возможности контроля качества спецификации в целом (завершенность, непротиворечивость). Просматривая фрагмент требования через экран весь контекст приходится держать в памяти.
Нужно понимать, что использование инструментов не решает всех проблем работы с требованиями. Они не помогут определить потенциальных пользователей или выявить нужные требования. Они не заменят интеллект экспертов и лиц, принимающих решения, при управлении изменениями. Они не могут полностью автоматизировать трассировку, так как информация о связях находится в памяти исполнителей. Использовать инструменты можно, когда у вас уже есть рабочая методика, но ей не хватает эффективности. Нельзя надеяться, что инструмент восполнит недостаток трудолюбия, дисциплины, опыта или понимания.
На рынке ПО предлагается много инструментальных средств, поддерживающих управление требованиями и контроль изменений. ЛОВУШКА. Не пытайтесь быстро, на скорую руку разработать собственное средство управления требованиями, сравнимое по мощности с коммерческими продуктами. Это может показаться легко, но такая разработка может сильно отвлечь ресурсы команды от основной разработки, и не приведет к созданию хорошего инструмента, особенно в условиях недостатка необходимых теоретических знаний и опыта ручного управления изменениями. [Карл Вигерс] Однако, если вы создали и сопровождаете производственную систему своего предприятия, то в нее без значительных затрат можно встроить простую систему сбора и обработки заявок на изменения системы от пользователей, которая может значительно повысить управляемость изменений.
Книги, руководства, стандарты всегда рисуют некоторую идеальную картину работы, которую в реальных условиях воспроизвести практически невозможно. Ее не следует отвергать из-за недостижимости, а нужно использовать в качестве ориентира для выбора первых шагов в ее направлении. Современная программная инженерия - мастерская с большим набором инструментов (принципы, методы, средства), которые не обязательно использовать все для решения конкретной задачи. Однако, нужно знать, что в мастерской имеется, чтобы подобрать для решения текущей задачи оптимальный набор инструментов. Не пытайтесь внедрять все методы сразу. Кроме того, инструменты нужно затачивать и делать профилактику, это означает что выбранные принципы, методы и средства нужно регулярно применять и совершенствовать.
Подводя итоги, хочется сформулировать несколько основных принципов работы, связанных с требованиями к ПО: Выявлять требования до программирования в максимально возможном объеме. Разработка без требований похожа на путешествие по незнакомой местности без карты. С точки зрения руководства и заказчика программист «ныряет в кротовую нору с множеством выходов, и в каком и когда он вылезет никто не знает» ("Тоннельный эффект"). Фиксировать все требования, запросы на изменение, результаты анализ влияния. В разработке ПО всегда есть много заинтересованных лиц (минимум 2), с которыми нужно обсуждать требования и изменения. Делать это в устной форме опрометчиво, из-за ненадежности нашей памяти и сильных различий в уровне подготовки Чувствовать границу между «что нужно сделать» и «как это сделать» Предпринимая любые шаги в разработке, на любом ее этапе сначала нужно понять «что нужно сделать», чтобы была свобода поиска и правильного выбора того «как это делать». «Что нужно сделать» задает границу между требованиями и решениями. Программист должен максимально себя защищать, выстраивая границу между тем, что он должен сделать, и своей работой. Не важно идут требования от заказчика. своего аналитика или руководителя. Это повысит качество ПО, позволит точнее спланировать работу и снизит ответственность за реализацию неудачно поставленной задачи. Упор делать не на процессы, процедуры и стандарты, а на принципы и результаты.
Образцы документов для управления требованиями Процесс управления требованиями . Описывает действия работающей над проектом команды , связанные с изменениями требований , различными версиями документации по требованиям , учетом и отчетностью статусов требований и накоплением информации по трассированию . Здесь должны быть указаны списки атрибутов для каждого требования — приоритет , ожидаемая стабильность и планируемый номер выпуска , а также действия , необходимые для одобрения спецификации и основной версии требований . Пример описания процесса управления требованиями вы можете найти в приложении J «CMM Implementation Guide» (Caputo, 1998). Процесс управления изменениями . Реально действующий процесс управления изменениями способен уменьшить хаос , вызываемый бесконечными , бесконтрольными изменениями требований . Процесс управления изменениями определяет пути предложения , передачи , оценки и разрешения нового требования или его модификации . Инструментальное средство выявления проблем облегчает контроль за изменениями , но помните , что инструмент — не замена процессу . В главе 19 детально описан процесс управления изменениями . Процедура проверки статуса требований . Подразумевает проверку статуса каждого функционального требования и отчетность по нему . Вам придется использовать базу данных или коммерческое средство управления требованиями , чтобы контролировать статус большого числа требований в огромной системе . Эта процедура также описывает отчеты , которые вы сможете генерировать для просмотра статуса собранных требований в любое время . Больше об учете статуса требований вы можете прочитать в главе 18. Устав совета по управлению изменениями . В совет по управлению изменениями (change control board, CCB) входят наиболее заинтересованные в проекте лица , которые решают , какие изменения в требованиях принять , какие отвергнуть и в какую версию продукта следует внести каждое предложенное изменение . Как вы знаете из главы 19, устав совета по управлению изменениями описывает структуру , функции и рабочие процедуры совета . Процедура трассируемости требований . Матрица трассируемо - сти требований содержит список всех функциональных требований , конструктивных элементов и модулей кода , связанных с каждым требованием , и варианты тестирования , подтверждающие его корректную реализацию . Матрица трассируемости должна также определять требование исходной системы , вариант использования , бизнес - правило или другой источник , из которого проистекает каждое функциональное требование . Список и шаблон анализа последствий изменений в требованиях . Оценка стоимости и другого влияния предлагаемого изменения в требованиях — ключевой шаг в определении того , принимать ли его . Анализ последствий помогает совету по управлению изменениями принимать информированные решения . Как показано в главе 19, список последствий помогает вам рассмотреть задачи , побочные эффекты и риски , которые могут возникнуть при реализации каждого изменения в требованиях . Рабочая таблица предлагает простой способ оценки трудовых затрат для каждого задания . Пример шаблона для результатов анализа последствий также показан в главе 19.
Это, конечно, не единственные источники информации. На сегодня существует масса литературы по этой развивающейся области Программной инженерии. Некоторые ссылки на нее приведены ниже: Астелс Девид, Миллер Гранвилл, Новак Мирослав. Практическое руководство по экстремальному программированию, Пер. с англ. - М.: Издательский дом "Вильямс", 2002. - 320 с.: Бек Кент. Экстремальное программирование. – СПб.: Питер, 2002. – 224 с.: Брукс Фредерик. Мифический человеко-месяц. - Пер. с англ. – СПб.: Символ-Плюс, 2005 Коберн Алистер. Современные методы описания функциональных требований к системам / Пер. с англ. - М.: Издательство "Лори", 2002. - 263 с.: Купер Алан. Психбольница в руках пациентов. - Пер. с англ. – СПб.: Символ-Плюс, 2004 Соммервил Иан. Инженерия программного обеспечения, 6-е издание. - Пер. с англ. - М.: Издательский дом "Вильямс", 2002. - 624 с.:
Шмуллер Джозеф. Освой самостоятельно UML за 24 часа, 2-е издание / Пер. с англ. - М.: Издательский дом "Вильямс", 2002. - 352 с.: IEEE Std 1233-1998, IEEE Guide for Developing System Requirements Specifications, 1998. IEEE Std 1362-1998, IEEE Guide for Information Technology-System Definition-Concept of Operations (ConOps) Document, IEEE, 1998. IEEE/EIA 12207.0-1996//ISO/ IEC12207:1995, Industry Implementation of Int. Std.
