Предисловие
Проблема камня
Одна из моих студенток назвала совокупность рассматриваемых в данной книге вопросов проблемой "камня". Она занимается разработкой программного обеспечения в исследовательской лаборатории, и ее заказчики часто предлагают ей задания, которые можно условно представить как "Принесите мне камень". Когда камень доставлен, заказчик некоторое время изучает его и говорит: "Да, но на самом деле то, что я хотел, - это небольшой голубой камень". После доставки небольшого голубого камня выясняется, что это должен быть круглый небольшой голубой камень.
Наконец, может оказаться, что заказчик все время думал о небольшом голубом кусочке мрамора или он и сам в точности не уверен, чего же он хочет, но небольшого кусочка голубого мрамора - или даже кусочка голубого мрамора, имитирующего кошачий глаз -вполне достаточно. Кроме того, его мнение о требованиях могло меняться в промежутке между доставкой первого (большого) и третьего (небольшого голубого) камня.
При каждой последующей встрече с заказчиком разработчик, как правило, вопрошает: "Чего же Вы хотите?". Разработчик недоволен, поскольку он представлял себе нечто совершенно иное, долго и трудно работая над созданием камня с ранее описанными характеристиками; заказчик также расстроен, поскольку, даже если ему и сложно объяснить, чего же он хочет, он считает, что выразил это достаточно ясно. Эти разработчики просто ничего не понимают!
Ситуация усложняется тем, что в большинстве реальных проектов принимает участие гораздо больше людей. Помимо заказчика и разработчика, которые, конечно же, могут иметь различные имена и названия, вероятно, должны быть маркетологи, специалисты по контролю качества, а также менеджеры нижнего и верхнего уровней и множество заинтересованных лиц, на чьи повседневные действия повлияет разработка новой системы.
Все они могут пострадать от проблем определения приемлемых "камней", в особенности потому, что зачастую в современном быстроменяющемся деловом мире с высоким уровнем конкуренции нет времени для того, чтобы отбросить дорогостоящий двухгодичный "проект по созданию камня" и начать все сначала. Задача состоит в том, чтобы сделать все правильно с первого раза с помощью некоего итеративного процесса, в рамках которого заказчик постепенно определяет, какой собственно камень он хочет получить.
Это достаточно сложно сделать, когда мы имеем дело с осязаемыми физическими предметами типа настоящего камня. Большинство коммерческих и государственных организаций сегодня интенсивно используют информационные технологии, поэтому, даже если они формально занимаются созданием и продажей неких "камней", с высокой степенью вероятности эти "камни" будут оснащены встроенными компьютерными системами. Даже если это не так, вполне возможно, что предприятие нуждается в тщательно разработанных системах для отслеживания продаж "камней" с помощью средств электронной коммерции, учета заказчиков, конкурентов и поставщиков, а также для хранения другой информации, необходимой для поддержания конкурентоспособности на рынке.
Системы программного обеспечения по своей природе являются неосязаемыми, абстрактными, сложными и, по крайней мере в теории, бесконечно изменяемыми. Поэтому, когда заказчик высказывает требования к "каменной системе" нечетко, он делает это, предполагая, что впоследствии сможет их уточнить, изменить и дополнить. Все было бы прекрасно, если бы разработчик и остальные участники процесса создания, тестирования, развертывания и обслуживания данной системы могли осуществлять это с нулевыми затратами времени и денег, но так не получается.
К сожалению, часто вообще ничего не получается: более половины разрабатываемых в настоящее время проектов систем программного обеспечения значительно превысили отведенное на них время и бюджет, а выполнение 25-33% проектов было прекращено, несмотря на то что уже были истрачены баснословные средства.
Цель данной книги - предотвратить подобные сбои и предложить рациональный подход, позволяющий создать систему, которую в действительности хочет видеть заказчик. Следовательно, необходимо понимать, что это не книга по программированию и она ориентирована не только на разработчиков программного обеспечения. Это книга об управлении требованиями в сложных программных приложениях. Таким образом, данная книга написана для всех членов команды разработчиков - аналитиков, разработчиков, персонала, проводящего тестирование и обеспечивающего качество, людей, осуществляющих управление проектом, разработчиков документации и т.д., а также для всех из внешней команды "клиентов" - пользователей и других заинтересованных лиц, представителей маркетинга и менеджмента. Иными словами, эта книга предназначена для всех, кто должен принимать участие в решении проблемы требований.
Оказывается, очень важно, чтобы члены обеих команд, в том числе и не имеющие отношения к технике члены внешней команды, овладели навыками, необходимыми для успешного осуществления процесса определения требований к новой системе и управления ими, хотя бы потому, что именно они изначально создают требования, а в итоге определяют успех (или неуспех) системы. Работающий в одиночку герой-программист - анахронизм, оставшийся в прошлом.
Надеюсь, никто не будет возражать, что при строительстве дома необходимо не раз посоветоваться с его владельцем, иначе можно построить дом с двумя спальнями, в то время как заказчик хотел, чтобы их было три. Но не менее важно обсудить и согласовать "требования" с властями относительно того, что касается строительных норм и регулирования застройки в данном районе; также может понадобиться проконсультироваться с ближайшими соседями, прежде чем вырубить некоторые деревья на участке, где будет расположен дом.
Инспектор по строительству и ближайшие соседи являются теми заинтересованными лицами, которые вместе с владельцем этого дома будут определять, удовлетворяет ли построенный дом всем требованиям. Понятно, что многие важные заинтересованные лица, такие как соседи и представители власти, в данной ситуации не являются пользователями (владельцами дома), также очевидно, что их представления о том, что такое качественный дом, могут существенно отличаться.
В данной книге обсуждаются программные приложения, а не дома или камни. Предъявляемые к дому требования можно, по крайней мере частично, описать посредством ряда чертежей и инженерных схем. Аналогично систему программного обеспечения можно описать с помощью моделей и диаграмм. Чертежи дома служат средством общения и переговоров между инженерами и непрофессионалами (юристами, инспекторами и соседями), точно так же связанные с программной системой технические диаграммы можно создавать так, чтобы "обычные" люди могли их понимать.
Для многих чрезвычайно важных требований диаграммы не нужны вовсе. Например, будущий владелец дома может просто написать (например, по-английски) требование, которое гласит: "В моем доме должны быть три спальни и достаточно большой гараж для двух машин и шести велосипедов". Как будет показано в этой книге, большинство критически важных требований к программной системе также можно написать с помощью естественного языка.
Многие профессиональные приемы, которыми необходимо овладеть для решения данной проблемы, также можно описать посредством практических советов на уровне здравого смысла. Строителю-новичку можно посоветовать: "Не забудьте побеседовать с инспектором по строительству до того, как начнете рыть котлован под фундамент, а не после того, как зальете его раствором и начнете возведение стен". В программном проекте уместен аналогичный совет: "Не забудьте задать правильные вопросы, определить приоритеты требований и не позволяйте заказчику говорить вам, что все 100% требований критически важны, поскольку вряд ли вы сумеете удовлетворить их все к моменту сдачи".
О данной книге
В книге Леффингуэлла (Leffingwell) и Уидрига (Widrig) выбран прагматический подход к описанию решения "проблемы камня". Книга состоит из введения и шести частей, соответствующих шести группам профессиональных приемов в сфере разработки требований. Во введении (главы 1-3) предлагаются определения и основные положения, необходимые для понимания последующего материала. В главе 1 содержится обзор возникающих при разработке систем проблем. Данные свидетельствуют, что некоторые проекты разработки программного обеспечения действительно потерпели неудачу из-за небрежного программирования, но последние исследования достаточно убедительно показали, что плохое управление требованиями само по себе может быть основной причиной провала проекта. В данном предисловии основные положения управления требованиями описаны свободно и неформально, в главе 2 авторы определяют их более тщательно, создавая основу для последующих глав. В главе 3 содержится краткое описание структуры команд, занимающихся разработкой программного обеспечения, чтобы можно было осуществить привязку разрабатываемых профессиональных приемов к среде, в которой они будут применяться.
В структуре книги выделяется шесть частей, описывающих шесть необходимых команде для эффективного управления требованиями профессиональных навыков.
Каждая из перечисленных ниже шести основных частей ориентирована на то, чтобы помочь вам и вашей группе овладеть одним из шести необходимых для успешного управления требованиями профессиональных навыков.
- Для начала, конечно, необходимо правильное понимание проблемы, решить которую призвана новая система программного обеспечения. Этому посвящена часть 1, "Анализ проблемы".
- Часть 2, "Понимание потребностей пользователей", также очень важна. Профессиональные приемы в этой области образуют основу данной части.
- Часть 3, "Определение системы", описывает процесс создания исходного определения системы, призванной удовлетворить эти потребности.
- В части 4, "Управление масштабом", рассматривается чрезвычайно важный и часто игнорируемый процесс управления масштабом проекта.
- Часть 5, "Уточнение определения системы", иллюстрирует основные методы, используемые для доработки системы до уровня детализации, достаточного для проведения проектирования и реализации, чтобы вся расширенная команда в точности знала, какая система создается.
- В части 6, "Построение правильной системы", обсуждается процесс построения действительно удовлетворяющей требованиям системы. Здесь также рассматриваются методы, позволяющие проверить, что система удовлетворяет поставленным требованиям, не наносит никакого вреда своим пользователям и не имеет никаких неприятных свойств, не оговоренных требованиями. Так как требования к любой нетривиальной системе не могут быть "заморожены" во времени, авторы описывают способы, позволяющие команде успешно справляться с изменениями, не разрушая создаваемую систему.
Наконец, после краткого подведения итогов авторы предлагают рецепт, которым вы можете воспользоваться для управления требованиями в вашем следующем проекте. Заканчивается книга главой 35, "С чего начать".
Мы надеемся, что, вооружившись новыми профессиональными приемами, вы сможете создать продукт, достойный восхищения. Но это будет нелегко. Даже если в вашем распоряжении имеются наилучшие методы и процессы, а также поддерживающие их автоматические средства, вы все равно увидите, что это сложная работа. Кроме того, она связана с риском; даже при использовании содержащихся в книге полезных советов, некоторые проекты будут заканчиваться неудачей, так как мы пытаемся создать как можно более сложные системы в наиболее короткое время. Но описанные в данной книге профессиональные приемы помогут значительно снизить риск и таким образом достигнуть успеха в вашем предприятии.
Эд Йордан
Предисловие автора
Дин Леффингуэлл
Источники предлагаемых методов
Предлагаемый в данной книге материал представляет собой опыт, накопленный множеством людей, занимавшихся определением, разработкой и распространением систем программного обеспечения мирового класса. Эта книга не является академическим исследованием, посвященным управлению требованиями. На протяжении 80-х годов мы с Доном Уидригом (Don Widrig) входили в руководство небольшой компании, занимавшейся созданием программного обеспечения для заказчиков. Разрабатывая многие представленные в книге приемы управления требованиями, мы старались сосредоточить внимание на тех из них, которые важны как для создания систем программного обеспечения, так и с точки зрения результатов, которые необходимо представить заинтересованным лицам. Поскольку функционирование программного обеспечения исключительно важно для успешной работы предприятия в целом, мы старались не отвлекаться на мелочи, избегать предвзятых мнений и экспериментов с непроверенными методами.
За последние десять лет методы претерпели эволюцию. Они были усовершенствованы в результате приобретенного в различных компаниях при разнообразных обстоятельствах опыта. Однако все представленные методы проверены на практике и прошли испытание временем. Возможно, даже более важным является то, что на них практически не повлияли происшедшие за этот период в отрасли технологические изменения. Действительно, большая часть изложенных в книге принципов не зависит от изменений в технологиях программного обеспечения. Поэтому мы надеемся, что полученные знания не утратят со временем своего значения.
Уроки работы с требованиями, извлеченные из создания систем программного обеспечения по заказу других пользователей
Поначалу я возненавидел компьютеры. ("Что? Я проторчал здесь всю ночь и должен снова запускать этот пакет, так как оставил лишний пробел? Вы сошли с ума?") Моим первым "настоящим компьютером" был мини-компьютер, который, хотя и имел чрезвычайно ограниченные возможности по современным меркам, был уникален в том смысле, что я мог его трогать, программировать и заставлять его делать все, что я хотел. Это был мой компьютер.
Мои первые исследования касались применения компьютеров к анализу физиологических сигналов человеческого тела, главным образом, электрокардиограмм, и мой компьютер был прекрасным средством для этих целей. Помимо этого я начал применять свои программистские навыки и опыт в системах реального времени, работающих в промышленности.
Наконец, я вошел в корпорацию RELA и начал долгую и временами невероятно сложную карьеру исполнительного директора по разработке контрактного программного обеспечения. Мой соавтор, Дин Уидриг (Din Widrig), вскоре присоединился ко мне в RELA в качестве вице-президента отдела исследований и разработок. Он внес неоценимый вклад в успех многих разработанных нами систем.
С годами компания быстро расширялась. В настоящее время в ней работают сотни людей, и она перешла от разработки простых систем программного обеспечения к созданию полнофункциональных сложных медицинских приборов и систем, которые наряду с программным обеспечением включают в себя механические, электронные и оптические системы. Однако в сердце любой машины, в том числе и самой современной клинической лаборатории для ДНК-диагностики, находится один или несколько компьютеров, которые постоянно надежно выполняют свои функции в заданном ритме в многозадачной системе реального времени.
Первоначально мы программировали все и для всех, от программного обеспечения для позиционирования антенн до игр с лазерными мишенями, автоматически управляемых движущихся аттракционов, обучающих систем, сварочных роботов и средств автоматизированного управления механизмами. Мы даже разработали крупную распределенную компьютерную систему, которая автоматически выявляла и подсчитывала количество рекламных роликов на телевидении. (Наш девиз выглядел так: "Мы делаем компьютеры, которые будут смотреть рекламу вместо вас!") Возможно, единственной объединяющей особенностью разрабатываемого тогда программного обеспечения было то, что оно разрабатывалось для других, т. е. мы не были экспертами в данной области и не могли покрывать расходы по своему усмотрению. Мы полностью зависели от того, насколько заказчик будет удовлетворен конечным результатом работы. Такие условия во многом благоприятствовали формированию эффективного управления требованиями. И вот почему.
- Мы мало знали о предметной области, поэтому зависели от клиента при определении требований. У нас не было искушения выработать их самостоятельно; нам приходилось спрашивать, и мы должны были учиться задавать нужные вопросы, в нужное время.
- Наши клиенты зачастую плохо разбирались в компьютерах, поэтому они зависели от нас в том, что касалось преобразования их потребностей и пожеланий в техническое задание.
- То, что работа оплачивалась, придавало строгость отношениям между разработчиком и клиентом.
- Качество было легко измерить: нам или платили, или нет.
Основной вопрос1. "Что же на самом деле должна делать программа?"
Именно в этой ситуации мы открыли для себя два основных вопроса, с которыми сталкиваются разработчики программного обеспечения во всех проектах. Первый из них руководил нашим поведением многие годы и по сей день остается, пожалуй, сложнейшим вопросом, на который необходимо ответить в любом проекте разработки программного обеспечения.
Что же на самом деле должна делать программа?
Именно для ответа на этот вопрос мы на протяжении более 10 лет разрабатывали принципы и методы, представленные в частях 1, "Анализ проблемы", 2, "Понимание потребностей пользователя", и 3, "Определение системы". Каждый из этих методов доказал свою полезность и продемонстрировал эффективность во многих реальных проектах. Именно в этот период я также впервые познакомился с работами Дональда Гауса (Donald Gause) и Джерри Вайнберга (Jerry Weinberg), в частности с их книгой Exploring Requirements: Quality Before Design (1989). Поскольку она значительно повлияла на нашу работу, мы использовали некоторые ее основные концепции в нашей книге; во-первых, потому, что они работают, а во-вторых, будет хорошо, если вы также воспользуетесь опытом Гауса и Вайнберга.
Уроки, извлеченные из создания высоконадежных систем
Спустя некоторое время корпорация RELA стала специализироваться на разработке различных медицинских приборов и систем, использующих компьютеры: систем искусственной вентиляции легких, инфузионных насосов, водителей ритма, клинических диагностических систем, систем искусственного кровообращения, оборудования, контролирующего состояние пациента, и других диагностических и терапевтических приборов.
Именно в начале работы над проектом системы искусственной вентиляции мы осознали, какая ответственность возложена на нас: Если мы перекроем кран, кто-то умрет! В первую очередь мы думали о пациенте; его жизнь зависела от прибора, для которого мы создавали одну из первых в мире жестко ограниченных по срокам и средствам систем программного обеспечения. (Представьте себе ответственность первопроходца. Вы - первый!)
Понятно, что подобное задание, когда ставки столь высоки, заставило нас очень серьезно подойти к разработке программного обеспечения на самых ранних этапах развития индустрии разработки встроенных систем. Очень быстро выяснилось, что для стабильного успеха необходимо сочетание следующих компонентов.
- Прагматический процесс определения требований к программному обеспечению и управления ими.
- Жесткая методология проектирования и разработки программного обеспечения.
- Применение разнообразных проверенных современных методов верификации и проверки того, что программное обеспечение является правильным и безопасным.
- Высочайшая квалификация и ответственность как команды разработчиков, так и группы, гарантирующей качество программной системы.
Я твердо верил в то время и еще более убежден сегодня, что все эти элементы необходимы для создания любой более-менее надежной программной системы значительного объема. В корпорации RELA это был единственный способ обеспечить безопасность пациентов, выживание нашей компании и экономическое будущее ее служащих.
Основной вопрос 2. "Как точно узнать, что программа делает именно то, что нужно, и ничего другого?"
Добившись успеха в разработке и применении различных методов для ответа на основной вопрос 1, перейдем ко второму фундаментальному вопросу, с которым постоянно сталкивается команда разработчиков программного обеспечения.
Как можно точно узнать, что программа делает именно то, что нужно, и ничего другого?
Методы, используемые для ответа на данный вопрос, составляют основу части 5, "Уточнение определения системы", и части 6, "Построение правильной системы".
Итак, вы можете быть уверены, что представленные в данной книге приемы проверены временем и хорошо зарекомендовали себя. Даже если вы не связаны с разработкой высокобезопасных систем, вы увидите, что это полезные практичные и эффективные (в плане затрат) советы, которые можно использовать для разработки систем программного обеспечения наивысшего качества.
Хотя методы, которые мы заимствовали, модифицировали, разрабатывали и применяли в корпорации RELA для решения двух основных вопросов, были достаточно эффективны, существовала проблема, которая постоянно держала меня в напряжении во время наиболее сложных моментов этих проектов.
При том, что значительная часть действий в процессе определения требований в силу его природы выполняется вручную, сколько времени может пройти, прежде чем мы совершим единственную, но потенциально опасную ошибку?
Существовал также вопрос затрат, так как проводимые вручную испытания были дорогостоящими и не исключали возможности ошибок. За этот период механическое конструирование прошло путь от выполняемых вручную чертежей до трехмерных компьютерных систем автоматического проектирования. За то же время наше продвижение в области программирования (в том, что касается практических целей) ограничилось повышением уровня абстракции наших языков программирования, что, конечно же, хорошо, но такие показатели, как частота ошибок, производительность написания строк кода, а также уровень качества, остались относительно неизменными. Проводимые нами в этот период эксперименты с CASE-средствами принесли неоднозначные результаты. Говоря откровенно, как разработчик программного обеспечения и руководитель, я считал состояние дел в отрасли инженерии программного обеспечения непростым.
Безусловно, автоматизация никогда не устранит потребность в необходимых для разработки программ мыслительных способностях. Тем не менее я согласен с тем, что автоматизация некоторых проводимых вручную операций записи и внесения изменений может высвободить дефицитные ресурсы, чтобы направить их на более продуктивную деятельность. Ну и, конечно, мы ожидали, что затраты на разработку снизятся, а надежность возрастет.
Уроки, извлеченные из деятельности в сфере управления требованиями
В 1993 году была образована корпорация REQUISITE, и некоторых из нас пригласили принять участие в разработке и внедрении нового инструментального средства разработки требований, RequisitePro. Поскольку в это время мы постоянно помогали пользователям в том, что касалось проблем управления требованиями, появилось много дополнительного материала для данной книги. Мы обязаны значительной частью этой работы клиентам корпорации, а также клиентам компании RELA, у которых многому научились.
В это время на мою карьеру большое влияние оказал д-р Алан Дэвис (Alan Davis), главный редактор журнала IEEE Software и заведующий лабораторией программирования им. Эла Помара (El Pomar) университета Колорадо в Колорадо Спрингс. В самом начале он вошел в компанию как директор и советник и в этом качестве оказывал заметное воздействие на нашу технологию и направления развития компании. Д-р Дэвис хорошо известен как специалист в области разработки требований. Он часто выступает в роли консультанта и разработал множество методов, помогающих компаниям усовершенствовать процесс управления требованиями. Эти методы были объединены с некоторыми методами, разработанными в RELA, и стали основой курса профессиональной подготовки "Requirements College", а также некоторых частей данной книги.
Кроме того, следуя недостаточно популярной бизнес-теории, согласно которой профессиональной помощи никогда не бывает слишком много, мы пригласили в компанию известного эксперта и автора книг о программном обеспечении Эда Йордана (Ed Yourdan). Он также оказал большое влияние на выработку курса в том, что касалось технологии и бизнес-направлений. Эд и Алан стояли у истоков этой работы, и многие приводимые в книге высказывания принадлежат им. На самом деле мы хотели выпустить эту книгу совместно с ними несколько лет назад. Но времена меняются, и они любезно предоставили нам возможность распоряжаться их результатами. Поэтому вы часто будете ощущать их присутствие в данной книге.
Опыт, приобретенный в корпорации Rational Software
В 1997 году корпорация Rational Software купила компанию Requisite. В Rational мы приобрели значительный опыт в управлении требованиями применительно к разработке и реализации полного спектра средств разработки приложений, по-прежнему продолжая помогать пользователям в решении их проблем при работе с требованиями. Дон продолжает сотрудничать с нами в вопросах совершенствования методов. Кроме того, в компании Rational я имел прекрасную возможность работать с такими экспертами в области программного обеспечения и авторами популярных книг, как Грейди Буч (Grady Booch), Айвар Джейкобсон (Ivar Jacobson), Джеймс Рамбо (James Rumbaugh), Уолкер Ройс (Walker Royce) и Филипп Крачтен (Philippe Kruchten). Все они оказали влияние на мое понимание проблемы управления требованиями, а Уолкер и Филипп были первыми читателями этой книги.
Мы стали обращаться к методу прецедентов для фиксации требований, а также использовать прецеденты в модели проектирования для того, чтобы обеспечить общую логическую связь при создании архитектуры, проведении реализации и тестирования.
Я также являюсь сторонником принятого в компании Rational итеративного подхода к разработке программного обеспечения, и мне хочется думать, что как в RELA мы в свое время были первопроходцами, так это происходит и теперь с Rational Unified Process - процессом, описывающим полный жизненный цикл разработки программного обеспечения.
Компания Rational помогла мне завершить данную работу, и я благодарен ей за это. Она также любезно разрешила использовать некоторые идеи, тексты и диаграммы.
Наконец, мы хотим поблагодарить всех, кто принимал участие в работе над книгой, в том числе Алана Дэвиса (Al Davis), Эда Йордана (Ed Yourdan), Грейди Буча (Grady Booch), Филиппа Крачтена (Philippe Kruchten), Лесли Пробаско (Leslee Probasco), Яна Спенса (Ian Spence), Джин Белл (Jean Bell), Уолкера Ройса (Walker Royce), Джо Мараско (Joe Marasco), Элмера Мэгэзинера (Elmer Magaziner), а также рецензентов издательства Addison-Wesley: Эга Марсония (Ag Marsonia), Грэнвилла Миллера (Granville Miller), Фрэнка Армура (Frank Armour), д-ра Ральфа Р. Янга (Ralf R. Young) (директора по разработке программного обеспечения компании Litton PRC Systems and Process Engineering), профессора Дэвида Райна (David Rine) (Университет Джорджа Мэйсона) и Дэна Роусторна (Dan Rawsthorn) (ACCESS).
Заключение
По сути, большинство идей этой книги не являются оригинальными. Они представляют собой результат обобщения опыта двух десятилетий совместной работы в сфере разработки программного обеспечения, в которой пристальное внимание уделялось целостному подходу к проблеме требований. Мы полагаем, что нам удалось объединить лучшие идеи и практические приемы в этой чрезвычайно важной и сложной области. Мы верим, что результат - шесть необходимых команде для эффективного управления требованиями наборов профессиональных приемов - поможет вам создать качественную систему программного обеспечения, уложившись в отведенные сроки и бюджет.
