rssh

37 (не 38)

2009-07-17T07:33:50Z

Да, тоже из серии "Очевидное/невероятное". Цифра настолько неочевидная, что пришлось считать, что бы ее высчитать. (Праздновать буду как вернусь в Киев).

Ой ('анализ' OSS от *** - они таки ССЗБ)

2009-07-15T15:56:16Z

Блин, Интернет стал хуже телевизора. Когда уже будет готов векторный фидонет, где не надо булет тратить время на чтение того, что тебе не надо ?.
В вышеупомянутой дискуссии о OSS (комментарии в http://www.itblogs.ru/blogs/cio_anatomy/archive/2009/07/13/51045.aspx)
Михаил Елашкин запостил статью, как-бы о http://www.elashkin.com/attach.asp?a_no=92
(Бизнес модель Open Source перспективы и угрозы). Так как я теме экономики OSS неравнодушен, то прочитал, надеясь какой-то анализ. Ну попытка расквалифицировать создателей, в принципе за мысль сойдет (а дальше [?]), но возникают вопросы:

1. В статье, посвященной экономике OSS, о самой распространенной модели финансирования (когда разработчики заказных проектов сообща делают бесплатную инфраструктуру что бы снизить издержки) нет ни слова. Эссе Раймонда "Волшебный котел" с объяснением тоже не упоминается.
Вопросы:
- почему ?
- как можно говорить о экономике ПО, не упомянув модель распределения затрат ?

2. Чуть ли не единственными цифрами в статье, является ссылка на исследование Forrest Research: вот цитата из статьи Елашкина
И вот что выяснилось. Был проведен детальный опрос 14 компаний из этого списка, которые используют Linux более одного
года. Меньше половины из них имеют хоть какой-нибудь формальный процесс экономической оценки эффективности внедрения. И те 5
компаний, которые действительно рассчитывают экономические показатели от использования информационных технологий, получили в
результате, что использование Linux обходитсяна 5-20% дороже, чем использование существующих систем на основе Windows54.
А вот ссылка на само исследование: http://www.forrester.com/Research/Document/Excerpt/0,7211,34146,00.html
Там написано следующее:

Open source, including Linux, is being deployed by a majority of companies in 2004, yet we question whether customers are adequately prepared to deal with the costs and risks of managing these environments. The allure of free software is accelerating the deployment of open source platforms, but open source is not free and may actually increase financial and business risk. Discussions with five companies that tracked their total costs indicated Linux was between 5% and 20% more expensive than Windows. There were two distinct situations where Linux was the clear cost winner: Unix migrations and Linux-only deployments. Linux, and other open source software can provide big benefits to the organization, however, companies need to know what to expect, and plan appropriately to mitigate these concerns.

То есть следующая фраза (также есть ситуации когда использование Linux явно дешевле ....) не приводится, и таким образом у читателя создается мысль, что в среднем Линукс таки оказываетсяя дороже. (Если конечно, читатель не задумается над тем, можно ли считать выборку в 5 предприятий хоть сколько-нибудь репрезентативной) А в отчете, кстати в большинстве случаев всте таки отмечается снижение затрат при помощи ОSS ;)

Далее - статья написанна в 2007 году. ForrestResearch опубликовал отчет в 2004.
А делал ли ForrestResearch другие публикации на эту тему между 2004 и 2007 ?
Да, в частности с названиями:
Evaluating the Costs and Benefits of Open Source Content Management (2004)
How Firms Should Work With The Open Source Ecosystem (2005)
Open Source Usage Is Up, But Concerns Linger (2005)
Integrated Open Source Stacks Reduce Deployment And Maintenance Costs (2005)
How To Turn An Open Source Product Into A Commercial Business (2007)
Sourcefire And Snort Are In Harmony With The Open Source And Commercial World (2007)
Где говориться о успешных применениях.

Кстати, среди заголовки отчетов ForrestResearch в 2008 и 2009 есть и такие:
Open Source Becoming Mission-Critical In North America And Europe (2008)
Open Source Software Goes Mainstream (2009)

То есть получается что взята одна старая статья из массива, да еще и из нее тенденциозно выдернута цитата
//UPD: (я плохо посмотрел, точнее поверил про "пару лет назад" Статья написанно в 2005, собственно часть
(но не все) претенизий к выборке именно этого отчета снимаются)

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

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

Что делать - не знаю, может посоветуете ?

Процессы на рынке, связанные с СПО

2009-07-13T19:41:02Z

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

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

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

1 - ситуация "бесплатного" сектора - не уникальная черта СПО и вполне может быть стабильна. пример - рынок научных исследований или рынок образования.

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

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

4 - На рынке продаются не только продукты, но и способность людей и организаций что-то сделать. Эту способность можно продемонстрировать, что-то сделав и предостваив на суд пользователей(то есть свободное ПО конкурирует с рекламой)

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

6 - Наличие свободного ПО снижает барьеры входа на рынок разработки (и может быть на смежные рынки) что таки повышает конкуренцию на смежных рынках

7 - Наличие свободного ПО и трудности разработки рынка продуктов. повышает емкость рынка разработки заказного ПО

8 - Активность свободного ПО приволит к встречам людей и организаций, и, как следствие, проект может стать площадкой для "кластеризации" участников.

9 - Происходит замедление развития средств разработки (раз этот рынок каннибализирован свободным ПО, то туда бесмысленно инвестировать)

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

То есть есть "+" факторы, есть и "-". Единственно что можно сказать качественно - экосистема нелинейна и подвержена большим колебаниям :)

//UPD: 11 - Свободное ПО может окупаться так-же, как "бесплатный телефон" выгоден операторам.
Ну и 0 - процесс, описанный автором поста на itblogs: Разработка СПО как инструмент конкурентной бороьбы с Microsoft.

а какие еще процессы происходят или можно придумать ?

Голдратт. Цель

2009-07-13T19:19:27Z

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

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

Индукция/Дедукция (а не наоборот)

2009-07-10T18:24:41Z

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

Подмосковье

2009-07-10T18:17:29Z

Королев выглядит очень чисто и красиво. Дожди (так что туризм из Киева на cевер летом вполне уместен. Главное - ненадолго). Скейтисты на большой пешеходной площади. Тропинки вдоль ж/д дорог (некоторые - заасфальтированные). Почему-то кажется, что лесов тут больше чем под Киевом: полгорода сплошная парковая зона.

Scala тоже умеет mixed compilation

2009-07-07T08:23:00Z

http://www.codecommit.com/blog/scala/joint-compilation-of-scala-and-java-sources
А можно и все три вместе
http://groovyland.wordpress.com/2009/03/03/groovyscalajava/

Очевидное невероятное

2009-07-06T19:09:38Z

С утеловских 3G не видна УП. Случайность или забанили ?

Для тех, кто не в отпуске (июль)

2009-07-06T12:19:20Z

А никто из моих друзей не хочет мааааленький субконтракт на попрограммировать middleware ? (туды хml, сюды xml, посередине - гвоздик.)
Детали по запросу, комменты на всякий случай скринятся.
UPD: Call closed. Завтра на все всем отвечу

Полл Ди Филлипо

2009-06-20T21:17:47Z

http://www.pauldifilippo.com/ (Он же pgdf)
Проглотил "Нечеткое дробление", сейчас читаю "Вавилонские Сестры и другие постчеловеки". Круть неимоверная - как 14-летний (даже стыдно немного). Этакая смесь из Гибсоновского Джонни Мнемоника, Кафкианского Превращения, рассказов Шекли и все это в анатураже Зведных Войн Лукаса (с блестками и фанерной стенкой)

Читая классику

2009-06-14T21:51:49Z

Перечитывал сегодня рассказы Честертона: обнаружил достаточно полную аналогию отношения к политической ситуации в Англии начале 20-го века и у нас сейчас. Вплоть до термина "плутократия".

О чем? Нет, ты правда не в себе? — искренне и звонко крикнул Гарри. — Ты что думал, тебя и впрямь прочат в парламент? Ты же взрослый, в конце концов! Пройти должен Вернер. Кому ж еще? В следующую сессию он должен получить финансы, а потом провернуть египетский заем и еще разные штуки. Мы просто хотели, чтоб ты на всякий случаи расколол реформистов. Понимаешь, Хьюзу слишком повезло в Баркингтоне.

Белая Ворона Из цикла "человек, который слишком много знал".

rssh @ 2009-06-12T10:20:00

2009-06-12T07:59:10Z

Презентации из Java One: http://developers.sun.com/learning/javaoneonline/index.jsp

Пока просмотрел не все (проматриваю по вечерам по нескольку штук)
Из заметного
* project coin Small language changes in JDK 7 ) - целая строчка посвящена моей работе ;) В остальном - грустно // вобще надо будет как-то подробней рассказать.
* What's new in groovy-1.6 (вот и статья на ту-же тему в http://www.infoq.com/articles/groovy-1-6) Это хорошо. Очень хорошо. Еще бы какую-то полсистему стаической типизации и вобще бы цены groovу не было.
* Fill of scala - не знал что там тоже 'duck typing'. Вобще скала всем хороша, скроме слишком сложной системы типов.
* Clojure: Dynamic Functional Programming for the JVM Machine . Оказываетмя там STM bу-default и нормально работает.

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

Обзор прессы

2009-06-11T06:21:44Z

Презентации из Softwate Architecture Challenges in 21 Century Workshop
http://csse.usc.edu/csse/event/2009/Arch-Workshop/pages/program.html
* когда сбоит Agile. (примеры) (Philippe Kruchten). Документация все-таки нужна. (Рассказывается о случае когда люди образовались что Agile гвайдов не требует, забили на описание архитектуры и кинулись писать код. Потом забуксовали и вернулись к документированию архитектуры.
* интересная типология проектов (в щзависимости от темпа изменений и масштаба изменений; в целом метафоры притянуты за уши но наводят на мысли) Pekka Abrahamsson
* Гради Буч говорит о простоте ;) // эти слова сказать бы ему-же 20 лет назад ;)
* Разрабатываются специальные тулзы для того, что бы описание архитектуры выдрать из кода (Nenad Medvidovic · Vladimir Jakobac) и рисовать красивые картинки (Andre van der Hoek)

Бонус: слово 'Defenestration' обозначает процесс выбрасывания из окна.

rssh @ 2009-06-05T18:50:00

2009-06-05T15:51:10Z

http://diktature-net.org/
// вот так мы узнаем число активных Интернет-пользователей в Украине

Лев Лосев. Иосиф Бродский

2009-06-03T20:42:19Z

Из серии ЖЗЛ. Я вообще-то очень настороженно отношусь к ЖЗЛ, после того как в прошлом году они мне подсунули биграфию Хармса, настолько неудобоваримую, что не заснуть через 15 минут чтения было нельзя. (Я специально старался открывать ее в 16:30; что бы в пять меня будили коровы, идущие на вечернюю дойку). Но здесь очевидно не тот случай: обстоятельная биография, с академическими примечаниями (которые интересно перечитать без привязки к основному тексту), хронологией и полной библиографией. Короче, Бродскому повезло с биографом. Ну и понятно, что Лосев как филолог тоже велик. Правда иногда его разбор кажется наивным: не возникает вопроса: слова ли несут поэта или наоборот. (у него - только наоборот и если человек что-то написал то он так думает); Теперь можно будет вдумчиво все перечитать.

Хотя .. кажется я начал понимать что "лучше не надевать очки". То есть когда я впервые прочитал "Линия и Цвет", Бабеля (там он спрашивает у Керенского: а почему вы не носите очки ? Тот ему отвечает - зачем, так все прекрасно, я вижу линии, цвета и могу себе что-то представлять. А надеваю очки - фи, какая гадость) я думал: что за фигня, понятно что лучше четко видеть. Потом точно тот же диалог был в переписке Пастернака и Цветаевой (Цветаева ответила что-то в стиле: "я уже сама себе составила представление о людях и хочу их видеть такими". Потом я этот же паттерн где-то прочитал в третий раз (и не могу вспомнить где). А теперь вот сам начал эту ситуацию понимать (боюсь взяться перечитывать Бродского - вдруг пойму и потеряю очарование [?]).

rssh @ 2009-05-30T15:42:00

2009-05-30T12:44:17Z

(chicken->chicken)->chicken->chicken

А может он думает:

2009-05-28T06:15:00Z

Блин, не пойму этих взрозлых. На кухне все время тянут себе что-то в рот и там ломают. Я хочу что-то себе в рот кинуть - забирают; подсовывают какие-то пластмаски. Сколько можно; я сколько себя помню эти пластмаски грызу - ОНИ НЕСЬЕДОБНЫ. Кто умеет говорить, скажите им, пожалуйста !

Стоимость документирования: слухи и цифры

2009-05-22T21:22:02Z

Вдогонку к вялотекущему флейму о документировании: В блоге Сергея Корнилова всплыла статья о разработке критически-важных систем в NASA. Они документируют все и вся и держат отдельную команду верификаторов. В обсуждении этой статьи на reddit были названы оценки стоимости одной строчки кода: в NASA и в индустрии. Это $850/LOC и $5/LOC соответственно. То есть выпускать масимально документированное и надежное ПО в 160 раз дороже чем обычное. Это похоже на правду.

На дворе - четверг, а в душе - пятница.

2009-05-21T09:45:39Z

Что напечатает следующая программа ?

package x;

public class X
{

  public X() throws Exception
  {
    throw new Exception("hi!");
  }

  public static void main(String[] args) {
    try {
      X x = X.class.newInstance();
    } catch (InstantiationException ex) {
      System.err.println("instantiation exception");
      ex.printStackTrace();
    } catch (IllegalAccessException ex) {
      System.err.println("illegal access exception");
      ex.printStackTrace();
    }
  }

}

Доколе!

Тлен Убкар

2009-05-18T17:24:21Z

Обсуждают в comp.lang.functional

11. TL;DR problem.

2009-05-07T11:21:44Z

Одно привлекало внимание: там говорилось что литература
Убкара имела фантастический характер и что тамошние эпопеи и
легенды никогда не отражали действительность, но описывали
воображаемые страны Млехнас и Тлен

Хорсе Луис Борхес. (Тлен Убкар, ORBIS TERTIUS)

Общие сведения.

TL;DR – это англоязычная идиома, которая расшифровывается как Too Long ; Don’t Read. Аналогичная албанская идиома: “ниосилимногобукфф” слишком длинна для ее использования. Проблема заключается в том, что проектную документацию никто не читает, так как людям лень читать длинные тексты. Вторую (симметричную) проблему можно было бы назвать Too Hard ; Don't Write — она заключается в том, что проектную документацию никто не пишет, так как людям лень писать длинные тексты. Казалось бы в чем проблема: никто не пишет, никто не читает, стало быть она просто не нужна.

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

Ну что-же: попробуем убрать из процесса 'too long' и 'too hard': хотелось что бы документация была короткой и писать было ее легко.

Во первых — можно ли выработать критерий, когда без нее можно обойтись, а когда нет — навернoе как и для любой другой подсистемы. Ведь принципиально, работа по написанию инструкций для человека ничем не отличается от работы по написанию инструкций для машины, кроме того что первое несколько труднее. Мы знаем, что писать программу более или менее неудобно, если точно не известно, что с этой программой будут делать (то есть случаи его использования [use-cases или user-stories] для UI и примеры работы [test-drive-design] для API) А если у вас в голове (не обязательно на бумаге) этого нет, то писать код более или менее бесполезно. Документацию тоже писать бесполезно, если вы не представляете себе ее использования:
Кто это будет читать ? (роли)
Зачем ему(ей) это надо ? (цели)
Что это изменит ? (процессы)
Связные вещи

Давайте не поленимся и напишем функциональные спецификации на какой-то распостраненный документ:

Техническое задание (традиционный подход)

Читатели
представитель заказчика
  Цели чтения:
   удостовериться в корректном описание бизнес-проблемы, вызывающей необходимость разработки ПО
   зафиксировать требования так, что бы можно было проверить их реализацию
представитель исполнителя
  Цели чтения
   понять функциональность разрабатываемого приложения
   понять нефункциональные требования приложения и разработать соответствующую архитектуру
   зафиксировать требования так, что бы можно было верифицировать их реализацию
   оценить приблизительный объем работы
   составить декомпозицию на подзадачи
   оценить необходимость создания детализации ТЗ

Основные процессы:

Согласование ТЗ
  Какой-то участник (назовем его — автором ТЗ) пишет первую версию
  Другие участники отмечают неоднозначности и вписывают дополнительные вопросы
  Автор ТЗ учитывает эти замечание
  На этапе исполнения представители исполнителя отмечают неоднозначности и задают дополнительные вопросы
   Автор ТЗ учитывает (OOPS, как быть со сроками и деньгами ?) // связный процесс -- смена ТЗ

Изменения ТЗ
  Инициатор изменений предлагает правки в ТЗ
  Правки в ТЗ проходят процесс согласования на понятность
  Представитель исполнителя пересчитывает сроки и стоимость
  Изменение ТЗ, а также сроки и стоимость, принимаются (или отвергаются) заказчиком

Реализация ТЗ
  Менеджер проекта со стороны исполнителя составляет перечень задач
  Функциональные спецификации соответствующих задач раздаются программистам (составляются ли ?)
  Программисты используют функциональные спецификации и оригинальное ТЗ для разработки ПО

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

Составление других документов
  Другие документы, описывающий программу разрабатываются путем копи

Связанные документы:
  Концептуальная модель предметной области (может быть частью ТЗ)
  Функциональные спецификации (могут быть частью ТЗ)
  Оценка трудоемкости разработки

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

В конце концов, техническое задание, состоящей из одной фразы:
“Разработать подсистему редактирования справочной информации, с помощью которых оператор может редактировать объекты, указанные в разделе “справочники”.
Может быть вполне приемлимым в одном контексте и быть смертельной ошибкой — в другом. Так что нельзя в принципе, говорить о “ТЗ в общем”, без привязки к конкретному процессу разработки.

Можем ли мы придумать какие-то методы, облегчающие написание документации (?): в целом такие-же как и для кода:

вынос “контекста” за скобки (пример — ссылка GAAP вместо собственного описания концепции бухгалтерского учета; ссылка на Java Coding Standards вместо описания стандарта кодирования)

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

Современные средства совместной разработки и навигации (wiki)

Средства автоматического контроля

Документация, как и планирования — одна из тех областей, где простого и удовлетворяющего решения просто нет. Есть какой-то прогресс: появляются новые средства работы с моделями, который могут автоматизировать часть генерацию (кода или документов) ; распространение языков высокого уровня может снизить потребность в документации; может быть в будущем системы искуственного интеллекта научаться писать учебники и обзоры лучше нас, но все это частичные улучшения, сама потребность в формализации требований и объяснения функциональности программы для человека “извне” никуда не исчезнет.
Ресурсы:

[1] Алистер Коберн. “Современные методы описания функциональных требований к системам”. Лори. 2002 г. 266 стр. ISBN: 0-201-70225-8, 5-85582-152-8
[2] Джоэл Спольский. “Функциональные спецификации малой кровью” (см. http://www.joelonsoftware.com/articles/fog0000000036.html)
[3] Влад Балин. “Читай код”. http://www.softwarepeople.ru/press/articles/09/

Обзор прессы

2009-05-07T11:16:48Z

В то время, когда все прогрессивное человечество жарило шашлыки, блогосферу потрясло два события:
- Публикация Chaos Report 2009 [[ нет ли у меня в друзьях Standish Group subscribers ? ]]
- Статья gaperton "читай код" , удостоверяющая наличие больших систем без документации. (очевидно первый шаг к легализации повсевместности такой практики)

Ну что сказать: и первое и второе событие говорит о том, что есть куда расти ;) Особенно второе - ну да, вполне возможен эффективный процесс, построенный без документации но только в определенных условиях, на первый взгляд кажется, что достаточно узких (нет ни публичных API ни взаимодействия с аппаратурой ни внешнего заказчика).
Я тут сподобился написать 11-ю главу: сейчас выложу TLDR;problem

ТЗ: еще одна рамка (scope)

2009-04-30T20:47:38Z

Кроме функций общения заказчика с исполнителем, техническое задание может выполнять еше одну роль -- ограничителя трудоемкости; когда в ТЗ написано не только, что входит в систему, но и что не входит. Это может быть полезной техникой для предотвращения ситуаций типа: вот есть у нас задача A c определенной спецификацией с предварительной оценкой трудоемкости T(a). Мы cделали А за N*T(a) [N >> К], а на вопрос 'почему так (?)', отвечаем -- так и надо, потому что получившиеся A умеет больше функциональности чем планировалось. Казалось бы очевидно - но сии грабли достаточно типичны (особенно при декомпозиции подсистем, куда конечный заказчик, как правило, и не заглядывает). То есть, если ради расширения придется менять мини-ТЗ, то сбои такого типа уменьшатся. И наоборот - ТЗ явно составлено слишком общо, если, не меняя его, можно существенно увеличить сложность разработки.

Осторожно, FUD

2009-04-27T21:41:29Z

Словно мухи, тут и там
Хотят FUD-ы по лохам
А беззубые старухи
Из раносят по умам

Мне как бы не хочется ругаться, но скоро людей, которые ходят на отраслевые конференции и серьезно относятся к тому, что говорят в технических докладах, придется расстреливать в целях сохранения экологичности окружающей среды. ( и видно эта идея пришла в голову не только мне )
Особенно достает два фуда, переходящих в разных формах из презентации в презентацию
- "при проектировании интернес-сервисов академические решения плохо подходят". Хмм, ребята, а вы в курсе что google это академическое решение (Стенфордский Университет) и вообще большинство технологий (особенно в области высоких нагрузок) пришло к нам из лабораторий. Если вы хотите сказать, что простое лучше сложного - так и скажите. Большинство научных работников это прекрасно знают.
- "java тормозит и требует хорошего железа" - это было 10 лет назад. Сейчас на том же железе Java работает быстрее PHP

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

Online LaTex equation editor

2009-04-24T07:51:42Z

http://www.codecogs.com/components/equationeditor/equationeditor.php