Так давайте уже определимся — мыслит или выдает результат. По поводу «мыслит» у меня вообще никаких комментариев нет. В этом деле не то, что Аристотель, даже наши современники британские ученые еще не разобрались.
На профессиональном языке аналитика? Вы представляете, что будет, если их попробует прочитать первое лицо заказчика? (перед тем, как поставить утверждающую подпись, например).
Кроме того, я не сильно много знаю программистов, способных в деталях понимать UML, PBMN или что-то похожее. Обычно диалог сводится к «ты не зю-зюкай, ты рукой покажи».
Это значит, что используется типовая модель, из наработанных ранее
Что-то вроде. Но знания предметной области при этом нет.
описана работа хирурга. Он в процессе операции поет только на профязыке
Это другое. Хирург действительно общается со своей группой. И действительно на специфическом языке. Но это язык, заточенный именно под общение с группой в процессе операции. Это не его язык, это язык группы. На своем профессиональном он, вполне вероятно, напишет статью об этой операции в журнал для коллег. И совсем другим языком будет объясняться со следователем, в случае не очень удачной операции. Я про эти языки говорю. Когда нужно донести информацию до разных потребителей.
«Профессиональный» же язык аналитика тут подобен тому, на котором хирург будет писать статью в журнал. Коллеги-аналитики поймут в нюансах, остальные — вряд ли. Но аналитику платят не за то, чтобы он делился курьезами со своими собратьями по цеху, а за доведение информации до не-аналитиков.
Экземпляры представления данных существуют только у Аристотеля.
Что значит только у Аристотеля? Вот давеча я распечатал вполне себе конкретный экземпляр представления недельных трудозатрат. Потом поменял сортировку, но печатать другой экземпляр не стал. Тем не менее, теперь он есть не только у Аристотеля, но и у меня. Как минимум.
На языке теории множеств это должно было бы звучать так: Для конкретного представления данных. Это понятно почему?
Теорию множеств я уже основательно подзабыл. Вы мне лучше скажите, как будут называться две одинаковых по форме и содержанию _распечатанных_ таблицы, разнящихся лишь сортировкой содержания? Поскольку «представлением данных» здесь можно назвать «Таблицу №45 Приложения 1 к Приказу Генерального директора от 15.04.2014 №35-ЛС» (а как в ней сортировать ЛС — дело текущих потребностей).
Возможно, что есть такая практика — строить требования не зная, к чему они относятся.
Нет, такой не видел. А вот без знания предметной области — запросто. На основании одних лишь поверхностных представлений. Например, приличная часть коммерческих предложений по «не своей» тематике пишется именно так.
Но есть кто-то, кто держит проект в целости.
В теории — да.
То, ка врач потом рассказывает про операцию, нас уже не касается, главное, чтобы в процессе операции он не перешел на непрофессиональный язык.
У врача нет необходимости петь (т.е. выполнять информационные транзакции). А вот если бы он:
1) программировал робота-хирурга,
2) объяснял фельдшеру, что и где резать,
3) рассказывал, что принимать пациенту (чтобы само отвалилось),
… он бы, пожалуй, пользовался разными языками. Какой из них будет непрофессиональным?
Да нет, он вполне объективный. Это просто разные вещи.
Есть номер книги — это параметр (атрибут) типа «книга».
Есть порядковый номер в таблице с книгами — это «параметр» таблицы.
На картинке — классический «номер по порядку», т.е. атрибут таблицы.
Сейчас это порядковый номер в сформированной таблице. То есть, атрибут таблицы. Объект не в курсе, как таблица его разместит.
Если бы было что-то вроде «ID» (даже упорядоченного по возрастанию), то да, это был бы номер (идентификатор) объекта (а следовательно, его родной атрибут).
Без знания предметной области это сделать невозможно. Пусть не всегда модель строится явно, но она всегда присутствует.
а) Увы, возможно. Наблюдаю сплошь и рядом.
б) Неявную модель трудно назвать «основной задачей».
Борьбой со словом «обратно» занималась наша учительница… И мы стали использовать слово «Снова».
Молодец учительница. И, несомненно, авторитет для Вас (как для меня моя в свое время). Ну а мне милее язык Зощенко.
Пусть и так, но он должен петь, а не спотыкаться, подыскивая слова.
Это примечание было про то, что ему петь. По части «как» — совершенно согласен. О чем и написал в следующем комменте.
Представьте себе архитектора, который так будет петь.
Как — так? Жизнь меня сводила с архитекторами, которые были способны говорить «о своем» очень по-разному, в зависимости от аудитории (в т.ч. и писать).
Основная задача бизнес-аналитика при разработке нового ПО – изучение предметной области и формальное описание полученных сведений в виде модели (Domain Model).
Не совсем. Его основная задача — сформировать систему требований к разрабатываемому ПО. И где-то там, среди прочего, может быть и Domain Model (а может и не быть). Причем не обязательно в качестве части системы требований — вполне может статься, что она так и останется «сырьем» для формирования требований.
Аналитик должен петь то, что он видит и то, что он хочет увидеть.
Обратно не согласен. Аналитик должен петь то, что уменьшит степень неопределенности для проектной команды. А «что видит» он вполне может бурчать себе под нос в ванной, почему бы и нет?
Для этого у него должен быть язык, на котором он исполнит свою песню.
Эх… Взашей гнать таких аналитиков, которые кроме как на своем птичьем языке петь не могут. Аналитик должен петь так, чтобы тот, для кого он поет (будь то заказчик, менеджер проекта, программисты и т.п.) восхищенно внимали и проникались каждой нотой и каждым куплетом.
он может перестать видеть то, что надо петь и начать видеть лишь то, для чего есть слова в словарном запасе используемого им языка. Все остальное перестает для него существовать.
Так это не аналитик, это тетерев. Общечеловеческое свойство, от профессии мало зависит.
Мы увидели, что моделирование в категориях типов или классов ООП приводит нас к тому, что построенные модели, нерасширяемы.
С фундаментом под многоэтажку примерно такая же фигня. Тенденция-с.
Оказывается, что модель мира, которую мы создаем, много богаче той, которую мы обычно записываем на бумаге в виде текста, или таблицы.
«Мысль изреченная есть ложь.» (с) Ф.И. Тютчев, 1831. Внезапно, да.
А уж если обратиться к самому определению «модель»…
Умение различать понятия, проводить границы — одно из важнейших аналитических умений.
Запихивая деятельность по созданию чего-то под название «управление», мы теряем важные компоненты смысла.
Так вроде никто и не утверждал, что созидание и управление — одно и то же. Просто они настолько пересекаются и врастают друг в друга, что рассматривать одно вне контекста другого — как раз и есть верный способ потерять важные компоненты смысла. Практически важные.
Именно поэтому я считаю, что с прикладной точки зрения полезно рассматривать разработку в составе управления. В его контексте, так сказать. Или же наоборот: что во что встраивать, зависит от относительных масштабов явлений в конкретной ситуации. Может получиться так, что управление станет «бедным родственником» при разработке.
Ну а в автоматизаторской жизни под «управлением» каким-то объектами чаще всего подразумевается активность а-ля CRUD («управление договорами», «управление учебными группами», «управление анкетами» и т.п.). То же худо-бедное управление персоналом — и то начитается с разработки образа будущего сотрудника (а не худо-бедное — с «сот» под образы в виде оргштатки).
Про то, как совмещать эти деятельности на практике — отдельный разговор
Если применение теории на практике требует большого напильника, то может, с ней что-то не так? Классик утверждал, что теория без практики мертва.
Я не призываю отказаться от этих теорий. Они милы и по-своему полезны. Я призываю не применять их как нечто, имеющее абсолютный авторитет. А уж тем более, как прокрустово ложе.
Так и статья автора тоже не на земельном кодексе. И даже ссылка есть:
обнаружил шкалу уровней зрелости процесса управления требованиями (requirements management maturity), предложенную в 2003 году одним из специалистов по работе с требованиями Rational Software Джимом Хьюманном (Jim Heumann).
(А даже если была бы на земельном кодексе — какая разница? Гораздо интереснее, что получилось в результате.)
Я о том, что собственное мнение авторов по тем двум ссылкам настолько же авторитетно, сколь и собственное мнение нашего автора (в хорошем смысле).
В частности, мешать разработку требований и управление ими или нет — дело вкуса, навыков (и «качества» кадров в целом), оперативной ситуации, случая и прочих факторов.
Я, например, более эффективным вижу разработку требований со встроенными фичами под дальнейшее управление ими во вполне конкретном окружении. Цена такого подхода — невысокая эффективность разработки без понимания специфики дальнейшего управления и невысокая эффективность управления без понимания нюансов разработки. Другими словами — высокие ожидания от сотрудников и повышенная стоимость(продолжительность) выхода сотрудников на крейсерскую производительность.
Если вернуться к Вашей аналогии, эффективнее (с точки зрения раскрытия возможностей и знания недостатков) водить автомобиль, спроектированный и собранный своими руками.
Disclaimer: The opinions expressed here are the authors
and do not express a position on the subject from the
Software Engineering Institute (SEI) or any organization
or SEI Partner affiliated with the SEI.
Так согласование и нужно, чтобы реализация соответствовала требованию, не так ли?
В частном случае — так.
Еще раз хочу обратить внимание: эта ветка идет от Вашего поста с утверждением «управление требованиями подразумевает многоэтапное и многоуровневое их согласование». Мои посты в ней — на тему этого утверждения.
До согласования и после него с требованиями может происходить много интересного и в разной степени полезного. Здесь я этого вопроса не касался. Только «утверждение», только хардкор.
Поэтому требование должно быть максимально подробным. И программист, лишь один раз получивший «на орехи» за неверную интерпретацию требований, в следующий раз будет занудно и педантично выяснять все детали, и требовать их письменной спецификации, прежде чем приступит к работе. Это мое наблюдение из практики.
В зависимости от того, кто на него смотрит, и от преследуемой цели (согласование — это одно, разработка — другое, тестирование — третье и т.д.), требование может выглядеть очень по-разному (не меняя своей сути). К заказчику мы идем с концепцией требования, программисту отдаем детализацию, с тестировщиком обсуждаем кейсы по требованию.
Только потом окажется что программист закодил не то и не через 2 дня а через две недели.
Это уже реализация, а не согласование. Требование согласовано аж с заказчиком (не так уж и редко у аналитика есть на это полномочия).
А клиент посмотрев на решение, отказался покупать.
Он ведь был в восторге и согласился, когда аналитик ему это презентовал?
И с кого спрашивать, если нет официального согласования?
А если есть? Если же нет — то это или нарушение процесса (в котором заказчик должен поставить согласующие подписи) или риски того же процесса (если «верим на слово»). Может быть и так, и так. И последствия будут разными.
И, главное, где тут формализованные структурированные требования? В словах аналитика?
Нет их тут. Пример — про важный участок работ под названием «согласование». Давайте считать, что после восторгов заказчика все требования были внесены «куда следует», протрассированы и включены в планы релизов.
Кроме того, я не сильно много знаю программистов, способных в деталях понимать UML, PBMN или что-то похожее. Обычно диалог сводится к «ты не зю-зюкай, ты рукой покажи».
Вот так точно нельзя. Это данные (т.е. продукт жизнедеятельности модели), но не модель.
Что-то вроде. Но знания предметной области при этом нет.
Это другое. Хирург действительно общается со своей группой. И действительно на специфическом языке. Но это язык, заточенный именно под общение с группой в процессе операции. Это не его язык, это язык группы. На своем профессиональном он, вполне вероятно, напишет статью об этой операции в журнал для коллег. И совсем другим языком будет объясняться со следователем, в случае не очень удачной операции. Я про эти языки говорю. Когда нужно донести информацию до разных потребителей.
«Профессиональный» же язык аналитика тут подобен тому, на котором хирург будет писать статью в журнал. Коллеги-аналитики поймут в нюансах, остальные — вряд ли. Но аналитику платят не за то, чтобы он делился курьезами со своими собратьями по цеху, а за доведение информации до не-аналитиков.
Что значит только у Аристотеля? Вот давеча я распечатал вполне себе конкретный экземпляр представления недельных трудозатрат. Потом поменял сортировку, но печатать другой экземпляр не стал. Тем не менее, теперь он есть не только у Аристотеля, но и у меня. Как минимум.
Теорию множеств я уже основательно подзабыл. Вы мне лучше скажите, как будут называться две одинаковых по форме и содержанию _распечатанных_ таблицы, разнящихся лишь сортировкой содержания? Поскольку «представлением данных» здесь можно назвать «Таблицу №45 Приложения 1 к Приказу Генерального директора от 15.04.2014 №35-ЛС» (а как в ней сортировать ЛС — дело текущих потребностей).
Нет, такой не видел. А вот без знания предметной области — запросто. На основании одних лишь поверхностных представлений. Например, приличная часть коммерческих предложений по «не своей» тематике пишется именно так.
В теории — да.
У врача нет необходимости петь (т.е. выполнять информационные транзакции). А вот если бы он:
1) программировал робота-хирурга,
2) объяснял фельдшеру, что и где резать,
3) рассказывал, что принимать пациенту (чтобы само отвалилось),
… он бы, пожалуй, пользовался разными языками. Какой из них будет непрофессиональным?
Есть номер книги — это параметр (атрибут) типа «книга».
Есть порядковый номер в таблице с книгами — это «параметр» таблицы.
На картинке — классический «номер по порядку», т.е. атрибут таблицы.
Если бы было что-то вроде «ID» (даже упорядоченного по возрастанию), то да, это был бы номер (идентификатор) объекта (а следовательно, его родной атрибут).
а) Увы, возможно. Наблюдаю сплошь и рядом.
б) Неявную модель трудно назвать «основной задачей».
Молодец учительница. И, несомненно, авторитет для Вас (как для меня моя в свое время). Ну а мне милее язык Зощенко.
Это примечание было про то, что ему петь. По части «как» — совершенно согласен. О чем и написал в следующем комменте.
Как — так? Жизнь меня сводила с архитекторами, которые были способны говорить «о своем» очень по-разному, в зависимости от аудитории (в т.ч. и писать).
Не совсем. Его основная задача — сформировать систему требований к разрабатываемому ПО. И где-то там, среди прочего, может быть и Domain Model (а может и не быть). Причем не обязательно в качестве части системы требований — вполне может статься, что она так и останется «сырьем» для формирования требований.
Обратно не согласен. Аналитик должен петь то, что уменьшит степень неопределенности для проектной команды. А «что видит» он вполне может бурчать себе под нос в ванной, почему бы и нет?
Эх… Взашей гнать таких аналитиков, которые кроме как на своем птичьем языке петь не могут. Аналитик должен петь так, чтобы тот, для кого он поет (будь то заказчик, менеджер проекта, программисты и т.п.) восхищенно внимали и проникались каждой нотой и каждым куплетом.
Так это не аналитик, это тетерев. Общечеловеческое свойство, от профессии мало зависит.
С фундаментом под многоэтажку примерно такая же фигня. Тенденция-с.
«Мысль изреченная есть ложь.» (с) Ф.И. Тютчев, 1831. Внезапно, да.
А уж если обратиться к самому определению «модель»…
Так вроде никто и не утверждал, что созидание и управление — одно и то же. Просто они настолько пересекаются и врастают друг в друга, что рассматривать одно вне контекста другого — как раз и есть верный способ потерять важные компоненты смысла. Практически важные.
Именно поэтому я считаю, что с прикладной точки зрения полезно рассматривать разработку в составе управления. В его контексте, так сказать. Или же наоборот: что во что встраивать, зависит от относительных масштабов явлений в конкретной ситуации. Может получиться так, что управление станет «бедным родственником» при разработке.
Ну а в автоматизаторской жизни под «управлением» каким-то объектами чаще всего подразумевается активность а-ля CRUD («управление договорами», «управление учебными группами», «управление анкетами» и т.п.). То же худо-бедное управление персоналом — и то начитается с разработки образа будущего сотрудника (а не худо-бедное — с «сот» под образы в виде оргштатки).
Если применение теории на практике требует большого напильника, то может, с ней что-то не так? Классик утверждал, что теория без практики мертва.
Я не призываю отказаться от этих теорий. Они милы и по-своему полезны. Я призываю не применять их как нечто, имеющее абсолютный авторитет. А уж тем более, как прокрустово ложе.
(А даже если была бы на земельном кодексе — какая разница? Гораздо интереснее, что получилось в результате.)
Я о том, что собственное мнение авторов по тем двум ссылкам настолько же авторитетно, сколь и собственное мнение нашего автора (в хорошем смысле).
В частности, мешать разработку требований и управление ими или нет — дело вкуса, навыков (и «качества» кадров в целом), оперативной ситуации, случая и прочих факторов.
Я, например, более эффективным вижу разработку требований со встроенными фичами под дальнейшее управление ими во вполне конкретном окружении. Цена такого подхода — невысокая эффективность разработки без понимания специфики дальнейшего управления и невысокая эффективность управления без понимания нюансов разработки. Другими словами — высокие ожидания от сотрудников и повышенная стоимость(продолжительность) выхода сотрудников на крейсерскую производительность.
Если вернуться к Вашей аналогии, эффективнее (с точки зрения раскрытия возможностей и знания недостатков) водить автомобиль, спроектированный и собранный своими руками.
Во первых строках читаем:
В частном случае — так.
Еще раз хочу обратить внимание: эта ветка идет от Вашего поста с утверждением «управление требованиями подразумевает многоэтапное и многоуровневое их согласование». Мои посты в ней — на тему этого утверждения.
До согласования и после него с требованиями может происходить много интересного и в разной степени полезного. Здесь я этого вопроса не касался. Только «утверждение», только хардкор.
В зависимости от того, кто на него смотрит, и от преследуемой цели (согласование — это одно, разработка — другое, тестирование — третье и т.д.), требование может выглядеть очень по-разному (не меняя своей сути). К заказчику мы идем с концепцией требования, программисту отдаем детализацию, с тестировщиком обсуждаем кейсы по требованию.
Это уже реализация, а не согласование. Требование согласовано аж с заказчиком (не так уж и редко у аналитика есть на это полномочия).
Он ведь был в восторге и согласился, когда аналитик ему это презентовал?
А если есть? Если же нет — то это или нарушение процесса (в котором заказчик должен поставить согласующие подписи) или риски того же процесса (если «верим на слово»). Может быть и так, и так. И последствия будут разными.
Нет их тут. Пример — про важный участок работ под названием «согласование». Давайте считать, что после восторгов заказчика все требования были внесены «куда следует», протрассированы и включены в планы релизов.