Поясните, наличия, каких умений Закон Дырявых Абстракций требует от программиста.

Сформулируйте и поясните закон Брукса

Кратко этот закон звучит так:

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

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

Происходит это из-за:

· Неоправданного оптимизма

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

· Ошибка в самой единице измерения: человеко-месяц.

Стоимость действительно измеряется по формуле, произведение числа сотрудников на затраченные месяцы.

Но это только в случае, если процесс протекает без взаимосвязи.

Например, при сбора урожая.

Если задачу нельзя разбить на части, то тут тоже увеличение затрат не окажет влияния на график.

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

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

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

· И самое главное начинают ошибочно добавлять новых людей.

Поясните, наличия, каких умений Закон Дырявых Абстракций требует от программиста.

"Закон дырявых абстракций"- это когда переход на более высокий уровень облегчает жизнь разработчика, но иногда приходится заглядывать глубже.

То есть хороший программист должен уметь «копаться в кишках».

3. Расскажите, что означает “вхождение в поток”.

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

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

По мнению Сполски, с входом в потом, может помочь, так называемая тактика «Огонь и движение». Он взял это название из военной тематики, когда он служил в Израиле парашютистом, генерал сообщил им, что лучшая тактика боя это: огонь и движение. Движетесь в сторону противника и при этом ведете огонь, противник вынужден спрятать голову, поэтому он не может вести ответный огонь. Движение позволяет подойти к врагу и захватить территорию. Если же ничего не делать, то противник откроет огонь и убьет вас.

По его мнению по этому же принципу нужно и работать. Нужно начать и хотя бы 15 минут в день уделять работе. Кстати в этом он приводит ещё плюс парного программирования, при таком подходе, партнеры могут друг друга подталкивать к работе.

4. Почему выдающихся программистов эффективнее “вербовать” в начале или середине обучения в университете, а не в конце?

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

5. Чем работа над одной задачей двух программистов в “хирургической бригаде” отличается от работы двух программистов в “классической” технологии?

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

При такой системе в этой команде есть:

Хирург. Миллз называет его главным программистом. Он лично определяет

технические условия на функциональность и эксплуатационные характеристики

программы, проектирует ее, пишет код, отлаживает его и составляет документацию.

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

Второй пилот. Это второе «я» хирурга, может выполнять любую его работу, но менее опытен. Его главная задача — участвовать в проектировании, где он должен думать, обсуждать и оценивать. Хирург испытывает на нем свои идеи, но не связан его предложениями. Он хорошо знает весь код программы. Он исследует возможности альтернативных стратегий программирования. Он, очевидно, подстраховывает на случай какой-либо беды с хирургом. Он может даже заниматься написанием кода, но не несет ответственности за какую-либо его часть.

Администратор. Хирург — начальник, и ему принадлежит последнее слово в

отношении персонала, прибавок к жалованью, помещений и т.п., но на эти дела он

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

Редактор. Обязанность разработки документации лежит на хирурге. Чтобы она была максимально понятна, он должен писать ее сам. Это относится к описаниям,

предназначенных как для внешнего, так и для внутреннего использования. Задача

редактора — взять созданный хирургом черновик или запись под диктовку,

критически переработать, снабдить ссылками и библиографией, проработать

несколько версий и обеспечить публикацию.

Два секретаря. Администратору и редактору нужны секретари. Секретарь

администратора обрабатывает переписку, связанную с проектом, а также документы, не относящиеся к продукту.

Делопроизводитель. Он отвечает за регистрацию всех технических данных бригады в библиотеке программного продукта.

Инструментальщик. Благодаря возможности в любое время редактировать файлы и тексты и пользоваться службой интерактивной отладки команде редко требуется

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

Инструментальщик обычно пишет специализированные утилиты,

каталогизированные процедуры, макробиблиотеки.

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

Языковед. Языковед может найти эффективные способы использования языка для решения сложных, неясных и хитроумных задач. Иногда ему требуется провести небольшое исследование (два-три дня) для нахождения удачной технологии. Один языковед может работать с двумя или тремя хирургами.

Вот таким образом 10 человек могут выполнять хорошо дифференцированные и

специализированные роли в команде программистов, организованной по образцу

операционной бригады.

Различия между классической формой программирования и таким подходом состоят:

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

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

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

6. Почему личные кабинеты могли бы увеличить эффективность работы программистов?

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

7. Программист осуществляет свои построения на основе чистого мышления. Какое отношение это имеет к оценке сроков задач?

В основе планирования разработки программ лежит ложное допущение, что

все будет хорошо, т.е. каждая задача займет столько времени, сколько «должна» занять.

Брукс, ссылаясь на книгу Доротти Сэйерс, говорит, что в творческой деятельности выделяют: замысел, реализацию и взаимодействие.

Соответственно, книга, компьютер или программа сначала

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

Творение будет завершено, когда кто-либо прочтет книгу, воспользуется

компьютером или запустит программу, тем самым вступив во взаимодействие с

разумом их создателя.

Во многих видах творческой деятельность материал с трудом поддается обработке.

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

Реализация, таким образом, требует сил и времени как из-за физического

материала, так и ввиду неадекватности основополагающих идей. Большую часть

затруднений при реализации мы склонны объяснять недостатками физического

материала.

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

ошибочности наших идей возникают ошибки в программах.

Для отдельной задачи допущение, что все буде хорошо, оказывает эффект на график работ

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

8. Почему средняя производительность программистов резко падает в крупных проектах по сравнению с малыми?

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

9. Что такое “концептуальная целостность”? Опишите это своими словами.

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

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

Пример такой разработки это «операционная бригада». Когда главный программист берет на себя всю работу по планированию и реализацию.

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

10. Сильно ли различается производительность программистов? Приведите пример(ы).

Менеджеры программных проектов давно поняли, что хорошие и плохие

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

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

соотношение между лучшими и худшими результатами составило примерно 10:1 по производительности труда и 5:1 по скорости работы программ и требуемой для них памяти! Короче, программист, зарабатывающий 20 тысяч долларов в год, может быть в десять раз продуктивнее программиста, зарабатывающего 10 тысяч долларов.

Правда, возможно и обратное. Полученные данные не выявили какой-либо

корреляции между стажем работы и производительностью. (Я не уверен, что это всегда справедливо.)

11. Что отличает программу от программного продукта? Программу от программной системы?

А   Программа	А   Программный комплекс     (интерфейсы, системная интеграция)
А   Программный продукт   (обобщение, тестирование, документирование, сопровождение)	А   Система

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

Есть два способа, которыми программу можно превратить в более полезный, но и более дорогой объект. Эти два способа представлены по краям рисунка.

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

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

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

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

12. Приведите примеры линейно разделимой и линейно неразделимой задач.

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

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

13. Как обмен информаций и получение первоначального опыта новыми сотрудниками влияет на время, затрачиваемое на разработку?

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

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

С обменом данными дело обстоит хуже. Если все части задания должны быть

отдельно скоординированы между собой, то затраты возрастают как n(n-2)/2. Для трех работников требуется втрое больше попарного общения, чем для двух, для четырех — вшестеро. Если помимо этого возникает необходимость в совещаниях трех, четырех и т.д. работников для совместного решения вопросов, положение становится еще хуже. Дополнительные затраты на обмен данными могут полностью обесценить результат дробления исходной задачи.

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

14. Стоит ли давать практикантам серьезные задачи?

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

15. В чем разница между обычным и системным тестированием?

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

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

16. Что такое архитектура, и чем она отличается от разработки?

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

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

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

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

17. Сформулируйте возможную проблему “подавления творческой активности разработчиков архитекторами”. Каково ваше отношение к ней?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21. Чем программный продукт сложнее, например, автомобиля?

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

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

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

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

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

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

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

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

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

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

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

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

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

Незримость.Программный продукт невидим и невизуализуем. Геометрические

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

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

22. В чем суть итеративной (пошаговой) разработки?

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

На следующем шаге мы навешиваем модуль ввода (возможно, примитивный) и

модуль вывода. Работающая система, делающая нечто, возможно,

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

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

Поскольку в любой момент времени у нас есть работающая система:

· можно очень рано начать тестирование пользователями;

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

23. В чем психологическое преимущество итеративной разработки?

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

24. Почему принцип “планируйте на выброс” был признан устаревшим в 80-е?

Самой большой ошибкой этой концепции является косвенное принятие классической последовательности — в виде каскада — модели создания программы.

В классической статье 1970 года Винтон Ройс усовершенствовал последовательную модель путем:

· добавления некоторой обратной связи с предшествующими этапами;

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

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

«Планируйте на выброс» действительно резко нападает на это заблуждение. Ошибка не в диагнозе, а в лекарстве. Сейчас я предположил, что первую систему можно отбросить или перепроектировать не всю целиком, а по частям. Хорошо, если это

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

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

пользователей.

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

Каскадная модель:

· На каждом этапе формируется законченный набор проектной документации – полный и согласованный

· Выполняемая в логической последовательности этапы работ позволяет планировать сроки завершения

· Каскадная модель исходит из того, что большая часть ошибок будет сосредоточена в реализации, а потому их устранение проходит равномерно по мере их возникновения

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

25. Назовите несколько из Top-10 рисков IT от Барри Боэма.

Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков:

1. Дефицит специалистов.

2. Нереалистичные сроки и бюджет.

3. Реализация несоответствующей функциональности.

4. Разработка неправильного пользовательского интерфейса.

5. “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.

6. Непрекращающийся поток изменений.

7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.

8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

9. Недостаточная производительность получаемой системы.

10. “Разрыв” в квалификации специалистов разных областей знаний.

Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.

26. Чем спиральная модель отличается от итеративной разработки?

Спиральная модель, предложенная Барри Боэмом в 1988 году, стала существенным прорывом в понимании природы разработки ПО. Она представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное проектирование. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует десять наиболее распространённых (по приоритетам) рисков:

1. Дефицит специалистов.

2. Нереалистичные сроки и бюджет.

3. Реализация несоответствующей функциональности.

4. Разработка неправильного пользовательского интерфейса.

5. «Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.

6. Непрекращающийся поток изменений.

7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.

8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

9. Недостаточная производительность получаемой системы.

10. «Разрыв» в квалификации специалистов разных областей знаний.

Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.

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

§ оценка и разрешение рисков,

§ определение целей,

§ разработка и тестирование,

§ планирование.

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

Спиральная модель ориентирована на большие, дорогостоящие и сложные проекты.

27. Программное обеспечение тиражируется практически бесплатно. Дает ли это дополнительные основания привлекать лучших спецов к его написанию?

Так как проект делится на копии, а ПО тиражируется бесплатно, то привлечение спецов становится выгодным делом.

Первоклассным специалистам нужно платить больше, однако и эффект от продукта будет намного выше.

28. Чем плохи генераторы кода?

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

29. Где искать выдающихся разработчиков?

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

Так же полезно следить за победителями олимпиад.

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

30. Приведите пример вопроса, который не следует задавать кандидатам на собеседовании.

Задавать чисто технические вопросы.

Типа: «А как реализовать функцию отмывки денег в системе?»