?

Log in

No account? Create an account

Вс, 3 авг, 2014, 16:15
Книги: июль

Барри Боэм, «Инженерное проектирование программного обеспечения»

Книга 1981 года, в оригинале называется Software Engineering Economics. Рассматриваются модели оценки стоимости разработки и сопровождения программного обеспечения с упором на КОМОСТ (конструктивная модель стоимости, в оригинале COCOMO). Попутно делается экскурс в методы анализа решений (тут и теория игр, и линейное программирование, и математическая статистика) и в управление проектами (сетевые графики, критические пути, диаграммы Ганта).

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

  • При разработке ПО надо учитывать не только технические, но и экономические и социальные задачи. Иными словами, обычно надо менять сам бизнес-процесс, а не пытаться автоматизировать старый.
  • Стоимость аппаратуры падает, стоимость ПО растет. Сопровождение стоит дороже, чем разработка (50–70% от общих затрат на жизненный цикл).
  • Стремление к успеху — сильный мотиватор программистов. Если определить успех в терминах требуемых проектом результатов, для достижения будут приложены все усилия. Но различные цели противоречат друг другу (например, стремление уменьшить трудозатраты и сроки негативно скажется на ясности кода, эффективности...). Необходимо постоянное разрешение противоречий.
  • Нет единого метода разработки на все случаи жизни. Надо владеть многими и выбирать в зависимости от ситуации.
  • Основные проблемы проектов: плохое планирование — 50%, недостатки контроля проекта — 34%, технические факторы — 15%.
  • Отрицательный эффект масштаба. Наиболее действенный способ — уменьшение масштаба (итерационная разработка, прототипы, отказ от фич).
  • Принцип максимизации прибыли работает, только если все существенные компоненты эффективности (удовлетворенность разработчиков, доброжелательность заказчиков, легкость управления системой и т. д.) будут представлены в денежной форме и включены в функцию общей стоимости.
  • Для большинства руководителей проектов страх потерь значительно сильнее возможности получения выгоды.
  • Для оценки надо использовать разные методы: КОМОСТ, экспертная оцена, оценка по аналогии... Важно не только получить независимые оценки, но и исследовать причины их расхождения.
  • «Для получения надежной оценки стоимости ПО необходимо сделать гораздо больше, нежели просто подставить в готовую формулу числовые значения и получить результат. ...сама эта работа является минипроектом и, следовательно, должна планироваться, подвергаться контролю и выполняться до конца».
  • Оценка стоимости должна сопровождаться указанием степени ее неопределенности.
  • «Обычно такой диалог [про бизнес-необходимость дать поспешную оценку] ведет к чрезвычайно неточной оценке стоимости ПО, которая становится основой утвержденного задания (обычно недооцененного) для многих ничего не подозревающих разработчиков ПО, заслуживающих лучшей участи».
  • «Лучший способ определить, насколько оцениваемой является спецификация на ПО, — это выяснить, насколько она тестируема. Спецификация тестируема в такой степени, в какой кто-либо может построить ясный тест, дающий ответ да или нет и определяющий соответствие разрабатываемого ПО данной спецификации. Для тестируемости спецификация должна быть конкретной, недвусмысленной и обладать по возможности количественными характеристиками. ... Для устранения неопределенности и неоднозначности спецификаций, а также для обеспечения их тестируемости часто требуется много дополнительных усилий. Однако такие затраты обычно хорошо окупаются...».
  • Подробное исследование приводит к лучшему пониманию. Чем больше число частей оцениваемого ПО, тем меньше отклонение итоговой оценки. Сильная тенденция оценивать наиболее заметные компоненты и недооценивать или забывать второстепенные — одна из главных причин недооценки.
  • «Получение формулы для оценки размера ПО во многом сходно с определением формулы для оценки объема литературного произведения. Обе относятся к изделиям с потенциально неограниченными уровнями детализации, которые трудно представить в виде, пригодном для оценивания размера». Кстати, про сравнение программ и литературы.
  • Главные причины неооценки: человек оптимистичен и хочет нравиться; человек склонен не полностью учитывать предыдущий опыт; как правило, люди не знакомы со всем объемом работы.
  • «Коммерческий директор, чье вознаграждение связано с заключением договора, вероятнее всего будет оптимистом. Руководитель проекта, ответственный за выполнение контракта в рамках бюджета, с не меньшей вероятностью окажется пессимистом».
  • «Оценку по Паркинсону [работа стремиться захватить все доступные ресурсы, поэтому оценка = люди × сроки] не рекомендуется применять. Такая оценка приводит к порочной практике разработки ПО».
  • «Метод конкурентных цен обеспечил большое число заказов на ПО многим программистским фирмам. ... Неизбежным результатом явилось то, что деньги и сроки кончились раньше, чем завершилась работа, отношения испорчены, принимаются компромиссные решения относительно поставки ПО, и многие программисты затратили массу усилий, чтобы спасти работу от полного провала».
  • Чтение, анализ, совещания и согласования составляют 40% затрат труда на разработку. Обучение, личные дела, общение — 30–50%.
  • «Для уменьшения сроков разработки есть ряд путей, с помощью которых руководство может добиться некоторого ускорения разработки за счет увеличения стоимости... Тем не менее есть предел сокращению сроков... Этот предел приходится примерно на 75% номинального срока разработки».
  • Меры сложности: мера Холстеда, цикломатическая мера Маккейба, число строк. «Конечно, следует быть осторожным, чтобы не ввести разработчиков в соблазн писать больше строк кода, чем того требует применение изделия».
  • «...в среднем проект во время работы над ним претерпевает 25% изменений в требованиях к ПО».
  • 90-процентный синдром. Когда программист оценивает готовность как 90%, нужно еще примерно столько же времени на завершение работы.
  • «Оценивание программного проекта и управление разработкой будут способствовать его развитию, если все идет по плану. Однако для больших проектов наблюдаются значительные отклонения от планов. ... При столкновении с такой неразберихой возрастающего отклонения от основного плана у заказчика и руководителя проектом часто возникают проблемы обеспечения общего развития проекта и, в частности, перед ними ставится задача оценивания затрат на завершение работы».
  • «Невозможно добиться значительного повышения производительности разработок без полной поддержки высшего руководства. Руководство может, например, дифференцировано повышать зарплату, отстранять неподходящих исполнителей, обеспечивать соблюдение дисциплины, отстаивать интересы разработчиков при установлении заказчиком нереальных сроков или изменений требований».