Книги: [Классика] [Базы данных] [Internet/WWW] [Сети] [Программирование] [UNIX] [Windows] [Безопасность] [Графика] [Software Engineering] [ERP-системы] [Hardware]
Предисловие
Эта книга прокладывает путь к следующему поколению методов управления проектами по созданию программного обеспечения (ПО). Многие организации остаются верными модели "водопада", поскольку, несмотря на все свои недостатки, она содержит наиболее полно разработанные руководящие указания о том, как поступать в каждой конкретной ситуации при создании ПО.
До недавнего времени непросто было найти подробное описание альтернативного подхода к управлению, который позволял бы решать такие вопросы, как интеграция компонентов, повторное использование ПО, управление рисками и эволюционные/итерационные/спиральные процессы, при создании ПО. В этой книге предлагается новый проверенный на практике подход и даются указания по его использованию.
Уокер Ройс разработал и опробовал данный подход к управлению созданием ПО в процессе своего участия в большом успешном проекте CCPDS-R, выполненном компанией TRW для военно-воздушных сил Соединенных Штатов. Этот подход был отточен и обобщен при осуществлении самых разнообразных правительственных, аэрокосмических и коммерческих проектов в корпорации Rational.
В главах с 1 по 4 дается обоснование нового подхода; показано, каким образом он позволяет управлять ключевыми для экономики создания ПО моментами по сравнению с традиционным подходом к управлению подобными проектами. Он обеспечивает, во-первых, уменьшение объема ПО, которое требуется создать, во-вторых, снижение количества переделок за счет совершенствования процессов и работы команды и, в-третьих, уменьшение интенсивности труда за счет его автоматизации.
В главах с 5 по 10 представлены особенности новой организации жизненного цикла ПО, которые к тому же служат основой унифицированного процесса создания ПО корпорации Rational (Rational Unified Process).
В нем сочетаются гибкость спиральной модели с дисциплиной управления рисками и набором основных стадий и контрольных точек жизненного цикла ПО, которые касаются основных управленческих решений, принимаемых в процессе создания ПО.
Подобно нашему подходу с анкерными точками (Anchor Point), принятому в University of Southern California (USC), одной из основных контрольных точек жизненного цикла является принятие решения об использовании при разработке архитектуры ПО результатов бизнес-анализа (или о не использовании - в этом случае проект благополучно заканчивается ничем). Контрольная точка, совпадающая с окончанием разработки архитектуры, включает в себя принятие решения о переходе к полномасштабной разработке, которая основывается на создании и описании стабильной архитектуры и на разрешении вопросов относительно всех основных источников риска. Контрольная точка, соответствующая обретению продуктом начальных функциональных возможностей, включает в себя решение о начале бета-тестирования продукта с участием внешних пользователей или эквивалентной ему процедуры.
Автор показывает, чем эти контрольные точки отличаются от точек традиционного подхода, ориентированного на создание документации или на написание кода. Ключевые результаты, материализуемые в ходе создания продукта (требования, проектные решения, реализация, ввод в действие), согласованно изменяются и соединяются в единое целое таким способом, который не противоречит целям проекта и принятой в рамках этого проекта стратегии управления рисками.
В главах с 10 по 14 автор рассказывает, как можно удостовериться в том, что рабочие продукты, касающиеся управления проектом, тоже изменяются согласованно, соединяясь в единое целое. Сюда входят планы проекта и соответствующие оценки затрат финансов и времени, деятельность по организации и созданию команды, параметры проекта, оснащение инструментальными средствами и процессы контроля. Особенно примечательной является глава 14. В ней не только объясняется тот факт, что решения, принимаемые в области управления, зависят от ситуации, но также даются указанию относительно того, каким образом следует учитывать масштаб проекта, культуру команды, зрелость процесса, риск, заложенный в архитектуре, и опыт, имеющийся в данной предметной области.
В главах с 15 по 17 автор пытается понять, в каком направлении движутся лучшие разработчики ПО в своей практике: в сторону управления продуктовой линией, в сторону разработки по "круговому" принципу (round-trip engineering) или в сторону уменьшения размеров команд разработчиков, в которых менеджеры являются одновременно исполнителями, а контроль за качеством становится делом каждого, В приложениях рассматриваются современная практика управления разработкой ПО, семейство моделей для оценки стоимости СОСОМО и СОСОМО II, а также модель технологической зрелости (Capability Maturity Model, CMM), предложенная Институтом программной инженерии (Software Engineering Institute, SEI). В приложении D дается убедительный практический пример успешного использования данного подхода при осуществлении широкомасштабного, технически сложного проекта CCPDS-R.
Ройс имеет свежий непредвзятый взгляд на некоторые причуды, глупости и излишества в сфере создания ПО. Это находит свое отражение в "практических" разделах, посвященных таким темам, как оценка стоимости ПС), проверки, рабочие продукты, планирование и метрики. Не все согласятся с мнением автора, однако его оценки являются весьма резкими и способствуют развитию дискуссии.
Мне чрезвычайно повезло в том, что довелось поработать вместе с Уокером Ройсом и с его отцом Уинстоном Ройсом, изучать их опыт и общаться с ними в процессе изменения их путеводных идей.
Барри Боэм
Директор USC Center for Software Engineering
Апрель 1998
Начало
Полное содержание
Введение
Структура книги
Заказать книгу в магазине "Мистраль"
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
