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

1. Марри Кантор: Управление программными проектамиE.A.2010

2. I. Успешный продуктКритерииПригодный

3. Отказоустойчивый

4. Восстанавливаемый

5. Надёжный

6. РасширяемыйI. Успешный продуктНе попадайте в ловушку бездефектностиЕсли поиск дефекта займёт 40 часов тестирования двадцатью программистами, вы можете оставить это занятие и выпускать продукт.Вы должны оценивать, какой уровень качества «по карману» для той или иной разработки.

7. II. Риски при разработке ПОКакие риски бываютРиск неправильного планирования

8. Риск превышения стоимости

9. Риск потерь качестваIII. Экономическая модель разработки ПОКак определить необходимые усилия Усилие = (коллектив) * (средства) * (сложность)процессКоллективСложностьПоказатель тем больше, чем больше проблем в коллективе: неопытность сотрудников, нововведения требующиеся от разработчиков ....Количественные показатели (количество строк кода, объёмы документации и т.п.)СредстваПроцессПоказатель тем меньше, чем больше эффективность, приобретённая или вследствие автоматизации процесса.Этот показатель равен количеству необходимых взаимодействий между разработчиками.

10. III. Экономическая модель разработки ПО... и как уменьшить величину тудозатратУсилие = (коллектив) * (средства) * (сложность)процесс< Коллектив< СложностьНаём и обучение,ограничение нововведенийУменьшение сложности< Средства< ПроцессАвтоматизация повседневных задачУменьшение количества взаимодействий между участниками

11. IV. Уменьшение трудозатрат1. Упрощение усилийРазбейте большие задачи на несколько меньших

12. Применение объектно-ориентированной технологии

13. Применение пошаговой разработки

14. Не создавайте последовательность действий

15. Помните о правиле 80/20IV. Уменьшение трудозатрат2. Уменьшение величины усилийОграничение функциональности продукта

16. Достижение функциональности при меньшем количестве кодаПовторное использование кода

17. Повторное использование архитектуры

18. Избегайте создания лишних материаловIV. Уменьшение трудозатрат3. Повышение эффективности работыВложение средств в создание архитектуры

19. Направление усилий коллектива на создание архитектуры подсистемСоздание надлежащего продукта

20. Использование и соблюдение стандарта UMLIV. Уменьшение трудозатрат4. Автоматизация стандартных задачИнструментальная среда(редакторы кода, средства автоматизации тестирования, компоновщики,системы контроля версий)

21. Автоматизация взаимодействий(создание документации, привычка документировать код)IV. Уменьшение трудозатрат5. Круговое проектирование«В любой момент времени продукт должен быть сконструировант так, как он спроектирован, и спроектирован так, как он сконструирован»Другими словами, продукт и документация по проектированию должны быть полностью совместимы.

22. IV. Уменьшение трудозатрат6. Сверхурочная работа?.. это путь, по которому не нужно идти:возрастает сложность

23. уменьшается эффективность

24. не остаётся резервов на решение неожиданно возникающих проблем