анализ требований. Приложение 1. Анализ требований по Вигерсу. Приложение 1 анализ требований (по Вигерсу)
 Скачать 1.62 Mb.
|
|
Четыре комбинации для определения шкалы приоритетов: — требования с высоким приоритетом (high priority) — и важные (пользователям нужны функции), и срочные (они необходимы уже в следующем выпуске). Некоторые требования приходится включать в эту категорию согласно контрактным или юридическим обязательствам либо из-за непреодолимых бизнес-причин; — требования со средним приоритетом (medium priority) — важные (пользователям нужны функции), но не срочные (они могут ждать следующего выпуска); — требования с низким приоритетом (low priority) — не важные (пользователи при необходимости могут обойтись без этой функций) и не срочные (пользователи могут ждать, причем вечно); — требования в четвертой клетке кажутся срочными, но в действительности — они не важны. Не тратьте время на работу над ними. Они не сделают продукт более ценным. Определение приоритетов на основе ценности, стоимости и риска В малом проекте заинтересованные лица могут согласовать приоритеты требований неформально. Крупные или спорные проекты требуют более структурированного подхода, устраняющего из процесса некоторые эмоции, политику и догадки. Для помощи в определении приоритетов предлагается несколько аналитических и математических методик. Они предполагают оценку относительной ценности и относительной стоимости каждого требования. Требования с самым высоким приоритетом — те, что обеспечивают большую ценность продукта при меньшей стоимости. Субъективная оценка стоимости и ценности посредством попарного сравнения всех требований не годится, если требований более двух десятков. Другая альтернатива — Quality Function Deployment (QFD), всесторонний метод определения относительной ценности для клиента предлагаемых функций продукта. Третий подход, заимствованный из Total Quality Management (TQM), позволяем оценить каждое требование по нескольким весомым критериям успеха проекта и подсчитать количество баллов для назначения приоритетов требований. Связь требований с другими составляющими проекта Требования составляют основу любого хорошо организованного проекта по разработке ПО, поддерживая технические и организационные задачи. Изменения способов разработки и управления требованиями повлияют на эти задачи, и наоборот.  Планирование проекта. Требования служат основой для процесса планирования проекта. Те, кто отвечает за планирование, выбирают подходящий жизненный цикл разработки ПО и разрабатывают ресурсные сметы и график работы на основе требований. Эта процедура может выявить невозможность реализации всего желаемого набора возможностей за отведенное время при выделенных ресурсах. В результате планирования иногда становится ясно, что следует сузить проект или выбрать инкрементальную модель либо модель постадийной реализации необходимой функциональности. Трассирование и контроль проекта. Трассирование подразумевает мониторинг статуса каждого требования, чтобы менеджеру проекта было ясно, действительно ли конструирование и проверка выполняются согласно принятому по плану. Если нет, он может потребовать сузить границы рассматриваемого объекта через процесс управления изменениями. Управление изменениями. После того как набор требований внесен в основную версию, все последующие изменения выполняются только через определенный процесс управления изменениями. Этот процесс помогает гарантировать, что: — все понимают эффект предлагаемого изменения; — уполномоченные сотрудники смогут обоснованно принимать решения об изменениях; — все люди, которых затронут изменения, осознают их; — ресурсы и обязательства выверены; — документация требований обновляется своевременно и точно. Тестирование системы. Пользовательские и функциональные требования представляют собой важнейшие входные данные для тестирования системы. Если предполагаемое поведение ПО в различных условиях не определено четко, тестировщикам будет чрезвычайно трудно обнаружить дефекты и проверить, вся ли запланированная функциональность реализована должным образом. Процесс конструирования. Несмотря на то, что работающая программа и есть конечный продукт проекта по разработке ПО, требования предоставляют основу для работы по конструированию и реализации и связывают воедино различные этапы разработки. Проверяйте построенные компоненты, чтобы удостовериться, что каждый из них точно соответствует требованиям. Тестирование блоков позволяет проверить, удовлетворяет ли их код спецификациям и соответствующим требованиям. Трассирование требований позволяет задокументировать, какие элементы конструкции и кода ПО были получены на основе каждого требования. Разработка пользовательской документации. Однажды я делил офис с техническими писателями, которые готовили пользовательскую документацию для сложных программных продуктов. Я спросил одного из них, почему они работают так долго. «Мы уже заканчиваем, — ответил он. — Нам приходится учитывать окончательные изменения в интерфейсах пользователей и функции, убранные или добавленные в последний момент». Требования к продукту содержат данные для процесса разработки пользовательской документации, так что плохо сформулированные или запаздывающие требования порождают проблемы в документации. Неудивительно, что страдальцы в конце цепочки разработки требований — технические писатели и тестировщики — часто с энтузиазмом поддерживают улучшенные приемы конструирования требований. Требования к ПО и управление риском Риск (risk) — это условие, которое может повлечь какие-либо потери или другим способом поставить под угрозу успех проекта. Это условие еще не породило проблему, и вы хотите, чтобы так оно и оставалось. Эти потенциальные проблемы могут оказать неблагоприятный воздействия на стоимость, сроки, технический успех, качество продукта или эффективность работы команды. Управление риском — лучшая практика индустрии ПО — это процесс выявления, оценки и управления риском до того, как он нанесет ущерб вашему проекту. Если что-либо нехорошее уже произошло с вашим проектом, то это — проблема, а не риск. Решайте текущие проблемы и вопросы, постоянно контролируя статус проекта и процессы введения поправок. Так как никто не может уверенно предсказывать будущее, управление риском — это способ минимизации вероятности потенциальных проблем или ущерба от них. Управление риском означает работу над потенциальной опасностью до того, как она перейдет в кризисную фазу. Это улучшает вероятность успеха проекта и уменьшает финансовые или другие последствия риска, которого не удастся избежать. Риск, лежащий вне сферы компетенции команды, следует передать руководству соответствующего уровня. Поскольку требования так важны в проектах по созданию ПО, предусмотрительный менеджер уже на ранних стадиях проекта выявит риск, связанный с требованиями, и будет достаточно агрессивно контролировать его. Распространенные факторы риска, связанные с требованиями, включают неверное понимание требований, недостаточное вовлечение пользователей, неточности или изменения в масштабах и целях проекта, и постоянно изменяющиеся требования. Менеджеры проектов могут управлять риском, связанным с требованиями, только в сотрудничестве с клиентами или их представителями. Совместное документирование факторов риска, связанных с требованиями и планирование действий по уменьшению их последствий укрепляет партнерство клиента и разработчика. Основы управления риском при создании ПО Проекты подстерегает масса рисков, помимо тех. что связаны с границами проекта и требованиями. Один из них — зависимость от внешних элементов, таких, как субподрядчик или другой проект, предоставляющий компоненты для повторного использования. При управлении проектом на первое место выходят такие виды риска, как неточные оценки, неприятие менеджерами точных оценок, недостаточная прозрачность статуса проекта и текучка кадров. Технологический риск представляет угрозу для очень сложных или использующих передовые разработки проектов. Недостаток знаний — — тоже очень опасен: исполнители не обладают достаточным опытом работы с используемыми технологиями или областью применения приложения. А постоянно изменяющиеся нормы законодательства могут разрушить и самые лучшие планы проектов. Как и в случае с другими процессами, соотносите действия по управлению риском с масштабами своего проекта. Для небольших проектов достаточно простого списка источников риска, а ключевым элементом успешного крупномасштабного проекта считается структурированное планирование управления риском. Составляющие управления риском Управление риском (risk management) — это применение инструментальных средств и процедур для ограничения факторов риска в проекте приемлемыми рамками. Управление риском предоставляет стандартный подход к выявлению и документированию факторов риска, оценке их потенциального ущерба и предлагает стратегии их смягчения. Управление риском включает в себя следующие действия:  Оценка риска (risk assessment) — это процесс исследования проекта для выявления областей потенциального риска. Облегчите задачу выявления факторов риска, составляя списки факторов риска, типичных для разработки ПО, в том числе связанных с требованиями. При анализе риска вы исследуете потенциальные последствия конкретных факторов риска для вашего проекта. Определение приоритетов факторов риска поможет вам сконцентрироваться на наиболее опасных, оценивая потенциальную подверженность каждому из них. Подверженность — это функция, включающая как вероятность потерпеть урон из-за риска, так и масштабы этого урона. Предотвращение риска (risk avoidance) — это один из способов решения вопроса: не делайте того, что рискованно. Вы можете избежать риска, не начиная определенные проекты, полагаясь на испытанные, а не самые передовые технологии или исключая функции, которые будет особенно трудно воплотить верно. Однако — разработка ПО рисковое предприятие, так что избежать риска означает потерять возможность. Большую часть времени вам придется выполнять контроль риска (risk control), что позволит управлять выявленными факторами риска с высоким приоритетом. Планирование управления риском подразумевает создание плана действий для каждого отдельного фактора, включая методы смягчения, планы на случай непредвиденных обстоятельств, ответственных лиц и сроки исполнения. Цель действий по смягчению воздействия риска — либо не позволить риску стать проблемой, либо уменьшить его вредное воздействие. Риск не будет контролировать сам себя, поэтому разрешение риска подразумевает реализацию планов по сдерживанию каждого риска. И, наконец, трассируйте свое продвижение к разрешению каждого риска посредством мониторинга риска, который должен стать частью вашего стандартного трассирования статуса проекта. Отслеживайте, насколько хорошо работают ваши действия по смягчению риска, ищите новые факторы риска, возникшие недавно, убирайте риски, угроза которых миновала, и периодически обновляйте приоритеты в вашем списке факторов риска. Документирование рисков проекта Недостаточно просто знать риски, угрожающие вашему проекту. Вам нужно управлять ими так, чтобы иметь возможность сообщать об областях и статусе риска заинтересованным в проекте лицам на протяжении проекта. Шаблон документирования отдельной области риска:  Иногда удобно хранить его в электронной таблице, что позволяет легко сортировать список областей риска. Вместо того чтобы включать его в свой план управления проектом или в спецификацию требований к ПО, ведите список областей риска в качестве отдельного документа — так его будет легко обновлять на протяжении проекта. Используйте формат «причина — следствие», документируя факторы риска. То есть сначала формулируйте причину риска, вызывающую вашу озабоченность, а затем ее потенциальный неблагоприятный результат—следствие. Часто люди, говорящие о риске, приводят только условие («клиенты не придут к единому мнению относительно требований к продукту») или только следствие («мы сможем удовлетворить лишь одного из наших основных клиентов»). Одна причина может повлечь несколько следствий, и несколько причин могут привести к одному и тому же следствию. В шаблоне предусмотрены поля для записи о вероятности материализации риска в проблему, о негативном влиянии на проект как результат этой проблемы и об общей подверженности проекта риску. Я оцениваю вероятность по шкале от 0,1 (практически невозможно) до 1,0 (обязательно произойдет), а ущерб — по относительной шкале от 1 (нет проблем) до 10 (полный кошмар). Еще лучше попытаться оценить потенциальное влияние в единицах потерянного времени и денег. Умножьте вероятность на влияние, чтобы оценить уязвимость для каждого элемента риска. Не пытайтесь оценить факторы риска слишком точно. Ваша цель — отделить наиболее угрожающие риски от тех, за которые не нужно хвататься немедленно. Проще оценивать и вероятность, и ущерб как высокий, средний или низкий. Факторы, имеющие как минимум одну оценку высокого уровня, требуют вашего внимания на ранних стадиях. В поле для плана смягчения риска записывайте действия, которые вы намереваетесь предпринять для контроля риска. Некоторые стратегии смягчения снижают вероятность риска, другие — уменьшают его влияние. Учитывайте стоимость этих действий при планировании. Неразумно тратить $20000 на управление риском, который стоил бы вам лишь $10000. Вы также можете составить планы на непредвиденные обстоятельства для самых угрожающих областей риска, заранее решив, какие действия предпринять если несмотря на ваши усилия проект подвергнется воздействию риска. Назначьте для каждого элемента риска, которым намереваетесь управлять, ответственное лицо и определите сроки исполнения действий по смягчению. Долгосрочные или сложные элементы риска могут потребовать ступенчатой стратегии минимизации риска с массой промежуточных целей. Планирование управления риском Список факторов риска — не то же самое, что план управления риском. Для малого проекта вы можете включить свои планы управления риском в план управления проектом разработки ПО. Для большого проекта необходимо написать отдельный план управления риском, формулирующий предполагаемые подходы для выявления, оценки, документирования и учета риска. Этот план должен включать распределение ролей и обязанностей в действиях по управлению риском. Для многих проектов назначается менеджер по управлению риском, который отвечает за все, что может пойти не так. В одной компании такого сотрудника называли «Иа-Иа», в честь печального персонажа из «Винни-Пуха», который постоянно горевал о том, как все может быть плохо. Ловушка. Не предполагайте, что фактор риска под контролем просто потому, что вы его обнаружили и выбрали действия по его смягчению. Эти действия нужно еще выполнить. Выделите достаточное время на управление риском в расписании проекта, чтобы не потратить впустую усилия, затраченные на планирование управления риском. Предусмотрите действия для смягчения риска, составление отчетов о статусе риска и обновление списка элементов риска в вашем списке задач по проекту. Установите периодичность мониторинга риска. Не упускайте из вида примерно десять факторов риска с наибольшим коэффициентом и регулярно оценивайте эффективность методов по смягчению. Когда действие по минимизации завершено, заново оценивайте вероятность и влияние соответствующего риска, а затем в соответствии с результатами обновляйте список факторов и остальные текущие планы по смягчению. Риск не обязательно взят под контроль просто потому, что выполнены действия по его минимизации. Вам нужно понять, снизили ли эти методы подверженность до приемлемого уровня и не осталась ли вероятность, что отдельный элемент риска перерастет в проблему. Не под контролем Менеджер проекта однажды спросил меня, что делать, если одни и те же пункты остаются в его еженедельном списке главных пяти факторов риска из недели в неделю. Это предполагает, что действия по минимизации воздействия этих элементов либо не исполняются, либо не эффективны. Если это так, то подверженность рискам, которые вы активно стараетесь взять под контроль, будет уменьшаться. В этом случае более значимыми и требующими вашего внимания становятся элементы риска, представлявшие меньшую угрозу, чем пять главных. Периодически проводите переоценку вероятности материализации угрозы каждого элемента риска и потенциального ущерба от этого, чтобы понять, насколько результативны ваши действия по смягчению риска. Риск, связанный с требованиями Факторы риска группируются по принадлежности к основным этапам конструирования требований: выявлению, анализу, документированию, проверке и управлению. Выявление требований Образ и границы проекта. Расползание границ становится более вероятным, если у лиц, заинтересованных в проекте, нет ясного, единого мнения о том, что продукт должен из себя представлять (и не представлять) и делать. Начиная проект, составьте документ об образе и границах, который содержит ваши бизнес-требования, и используйте его при выработке решений о принятии или изменении требований. Время, затраченное на разработку требований. Жесткие сроки проекта часто заставляют менеджеров и клиентов пренебрегать составлением требований; они считают, что если программисты не начну работать над кодом немедленно, то не закончат вовремя. Проекты широко варьируются в зависимости от размера и класса приложения (например, информационные системы, системное ПО, коммерческие или военные), но по самым грубым прикидкам стоит расходовать 10-15% ресурсов проекта на действия по разработке требований. Записывайте, сколько усилий понадобилось в реальности на разработку требований к каждому проекту, чтобы иметь возможность оценить, достаточно ли этого, и улучшить планирование следующих проектов. |