Обзор и влияние главы Ф. Брукса «Серебряной пули нет»

Введение

Статья Фредерика Брукса «Серебряной пули нет» была опубликована им в 1986 году[1]. Статья широко обсуждалась как раз в тот период, когда проходила компьютерная революция (1970-80е гг.). Персональный компьютер стал появляться в каждом доме, офисе мелких и крупных фирм, в институтах.
Актуальностью данной работы является изучения процесса разработки программного обеспечения, характеристический анализ используемых в разработке приемов и методов, описанных в главе «Серебряной пули нет» в рамках книги «Мифический человеко-месяц».
Основной целью реферата является рассмотреть главу «Серебряной пули нет» в рамках книги «Мифический человеко-месяц», определить содержание главы и провести характеристический анализ.
Задачами реферата являются:
• ознакомиться с главой «Серебряной пули нет» в рамках книги «Мифический человеко-месяц»;
• провести характеристический анализ изложенного в ней материала;
• определить значимость информации, содержащейся в главе;
• сделать выводы и дать рекомендации.
1 Анализ главы Ф.Брукса «Серебряной пули нет»
Условно, создание персонального компьютера можно разделить на две составляющие: разработка «железа» – аппаратной части ПК, и разработка программного обеспечения для ПК.
Именно это и рассматривает в своей статье Ф. Брукс с точки зрения эффективного управления проектом разработки и отражает до сих пор актуальную аксиому о том, что «мы не можем ожидать увеличения прибыли в два раза каждые два года» при разработке ПО, как это происходит с разработкой аппаратной составляющей персонального компьютера.
Брукс делает акцент на детали процесса разработки программного обеспечения, учитывая, что инновации должны быть направлены на решение сложностей, что, в свою очередь, приводит к качественным улучшениям.
Для менеджера проекта, не являющегося инженером или разработчиком, не всегда понятен сам проект и его технологическая составляющая, кроме итогового результата, что делает его совершенно безоружным на этапе разработки программного обеспечения. И такие менеджеры начинают искать методы для понятия и упрощения процесса разработки, а именно «серебряные пули», которыми смогли бы воспользоваться, но таковых нет.
В разработке программного обеспечения существуют свои тонкости и сложности, которые необходимо учитывать. Брукс выделил, что на этапе управления разработкой программного объекта, менеджер проекта должен ориентироваться на решение следующих сложностей:
• использовать массовый рынок, чтобы избежать создания того, что можно купить;
• использовать быстрое макетирование как часть запланированных итераций для установления технических требований к ПО;
• органично наращивать программы, добавляя к системам все большую функциональность по мере их запуска, использования и тестирования;
• выявлять и растить выдающихся разработчиков концепций нового поколения.[2]
Ф.Брукс предполагает, что решение таких задач обязательно приведет к созданию качественного управления проектом, а как следствие, решение проекта в соответствии с его назначением и функциональной принадлежностью.
Так же делается акцент на одну важную деталь – обновление аппаратного обеспечения каждые два года, которое может существенно снизить актуальность будущего программного обеспечения (элементарная потеря актуальности). Так же стоит учитывать, что процесс программирования всегда запаздывает относительно процесса разработки аппаратного обеспечения, т.к. не может учитывать потенциальных изменений в технических характеристиках и потенциальных затрат на производство и разработку.
Брукс условно разделил трудности, с которыми сталкиваются при разработке, на сущности (трудности, присущие природе программирования[3]) и акциденции (трудности, которые сопутствуют производству программного обеспечения[3]).
1.1 Сущность программного объекта

Сущностью программного объекта является конструкция, состоящая из сцепленных вместе концепций: наборов данных, взаимосвязей между элементами данных, алгоритмов и вызовов функций.[2]
К свойствам сущности можно отнести:
• сложность (зависит от размеров, уникальности каждой составляющей подпрограммы, проблема масштабирования ПО и прочее

. Служит причиной технических и административных проблем.);
• согласованность (для качественной работы в различных операционных системах, интегрировании с другим программным обеспечением);
• изменяемость (постоянная модификация программного обеспечения в зависимости от изменений на рынке или свойств аппаратного обеспечения);
• незримость (сложность заключается в визуальном представлении концепции работы программного обеспечения, его иерархии и контроля поэтапной работы).
Брукс считает, что сложность создания программного обеспечения заключается в задании технических требований, проектировании и проверке этой концептуальной конструкции, а не в затратах, связанных с ее представлением и проверкой точности представления. [3]
1.2 Акциденции программного объекта

Акциденция – сложности разработки программного продукта, которые уже были решены или упрощены, которые предлагают упрощенное разработку и продвижение.
К акциденциям Ф.Брукс отнес:
• языки программирования высокого уровня (языки программирования, обладающие абстракциями, структурированностью и иерархичностью, возможностями модульного программирования. Например, язык программирования высокого уровня Ada, очень популярный на тот период);
• объектно-ориентированное программирование (возможность описания объектов, классов и свойств заметно упрощают процесс программирования);
• искусственный интеллект (использование компьютеров в решении задач для ускорения и оптимизации процесса программирования);
• экспертные системы (составляющая часть ИИ, которая призвана обеспечить правила и требования необходимые для приема, обработки и результата работы программного обеспечения);
• «автоматическое» программирование (задание задачи и автоматическое получение ее решения, своего рода эфимизм в программировании);
• графическое программирование (использование компьютерной графики в программировании);
• верификация программ (устранение ошибок на этапе тестирования, соотношение частоты ошибки к периоду работы без ошибок);
• среды программирования и инструменты (редакторы для упрощенного программирования);
• рабочие станции (совершенствование аппаратуры ведет к совершенствованию программных возможностей).
• быстрое макетирование (моделирование главных интерфейсов, функций предполагаемой системы);
Несмотря на то, что на данный момент существует много акциденционных процессов, они ограничены производительностью, стоимостью и прочее. Поэтому иногда удобнее использовать уже готовые программы, чем создавать свои, так как можно столкнуться с проблемой – что решить, а что разрабатывать.
Так же немаловажной концепцией может стать наращивание программного обеспечения со временем и, тем самым, его совершенство и удобство для использования. Но с этой теорией тоже нельзя пользоваться постоянно, так как в определенный момент может получиться огромная структура данных, которая хоть и будет многозадачной, но из-за своих технических и аппаратных требований будет не эффективной и малопроизводительной среду для работы.
Самой важной частью будет хорошие и качественные разработчики. Мало иметь хорошее программное обеспечение для разработки, необходимо иметь грамотных и обученных людей, которые будут на нем работать