Документирование программного обеспечения и эффективный процесс разработки

Каких документов «необходимо и достаточно» для создания качественного продукта в срок? ... и правильно ли вообще поставлен вопрос?

Что такое «необходимо и достаточно»? Требование необходимости документа означает то, что без этого документа невозможно создать качественный продукт. Достаточность означает, что при соблюдении документа, Вы гарантированно получите продукт.

В зависимости от типа проекта и предназанчения программного продукта могут потребоваться разные уровни документирования требований заказчика и процесса разработки продукта.

Рассмотрим такой вариант: заказчик и разработчик решили подойти к задаче создания программного продукта с инженерной точки зрения. Заказчик уверен, что точно знает, какой продукт он хочет получить, какие функции и как он должен выполнять. Не просто хочет, чтобы программа делала то и то, но уже знает, где находится «нужная кнопка» и как ее действия связаны со всеми остальными кнопками и т.д.

Это «идеальный заказчик» с точки зрения разработчика. Он никогда не передумает, он все заранее знает. В организации заказчика ни когда и ни чего не меняется. Задача разработчика хорошо расспросить заказчика о его пожеланиях и сделать ровно то, что нужно. Процесс разработки программного продукта уподобляется строительству моста, разработке технического устройства и многим другим инженерным задачам. Его наиболее удачная адаптация для программистов называется Унифицированный процесс разработки программного обеспечения (USDP- Unified Software Development Process). Институт инженеров по электротехнике и радиоэлектронике (IEEE, www.ieee.org) разработал стандарты документации такого процесса разработки программного обеспечения. Согласно этим стандартам документация проекта состоит из следующих составляющих, разрабатываемых в порядке перечисления:

• План экспертизы программного обеспечения (SVVP – Software Verification and Validation Plan): документ описывает, каким образом, и в какой последовательности должны проверяться стадии проекта и сам продукт на соответствие требованиям.
  Проще говоря, этот документ оговаривает то, как заказчик и разработчик убедятся в том, что они сделали то, что хотели сделать и что они действительно это сделали. Он не описывает, что и как они будут делать.
  
• План контроль качества программного обеспечения (SQAP – Software Quality Assurance Plan) каким образом проект должен достигнуть соответствия установленному уровню качества.
  То есть, разработчик в отдельном документе описывает, что он будет стараться, чтобы в программном продукте не было ошибок. А если, не смотря на все «организационные меры», они все-таки возникли, то заказчик будет знать, что разработчик очень старался, чтобы их не было.
  
• План управления конфигурациями программного обеспечения (SCMP – Software Configuration Management Plan) описывает, где и как разработчик будет хранить версии документации, программного кода и как будет определять, каким образом код связан с документацией.
  Например, программисту необходимо внести изменения в программный модуль. При данном подходе ему бывает трудно среди огромного вороха различных версий документов найти описание того, что именно должен делать этот модуль, что он делал раньше и так далее. Чтобы ему помочь в поисках существует этот документ, который описывает, что именно он должен делать, что найти нужную информацию.
  
• План управления программный проектом (SPMP – Software Project Management Plan) описывает, как разработчик будет управлять проектом создания программного продукта, чтобы довести разработку до удачного финала. Включает кадровые вопросы, управления рисками, календарный план и так далее.
  
• Спецификация требований к программному обеспечению (SRS – Software Requirements Specification) – это самый важный документ. Состоит из двух частей, первая включает то, что «попросил заказчик», вторая то, что «сделают программисты».
  Обычно заказчика просят прочитать обе части и убедиться, что все его требования правильно описаны в обеих частях документа. После того, как заказчик подписывает этот документ, он будет виноват в том, что передумал; в том, что разработчик ошибся в формулировании требований и сделал не то, что заказчик хотел и так далее.
  
  
• Проектная документация программного обеспечения (SDD – Software Design Document) – это архитектура и детали проектирования приложения. Редкому заказчику «повезет» почитать этот документ.
  
• Документация по тестированию программного обеспечения (STD – Software Test Documentation): описание того, как должно проводиться тестирование, кто при этом присутствует и так далее.

И так, заказчик сообщает разработчику все и сразу о том, какой программный продукт ему необходим. Разработчик подготавливает все эти семь документов. Заказчик оплачивает их подготовку, тратит время на их внимательное прочтение и подтверждает, что они описывают именно тот продукт, который ему нужен. Разработчик создает продукт и показывает его заказчику. Заказчик согласен, что продукт качественно делает все, что он должен делать, ведь он же «идеальный заказчик». После 15 минут работы с программой заказчик говорит, что все хорошо, но «вот это лучше сделать не так, а вот так». Разработчика охватывает ужас, ведь теперь надо переписать требования заказчика, переформулировать их в требования программиста, выполнить валидацию и верификацию этого документа (т.е. убедиться, что результат будет работать, и будет делать то, что требуется), переписать проектную документацию, еще раз выполнить валидацию и верификацию, переписать документацию по тестированию и, наконец, внести изменения в саму программу. Когда заказчик узнает стоимость такого незначительного с его точки зрения изменения, его тоже охватывает ужас (а вдруг потом еще захочется что-нибудь поменять). Если заказчик поинтересуется у разработчика, из чего складывается стоимость изменения, то даже «идеальный заказчик» откажется платить. Ведь он уже заплатил за разработку технической документации.

В результате, либо заказчик пользуется неудобной программой, либо разработчик на свой страх и риск бросает ведение документации вообще и меняет только программное обеспечение. Тогда заказчик зря тратил время и немалые деньги на эту документацию. И вряд ли продукт станет качественнее, если процесс его создания превратиться в хаос.

Такой «документированный» подход считался единственно верным в 80-х и 90-х годах прошлого века. Все понимали, что что-то не так. Заказчикам не нравилось учить специфическую терминологию, подписывать странные документы и платить за них деньги. Разработчикам не нравилось писать огромное количество документации, которая им совершенно не нужна. При этом ничто ничего не менял. Разработчики считали, что им надо «подстраховаться, чтобы не попасть в рабство к заказчику», а заказчики думали, что «программисты по-другому не умеют».

Лед тронулся в конце 90-х – начале 2000-х, когда все пришли к пониманию того, что программное обеспечение постоянно изменяется, так как постоянно меняются требования к программному обеспечению, и нет необходимости создавать программный продукт «на века». Гораздо важнее заказчику получиться сейчас то, что ему нужно сейчас, а завтра ему нужно будет другое и это надо будет завтра же, а не послезавтра. Компьютер сделан программируемым, именно для того, чтобы его поведение можно было менять.

В результате сформировался подход, названный «экстремальное программирование» (XP -eXtreme Programming). Сейчас название уже не совсем отражает содержание, но в те годы для многих разработчиков и заказчиков это казалось экстремальным. Несмотря на все титанические усилия предусмотреть все, что только возможно и создать лучший в мире продукт редкий проект заканчивался вовремя, а тем более удачно, поэтому долгое время разработчики не могли поверить в то, что экстремальное программирование может работать.

Экстремальное программирование позволяет заказчику:

• не знать абсолютно всех требований заранее,
• вносить изменения в процессе разработки,
• управлять развитием продукта,
• не тратить деньги на создание не нужной им документации.

Это действительно неприятные расходы, ведь Вы ничего не получаете взамен. Чем можно аргументировать заказчика платить за создание документации, кроме как обращением к его совести: «ведь мы потратили на нее свое время». Тем более странно, когда платят одной организации за создание документации, а второй за создание продукта. При этом часто вторая не пользуется результатом работы первой. Платите лучше за продукт, который дает Вам то, чего Вы сами хотите.

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

«Команды, использующие экстремальное программирование, производят качественное программное обеспечение с весьма высокой скоростью» Кент Бек

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

Раньше у экстремального программирования было много противников, которым казалось, что это не надежно и не профессионально, так как они не были знакомы с этой технологией. Сейчас их практически не осталось, но появились разработчики, которые думают, что если они не ведут документацию, то они используют эту технологию. Это не так. Это гораздо хуже, чем «слишком много документации».

Если Вам говорят, что используется экстремальное программирование, но при этом

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

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

Одним из требований экстремального программирования является постоянное присутствие представителя заказчика в команде разработчиков. Если Вы готовы на этой пойти, нам будет легче. Но на самом деле обычно у заказчика нет такой возможности, поэтому мы просим, чтобы один сотрудник, способный ответить на все возможные вопросы был постоянно доступен по телефону, а в идеале по icq+email.
И так, отвечая на риторический вопрос о необходимости и достаточности, можно сказать, что для создания качественного программного продукта нужен заказчик с нерешенной задачей и адекватный грамотный разработчик, готовый вместе с заказчиком найти идеальное в данный момент решение задачи.

Если Вас интересует более подробная информация об экстремальном программировании и способах его внедрения, мы рекомендуем почитать уже ставшую классической книгу Кета Бека «Экстремальное программирование – разработка через тестирование». Нам так же оказалась полезна книга Кена Ауэра и Ройя Миллера «Экстремальное программирование – постановка процесса с первых шагов и до победного конца».

Свяжитесь с нами сейчас!