Назад к книге «Ключевые идеи книги: Мифический человеко-месяц, или Как создаются программные системы. Фредерик Брукс» [М. Иванов]

Ключевые идеи книги: Мифический человеко-месяц, или Как создаются программные системы. Фредерик Брукс

Smart Reading

Smart Reading. Ценные идеи из лучших книг

Это саммари – сокращенная версия книги Фредерика Брукса «Мифический человеко-месяц, или Как создаются программные системы». Только самые ценные мысли, идеи, кейсы, примеры.

В 1960-е IBM была ведущим в мире разработчиком программного обеспечения, ее проект IBM System/360 – ведущим проектом своего времени, а Фредерик Брукс – отцом этого проекта. Как и все менеджеры, Брукс сначала хотел ускорить проект, пригласив к участию в нем больше сотрудников. Как и все менеджеры, он вскоре понял, что этот прием не работает. Что Брукс сделал не как все, так это не повторил собственных ошибок – в результате IBM System/360 вышел в свет, а человечество познакомилось с первыми универсальными компьютерами. Совместимые с System/360 компьютеры IBM System Z выпускаются до сих пор – абсолютный рекорд совместимости. Что пошло не так в далекие 1960-е, как Брукс это исправил и почему его уроки актуальны через десятки лет, в совсем другую компьютерную эпоху?

Smart Reading

Ключевые идеи книги: Мифический человеко-месяц, или Как создаются программные системы. Фредерик Брукс

Мифический человеко-месяц, или Как создаются программные системы

Автор:

Frederick P. Brooks

Оригинальное название:

The Mythical Man-Month: Essays on Software Engineering

www.smartreading.ru (http://www.smartreading.ru/)

Из чего состоит сложность

«Мифический человеко-месяц» был написан тогда, когда человечество и не мечтало о персональном компьютере в каждом доме. Книга приблизила эту возможность. Из 1960–1970-х неразличимы айфоны и беспроводная связь, однако принципы управления сложными проектами, которые сформулировал в те годы молодой ученый Фредерик Брукс, работавший тогда в передовой сфере кибернетики – создании OS/360 в IBM, – могут быть полезны и по сей день. Мы подготовили саммари этой замечательной книги с комментариями руководителя разработки Smart Reading Вячеслава Никулина.

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

Программа и программный продукт – не одно и то же. Программный продукт отличается от программы:

? максимально обобщенным диапазоном и видом входных данных;

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

? подробной документацией.

Создание программного продукта требует в три раза больше времени, чем программа. При этом программное обеспечение (ПО) – одно из самых сложных творений человека, и с этой сложностью нелегко совладать. Мощным стимулом для повышения продуктивности ПО было широкое использование языков высокого уровня[1 - Роль продюсера сейчас называется teamlead.] (исследователи приписывают этому фактору пятикратный рост продуктивности ПО).

Свою роль сыграли и унифицированные среды программирования. И все-таки ПО можно упрощать лишь до определенного предела, который ставят четыре условия:

1) сложность (огромное количество программных конфигураций затрудняет их описание и тестирование);

2) подчиненность форме (интерфейсы создаваемого ПО должны подчиняться многообразию человеческих институтов и систем, для которых и создаются);

3) изменчивость (ПО функционально, а функциональность – то, что в наибольшей степени подвержено изменениям в связи с быстро меняющейся реальностью);

4) невидимость (реальность ПО не встроена в пространство, ее трудно представить в том смысле, в каком, допустим, Земля отражена на географических картах, визуализировать ПО без принципиального упрощения трудно).

Объективные трудности, однако, можно минимизировать, если организоват