2
2.2. Техническое задание (ТЗ)
ТЗ это формальный документ,представляющий собой структурированный набор требований заказчика. Наиболее распространенная форма фиксации требований в СНГ – Техническое Задание (ТЗ). Этот термин в ИТ задан стандартом ГОСТ 34.602-89. Современным аналогом является стандарт IEEE Std 830 (http://shikardos.ru/text/standart-ieee-830-1998/).
Профессиональный термин – SRS – SoftwareRequirementSpecification, на нашем программистском сленге – просто «спецификации» или «спеки».
Основные характеристики ТЗ:
- текст структурирован и разбит на главы;
- все разделы пронумерованы – это дает возможность сослаться не только на конкретное требование, но и на каждый конкретный раздел в документе;
- не допускается использование фраз содержащих неточности или неоднозначное толкование;
- имеет графический контент - модели, рисунки, графики, схемы;
- имеет внутренние ссылки на другие разделы (например, см. п.2.6.);
- имеет раздел «История изменений»;
- имеет оглавление.
Для написания ТЗ рекомендуется использовать стандарт IEEE 830, раздел «Структура SRS» (Software Requirement Specification), включающий в себя (http://school.system-analysis.ru/wp-content/uploads/2014/09/IEEE-830-1998):
- введение;
- цели;
- соглашения о терминах;
- предполагаемая аудитория и последовательность восприятия;
- масштаб проекта;
- ссылки на источники;
- общее описание;
- видение продукта;
- функциональность продукта;
- классы и характеристики пользователей;
- среда функционирования продукта (операционная среда);
- ограничения, правила и стандарты;
- документация для пользователей;
- допущения и зависимости;
- функциональность системы;
- функциональный блок X (таких блоков может быть несколько);
- описание и приоритет;
- причинно-следственные связи, алгоритмы (движение процессов, workflows);
- функциональные требования;
- требования к внешним интерфейсам;
- интерфейсы пользователя (UX);
- программные интерфейсы;
- интерфейсы оборудования;
- интерфейсы связи и коммуникации;
- нефункциональные требования;
- требования к производительности;
- требования к сохранности (данных);
- критерии качества программного обеспечения;
- требования к безопасности системы;
- прочие требования;
Приложение 1. Глоссарий
Приложение 2. Модели процессов и предметной области и другие диаграммы
Приложение 3. Список ключевых задач
В настоящее время стало популярным фиксировать требования в виде wiki-сайтов, т.е. веб-сайта, структуру и содержимое которого пользователи могут самостоятельно изменять с помощью инструментов, предоставляемых самим сайтом. Форматирование текста и вставка различных объектов в текст производится с использованием вики-разметки. На базе этой технологии построена Википедия. На сегодняшний день самым популярным инструментом ведения документации в стиле wikiявляется Google Sites (https://sites.google.com/).
Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.
Начинаем разбираться с метриками проекта.
- Во что это выльется по времени?
Некоторые инструменты:
2.3. Пользовательские сценарии (Use Cases)
Пользовательские сценарии построены на основе использования пользовательских историй (Story mapping), см. п.2.4.
2.4. Agile-методы или Пользовательские истории(Story mapping)
В современных подходах к управлению программными проектами – Agile/Scrum [98] – применяется развитие идеи пользовательских сценариев т.н. пользовательские истории (User Story). Пользовательские истории собираются в бэклог – Backlog.
User Stories
Суть записи пользовательских историй проста [98]. Вся функциональность программного продукта разбивается на отдельные (максимально независимые) кусочки. В Scrum их называют «кусочки требований» - piece of requirement. И каждый такой «кусочек» записывается в формате:
Я как [пользователь] хочу [действие], чтобы была [польза].
Пользователь – любой пользователь в системе. В несложных системах обычно вводят 3-5 типов пользователей.
Действие – описание функциональности.
Польза – что получает пользователь в результате этого действия. Здесь фиксируется некая бизнес-ценность – ради чего это действие требуется делать.
Примеры:
Описание функциональности
Пользовательские истории
Электронная библиотека
Я как читатель хочу видеть перечень книг упорядоченных по авторам, разделам
Система управления обучением.
Информирование участника тренинга о месте, дате и стоимости обучения.
Я как участник тренинга хочу получить письмо с расписанием занятий и банковские реквизиты на оплату обучения.
Подобный подход понятен бизнес-пользователям и может его структурировать в смысле управления требованиями со стороны пользователей. Пользовательские истории традиционно фиксировались в Scrum в виде карточек или стикеров. Такие карточки называются «пользовательские карточки» – User Card.
Однако такой формат хоть и удобен для команд, которые находятся в одном помещении,он не применим для распределенных команд. В этом случае используются online инструменты.
Самые популярные:
- Jira&Confluence – от компании Attlassian.
- Google Docs + Spreedsheet
- MS Excel
- Backlog
Все пользовательские истории собираются в бэклог.
Примеры бэклога:
Каждая пользовательская история в бэклоге должна содержать:
- описание
- приоритет – обычно, чем выше висит карточка с историей – тем выше приоритет
- объем – оценка этого требования
- релиз/итерация – когда по плану предполагается разработка истории
Последние два требования появляются после планирования проекта.
После того как в проекте получено структурированное дерево работ (СДР, WBS – work break downstructure), следует перейти к оценке пакетов работ.
При этом разделяют оценку:
- требований;
- трудозатрат;
- ресурсов;
- бюджета.
Оценка проекта проходит в следующем порядке:
Различные методы и подходы используются для оценки: объема функциональности, размера проекта, сроков, объема работ. При этом некоторые подходы лучше применимы к большим (Б) проектам, а некоторые только к средним (С) и малым (М).
В таблице ниже представлены методы оценки, используемые в программных проектах, и их применимость:
Функциональные точки
Story Points
Метод футболки
Метод аналогий
Экспертная оценка
Метод Дельфи
Что оценивается
Размер, объем работ, сроки, функциональность
Размер, объем работ, сроки, функциональность
Размер проекта
Стадия разработки
Ранняя-средняя
Ранняя
Итеративный или последовательный подход
Возможная точность
Средняя-высокая
Метод функциональных точек
Метод функциональных точек (Functional Points),с одной стороны, очень прост; с другой стороны, его сложно применить в современных проектах.
(http://citforum.ru/SE/project/arkhipenkov_lectures/12.shtml)
Function Points – это единица измерения размера программных систем.FunctionPointAnalysis (FPA) – метод определения размера программных систем (приложений) и проектов по их разработке. Размер приложения определяется с точки зрения функциональности, т.е. с точки зрения пользователя. Данный метод используется довольно редко ввиду того, что для его использования требуется полностью разработанный пользовательский интерфейс системы еще до начала разработки. С появлением Agile-подходов полная проработка интерфейсов и дизайна системы до начала разработки не делается – в результате этот метод используется редко.
Метод Story Points
Точного перевода StoryPoint до сих пор не предложено. У Стива Макконелла(SteveMcConnell - CodeComplete, SecondEdition,2004) данный метод называется "метод абстрактных рейтингов".
Впервые этот метод оценки применялся в экстремальном программировании, но позже нашел широкое применение в оценке пользовательских историй в Scrum.
При использовании метода абстрактных рейтингов группа оценщиков просматривает список пользовательских историй (или требований), которые они предполагают реализовать. При этом присваивает каждой истории некоторый размер, измеряемый в пунктах (points), или единицах сложности. При этом историям назначаются значения по одной из числовых последовательностей, представленных в таблице:
Процесс оценки проходит следующим образом:
- Все требования записываются в виде функционального листа (Feature List);
- Выбирается самая малая история за эталон единицы сложности – один пункт;
-Все истории сравниваются с эталоном и друг с другом;
- Все оценки историй складываются.
В результате получается оценка проекта в абстрактных единицах сложности.
На этой стадии пункты не принесут никакой информации, потому как являются абстрактными единицами сложности – они не преобразуются в человеко-часы, календарное время и т.д. Т.е. не дают никакой информации для принятия решений менеджером проекта.
Почему такой формат используется?:
Оценивать требования в часах (или, иначе говоря, в трудозатратах) не совсем верно. Трудозатраты могут меняться исходя из производительности программиста, который будет выполнять задачу.
Этот метод довольно прост и он не дает грубых ошибок.
После проведения первичных оценок команда планирует первую итерацию, включая в нее ряд историй, т.е. планируя завершить некоторое количество абстрактных пунктов. В основу этого плана может быть заложено предположение, что один пункт равен восьми или шести человеко-часам трудозатрат, но на этом этапе это всего лишь предположение.
После завершения первой итерации у команды появляется возможность более определенно составлять дальнейшую оценку проекта. Команда видит, какие истории были завершены, сколько пунктов было выполнено, и на основе полученной информации может строить дальнейшую оценку.
Данные итерации №1
Реализовано историй на 27 SP (StoryPoint)
Затрачено 12 человеко-недель
Затрачено 3 календарные недели
Предварительная калибровка
Объем работ = 27 SP / 12 человеко-недель = 2,25 SP/человеко-неделю
Сроки = 27 SP / 3 календарные недели = 9 SP/календарную неделю
На основе этой калибровки руководитель проекта составляет оценку оставшейся части проекта. Пример – в следующей таблице.
Данные итерации №1
Предположения (из предварительной калибровки)
Объем работ = 2,25 SP/человеко-неделя
Сроки = 9 SP/календарную неделю
Размер проекта = 180 SP
Предварительная оценка для всего проекта
Объем работ = 180 SP / 2,25 SP/человеко-неделя = 80 человеко-недель
Сроки = 180 SP / 9 SP/календарную неделю = 20 календарных недель
Исходная оценка будет уточняться по данным из следующих итераций и обычно находят какое-то среднее значение производительности команды. При этом, чем короче итерации, тем быстрее у вас будут появляться данные для оценки и тем точнее будет становиться оценка проекта.
Метод футболки
Часто на ранних этапах проекта участникам проекта требуется решить, какую функциональность предстоит делать в проекте (http://cribs.me/upravlenie-proektami/metody-upravleniya-proektami).И при этом бизнес-заказчикам требуется принять решения, не обладая информацией о реальной сложности той или иной функциональности продукта. Действительно, они задаются вопросом: - "Как я могу понять, нужна мне эта функциональность или нет, если я не знаю, сколько она будет стоить?!" На что разработчик возразит: "Я не могу оценить стоимость, пока не получу более подробные требования". Ситуация заходит в тупик.Вспомним, что хорошая оценка – это та оценка, которая позволяет принимать решения для управления проектом. Для этого используется так называемый метод футболки.(см. также: А.Полковников, М.Дубовик. Управление проектами. Полный курс МВА).
В этом методе разработчики классифицируют все отдельные функции по отношению к другим как малые (S), средние (M), большие (L) и очень большие (XL). Параллельно бизнес-заказчики классифицируют бизнес-ценность данной функциональности, пользуясь такой же шкалой. Затем два набора оценок объединяются и сравниваются.
Именно за размеры S, M, L, XL данный метод и называется методом футболки – используются размеры футболок.
Функция
Коммерческая ценность
Для принятия решения достаточно сравнить два столбца. Даже в таком виде таблица позволяет принимать решения: "Данная функция требует больших затрат на разработку, но обладает низкой ценностью для бизнеса – от нее лучше отказаться". Если вы исключаете работу над функцией уже на этом этапе, вы экономите не только на разработке, но и на выявлении требований, постановке задачи, управлении проектом и т.д.
Что стоит сохранить, а что выбросить? Обсуждать эту тему будет проще, если задать для размеров футболки веса и проанализировать данные по соотношению затраты/выигрыш, используя следующую таблицу.
Коммерческая ценность
Затраты на разработку
Наличие подобной таблицы дает возможность добавить 3-й столбец в изначальную оценку и показать соотношение затрат/выгоды в числовом выражении и поставить разумный приоритет.
Функция
Коммерческая ценность
Затраты на разработку
Решение
Данную цифру не стоит воспринимать слишком серьезно и проводить черту, ниже которой функциональность не будет даже обсуждаться. Данный метод, прежде всего, позволяет расставить приоритеты и дать определенное "да" для функций в верхней части списка.
Этот метод обычно используется для обсуждения функциональности с заказчиком проекта.
Несколько советов оценщикам:
- Всегда давайте оценку с адекватным уровнем точности. Используйте вилку оценок (от – до).
- Оценивайте не объем документации, а реальную функциональность. Сведите документацию в FeatureList.
- Фильтруйте информацию, не допускайте к оценке слишком много информации.
- Не сообщайте экспертам ваши соображения насчет размера и длительности оцениваемого проекта. Не влияйте на их ход рассуждений.
- Никогда не давайте спонтанных оценок. Возьмите 15 минут на "подумать".
- Даже 15 минут хватает, чтобы дать более детальную оценку.
Сбор метрических данных
Определяйте размер каждого проекта.
Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.
2.5. Концептуальное единство
– Ты что, не знаешь, что такое «это»?
– Я прекрасно знаю, что такое «это»,
когда я его нахожу.
(Льюис Кэрол.«Алиса в Стране чудес»)
Концептуальное единство либо разобщенность лучше всего просматривается в архитектуре [10].(См. также: http://webkomora.com.ua/ru/articles/web/management/man-month/145.html).
У большинства европейских соборов части, построенные разными поколениями строителей, имеют различия в планировке и архитектурном стиле, пишет Брукс. Более поздние строители испытывали соблазн «улучшить» проект своих предшественников, чтобы отразить новые веяния моды и свои личные вкусы. В результате общий вид собора создает впечатление перегруженности и неискренности. Архитектурное единство Рейнского собора находится в прямой противоположности с таким смешением стилей. Его гармоничность и чистота стиля явились результатом того, что восемь поколений строителей смиряли свою гордыню в пользу сохранения концепции собора.
Хотя программные системы не создают восемь поколений разработчиков, в большинстве своем они демонстрируют меньшую согласованность концепций, чем в любом соборе. Обычно это происходит не оттого, что главные проектировщики сменяют друг друга, а потому, что проект расщепляется на ряд задач, выполняемых разными разработчиками.
Концептуальная целостность является важнейшей характеристикой большого системного проекта. Концептуально целостная система быстрее разрабатывается и быстрее отлаживается. Поэтому, если есть важная идея, не вписывающаяся в основные концепции, то ее лучше оставить в стороне, полагает Брукс [10].
Поскольку целью проектирования является простота использования, окончательную оценку проекта дает достигнутое отношение функциональности к сложности концепций. Ни функциональность, ни простота в отдельности не являются признаками хорошего проекта. Важна простота и непосредственность.И то, и другое вытекает из концептуальной целостности.
Архитектура – это полная и подробная спецификация интерфейса пользователя. Архитектор является представителем пользователя, а не продавца или разработчика. Для того чтобы добиться концептуальной целостности, архитектура и разработка должны быть разделены. Архитектура говорит, что должно произойти, а разработка – как сделать, чтобы это произошло, т.е. предусматривает реализацию.
Второй закон Брукса[10]: Архитектура системы должна исходить из одной головы.
Естественно, эта голова должна прислушиваться ко всем мнениям, но оставлять только то, что вписывается в первоначальную концепцию, уверен Брукс (Frederick P.Brooks, TheMythicalMan-Month). Могут возникнуть возражения: не захватят ли архитекторы всю творческую деятельность, сделав исполнителей лишь зубчиками в механизме? Не окажется ли, что более совершенный продукт можно получить, используя идеи всей бригады?
В действительности, разработка проекта требует не меньше творчества, новых идей, изобретательности, чем создание архитектуры. Это просто другая работа.
Практический опыт говорит о том, что дисциплина идет на пользу. В проектах, где проектирование архитектуры и разработка тщательно разделены, исполнители сразу сосредотачиваются на своей части задачи, в результате чего изобретательность бьет ключом. В ничем не ограничиваемой группе большая часть обдумывания и обсуждения посвящена архитектурным решениям в ущерб реализации. «Форма освобождает» – говорят художники.
Если Вы хотите, чтобы система обладала концептуальной целостностью, то управлением концепциями должен заниматься кто-то один.
Примеры концептуально целостных систем: UNIX, APL, Pascal, Modula, SmallTalk, Fortran, Microsoft Windows NT, Microsoft Excel, Apple iOS.
Отрицательные примеры: Cobol, PL/I, Algol, MVS/370, MS-DOS, Microsoft Windows 95, Microsoft Word.
Когда руководитель проекта делает свою первую систему, проект стремится к скромности и ясности, продолжает Брукс. При работе ему постоянно приходят в голову то одни, то другие «украшения». Они откладываются в сторону для использования «в следующий раз». После того, как система закончена, архитектор с твердой уверенностью в себе готов к созданию нового проекта.
Эта вторая система является наиболее опасной для проектировщика. При работе над третьей и последующими системами он уже приобретет необходимый опыт. Разрабатывая вторую систему, проектировщик стремится реализовать все идеи и украшательства, отложенные в сторону при работе над первым проектом, свидетельствует Брукс. В результате получается «большая куча», из которой используется едва ли половина возможностей. Примерами могут служить Windows 95 и MS Exchange.
Третий закон Брукса: для руководителя проекта система не должна быть «второй», а если это случилось, то и ему самому, и его окружению необходимо максимально снизить соответствующие риски.
Упрощение концептуальной сложности
До самого красивого никогда не дотянешься.
(Льюис Кэрол.«Алиса в Стране чудес»)
Всемирно известный специалист в области программирования Э.Дейкстра как-то заметил (Edsger Dijkstra, «A discipline of programming», 1-е изд. — М.: Мир, 1978), что «программирование сложно не только из-за больших задач, но и из-за наших маленьких голов».
Как определить, сколько времени потребует задача системного программирования? Прежде всего, нужно учесть, что оценки, полученные при создании отдельных небольших программ, нельзя применять для больших системных продуктов. Даже для небольших программ увеличение размера программы вдвое приводит к увеличению затрат и времени в четыре, а то и в шесть раз. А ведь для больших проектов нужно еще добавить затраты на планирование, составление документации, тестирование, системную интеграцию и обучение. Линейная экстраполяция бессмысленна. Это все равно, что экстраполировать время, за которое возможно пробежать стометровку, и получить, что можно пробежать три километра за пять с половиной минут.
Исследования показывают, что объем работы в больших проектах растет как степенная функция с показателем степени приблизительно 1,5:
Объем работы = (константа) ´ (число командных строк)1,5
Из этой формулы следует, что производительность программиста, измеренная в элементарных операциях, постоянна. Известно также, что число ошибок прямо пропорционально числу командных строк. Следовательно, необходимо выбирать язык программирования как можно более высокого уровня. Статистические данные говорят о том, что при использовании подходящего языка высокого уровня производительность кодирования можно повысить в пять раз.
Программа не перестает изменяться после своей поставки клиенту. Сопровождение и развитие программных систем состоит главным образом из изменений, исправляющих конструктивные дефекты. Очень часто эти изменения включают в себя дополнительные функции, которые видны пользователю.
Общая стоимость сопровождения широко используемой программы, даже если она достаточно стабильна (как, например, системные программы), обычно составляет 40 и более процентов стоимости ее разработки. В случае ПО для бизнеса стоимость сопровождения и развития ПО близка к 100%. На стоимость сопровождения сильно влияет число пользователей, чем больше пользователей, тем больше ошибок они находят.
Главная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20–50 %) влечет появление новой. Поэтому весь процесс идет по принципу «два шага вперед, шаг назад».
Все исправления имеют тенденцию к разрушению структуры, увеличению энтропии и дезорганизации системы. С течением времени все меньше сил тратится на исправление ошибок исходного проекта и все больше – на ликвидацию последствий предыдущих исправлений. Исследования показали, что начиная с какого-то момента, число ошибок в программе перестает снижаться. Кроме того, меняются машины, конфигурации, требования пользователя, так что фактически ни одна система не может оставаться вечной. Становится необходим новый проект, выполненный с нуля.
Правила системной отладки:
Используйте отлаженные компоненты.
Создайте и используйте больше инструментов среды разработки: отладочных тестов, программ, заглушек, генераторов тестовых данных.
Ведите жесткий контроль над изменениями.
При сборке добавляйте компоненты по одному.
При сопровождении уже установленного продукта делайте изменения большими порциями, чтобы периоды стабильности продолжались дольше.
«Серебряной пули» нет
План, что и говорить, был превосходный:
простой и ясный, лучше не придумать.
Недостаток у него был только один:
было совершенно неизвестно,
как привести его в исполнение.
(Льюис Кэрол.«Алиса в Стране чудес»)
Этот доклад Ф. Брукса на конференции 1986 г. в Дублине вызвал большой резонанс(Frederick P.Brooks, TheMythicalMan-Month). Речь идет о методах борьбы с концептуальной сложностью.
Хорошо знакомый программный проект весьма напоминает оборотней из фильма ужасов, считает Брукс. Будучи простым и невинным на вид, он может стать чудищем проваленных графиков работы, раздувшихся бюджетов и неработающих продуктов. Мы ищем серебряную пулю, которая могла бы волшебным образом уложить оборотней наповал. Нечто, способное снизить стоимость программных продуктов так же резко, как снизилась стоимость компьютеров.
Брукс утверждал, что в ближайшее десятилетие после этого доклада (1986 г.) не будет сделано открытий ни в технологии, ни в методах управления, использование которых обещало бы хоть на порядок повысить производительность, надежность и простоту программного обеспечения.
С тех пор прошло почти 30 лет, а его предсказание все еще остается в силе. Панацеи вроде объектно-ориентированного программирования, систем искусственного интеллекта и экспертных систем себя не оправдали. «Серебряной пули» нет, и она вряд ли скоро появится. В качестве панацеи сейчас продвигается идея «облака», однако и она ликвидирует концептуальную сложность лишь частично.
Впрочем, скептицизм – не пессимизм! И хотя Брукс совершенно справедливо считает ошеломляющие прорывы не свойственными самой природе программирования, он указывает на многие перспективные нововведения, дисциплинированное и последовательное внедрение которых действительно может дать многократный рост:
Покупать, а не создавать.
Развитие массового рынка позволяет избежать создания того, что можно купить. Любой «коробочный» продукт намного дешевле купить, чем создавать заново. Кроме того, массовый рынок и распространение программных пакетов привели к появлению метапрограммирования – создания нового слоя ПО, приспосабливающего функции к нуждам определенной группы пользователей пакета (например, внутренний язык программирования в 1С Предприятие). Метапрограммирование значительно повышает производительность программиста.
Уточнение требований и быстрое прототипирование
- как часть запланированных итераций для установления требований к ПО. Это направление предусматривает быстрое создание макета системы, который моделирует главные интерфейсы и выполняет основные функции предполагаемой системы. Назначение макета – показать, как воплощается выбранная концептуальная структура, чтобы клиент мог проверить ее пригодность к использованию и непротиворечивость.
Пошаговая разработка.
Следует органично наращивать (выращивать) программы, а не строить сразу. Сначала систему надо заставить просто выполняться, даже если при этом она не делает ничего полезного, кроме вызова некоторых фиктивных подпрограмм. Затем нужно добавлять к системе все большую функциональность по ходу ее разработки, внедрения и эксплуатации, причем делать это параллельно с тестированием.
Выращивание выдающихся проектировщиков.
Хорошим практическим приемом можно обучить, однако создание программ является творческим процессом. Выдающиеся проекты создаются выдающимися проектировщиками. Поэтому каждая организация, занятая в программировании, должна как можно раньше выявлять и растить выдающихся разработчиков концепций нового поколения.
Стратегия открытых исходных текстов как альтернатива концепции Брукса
Э. Раймонд в своей статье «Собор и базар» (http://project.dovidnyk.info/index.php/programnye- proekty/upravlenieproektamiposozdaniyuprogrammnogoobespecheniya) попытался опровергнуть Брукса, утверждая, якобы стратегия открытых исходных текстов OpenSource, при помощи которой был разработан Linux, полностью опровергает основные положения книги Брукса.
Однако профессор университета в Нью-Джерси Николай Безруков (автор некогда знаменитой «Вирусологии» – первой книги о вирусах на русском языке) в своей статье http://www.linux.org.ru/books/GNU/misc/second-look-at-CatB.htmlойопроверг Э.Раймонда по всем пунктам.
Во-первых, в случае Linux речь идет о переписывании уже существующей системы, когда всем известно, что в точности система делает и из каких модулей должна состоять, отмечает Безруков. При ее разработке не требовалось вырабатывать концепции, создавать спецификации и заниматься проектированием.
Во-вторых, никакой демократии в OpenSource нет и в помине. Дисциплина там очень жесткая. Ее осуществляют высшие модераторы по своему произволу, давая дорогу модулям, разработанным одними разработчиками, и отбрасывая модули, разработанные другими. Занимался этим и Линус Торвальдс – главный модератор проекта Linux.
Лучшее качество программ OpenSource или GNU из-за их всеобщей доступности – это тоже миф, ибо никто не ставит цель выявить в них ошибки. Кроме того, пока еще никем не доказано, что самодеятельное тестирование лучше профессионального. На самом деле серьезных ошибок в Linux и «дыр» в ее безопасности предостаточно, просто никто не пытается их искать с той же тщательностью, с какой их ищут в продуктах корпорации Microsoft, Apple или Google.
2.6. Оценка трудоемкости
Планирование – это самый ответственный для менеджера момент. По Ф.Бруксу, неумение правильно оценить объем проекта является главной причиной срыва сроков разработки.
Для оценки трудоемкости необходимо:
Оценить объем продукта.
Оценить усилия разработчиков, необходимые для создания продукта.
Оценить график работ по проекту.
Оценить финансовые затраты.
Пример истории создания Microsoft Word 1.0 – отличная иллюстрация классической ошибки надежды на то, что все пойдет хорошо (wishfulthinking). Эта ошибка характерна как для тех заказчиков и руководителей разработчиков высшего уровня, которые свято верят, что любая работа может быть выполнена за любое время, стоит только того пожелать.
В 1984 году Билл Гейтс, впечатленный успехами первых текстовых редакторов, приказал дословно «создать лучший в мире текстовый редактор за 12 месяцев». Как выяснилось впоследствии, для подобного проекта, который в результате занял 250000 строк, по нормам необходимо 26 месяцев. Даже если сильно сжать сроки, все равно проект никак нельзя было сделать менее чем за 22 месяца. В результате вышло следующее.
Изотчета Microsoft Corporation: Office Business Unit, 1994
Месяц составления плана
Планируемый срок поставки
Планируемое число дней до поставки
Фактическое число дней до поставки
Относительная ошибка планирования
Дело не только в том, что из-за неправильного планирования первая версия текстового редактора Microsoft Word создавалась 5 лет. Именно неверное планирование работ и попытки выполнить работу в нереальный срок привели к тому, что MS Word до сих пор является чрезвычайно громоздким продуктом со значительным количеством ошибок. Он потребляет для своей работы значительные ресурсы компьютера и резко замедляет работу при редактировании даже не очень длинных документов. Его менее именитые конкуренты куда изящнее, компактнее, мощнее и эффективнее, как, впрочем, и другие продукты, входящие в Microsoft Office. Например, Microsoft Excel является весьма удачным продуктом.
2.7. Типовые причины оптимистических планов
Существуют внешние причины, определяющие срок выполнения проекта: компьютерные выставки, изменения в законодательстве, распродажи.
Менеджеры или заказчики строят планы для случая, если все пойдет хорошо.
Необходимо заключить важный договор с заказчиком.
Разработчики хотят поучаствовать в интересном для них проекте.
Менеджер проекта считает, что под прессингом программисты будут работать лучше.
Давление внешнего заказчика, руководства или службы маркетинга.
Плохая оценка сроков.
Удивительно, что реалистические оценки сроков вообще появляются. Обычно программисты недооценивают свои проекты на 20-30%.
Как же ускорить разработку? Оказывается, чаще всего для быстрой разработки достаточно лишь правильно организовать работу. Быстрая разработка и эффективная разработка – это синонимы.
2.8. Оценка объема работ по функциональным баллам
Функциональные баллы – это специальная величина, которая используется для оценки размера программы. Функциональные баллы легче использовать, чем количество строк или слов программы, и они дают более точную оценку размера программы.
Количество функциональных баллов зависит от следующих величин:
- число входных форм. Сюда входят диалоги, формы, сообщения, посредством которых конечный пользователь или другие программы могут добавлять, удалять или изменять данные программы.
- число выходных форм – экраны, отчеты, графики или сообщения, которые генерирует программа для использования конечным пользователем или другими программами.
- число запросов. Количество комбинаций «ввод/вывод», когда ввод имеет своим результатом немедленный вывод.
- логические внутренние файлы – логические группы данных, которые полностью контролируются программой. Это может быть простой файл или таблица в реляционной базе данных.
- внешние файлы – данные, контролируемые другими программами. Включают любые логические группы данных, которые вводятся или выводятся из программы.
В табл. 2.1. приведено, каким образом может быть подсчитано количество функциональных баллов в программе. Множители взяты на основе данных нескольких тысяч проектов.
Характеристика программы
Низкая сложность
Средняя сложность
Высокая сложность
Число входных форм
Число выходных форм
Число запросов
Логические внутренние файлы
Внешние файлы (интерфейс)
