Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 37
Текст из файла (страница 37)
Может оказаться, что некоторые ре»тизованные в версии 1.0 функции не достигают поставленной цели (воз»»ажно, иэ.эа того, что внев»няя среда изл»спилась эа время разработки и фунт»ия балыке не нужна или должна быть заменена новой, либо иэ-за того, что она просто не нужна клиентам, хотя опп предполагали обратное). В любом случае скорее всего обнар)- жится, что в след)чащей версии некоторые функции необходимо удалить. Как отразить этн "антитребования"? В данной ситуации нужно просто испольэовать документ.ко»»цепцию для указания того, что определенная функция должна быль удалена иэ следующей версии.
В процессе работы документ постоянно растет. Это естественно, так как он определяет растущую систему. К сожалению. может случиться, что со временем документ будет все труднее читать и понимать. Почему? Потому, что он теперь гораздо длиннее и содержит множно информации, которая не претерпела изменений со времени предыдущей реализации. Например, определение позиции продукта и целевые пользователи, скорее всего, остал»юь неизменными, как и 25-э0 функций, реализованных в версии 1.0, которые сохрапилнсь в документе-концепции версии 2.0. Поэтому мы предлагаем вести дохумвн»н изменений конке»»иии 11Уейа Уи»ол доги»лен»).
В нем отражается только то, что измени»ось, а таххсе любая другая »»нфоРмац»»я, нови»Рую слсдугв» включить для ясности. Эта информация включается для того, чтобы напомнить команде концепцию проекта илн полючь йе»1амн» войти в курс дела новым членам команды. В результате получается документ изменений, в котором основнов беев Язов »2.0 внимание уделяется н»ему, что нового включено в данную версию и что отлнчоеш ев от»»рвдыду»»»их версий. При работе со сложными системами информации полезно применять данный метод, который позволяет схоние»»тр»»рован»ь внимание на н»ом, что изменилось. Воспользовавнп»сь им, мы получаел» модель, представленную на рис.
17.3. Глава 17. Докумеивчсоицепция 183 Общая кврактернстни т Функции версии 1.0 т Будущие фуеции Ясеобщш котка отощщ Докуыент- конодпцня 1.0 Новые функции т Удленные функции т будущие функции Оеяв Чввж2.0 и Попков определение продукта 1Ъс. к 7.3. Дат)ымнш ккейа Иваси ДОКУМЕНТ ЭЕ12а'Ут'101ОН ДЛЯ УжЕ СУЩЕСтВУЮЩЕй СИСТЕМЫ Крайне редко практикуется документирование полных требований крупномасштабной существующей системы. Одна из сложнейших проблем при управлении требованиями состоит в применении методов управления трсоованиями к эволюции существующих Б/1Т-систем.
Крайне редко существуют полные и адекватные спецификации требований для лтиллионов строк ° Докуменгконцепция 1.0 является вгвобыаыющсй тонкой оикчеикт; здесь представлено все, что необходимо знать о нашем проекте. ° 1)е1ка ЧЬ)оп 2.0 определяет то, что отличает данную версию. ° Объединение этих двух документов задает нолнсе оярвдкксние я)уодукнш. Следует использовать обе версии вместе, если согласно требованиям заказчика или регулирующих инструкций необходимо предоставить полное определение продукта. Их совместное использование, несомненно, полезно для новых членов команды. Однако в этом случае приходится читать о функциях версии 1.0, которых уже нет в версии 2.0, так как онн были позднее удалены, и нужно всегда отслеживать эти изменения при воссоздании полного определения.
Если это необходилто, можно достаточно просто соединить содержимое документакоицепции 1.0 и 1)е1та 2.0 в новый документ-концепцию 2.0, который представляет все. объемлющую и полную картину проекта. Не существует строгих правил относительно определений этих документов или того, что каждый из них содержит. В других обстоателыгвах может оказаться удобным испольэовать Ре!та УЫоп только при относительно небольших модификациях (таких, как версии 1.1 и 1.2) и начинать все сначала и переслтатривать определение продукта в целом для каждой крупной реализации 1версии 2.0 или 3.0). В любом случае применение документа 1)е!ка ЪЪюп поможет лучше справиться с процессом управления требованиями, тзк как позволит команде сконцентрироваться на "том, что действительно важно" на каждом конкрептом этапе. 184 Часть 3.
Определение системы кода и сотен чсловско-лет трудозатрат, отражснисм которых являются эти системы. Тмжс непрактично останавливаться н повторно документировать прошлое. При этом можно упустить время и нс выполнить свою задачу, записывая исторические требования тогда, когда следовало писать код! Таким образом, если приходится начинать с нуля или с минимальной документации, следует использовать все имеющиеся в ващем распоряжении ресурсы (программный код, спецификации, знания членов команды о предыстории), чтобы прийти к пониманию того, что система делает в настоящий момент. Затем мы рекомендуем применить процесс создания Ве!га 'тЬ1оп и задать функции и прецеденты, описывающие пэмененял, которые вы собираетесь вносить в существующую систему.
Следуя этому процессу, можно сконцентрироваться на том, чюо гшвого в данной реолшании и чяю отличает ее от ггредыдугйих умалкэайий; в результате ваши закаэчики и команда получат несомненную пользу от хорошо организованного процесса управления требованиями. Кроме того, созданныс вами записи требований будут служить документацией для ваших последователей. Глава 18 Лидер продукта Осиовиые положения : И Лидер продукта отвечает за концепцию проекта.. ° Каждому проекту нужен лидер или небольшая лидирующая группа для за- ' щиты интересов продукта. ' ° При разработке программных продуктов лидером часто является представитель маркетинга.
В главе 1 мы проанализировалн проекты, в которых возникли затруднения, и выявили множество разнообразных причин этого, причем управление требованиями оказалось в верхней части списка. В главе (7 мы определили документ-концепцию как ключевой документ сложного жизненного цикла программы.
Он непосредственно ориентирован па рея|ение проблемы требований н является единственным документом, к которому зюжно обратиться в любой момент, чтобы увидеть, что продукт, приложение или система должны делать, а что не должны. В целом документ-концепция представляет суть пр<» дукта, и его необходимо защищать так, как если бы весь успех проекта зависел от него (потому что яюк оно и есть). В некоторый момент возникает закономерный вопрос: "Кто же разрабатывает и поддерживает этот исключительно важный документ? Кто управляет ожиданиями заказчика? Кто ведет переговоры с командой разработчиков, заказчиком, отделом маркетинга, менеджером проекта и руководством компании, которое проявило такой интерес к проекту именно теперь, когда подходит срок сдачи?".
Практически в каждом успешном проекте (от машинок для аттракционов до систем искусственного дыхания, которые спасли десятки тысяч жизней, пе допустив ни единого сбоя программного обеспечения), которым мгл занимались, был лидер. Мы можем оглянуться на эти проекты и указать некоего человека или (в случае более крупного проекта) небольшую группу из нескольких человек, которые играли роль, "большую, чем жизнь", Лидеры ставят концепцию продукта (системы или приложения) во главу угла, как будто зто самое важное в их жизни.
Они думают о ней постоянно, за едой и во время сна. Роль лидера продукта Лидером продукта может быть кто угодно: менеджер продукта, менеджер проекта, менеджер по маркетингу, менедхсер проектирования, менеджер информационных технологий, руководитель проекта. Однако название должности в данной ситуации не имеет никакого значения; обязанности одинаковы.
И они достаточно велики. Лидер должен заниматься следующим. 186 Часть 3. Определение системы ° Руководить процессом выявления требований и успокаиваться лишь тогда, когда обнаружено достаточное их количество. ° Рассматривать конфликтующие пожелания, поступакнцие от различных участников. ° Находить компромиссы, необходимые для определения набора функций, пред- ставляющих наибольшую ценность для максимального числа участников.
° Владеть концепцией продукта. ° Защищать интересы продукта. ° Вести переговоры с руководством, пользователями и разработчиками. ° Противодействовать "просачиванию" функций. ° Поддерживать "здоровое равновесие" между тем, чего хочет заказчик, и тем, что может предоставить команда разработчиков за время, отведенное для реализации. ° Выступать в роли представителя официального канала общения между заказчиком и командой разработчиков.
° Управлять ожиданиями клиентов, исполнительной дирекции и внутренних отде- лов маркетинга и проектирования. ° Сообщать о реализуемых функциях всем заинтересованным лицам. ° Осуществлять проверку спецификаций программного обеспече. ния, чтобы удостовериться, что они соответствуют истинной концепции, представленной функциями. ° Осуществлять управление изменением приоритетов, а также добавлением и исключением функций. Это единственный человек, которому действительно можно доверить судьбу документа-концепции, и выбор "правильного" лидера может оказаться ключом к >спеху проекта. Лидер продукта в среде программных продуктов Однажды мы проводили семинар для провайдера интерактивных услуг, который сник.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
