Документирование программного обеспечения
Качество программного обеспечения, наряду с другими факторами, определяется полнотой и качеством пакета документов, сопровождающих ПО.
К программным документам относятся документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения программ и эксплуатации.
Документация формализует договоренности и обязательства, под которыми можно понимать широкий спектр обещаний, намерений или заданий, циркулирующих между одной или несколькими организациями.
Документы могут служить формальным контрактом, определяющим взаимные ожидания сторон.
Наконец, проектная документация служит для демонстрации продвижения проекта и повышения личной ответственности его участников за результат — на многих стадиях проекта при отсутствии документально подтвержденных результатов работ убедить руководство в успешном ходе проекта становится чрезвычайно трудной задачей.
Классификация и виды документации
Документацию, используемую в проектах разработки программного обеспечения, можно разделить на следующие группы (см. рисунок): Документация проекта и Документация продукта.
|
Рисунок. Виды документации |
Описание проекта
Описание проекта (project statement) содержит основополагающую информацию о сути и назначении проекта, включая постановку задачи, оценки, приоритеты и ограничения технического, бюджетного и временного характера и критерии, при выполнении которых проект будет считаться успешным. При этом уделяется внимание перечислению границ — активностей, которые служат входом в проект, а также тех, которые не будут выполняться в рамках данного проекта.
Постановка задачи. Оценка осуществимости
Обычно заказчик выдает две-три страницы текста задания и сразу же просит оценить время исполнения заказа и его стоимость. Надо быть сумасшедшим, чтобы на это согласиться.
Нередки случаи, когда целые коллективы ошибаются в пять-десять раз и попадают в кабалу или теряют профессиональную репутацию.
Чтобы избежать такой ситуации, нужно предложить заказчику оформить начальный договор на две-четыре недели с тем, чтобы два-три системных аналитика разобрались в задаче, с помощью каких-то инструментальных средств выполнили разбивку системы на компоненты, прикинули возможные объемы этих компонентов и, соответственно, время их реализации. Такая начальная стадия ЖЦП называется "оценкой осуществимости".
Постановка задачи – наиболее творческая часть ЖЦП, которая поднимает почти философские проблемы.
Требуется описать поведение разрабатываемой системы. Эта система получает какие-то сигналы из ее окружения, поэтому надо описать поведение окружения, но окружение само зависит и изменяется под влиянием системы, ее сигналов, особенно аварийных.
Разрешают это противоречие, постепенно уточняя поведение как системы, так и ее окружения.
Когда мы говорим "формализация постановки задачи", мы подразумеваем разработку последовательности моделей, каждая из которых описывает систему и ее окружение с различных точек зрения с постепенной детализацией.
В различных организациях документы такого рода называются по-разному: техническое задание, задание на разработку, обоснование и т.д. Однако, несмотря на различия в названиях, их цель — описать ключевые положения контрактного характера.
Это описание обычно служит приложением к контракту и основой для выделения средств, а поэтому должно быть разработано с максимальной тщательностью.
Поскольку успешное выполнение проекта является основной задачей исполнителя (будь это специализированная организация или внутреннее подразделение заказчика), разночтения в оценке успешности проекта могут привести к тяжелым репутационным и финансовым последствиям. Поэтому уточнение положений таких документов и внесение необходимых дополнений, равно как согласование уточненных и добавленных мест с заказчиком, относится к важнейшим интересам исполнителя и выполняется обычно менеджером проекта.
Техническое задание. Требование к содержанию и оформлению.
Техническое задание (ТЗ) содержит совокупность требований к ПО и может использоваться как критерий проверки и приемки разработанной программы. Поэтому достаточно полно составленное (с учетом возможности внесения дополнительных разделов) и принятое заказчиком и разработчиком, ТЗ является одним из основополагающих документов проекта программного средства.
Техническое задание на разработку ПО должно включать следующие разделы:
введение. В разделе “Введение” указывается наименование, краткая характеристика области применения ПО.
основания для разработки. В разделе “Основания для разработки” указывается: документ (документы), на основание которых ведется разработка; организация, утвердившая документ, и дата утверждения; наименование (условное обозначение) темы разработки.
назначение разработки. В разделе "Назначение разработки" должно быть указано функциональное и эксплуатационное назначение ПО.
требования к программе;
требования к программной документации;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки; приложения.
Планы
Необходимыми атрибутами планов являются: собственно описание требуемых действий; информация о событиях, «запускающих» эти действия; описание взаимной зависимости действий между собой; информация об исполнителях.
Календарный план (schedule), кроме этого, содержит информацию о прогнозируемых датах начала и окончания действий.
Теория разработки программного обеспечения (в частности, модель CMMI) также упоминает множество других планов, которыми должна сопровождаться разработка:
план управления требованиями,
план управления изменениями,
план управления рисками,
план управления конфигурациями,
план тестирования и т.д.
Сетевой график – очень удобный инструмент: во-первых, на нем четко видна зависимость работ друг от друга, во-вторых, на основе сетевого графика можно вычислить длительность всей работы, в-третьих, пользуясь результатами этих расчетов, можно попытаться оптимизировать длительность и затраты на работу.
На практике в «одиночном» проекте, не носящем большой сложности, большинство из этих планов могут носить самый общий характер и ориентироваться скорее на правила взаимодействия с заказчиком, чем на описание внутренних операций.
Риски, связанные с отсутствием большинства планов, кроме плана-графика и плана тестирования, имеют значительный размер только для крупных или критичных проектов.
Задания исполнителям и отчеты о ходе работ
Задания (task), выдаваемые исполнителям, подлежат документированию в целях исключения их «забывания» и двоякого толкования. Документальные формы, используемые для накопления и отслеживания заданий, на практике используются редко и обычно в качестве источника информации о выданных заданиях применяются: планы-графики; специально выделенные разделы в регулярных отчетах; задачи, выставленные через Microsoft Outlook или через системы управления изменениями (такие, как IBM ClearQuest).
Отчеты о ходе работ (status report) применяются для информирования руководства и заказчика о статусе проекта. Отчеты могут исходить как от конечных исполнителей, так и от менеджера проекта.
Протоколы
Всякий сколько-нибудь сложный проект немыслим без формальных и неформальных, запланированных и спонтанных обсуждений, посвященных самым разным вопросам. Эти обсуждения могут происходить в форме очных встреч, по телефону и по переписке. Итоги устных обсуждений целесообразно фиксировать в форме протокола, если приняты решения, изменяющие или дополняющие описание проекта; принято много разнообразных решений; высказаны новые идеи, например, технического характера, которые могут оказаться востребованными в дальнейшем.
Отчеты о результатах активностей
Ход мероприятий, которые завершаются принятием ключевых для проекта решений, отражается в отчетах, представляемых на рассмотрение лицу, принимающему решение. Основными мероприятиями такого рода являются: анализ осуществимости, анализ альтернатив реализации, обзор (review) проектной документации, тестирование и приемка. Протоколы этих активностей, как правило, содержат сведения о времени, объекте, рамках и характере активности, среде, в которой проводилась активность, достигнутых результатах и рекомендуемых решениях.
Отчет служит отправной точкой и средством минимизации длительности обсуждения, так что в некоторых случаях решение может быть принято по переписке. Практика показывает, что при отсутствии отчета обсуждение носит хаотичный и беспредметный характер, непроизводительно отвлекая время высокооплачиваемых сотрудников.
Журналы
Журнал (log) — накопительное перечисление тех или иных однотипных событий или фактов, возникающих в ходе проекта. Типичными объектами, накапливаемыми в журналах, являются риски, проблемы, запросы на изменения, дефекты (как документации, так и собственно продукта). План-график может заменяться или дополняться «журналом задач», в случае, если эти задачи носят локальный характер.
Журналы редко оформляются в виде отдельного документа. Журналы рисков и проблем обычно являются разделом в отчете о состоянии проекта; ведение журналов изменений и дефектов организуется с помощью систем управления изменениями.
Необходимо отметить, что ведение журналов дефектов имеет смысл только в случае, когда инспекции или тестирование производятся лицом, которое не является автором верифицируемого документа или исходного кода. В большинстве случаев разработчик, нашедший ошибку в собственном творении, предпочтет тут же исправить ее, не утруждаясь каким-либо документированием.
Технические требования
Технические требования, или требования к системе (system requirements specification), описывают функциональность, которую должен содержать продукт, а также ожидания заказчика относительно производительности, отказоустойчивости, надежности системы, среды, в которой она должна работать и т.д. Часто требования являются частью контрактной документации.
Исполнитель заинтересован в детализации и фиксации требований как можно раньше, чтобы избежать перепланирования, связанного с изменением требований, и чтобы цель в виде окончания проекта была ясно видна. На практике этого не происходит — каждый проект в ходе разработки в той или иной степени подвержен изменению требований.
Технические спецификации
Технические спецификации (technical specification) содержат описание архитектуры программного продукта и примененных в нем технических решений. Детальность и содержание этих спецификаций в основном зависит от сложности предметной области, нестандартности примененных решений, квалификации разработчиков и распределения задач между ними.
Минимальный набор технических спецификаций содержит общее описание архитектуры и интерфейсов между компонентами, создаваемыми разными разработчиками.
Учитывая, что поддержка обычно поручается менее квалифицированным разработчикам, разумным представляется такой уровень детальности технических спецификаций, который кажется слегка избыточным для сотрудников, разрабатывающих систему. Впрочем, это соображение имеет меньший вес в том случае, когда поддержка будет производиться силами другой организации, а ожидания заказчика на этот счет не сформулированы явно.
Сведения о выпуске
Сведения о выпуске (release note) описывают фактически реализованную функциональность и ошибки, исправленные в данном выпуске системы, а также различные особенности выпуска: среду, в которой продукт тестировался, отклонения от требований, неисправленные ошибки и т.д. В некотором смысле они представляют собой отчетный документ, так как от каждого выпуска заказчик ожидает определенных свойств и качества.
При определении детальности этого документа в первую очередь необходимо принимать во внимание требования заказчика и понимать, будет ли заказчик использовать его для первичной оценки качества разработки.
Руководства
Необходимость и формат представления руководства пользователя всегда диктуются заказчиком, и, следовательно, работы по его составлению так или иначе бюджетируются и оплачиваются. Аналогичные ожидания в отношении инструкций администратора могут не быть сформулированы в случае, если административную поддержку системы предполагается поручить разработчикам. При оценке необходимой детальности инструкций в этом случае следует принимать во внимание, что поддержка, как правило, осуществляется младшим персоналом, который часто сменяется и не имеет постоянного контакта с разработчиками. Отсутствие инструкций затрудняет передачу знаний, привнося искажения, а наличие в системе недокументированных особенностей рано или поздно приводит к утрате знаний, передаваемых «из уст в уста», ухудшая способность исполнителя выполнять свои обязательства.
Психология программирования
Многое в поведении людей объясняет пирамида Маслова [11]:
Диаграмма Маслова носит совершенно тривиальный характер – если человеку нечего есть и негде жить, то что ему до высоких материй?
Но совокупное понимание человеческих потребностей и их выстроенная последовательность очень важны.
В каком-то смысле каждый программист проходит весь путь от простого зарабатывания денег до понимания того, как важно быть членом команды, признания товарищей, достижения высокой самооценки.
Любой человек принадлежит к одному из трех типов:
Лидер. Человек, который стремится управлять другими людьми, проектами, для которого нестерпимо быть просто "винтиком" в сложном механизме. Из лидеров выходят политические деятели, менеджеры разного уровня, для них, прежде всего, важен личный успех.
Технарь. Человек, который получает настоящее удовольствие от самого процесса поиска решения, например, программирования, которому по большому счету наплевать, что есть начальники и подчиненные, что о нем не пишут газеты и т.д. Главное – решить задачу.
Общительный. Эти люди разносят информацию, популяризуют результаты других людей. Психологи говорят, что 60% женщин относятся именно к этой категории.
Знание этих категорий очень важно для менеджеров программистских коллективов. Если собрать коллектив из одних лидеров, то будет постоянная борьба за власть, даже самые лучшие идеи не будут доведены до реализации, да и обмена идеями, скорее всего, не будет.
Команда из одних технарей не будет соблюдать бюджет и сроки, каждый будет сидеть в своем углу и решать ту задачу, которая ему больше нравится, а не ту, решение которой необходимо в данный момент.
Наконец, в коллективе, состоящем преимущественно из общительных людей, будут самые веселые праздники, туда всегда будет приятно зайти, но работа спориться не будет. И такие коллективы я встречал неоднократно.
Понятно, что хороший коллектив должен включать удачное сочетание лидеров, технарей и людей, ориентированных на общение. Как говорится, "мамы разные нужны, мамы всякие важны".
Организация коллектива разработчиков
Основная идея состоит в построении иерархии подчиненности.
Есть руководитель темы или отдела, у него в подчинении несколько руководителей групп, у каждого руководителя группы в подчинении несколько специалистов. Разумеется, уровней иерархии может быть и 2, и 3, и 4, но все-таки не 15 и не 20.
Каждый руководитель должен сформулировать задачу своим подчиненным так, чтобы минимизировать интерфейсы между ними, т.е. максимально локализовать решаемые ими задачи. Это не всегда возможно, не у всех руководителей получается, но так и различаются руководители и их команды.
В незапамятные времена многие верили в закон Конвея: "Каждая система структурно подобна коллективу, ее разработавшему". То есть, если команда состоит из 50 разработчиков – соответственно и ПП будет состоять из 50 структурных частей)))
Cо временем закон Конвея, который был сформулирован его автором только в качестве шутки, был обобщен до довольно конструктивного метода – матричного. К чему подталкивает закон Конвея? Каждый специалист выполняет только свой небольшой кусок работы, но делает это всегда, для всех заказов такого же типа, набивает руку, почти не думает, совершает мало ошибок, т.е. процесс превращается в производственный.
Итак, пусть у нас есть n специалистов и m однотипных заказов. Строим матрицу из n строк и m столбцов. Элемент в i-ой строке из j-ого столбца обозначает работу i-ого специалиста для j-ого заказа. Например, один специалист хорошо делает синтаксические анализаторы, другой – оптимизаторы, третий – генераторы и т.д., а однотипные заказы – это трансляторы с разных языков для разных платформ.
Тем самым каждый специалист подчинен двум руководителям – административному (он же принадлежит какой-то группе, отделу) и руководителю проекта, в котором он принимает участие в данный момент.
У матричного метода есть свои плюсы и минусы. С одной стороны, узкая специализация по конкретной теме позволяет надежнее планировать сроки.
С другой стороны, нарушен принцип единоначалия. Часто возникает ситуация, когда руководителю проекта нужен какой-то конкретный специалист, а начальник отдела загрузил его работой для другого заказа.
Есть и еще один недостаток матричного метода, не столь очевидный. Конечно, занимаясь годами одним и тем же, специалист оттачивает свое мастерство, но в целом он ограничен, не расширяет свой кругозор и т.п.
Описана совершенно другая модель организации коллектива – бригада главного хирурга. Сложные операции всегда делает один человек – главный хирург, но ему помогает целая бригада – кто-то делает надрезы, а потом зашивает, кто-то подает инструменты, следит за показаниями приборов и т.д. То есть, все программы, документацию, основные тесты пишет один человек – главный программист. У него есть заместитель, который участвует в проектировании, обсуждениях, критикует решения главного программиста, но ни за что не отвечает. В случае болезни или по какой-то другой важной причине заместитель может заменить главного программиста.
В бригаде есть тестер, секретарь, библиотекарь, продюсер с вполне понятными функциями. Возможно подключение еще каких-то узких специалистов.
Оказалось, что такая бригада может работать в 3-5 раз быстрее традиционных команд программистов, поскольку не нужно тратить время на согласование деталей интерфейсов с другими программистами, изделие получается цельным и "элегантным", выполненным в одном стиле. Главный программист выбирается из числа наиболее опытных и высококвалифицированных, он может себе позволить сосредоточиться на основной задаче и не тратить время на всякие "бытовые" функции, которыми полна наша повседневная жизнь.
Эта модель организации коллектива не нашла широкого применения. Где вы найдете множество программистов, готовых безропотно подчиняться главному программисту? Наша специальность подразумевает наличие твердого характера, творческого начала, гордости за свое детище.
Организация коллектива разработчиков в компании Microsoft
Относиться к компании Microsoft можно по-разному – слишком агрессивны, чрезмерное стремление к монополизму, программы огромны и неэффективны, документация часто непонятна и, опять-таки, очень объемна.
Тем не менее, абсолютное большинство пользователей работает именно на продуктах этой компании, Microsoft поддерживает университеты по всему миру, да и со своим бесконечным ПО успешно справляется. Поэтому мы не можем пропустить опыт Microsoft в этой области.
Служба Microsoft Consulting Services провела анализ результатов выполнения большого количества программных проектов. Оказалось, что только 24% проектов можно признать в той или иной степени успешными, 26% не были завершены, а остальные столкнулись с большими проблемами, например, бюджет был превышен вдвое или затрачено в 1,5 раза больше времени.
Основными причинами неудач были признаны следующие:
постоянное изменение требований;
нечеткие или неполные спецификации;
низкое качество кода;
слишком широкая постановка задачи;
ошибка в подборе кадров;
плохая организация работы;
нечетко сформулированные цели.
Для преодоления этих трудностей был предложен набор моделей Мicrosoft Solution Framework (MSF), в котором учтен опыт, накопленный группами разработки программных продуктов.
Формирование коллектива – сложная задача, которая должна решаться с помощью психологов. Вот некоторые основные положения:
не должно быть команды из одних лидеров;
не должно быть команды из одних исполнителей;
в случае неудачи команда расформировывается;
система штрафов (если проект проваливается – наказывают всех).
Самыми революционными оказались модель команды разработчиков и модель процесса разработки. Первая модель (team model) описывает, как должны быть организованы коллективы и какими принципами им надо руководствоваться для достижения успеха в разработке программ. Разные коллективы могут по-своему применять на практике различные элементы этой модели – все зависит от масштаба проекта, размера коллектива и квалификации его участников.
Этот "бублик" описывает только роли, за ними могут скрываться несколько человек, исполняющих каждую роль. Самое удивительное, что в этой модели не предусмотрено единоначалия – все роли важны, все роли равноправны, поэтому MSF называют моделью равных (team of peers).
Program management – управление программой. Исполнитель этой роли отвечает за организацию (но не руководит!): осуществляет ведение графика работ, утренние 15-минутные совещания, обеспечивает соответствие стандартам и спецификациям, фиксацию нарушений, написание технической документации.
Product management – управление продуктом. Исполнители этой роли отвечают за общение с заказчиком, написание спецификации, разъяснение задач разработчикам.
Development – наиболее традиционная роль – разработка и начальное тестирование продукта.
User education – обучение пользователей. Написание пользовательской документации, обучающих курсов, повышение эффективности работы пользователей.
Logistic management – установка, сопровождение и техническая поддержка продукта, а также материально-техническое обеспечение работы коллектива.
Testing – тестирование. Выявление и устранение недоработок, исправление ошибок, другие функции QA.
Все решения принимаются коллективно, разделяется и ответственность в случае провала проекта.
Модель процесса определяет, когда и какие работы должны быть выполнены.
Process model имеет три основные особенности:
разбиение всего процесса на фазы;
введение опорных точек;
итеративность.
Весь процесс разбивается на четыре взаимосвязанных фазы. Прежде чем переходить к следующей фазе, на предыдущей должны быть получены определенные результаты.
В принципе, ничего нового тут нет, это известная спиральная модель, но необычно разбиение трудоемкости по фазам, связанное с тем, что и назначение каждой фазы весьма своеобразно.
Envisioning – выработка единого понимания проекта всеми членами коллектива. Эта фаза заканчивается разработкой формализованного документа:
problem statement — описание задачи объемом не более одной страницы;
vision statement — от чего хотим уйти, чего хотим добиться;
solution concept — что хотим внедрить и как;
user profiles — кто будет этим пользоваться;
business goals — возврат инвестиций;
design goals — конкретные цели и ограничения продукта, его конкретные свойства.
Planning — планирование очередного цикла разработки:
функциональные спецификации;
план-график работ;
оценка рисков.
Developing — разработка, причем рекомендуются различные технологические приемы, например, переиспользование кусков кода, программирование по контракту, написание защищенного от ошибок ПО и т.д.
Stabilizing — создание стабильной версии, готовой к использованию.
Важную роль играют опорные точки (milestones), в которых анализируется состояние работ и производится их синхронизация. В этих точках приложение или его спецификации не замораживаются. Опорные точки позволяют проанализировать состояние проекта и внести необходимые коррективы, например, перестроиться под изменившиеся требования заказчика или отреагировать на риски, возможные в ходе дальнейшей работы. Для каждой опорной точки определяется, какие результаты должны быть получены к этому моменту.
Каждая фаза процесса разработки завершается главной опорной точкой (major milestone). Характеризующие ее результаты видны не только коллективу разработчиков, но и заказчику. Главная опорная точка – это момент, когда все члены коллектива синхронизируют полученные результаты. Назначение таких точек в том, что они позволяют оценить жизнеспособность проекта. После анализа результатов коллектив разработчиков и заказчик совместно решают, можно ли переходить на следующую фазу. Таким образом, главные опорные точки – это критерии перехода с одной фазы проекта на другую.
Внутри каждой фазы определяются промежуточные опорные точки (interium milestones). Они, как и главные, служат для анализа и синхронизации достигнутого, а не для замораживания проекта. Но, в отличие от главных опорных точек, промежуточные видны только членам коллектива разработчиков. Промежуточные опорные точки отмечают более скромные достижения и разбивают большую задачу на мелкие части, выполнение которых легче контролировать.
Итеративность процесса заключается в его многократном повторении на протяжении всего цикла создания и существования продукта. На каждой успешной итерации в продукт включаются только те новые средства и функции, которые удовлетворяют изменяющимся требованиям бизнеса.
Важную роль в MSF играет postmortem – так раньше называли распечатки памяти после аварийных завершений программы. В этом документе описывается, что было хорошо и какие возникали проблемы, т.е. такие знания, которые можно накапливать для использования в следующих проектах.