Опубликовано

Управление изменениями проекта.

Управление изменениями проекта

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

Что входит в управление изменениями проекта:

  • Анализ и сбор всех требований Заказчика.
  • Фиксирование всех требований (общий бизнес-процесс, GUI, функционал) в спецификации.
  • Регистрация всех требований, подлежащих реализации, в багтрекинговой системе. Соответствующая пометка тех требований, которые должны войти в деливери. Ответственный – руководитель проекта.
  • Обязательный групповой анализ каждого запроса на изменение или доработку (руководитель проекта, QA, бизнес аналитик, техлид). Полное уточнение информации, принятие решения (отклонение запроса, запуск в реализацию, оформление дополнительным оплачиваемым этапом и т.п.)
  • Оформление каждого запроса на изменение или доработку в форме Change Order, подлежащего подписи заказчиком (отвечает за оформление – бизнес аналитик, за подписание – руководитель проекта).
  • После утверждения изменений должно проходить обязательное обновление спецификаций, тест-кейсов и т.д.
  • Определение целесообразности начала тестирования следующего деливери.

Критерий начала:

  • Все или большинство требований, относящихся к следующему деливери (фазе), реализованы.

Определяет готовность версии к тестировании по багтрекинговой системе, ответственный QA. Все требования, которые необходимо реализовать в определенном деливери, внесены в багтрекинговую систему с пометкой «Реализовать в x.y.» и, соответственно, попадают в фильтр «Деливери x.y.». Когда все или большинство требований, попадающих в фильтр, будут реализованы, версию можно передавать на тестирование QA.

  • Определение готовности деливери к отправке. Критерии готовности:
  • все требования, относящиеся к данному деливери (фазе), реализованы;
  • открытые дефекты, относящиеся к данному деливери (фазе), отсутствуют.

Определяет по багтрекинговой системе QA и уведомляет руководителя проекта. Все требования, которые необходимо реализовать в определенном деливери, внесены в багтрекинговую систему с пометкой «Реализовать в x.y.» и, соответственно, попадают в фильтр «Деливери x.y.». Когда все требования и дефекты, попадающие в фильтр, будут закрыты, версию можно отсылать заказчику.

Мы рассмотрели пример процесса управления изменениями в ИТ проекте. Одна из распространенных ошибок – одноособное управление требованиями исходящее от руководителя проекта. Залог успеха – групповое обсуждение изменений, достижение компромисса со всеми учасниками.

Опубликовано

Роли в команде разработчиков ПО.

Роли в команде разработчиков ПО

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

Роли в команде разработчиков ПО:

Менеджер Проекта (PM) ответственный за:

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

Бизнес аналитик (Business Analyst) ответственный за:

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

Системный аналитик (Technical Leader) ответственный за:

  • координацию и контроль деятельности по дизайну, архитектуре и кодированию;
  • поддержку контроля версий;
  • настройку скрипта для авто-билдера и своевременную сборку версий.

QA менеджер (QA manager) ответственный за:

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

QA аналитик (QA Analyst) ответственный за:

  • подготовку тест дизайна;
  • написание тест кейс спецификаций;
  • проведение тестирования;
  • регистрацию багов;
  • прослеживание и проверку багов;
  • написание документации пользователя.

Разработчик (Developer) ответственный за:

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

Заказчик (Customer) ответственный за:

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

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

Опубликовано

План разработки сайта – SDP

План разработки сайта – SDP

План разработки сайта — Software Development Plan. Этот документ дает понимание участникам проекта (проектной группе и заказчику) о том, каким образом будет вестись работа в рамках проекта, каковы правила и т.д.

Документ дает полное представление:

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

План разработки сайта описывает:

  • Цель, содержание и функции проекта
  • Объекты, подлежащие сдаче
  • Приоритеты проекта
  • Организация проекта
  • Проектная группа
  • Артефакты проекта
  • Роли и ответственности
  • Взаимодействие участников
  • Управление разработкой
  • План-график проекта
  • Контроль качества
  • Управление требованиями и изменениями
  • Управление конфигурацией
  • Инструменты, инфраструктура
  • Контроль версий
  • Процесс сборок и релиза
  • Работа с дефектами
  • Параметр бага «Fix in»
  • Фильтры
  • Зависимость полей
  • Значения поля «Version»
  • Действия QA после сборки внутреннего билда
  • Действия QA после сборки деливери
  • Действия PM после сборки деливери
  • Предоставление отчетов
  • Почта
  • Проектный цикл
  • Разработка
  • Тестирование
  • Приемо-сдаточные испытания
  • Участие клиента в процессе
  • Ревю и утверждение проектной документации
  • Обсуждение изменений в требованиях, сроках, бюджете
  • Просмотр промежуточных версий ПО
  • Фиксирование замечаний и дефектов
  • Приемо-сдаточные испытания
  • Дополнительные планы
  • План обучения пользователей
  • План решения проблем
Опубликовано

Процесс тестирования програмного обеспечения (ПО).

Процесс тестирования програмного обеспечения (ПО)

Цель QA тестирования – убедиться, что ПО работает согласно задекларированным требованиям к ПО. Это включает в себя поиск несоответствий между полученным и ожидаемым результатом. Задача тестирования – систематическое обнаружение дефектов, с минимальной затратой времени и усилий, минимизация количества дефектов, найденных клиентом.
В QA процессе под “тестированием” подразумевается проверка того, что требований соблюдены и правильно реализованы. Трудоёмкость тестирования зависит от специфики проекта и его фазы.
Процесс тестирования плотно связан с процессом разработки, и идёт параллельно с ним.
Процесс тестирования итеративен. В каждой итерации интенсивность тестирования и специфика могут отличаться.
1 Критерии входа
До возможности начала QA тестирования должны быть выполнены следующие критерии:

  • QA инженеры проинформированы об объеме проекта, сути, оценке, графике, составе проектной группы, задачах и обязанностях её членов.
  • Все требования к ПО определены и приняты (зафиксированы в ТЗ и спецификациях, причём достаточно детализированы).
  • Есть план разработки по версиям.
  • Разработчики выполняют тестирование кода (Unit, Stress и Integration тестирование).
  • Определён подход к тестированию.
  • Установлена среда тестирования.

2 Работы
Объем работы зависит от качества входной информации, а именно: спецификаций, объёма и сложности проекта, требований.
Для повышения эффективности можно выполнять сразу несколько видов тестов.
Тестирование, как и разработка, носит итеративный характер. Каждую итерацию:

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

2.1 Определение требований, подлежащих тестированию
QA определяет требования, подлежащие тестированию, и определяет их приоритеты. Отталкивается QA от ТЗ, плана разработки по версиям, спецификаций – всего, что имеется в наличии и относится к требованиям к системе, которую необходимо разработать.
После этого можно создавать тест кейсы, сценарии, тестовые данные.
Эта работа тесно связана с планированием и оценкой.

2.2 Планирование тестирования
Для проекта составляется план тестирования, включающий в себя стратегию и подход, компоненты и конкретные требования, подлежащие тестированию, критерии приёмки системы, вид и глубину тест кейсов и сценариев.
Подробнее о проектном документе тест план написано здесь: http://www.seolux.com.ua/archives/89.

2.3 Тест дизайн
Подробнее тест дизайн описан здесь: http://www.seolux.com.ua/archives/103.

2.3.1 Описание сценариев
Тестирование бизнес-процесса или его логической части описывается сценарием. Сценарий виртуально моделирует поведение пользователя.
Сценарии базируются на определенных тест кейсах и представляют рабочий процесс с конечным результатом.
У каждого сценария есть описание и предварительная подготовка данных (где это необходимо).

2.3.2 Функциональные тест кейсы
Подробнее о функциональных тест кейсах написано здесь: http://www.seolux.com.ua/archives/110.

2.3.3 Чек-листы для тестирования GUI
Для того, чтобы протестировать требования к GUI (графический интерфейс пользователя), обычно достаточно составить чек-лист. Он должен опираться на стандартные соглашения в дизайне интерфейса и специальные запросы заказчика. Полезно классифицировать требования на те, что относятся ко всему приложению, и те, что относятся к отдельным частям.
Обычно для всего приложения создается общий GUI чек-лист, поскольку в большинстве случаев разные формы и части функционируют практически одинаково.

2.3.4 Подготовка тестовых данных
Чтобы составить полный тест план, необходимо определить полный набор необходимых данных в базе данных, которые, в идеале, должны быть всегда готовы на момент начала тестирования. Необходимые данные определяются на стадии написания тест кейсов (для прохождения которых необходимо наличие готовых данных в системе). Перед началом тестирования определённые тестовые данные должны быть подготовлены. Обычно данные создаются средствами GUI самой системы или с помощью скриптов, заполняющих базу данных необходимыми значениями.
Как только база данных готова, рекомендуется заархивировать базу данных для сохранения тестовых данных для тестирования следующих версий. В следующей итерации, по возможности, из архива просто восстанавливается необходимое для тестирования состояние базы данных.

2.3.5 Поддержка тест кейсов
Тест кейсы должны постоянно поддерживаться в актуальном состоянии. То есть, при поступлении новых требований, изменении существующих требований, тест кейсы должны обновляться.
Должен соблюдаться контроль версий всех артефактов.

2.4 Выполнение тестирования
Существует несколько видов тестов. Их нужно разграничить в плане проекта, так как некоторые из них можно проводить одновременно, а другие – в строгой логической последовательности.

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

2.6 Оценка качества
После окончания тестирования каждой версии проводится оценка результатов тестирования, и в итоге создается Test Summary Report (Итоговый отчет по тестированию). Отчет содержит следующую информацию:

  • Выполненный объем тестирования
  • Статистика и перечень дефектов
  • Заключение о качестве продукта

На основании этих данных QA инженер делает заключение о версии – выполнены ли предъявленные к данной версии приёмочные критерии.

3 Критерии выхода
Следующие критерии показывают, может ли продукт тестирования выйти из фазы QA:

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

Как проверить сайт.

Как проверить сайт

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

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

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

Не стесняйтесь напоминать о себе исполнителю, чем чаще, тем лучше. Ведь о Вас могут попросту забыть.  А еще лучше требуйте посмотреть промежуточный результат.

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

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

Как известно, скупой платит дважды, в редких случаях трижды. Заложив в бюджет создания сайта работу по описанию требований и их тестированию от 20% до 30% стоимости всей разработки, позволит Вам избежать многих подводных камней на пути к успеху.