Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Управление проектами и рискамии (ответы).docx
Скачиваний:
8
Добавлен:
03.08.2019
Размер:
72.03 Кб
Скачать
  1. Сформулируйте возможную проблему “подавления творческой активности разработчиков архитекторами”. Каково ваше отношение к ней?

Проблема состоит в том, что архитекторы получат все радости творчества и заблокируют изобретательность исполнителей. Брукс говорит, что при таком подходе разработка также является в высшей степени творческой деятельностью.

Возможность проявить творчество и изобретательность при разработке

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

По сути, я с ним согласен, излишний простор, иногда является лишним. Когда разумно ограничивают это хорошо.

  1. Планируйте на выброс”. В чем суть этого утверждения?

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

сначала и построить перепроектированную программу, в которой эти проблемы решены.

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

Поэтому планируйте выбросить первую версию — вам все равно придется это сделать.

  1. Msf и другие методологии говорят о “вехах”. События с какой отличительной чертой должны приниматься в качестве “вех”?

«Вехи»  — ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата. Этот результат может быть оценен и проанализирован, что подразумевает ответы на вопросы: «Пришла ли проектная группа к однозначному пониманию целей и рамок проекта?», «В достаточной ли степени готов план действий?», «Соответствует ли продукт утвержденной спецификации?», «Удовлетворяет ли решение нужды заказчика?» и т. д.

  1. Две отличительные черты разработки программного обеспечения по Бруксу - Согласованность и Изменяемость. Каким образом они усложняют разработку программного обеспечения?

Согласованность. Люди, связанные с программированием, не одиноки в проблемах сложности. Физика имеет дело с объектами чрезвычайной сложности даже на уровне элементарных частиц. Однако физик работает в твердой уверенности, что можно найти общие принципы, будь то кварки или общая теория поля. Эйнштейн неоднократно утверждал, что природа должна иметь простые объяснения, поскольку Богу не свойственны капризность и произвол.

У разработчика программного обеспечения нет такой утешительной веры.

Сложность, с которой он должен совладать, по большей части является

произвольной, необоснованно вызванной многочисленными человеческими

установлениями и системами, которым должны удовлетворить его интерфейсы.

Системы различаются интерфейсами и меняются во времени не в силу

необходимости, а лишь потому, что были созданы не Богом, а разными людьми.

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

Изменяемость. Программные объекты постоянно подвержены изменениям. Конечно, это относится и к зданиям, автомобилям, компьютерам. Но произведенные вещи редко подвергаются изменениям после изготовления. Их заменяют новые модели, или существенные изменения включают в более поздние серийные экземпляры того же базового проекта. Отзывы у потребителей автомобилей на практике встречаются весьма редко, а изменения работающих компьютеров еще реже. То и другое случается значительно реже, чем модификация работающего программного

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

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

Во-вторых, удачный программный продукт живет дольше обычного срока

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

Короче, программный продукт встроен в культурную матрицу приложений,

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