Дисциплина обязательств

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

Основой этой формы отношений являются обязательства, которые:

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

Кроме того:

• ответственная сторона стремится выполнить обязательства, даже если нужна помощь;
• как только становится очевидно, что работа не может быть закончена в срок, обсуждаются новые обязательства.

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

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

Дисциплине обязательств уделяется много внимания в различных моделях процесса производства ПО.

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

Необходимо различать проекты промышленные и проекты творческие. Сложность промышленных проектов – в большом количестве разных организаций, компаний и относительной уникальности самих работ. Пример – строительство многоэтажного дома.

Творческие проекты характеризуются абсолютной новизной идеи – новый сервис, абсолютно новый программный продукт, какого еще не было на рынке, проекты в области искусства и науки. Любой начинающий бизнес, как правило, является таким вот творческим проектом. Причем новизна в подобных проектах не только абсолютная – такого еще не было. Такое, может, уже и было, но только не с нами, командой проекта. То есть присутствует огромный объем относительной новизны для самих людей, которые воплощают этот проект.

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

Управление проектами (project management) – область деятельности, в ходе которой, в рамках определенных проектов, определяются и достигаются четкие цели при нахождении компромисса между объемом работ, ресурсами (такими как время, деньги, труд, материалы, энергия, пространство и др.), временем, качеством и рисками.

Отметим несколько важных элементов, учитываемых при управления проектами.

• Stakeholders – это люди со стороны, которые не участвуют непосредственно в проекте, но влияют на него и/или заинтересованы в его результатах. Это могут быть будущие пользователи системы (например, в ситуации, когда они и заказчик – это не одно и то же), высшее руководство компании-разработчика и т.д. Идентификация всех stakeholders и грамотная работа с ними – важная составляющая успешного проектного менеджмента
• Project scope – это границы проекта. Это очень важное понятие для программных проектов в виду изменчивости требований. Часто бывает, что разработчики начинают создавать одну систему, а после, постепенно, она превращается в другую. Причем для менеджеров по продажам, а также заказчика, ничего радикально не произошло, а с точки зрения внутреннего устройства ПО, технологий, алгоритмов реализации, архитектуры – все радикально меняется. За подобными тенденциями должен следить и грамотно с ними разбираться проектный менеджмент.
• Компромиссы – важнейший аспект управления программными проектами в силу согласовываемости ПО. Важно не потерять все согласуемые параметры и стороны и найти приемлемый компромисс.

Управление проектами рассматривается в методологии разработки программного обеспечения, предложенной корпорацией Microsoft – Microsoft Solutions Framework (MSF).

Эта технология учитывает следующие области управления.

Планирование и мониторинг проекта, контроль за изменениями в проекте (Project planning / Tracking / Change Control)	Интеграция и синхронизация планов проекта; организация процедур и систем управления и мониторинга проектных изменений
Управление рамками проекта (Scope Management)	Определение и распределение объема работы (рамок проекта); управление компромиссными решениями в проекте
Управление календарным графиком проекта (Schedule Management)	Составление календарного графика исходя из оценок трудозатрат, упорядочивание задач, соотнесение доступных ресурсов с задачами, применение статистических методов, поддержка календарного графика
Управление стоимостью (Cost Management)	Оценки стоимости исходя из оценок временных затрат; отчетность о ходе проекта и его анализ; анализ затратных рисков; функционально-стоимостной анализ (value analysis)
Управление персоналом (Staff Resource Management)	Планирование ресурсов; формирование проектной команды; разрешение конфликтов; планирование и управление подготовкой
Управление коммуникацией (Communications Management)	Коммуникационное планирование (между проектной группой, заказчиком/спонсором, потребителями/пользователями, др. заинтересованными лицами); отчетность о ходе проекта
Управление рисками (Risk Management)	Организация процесса управления рисками в команде и содействие ему; обеспечение документооборота управления рисками
Управление снабжением (Procurement)	Анализ цен поставщиков услуг и/или аппаратного/программного обеспечения; подготовка документов об инициировании предложений (requests for proposals – RFPs), выбор поставщиков и субподрядчиков; составление контрактов и переговоры об их условиях; договора; заказы на поставку и платежные требования
Управление качеством (Quality Management)	Планирование качества, определение применяемых стандартов, документирование критериев качества и процессов его измерения

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

При разработке архитектуры ПО важным оказывается совмещение множества точек зрения. Часто ПО оказывается настолько сложным, что его архитектуру не построить как единую модель – в ней должно быть представлено множество отдельных аспектов, связи между которыми сложны и плохо выразимы в явном виде. Полезнее оказывается создание множества моделей, созданных с разных точек зрения. Это происходит из-за разных видов деятельности в процессе разработки ПО При составлении функциональных требований к ПО обращают внимание на то, какая именно функциональность должна быть реализована, но при этом опускаются принципы и детали реализации. При проектировании, наоборот, на первое место выходят принципы реализации ПО. А при тестировании детали реализации снова неважны — на ПО смотрят как на черный ящик, реализующий (не важно каким способом) некоторый набор пользовательской функциональности. При установке у заказчика на ПО смотрят как на набор файлов, хранилищ данных и т. д.

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

Часто понятие архитектуры сужают, понимая под ним лишь описание основных, важных аспектов ПО, создаваемых, например, архитектором при разработке дизайна системы. Для этих целей обычно используется язык моделирования UML (Unified Modeling Language).

"Скелетом" UML является диаграммная структура. Каждый вид диаграммы связан с типом моделей, реализующим определенную точку зрения на программную систему. Виды диаграмм не являются строго обязательными в UML – их можно перемешивать, и создавать свои собственные. Тем не менее, стандартные виды диаграмм являются определенным достоянием программной инженерии, так как отражают опыт многих исследователей и практиков.

Структурные диаграммы:

• диаграммы классов (class diagrams) предназначены для моделирования структуры объектно-ориентированных приложений классов, их атрибутов и заголовков методов, наследования, а также связей классов друг с другом;
• диаграммы компонент (component diagrams) используются при моделировании компонентной структуры распределенных приложений; внутри каждая компонента может быть реализована с помощью множества классов;
• диаграммы объектов (object diagrams) применяются для моделирования фрагментов работающей системы, отображая реально существующие в runtime экземпляры классов и значения их атрибутов;
• диаграммы композитных структур (composite structure diagrams) используются для моделирования составных структурных элементов моделей – коопераций, композитных компонент и т.д.;
• диаграммы развертывания (deployment diagrams) предназначены для моделирования аппаратной части системы, с которой ПО непосредственно связано (размещено или взаимодействует);
• диаграммы пакетов (package diagrams) служат для разбиения объемных моделей на составные части, а также (традиционно) для группировки классов моделируемого ПО, когда их слишком много.

Поведенческие диаграммы:

• диаграммы активностей (activity diagrams) используются для спецификации бизнес-процессов, которые должно автоматизировать разрабатываемое ПО, а также для задания сложных алгоритмов;
• диаграммы случаев использования (use case diagrams) описание поведения системы, которым она отвечает на внешние запросы. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой;
• диаграммы конечных автоматов (state machine diagram) применяются для задания поведения систем, которые можно описать конечными автоматами;
• диаграммы взаимодействий (interaction diagram):
• диаграммы последовательностей (sequence diagram) используются для моделирования временных аспектов внутренних и внешних протоколов ПО;
• диаграммы схем взаимодействия (interaction overview diagram) служат для организации иерархии диаграмм последовательностей;
• диаграммы коммуникаций (communication diagrams) являются аналогом диаграмм последовательностей, но по-другому изображаются (в привычной, графовой манере);
• временные диаграммы (timing diagrams) являются разновидностью диаграмм последовательностей и позволяют в наглядной форме показывать внутреннюю динамику взаимодействия некоторого набора компонент системы.

Виды и свойства требований

Разделим требования на две большие группы – функциональные и нефункциональные.

Функциональные требования являются детальным описанием поведения ПО, его функционала. Они определяют то, что ПО должно уметь делать.

Нефункциональные требования не являются описанием функций ПО. Этот вид требований описывает такие характеристики, как надежность, особенности поставки (наличие инсталлятора, документации), определенный уровень качества. Сюда же могут относиться требования на средства и процесс разработки системы, требования к переносимости на различные операционные системы или различные виды оборудования, соответствию стандартам и т.д. Требования этого вида часто относятся ко всей системе в целом..

Сформулируем ряд важных свойств требований.

• Ясность, недвусмысленность — однозначность понимания требований заказчиком и разработчиками. Часто этого трудно достичь, поскольку конечная формализация требований, выполненная с точки зрения потребностей дальнейшей разработки, трудна для восприятия заказчиком или специалистом предметной области, которые должны проинспектировать правильность формализации.
• Полнота и непротиворечивость.
• Необходимый уровень детализации. Требования должны обладать ясно осознаваемым уровнем детализации, стилем описания, способом формализации: либо это описание свойств предметной области, для которой предназначается ПО, либо это техническое задание, которое прилагается к контракту, либо это проектная спецификация, которая должна быть уточнена в дальнейшем, при детальном проектировании. Либо это еще что-нибудь. Важно также ясно видеть и понимать тех, для кого данное описание требований предназначено, иначе не избежать недопонимания и последующих за этим трудностей. Ведь в разработке ПО задействовано много различных специалистов – инженеров, программистов, тестировщиков, представителей заказчика, возможно, будущих пользователей – и все они имеют разное образование, профессиональные навыки и специализацию, часто говорят на разных языках. Здесь также важно, чтобы требования были максимально абстрактны и независимы от реализации.
• Прослеживаемость — важно видеть то или иное требование в различных моделях, документах, наконец, в коде системы. А то часто возникают вопросы типа – "Кто знает, почему мы решили, что такой-то модуль должен работать следующим образом ….?". Прослеживаемость функциональных требований достигается путем их дробления на отдельные, элементарные требования, присвоение им идентификаторов и создание трассировочной модели, которая в идеале должна протягиваться до программного кода. Хочется например, знать, где нужно изменить код, если данное требование изменилось. На практике полная формальная прослеживаемость труднодостижима, поскольку логика и структура реализации системы могут сильно не совпадать с таковыми для модели требований. В итоге одно требование оказывается сильно "размазано" по коду, а тот или иной участок кода может влиять на много требований. Но стремиться к прослеживаемости необходимо, разумно совмещая формальные и неформальные подходы.
• Тестируемость и проверяемость — необходимо, чтобы существовали способы оттестировать и проверить данное требование. Причем, важны оба аспекта, поскольку часто проверить-то заказчик может, а вот тестировать данное требование очень трудно или невозможно в виду ограниченности доступа (например, по соображениям безопасности) к окружению системы для команды разработчика. Итак, необходимы процедуры проверки –выполнение тестов, проведение инспекций, проведение формальной верификации части требований и пр. Нужно также определять "планку" качества (чем выше качество, тем оно дороже стоит!), а также критерии полноты проверок, чтобы выполняющие их и руководители проекта четко осознавали, что именно проверено, а что еще нет.
• Модифицируемость. Определяет процедуры внесения изменений в требования.

Варианты формализации требований

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

Рассмотрим варианты.

1. Неформальная постановка требований в переписке по электронной почте. Хорошо работает в небольших проектах, при вовлеченности заказчика в разработку (например, команда выполняет субподряд). Электронные письма в такой ситуации часто оказываются важными документами – важно уметь вести деловую переписку, подводить итоги, хранить важные письма и пользоваться ими при разногласиях. Важно также вовремя понять, когда такой способ перестает работать и необходимы более формальные подходы.
2. Требования в виде документа – описание предметной области и ее свойств, техническое задание как приложение к контракту, функциональная спецификация для разработчиков и т.д.
3. Требования в виде графа с зависимостями в одном из средств поддержки требований (IBM Rational RequisitePro, DOORS, Borland CaliberRM и нек. др.). Такое представление удобно при частом изменении требований, при отслеживании выполнения требований, при организации "привязки" к требованиям задач, людей, тестов, кода. Важно также, чтобы была возможность легко создавать такие графы из текстовых документов, и наоборот, создавать презентационные документы по таким графам.
4. Формальная модель требований для верификации, модельно-ориентированного тестирования и т.д.

Некоторые ошибки при документировании требований.

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

В своде знаний по программной инженерии SWEBOK определяются следующие виды деятельности при работе с требованиями.

· Выделение требований (requirements elicitation), нацеленное на выявление всех возможных источников требований и ограничений на работу системы и извлечение требований из этих источников.

• Анализ требований (requirements analysis), целью которого является обнаружение и устранение противоречий и неоднозначностей в требованиях, их уточнение и систематизация.
• Описание требований (requirements specification). В результате этой деятельности требования должны быть оформлены в виде структурированного набора документов и моделей, который может систематически анализироваться, оцениваться с разных позиций и в итоге должен быть утвержден как официальная формулировка требований к системе.
• Валидация требований (requirements validation), которая решает задачу оценки понятности сформулированных требований и их характеристик, необходимых, чтобы разрабатывать ПО на их основе, в первую очередь, непротиворечивости и полноты, а также соответствия корпоративным стандартам на техническую документацию