Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 11
Текст из файла (страница 11)
! (сна акции нснадолго поднялась до 255 нрон|лой весной на волив новых заказов, цо затсм вновь опустилась ло 153. В отрасли, которая занимается созданном оборудования для тсатров, в цслол| мало новых раэраооток. данная отрасль являстся >стоявшсйгя н вссьма консолидированной. Поскольлу оборотныс средства кол|нации !.шпсца>!оцз ограничсны, а капитализация вссьма умсрсина, нриобрстснис лр>той компании в данном случас нс являстся выходом. '1то дсйствнтсльно нужно — это новая нозпцня на рыжко сбыта, ис очснь отличающаяся от того, в чсм спсциалнзирустгя компания, но где сгть простор для роста дохода и прибыли.
Проведя тщатсльнос нсслслованис рынка и истратив нсмало грсдгтв на консультации по маркстингу, компания приняла рсшснис выйти на новый рынок скг. щсм авяюл|атнчвгкого асвеявннл г>ля лг| |ых лочс|бс|тй сового высокого хлнсгл. Этот рьшок растст приблизительно на 25 35% ежегодно. Ещс отраднсс то, |то этот рынок был образован нсдавио, и на нсм сщс нст постоянных игроков, занимающих домцниру|ощис позиции.
Мощныс развствлснныс но весну миру каналы дистрибьюторов будут нагтоящнм активом на рынкс, а дистрибьюторы вссгда охочи ло новых продуктов. Это прскрасная возможность! Команда разработчиков программного обеспечения НОЯБ 1!росктом, который мы выорали в качсгтвс рабочсго иримсра, оулст разработка гистсм|я П01.13 (это кодовос наимспонанис новой домащнсй сигтсмы автоматичоского уиравлсция освсщсцисм — ПОя|с 1.13Ь>н|3 юноша|!оп буз|сш), рагнрогтрацясмой комцацнсй ! цшсца>(онз, Кол|аида П01.13 имсст тшшчиыс размсры. В нащсм нримсрс она достаточно нсболыная (вссго 15 чсловск).
но этого вполнс лостато ню для того, чтобы всс нсобходим|к нрофсггиоцальпыс навыки были нрсдставлсны отдсльнымц члсцаьш комацлы с оирсдслснной стснснью сцсциализацнн их ролей. Паиболсс важна имснно структура кол|анды; ссли добавить лонолнитсльцых разработчиков и тсстологов, команда б>дст включать 30 50 иловск и сможет разрабатьц|ать пропорционально болсс обьсмныс нрограммныс прнложсння. бб Введение Для работы на новом рынке сбыта компания Ешпеиаг1опв учредила новое подразде ление, отдел автоматического управления домашним освещением. Поскольку отдел и технология являются достаточно новыми для колгпании 1.ишепагуопз, команда НО1ЛЬ, в основном, образована из новых сотрудников, хотя некоторые члены команды перешли в нее из отдела коммерческого освещения. На рис.
$.1 представлена организационная схема команды разработчиков и взаимосвязи между ее членами. Мы периодически будем возвращаться к этой схеме далее по ходу изложения, чтобы посмотреть, как команда применяет новые профессиональные навыки для рептения проблем требований и НО1.18, Организация группы преданы«рования пеярвздепв пня автоматизации дпмэшнего есвеииния компании 1инипэгппв, Ггб Рис. З.д О1лзанизацивюиы егема команды разрабгинчмнэе программного обеспечении агпнеиы НО1 Б Заключение Вряд ли кто-нибудь будет выступать против управления требованиями к системе и их документирования с целью удостовериться, что мы предлагаем клиенту именно то, что он хотел. Однако данные свидетельствуют о том, что в отрасли этому уделяется недостаточное внимание.
Недосниинан инфгфмацни от клиента, ненолтгые нцуебпватгия и шгецифихации, а тахнге изменения эфебоеаний и спецификаций наиболее часто указываются в качест. ве основных причин возникновения проблем в проектах, не достигших поставленных целей. Л число программных проектов, потерпевших неудачу в достижении намеченных целей, действительно велико. Глава 3. Команда разработчиков Бб Часто разработчики и клиенты придерживаются позиции, что "даже если мы в действительности точно нс знаем, чего хотим, лучше приступить к реализации сейчас, поскольку у нас мало времени.
Мы сможем уточнить требования позже". Но слишком часто этот продикто. ванный благими намерениями подход превращается в хаотические действия разработчиков, когда никто в точности не знает, чего в действительности хочет клиент и что на самом деле делает созданная на данный момент системз. При наличии современных мощных и простых в использовании средств построения прототипов создастся впечатление, что если разработчики сумеют создать хотя бы грубый прототип, то клиент сможет указать, какие функции нсчКг ходимо добавить, удалить или налепить.
Это можем сработать, и зто один иэ важных аспектов итеративной разработки. Но из-эа слишком высокой стоимости устранения ошибок требований данный процесс должен происходить в фамхах ойвгй сшраямгкн ул~мылеяил ифсбеаанклми, иначе результаты будут хаотичными. Как узнать, что должна делать система? Как отслеживать текущее состояние требований? Как определить, какое воздействие окажет определенное изменение? Именно нэ-эа подобных вопросов управление требованиями стало неооходимой практической дисциплиной в инженерии программного обеспечения. Мы предложили вашему вниманию основополагающую философию управления требованиями и ряд определений, поддерживающих данную деятельность.
Поскольку история развития программного обеспечения и его будущее, по крайней мере обозримое, связаны с возрастанием сложности, нужно отдавать себе отчет, что задачи разработки программного обеспечения должны рев~аться хорошо организованными н хорошо подготовленными компндоми разработчиков. В частности, в сфере управления требованиями каждый член команды будет время от времени привлекаться к разработке требований к системе. Команды должны обладать необходимыми профессиональными навыками, чтобы понимать потребности клиента, управлять масштаоом приложения и создавать системы, удовлетворяющие указанные потребности.
Команда должна работать кэк команда, чтобы решить задачу управления требованиями. Первый шаг в процессе управления требованиями должен состоять в том, чтобы удостовериться, что разработчики действительно поняли "проблему", которую пытается решить пользователь. Эта тема рассматривается в последующих трех главах, объединенных в часть 1, "Лналиэ проблемы". Часть 1 Анализ проблемы 88 Иасть К Анализ проблемы В последние годы наблюдался беспрецедентный рост возможностей средств и технологий, используемых разработчиками программного обеспечения для создания приложений в различньш современных предметных областях.
Новые языки программирования повысили уро. вень абстракции и производительность решения проблем польювателей. Применение объектноориентированных методов позволило создавать более устойчивые и расширяемые про. ектные решения. Автоматические средства управления конфигурацией, управления требованиями, проектирования и анализа, обнаружения неисправностей и автоматического тестирования помогают разрабогчикам программного обеспечения справиться с тысячами требований и сотнями тысяч строк программного кода.
Казалось бы, увеличение производительности средств разработки программного обеспечения должно существенно упростить разработку систем, удовлетворяющих реальные бизнес-потребности. Однако данные свидетельствуют, что проблегвы, связанные с правильным пониманием и удовлетворением этих потребностей, по-прежнему существуют. Возможно, этому есть простое объяснение. Команды разрабо~ачихов траэшт слишком мало времени на то, чгвобы понять тфобеемы реального иредтфиятил, потребности яоеь. зовпгвелей н других заинэмресованных лиц, а также природу яюй среды, в козырей должны функциомаРовать их приложения.
Они торопятся и предлагают технические решения, основанные на неадекватном понимании решаемой проблемы. Команды разработчиков забегают вперед, предлагая технические решения, основанные на неадекватном понимании решаемой проблемы. Полученные в результате системы не могут удовлетворить потребности пользователей и заинтересованных лиц в той мере, как ожидалось. Последствия — недостаточный экономический эффект для заказчиков и разработчиков системы и неудовлетворенность пользователей. Кроме того, это может отрицательно отразиться на репутации разработчиков.
Поэтому мы считаем, что увеличение инвестиций в анализ проблемы приведет к ощутимой финююовой отдаче. В данной части книги излагаются основные принципы анализа проблем, а также уюь зывзются конкретные цели его применения при разработке приложений. В последующих главах описывается, как точно определить, в чем состоит проблема.
Ведь без этого невозможно предложить подходящее решение, Глава 4 Пять этапов анализа проблемы Основные полоэхения ° Ананиз проблем — это процесс осознанна реальных проблем и потребно:! стей пользователей и предложения решений, позволяющих удовлетворить ' эти потребности. И Цель анализа проблемы состоит в том, чтобы добиться лучшего погшма-'.
' ння решаемой проблемы до начала разработки. ° Чтобы выявить причины (иличзроблемы,'стоящие за проблемой), необ-';,' ходпмо опросить людей, которых непосредственно затрагивает данная,' проблема. ° Выявление акторов системы является ключевым патом в анализе проблемы Эта глава посвящена тому, как команда разработчиков может осознать реальные пс» требности заинтересованных лиц н пользователей новой системы (или приложения).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
