Пользователь
0,0
рейтинг
30 ноября 2011 в 05:14

Управление → Разработка ПО: 2. Наследство

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



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

Однако, происходит некоторая подмена причин этого знакомства. Да, эта область в чем-то похожа, в первую очередь наличием понятий “требования”, “проектирование”, “проект”, “строительство” (construction), “контроль качества”, “человеко-часы”, “работы”, “сроки”, а сам процесс развивается от экономической потребности и идеи до некого конечного продукта. Но основная причина того, что строительство является хорошей аналогией в том, что это наглядная аналогия.

(В качестве иллюстрации фотография проекта А.Гауди «Sagrada Familia», степень выхода которого за сроки и бюджет до сих пор не могут даже приблизительно оценить)


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

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

Но строительство относится к материальному производству и это означает, что тиражирование ограниченно возможно только на уровне апробированных сочетаний технико-экономических показателей и проектирования, которое занимает не очень большие 1%-15% от стоимости (и гораздо меньший процент от объема в человеко-часах) работ, а остальная часть процесса создания отличается в корне.

Цели подобного материального производства и требования к продукту относительно просто задать, так как измерение материального мира достаточно устоявшаяся область. 8 этажей означает 8 этажей за очень редкими исключениями, нагрузка в 150 килограмм на метр может увеличиться до предельных 300 килограмм или среднеэксплуатационных 50 но не превратиться в десять тон на километр.

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

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

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

Мало похоже и то, как влияет на процесс бюджет. Если у нас оказывается маленький санузел или низкий потолок, это вовсе не означает что архитектор идиот или у строителя оторвался кусок рулетки. Просто это низкобюджетный проект, так как потенциальный клиент не готов платить за большее. (Часто ли вам попадались жилые здания с санузлами, в которые нельзя войти или потолком с высотой полтора метра? А сервер, который не выдержал нагрузки?).

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

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

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

В следующей заметке я хочу рассмотреть, что становится основным камнем преткновения при переносе существующих каскадных методик в область разработки и оценки ПО
mrjj @mrjj
карма
100,7
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Управление

Комментарии (11)

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

    В строительстве прогресс идет более медленными темпами. В этой отрасли есть время собрать камни. При разработке ПО инструменты, технологии, окружение и прочее меняются очень стремительно. То что использовалось 10 лет назад, уже с трудом может быть использовано сегодня в новой разработке. В строительстве и 40 лет не помеха.
  • +9
    Добавлю из личного опыта. На конференциях и прочих мероприятиях, где общаются архитекторы ПО, модно сравнивать разработку ПО со строительством зданий. Так что я за годы выработал набор контраргументов, дабы было о чем пиво пить.

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

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

    Вот такая вот беда. Как сказал на одной из конференций умудренны опытом докладчик — «справочник по архитектуре ПО — это кулинарная книга с рецептами, ингридиенты для которых были в единственном количестве».
    • 0
      Ну, не совсем верно.
      Набор инструментов в разработке ПО более-менее стабилен в течение пары лет.
      Да, новые технологии появляются, старые улучшаются, но не обязательно же все сразу внедрять.
      У нас есть заготовки частей каркаса (framework'и), у которых заданы правила, по которым их можно соединять друг с другом. А вот какие части выбрать и как их соединять, какую делать начинку — это всегда разное, увы.
      И еще: программный продукт лучше соотносить не с законченным зданием, а с заселенным.
      В каждой квартире свой ремонт, кое-где ремонта уже 10 лет не было, и нет денег и времени, чтобы его сделать, и т.д. В подъезде обваливается штукатурка, стены оказываются изрисованными, косметический ремонт спасает ненадолго, и т.д.
      Но это не мешает в этом доме жить, хотя многое и не нравится.
      IMHO, этот процесс уже довольно точно соответствует реальной жизни проекта.

      И цена координальных изменений в ПО примерно соответствует цене перестройки части здания (а давайте на крыше бассейн сделаем?)
    • +1
      >В разработке софта опыт и удачные решения накапливаются граздо хуже, потому что каждая новая программа не похожа не предыдущие.

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

      Например в абстрактном проекте сначала развертывание производилось ручками. По мере накопления опыта и роста количества серверов стало рентабельным сделать автоматическую систему развертывания, ее сделали и вместо локальных проблем деплоя на конкретном сервере встали проблемы работы этой системы.
  • +1
    Мне понравилась аналогия из «Программист-прагматик», там авторы сравнивают ПО и процесс его разработки с садом и работой садовника. Вообще, к программным продуктам хорошо применимы аналогии из живой природы, так как большинство систем, стремящихся к гомеостазу, мы видим вокруг себя.
    • +2
      Есть ещё хорошая аналогия с горным походом альпинистов, она у Мараско, например, отлично описана.
      • 0
        Ага, жаль только что достаточно распространено мнение, что по мере увеличения масштаба все что касается архитектуры и непосредственно конструирования начинает волшебным образом вести себя как-то по другому. На самом деле это тот же сад и тот же поход, просто, если пользоваться аналогией, людей идет больше и гора выше.
    • 0
      да, отличная статья, жаль ссылка потерялась
  • +3
    Отличная статья, жаль, что слишком «мягкая». У разработки ПО вообще слишком много неверных (радикально неверных, причём) прицепилось. Тут и строительство, и автомобилестроение, а из общего там только термины, за которыми в каждом случае стоят совершенно разные вещи.

    Мне когда-то попалась статья, где автор сравнил разработку ПО не со строительством, а с работой архитектора (классического, не софтварного), причём даже не одного, а целого коллектива, который должен построить дом по техзаданию вида «Лучший дом в мире! Пять тысяч этажей. И чтобы можно было на колёсиках катать по обычным дорогам».
  • +3
    Извините, а о чем статья?
    Я перечитал ее 2 раза и не понял ни мысли, ни цели, ни логики. Единственный point — «разработка по, это как строить дома, только по другом». Не могли бы вы помочь мне, закончив статью «выводом»? Спасибо.
    • 0
      Прошу прощения, видимо поинт конкретно этой заметки размазался в силу того, что цельная статья сначала разбилась на две, потом на три, а потом три части оказалось только во введении. Вывод в явном виде не помешает.

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