Мастер-класс для отработки навыков ревизии требований, в продолжение доклада "Не все проверки бесполезны или несколько способов ревизии требований".

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

Стив Макконнелл в книге «Сколько стоит программный проект» и мировая статистика утверждают, что наиболее дорого исправлять ошибки, допущенные на этапах сбора требований и проектирования. Иногда выявленные ошибки достаточно серьезные и требуют переработки не только своей системы (или некоторой ее части), но и смежных систем. Когда выявление этих ошибок происходит на этапе тестирования, то в корзину уходит труд и аналитиков, и разработчиков, и тестировщиков и технических писателей. 

Можем ли мы выявить хотя бы часть таких ошибок на более ранних стадиях работ? Может ли тестировщик (инженер по требованиям) выявить ошибки в требованиях до разработки ПО? 

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

В чатах и группах аналитиков часто возникают вопросы: 

• Как провести оценку компетенций аналитиков? 
• Какими компетенциями должен обладать мидл, какими – сеньор? 
• Как оценить компетенции? Как понять каких компетенций не хватает специалисту? 
• Как объяснить человеку результат оценки, чтобы не обидеть его?

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

И как за 5 шагов построить подобную систему под свои нужды.

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

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

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

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

Многим из нас знакома ситуация: от заказчика поступил запрос на пресейл, срочная задача аналитикам, потенциальный новый перспективный контракт, но среди аналитиков Компании нет специалистов в этом домене. Это причина отказаться от контракта? Или есть выход? 

На мастер-классе поделюсь опытом, как за несколько дней погружались в новый домен, какие проблемы возникали и как их решали. Обсудим примеры удачного и неудачного опыта и причины неудач. Рассмотрим применение метода ментальных карт (Impact Mapping), как способа определения границ проекта и основных гипотез, созданных совместными усилиями разработчика и Заказчика. Совместно выработаем чек-лист погружения аналитика в новый домен.

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

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

Этот доклад не для вас, если у вас:

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

-       разноплановые, зачастую исследовательские работы;

Информационная система крупной корпорации или ведомства является, как правило, комплексом программных подсистем, а также взаимодействует с ИС других предприятий /организаций. В силу различных причин, внесение изменений в ПО – постоянная жизненная потребность. Несогласованные изменения связанных подсистем (или смежных ИС) могут привести не только к блокировке работы ПО, но и предприятия (ведомства) в целом. В докладе описан пример управления функциональными требованиями автоматизированной документоориентированной системы (комплекса подсистем). Рассмотрены изменения документов, функций ПО над документами, операций пользователями с документами и интерфейсов обмена между подсистемами. Предложена структура хранения требований и методика контроля изменений. Контроль изменений доработок смежных подсистем и внешних ИС обеспечивает стабильную работу корпорации или ведомства. Кроме того, с помощью системы управления требованиями частично автоматизирована подготовка проектной документации.