Comments 114
Самая большая дыра - это отсутствие описания целевой аудитории, которая будет использовать калькулятор. И в каких условиях они будут это делать. В результате половина требований может измениться, а половина быть нерелевантной. Возможно, что мы делаем калькулятор для детей, а может быть мы делаем калькулятор для прорабов на стройку. Я бы предпочла тут аджайл подход - можно сделать за минимальное количество человекодней прототип, проверить на фокус-группе, и вносить новые требования по результатам реальной обратной связи
аудитория не является требованием к калькулятору)
Без аудитории или хотя бы предполагаемой ценности это всё сферические требования в вакууме. Можно придумать ещё пару десятков. Только зачем?
чтобы показать, как много аспектов есть у казалось бы простой программы, чтобы её можно было разрабатывать и сдавать
допустим, вы определились с аудиторией
вспомните ли вы обо всём том, что написано в статье?
вспомните ли про то, какой символ использовать для отделения дробной части от целой?
вспомните ли про то, какой символ использовать для разделения разрядов?
подумаете ли о том, как должен вести себя калькулятор при удержании пальца на кнопке?
Тогда я бы назвала это не требованиями, а гипотезами.
"Мы предполагаем, что нашему пользователю важно явно различать целое число и дробь
Мы предполагаем, что пользователям нужно различать разряды чисел
и т.д."
Во время исследования гипотеза либо подтвердится, либо не подтвердится. Либо будут получены более значимые инсайты, на которые следует сделать акцент в дальнейшем проектировании
Вообще-то то вы тут не правы, а предыдущий автор вполне прав.
Символ разделения дробной и целой части на калькуляторе не имеет значения. Как и символ разделения разрядов. Достояно не использовать для разделения разрядов . Или , и у вас нет проблем с в 99.9 случаев.
Даже если вы используете . И , то через 2 минуты пользования калькулятором пользователь поймёт что к чему.
Далее моя целевая аудитория - космонавты на МКС.
Соответственно 99% ваших требований летит в корзину так как они очевидны.
Более того, поскольку МКС - международная станция, вам прямой путь к скинию ISO норм по отображению цифр, разрядности системы
В ы в своих требованиях допустили ошибку/ у вас только 4 арифметических оператора. В то время как на обычном калькуляторе есть ещё операция смены знака (*-1) которая сильно упрощает расчеты.
Ещё одним вариантом постановки ТЗ на разработку калькулятора - вы делаете улучшенный аналог а не принципиально новое устройство, было бы привести ссылки на существующие образцы, сказать что сделано не так и что надо улучшить.
В результате пользы будет больше а бесполезного текста меньше.
Кроме того, если. Включить «дурочку» то под ваше ТЗ подходит калькулятор работающий в любой система счисления с основанием меньше или равным 10.
Так что не удивляйтесь, что когда ваш QA введёт пример 1+1 он получит 10 в качестве ответа.
Символ разделения дробной и целой части на калькуляторе не имеет значения.
как говорил Джек Воробей — но вы про него слышали! в статье вообще нет упоминания про него. как представляются дробные числа — не указано
Как и символ разделения разрядов.
Так если его не будет, это существенно увеличивает число человеческих ошибок при вводе чисел.
на обычном калькуляторе есть ещё операция смены знака (*-1)
я ниже постил скриншот моего дефолтного калькулятора на xiaomi — там такой операции нет
Ещё одним вариантом постановки ТЗ на разработку калькулятора - вы делаете улучшенный аналог а не принципиально новое устройство, было бы привести ссылки на существующие образцы, сказать что сделано не так и что надо улучшить.
в общеинженерном случае приведение аналога означает выдачу разработчику или аналитику чёрного ящика, который надо отдельно исследовать
например китайцы хорошо владеют реверс-инжинирингом, но это не значит, что определить по микросхеме, как она работает — это дёшево и быстро
Кроме того, если. Включить «дурочку» то под ваше ТЗ подходит калькулятор работающий в любой система счисления с основанием меньше или равным 10.
да, это хороший пример упущенного «очевидного» требования!
я больше скажу — на самом деле для разработки требований к ПО нужно не просто уточнить контекст и аудиторию, а ещё спроектировать использование, а если точнее — спроектировать надсистему, а для этого например сначала разработать требования к человеку, который будет применять калькулятор — в каком процессе, для чего, с какими ограничениями
если вам просто сказать «строитель», у вас же автоматически требований к ПО не появится, тк вы в общем случае не знаете того, что описано выше
По госту это называется "область применения" и относится к основным требованиям.
в ГОСТ 19.201-78 слова «область применения» упоминаются только в пункте
> 2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
раздел «Введение» сложно назвать основными требованиями, это что угодно, только не требования
Вашими бы устами да мёд пить. Лично я видел множество случаев, когда приёмка программы заканчивалась отказом на разделе “Введение” или “Основания для разработки”.
А если подходить к вопросу более формально, то из “Области применения” в ТЗ во многом получаются разделы “Назначение программы” и “Условия применения” в Описании программы.
Еще как является!
Помню у нас студент какой-то пожаловался, что у него калькулятор не возводит в степени (а нужны были дробные показатели) - преподаватель сказал ему, что ну... если у вас калькулятор для домохозяек, то сами виноваты.
аудитория не является требованием к калькулятору)
Так в том и дело, что требования бестолковы - не отражают сути того, что нужно.
Если "общего здравого смысла" нет - то они бесполезны.
Если же общий здравый смысл присутствует - то гораздо проще и полезнее избавиться от ТЗ и сразу писать "что нужно".
Именно поэтому эти недоформализмы и заменяются (где не приколочены законодательными гвоздями) - на "use case / user story", конкретные примеры.
Расскажите пожалуйста, какая аудитория у встроенного калькулятора Андроида
и какие конкретно требования вы определите исходя из этой аудитории
Допустим, для меня это большая загадка (ну, про айфон), и в том числе именно поэтому я не пользуюсь встроенным калькулятором.
Ребята в Apple в 18-й версии iOS наконец, подумали над этим вопросом и реализовали нормальный калькулятор в Заметках, почти как это было в редакторе Слово и Дело 30 лет назад.
Самая большая дыра - это отсутствие описания целевой аудитории, которая будет использовать калькулятор
И краткого анализа геополитического контекста!
Как-то было здесь обсуждение задачи, которую дали Фермана на устный счëт: тангенс гугола... Так в процессе обсуждения выяснилось, что разные программные (да и хардверные) калькуляторы дают разный результат...
И, конечно, кто-нибудь должен следить чтобы ТЗ не превратилось во фрактал!
Какие ещё дыры вы видите в такой спецификации требований? :)
у меня противоричивые чуства: с одной стороны к выводу о том что написать калькулятор на четыре действия невозможно, можно прийти гораздо быстрее,
с другой стороны кто-то может всетаки попытаться начать действительно что-то делать в направлении решения задачи, поскольку в требованиях не достаточно маразма.
С чего это вдруг калькулятор стал простой программой? Арифметические действия изучаются в школе на протяжении 4 лет! Никак нельзя назвать простым то, что выполняет действия, на освоение которых надо потратить аж 4 года.
Рассмотрим, как может выглядеть работа по созданию ТЗ на несложную программу.
О_о! Очень хорошее начинание! Чрезвычайно интересно посмотреть, можно ли раскрутить эту тему до конца. Будет ли этот конец достигнут. За какие сроки. И т. д. И т. п.
Калькулятор должен демонстрировать числа, с которыми происходят вычисления, в графическом пользовательском интерфейсе.
А почему не рассматривается такая возможность, как реализация некоторого внутреннего для ОС компонента и организации соответствующего пользовательского интерфейса?
Калькулятор должен уметь считать. Это суть главное. У него на входе — строка (содержащая набор операций над числами) и на выходе — строка (содержащая результат выполнения операций). То есть, калькулятор — это компонент, который производит преобразование одних строк в другие. (Понятно дело, что мы говорим пока только об обыкновенных численных калькуляторах. В принципе, много чего можно интерпретировать, как калькулятор.) И это должен быть некий компонент без какой-либо привязки к пользовательскому интерфейсу. Другое дело, что пользователю этот самый пользовательский интерфейс очень нужен. Это всё надо понимать и отдавать себе отчёт в том, что, смешение двух различных сущностей в рамках одного приложения породит постоянно действующие проблемы в реализации.
Таким образом, первейший вопрос создания калькулятора — это вопрос о том, что именно делается: приложение или компонент. Понятное дело, что создаётся и то, и другое. Но ТЗ на приложение и ТЗ на компонент будут, очевидно, различаться.
написать компонент ОС — это задача для условно системных программистов, а не прикладных
она встречается гораздо реже и у неё своя специфика
частным случаям — частные решения
Так вы здесь внутренние системные решения почему-то в требования вписали.
Вы как архитектор при проектировании системы вероятно реализуете калькулятор как "компонент для вычислений" и "пользовательский интерфейс", но это ж ваши решения по реализации, это не требования к самому приложению.
Итак, это воскресенье и это время пофлудить, потому что никто не читает воскресный хабр.
Во-первых, не дыры, а отверстия.
Я все листал и все ждал, что в какой-то момент автор напишет - "видите, если все делать задом наперед - то будет трэш и угар, давайте уже сделаем передом назад". Но так и не дождался. В конце я увидел только "Микро-ограничения функций" и "Макро-ограничения". Предполагаю, что в данном случае "ограничения среднего размера" не понадобились. И я ведь так весь день ерничать могу.
Все описанное ниже - строго на основании текста статьи ТОЛЬКО.
Автор говорит как бы правильно, но потому что он старается и вертит головой во все стороны, чтоб не упустить ничего. А не потому, что он знает, что делает. И это не ремесло получается, а искусство, а так жыть нельзя. И автору об этом в первом же комменте указали кстати.
Передом назад - это вот так, как я дальше пишу.
АБСОЛЮТНО ЛЮБАЯ система - это костыль, который помогает сделать что-то. И если не понять, чему этот костыль помогает, то его все еще можно имплементировать. Просто им не будут пользоваться, потому что "а зачем мне эта штука"? А если понять, зачем он делается, то вот мы и получили бизнес-требования (ака БТ) - ответы на вопросы "что", "зачем" и "сколько". И только из них становится ясно, кто по итогу будет пользоваться этим костылем. И узнать у этих людей (порой (но очень редко) это будут не люди, кстати) случаи, в которых этот костыль поможет - и зафиксировать их. В б-гомерзких сторях или в православных юз-кейсах или еще как-то. И назвать их "пользовательские требования" (ПТ). И они всегда и это вообще неочевидно - следствие БП. И только поняв, сценарии юзания этого костыля (это все те же ПТ) - писать уже крнкретно требования к способу воплощения костыля в жизнь так, чтоб он под эти сценарии по итогу подпал. И это называется "требования к решению" (ТР). И они - прямое следствие ПЕ, которые сами - следствие БТ. А ТР могут быть про то, а) что костыль должен уметь (функциональные требования, ФТ) и б) как он должен это уметь (нефункциональные требования, НФТ). ФТ + НФТ = ТР.
Т.е., в сути своей предыдущий абзац звучит так:
БТ -> ПТ -> ТР. И это без шуток часто открытие для юниоров и неосведомленных
ТР = ФТ + НФТ. Это, в принципе, минимальный набор, формирующий ТЗ. Но это ТЗ без возможости доработки. Потому что доработка потребует ПТ, а их тут нет, как видно. И вот так - правильно. И этот подход всегда один и тот же. И это именно то самое ремесленничество. Новый проект? Пришел на дискавери, вызнал БТ, сформировал пул будущих юзеров, узнал у них ПТ, сочинил ФТ. Потом у всех поспрашивал и сформировал НФТ. Конец. Все всегда одинаково.
Ну и с высоты сказанного, о чем написал автор. По всему тексту размазаны ПТ, причем пользователь - это автор ("Суперкорень нам вряд ли завтра пригодится", "Как мы понимаем сейчас, интерфейс вполне может быть как минимум голосовым, если не тактильным по Брайлю" и т.п.) и НФТ, и у них то как раз нормальный источник - все подряд ("Калькулятор должен работать на устройствах Redmi 9A (32 Гб)", "Калькулятор должен выполнять вычисления над выражениями с надёжностью не меньше, чем 98%", "у Google Play есть собственные рекомендации и ограничения"). А в резюмирующей главе - ФТ (это которые функции с микро-ограничениями) и НФТ (которые макроограничения). БТ в статье нет. По итогу автор выдал-таки ТЗ, но потому что старался, а не потому знал как надо.
И я бы написал, почему автор тут ни в чем не виноват, но этот коммент и так уже больше страницы высотой. Но если кто захочет - говорите, напишу)
По итогу автор выдал-таки ТЗ, но потому что старался, а не потому знал как надо.
Обожаю догадки. Я практикую разработку требований с 2004-го года, применяю сценарии использования с 2006-го, подход с разделением бизнес-требований, пользовательских требований и требования к ПО где-то с того же года. С 2013 года мы с коллегами обучили пару тысяч человек такому подходу.
Кмк статья хорошо показывает ограниченность подхода к разработке требований как к заполнению шаблона SRS, как любят делать в некоторых госпроектах и ее только.
Обожаю догадки.
Рад, что сумел доставить Вам удовольствие)
Только небольшой вопросик. После двух тысяч людей, которым Вы лично рассказали про разработку требований в целом, плюс бизнес- и пользовательские требования в частности, Вы пишете явно обучающую (ну или хотя бы показывающую пример) статью, в которой эти требования не упоминаются, зато есть "микро-ограничения функций". Какого эффекта должна была достичь эта статья?
не рассказали, а научили. не надо подменять обучение получением знаний.
повторюсь, показать ограниченность подхода к разработке требований, как заполнению шаблона ТЗ
Ок, приношу глубочайшие извинения
Я писал длинный коммент, но решил написать покороче. Ваша статья не про то, что писать ТЗ по шаблону - неудобно (ограниченно). Вы про шаблон там вообще не пишите. Ваша статья про то, как Вы прорабатываете требования к каким-то аспектам несложной системы, взятым из воздуха. И именно к взятию из воздуха у меня и претензии. Особенно к человеку, который "не рассказал, а обучил" 2 тыщи людей бизнес-требованиям и всему такому. Но если Вы считаете, что так - верно, то ок, это Ваше право)
Но если кто захочет - говорите, напишу
Пишите обязательно. Я то же буду думать над ТЗ. Надо добить хотя бы один рабочий пример до конца. Если, конечно, это возможно.
Фактически у нас получился типичный минимальный прото-юскейс из 4-х шагов:
Программа предоставляет возможности ввода исходных данных и выдачи команды
Пользователь вводит исходные данные и даёт команду
Программа выполняет запрошенную команду над данными
Программа сообщает пользователю результат выполнения команды
Любопытно, что, при таком неожиданном обобщении, мы получили описание, под которое подпадает практически любое приложение.
Например, я захожу и интернет-магазин, выбираю нужные мне товары и нажимаю кнопочку "Заказать", а программа на выходе сообщила мне (на выбор из трёх вариантов):
Заказ оформлен и оплачен.
Заказ не может быть оформлен, потому что кончились такие-то товары.
Заказ не был оплачен, потому что на Вашей карте не имеется достаточно средств.
Можно затребовать оба интерфейса сразу, по крайней мере такой вариант мы видим в типичном десктопном калькуляторе. Стоп, а почему мы решили, что у нас десктоп, а не мобилка? Неужели для простейшей программы надо учитывать контекст применения? Получается, да. Или нет?
Если мы создаём приложение, то нас, конечно, будут волновать эти вопросы. Но, если мы создаём компонент Калькулятор, то мы должны описать некий протокол, в соответствии с которым на вход будут поступать одни команды (Вы же должны понимать, что сами числа — это один тип команд, а, собственно, команды для операций — это другие команды), а на выходе формируются другие.
(Здесь, о сути, происходит разделение на front-end и back-end.)
А уже другие разработчики, руководствуясь Вашим протоколом будут отдельно делать конечное приложение для каждой платформы.
Я бы поспорил с тем, что ваш калькулятор позволяет ВВОДИТЬ АРИФМЕТИЧЕСКИЕ ВЫРАЖЕНИЯ. Он вводит отдельные числа и операции, а с такой сущностью, как арифметическое выражение, вообще не работает. Программа не соответствует ТЗ.
в литературе по программированию такие конструкции называются арифметическими выражениями
https://dit.isuct.ru/IVT/sitanov/Literatura/InformLes/Pages/Glava7_3_1.htm
https://devmark.ru/article/java-calculator-example
в статье не указана «библиотека», пространство понятий, из которой используются термины:
а) прикладная предметная область — арифметика или
б) область предмета разработки — разработка компьютерных программ
Не понял, к чему ваши ссылки. Я знаю, что такое арифметические выражения, но в вашем калькуляторе с кнопками они не вводятся. У вас нет никакого оператора ввода, который читал бы значение " 20 * (10 - 5) " , как в вашей статье. И арифметическое выражение (общего вида, а не частный случай выражения, представляющий одно число) вообще не представляется в вашей программе ни в какой момент.
Я бы не принял такую программу, как на иллюстрациях в вашей статье, на соответствие такому требованию. Программу на джаве, на которую вы ссылаетесь выше, принял бы, а эту - нет.
иллюстрации уже совсем шуточные, о чём вы?
и да, частный случай арифметического выражения — это тоже арифметическое выражение
Калькулятор должен производить вычисления с точностью не хуже 8 знаков после запятой.
Следует напомнить, что у каждого вида вычислений своя точность. Чтобы обеспечить определённую точность результата, нужно требовать соответствующую точность у операндов. Не всегда точность можно гарантировать. Не всегда высокая точность имеет смысл.
Калькулятор должен производить вычисления с числами от 10^-99 до 10^99.
Не думаю, что выбор некоторого фиксированного предела на все случаи жизни полезен. Всё-таки, калькулятор используется в конкретных обстоятельствах. Иногда нужно включать и "научный режим". (Конечно, если у пользователя есть GPU, то можно будет просто здорово извернуться.)))
Не очень понятно, зачем в программе размером целых 50 мегабайт вообще ограничивать диапазон чисел.
А мне не понятно, почему, вообще, здесь возникает вопрос о размере программы? 50 Мб — это что, исполняемый файл? Можно в Кб засунуть. Диапазон чисел определяется задачей. А про задачи у Вас ничего не сказано.
Разные задачи — разные калькуляторы — разные ТЗ.
Как-то так. ;-)
Размер программы – это объективное техническое требование, из которого растёт всё остальное. Форма классического настольного калькулятора, бездумно копируемая многими современными поделиями, продиктована техническими возможностями 4-разрядного микропроцессора с десятком ячеек паряти. Никакого иного объективного основания она не имеет.
Современная молодёжь уже никогда не видела железного калькулятора. Пора уж опомниться, зачем рисовать 20 кнопок и жамкать на них мышкой?!
а что она видела?
Размер программы – это объективное техническое требование, из которого растёт всё остальное.
Вот это я никак не могу понять. Размер программы определяется исключительно реализацией. Какие библиотеки, какие алгоритмы.
Пора уж опомниться, зачем рисовать 20 кнопок и жамкать на них мышкой?!
Вообще-то, ещё бывают и обыкновенные настольные компьютеры, а у ноутбуков может не быть отдельной цифровой клавиатуры. Иногда можно и "жамкнуть". Всё-равно, в ОС должен быть калькулятор. Вот и вопрос в том, как его делать.
Непредвзятому человеку понятно, что вот так:
2+2*sin(0.5)/3 =2,32
Между прочим, это работает даже в поле ввода хабра. Хотя насчёт разрядности я бы тут поспорил.
А причём здесь размер программы?
Потому что в 1970 году такой калькулятор было не сделать из-за размера его программы, и исключительно по этой причине мы должны сейчас смотреть на нарисованные на экране кнопки.
на чем основано ваше предположение? есть ссылки на исследования?
Предположение о чём? О том, что в 1970 году в калькуляторах были маленькие программы, или о том, что современные калькуляторы воспроизводят старые? Это общеизвестные факты.
О том, что дело именно в воспроизведении. С таким же успехом можно утверждать, что колеса круглые, потому что люди увидели луну и по её подобию создали.
Почему, например, дело не в наиболее удобном формате для большинства пользователей.
Когда есть готовое изделие - Т.З. написать не составляет труда. В случае с калькулятором уже есть от Google или MS и еще 100500 разных. Так и говорите - должно быть как то, только вместо А сделайте Б... И указываете разницу что должно быть иначе.
Намного сложнее если вы задумали сделать не клон чего-либо (с небольшими изменениями), а совершенно новый продукт, который нельзя открыть в готовом виде и потыкать.
как видно из статьи, даже у простой программы есть множество аспектов, которые можно учитывать
чтобы делать требования по аналогии, надо уметь исследовать поведение объекта и иметь кругозор как в предметной области, так и в ПО
например представим, что разработчик написал такой калькулятор, который при каждом запросе операции ходит в интернет за каким-то API
и программа ведёт себя формально аналогично уже существующим, чтобы проверить, что это не так, надо догадаться отключать интернет
или допустим новая программа зачем-то кэширует в памяти результаты вычислений в не самом компактном формате
и когда вы её гоняете на одних и тех же примерах и потом отключаете интернет, она формально его не требует и проходит тесты
или например исходный код программы окажется написан вашим разработчиком на языках brainfuck, whitespace, visual prolog с последующей трансляцией в технический не читаемый kotlin
или вообще калькулятор сделан на no code платформе типа adalo
или с фрагментами ворованного нелицензированного кода
например представим, что разработчик написал такой калькулятор, который при каждом запросе операции ходит в интернет за каким-то API
Чтобы такого не было, достаточно чтобы человек был просто адекватен. В здравом уме такого никто делать не будет.
Боюсь, что если чел. не адекватен, то все-равно придумает как сделать глупость при любом детально описанном т.з. и формально будет прав.
А мы-то думаем, зачем софтверным гигантам такие мощные дата-центры? Может быть, там тщательно затабулированы таблицы Брадиса и статистические таблицы Большева (Большев Л.Н., Смирнов Н.В, "Таблицы математической статистики")? Тогда понятно, зачем программа будет ходить в интенет. ;-)
адекватность — это математический термин, означающий «соответствующий». соответствующий чему? вы скорей всего используете его как эвфемизм-замену слову «нормальный»
мне интересно разбирать тему правильной постановки задачи, которая содержит как целевое поведение, так и ограничивает нецелевое.
иначе можно в вашей логике опустить бОльшую часть требований, сославшись на «нормального» разработчика. но понятие нормальности и не определено и сложно проверяемо и тест существенно сокращает количество потенциальных разработчиков и тд
но понятие нормальности и не определено и сложно проверяемо и тест существенно сокращает количество потенциальных разработчиков и тд
Так в том то и фишка - базовые вещи нашего мира то не определены, но мы ими оперируем и на них все зиждется.
мне интересно разбирать тему правильной постановки задачи, которая содержит как целевое поведение, так и ограничивает нецелевое.
Да это невозможно - все равно вы будете опираться на нормальность. Вот если я сделаю кнопки не стандартные а в виде цифр (чтобы область допустимого нажатия совпадала с контуром цифры). По вашему Т.З. так можно - но будет жутко неудобно, т.к. постоянно пальцем будешь промахиваться.
Все равно, по сути, вам нужно передать адекватному человеку свою идею - не более того. А формализовать нет смысла - напишите трехтомник, который все-равно не учтет всех вариантов и будет весьма сложен для восприятия.
Так что самое просто - гуглите уже имеющиеся калькуляторы и пишите - хочу как тот, только вместо А сделай Б. И чел. уже скачивает прогу, смотрит, дорабатывает.
Да это невозможно - все равно вы будете опираться на нормальность. Вот если я сделаю кнопки не стандартные а в виде цифр (чтобы область допустимого нажатия совпадала с контуром цифры). По вашему Т.З. так можно - но будет жутко неудобно, т.к. постоянно пальцем будешь промахиваться.
Так подождите, я же нигде не утверждал, что такое ТЗ, как в статье, исчерпывающее и полное) Специально спрашивал, чего ещё не хватает и по комментариям видно, что потенциально не хватает многого :)
Так подождите, я же нигде не утверждал, что такое ТЗ, как в статье, исчерпывающее и полное)
В попытках написать полное и всеобъемлющее непротиворечивое Т.З. - у вас получится целая книга, которую будет жутко неудобно воспринимать ввиду очевидности многих пунктов и объема воды.
Получается не полезное Т.З. а некая игра разума.
Чтобы было полезное Т.З. - нужно смириться что мир не формален, что основы нашего мира просто воспринимаются интуитивно и ничем не подтверждены, ни на чем не зиждутся. Смириться с этой горькой правдой и перестать пытаться все формализовать - достаточно чтобы адекватный настроенный на результат человек понял вашу идею.
так подождите, я и не предлагал ВСЁ формализовать
я показываю, к чем приводит попытка подробно поставить задачу на казалось бы простое приложение
с другой стороны, чтобы не описывать кучу деталей, как раз существуют и стандарты и повторное использование — когда можно ссылаться на другие разработки.
непонятно, при чём тут «основы нашего мира», если программы среднего и высшего образования известны и можно на них опираться.
Все равно, по сути, вам нужно передать адекватному человеку свою идею - не более того. А формализовать нет смысла - напишите трехтомник, который все-равно не учтет всех вариантов и будет весьма сложен для восприятия.
Ну т.е. вы вообще отвергаете современные практики постановки задач на разработку?
Например, можно уйти от спецификации устройства на спецификацию поведения, например задать требования по тому, кто, в каком контексте, что должен суметь сделать с калькулятором и с каким качеством. По сути это нормальные «пользовательские требования», критерии приёмки, программа испытаний, валидация ПО.
Это как раз подход, который позволяет сместиться на настоящую целевую систему, где оказывается, что нужен не калькулятор сам по себе, а нужно некоторое новое качество человеко-машинной системы, которая очевидно состоит из человека и калькулятора.
А так вообще непонятно, как вы себе представляете например проектирование и производство самолётов, и в частности, например, бортового ПО, если «надо по сути передать адекватному человеку свою идею» при 5000 подрядчиков — так у вас ничего не взлетит, разве что на воздух вместо в воздух :)
Бортовое ПО в реальности с неизбежностью пишут люди, находящиеся внутри определённой школы авиастроения, и, вообще говоря, ТЗ у них носит вторичный характер по отношению к подразумеваемым требованиям и обстоятельствам.
Именно поэтому в хайтеке не может работать задуманным образом 44-ФЗ.
вот мы переводили руководство по разработке требований для встраиваемых авиационных систем
вполне себе понятная инженерная практика, никакого там «давайте наймём правильного контрактора и он сделает как надо»
Как известно, самолёт взлетает, когда вес документации превышает вес самолёта. Документов полно, но они просто являются частью инженерной школы.
я не понимаю, к чему вы ведёте
мы не просто так перевели эти документы
они демонстрируют практику системного проектирования, которую вполне можно заимствовать в коммерческом ИТ
более того, культура юскейсов например, на которую они там сильно опираются, наоборот пришла в общую инженерию из коммерческого ИТ
в коммерческой ИТ тоже формируется инженерная школа, только с ней сложнее, тк высокая турбулентность
Я веду к тому, что заимствовать практику системного проектирования в коммерческом ИТ можно, и даже в ряде случаев полезно, но бортовое ПО вы не напишете с приемлемым уровнем качества, не относясь к соответствующей инженерной школе, хоть вы сколько угодно таких руководств прочтёте. Даже чисто законодательно это лицензируемый вид деятельности, и это не просто так.
в чём магия этой школы, расскажите?
Десятилетия невербальной передачи опыта.
и что конкретно произошло в результате этого опыта?
В первую очередь, у сотрудников в головах формируются паттерны решения задач, главные из которых – паттерны способов организации.
Во вторую очередь, изучается сама предметная область. Вот у вас, например, в вашем документе приведена спецификация подсистемы в приложении D. Там, в частности, используется понятие “крен”. А что такое крен? В какой системе координат он задаётся, где именно проходит нулевой крен? Как крен считается с заданной точностью 0.1˚, если корпус воздушного судна немного деформирован (скручен), что вполне нормально для упругого тела? И так далее. Можно до бесконечности зарыться в любое понятие, если нет источника экспертного знания.
Да банально на вопрос, как зависит тяга двигателя в кгс от величины ускорения свободного падения на данной высоте – не каждый ответит, хотя в данном случае ответ есть в гостах.
прекрасная иллюстрация, спасибо
а почему для работы с этим не достаточно инженерного образования?
после нескольких лет курсов теормеха, дифуров и прочей физики с химией разобраться в этих вопросах не представляет труда, как и найти госты
Ну если для вас не представляет труда, то ответьте.
Инженерное образование редко касается частного знания о предметной области, которое к тому же зачастую представляет собой ноу-хау.
Я вам больше скажу, в авиации и на флоте ответы на эти вопросы разные. И в российском и китайском флоте – разные. А как должен работать палубный самолёт?
разобраться в том, как разбирается обычный системный аналитик — берёт вопрос и изучает. я например сейчас автомобильный проект делаю. оцениваю, что это у меня займёт полчаса-часа на каждый из вопросов.
подождите, так весь замысел вузовском образовании и в частности инженерном в том, что «знание принципов освобождает от знания множества деталей-фактов» :)
или как ещё говорили «мы вас учим добывать и находить информацию».
какой именно самолёт и флот — как раз будет известно в конкретном проекте
С автомобилями всё гораздо проще, поэтому какой-никакой автомобиль может сконструировать любой пакистанец в сарае, а самолёты конструируют единицы. Но при этом конструкция пакистанского автомобиля будет заметно отличаться в худшую сторону от конструкции тоёты, хотя нормативно-технические документы их инженеры могут прочесть одни и те же.
подождите, так весь замысел вузовском образовании и в частности инженерном в том, что «знание принципов освобождает от знания множества деталей-фактов» :)
Это замысел естественнонаучного образования. Никогда не слышал, чтобы в инженерном образовании кто-то учил пренебрегать фактами или претендовал на универсальные принципы.
Основной инженерный замысел состоит в том, что всякий принцип имеет свои границы применения, и всё надо проверять на практике. Только в случае самолёта очень дорого выйдет лично всё проверять на собственном опыте.
О...
Напишите ТЗ на Word, например.
Напишите ТЗ на Word, например.
Какая цель? Если вы формально опишите все в виде требований - получите 10 толстых томов нудного текста, в которых все-равно не все учтено. И кому это поможет?
Передать свою идею можно намного более простым путем. Тут лишь вопрос - этот продукт не сможет сделать один человек - потребуется команда. Как организовать слаженную работу команды - но это совсем другой вопрос.
Возвращаясь к вашему вопросу. Если вы готовы плевать на судебные иски от MS - то вот так прямо и даете Т.З. - должно работать 100% как Word на все платформах, на которых работает Word. Вряд ли в реальности такое может потребоваться, ведь там много легаси. И всегда есть критерий приемки работы - всегда можно сказать - я проверил на такой-то и такой платформе - работает не так как Word (и указываете что именно не так).
Какая цель?
Подтвердить ваши слова, что при готовом изделии написание ТЗ не составляет труда.
Я вот как-то считаю, что даже при готовом изделии написать на него внятное ТЗ - может быть весьма трудоемким.
даже при готовом изделии написать на него внятное ТЗ - может быть весьма трудоемким.
Ну разве что когда объем большой - много букв писать.
А так сравните - когда у вас вообще ничего нет, ноль - нужно придумать концепцию, смысл, учесть потребности. И когда уже все готово и нужно просто одно за другим описать.
подождите, вы правда считаете, что если мы видим, как некоторая чужая программа ведёт себя снаружи, то можем легко описать, как она работает внутри?
Не.
Для начала - нужно досконально понять все возможные варианты использования (иначе у нас ТЗ не опишет как минимум часть функциональности) - а это уже дело весьма нетривиальное.
Вы вот уверены, что знаете все-все-все клавиатурные сочетания ворда? Я вот уверен, что знаю хорошо если половину.
Я категорически не уверен, что догадываюсь о большей части редких вариантов развития событий в нем и принятых по ним решениям.
Короче - для написания полного ТЗ на готовое изделие, на мой взгляд, нужен его обратный инжиниринг. Это тоже не по щелчку пальцев сделать можно.
Я не спорю с тем, что создавать новое сложно - Вигерс упаси.
Я спорю с тем, что описывать существующее нетрудно - нет, может быть очень трудно.
Вы вот уверены, что знаете все-все-все клавиатурные сочетания ворда? Я вот уверен, что знаю хорошо если половину.
Все это есть в документации, иначе смысла нет в них. Завершенный продукт либо имеет документацию, либо интуитивно понятен для использования.
Возможно что для разработки будет удобнее все представить в виде списка - чтобы разработчики не искали в документации или элементах интерфейса. А может и не всегда будет удобнее, возможно документация к готовому продукту выполнена лучше.
Из требований, которые неплохо было бы уточнить: раз нам позволяется вводить выражения большой длины, то нужно установить приоритет операций (2 + 2 × 2 — это 6 или 8?), а также, очевидно, разрешить скобочные выражения.
Также следует определить реакцию на синтаксические ошибки (как интерпретировать ввод "1 + ="?). Со скобками количество различных синтаксических ошибок увеличивается.
Далее, у нас есть возможность переполнения рабочего диапазона даже при вводе, ну и при сложении тоже, как её обрабатывать? А что если при промежуточных вычислениях случается переполнение рабчего диапазона, но ответ может быть вычислен всё равно? (MAX + 1 − 1)
Далее, десятичные разделители и разделители тысяч, нужны? Должны ли зависеть от локали? И что такое локаль — системный язык или задаётся юзером в настройках?
Требования можно улучшать до бесконечности.
Требования можно улучшать до бесконечности.
Вы хотели сказать "продолжать"?
а в какой-то культуре приоритет операций другой? интересно
скобочные выражения я вводить не стал, интересна аргументация за них
переполнения рабочего диапазона чего? в статье таких слов нет
да, про разделители я писал выше
до бесконечности не надо же
я предлагаю ещё подумать про исходный код и его устройство
Нет, зависимость не от культуры. Встроенный калькулятор Windows, например, в ранних версиях вычислял выражения сразу при вводе. В результате 2 + 2 × 2 вычислялось так: 2 + 2 даёт сразу 4, пользователь дописывал × 2 и получал 8. Так работали многие старые, «железные» калькуляторы. Более свежие версии учитывают приоритет операций, и откладывают вычисление и показ промежуточного результата до момента, когда этот промежуточный результат более не сможет измениться дальнейшим вводом пользователя.
По поводу скобок, если вы вводите длинное выражение (например, 1 + 2 / 3 + 4), скобки были бы полезны для случая, если вам на самом деле надо (1 + 2) / (3 + 4).
Под рабочим диапазоном я понимаю диапазон [−10⁹⁹, 10⁹⁹], как указано в статье.
Посмотрев некоторые калькуляторы из store могу добавить
Калькулятор не должен собирать статистику и иную информацию о пользователе)))
Ну хотя бы без его ведома...
"Арабские числа"... Например, 1054 - это число. На вашем калькуляторе будет любое возможное число, или только самые используемые? Где требования к набору чисел или я могу сам выбрать нужные? Арабских цифр всего 10, а записываемых ими чисел...
Денис, отличная статья! Показан пример, что даже для примитивной и давно известной программы в ТЗ нужно подумать о различных аспектах в различных направлениях.
Придирки к аудитории, БТ/ПТ интересны, конечно, но как будто оторваны от реальности. Мне подход с ТЗ кажется понятным и как учебный пример довольно хорошо показывает, что бы я отдавал разработчикам. Вряд ли токарь на заводе, вытачивая деталь, будет метаться в сомнениях насчет аудитории, для которой эта датель нужна. Знание могло бы быть ему полезно, но важнее размеры детали на чертеже. Другие люди зарнее об этом подумали, вероятно.
Рассуждения про интерфейс и кнопки из 1970х касаются лишь одного раздела из ТЗ и достаточно легко абстрагироваться, что в реальной задаче в этом разделе могли быть другие требования.
Статью добавляю в закладки на два случая:
Подскажи, как мне писать ТЗ разработчику, когда не знаю, с чего начать
Ой, что там писать, делать надо, по ходу разберемся...
Вряд ли токарь на заводе, вытачивая деталь, будет метаться в сомнениях насчет аудитории, для которой эта датель нужна. Знание могло бы быть ему полезно, но важнее размеры детали на чертеже. Другие люди зарнее об этом подумали, вероятно.
Поэтому токарь работает по чертежу, а не по ТЗ. Как компилятор по исходному тексту программы. И поэтому токаря постепенно заменяет станок с ЧПУ. И поэтому же кодировщиков, не думающих об аудитории и прочих сложных вещах, постепенно заменит генеративный ИИ. Но инженерам об этом нечего беспокоиться.
Чего, на мой взгляд, не хватает:
Используемой системы счисления (мы же хотим зафиксировать десятичную? Или двоичную? Или какую-то иную? Или поддержку нескольких с возможностью переключения?)
Набором операнда поразрядно с помощью кнопок, дающих все необходимые цифры, начиная со старшего разряда (так-то можно просто по умолчанию ставить, скажем, ноль - и две кнопки - n++ и n--. Ну и переключатель, на каком разряде мы эту кнопку применяем)
Отдельных кнопок операции (иначе тоже можно сделать циклический переключатель типа операции)
(Не)использование кнопок памяти
(Не)использование кнопок сброса
Наличие(отсутствие) кнопок корректировки ввода
(Не)возможности работы с буфером обмена
Соответствия приложения требованиям магазинов приложений
Требованиям к компонентам, используемых для создания приложения (например, лицензионная чистота)
Требования к сбору статистики использования (или явно обозначенный отказ от такой статистики)
Требования к платформе(ам) функционирования (список ОС и версий, на которых должен быть возможен запуск, наличие/отсутствие выхода в инет и т.п.) - если я вкорячу на Redmi Андроид версии 4.4.4 - на нем точно обязано запускаться?
Как написать ТЗ на простую программу (калькулятор)