Книги: [Классика] [Базы данных] [Internet/WWW] [Сети] [Программирование] [UNIX] [Windows] [Безопасность] [Графика] [Software Engineering] [ERP-системы] [Hardware]
Предисловие
Проблема камня
Одна из моих студенток назвала совокупность рассматриваемых в данной книге вопросов проблемой "камня". Она занимается разработкой программного обеспечения в исследовательской лаборатории, и ее заказчики часто предлагают ей задания, которые можно условно представить как "Принесите мне камень". Когда камень доставлен, заказчик некоторое время изучает его и говорит: "Да, но на самом деле то, что я хотел, - это небольшой голубой камень". После доставки небольшого голубого камня выясняется, что это должен быть круглый небольшой голубой камень.
Наконец, может оказаться, что заказчик все время думал о небольшом голубом кусочке мрамора или он и сам в точности не уверен, чего же он хочет, но небольшого кусочка голубого мрамора - или даже кусочка голубого мрамора, имитирующего кошачий глаз, - вполне достаточно. Кроме того, его мнение о требованиях могло меняться в промежутке между доставкой первого (большого) и третьего (небольшого голубого) камня.
При каждой последующей встрече с заказчиком разработчик, как правило, вопрошает: "Чего же Вы хотите?". Разработчик недоволен, поскольку он представлял себе нечто совершенно иное, долго и трудно работая над созданием камня с ранее описанными характеристиками; заказчик также расстроен, поскольку, даже если ему и сложно объяснить, чего же он хочет, он считает, что выразил это достаточно ясно. Эти разработчики просто ничего не понимают!
Ситуация усложняется тем, что в большинстве реальных проектов принимает участие гораздо больше людей. Помимо заказчика и разработчика, которые, конечно же, могут иметь различные имена и названия, вероятно, должны быть маркетологи, специалисты по контролю качества, а также менеджеры нижнего и верхнего уровней и множество заинтересованных лиц, на чьи повседневные действия повлияет разработка новой системы.
Все они могут пострадать от проблем определения приемлемых "камней", в особенности потому, что зачастую в современном быстроменяющемся деловом мире с высоким уровнем конкуренции нет времени для того, чтобы отбросить дорогостоящий двухгодичный "проект по созданию камня" и начать все сначала. Задача состоит в том, чтобы сделать все правильно с первого раза с помощью некоего итеративного процесса, в рамках которого заказчик постепенно определяет, какой собственно камень он хочет получить.
Это достаточно сложно сделать, когда мы имеем дело с осязаемыми физическими предметами типа настоящего камня. Большинство коммерческих и государственных организаций сегодня интенсивно используют информационные технологии, поэтому, даже если они формально занимаются созданием и продажей неких "камней", с высокой степенью вероятности эти "камни" будут оснащены встроенными компьютерными системами. Даже если это не так, вполне возможно, что предприятие нуждается в тщательно разработанных системах для отслеживания продаж "камней" с помощью средств электронной коммерции, учета заказчиков, конкурентов и поставщиков, а также для хранения другой информации, необходимой для поддержания конкурентоспособности на рынке.
Системы программного обеспечения по своей природе являются неосязаемыми, абстрактными, сложными и, по крайней мере в теории, бесконечно изменяемыми. Поэтому, когда заказчик высказывает требования к "каменной системе" нечетко, он делает это, предполагая, что впоследствии сможет их уточнить, изменить и дополнить. Все было бы прекрасно, если бы разработчик и остальные участники процесса создания, тестирования, развертывания и обслуживания данной системы могли осуществлять это с нулевыми затратами времени и денег, но так не получается.
К сожалению, часто вообще ничего не получается: более половины разрабатываемых в настоящее время проектов систем программного обеспечения значительно превысили отведенное на них время и бюджет, а выполнение 25-33% проектов было прекращено, несмотря на то что уже были истрачены баснословные средства.
Цель данной книги - предотвратить подобные сбои и предложить рациональный подход, позволяющий создать систему, которую в действительности хочет видеть заказник. Следовательно, необходимо понимать, что это книга не по программированию и она ориентирована не только на разработчиков программного обеспечения. Это книга об управлении требованиями в сложных программных приложениях. Таким образом, данная книга написана для всех членов команды, разработчиков - аналитиков, разработчиков, персонала, проводящего тестирование и обеспечивающего качество, людей, осуществляющих управление проектом, разработчиков документации и т.д., а также для всех из внешней команды "клиентов" -пользователей и других заинтересованных лиц, представителей маркетинга и менеджмента. Иными словами, эта книга предназначена для всех, кто должен принимать участие в решении проблемы требований.
Оказывается, очень важно, чтобы члены обеих команд, в том числе и не имеющие отношения к технике члены внешней команды, овладели навыками, необходимыми для успешного осуществления процесса определения требований к новой системе и управления ими, хотя бы потому, что именно они изначально создают требования, а в итоге определяют успех (или неуспех) системы. Работающий в одиночку герой-программист- анахронизм, оставшийся в прошлом.
Надеюсь, никто не будет возражать, что при строительстве дома необходимо не раз посоветоваться с его владельцем, иначе можно построить дом с двумя спальнями, в то время как заказчик хотел, чтобы их было три. Но не менее важно обсудить и согласовать "требования" с властями относительно того, что касается строительных норм и регулирования застройки в данном районе; также может понадобиться проконсультироваться с ближайшими соседями, прежде чем вырубить некоторые деревья на участке, где будет расположен дом.
Инспектор по строительству и ближайшие соседи являются теми заинтересованными лицами, которые вместе с владельцем этого дома будут определять, удовлетворяет ли построенный дом всем требованиям. Понятно, что многие важные заинтересованные лица, такие как соседи и представители власти, в данной ситуации не являются пользователями (владельцами дома), также очевидно, что их представления о том, что такое качественный дом, могут существенно отличаться.
В данной книге обсуждаются программные приложения, а не дома или камни. Предъявляемые к дому требования можно, по крайней мере частично, описать посредством ряда чертежей и инженерных схем. Аналогично систему программного обеспечения можно описать с помощью моделей и диаграмм. Чертежи дома служат средством общения и переговоров между инженерами и непрофессионалами (юристами, инспекторами и соседями), точно так же связанные с программной системой технические диаграммы можно создавать так, чтобы "обычные" люди могли их понимать.
Для многих чрезвычайно важных требований диаграммы не нужны вовсе. Например, будущий владелец дома может просто написать (например, по-английски) требование, которое гласит: "В моем доме должны быть три спальни и достаточно большой гараж для двух машин и шести велосипедов". Как будет показано в этой книге, большинство критически важных требований к программной системе также можно написать с помощью естественного языка.
Многие профессиональные приемы, которыми необходимо овладеть для решения данной проблемы, также можно описать посредством практических советов на уровне здравого смысла. Строителю-новичку можно посоветовать: "Не забудьте побеседовать с инспектором по строительству до того, как начнете рыть котлован под фундамент, а не после того, как зальете его раствором и начнете возведение стен". В программном проекте уместен аналогичный совет: "Не забудьте задать правильные вопросы, определить приоритеты требований и не позволяйте заказчику говорить вам, что все 100% требований критически важны, поскольку вряд ли вы сумеете удовлетворить их все к моменту сдачи".
О данной книге
В книге Леффингуэлла (Leffingwell) и Уидрига (Widrig) выбран прагматический подход к описанию решения "проблемы камня". Книга состоит из введения и шести частей, соответствующих шести группам профессиональных приемов в сфере разработки требований. Во введении (главы 1-3) предлагаются определения и основные положения, необходимые для понимания последующего материала. В главе 1 содержится обзор возникающих при разработке систем проблем. Данные свидетельствуют, что некоторые проекты разработки программного обеспечения действительно потерпели неудачу из-за небрежного программирования, но последние исследования достаточно убедительно показали, что плохое управление требованиями само по себе может быть основной причиной провала проекта. В данном предисловии основные положения управления требованиями описаны свободно и неформально, в главе 2 авторы определяют их более тщательно, создавая основу для последующих глав. В главе 3 содержится краткое описание структуры команд, занимающихся разработкой программного обеспечения, чтобы можно было осуществить привязку разрабатываемых профессиональных приемов к среде, в которой они будут применяться.
В структуре книги выделяется шесть частей, описывающих шесть необходимых команде для эффективного управления требованиями профессиональных навыков.
Каждая из перечисленных ниже шести основных частей ориентирована на то, чтобы помочь вам и вашей группе овладеть одним из тести необходимых для успешного управления требованиями профессиональных навыков.
- Для начала, конечно, необходимо правильное понимание проблемы, решить которую призвана новая система программного обеспечения. Этому посвящена часть 1, "Анализ проблемы".
- Часть 2, "Понимание потребностей пользователей", также очень важна. Профессиональные приемы в этой области образуют основу данной части.
- Часть 3, "Определение системы", описывает процесс создания исходного определения системы, призванной удовлетворить эти потребности.
- В части 4, "Управление масштабом", рассматривается чрезвычайно важный и часто игнорируемый процесс управления масштабом проекта.
- Часть 5, "Уточнение определения системы", иллюстрирует основные методы, используемые для доработки системы до уровня детализации, достаточного для проведения проектирования и реализации, чтобы вся расширенная команда в точности знала, какая система создается.
- В части 6, "Построение правильной системы", обсуждается процесс построения действительно удовлетворяющей требованиям системы. Здесь также рассматриваются методы, позволяющие проверить, что система удовлетворяет поставленным требованиям, не наносит никакого вреда своим пользователям и не имеет никаких неприятных свойств, не оговоренных требованиями. Так как требования к любой нетривиальной системе не могут быть "заморожены" во времени, авторы описывают способы, позволяющие команде успешно справляться с изменениями, не разрушая создаваемую систему.
Наконец, после краткого подведения итогов авторы предлагают рецепт, которым вы можете воспользоваться для управления требованиями в вашем следующем проекте. Заканчивается книга главой 35, "С чего начать".
Мы надеемся, что, вооружившись новыми профессиональными приемами, вы сможете создать продукт, достойный восхищения. Но это будет нелегко. Даже если в вашем распоряжении имеются наилучшие методы и процессы, а также поддерживающие их автоматические средства, вы все равно увидите, что это сложная работа. Кроме того, она связана с риском; даже при использовании содержащихся в книге полезных советов, некоторые проекты будут заканчиваться неудачей, так как мы пытаемся создать как можно более сложные системы в наиболее короткое время. Но описанные в данной книге профессиональные приемы помогут значительно снизить риск и таким образом достигнуть успеха в вашем предприятии.
Начало
Полное содержание
Предисловие автора
Введение
Об авторах
Заказать книгу в магазине "Мистраль"
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
