Управление требованиями к ПО

Вы знаете, что в мире около 30% проектов по разработке программного обеспечения закрываются до завершения, около 50% завершаются с двойным превышением бюджета и только 20% можно считать успешными? Вы можете себе представить, чтобы 30% зданий никогда не были достроены? На самом деле интересно было бы взглянуть на Минск в таком случае: наверное, впечатляющее зрелище...

В чем же причина такого плачевного положения в отрасли разработки ПО? Вот три наиболее часто встречающихся фактора, которые создают проблемы в проектах:

  • Недостаток исходной информации от клиента: 13% всех проектов
  • Неполные требования и спецификации: 12% проектов
  • Изменение требований и спецификаций: 12% проектов

Как видите, каждый третий проект испытывает проблемы, связанные со сбором, документированием и управлением требованиями к ПО. Кроме того, устранение ошибок, найденных на стадии установления требований к ПО, обходится в несколько раз дешевле, чем на стадии кодирования. Очевидно, что работа с требованиями является одной из ключевых практик при разработке программного обеспечения.

Как обычно, русскоязычная техническая литература отстает от англоязычной на несколько лет, хотя в последнее время разрыв немного сокращается. Поэтому первая приличная книга, посвященная управлению требованиями, появилась только в 2002 году. Книга называется "Принципы работы с требованиями к программному обеспечению", а ее авторами являются Дин Леффингуэлл (Dean Leffingwell), вице-президент компании Rational Software, и Дон Уидриг (Don Widrig) - независимый консультант, который, впрочем, тоже связан с Rational. Даже не стоит говорить о привычной отвратительной полиграфии. К счастью, сама книга настолько хороша, что ее следовало бы прочитать, даже если бы ее издали на туалетной бумаге.

 

Читать действительно интересно. Не то чтобы стиль был уж совсем легким и простым, но все же авторы постарались не усложнять то, что можно было усложнить. Хороший перевод тоже благоприятно отражается на восприятии информации. Авторы отлично знают, что такое управление требованиями, как лучше структурировать информацию и как подавать ее читателю - а это самое главное. В итоге книга получилась целостной и понятной - отличный учебник для системного аналитика.

Книга разбита на шесть частей, каждая из которых посвящена отдельному аспекту управления требованиями: анализ проблемы, понимание потребностей пользователя, определение системы, управление масштабом, уточнение определения системы, построение правильной системы.


Анализ проблемы

"Анализ проблемы - процесс осознания реальных проблем и потребностей пользователя и предложения решений для удовлетворения этих потребностей". Очевидно, сначала надо установить проблему, прежде чем ее анализировать. Бывает, что сделать это не так просто. В книге описывается несколько полезных и достаточно простых методик, которые позволяют четко идентифицировать проблемы и их основные причины.

Затем авторы описывают моделирование бизнес-процессов и инженерию систем. Наверное, это одни из самых слабых разделов книги, потому что новичкам они не дают практически ничего, что можно использовать на практике, а зрелые аналитики и проектировщики не найдут здесь ничего нового.


Понимание потребностей пользователей

Одна из самых интересных частей. Вначале описываются основные преграды на пути выявления требований. Авторы выделяют несколько синдромов:

  • "Да, но...". Это достаточно распространенная первая реакция пользователей на новую систему: "Да, все отлично, но как насчет изменения механизма управления пользователями?"
  • "Неоткрытых руин". "Поиск требований напоминает поиск неоткрытых руин: чем больше их найдено, тем лучше известно, что это еще не все".
  • "Пользователя и разработчика". Пользователи и разработчики часто совершенно не могут понять друг друга. Они по-разному представляют, что и как должна делать система, а это приводит к проблемам типа: "Пользователи не знают, чего хотят, а если и знают, то не могут это выразить".

Выявление требований - сложный процесс. Тем ценнее методики выявления требований, описанные в книге:

  • интервьюирование и анкетирование: простые и доступные методы, которые можно использовать в любой ситуации при любом проекте;
  • совещания, посвященные требованиям: самый мощный метод выявления требований, но часто неприменимый из-за удаленности клиента;
  • мозговой штурм и отбор идей: позволяет получить множество возможных решений для любой проблемы;
  • раскадровки: простой и недорогой метод, который помогает выявить на раннем этапе реакции типа "да, но...";
  • прецеденты: описывают взаимодействие между системой и пользователем, уделяя основное внимание тому, что система делает для пользователя;
  • обыгрывание ролей: с помощью обыгрывания ролей команда разработчиков может почувствовать мир пользователя, поставив себя на его место;
  • создание прототипов: эффективно помогает преодолеть синдромы "да, но..." и "неоткрытые руины";

Каждая методика рассмотрена достаточно подробно и содержит прямые указания и советы, которые можно сразу же применять на практике.


Определение системы

В этом разделе подробно описывается, как документировать требования. Недостаток раздела в том, что документирование требований рассматривается в контексте методологии RUP (Rational Unified Process). Конечно, многие мысли и замечания можно использовать в любом процессе, но их придется вылавливать самостоятельно. Положительная сторона в том, что даны шаблоны документов, которые лучше помогают понять механизм документирования требований.


Управление масштабом проекта

Данный раздел предназначен для управляющих проектами. Оценка масштаба проекта непосредственно влияет на количество требуемых ресурсов, план и бюджет проекта. Собственно, требования к ПО являются определяющими для правильного планирования, так что авторы рассматривают как бы стыковку системного анализа и управления проектом.


Уточнение определения системы

Требования к ПО для разработчиков несколько отличаются от требований клиентов. Для разработчиков важны детали, поэтому итоговый документ SRS (System Requirements Specification) содержит функциональные требования (то, что должна делать система), нефункциональные требования (производительность, надежность и т.п.) и ограничения проектирования (платформы, СУБД и т.п.).

Есть в книге уникальная деталь. Шестая часть начинается на странице 293 и мирно следует до страницы 320, а затем... неожиданно вместо 321 страницы находится страница 289, причем с абсолютно идентичным содержанием! А еще через четыре страницы шестая часть начинается вновь:). В итоге в книге полностью отсутствуют главы 32 и 33, которые должны были быть посвящены проверке правильности системы. Это не просто ложка, это настоящий черпак дегтя от киевского издательства...

В конце книги есть отличная глава, в которой описан четкий пошаговый процесс работы с требованиями к ПО. Глава просто бесценна для начинающих. Кроме того, имеется множество приложений. Некоторые полезны, некоторые нет, но ничего выдающегося вы в них не найдете.

Отличительной особенностью книги является ориентированность на Rational Unified Process, что и понятно, так как оба автора имеют к компании Rational прямое отношение. Несмотря на это, книга полезна всем без исключения, потому что анализ проблемы и методы выявления требований универсальны.

Михаил ДУБАКОВ

Версия для печатиВерсия для печати

Номер: 

29 за 2003 год

Рубрика: 

Книжная полка
Заметили ошибку? Выделите ее мышкой и нажмите Ctrl+Enter!
 

Комментарии

Страницы

Аватар пользователя Mike
This is a rule that works...

Looks like I touched that guy to the sick place, that is why I have been given such a harsh reaction... :) If you are not able to communicate, do not try...

I am not going to teach you buddy, but even do not try to prove anyone your crappy approach that works having either certain cercumstances or if you want to shove onto customer the product that is not going to be treated well...

Even it is laughing to dispute...

About remote programming - there is no even subject to discuss, nobody will deal with you until you provide them with the EXACT REQUIREMENTS, in the US that buisness works like I said...

Аватар пользователя Андрюха
>>You talk like management from my presious job. Those silly people wanted to control, but lost everything. Not a single good person worked there for a long time. And you know, they've been talking like you.

Насколько я могу судить, Mike -- совсем не манагер. Но о-о-о-чень хочет им стать.

Аватар пользователя Mike
:)

вот съострил, так съострил, как в одном фильме, язвительный вы наш... что могу сказать, молодой ты истчо, подрасти, ok...

Аватар пользователя Dionique
Mike,

It seams to me that you're incompetent guy. You can't even draw up your thoughts well.

Those abstract shit you gave me in the last post says nothing. So why don't you go home?

Аватар пользователя Михаил Дубаков
Дело не в том, хорош руп или плох. И дело не в требованиях. Я не хочу спорить о процессах. Дело в подходе. Одна из основных задач команды - оставить после себя наследство. Если этого не сделать, то уход пары ключевых сотрудников по любым причинам приведет к катастрофе. Если этого не сделать, передача продукта в чужие руки для поддержки просто невозможна.

Я не знаю, как можно оставить наследство без документации. Может подскажете?

Аватар пользователя Dionique
По своему опыту сужу о том, что документация не решает многого. Ни разу не слышал о возможности составления какой-либо документации, которая на 100 % могла бы заменить человека.

Самое клевое в этом деле, добиться, чтобы уходящий человек провел несколько консультаций с оставшимся сотрудником, сохранил связь с фирмой на несколько недель. Это самый лучший выход. Так проще всего передавать дела. Если это удаленная работа, проще всего общаться по ICQ, email - хуже. Само клево - это телефон или личная встреча.

Да, конечно, очень неплохо иметь документацию. Че-нить аля функциональной и технической спецификации, руководства пользователя. Важность других документов - невывсока. Однако, по-любому, чтобы разобраться в низкоуровневых прибамбасах проекта необходимо лезть в исходный код. Исходный код - это образ мышления предыдущего программера. Его нужно понять. А это луче всего сделать вместе с предыдущим программером. Тут никакая спецификация не поможет. Конечно, клево, когда исходники содержат комментарии, но не все программеры делают это хорошо. Нужно еще уметь писать, просто уметь писать.

Да, здорово иметь штат чуваков, которые могут описать действия системы изнутри. Но, сорри, сколько таких людей существует? Единицы. Программеры иногда вообще нормально ничего объяснить не могут. А люди такие стоят очень дорого, слишком дорого... Так что проще настроиться на коммуникациюю внутри команды. А когда на конторе появляется 100 людей, тогда появляются общие стандарты и прочая хрень, вот тогда, видимо, и стоит начинать задумываться о системах сбора требований и прочей хрени, т.к. бабки на это уже есть.

Аватар пользователя Mike
Михаил Дубаков

Правильно спросил, но как видишь тот чувак только себе и защищает, все старается перевести на его частный случай...

Представил чисто совковский метод, и считает что открыл что то новое в проект менеджменте... Попросить кого-то, сделать отдолжение приемнику и т.д. ни хера это толком не работает по своему опыту скажу, если и ожидать помощи от уходящего то стоит ему не плохо заплатить, как правило у нас с работы уходят сильно обиженные на начальников за недоплату зарплаты, остается, как правило приемнику, херова туча кода с единичными коментариями и дай бог ему сил с этим всем разобряться... :), все потому что тот кто требовал с тех програмеров нихера не требовал, на словах просил все ему рассказать... :), так писали что хотели, одни и те же модули по двадцать раз по разному программировали... :) когда окунаешься в это все диву даешься откуда такое берется, люди вроде в одном метре друг от друга сидят, а придти к общему знаменателю не могут...

Аватар пользователя Dionique
Дяди Миши,

Вот видите. Проблема у Вас не в документации и требованиях, а в обычном менеджменте. Руководство у вас, как обычно, порядочные мрази. А почему? А потому, что не доросли, потому что колхозники и просто лохи. Они не понимают, что с людьми можно по-хорошему. Им все кажется, что кого-то можно напугать, болты можно завинтить, что можно установить тотальный контроль и все будет работать.

Типичная ситуация, когда двое сидят рядом и даже не знают, кто и чем занимается. Я это называю это расп***ством. Нужно менеджера по спине лопатой за такие дела.

С другой стороны, когда нормальное отношение, ушедший программер и через пол года придет - все покажет и расскажет и еще пива принесет. Это из моей работы.

Вы совершенно не хотите ничего понимать, т.к. повязли в своем дерьме. Вам не доверяют и вы не доверяете. Далеко вы так не уедете. А все эти документации - это бюрократия чистейшей воды. Почитайте как работает Микрософт, спросите у них про РУП. Они вас пошлют далеко с вашим рупом. У этих парней - главное работа и обычные человеческие взаимоотношения. Пока не научитесь работать вместе по 2, по 3, по 5 чел. - нифига у вас не будет.

Страницы