Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 39
Текст из файла (страница 39)
В кзждолл новом проекте был новый лидер. Это создавало возможности для профессионального роста сотрудников. Данная роль стала одной из главных в компании. И конечно, не следует забывать о ССВ. В каждом новом проекте создавался ССВ, в который входили представители различных отделов, в зависимости от содержания каждой новой версии и то. го, па какие организации она будет оказывать непосредственное влияние. Ховш не суигествуее общих предтгсоний, коннузым мохсно смдовангь аунг выйо)гелидера юую.
егта, дгя козодой команды чугзвычайно важно найпш его, поддгржангь или наделить полномочиями того, кнш узке фактически паол лиде)лом. После етого задача команды сосошит во всесмоРонней помощи лидеру в углРовлпиги н~Угебовсипшми к п)знлохсению. Эош поможет дой)сальса успеха. Кстати, если вы не помогаете этому человеку, оп может предложить вам быть лидеролг в следующем проекте. 190 Часть 3.
Определение системы В части 3 мы начали переход от понимания потребностей пользователя к определе нию решения. При этом мы сделали свои первые шаги из области проблемы, вотчины пользователя, в область решения, где нашей задачей является определить систему для решения имекзщейся проблемы. Мы поняли, что для сложных систем требуются всеобъемлющие стратегии управления информацией о требованиях, и рассмотрели несколько способов ор~анизации дак. ной информации, Оказалось, что на самом деле существует информационная иерархия, которая начинается с потребностей пользователей, переданных с помощью функций, а затем превращается в более подробные требования к программному обеспечению, выраженные посредством прецедентов или традиционных фора~ описания.
Мы также отметили, что эта иерархия отражает уровень абстракции при рассмотрении области проблемы и области решения. После этого мы рассмотрели процесс определения отдельного программного прнло. жения и затратили некоторое время на определение документа. концепции для приложо ния такого типа. Мы считаем, что докусиент-концепция, модифицированный в соответ стяни с конкретным содержанием программных приложений компании, является чрезвычайно важным, и его необходимо иметь в вождам проекте. Мы также осознали, что без лидера — человека, который будет защищать требования к приложению н поддерживать потребности клиента и команды разработчиков — нельзя быль уверенным в том, что будут приняты необходимые жесткие решения.
Вероятно возникнове. нне дрейфа тресюваиий, задержек, а также принятие неоптимальных решений, вызванное приближением срока окончания проекта. Поэтому мы решили назначить лидера, который бу дет владеть документом-концепцией и содержащимися в нем фзнкциями. В свою очередь, лн. дер и команда должны создать совет по контролю за изменениями, который призван помогать лидеру в принятии действительно сложных равнений и гарантировать, что изменения требований будут приниматься только после их обсуждения. Вооружившись методом организации требований (с лидером во главе), мы теперь лучше подготовлены к предстоя~ней работе.
Но сначала нам нужно рассмотреть проблему лкимэшба проекта, которой посвящена часть 4. 192 Часть 4. Управление масштабом К этому моменту мы уже ознакомились с приемами, используемыми для анализа проблемы, поник~авив потребностей пользователя н определения системы. Все опи направлены на устранение основной причины возникновения проблем при разработке программного обеспечения: при переходе к области решения команда не имеет адекватного представления о реп~асмой проблеме Конечно же, членам команды необходимо попрактиковаться в использовании этих приемов, чтобы полностью овладеть ими, однако это не потребует чрезмерных усилий. Мы настоятельно рекомендуем потратить чуть больше времени на это в начале жизненного цикла проекта; затраты на все действия, описанные до сих пор, составят только малую часть выделенных на проект средств (5% или около того).
Несмотря на сложность рассматриваемых вопросов, до настоящего момента их решением серьезно занимались только несколько членов команды (аналитики, менеджер проекта, технический руководитель, менеджер продукта/лидер проекта). Далее, однако, правила игры кардинально меняются, так как команда значительно увеличивается. Все новые ее члены должны участвовать в общих координированных действиях н общаться друг с другом.
Кроме того, затраты также существенно возрастают. Мгя создаем документы для планов тестирования, строим модели архитектуры, уточняем требования, дорабатываем прецеденты и разрабатываем программный код, тем самым создавая объем работы, которую придется менять, если определение не будет правильно понято илн изменятся внешние требования. Форма пирамиды требований, которая становится гораздо шире у основания, наглядно отражает тот факт, что нам предстоит гораздо болыпе работы. Часть 4 посвящена разработке стратегии управления масштабом.
О важности этой деятельности говорит следуюгпее. Со гласно результатам исследований группы Стендиша (1994), "затраты на 54% проектов оудуг составлять 189% от запланированных". Наш опыт свидетельствует, что практически все про. гразмшые проекты будут ззвершены с опозданием; коэффициент запаздывания составит 50— 100%. Из этого можно сделать вывод или о недостаточном уровне компетентности в нашей отрасли, или о том, что мы пытаемся сделать слишком много с помощью недостаточных ресурсов, навыков и средств. Мы пытаемся впихнуть десятифунтовые функции в пятифунтовый портфель. Хотя физика процесса разработки программного обеспечения еще не ясна, очевидно, что этот элемент нашей стратегии ведет к неприятностям, и от этого зависит как качество наших продуктов, так и наша реп)тания. Поэтому, л)магде чсв расширять команду, разрабатывать более подробные спецификации, окончательно 9юрмулировать технологические идеи проектирования н создавазь сценарии тестирования, следует остановиться и научиться уироеллть мааияюйм н~юекякь 11емного психологии, немного технологии и немного просто хорошего управления проектом — и вы овладеете этим приемом, что значительно повысит вероятность успешного завершения проекта.
Глава 19 Проблема масштаба проекта Основные положении !й Масштаб проекта определяется набором функций продукта,' ресурсамн ' проекта и выделенным на него временем. ' ° Закон Брукса (Вгоо!ск) гласит, что привлечение дополыительной рабочей ~ силы к запаздывающему проекту приводит к еще болыпему запаздыванию. ',: ° Если объем работ, необходимый для реализации фуыкцнй системы, равен ,' имеющимся ресурсам, умноженным па выделеывое время, проект имеет достижимый масштаб.
И Слишком маспктабные проекты типичны для отрасли. И Во многих случаях, чтобы иметь возможность успешно заверппкть проект,: пеобкодимо сократить его масштаб, как минимум, вдвое. Составляющие масштаба проекта Как и в любой профессиоыальыой деятельности, приступая к разработке приложения, необходимо сначала произвести реалистическую оценку ресурсов проекта, выделенного времени и поставленных целей.
При разработке программного обеспечения зти факторы задают "масштаб" проекта, который определяется следующими переменпымн. ° Набором функций, которые необходимо предоставить для удовлетворения по- требностей пользователей. ° Ресурсамы, которыми располагает проект. ° Временем, выделенным ыа реализацию. На рис. 19.1 изображен "прямоугольник", который мы можем использовать для представления масштаба проекта.
Время А Срок скача Рис. 19.1. Маааамб араеаака 194 Часть 4. Управление масштабом Площадь прямоугольника на рисунке представляет достижимый масштаб проекта. Его определяют следующие элементы. ° Ресурсы, состоящие в основном из труда разработчиков, тестологов, составителей руководств, персонала отдела обеспечения качества н др. Еще в 1970.х годах Фред Брукс (Егег( Вгоо)гз) (1975) показал, что предложение до. бавнть рссурсы в программный проект с целью увеличить отдачу является, в лучшем случае, рискованным.
Закон Брукса гласит, что дополнительное привлечение рабочей силы к запаздывающему программному проекту приведет к еще большему его запаздыванию. Если временная шкаэа достаточно протяженная, то результат может действительно возрасти. Но ои ие возрастет пропорционально добавленным ресурсам; таким образом, общая эффективность проекта снизится.
Добавление ресурсов может даже замедлить проект, так как необходимость обучать и поддерживать новых сотрудников снижает производительность тех, кто уже был занят в проекте. По мере того как условия конку. реицнн иа рынке побуждают пас сокращать сроки разработки, добавление ресурсов в ходе работы над проектом практикуется все реже и реже. Для целей анализа масштаба предположим, что ресурсы, откладываемые по оси у (рис. 19.1), являются постоянными во время выполнения проекта. ° В)уемя.
Возможно, здесь мы нлгеем "мягкое" ограничение, которое подвержено изменениям, если наличные ресурсы недостаточны для достижения желаемых функциональных возможностей. Но при анализе масштаба мы будем считать время, откладываемое по оси х, фиксированным фактором. К сожалению, предоставление программ с опозданием является "нормальным явлением". Но с др)той стороны, многие приложения имеют жесткие фиксированные сроки сдачи. Примерами могут быть новая программа начисления налогов, которая должна быть представлена ко времени начала периода налогообложения, демонстрация нового продукта, приуроченная к торговой выставке, или огово. рснный контрактом с заказчиком срок сдачи. Кроме того, если мы хотим доказать свою профессиональную состоятельность и завоевать доверие наших клиентов, очень важно ие ошибиться в графике. Набор функциональных воэможностей, который мы в состоянии создать, естественным образом ограничен временем (фиксированным), выделенным иа реализацию, и доступными ресурсами (также фиксированными).
Поэтому достижимый масштаб пред. ставляет собой площадь прямоугольника. В данной книге мы использовали понятие "функции (геагпгез) для обозначения до. полннтельпых функциональных возможностей, которые мы должны предоставить поль. зователю. Если необходвмыгу для Реалвзацгги ягребуемых функций обзсм )забою (Уаапг имеюгиимся )Уесу)гсалг, умяолсеюгы.гг иа выделенное время, масгатаб я~юекта яаглеикя достизсимым и п)Уоблся не еознвкаегл, В этом случае, за исключением непредвиденных обстоятельств, ко. луанда создаст программу вовремя н без потери качества. Однако опыт свидетельствует, что зачастую части в уравнении масштаба отнюдь не равны.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
