Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга
 Скачать 37.95 Mb.
| Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
Полное содержание архива WinRAR ZIP archive.zip: Глава 2. Требования с точки зрения клиента 29неблагоприятного будущего. Избежать этого помогает ясное и полное обсуждение целей и ограничений проекта. Возможно, действитель- ность не удовлетворит никого, но у людей появится возможность по- нять и подстроиться под нее. Для сглаживания всех конфликтов тику необходимо взаимодействовать с полномочными представителя- ми пользователей и менеджеров. Сотрудничество клиентов и разработчиков Отличные программные — результат правильно реализован- ной архитектуры, основанной на требованиях, полученных в результа- те эффективного, то есть тесного взаимодействия разработчиков и клиентов. Слишком часто сотрудничество разработчиков и клиентов оборачивается враждой. Напряженность также создают изменяющие требования пользователей по собственному усмотре- нию. В этом случае не выигрывает никто. Совместная работа возможна только тогда, когда все участники процесса разработки знают, что именно необходимо им для успеха, и когда они понимают и уважают стремление их соратников к успеху. гда при работе над проектом нагнетается напряжение, очень легко за- быть, что у всех участников единая цель — создать успешный про- граммный продукт, ценный для бизнеса и отвечающий чаяниям всех участников проекта, о правах клиента ПО» содержит на выполнении которых клиенты могут на вполне законных основаниях настаивать при общении с аналитиками и разработчиками на этапе формулирования требований к проекту. Каждый пункт этого права описывает соответствующую ответственность аналитиков и разработ- чиков ПО. «Билль об обязанностях клиента (табл. 2-2), содержит 10 положений, определяющих ответственность клиента пе- ред аналитиком и разработчиком на этапе формулирования требова- ний. его стоит назвать «Билль о правах разработчика». Перечисленные ниже права и обязанности распространяются непо- средственно на клиентов в случае, когда программный продукт разра- батывается для внутрикорпоративного использования, на заказ или для определенной группы крупных клиентов. При разработке продук- тов для массового рынка интересы клиентов представляют сотрудни- например, отдела маркетинга. В процессе планирования проекта клиенту и разработчикам следует изучить оба этих списка и постараться достигнуть взаимопонимания, 30 Часть I. Требования к продукту: что, почему и кто Сильно занятые клиенты, возможно, предпочтут не принимать участия в формулировании требований (то есть попытаются избежать ности № 2). Однако мы знаем, что в этом случае значительно ется риск создания продукта ненадлежащего качества. Убедитесь, основные участники процесса формулирования требований понимаю г и принимают свои обязанности. В случае затруднений организуйте семинар и обсудите спорные пункты. Это позволит избежать трений позже, когда одна сторона будет ожидать чего-то, что другая не может или не желает предоставить. Таблица Билль о правах клиента ПО при формировании требований Клиент имеет право Иметь дело с который на вашем языке 2. Иметь дело с хорошо изучившим ваш бизнес и цели, для которых создается система 3. чтобы аналитик преобразовал требования, предоставленные вами в письменную спецификацию требований к программному продукту 4. Получить от аналитика подробный отчет обо всех рабочих продуктах, созданных в процессе формулирования 5. На уважительное и профессиональное отношение к вам со стороны аналитиков и разработчиков 6. Знать о вариантах и альтернативах требований и их реализации 7. Описать упрощающие работу с продуктом 8. Изменить требования или разрешить использование имеющихся программных компо- нентов Э. Получить исчерпывающие о сумме ожидаемом и необходимых которые возникают в связи с изменениями в ПО Потребовать, чтобы система функциональностью и качеством удовлетворяла заказчика Таблица 2-2. Билль об обязанностях клиента ПО при формировании требований Клиент обязан Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса 2. Потратить столько времени, сколько необходимо, на требований 3. Точно и конкретно описать требования к системе 4. Принимать своевременные решения Глава 2. Требования с точки зрения клиента , Таблица 2-2. Билль об обязанностях клиента ПО при требований Клиент обязан 5. Уважать определенную разработчиком оценку стоимости и возможность реализации ваших 6. приоритеты требований 7. Просматривать документы с требованиями и оценивать прототипы 8. Своевременно сообщать об изменениях требований 9. Поддерживать принятый в порядок контроля изменений Уважительно относиться к методам, с помощью которых аналитики создают требования Ловушка Не предполагайте, что участники проекта интуитивно знают, как со- трудничать при формулировании требований. Потратьте время и обсудите, каким образом организовать взаимодействие наиболее Билль о правах клиента ПО Право № Иметь дело с который разговаривает на вашем языке При обсуждении требований следует выяснить потребности и задачи вашего используя при этом принятую в вашем бизнесе тер- минологию. Заставьте аналитиков говорить с вами на вашем языке (возможно, для этого им следует предоставить небольшой не продирайтесь в с ними через компьютерный жаргон. Право № 2. Иметь дело с который изучил ваш бизнес и цели Выявляя аналитики смогут лучше понять задачи вашего бизнеса и осознать, какое место уготовано создаваемому ПО в вашем бизнесе. Это поможет им удовлетворить ваши ожидания. Пригласите разработчиков и аналитиков к себе в офис. Если заказанная система заменит существующее приложение, предложите разработчикам по- работать с ним. Таким образом, им будет легче понять его сильные и слабые стороны и то, как его можно усовершенствовать. 32 Часть I. продукту: что, почему и кто Право № 3. чтобы аналитик преобразовал предоставленные вами устно, в письменную спецификацию требований к ПО Аналитик отсортирует всю информацию, предоставленную вами и гими клиентами, и выявит на основе бизнес-требований, вил, функциональных требований, целей качества, возможных и прочих элементов область Конечный итог анализа — спецификация к программному обеспечению (software requirements specification, SRS), представляющая собой глашение между разработчиками и клиентами о функциях, качестве и ограничениях создаваемого продукта. Она должна быть организована и написана так, чтобы вы ее легко поняли. Если вас что-то не устраива ет, выскажите свое мнение: документ должен точно и полно отражать ваши нужды и чаяния. Право № 4. Получить подробный отчет обо всех рабочих продуктах, созданных в процессе формулирования требований Аналитик может представить требования с помощью различных диа' грамм, дополняющих текст спецификации требований к обеспечению. В главе рассматриваются несколько моделей анали' за. Альтернативные представления требований очень важны, иногда графики позволяют яснее выразить некоторые особенности ведения системы, например последовательность выполняемых вий. И хотя эти диаграммы могут показаться непривычными, понять несложно. Попросите аналитика объяснить назначение каждой из (а также других продуктов, созданных в процессе формулирования требований), смысл обозначений и процедуру проверки диаграмм предмет ошибок. Право № 5. На уважительное и профессиональное отношение к вам со стороны аналитиков и разработчиков Если клиенты и разработчики не понимают друг друга, требований может обернуться большим разочарованием. работа позволяет открыть друг другу глаза на проблемы, с которым сталкивается каждая из этих групп. Клиенты, участвующие в выработки требований, имеют полное право требовать от и разработчиков уважительного отношения к себе и бережного шения к затраченному времени. В свою очередь, и клиентам следует оказывать уважение разработчикам, они все вместе сотруднича- ют для достижения общей цели — успешного проекта. Глава 2. Требования с точки зрения клиента 33 Право № 6. Знать о вариантах и альтернативах требований и их реализации Чтобы гарантировать, что новая система не будет автоматизировать неэффективные или устаревшие процессы, аналитик должен знать, почему существующие системы не годятся для ваших бизнес-процес- сов. Аналитики, основательно разбирающиеся в предметной области бизнеса, иногда предлагают те или иные усовершенствования ваших бизнес-процессов. Полезен и аналитик, творчески подходящий к делу: он предлагает новые возможности программы, о которых пользовате- ли даже и не мечтали. Право № 7. Описать характеристики, упрощающие работу с продуктом Вполне что аналитики спросят вас о характеристиках ПО, выходящих за рамки функциональных потребностей пользователей. Благодаря им программный продукт становится более удобным в ра- боте, что позволяет клиентам эффективнее выполнять их задачи. Ино- гда пользователи просят, чтобы продукт был надеж- ным или эффективным, однако эти термины слишком субъективны, чтобы помочь разработчикам. Поэтому аналитик должен выяснить конкретные характеристики, означающие для вас дружественность, надежность или эффективность. Подробнее — в главе Право № 8. Изменить требования или разрешить использование имеющихся программных компонентов Отношение к требованиям должны быть гибкими. Аналитику могут быть известны готовые программные компоненты, которые практиче- ски полностью удовлетворят некоторые названные вами потребности. В таком случае вам следует скорректировать отдельные требования, чтобы разработчики могли использовать имеющееся ПО. Разумные возможности применения существующих модулей сэкономит время и деньги. Если вы посчитаете разумным включить в свой про- дукт готовые коммерческие компоненты, будьте готовы проявить гиб- поскольку характеристики таких компонентов ли будут точ- но соответствовать вашим потребностям. Право № 9. Получить исчерпывающие сведения о сумме ожидаемом эффекте и необходимых компромиссах, которые возникают в связи с изменениями в ПО что один дороже другого, разные люди делают разный выбор. Для принятия правильных бизнес-решений необходимы 34 Часть I. Требования к продукту: что, почему и кто об эффективности и стоимости предполагаемого изменения требований. У вас есть право ожидать от аналитиков добросовестной оценки эффекта, затрат и компромиссов. Разработчики не должны за- вышать предполагаемую стоимость изменения только потому, что не хотят его реализовывать. Право № 10. Потребовать, чтобы система функциональностью и качеством удовлетворяла требования заказчика Такого завершения проекта желают все, однако он возможен, только если вы сумеете донести до разработчиков всю информацию, поможет им создать подходящий продукт, и если разработчики четко изложат вам все варианты и ограничения. Убедитесь, что вы высказа- ли все свои ожидания и предположения; в противном случае програм- мисты, скорее всего, не смогут реализовать их. Билль об обязанностях клиента ПО Обязанность № Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса Только вы можете полноценно познакомить разработчиков с циями и терминологией своего бизнеса. Вам не надо делать аналити- ков экспертами в предметной основная задача — помочь им понять ваши проблемы и цели. Не ожидайте, что аналитики нюансы и неявные особенности бизнеса. Скорее всего у них нет ний, воспринимаемых вами и вашими коллегами, как должное. сказанные предположения о таких знаниях могут вызвать проблемы в дальнейшем. Обязанность № 2. Потратить столько времени, сколько на объяснение требований Клиенты — занятые люди, и те, кто участвует в формулировании тре- бований — обычно самые занятые из них. Тем не менее вы обязаны потратить время на участие в совещаниях, штурмах, интер- вью и прочих процедурах, необходимых для выявления Иногда аналитик считает, что понял вашу идею, а позже сообразит, ему необходимы дополнительные разъяснения. Пожалуйста, во относитесь к такому поэтапному подходу к формулированию и про- яснению требований; это — природа сложного человеческого ния и ключ к успеху. Терпимо относитесь к глупым, на ваш взгляд, во- просам; хороший аналитик задает вопросы, которые заставляют говорить. Глава 2. Требования с точки зрения клиента Обязанность № 3. Точно и конкретно описать требования к системе Весьма заманчиво оставить требования неопределенными и нечетки- ми, ведь подробности так утомительно и долго. Тем не ме- нее на каком-то этапе разработки участникам проекта необходимо устранить все неоднозначности и неточности. Вам, как клиенту, и кар- ты в руки. В противном случае угадывать, что же именно вам будут разработчики. В спецификации требований к программному обеспечению реко- мендуется использовать пометки (to be determined — необхо- димо определить), указывающие на необходимость дополнительных исследований, анализа и информации. Тем не менее иногда такие мар- керы используют в случаях, когда конкретное требование трудно опре- делить точно и никто не хочет с ним возиться. Попытайтесь прояснить цель каждого требования, чтобы аналитик мог точно выразить его в спецификации требований к ПО. Если точное определение невозмож- но, выработайте совместно процедуру, которая позволит достичь не- обходимой ясности. Зачастую в таких случаях применяют метод прототипов — когда вы совместно с разработчиками формулируете требования поэтапно и постепенно. Обязанность № 4. Принимать своевременные решения Точно так же, как и подрядчик при строительстве дома, аналитик за- даст вам множество вопросов и попросит выбрать различные вариан- ты и принять решения. Это может быть согласование противоречивых запросов от разных клиентов, выбор между конфликтующими атрибу- тами качества и оценка точности информации. Клиенты, обладающие соответствующими полномочиями, должны принять эти ко- гда их об этом попросят. Зачастую работа стопорится, так как клиент не может принять окончательного решения, и поэтому, медля с отве- он затягивает работу над проектом. Обязанность № 5. Уважать определенную разработчиком оценку стоимости и возможность реализации ваших требований Все программные функции чего-то стоят. Разработчики лучше всего способны оценить эту стоимость, хотя многие из них и не имеют опыта в этом деле. Может оказаться, что некоторые необходимые вам функ- ции технически неосуществимы или их реализация слишком дорога, например недостижимая в рабочей среде производительность или доступ к данным, которые системе просто недоступны. Даже све- 36 Часть I. Требования к продукту: что, почему и дения об осуществимости и стоимости некоторых функций, ные вам не понравятся, следует уважать эту оценку. Иногда требования можно изменить так, что они станут дешевле и достижимее. Например, «мгновенное» выполнение операции реализс - нельзя, однако вполне по силам задать минимальный интервал (скажем, «в пределах 50 Обязанность № 6. Определять требований Лишь при работе над ограниченным кругом задач можно время и ресурсы для реализации всей желаемой Определить, какие возможности необходимы, какие полезны и без ких пользователи обойдутся, — важная составляющая анализа ваний. Именно вы определяете эти приоритеты, поскольку разработ- чики не в состоянии расставить приоритеты. Чтобы вам облегчить за- дачу, разработчики предоставляют информацию о стоимости и всех требований. Определив приоритеты, вы поможете кам вовремя и с минимальными затратами создать максимально эф- фективный продукт. Обязанность № 7. Просматривать документы с требованиями и оценивать прототипы Как говорится в главе 15, просмотр требований — одна из значимых операций, обеспечивающих качество ПО. Участие в таких просмотрах — единственный способ узнать, отражены ли требности клиента наиболее полно и точно. Если клиенты не уверены <з точности задокументированных требований, им следует как можно раньше сообщить об этом лицам, ответственным за реализацию бований, и предложить варианты усовершенствования. Читая спецификацию требований, не всегда удается четко вить работу программы. Чтобы лучше понять потребности клиента выявить оптимальные способы их удовлетворения, разработчики гда создают прототипы предполагаемого продукта. Ваша ответная ре- акция на эти предварительные, частичные или пробные версии разработчикам необходимую информацию. Поймите, что прототип является рабочим продуктом, и не давите на разработчиков. Обязанность № 8. Своевременно сообщать об изменениях требований Постоянное изменение требований — серьезная угроза для возмож- ности своевременной сдачи проекта командой разработчиков. Изме- нение неизбежно, но чем позже в ходе разработки о нем  перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
