vit_r | Entries tagged with re

Был вчера на завтраке предпринимателей. Не в смысле бизнесменов, а в смысле стартаперов.

Была тётя бывший менеджер, которая решила что-нибудь начать и у неё десяток идей. Был свежий выпускник. Тоже хочет начать, но идей сотня. Сложно выбрать.

Мужик, ушедший в фотографы, всё налегал на то, что нужно passion. В смысле он не просто фотограф, а нашёл свою нишу и ей доволен. Теперь может советы давать по любым вопросам.

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

Тётя, которая менеджер, затронула интересную тему. Молодое поколение приходит и сидит.
( Read more... )

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

Первым делом, споря с Crosby, скажу, что качество - это мотивация.

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

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

Качество - это то, что закладывается в процесс создания.

Не в процессе, а в процесс. То есть, те требования, которые стоят в контракте, и те системы контроля, которые обеспечивают нужный уровень нужных параметров.

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

Кстати, это только в мире реальных вещей такое видно сразу. А в IT всё эфемерное. Именно так и продаётся agile, User eXperience, eXtreme Programming и прочие магические методики.

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

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

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

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

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

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

Побеседовал с российскими преподавателями о будущем образования.

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

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

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

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

Статическая нагрузка для моста, стоящего на "висячих" опорах (не опирающихся на скальное основание, а удерживаемых лишь силой трения грунта о сваи) не самое главное. Определяющими являются нагрузки динамические, приводящие к вибрациям. Ибо именно вибрации приводят к разжижению водонасыщенных грунтов (в том числе и илов) и интенсивной просадке опор.
А то, что эта просадка уже есть, свидетельствует появление трещин на одной из опор. Причём просадка неравномерная, приведшая к перераспределению нагрузки именно на пострадавшую опору.
Как говорится, включаем обратный отсчёт и наблюдаем.
Желающие могут запастись попкорном.

А так, беседа напомнила дуру-математичку с её "Нагло улыбался на уроке! 2"

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

Первая борода обсуждения выросла из диалога.

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

Вторая борода - просто из фразы:

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

Не понятно, зачем с этим спорить, но преподаватели нашли. Для желающих, под катом краткое описание моей позиции.
( Read more... )

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

По новым правилам LJ неактивные журналы будут удалены. Есть два фотографа

wildrussia и

slusarev, которых бы не хотелось терять. (Можно купить книги Сан Саныча с ч/б и цветными фотографиями, но это не то и не в том объёме.)

Что-то интересное я сохранил локально, когда с людьми общался, но бессистемно. Жалко, если пропущенное и умные мысли пропадут.

По теме чудес IT ничего писать не буду, просто приведу три цитаты. Сопоставить и сделать выводы каждый может сам.

Мечты

ailev

А зачем вообще нужна эта формализация в инженерных проектах? Зачем моделировать данные и интегрировать затем эти модели данных? Для управление конфигурацией, отслеживания конфигурационных коллизий, организации проверок непротиворечивости и полноты описания системы. Все формализмы нужны прежде всего для гарантирования этой "правильности", "целостности", "непротиворечивости", "актуальности". Если мы хотим что-то воплотить в жизнь, получить хорошо работающее в реальном физическом мире, то описание этого чего-то в мире виртуальном должно быть непротиворечиво и полно. Легче всего это описание проверить, если его делать на языке без неоднозначностей, и этот язык должен выражать всё самое важное для создания системы и опускать неважное. То есть язык должен быть формальным, или формальным оестествлённым (но не естественным с его неоднозначностью и склонностью смешивать в тексте собственно содержание и множество ассоциаций, которые иногда могут быть полезны, но чаще только отвлекают).

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

А сотрудник мне и говорит, что справки я могу трубочкой свернуть и засунуть куда-нибудь, в рюкзак например. Потому что теперь все записи электронные и существуют в базе данных. Что в базе написано, то так оно и есть. А способа изменить эти записи нет. Потому что налоговая должна послать электронный запрос во все ведомства, а они изменяют свои базы, а потом эти записи попадают в базу налоговой. Поэтому правильно у меня все списали за:
1) Машины, которой у меня нет уже 10 лет
2) Машины, которой у меня нет уже 5 лет
3) Дачи, которой у меня никогда не было
4) Квартиры, которая почему то значится офисом
И я еще должен за 9 лет лет за одну машину, 4 года за другую машину и 3 года за дачу. И я не один такой, потому что в росреестре не там галочку поставили и 20% квартир в моем районе записали как офисы. Запрос налоговая может послать, но он почему то не проходит, видимо база кривая. Поэтому все пока платят.

Пришло в рассылке: "Call for Papers zur Modern RE - agiles Anforderungsmanagement". Щёлкнув мышкой на http://www.modern-re.de/ вижу страницу :

Contao Open Source CMS
No root page found
What's the matter?

There is no website root page which matches the requested language and/or domain name.

How can I fix the issue?

If you have explicitly set a language, try to go to the top level and see whether you are being redirected. Otherwise contact the webmaster and let him know that there is something wrong.

Симптоматичненько.

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

Это базовые знания, которые минимально необходимы просто для того, чтобы меня понимать. По мере надобности или желания список будет пополняться.
( Read more... )

Смотрим на аватар и запоминаем:

Vit minus R dot com

Там сейчас ничего нет, но если что, адрес всем известен.

Запомнить советую потому, что Гугл находить не будет, если сделаю так, как мне нравится. Судя по тестам, Империя Зла фильтрует определённые вещи из результатов поиска. Бинг и остальные в подобном не замечены.

А теперь к делу.
( Read more... )

Вчера

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

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

Попробую перевести на английский.

Engineering is the process of search for an optimal compromise of a tangle of interconnected problems that cannot be solved together by consideration of all given constraints.

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

В вульгарной интерпретации отсюда следует известная формула «Быстро, хорошо, дёшево: выберите два из трёх». Реальность гораздо сложнее.

Если принять предложенное определение, первым печальным фактом придётся признать, что мы работаем в зоне высокого риска. Search is not finding. То есть, можно затратить все ресурсы и ничего не найти.

Вторая проблема - проблема планирования.

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

Решается это или банальной магией по подобию «Мы делали подобный проект и затратили X ресурсов за Y времени. Новая проблема более-менее похожа. Накинем десять процентов и запишем в план», или путём последовательных приближений плана на будущее по результатам завершённых этапов (Moneyfall modell).

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

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

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

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

Если у управляющих нет необходимых для управления инженерами знаний и опыта, есть несколько подходов. Они заключаются в работе над словами «by consideration of all given constraints»

Самый распространённый - менеджерский.
( Read more... )

Свалилась в рассылке ссылка на вопросник. Precise and Flexible Wiki-Based Requirements Engineering

OCDT is an initiative of the European Space Agency, and in particular its Concurrent Design Facility at ESA/ESTEC, to create an open software environment for concurrent, collaborative and distributed engineering applied to the development of space systems in the early phases of the life cycle.

И на второй странице:

A model-based engineering process is foreseen to replace the currently used document-based process.
...
Mechanisms like tickets, chat, shared material can be considered to further enhance the knowledge sharing. Enhancing the platform to contain and maintain reference architectures comprising generic requirements and corresponding solutions (product lines), could greatly reduce costs and simplify the overall process complexity.

И, конечно, вопрос.

42. [UR-20] As a user I want to export requirements specifications to at least one SysML tool so that the principle of data exchange with SysML tools is demonstrated.

Всего вопросов 62. Автор Sam Gerene, System Engineer at RHEA.

Я, даже, и не знаю, что сказать по этому поводу. Я не

ailev, чтобы верить в светлое будущее, и не

zelenyikot, чтобы не знать о технических мелочах.

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

Если NASA тоже занимается подобным (а все косвенные признаки говорят о том, что занимается), понятно, почему мы ни сейчас, ни в ближайшие лет пятьдесят не освоим ни Луну, ни Марс, ни астероиды. Надежда только на частников.

Wir haben mit den Lehrplänen eine solide Basis für eine gute Ausbildung geschaffen. Insbesondere das deklarative Wissen (Faktenwissen), das ein Requirements-Engineer für seine Arbeit braucht ist gut abgedeckt. Die IREB-Foundation Level Prüfung haben inzwischen über 20.000 Menschen abgelegt. Der Erfolg am Markt zeigt auch, dass das Zertifikat sinnvoll ist und in die Zeit passt.
Das prozedurale Wissen (also wie man RE wirklich im Projekt erfolgreich anwendet) lässt sich allerdings nur bedingt in einem Lehrplan vermitteln. Die wirkliche Vermittlungsarbeit – insbesondere beim prozeduralen Wissen – muss damit der Trainer leisten, der das entsprechende CPRE-Training hält. Hier gibt es naturgemäß Qualitätsunterschiede.
...
Ich denke man kann die Situation kurz gefasst so beschreiben: Jemand, der das CPRE-Zertifikat abgelegt hat, ist nicht automatisch ein guter Requirements-Engineer. Er hat aber zumindest das nötige Faktenwissen um starten zu können und befindet sich auf einem guten Weg.

Наши учебные планы создали солидный базис для хорошего образования. Особенно хорошо раскрыта тема декларативных знаний [искусство произнесения умных слов - vit-r]. В настоящее время число сдавших экзамен IREB-Foundation Level превысило 20 000 человек. Успех на рынке тоже показывает, что сертификат полезен и соответствует времени.
Созидательные знания (то есть, умение применять RE в реальном проекте) можно включить в учебный план только условно. За передачу этих знаний отвечает сам преподаватель, ведущий CPRE тренинг. По естественным причинам в этом процессе имеются отличия по качеству.
...
Я думаю, можно суммировать следующим образом: тот, кто получил CPRE-сертификат не является автоматически хорошим Requirements-инженером, [но он знает много красивых слов и, может быть, когда-нибудь из него выйдет что-то дельное. - vit-r]

Из интервью с Chris Rupp (гуру requirements engineering)

All too often I've heard the comment "it's not agile if we don't do it this way." In their defense, most of those speaking that way had little experience in what agile even was, much less what it looks like. Even those with certificates proving they sat for two days in a classroom and took modest notes about how to be a Scrum Master can't possibly define "true agile" until they have seen not only the effects of it, but also how it is achieved at different places.
...
Many people might actually be thinking about agile in a completely non-agile way. They might think true agile is a destination. Something you can reach. Something you can hang on a wall and say we achieved this; our job is done.
...
True agile is the ability to constantly try something, evaluate how well it worked, and adapt what you tried to make it better.

отсюда

Ещё кусок из диалога, который мог бы стать постом.

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

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

(Естественно, это в какой-то мере троллинг, но как профессиональная реакция на "фактически невозможно")

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

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

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

При этом само наличие контроля может незаметно сдвинуть цели в совсем неправильном направлении.

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

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

ailev.

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

ailev.

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

В принципе, это надо было бы переработать, проанализировать и выдать в дистиллированном виде. Но просто для демонстрации даю только цитаты и таблицы. Выводы делайте сами.

Итак Error Cost Escalation Through the Project Life Cycle. Как говорится, следите за руками.
( Read more... )

Перевёл предыдущую версию на русский. (Заголовок пусть остаётся так, чтобы искать легче было.)

Недавно на одном форуме опять наткнулся на старый разговор «Мы такие замечательные. Но менеджеры тупые - не понимают нашей замечательности. И коллеги из других отделов тоже тупые - не понимают кто мы и зачем нужны. И, вообще, мир несовершенен. Надо их обучить. А ещё ввести для нас сертификацию, а то много жуликов лезет, кто только прикидывается, что такой же замечательный как мы.»
( Read more... )

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

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

Let's say, a company decides to build a web portal to sell soap bubbles online. There are investors who give money and who hope for returns of their investments. There are managers who have budgets that they try to spend wisely. (This is an artificial situation. We do not concern ourselves with the sad reality.)

Imagine 3 experienced managers (CEO, CTO and CFO) are hiring experts for a new project. They want to know who the people are, what they do and what their work would add to the success of the soap bubbles selling site.

Each candidate has 3 sentences for their answer. The answer may contain only a part of the information but it must confirm to the following criteria:

It must be honest.

It must be specific. It is not permitted to offer "more profits", "big savings" or "customers' loyalty".

It must be simple. This means anybody familiar with software development must be able to understand it and this understanding must be correct.

The pitch must be attractive. The budget is limited and not all can come aboard.

All people have the common understanding about users. This means nobody makes dumb mistakes in design, processes and interfaces. Also nobody follows obvious bad examples from existing internet sites.

For instance:
I'm a project manager. I define plans, estimate risks, distribute resources, give orders, control the project state and report to stakeholders. This helps to finish each project on time and within budget.

I'm a requirements engineer. I gather information from stakeholders and users and convert it into clear and unambiguous requirements. This gives a common understanding about results to be achieved and makes possible precise estimations about work volumes.

I'm a system administrator. I order hardware and software, install and configure them, distribute access rights and control the healthy state of all servers. This allows your site to be online 24 hours, day and night.

I'm a usability expert. I check the design and the processes for common errors, make suggestions for correction and then I test how real users communicate with your site. This makes your site easy to use and each user would be able to find products and to make purchases.

I'm a GUI designer. I choose the color schema for your site, find places for GUI elements and draw mockups of web pages in Photoshop. I make your site attractive and comfortable for users.

I'm a front-end developer. I write the code that renders web-pages in users' browsers and communicates with the server. This is the part of your business processes that the end user sees and works with.

I'm a massage therapist. I massage the backs and the shoulders of your employees. This removes tensions from long time sitting, prevents health issues and makes your staff to feel important.

I'm a back-end developer. I write the server code that communicates with users and databases. This makes your essential business processes alive.

I'm a copywriter. I find right words for all texts from a company presentation to error messages. I fill your site with content that your users can easily understand.

I'm a cleaner. You know what I do. You also know why my work is essential.

Next is your turn.

I'm a ...

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

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

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

Requirements are like naval mines. A lot of projects have sunk by explosions of missing requirements.

Experienced managers and companies gather requirements very carefully and their requirements specifications are good without academies, guides and certifications. They don't spend resources for unnecessary things.

Хотел намекнуть о том, где проблема. Но бесполезно.

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

По моим прикидкам, софтописательная наука свернула с правильного пути где-то в начале девяностых. До этого шло сближение с человеком. У меня в архивах ещё лежит файл, где последней записью стоит «Хватит переписывать книжку!» Практически в каждом утверждении о психолингвистике находились параллели из программирования и сопутствующих процессов, и, записывая мысли, я просто перекладывал их на софтописательскую индустрию.

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

И так во всём.

Вчерась после ужина опять наехал на чистое и светлое у

ailev. Закончилось всё заявлением

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

Сегодня я на самом деле посмотрел, откуда растут ноги у второго слайда.

И открылись бездны.

Похоже, вместо чего-то полезного я напишу про то, почему Главная Таблица Requirements Enginering - это создание тьмы.

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

But one of my points is, with so many poor examples held up by vendors, it is no wonder that poorly written requirements are found acceptable.

So as Eckhard has suggested, I do push back. Maybe that's why I'm unemployed. I guess posting on LinkedIn that your co-workers are morons is a bad idea.

Из дисскуссия в группе RE (Группа закрытая, так что линк работает только для участников)

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

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

A bird's point of view does not allow to see the monsters that live in mud.

I won't fully describe the model I preferably use but simply speaking there are real requirements and there are formal requirements. In most cases they do not match.

I have seen projects with nearly perfect requirements specifications. In all cases there are 2 conditions:
1. The requirements specifications (the formal requirements) were written by people who do the real work.

2. Significant part of requirements was in the state "to be clarified" until the later development stages.

I have also seen mission critical projects where requirements specifications were "adapted" to meet project outcomes. (This means formal requirements were changed to match real requirements after their implementation.)
( Read more... )

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

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

Каждый день готовит чего-нибудь новенькое.

Что и не удивительно, если жизнь идёт по последней моде проповедников agile: вместо requirements engineering храбрые обещания маркетинга, а вместо quality assurance панические вопли в Jira. (Кстати, чем дальше работаю с этим тулом, тем больше он раздражает.

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

Сейчас вместо напильников мощные бензопилы, но всё равно не выходит каменный цветок.

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

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

Краски в тюбиках понадобились для Pocket Palette. Заказ из Штатов был отдельным приключением с перепутанным при пересечении немецкой границы номером посылки и весёлым общением с таможней.

Ещё один короткий текст на немецком.

Anforderungsdokumente sind Texte, die beschreiben, was Kunden brauchen. Wie mit anderen Texten (z.B. Romanen) gibt es wesentlich mehr Leute, die denken, dass sie ausgezeichnet schreiben können, als die Leute, die dafür wirklich fähig sind.( Read more... )

Этот пост скопирован с поста в LJ вручную из-за проблем с автоматическим переносом.

Заметил, что на эфемерность существования специалистов по requirements engineering жалуются в основном люди из индустрии информационных технологий, в просторечии называемые программистами.

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

В ИТ тех, кто может работать на уровне отличном от «Потыкайте в это окошечко и скажите, что вам не нравится», встречал очень редко, хотя как раз в этой области больше всего и крутился.

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

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

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

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

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

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

Ещё один текст на немецком для архива. Переводить на русский влом. Сообщения об ошибках приветствуются.

RE-Tools, ReqIF und andere Albträume in Requirements Engineering

( Read more... )

Profile

vit_r

May 2025

S	M	T	W	T	F	S
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31

Syndicate

Page Summary

Занимательная стартапология
В дебрях водопада
В дебрях водопада
Про ёжика в тумане, зазнайство, языки программирования и вериги
Про ёжика в тумане, зазнайство, языки программирования и вериги
Про чекистское рождество
Moneyfall taming and other lost secrets of ancient ages
Про ёжика в тумане, зазнайство, языки программирования и вериги
Большое сбрасывание [2]
В дебрях водопада
3 sentences challenge
3 sentences challenge
Про ёжика в тумане, зазнайство, языки программирования и вериги
Про ёжика в тумане, зазнайство, языки программирования и вериги
Про ёжика в тумане, зазнайство, языки программирования и вериги
В дебрях водопада
В дебрях водопада
Письма римскому другу
В дебрях водопада
Письма римскому другу

Style Credit

Style: Gray for Stepping Stones by branchandroot

Expand Cut Tags

No cut tags

Page generated May. 30th, 2025 10:28 pm