— нужна библиотека для сортировки больших файлов. G>>Это слишком маленький пример. Речь идет о проектах минимум полгода до первого релиза. Выбор как сортировать файлы потеряется на фоне других задач. S>Из маленьких и состоит проект. Не убегайте от ответа.
В том и проблема что не состоит. В крупном проекте (от полугода программирования) задачи типа "сортировка большого файла" занимают настолько мизерную часть кода, что обсуждать проблемы связанные с этой задачей не имеет смысла.
S>Вот это как бы вы решали? Искали бы готовую библиотеку или же писали вручную? Понятно что структура данных может усложняться.
Я бы готовый вариант взял через полчаса гугления.
S>Все же нет — анализ требований — это четкое понимание что мы хотим получить на выходе.
И чего мы хотим получить на выходе "анализа требований" ?
S>>>Сколько у вас времени займет подбор библиотеки? Предложенный мной вариант с LevelDB — хороший или плохой? Будете писать самостоятельно или лучше такой вариант? G>>Я думаю в масштабах достаточно крупного проекта (см выше) займет незаметно малую величину. S>Вы убегаете от ответа таким образом. Хотите размазать истину.
Это вы хотите свою идею подогнать под условия, я не хочу этим заниматься.
S>>>>>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это? G>>>>Я тоже могу бесплатно стоимость назвать, как это относится к теме? S>>>А как ты назовешь стоимость без сбора, систематизации и анализ требований? G>>Возьму и назову, что мне помешает? S>А как вы назовете, если не знаете что будете делать? Ведь чтобы знать что от вас требуют — нужно собрать и проанализировать требования.
Я сам назову и цену, и состав работ. Зачем мне что-то для этого анализировать?
Разработка ПО это не НИОКР уже давно. Даже не инженерия вида "построить мост". Это скорее ремесло как "сшить костюм". С одной стороны у заказчика есть требования, с другой стороны уже миллионы костюмов были сшиты за всю историю, да и вы сами скорее всего уже не один костюм сшили. Весьма вероятно что мастер даже гораздо лучше заказчика знает какой костюм надо сшить. Что ему помешает назвать цену? По короткому, даже устному, брифу будет понятно какой костюм нужен. Также и в ПО.
S>>>>>Это все процесс кодирования — написания кода. И этот процесс включает исследования. G>>>>Хочешь сказать, что в принципе нет возможности описать продукт до того как будет написан код? G>>>>Или ты просто не видел этого ни разу? S>>>Это будешь еще дольше, чем выразить в коде. G>>Что именно будет дольше? S>Представить все алгоритмы в виде квадратиков. Представить все состояния в виде диаграмм...
Зачем это делать?
S>В коде это проще и быстрее. Те же состояния — можно автоматом сгенерить схему переходов на основе кода машины состояний.
Это верно. Только с UI так не получается. В подавляющем большинстве случаев UI сгенерированный на основе схемы не подходит вообще никому. А UI не учитывающий пользовательских сценариев оказывается "не интуитивно понятным" для конечных пользователей.
Можно ли "проще и быстрее" сделать UI в коде и не заниматься рисованием прототипов\интерфейсов?
Сбор, систематизация и анализ требований vs кодирование
Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы.
Согласны с этим или нет? Что по вашему опыту?
То с чем я сталкивался — никто не проводил детального анализа до написания кода. Система обычно известна в общих чертах, примерно что хотят получить на выходе. Могут нарисовать и попытаться с умным видом описать детали — в при соотнесении с реальностью все рушится как карточный домик.
И только когда идея получает выражение в коде — только тогда появляются четкие вопросы, осознаются реальные проблемы и ищутся пути решения.
Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы? UML-диаграммы и нарисованные в виде квадратиков алгоритмы?
Приведу простой пример. Есть некое API. Можно с умным видом описать его в виде таблиц — перечислить все методы и входящие-исходящие параметры. Но в реальности, когда это API начнут использовать, когда создадут первого клиента — только тогда выявляются реальные требования и ищутся пути решения — какие методы реально нужны, какие данные нужно принять и вернуть. Даже до того как клиент создан — разработчик клиента может посмотреть и сказать — ну вроде все ОК. И только как начал писать код — только тогда всплывает что нужно на самом деле.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, maxkar, Вы писали:
S>>> Вот ту же библиотеку LevelDb, которая, по сути, тоже делает лишь сортировку — вы бы за сколько написали? M>>Она не делает "лишь ту же сортировку": M>>
M>>LevelDB is an open-source on-disk key-value store ...
M>>It supports batching writes, forward and backward iteration, and compression of the data ...
S>Так а что, из-за компрессии данных — уже не сможете за пол дня сделать? Сложно добавить 1 строчку кода gZip?
Две. На распаковку и на запаковку. И столько же (а то и больше) времени на прокрастинацию над требованиями. Например, нужно ли сжимать ключи записей или только их значения. Должна ли упаковка быть независимой для всех записей или группы могут сжиматься вместе (это влияет на итоговый объем). Видите, уже на требования потратил больше времени, чем на реализацию. В некоторых специальных условиях можно было бы и в одну строчку сделать — установить файлу атрибут storage compression, но опять же — нужно сначала выяснить требования и применимость. Это куча времени, gzip универсальнее.
S>Поймите что я таких как вы уже не первого наблюдаю — причем некоторые с 15 летним опытом. Думают что все легко и просто, пока не коснется практики.
Нормально у меня все с практикой. Не все легко и просто. Но то, что вы описываете — это такие мелочи. Которые для типичного проекта выливаются в придуманные внутренние проблемы. Т.е. очень часто приходится сначала выпилить кучу конфликтующих библиотек, обложенных костылями, и уже потом приступать к решению интересных задач на пересечении бизнеса и технологии. Самые интересные задачи возникают, когда есть с десяток разных требований к одному и тому же участку кода. Производительность, безопасность, потребление памяти, сопровождаемость и т.п.
S>Т.е. вы предлагаете не писать а использовать готовый инструмент — сортировку B-tree, которую использует ОС для файловой системы?
Ну не знаю, моя FS испольует htree. И API, которые я знаю, не гарантируют порядок обхода файлов в каталоге. Так что придется писать сортировку. Хотя я бы в памяти ключи сотритровал. Не было требования поддерживать объем ключей, который в память не влезает. А данные — так и быть, пусть их будет много.
S>Есть ли у вас осознание что именно вы предложили?
Я предложил минимальное решение, удовлетворяющее требованиям .
S>Операционная система — это тоже всего лишь программа. И вызывать ее функции — это тоже вызов своего рода библиотеки.
Нет. Это среда выполнения. Так просто от нее не отказаться. И, в отличие от библиотек, нельзя смешивать функции нескольких ОС в одном приложении.
S>Однако же вам нужно исследовать эту библиотеку, чтобы понять корректно ли она работает, к примеру, с большим количеством файлов в одной папке.
Нет. Не нужно. Не было такого требования, что среда выполнения работает некорректно. Поэтому по условиям задачи я могу хранить хоть триллионы файлов в одном каталоге. Не нравится? Можно протестировать конкретную ОС. Но пойдет это по статье "выяснение требований" — я будут тратить время на выяснение контекста, в котором должна работать библиотека. Да, я буду писать какой-то код. Но к коду библиотеки он не будет иметь никакого отношения. Это не кодирование.
S>В идеале вообще ничего писать не нужно — просто найти готовую систему. Второй случай — собрать систему из готовых библиотек. Третий случай — доработать готовые библитеки. Четвертый — писать самому.
Приоритет зависит от требований. Да, найти готовую систему (которая отвечает всем современным и будущим требованиям) — идеальный вариант. Только для этого нужно знать все требования. А обычно заказчик хочет "точно такую же систему, но с бриллиантовыми пуговицами". Начинаешь выяснять — выясняется, что решается вообще другая проблема и есть лучшее решение.
Re: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы. S>Согласны с этим или нет? Что по вашему опыту?
Когда начинается большой проект (или сперва он маленький, а потом быстро растет), то к нему собираются требования (бывает очень быстро тяп-ляп, бывает долго и тщательно), потом он реализуется, при этом пишется куча кода, так что процентное соотношение достаточно большое в плане кода, даже если требования собирались и анализировались тщательно.
Потом проект расширяется, растет, и через несколько лет это уже большой-большой проект, с кучей логики. И оказывается что что-то внедрить или изменить в большой системе это надо очень хорошо подумать как эта новая функциональность будет соотноситься со старой, так чтобы система оставалась адекватной, а не превратилась в мутное болото.
Если при этом еще есть и интеграция с другими системами, то надо узнавать, как поведение логики тут может отразиться на тех системах.
И оказывается что вот этот анализ "нужна ли эта функциональность и в каком именно виде" часто занимает много больше времени чем собственно изменение кода.
Предельный случай — но он бывает! — когда заказчик запрашивает функциональность для решения проблемы, проводится аналитика и выясняется что эту проблему можно решить уже имеющейся в системе другой функциональностью. Несколько дней анализа и 0 минут изменения кода.
Так что процент времени разный в зависимости от размера проекта и времени его жизни.
S>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы?
Описание требуемой функциональности системы. Чем четче — тем проще потом будет кодировать и меньше вопросов придется решать по месту (но какие-то все равно наверняка придется, действительно учесть все сразу часто не удается или занимает неоправданно много времени)
S>Приведу простой пример. Есть некое API. Можно с умным видом описать его в виде таблиц — перечислить все методы и входящие-исходящие параметры. Но в реальности, когда это API начнут использовать, когда создадут первого клиента — только тогда выявляются реальные требования и ищутся пути решения — какие методы реально нужны, какие данные нужно принять и вернуть. Даже до того как клиент создан — разработчик клиента может посмотреть и сказать — ну вроде все ОК. И только как начал писать код — только тогда всплывает что нужно на самом деле.
Выглядит как "надо сделать АПИ, мы не знаем зачем оно нужно, кому оно нужно, какие задачи будет выполнять, но АПИ нам вот точно надо".
Но пусть даже так, решить вопрос по месту — это то же самое, часть времени ты будешь кодировать, а часть переписываться с разработчиком клиента согласовывая детали реализации. Вот эта вторая часть и есть сбор, систематизация и анализ требований, и она вполне может быть сложнее самого кодирования (намекну — клиентов может быть 50, у каждого свой разработчик, и чуть-чуть разные пожелания, а тебе в твоем АПИ придется как-то учесть все потребности).
Re[15]: Сбор, систематизация и анализ требований vs кодирован
S>LevelDB писать с нуля — не неделя-две — а требует квалифицированного программиста и стоит это около несколько десятков тысяч долларов.
Написание ни одной СУБД не стоит таких маленьких денег. Если это не лабораторная/курсовая/дипломная работа. Думаю, вы ошиблись на 1-2 порядка, если говорить о коммерческом продукте.
Патриот здравого смысла
Re[3]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Нахождение оптимальных решений.
Прежде чем искать оптимальное решение, нужно определить, что именно является оптимальным решением. Быстродействие? Надежность? Потребление памяти? Скорость кодирования? Да и вообще, нужно определиться, нужно ли "оптимальное решение" в данном месте (ладно, если не нужно — у нас оптимальное решение по критерию "сложность реализации"). Т.е. чтобы начать искать оптимальное решение, нужно собрать требования.
S>К примеру, выбор подходящей библиотеки — кто этим будет заниматься на этапе сбора требований?
Архитектор/лидер/команда. Зависит от процесса. Потому что часть анализа проекта — проверка возможности его выполнения (feasibility). Прямо в процессе разговора с пользователями требования приоритизируются по техническим рискам. Если все более-менее ложится в знакомые библиотеки, проблем нет. А вот если не ложится, производится дальнейшее исследование. Может производиться архитектором. Может отдаваться команде. При этом может оказаться, что команда уже решала проблему и знает решение. Или не знает и нужно провести эксперименты. После этого выяснить, что у нас получились три требования, которые друг с другом не сочетаются. И опять идет процесс общения с "заказчиками" о том, что можно выкинуть. А может вопрос записывается в риски и проект строится на условии успешной реализации прототипа.
S>Иногда нужно из исходников собрать библиотеку, протестировать на неких данных — сделать выводы о необходимых доработках — смотреть код.
Исследовательская работа. Ну и да, с целью уточнения/изменения требований. А потом выяснится, что допиливать библиотеку придется следующие три года и внезапно выясняется, что требование не очень-то и нужно было.
S>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!!
А они готовы дать гарантии? По качеству решения и по срокам выполнения. А потом заплатить, если не уложились в сроки или если приложение не удовлетворяет спецификации. А так подобные конторы работают с типовыми решениями в нише. Там все требования более-менее известны и ложатся в шаблон. "Кастомизация" готового решения опять же будет по большей части выяснение требований, описание контракта и т.п. Кодирования там мало. А какие-нибудь нестандартные требования они вряд ли делать станут. Или вообще не реализуют в надежде, что заказчику и так сойдет (гарантий они обычно не дают).
S>Т.е. по их мнению этот этап стоит не значительных денег, которыми можно пренебречь.
Не совсем. У них "сбор требований" размазан по многим типовым заказчикам. Там "кодирование" обычно тоже не так много стоит.
S>Предвидеть все заранее, знать тонкости каждого протокола, знать все алгоритмы, которые придется реализовывать, знать тонкости библиотек.
Не нужно предвидеть все заранее. Нужно уметь структурировать знания. Что-то может быть определено в риски и получить приоритет в реализации (чтобы можно было остановить проект если риски реализовались). Что-то уже известно, что работает. Какие-то вещи можно спросить у команд, которые с этим уже работали и могут заметить проблемы. А какие-то вещи можно изолировать в архитектуре и иметь несколько планов (План А для первого приближения и План Б на случай, если всплыли какие-то проблемы). Проверка доступности — это командная работа. Да, нужно знать, как распределяются компетенции в команде/компании. Можно привлекать разных людей на разных этапах. Никто же не говорит, что нужно в одиночку это все делать.
S>Вы представляете себе, чтобы до написания кода некая команда МЕСЯЦАМИ на хорошем окладе просто анализировала требования и рисовала квадратики? Я не могу такого представить.
А почему "до написания кода"? Это никто кроме вас не утверждал. Выяснение/уточнение/анализ требований происходит и до, и в процессе кодирования. Разработчики могут выполнять несколько разных активностей/ролей в течение дня. Кодирование — одна активность, выяснение требований — вторая.
S>Это все процесс кодирования — написания кода. И этот процесс включает исследования.
Исследования-то оно включает. Но во многих случаях можно сделать наоборот и включить "написание кода" в процесс выяснения требований. Ну хотя бы потому, что на встречу с пользовтаелем тратится час, потом за 10 минут его хотелки реализуются и задается вопрос: "ты этого хотел?".
S>>>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. G>>Этот вопрос надо задавать не сообществу, а тому кто делает утверждение. S>Интересует мнение и опыт других.
Еще раз. Никто не утверждал, что сбор требований должен быть завершен перед кодированием. Он может продолжаться и в процессе реализации, и в процессе тестирования и даже в процессе эксплуатации. Автор всего лишь утверждает, что большую часть времени программист как раз выясняет, что должно быть сделано а не пишет код.
S>Даже не подумаешь о том, что всплывет в процессе использования.
"Что всплывет в процессе использования" — тоже сбор требований. Но на позних этапах. Потому что если это всплывшее не является требованием, то зачем на него вообще вни
S>Узнать что он выдает по итогу — как проверяет гипотезы.
План он выдает с четкими условиями. Выглядит примерно так: "На данном этапе мы знаем/считаем, что ... (длинный и скучный список). Поэтому предлагается решение АБВ, которое удовлетворяет контексту и требованиям. Другие решения в данном контексте не применимы". Когда приходит фидбэк (от программистов, от пользователей, от девопсов — не важно), он включается в требования/контекст. Потом список превращается в табличку, обрастает приоритетами, рисками и прочими атрибутами. В какой-то момент страничка может превратиться в "изначально у нас были условия АБВ, поэтому решение было ..., теперь условия изменились, у нас условия ВГД, идеальное решение будет выглядеть как ... и рабочий план перейти к нему состоит из ... (еще один список)". Все документы живые. Гипотезы часто проверяются общением с людьми.
Re: Сбор, систематизация и анализ требований vs кодирование
.
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы.
S>Согласны с этим или нет? Что по вашему опыту?
S>То с чем я сталкивался — никто не проводил детального анализа до написания кода. Система обычно известна в общих чертах, примерно что хотят получить на выходе. Могут нарисовать и попытаться с умным видом описать детали — в при соотнесении с реальностью все рушится как карточный домик.
S>И только когда идея получает выражение в коде — только тогда появляются четкие вопросы, осознаются реальные проблемы и ищутся пути решения...
Вопрос поставлен общо, поэтому, в общем, да, соласен, кодирование порядка 15%.
Про систематизацию и анализ, тут все очень специфично, как ни странно, хотя вроде бы это фундаментальная вещь.
По моим наблюдениям существуют две взаимопротивоположные парадигмы. Первая — это то, что, мол, хорошо бы вначале
пообщаться с заказчиками и будущими пользователям, посмотреть на конкурентов, и в итоге предусмотреть как можно
больше ключевых моментов, которые затем сложно будет менять (ЯП, фрамеворк, архитектура и т.д.).
Вторая — это то, что всего сразу не предусмотришь, а выжить надо, поэтому делается то, что будет привлекать внимание и
генерить фидбек (МВП и т.д.).
Мне субьективно ближе первый подход. Но фейлов и успехов и той и другой парадигмы за 20 лет видел примерно одинаковое
количество. Кмк, большинство фейлов которые пришлось видеть были связаны с тем, что парадигма уже изначальна была заложена в разработку,
до или после слишком поверхностного знакомства с требованиями и ситуацией на рынке.
В то же время, если во главе проекта находится опытный человек (из разработчиков или из бизнеса, опыт должен быть
существенный), и сбор требований, МВП, фидбеки, анализ проводит как для себя (иными словами, если руководитель
нормально заинтересован, в том числе финансово), то проект взлетает хорошо, как минимум выходит в ноль при крайне неблагоприятных условиях.
Re[17]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Есть здравый смысл и людям не нужно уточнять миллионы деталей, потому что пределы здравого смысла и так ясны.
Да вот как раз наоборот. Полагаться на "здравый смысл" в командной разработке — очень плохая идея. Во-первых, люди очень часто принимают решения иррационально, на основе "интуиции". Это далеко не всегда приводит к оптимальным решениям. В быту это скорее полезно (меньше ресурсов мозга тратится), а вот в разработке — вредно. Во-вторых, все люди разные. Образование, опыт, воспитание и культурные традиции, текущие цели и текущий контекст работы. То, что для опытного работника с десятилетним стажем на производстве является здравым смыслом может быть совсем не очевидным фактом для разработчика, который разрабатывает систему для того же производства. Хорошо систематизированные требования уменьшают вероятность того, что возникнет взаимонепонимание на "очевидных" вещах.
S>Вспомнилось: https://xakep.ru/2006/12/16/35784/
О! Прекрасная иллюстрация о том, что происходит при неодстаточной систематизации требований. Смотрите. "Солонки на столах" сами по себе не являются требованием. Это одно из возможных решений задачи "досолить пищу после подачи". В процессе эксплуатации выяснились новые требования — безопасность и доступность. При этом заказчик, путая цель и средства, продолжает вкладывать ресурсы в уже существующее решение "солонки на столах". Хотя для исходной задачи "досолить" есть простое административное решение. Убрать солонки со столов, раздать официантам. Обязать официантов досаливать еду по просьбе клиента. И для получения решения всего лишь было нужно обратиться к специалистам по систематизации требований.
Re: Сбор, систематизация и анализ требований vs кодирование
.
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы.
S>Согласны с этим или нет? Что по вашему опыту?
15% от вообще всего времени, потраченного на разработку?
Ну да.
потому что никто не отменял сбор, систематизацию, анализ требований.
Никто не отменял декомпозицию задач, планирование.
И архитектуру.
И всякие код-ревью.
И тестирование.
И развертывание на дев-тест-препрод-прод (или что там из этого присутствует) Возможно, в ручном режиме, а возможно, надо долго и нудно писаь, а потом поддерживать всякие ci/cd и прочие штуки
и поддержку 3-й линии. ковыряние в логах, выяснение у всех свечку-державших, что же собственно, произошло.
и помощь коллегам
И кучу времени, убитых на интеграцию (не написание кода, а на понимание, как оно вообще может работать вместе)
И коммуникации с командой, и с заказчиками, и со смежниками.
А, ну еще документацию — руководство пользователя, администратора, базу знаний по траблшутингу.
Документацию самого проекта в конце концов.
И вишенкой на торте — всякие аджайл и прочие религиозные ритуалы, отъедающие туеву хучу времени.
В общем, надоело описывать активности.
Они могут быть раскиданы по разным другим людям. А могут падать на разрабов. Это уж смотря какие процессы сложились в компании.
15% от времени конкретного программиста? Возможно, если он сидит на двух или нескольких стульях. Но в среднем скорее процентов 50 или даже больше.
Re: Сбор, систематизация и анализ требований vs кодирование
.
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы.
S>Согласны с этим или нет? Что по вашему опыту?
Чем крупнее проект и чем выше цена ошибки, тем больше времени тратится на сбор требований и системную аналитику.
Re[11]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, so5team, Вы писали:
S>>Вот требование — сделать поисковик по интернету аналог гугл и бинг. Все! Это достаточно четкое требование. S>Это не требование. Это хотелка.
Достаточно для того, чтобы сказать сделана работа или нет.
S>>А вот уже раскрыть тех. детали — каким образом мы сможем сделать такой поисковик — это не сбор и анализ требований. S>Это как раз и будет сбор и анализ требований.
Что вы вкладываете в понятие "анализ требования"? Подобрать библиотек из опенсорса, с помощью которых можно как из кирпичиков собрать части системы — это анализ требований?
Re[12]: Сбор, систематизация и анализ требований vs кодирован
G>Еще раз повторю: писать свой поиск может 5-10 компаний в мире или очень богатые и не совсем здоровые люди.
... и даже там будет ооооочень много работы помимо не то что кодинга, но и всей разработки вместе взятой (архитектура, тестирование и т.д.). В частности, всякие юридические моменты, удовлетворение требований регуляторов в разных странах, какая-то ручная модерация и рассмотрение жалоб, обслуживание CI/CD/прода, обслуживание железа и куча всего.
Патриот здравого смысла
Re[15]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Скорость не критична. Развитие не требуется. Вызывать нужно из .Net Core на Ubuntu. S>Все! Мы все требования собрали. 2 минуты ушло. А теперь подумайте сколько времени уйдет на реализацию!!!
Допустим, 4 дня мне на реализацию (я ленивый и имею склонность к идеализму в решениях) плюс один день кого-нибудь с форума, кто хорошо знает .NET. Эксплуатация будет вам стоить 30000$ в месяц.
Не верите? Архитектура и реализация следующая. Я пишу систему, которая через http принимает запросы с выражениями для вычисления (плюс basic authorization) и сохраняет их в базу. Я раз в день читают очередные запросы и очень тщательно лично выполняю (интерпретирую) их на бумажке. Могу curl'ом делать GET-запросы. Потом записываю результат выполнения скрипта в базу, где его может опросить скрипт. Все крутится в AWS (Postgresql RDS + Beanstalk + ELB). Помощь коллег будет нужна на написание клиента, который будет вызывать мой сервис и периодически опрашивать результаты. Собственно, всё. Эта архитектура удовлетворяет всем требованиям. Какие требования — такое и решение. Ничего особо сложного.
Re: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы. S>Согласны с этим или нет? Что по вашему опыту?
Да.
S>То с чем я сталкивался — никто не проводил детального анализа до написания кода. Система обычно известна в общих чертах, примерно что хотят получить на выходе. Могут нарисовать и попытаться с умным видом описать детали — в при соотнесении с реальностью все рушится как карточный домик.
Ммммм, тут надо говорить о методах сбора, систематизации и анализы требований, это не просто описание разделов соответствующей документации по госту, иногда стоит в начале проекта поставить пилот, и собирать замечания от пользователей: тут то не так, а тут это. Но обязательно их фиксировать отдельным документом, и утверждать протоколом специального совещания. И нужно различать шароварный сидиэжектор и какую-нибудь корпоративную автоматизацию. Во втором случае основная работа не просто собрать требования, а еще и согласовать функционал, чтобы потом на приемке тебе мозг не вынесли (тут расширенное ТЗ больше в юридической плоскости лежит, надо тщательно подбирать формулировки — был случай в моей практике, когда нас кинули на два млн, докопались как раз до формулировки в расширенном ТЗ).
Кроме того, хорошо прописанные требования это почти готовая программа, ее осталось перевести с естественного языка на формальный язык программирования.
Счастье — это Glück!
Re[17]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, AleksandrN, Вы писали:
AN>>Чем крупнее проект и чем выше цена ошибки, тем больше времени тратится на сбор требований и системную аналитику.
S>А как же время на тестирование — если цена ошибки высока? Почему именно сбор требований?
Роль тестирования для таких проектов тоже возрастает. Но тема про сбор требований, про него и написал
А тест-кейсы создаются на основе требований.
Re[9]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
bnk>>Речь скорее всего про разные вещи. bnk>>Задача "сортировка файла" проектом не является, это же просто задача.
S>Проект состоит из таких вот задач. И на поиск решения для некоторых из них — троится немало времени. S>Да, можно согласится что время тратиться на написание документации, тесты, создание авто-тестов. Но никак не на сбор и анализ требований — это вообще 1% от проекта.
IMHO если не тратить на обсуждение кучу времени, придется постоянно переписывать код.
В конце концов заказчик просто устанет от этого и выберет другого исполнителя, или у него деньги закончатся.
Цена ошибки увеличивается экспоненциально по мере реализации кода.
На этапе когда только обсуждаешь — 1 рубль, когда код написан — 10 рублей, когда выложен в продакшен — 100 рублей.
Самая большая ошибка — решать не ту задачу.
А многие задачи можно же решить вообще без написания кода, чисто административными методами
Re: Сбор, систематизация и анализ требований vs кодирование
.
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы.
Уточни у того кто заявляет какие артефакты на выходе этого процесса он рассматривает, чтобы в говорили об одном и том же.
S>Согласны с этим или нет? Что по вашему опыту?
По моему опыту если взять любой длинный проект, среднюю дневную продуктивность программистов в строках кода поделить на количество строк кода в проекте, то получится как раз около 15%.
Чем делают программисты 85% времени? Видимо этот самый "сбор, систематизация и анализ требований".
S>То с чем я сталкивался — никто не проводил детального анализа до написания кода. Система обычно известна в общих чертах, примерно что хотят получить на выходе. Могут нарисовать и попытаться с умным видом описать детали — в при соотнесении с реальностью все рушится как карточный домик. S>И только когда идея получает выражение в коде — только тогда появляются четкие вопросы, осознаются реальные проблемы и ищутся пути решения.
Потому что многие считают, что для анализа нужна более низкая квалификация, чем для написания кода. Средний ценник системного или бизнес-аналитика ниже ценника программиста.
По факту такой анализ требует больше знаний, умений и навыков, чем программирование.
По этому фактически анализом и систематизацией по большей части занимаются сами программисты теми средствами, которыми владеют.
S>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы? UML-диаграммы и нарисованные в виде квадратиков алгоритмы?
Этот вопрос надо задавать не сообществу, а тому кто делает утверждение.
Я, например, считаю что до начала кодирования нужно проектирование интерфейсов. С артефактами в виде интерактивных прототипов UI, для пользовательского UI, или коллекцией запросов в Postman для будущего веб-сервиса. Естественно эти прототипы должны быть не просто художеством в вакууме, а согласованы с программистами, которые их будут делать. Наличие заранее подготовленных таких артефактов, по моему опыту, помогает сократить время на написание кода до 10 раз.
А если никто заранее этого сделать не может, то идем итерационным путем — делаем прототип, получаем фидбек, переделываем. Схемы, диаграммы и длинные текстовые описания не помогают.
Re[2]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, gandjustas, Вы писали:
G>Чем делают программисты 85% времени? Видимо этот самый "сбор, систематизация и анализ требований".
Нахождение оптимальных решений. К примеру, выбор подходящей библиотеки — кто этим будет заниматься на этапе сбора требований? Иногда нужно из исходников собрать библиотеку, протестировать на неких данных — сделать выводы о необходимых доработках — смотреть код.
G>Потому что многие считают, что для анализа нужна более низкая квалификация, чем для написания кода. Средний ценник системного или бизнес-аналитика ниже ценника программиста.
Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это?
Т.е. по их мнению этот этап стоит не значительных денег, которыми можно пренебречь.
G>По факту такой анализ требует больше знаний, умений и навыков, чем программирование.
Нужен человек со сверхспособностями для этого. Предвидеть все заранее, знать тонкости каждого протокола, знать все алгоритмы, которые придется реализовывать, знать тонкости библиотек.
G>По этому фактически анализом и систематизацией по большей части занимаются сами программисты теми средствами, которыми владеют.
Не по большей части — а просто нет иного пути. Вы представляете себе, чтобы до написания кода некая команда МЕСЯЦАМИ на хорошем окладе просто анализировала требования и рисовала квадратики? Я не могу такого представить.
Это все процесс кодирования — написания кода. И этот процесс включает исследования.
S>>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы? UML-диаграммы и нарисованные в виде квадратиков алгоритмы? G>Этот вопрос надо задавать не сообществу, а тому кто делает утверждение.
Интересует мнение и опыт других.
G>Я, например, считаю что до начала кодирования нужно проектирование интерфейсов. С артефактами в виде интерактивных прототипов UI, для пользовательского UI, или коллекцией запросов в Postman для будущего веб-сервиса. Естественно эти прототипы должны быть не просто художеством в вакууме, а согласованы с программистами, которые их будут делать. Наличие заранее подготовленных таких артефактов, по моему опыту, помогает сократить время на написание кода до 10 раз.
Даже согласование с программистами не поможет — пока не начнешь делать — не поймешь все ли нюансы учтены в API или нет. Даже не подумаешь о том, что всплывет в процессе использования.
G>А если никто заранее этого сделать не может, то идем итерационным путем — делаем прототип, получаем фидбек, переделываем. Схемы, диаграммы и длинные текстовые описания не помогают.
Я хотел бы посмотреть в глаза человеку, который это может сделать. Узнать что он выдает по итогу — как проверяет гипотезы.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Чем делают программисты 85% времени? Видимо этот самый "сбор, систематизация и анализ требований". S>Нахождение оптимальных решений.
Увы нет
S>К примеру, выбор подходящей библиотеки — кто этим будет заниматься на этапе сбора требований?
Если библиотека распространяется пакетом, то это настолько мелочь, что нет смысла обсуждать.
S>Иногда нужно из исходников собрать библиотеку, протестировать на неких данных — сделать выводы о необходимых доработках — смотреть код.
Тогда она попадет в подсчет строк кода, которые все равно занимают 15% времени.
G>>Потому что многие считают, что для анализа нужна более низкая квалификация, чем для написания кода. Средний ценник системного или бизнес-аналитика ниже ценника программиста. S>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это?
Я тоже могу бесплатно стоимость назвать, как это относится к теме?
S>Т.е. по их мнению этот этап стоит не значительных денег, которыми можно пренебречь.
по факту стоимость этой работы включена в другие этапы
G>>По факту такой анализ требует больше знаний, умений и навыков, чем программирование. S>Нужен человек со сверхспособностями для этого. Предвидеть все заранее, знать тонкости каждого протокола, знать все алгоритмы, которые придется реализовывать, знать тонкости библиотек.
Тонкости как раз знать необязательно, а основные принципы — необходимо, причем из разных областей. Навскидку чтобы разработать просто web api надо как минимум понимать в проектировании БД, HTTP и REST, "паттернах" разработки кода сервера и клиента.
G>>По этому фактически анализом и систематизацией по большей части занимаются сами программисты теми средствами, которыми владеют. S>Не по большей части — а просто нет иного пути. Вы представляете себе, чтобы до написания кода некая команда МЕСЯЦАМИ на хорошем окладе просто анализировала требования и рисовала квадратики? Я не могу такого представить.
Я не просто представляю, я в таком работал. Более того, на стороне заказчика такая же команда анализировала квадратики.
Проекты для госов вообще страшная вещь. Только толку от таких квадратиков незаметно больше нуля.
S>Это все процесс кодирования — написания кода. И этот процесс включает исследования.
Хочешь сказать, что в принципе нет возможности описать продукт до того как будет написан код?
Или ты просто не видел этого ни разу?
S>>>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы? UML-диаграммы и нарисованные в виде квадратиков алгоритмы? G>>Этот вопрос надо задавать не сообществу, а тому кто делает утверждение. S>Интересует мнение и опыт других.
Сильно зависит от того, что говорящий вкладывает в эти слова.
G>>Я, например, считаю что до начала кодирования нужно проектирование интерфейсов. С артефактами в виде интерактивных прототипов UI, для пользовательского UI, или коллекцией запросов в Postman для будущего веб-сервиса. Естественно эти прототипы должны быть не просто художеством в вакууме, а согласованы с программистами, которые их будут делать. Наличие заранее подготовленных таких артефактов, по моему опыту, помогает сократить время на написание кода до 10 раз. S>Даже согласование с программистами не поможет — пока не начнешь делать — не поймешь все ли нюансы учтены в API или нет. Даже не подумаешь о том, что всплывет в процессе использования.
Тем не менее разницу в 10 раз я наблюдал своими глазами
Re: Сбор, систематизация и анализ требований vs кодирование
Там контекст был шире — речь шла про разработку продукта в целом.
Я в целом согласен. Но думаю, что не 15%, а больше. Но если взять вообще полностью создание программного продукта, то да — процентов 10-20% без учета дальнейшей поддержки продукта.
Тут интересно было бы услышать мнение шароварщиков: сколько у них в процентах уходит времени на написание кода.
S>То с чем я сталкивался — никто не проводил детального анализа до написания кода. Система обычно известна в общих чертах, примерно что хотят получить на выходе. Могут нарисовать и попытаться с умным видом описать детали — в при соотнесении с реальностью все рушится как карточный домик.
Не очень хороший вариант. А как руководство давало добро на старт проекта? Сроки изначально как-то оценивали?
S>И только когда идея получает выражение в коде — только тогда появляются четкие вопросы, осознаются реальные проблемы и ищутся пути решения.
Ну что-то очень рискованный бизнес получается. Если только речь не о чем-то действительно новаторском, которого никто еще не реализовывал.
S>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы? UML-диаграммы и нарисованные в виде квадратиков алгоритмы?
Ну а все митинги по разбиению задач, их оценке? А работа ПМа и тимлида по декомпозиции? А работа сейлзов, маркетологов, application field engineers и CEO/CTO/CFO по поиску нужных областей, общению с клиентами, выявлению "болей" клиентов, написанию бизнес-фич?
S>Приведу простой пример. Есть некое API. Можно с умным видом описать его в виде таблиц — перечислить все методы и входящие-исходящие параметры. Но в реальности, когда это API начнут использовать, когда создадут первого клиента — только тогда выявляются реальные требования и ищутся пути решения — какие методы реально нужны, какие данные нужно принять и вернуть. Даже до того как клиент создан — разработчик клиента может посмотреть и сказать — ну вроде все ОК. И только как начал писать код — только тогда всплывает что нужно на самом деле.
Это все программирование. И только в рамках программирования кодирование — далеко не 100%. А помимо программирования (см. выше) есть еще очень много другой работы.
Ну и опять же, приведенный пример показывает не очень эффективно налаженные процессы.
Патриот здравого смысла
Re[4]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, gandjustas, Вы писали:
S>>К примеру, выбор подходящей библиотеки — кто этим будет заниматься на этапе сбора требований? G>Если библиотека распространяется пакетом, то это настолько мелочь, что нет смысла обсуждать.
— нужна библиотека для сортировки больших файлов. Писать самому или использовать готовые? Если готовые — то насколько сильно придется дорабатывать? Кто и когда это будет решать?
S>>Иногда нужно из исходников собрать библиотеку, протестировать на неких данных — сделать выводы о необходимых доработках — смотреть код. G>Тогда она попадет в подсчет строк кода, которые все равно занимают 15% времени.
Можно ли подбор подходящей библиотеки с учетом возможности ее доработки — назвать анализом требований?
Сколько у вас времени займет подбор библиотеки? Предложенный мной вариант с LevelDB — хороший или плохой? Будете писать самостоятельно или лучше такой вариант?
S>>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это? G>Я тоже могу бесплатно стоимость назвать, как это относится к теме?
А как ты назовешь стоимость без сбора, систематизации и анализ требований?
S>>Это все процесс кодирования — написания кода. И этот процесс включает исследования. G>Хочешь сказать, что в принципе нет возможности описать продукт до того как будет написан код? G>Или ты просто не видел этого ни разу?
Это будешь еще дольше, чем выразить в коде.
Re: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы.
S>Согласны с этим или нет? Что по вашему опыту?
Похоже на правду.
S>То с чем я сталкивался — никто не проводил детального анализа до написания кода. Система обычно известна в общих чертах, примерно что хотят получить на выходе. Могут нарисовать и попытаться с умным видом описать детали — в при соотнесении с реальностью все рушится как карточный домик.
S>И только когда идея получает выражение в коде — только тогда появляются четкие вопросы, осознаются реальные проблемы и ищутся пути решения.
S>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы? UML-диаграммы и нарисованные в виде квадратиков алгоритмы?
S>Приведу простой пример. Есть некое API. Можно с умным видом описать его в виде таблиц — перечислить все методы и входящие-исходящие параметры. Но в реальности, когда это API начнут использовать, когда создадут первого клиента — только тогда выявляются реальные требования и ищутся пути решения — какие методы реально нужны, какие данные нужно принять и вернуть. Даже до того как клиент создан — разработчик клиента может посмотреть и сказать — ну вроде все ОК. И только как начал писать код — только тогда всплывает что нужно на самом деле.
Да, так и происходит. Поэтому если даже на кодирование уходит много времени, там будет куча переписываний и доработок.
Re[4]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, maxkar, Вы писали:
M>Прежде чем искать оптимальное решение, нужно определить, что именно является оптимальным решением. Быстродействие? Надежность? Потребление памяти? Скорость кодирования? Да и вообще, нужно определиться, нужно ли "оптимальное решение" в данном месте (ладно, если не нужно — у нас оптимальное решение по критерию "сложность реализации"). Т.е. чтобы начать искать оптимальное решение, нужно собрать требования.
— является ли выбор библиотеки оптимальным решением или лучше своя реализация? Или не своя, а другая библиотека? Кто и когда это будет решать?
Архитектор или технический лидер команды. И это обычно выводится из общей стратегии использования библиотек. Это не всегда формальная стратегия. Но она определяет, в каких случаях применяются внешние библиотеки. Какие критерии применения (их поддержка, предоставляемая функциональность vs требуемая функциональность, наличие других задач, которые можно решить с использованием библиотеки, соображения безопасности, распространенность в индустрии (косвенно влияет на нахождение ошибок) и т.п.).
S>Понятно что цель — чем меньше памяти и чем быстрее — тем лучше. Но тратить много дней тоже не хочется — как бы здравый смысл определяет.
Обычно — нет, не цель. Обычная цель — получить сортировку, которая влезает в существующую память и работает более-менее разумное время. Исходя из задачи, решение будет IO-bound. Теория хорошо известна — external sort, пишется за один-два часа. Всё. Реализуем сами. Потом при необходимости добавляем метрики, профилируем и т.п. Я не вижу смысла тратить много времени на исследование и выбор лучших библиотек. Более того, я вообще не вижу смысла включать внешнюю библиотеку. Вот что вы будете делать, если со временем выяснится, что библиотека не оптимально работает в вашей задаче? Править библиотеку? Так можно и свой код править. И обычно свой код будет исправить проще. А еще библиотека может притащить кучу транзитивных лишних зависимостей, которые конфликтуют с другими библиотеками. Или иметь уязвимости, которые нужно регулярно исправлять/поддерживать.
После того, как это ручное решение реализовано, можно дальше собирать требования. Если все устраивает — ничего не нужно делать. Если не устраивает, поялвюятся новые объективные критерии — "сортировка X Гб файла с таким-то распределением данных не должна занимать более Y минут и потреблять больше Z Мб памяти". Вот тогда уже можно общаться с бизнесом о том, сколько они готовы платить за достижение результата. Бюджетом определяется, сколько можно анализировать. Если бюджет только 1000$, это один день анализа (может даже меньше) и день на реализацию. Если бюджет 10)00$, можно анализировать уже неделю (остаток уйдет на реализацию и, возможно, лицензии и т.п.).
Re[5]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>К примеру, выбор подходящей библиотеки — кто этим будет заниматься на этапе сбора требований? G>>Если библиотека распространяется пакетом, то это настолько мелочь, что нет смысла обсуждать.
S>Какая разница пакетом или нет?
Болшая
S>Пример
— нужна библиотека для сортировки больших файлов.
Это слишком маленький пример. Речь идет о проектах минимум полгода до первого релиза. Выбор как сортировать файлы потеряется на фоне других задач.
S>>>Иногда нужно из исходников собрать библиотеку, протестировать на неких данных — сделать выводы о необходимых доработках — смотреть код. G>>Тогда она попадет в подсчет строк кода, которые все равно занимают 15% времени. S>Можно ли подбор подходящей библиотеки с учетом возможности ее доработки — назвать анализом требований?
Анализом требований можно назвать что угодно, в этом и суть проблемы.
S>Сколько у вас времени займет подбор библиотеки? Предложенный мной вариант с LevelDB — хороший или плохой? Будете писать самостоятельно или лучше такой вариант?
Я думаю в масштабах достаточно крупного проекта (см выше) займет незаметно малую величину.
S>>>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это? G>>Я тоже могу бесплатно стоимость назвать, как это относится к теме? S>А как ты назовешь стоимость без сбора, систематизации и анализ требований?
Возьму и назову, что мне помешает?
S>>>Это все процесс кодирования — написания кода. И этот процесс включает исследования. G>>Хочешь сказать, что в принципе нет возможности описать продукт до того как будет написан код? G>>Или ты просто не видел этого ни разу? S>Это будешь еще дольше, чем выразить в коде.
Что именно будет дольше?
Re[5]: Сбор, систематизация и анализ требований vs кодирован
— нужна библиотека для сортировки больших файлов. Писать самому или использовать готовые? Если готовые — то насколько сильно придется дорабатывать? Кто и когда это будет решать?
В рамках проекта это всего лишь одна из сотен разработческих задач. Команда сможет эту задачу оценить из своего опыта, например, она знает, что поиск, выбор и интеграция с библиотекой на языке X занимает примерно N дней. Вот и все. Как уже сказали — это мелочь в рамках всего проекта.
S>Можно ли подбор подходящей библиотеки с учетом возможности ее доработки — назвать анализом требований?
Зависит от процесса в команде. Вообще, анализ требований — это скорее не про выбор библиотек, а про предметную область. Какие требования регулятора соблюсти, какие нагрузки нужно держать, какие специфичные требования для пользователей, какие форматы данных надо поддерживать и так далее. Выбор библиотеки — это всего лишь выбор инструмента. Примерно как для анализа и подсчета сметы делать выбор — считать в экселе, на бумажке или в Google Sheets.
S>Сколько у вас времени займет подбор библиотеки? Предложенный мной вариант с LevelDB — хороший или плохой? Будете писать самостоятельно или лучше такой вариант?
Также как и выше. Выбор бибилиотки хоть и важный процесс, но даже с написаное Proof of Concept крайне редко занимает больше недели. Я говорю об узкоспециализированных библиотеках на плюсах, например. Выбор утилитарной либы для реакта будет в разы быстрее.
S>>>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это? G>>Я тоже могу бесплатно стоимость назвать, как это относится к теме? S>А как ты назовешь стоимость без сбора, систематизации и анализ требований?
Ну вот именно, что ее точность будет примерно такой же по ценности. Это будет очень примерная оценка.
Патриот здравого смысла
Re[3]: Сбор, систематизация и анализ требований vs кодирован
S>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это?
S>Т.е. по их мнению этот этап стоит не значительных денег, которыми можно пренебречь.
Во-первых, в таких случаях обычно предполагается анализ "крупными мазками". Чтобы приблизительно оценить трудоемкость и цену вопроса. Более детальный анализ делается уже потом.
Во-вторых, это вовсе не означает, что по мнению конторы-разработчика эта работа ничего не стоит. Просто эта работу делают "авансом", рассчитывая на то, что при хорошем раскладе им этот проект закажут, и доходы от него все компенсируют.
Re[6]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, maxkar, Вы писали:
M>Архитектор или технический лидер команды.
Он не пользовался этими библиотеками. Когда это делать — на этапе разработки или на этапе сбора/систематизации требований?
M>Обычно — нет, не цель. Обычная цель — получить сортировку, которая влезает в существующую память и работает более-менее разумное время. Исходя из задачи, решение будет IO-bound. Теория хорошо известна — external sort, пишется за один-два часа. Всё. Реализуем сами.
А откуда вы взяли цифру 1-2 часа? Вот ту же библиотеку LevelDb, которая, по сути, тоже делает лишь сортировку — вы бы за сколько написали?
Re[6]: Сбор, систематизация и анализ требований vs кодирован
— нужна библиотека для сортировки больших файлов. G>Это слишком маленький пример. Речь идет о проектах минимум полгода до первого релиза. Выбор как сортировать файлы потеряется на фоне других задач.
Из маленьких и состоит проект. Не убегайте от ответа.
Вот это как бы вы решали? Искали бы готовую библиотеку или же писали вручную? Понятно что структура данных может усложняться.
S>>>>Иногда нужно из исходников собрать библиотеку, протестировать на неких данных — сделать выводы о необходимых доработках — смотреть код. G>>>Тогда она попадет в подсчет строк кода, которые все равно занимают 15% времени. S>>Можно ли подбор подходящей библиотеки с учетом возможности ее доработки — назвать анализом требований? G>Анализом требований можно назвать что угодно, в этом и суть проблемы.
Все же нет — анализ требований — это четкое понимание что мы хотим получить на выходе. Библиотеки тут ни при делах — это уже внутренняя кухня разработки.
S>>Сколько у вас времени займет подбор библиотеки? Предложенный мной вариант с LevelDB — хороший или плохой? Будете писать самостоятельно или лучше такой вариант? G>Я думаю в масштабах достаточно крупного проекта (см выше) займет незаметно малую величину.
Вы убегаете от ответа таким образом. Хотите размазать истину.
S>>>>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это? G>>>Я тоже могу бесплатно стоимость назвать, как это относится к теме? S>>А как ты назовешь стоимость без сбора, систематизации и анализ требований? G>Возьму и назову, что мне помешает?
А как вы назовете, если не знаете что будете делать? Ведь чтобы знать что от вас требуют — нужно собрать и проанализировать требования.
S>>>>Это все процесс кодирования — написания кода. И этот процесс включает исследования. G>>>Хочешь сказать, что в принципе нет возможности описать продукт до того как будет написан код? G>>>Или ты просто не видел этого ни разу? S>>Это будешь еще дольше, чем выразить в коде. G>Что именно будет дольше?
Представить все алгоритмы в виде квадратиков. Представить все состояния в виде диаграмм...
В коде это проще и быстрее. Те же состояния — можно автоматом сгенерить схему переходов на основе кода машины состояний.
Re[6]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
DP>В рамках проекта это всего лишь одна из сотен разработческих задач. Команда сможет эту задачу оценить из своего опыта, например, она знает, что поиск, выбор и интеграция с библиотекой на языке X занимает примерно N дней. Вот и все. Как уже сказали — это мелочь в рамках всего проекта.
Вы бы писали свою такую библиотеку или использовали готовую? Причем тут старый опыт?
Нужно брать конкретные библиотеки и анализировать. И это займет много времени. Потом брать и пробовать дорабатывать одну из них — и только спустя N дней поймешь подводные камни.
S>>Можно ли подбор подходящей библиотеки с учетом возможности ее доработки — назвать анализом требований?
DP>Зависит от процесса в команде. Вообще, анализ требований — это скорее не про выбор библиотек, а про предметную область. Какие требования регулятора соблюсти, какие нагрузки нужно держать, какие специфичные требования для пользователей, какие форматы данных надо поддерживать и так далее. Выбор библиотеки — это всего лишь выбор инструмента. Примерно как для анализа и подсчета сметы делать выбор — считать в экселе, на бумажке или в Google Sheets.
Выбор библиотеки очень на многое влияет.
S>>Сколько у вас времени займет подбор библиотеки? Предложенный мной вариант с LevelDB — хороший или плохой? Будете писать самостоятельно или лучше такой вариант?
DP>Также как и выше. Выбор бибилиотки хоть и важный процесс, но даже с написаное Proof of Concept крайне редко занимает больше недели. Я говорю об узкоспециализированных библиотеках на плюсах, например. Выбор утилитарной либы для реакта будет в разы быстрее.
Неделя — это уже много. Вот в том то и дело — а когда библиотек несколько десятков экзотических и одну их них проще написать с нуля чем править — вот тогда время и уйдет.
DP>Ну вот именно, что ее точность будет примерно такой же по ценности. Это будет очень примерная оценка.
Вот в том то и дело. Такой анализ требований делается бесплатно за 0.5-1% времени и другого никто не делает — дальше уже как угадали.
Re[4]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, klopodav, Вы писали:
K>Во-первых, в таких случаях обычно предполагается анализ "крупными мазками". Чтобы приблизительно оценить трудоемкость и цену вопроса. Более детальный анализ делается уже потом.
А зачем делать более полный анализ, если цена уже названа?
K>Во-вторых, это вовсе не означает, что по мнению конторы-разработчика эта работа ничего не стоит. Просто эта работу делают "авансом", рассчитывая на то, что при хорошем раскладе им этот проект закажут, и доходы от него все компенсируют.
Стоит 0.5-1% общего времени проекта. Но никак не большую часть времени.
Re[7]: Сбор, систематизация и анализ требований vs кодирован
S>Вы бы писали свою такую библиотеку или использовали готовую? Причем тут старый опыт?
It depends. Опыт — это опыт выбора библиотек.
S>Нужно брать конкретные библиотеки и анализировать. И это займет много времени. Потом брать и пробовать дорабатывать одну из них — и только спустя N дней поймешь подводные камни.
Вы сами себе противоречите. Вот же ниже вы пишите S>Неделя — это уже много. Вот в том то и дело — а когда библиотек несколько десятков экзотических и одну их них проще написать с нуля чем править — вот тогда время и уйдет.
Вы же не берете каждую библиотеку и не встраиваете к себе в продукт, чтобы проверить ее.
S>Выбор библиотеки очень на многое влияет.
Да. Но в рамках разработки продукта (продукта!) это мелочь. Это как если при строительстве завода заморачиваться, какого цвета болты брать — никелированные или какие-то другие. Да пофиг, решит бригадир или архитектор в соответствии с нагрузками или требованиями по влажности и т.п.
S>Неделя — это уже много. Вот в том то и дело — а когда библиотек несколько десятков экзотических и одну их них проще написать с нуля чем править — вот тогда время и уйдет.
Еще раз: если вам надо выбрать какую-то особо важную библиотеку, на которой будет весь функционал, то их будет немного. Вы на это потратите чуть больше времени. А если вам нужно выбрать сотню мелких либ для JS, то конечно вы не будете так тщательно каждую изучать.
S>Вот в том то и дело. Такой анализ требований делается бесплатно за 0.5-1% времени и другого никто не делает — дальше уже как угадали.
"никто не делает" — весьма спорное утверждение, когда вам тут как минимум 3 человека в теме сказали, что бывает иначе
Все зависит от проекта. Сделать дабу можно и без оценки. Написать утилиту для парсинга веб-страницы — чуть посложнее. Сделать веб-сайт на 10 страниц — еще сложнее. Написать систему для доставки суши с мобильными приложениями — еще сложнее. Чем выше сложность, тем больше необходимость предварительной оценки. Есть такое негласное примерное правило: оцени в днях, и ошибешься на день, оцени в неделях, ошибешься на неделю, оцени в месяцах — ошибешься на месяц. А некоторые оценки даются вообще в годах.
Когда делают бесплатную оценку срока, то либо это каткая-то конвейерная работа (сделать типовой сайт), либо вас кхм-кхм, обманут и вы потеряете x3 вложений и срок по факту будет в 2-3 раза дольше. Ну либо это что-то совсем простое (написать парсер для простенького сайта, где оценка будет 3 дня). Все, что более-менее сложное — надо садиться и предварительно обсчитывать. Не детально, без выбора библиотек, а просто примерно с точностью в +- пару недель (для небольших проектов), +- пару месяцев (не очень большие — средние), ну и так далее. Бесплатно такого никто делать не будет. Потому что это будет 2-3 человека-дня. И это будет грубая оценка. Если уже заказчик договаривается о работе, то тогда уже начинается плотная коммуникация с ним и обсуждение/утверждение требований. И это все затягивается не то что на недели, порой на месяцы. Программисты тут даже еще не приступают к работе.
Патриот здравого смысла
Re[5]: Сбор, систематизация и анализ требований vs кодирован
K>>Во-первых, в таких случаях обычно предполагается анализ "крупными мазками". Чтобы приблизительно оценить трудоемкость и цену вопроса. Более детальный анализ делается уже потом.
S>А зачем делать более полный анализ, если цена уже названа?
Чтобы понимать, что и как разрабатывать и какой код писать программисту. При том, что по трудоемкости этот код будет плюс-минус укладываться в полученную ранее оценку, но нюансы реализации могут уже сильно варьироваться.
K>>Во-вторых, это вовсе не означает, что по мнению конторы-разработчика эта работа ничего не стоит. Просто эта работу делают "авансом", рассчитывая на то, что при хорошем раскладе им этот проект закажут, и доходы от него все компенсируют.
S>Стоит 0.5-1% общего времени проекта. Но никак не большую часть времени.
Так никто и не предполагает, что это будет большая часть.
На большую часть придется последующий более детальный анализ требований, проектирование, всякие там согласования и утрясания, отладка, тестирование, документирование и т.п. А непосредственно кодирование займет меньшую часть.
Re[8]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
S>>Вы бы писали свою такую библиотеку или использовали готовую? Причем тут старый опыт? DP>It depends. Опыт — это опыт выбора библиотек.
Оно по разному бывает. Бывает что просто ввел название пакета и подключил. А бывает что нужно дорабатывать настолько, что легче самому переписать. И чтобы это понять — нужно попробовать библиотеку применить.
DP>Вы сами себе противоречите. Вот же ниже вы пишите S>>Неделя — это уже много. Вот в том то и дело — а когда библиотек несколько десятков экзотических и одну их них проще написать с нуля чем править — вот тогда время и уйдет.
В смысле неделя — это вообще много. И влияет на стоимость и сроки. А так да — неделю можно допиливать библиотеку и даже больше недели.
DP>Вы же не берете каждую библиотеку и не встраиваете к себе в продукт, чтобы проверить ее.
Создать тестовую среду нужно, чтобы повторяла реальное использование.
DP>Да. Но в рамках разработки продукта (продукта!) это мелочь. Это как если при строительстве завода заморачиваться, какого цвета болты брать — никелированные или какие-то другие. Да пофиг, решит бригадир или архитектор в соответствии с нагрузками или требованиями по влажности и т.п.
Нет, не мелочь. Написать библиотеку с нуля — может быть сопоставимо с разработкой самого проекта.
DP>Все зависит от проекта. Сделать дабу можно и без оценки. Написать утилиту для парсинга веб-страницы — чуть посложнее. Сделать веб-сайт на 10 страниц — еще сложнее.
Да причем тут 10 страниц? Сколько будет стоить написать сайт с 1 страницей, 1 полем и 1 кнопкой? Отож.
Re[6]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, klopodav, Вы писали:
K>Чтобы понимать, что и как разрабатывать и какой код писать программисту. При том, что по трудоемкости этот код будет плюс-минус укладываться в полученную ранее оценку, но нюансы реализации могут уже сильно варьироваться.
Как же дали первоначальную оценку, не понимая до конца что нужно сделать?
Вот дали вам задание — 1 простая Web-страница с 1 полем и 1 кнопкой, после нажатия кнопки выводит список.
Какие требования вам нужно собрать? Много ли их будет?
И потом сколько вы будете это делать?
K>Так никто и не предполагает, что это будет большая часть.
В стартовом сообщении ссылка.
K>На большую часть придется последующий более детальный анализ требований, проектирование, всякие там согласования и утрясания, отладка, тестирование, документирование и т.п. А непосредственно кодирование займет меньшую часть.
Не думаю что более детальный анализ отнимет много времени. Время занимает именно разработка — не только написание кода, но и нахождение подходящих библиотек, алгоритмов, решений.
Re[8]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, gandjustas, Вы писали:
G>В том и проблема что не состоит. В крупном проекте (от полугода программирования) задачи типа "сортировка большого файла" занимают настолько мизерную часть кода, что обсуждать проблемы связанные с этой задачей не имеет смысла.
Ну ок. А сколько вы будете делать аналог библиотеки LevelDB? Она просто сортирует большой файл и находит бинарным поиском нужный ключ.
S>>Вот это как бы вы решали? Искали бы готовую библиотеку или же писали вручную? Понятно что структура данных может усложняться. G>Я бы готовый вариант взял через полчаса гугления.
Почему именно пол часа?
А если бы не нашлось ничего — то сколько писать вручную?
S>>Все же нет — анализ требований — это четкое понимание что мы хотим получить на выходе. G>И чего мы хотим получить на выходе "анализа требований" ?
Требования — это описание того что мы хотим получить в результате работ. Можно словами, можно добавить таблицы, диаграммы, схемы и пр.
G>>>Я думаю в масштабах достаточно крупного проекта (см выше) займет незаметно малую величину. S>>Вы убегаете от ответа таким образом. Хотите размазать истину. G>Это вы хотите свою идею подогнать под условия, я не хочу этим заниматься.
Допускаете ли вы, что займет значительно дольше чем кажется?
G>Я сам назову и цену, и состав работ. Зачем мне что-то для этого анализировать?
Потому что без анализа требований — ты не будешь знать что именно нужно сделать.
Вот я тебе говорю — нужна 1 страница с 1 полем и 1 кнопкой. По нажатию на кнопку просто вывести список их текстов, где встречается введенные 2-3 слова.
Много еще требований нужно?
Что тут займет основное время?
G>Разработка ПО это не НИОКР уже давно. Даже не инженерия вида "построить мост". Это скорее ремесло как "сшить костюм". С одной стороны у заказчика есть требования, с другой стороны уже миллионы костюмов были сшиты за всю историю, да и вы сами скорее всего уже не один костюм сшили. Весьма вероятно что мастер даже гораздо лучше заказчика знает какой костюм надо сшить. Что ему помешает назвать цену? По короткому, даже устному, брифу будет понятно какой костюм нужен. Также и в ПО.
Глупости. Костюм — это натянуть дизайн на готовый движок и максимум подправить пару мелочей.
Я же говорю о проектах, которые пишут с нуля.
S>>Представить все алгоритмы в виде квадратиков. Представить все состояния в виде диаграмм... G>Зачем это делать?
Ну это можно назвать анализом и систематизацией требований. Тогда да — займет и больше времени чем кодирование. Но не видел чтобы так делали.
G>Можно ли "проще и быстрее" сделать UI в коде и не заниматься рисованием прототипов\интерфейсов?
UI это больше к дизайнерам.
Re[9]: Сбор, систематизация и анализ требований vs кодирован
S>Оно по разному бывает. Бывает что просто ввел название пакета и подключил. А бывает что нужно дорабатывать настолько, что легче самому переписать. И чтобы это понять — нужно попробовать библиотеку применить.
S>В смысле неделя — это вообще много. И влияет на стоимость и сроки. А так да — неделю можно допиливать библиотеку и даже больше недели.
S>Создать тестовую среду нужно, чтобы повторяла реальное использование.
S>Нет, не мелочь. Написать библиотеку с нуля — может быть сопоставимо с разработкой самого проекта.
Приведите уже конкретный пример, пожалуйста. Чтобы предметнее говорить: что за задача/продукт и о каких библиотеках идет речь. Необязательно именно ваши (если NDA), можно сопоставимые по размеру и сложности.
S>Да причем тут 10 страниц? Сколько будет стоить написать сайт с 1 страницей, 1 полем и 1 кнопкой? Отож.
Ну вот вам навскидку — 2 недели на все про все. Это очень грубая первая оценка. Дальше вы можете уже предметнее со мной говорить (это я сейчас для примера), показав макет вашей страницы или список требований, если это умещается на 1 страницу. Можно будет сделать оценку и бесплатно, т.к. тогда это мелкий проект. А если описание/ТХ больше чем на страницу, тогда уже тут скорее всего речь будет идти о реализации дольше чем 2 недели + оплата проработки ТЗ/оценке сроков.
Патриот здравого смысла
Re[7]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, maxkar, Вы писали:
M>>Архитектор или технический лидер команды. S>Он не пользовался этими библиотеками. Когда это делать — на этапе разработки или на этапе сбора/систематизации требований?
Если библиотека критична для реализации функциональности — на этапе сбора требований. Так и говорим заказчику: "спасибо за информацию. Нам нужно ее обдумать, давайте через три дня встретимся еще раз, у нас могут появиться новые вопросы". В эти три дня детально исследуем вопросы. А если не критична, то все просто. Мы эту библиотеку на данном проекте использовать вряд ли будем. Потому что есть альтернативы — либо ручное решение, либо какая-то известная библиотека, которой команды в компании умеют пользоваться. Все выше — часть проверки проекта на выполнимость (feasibility). Это, конечно, зависит от компании и отношений с заказчиком. Лично я считаю, что лучше честно предупредить, что проект имеет большой шанс на провал (и заниматься высокоприоритетными рисками), чем долго и мучительно доить заказчика. К моменту, когда начинается более-менее серьезная разработка и инвестиции вопрос о наборе библиотек и основных технических решениях уже не стоит.
S>А откуда вы взяли цифру 1-2 часа?
Из практики. Что может быть сложного в задаче: прочитать файл кусками, отсортировать куски стандартной библиотекой, записать файл, потом произвести слияние нескольких файлов (здесь можно использовать priority queue)? Ну у у команды это займет может один день (прочитать про merge sort, написать, протестировать). А если команда не может, это отдельная проблема, которая решается своими способами.
S> Вот ту же библиотеку LevelDb, которая, по сути, тоже делает лишь сортировку — вы бы за сколько написали?
Она не делает "лишь ту же сортировку":
LevelDB is an open-source on-disk key-value store ...
It supports batching writes, forward and backward iteration, and compression of the data ...
Wiki.
Это не сортировка. Так что не надо подменять требования на ходу (здесь будет долгий разговор с заказчиком о том, что "может быть через 10 мы будем делать ххх но пока не уверены" — это тоже очень важная информация для принятия решений на текущем этапе). В таких требованиях — за неделю не напрягаясь. Может она будет не очень быстрая, но это уже другой вопрос. Здесь мы опять переходим к выяснению требований. Хотя... Не, давайте напишу за день. "Хранилище" — это каталог. Ключ записи — имя файла. Данные могут сжиматься при записи (gzip). Итерация — через чтение списка каталогов. Если файлов много (и их список в память не влезает), используем внешнюю сортировку оглавления каталога. Вроде удовлетворяет всем требованиям
Re: Сбор, систематизация и анализ требований vs кодирование
. S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы. S>Согласны с этим или нет? Что по вашему опыту?
Это во всех книжках пишут, вроде Роберт Гласс в какой-то из своих писал, то ли в книге "программист-прагматик". Это общее место, что кодирования не
самая главная и долгая часть, тестирование и отладка дольше. Сбор, систематизация и анализ требований -- кмк, это самый важный этап. Чем тщательнее этот
этап проработан, тем легче будет далее.
Кодом людям нужно помогать!
Re[9]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>В том и проблема что не состоит. В крупном проекте (от полугода программирования) задачи типа "сортировка большого файла" занимают настолько мизерную часть кода, что обсуждать проблемы связанные с этой задачей не имеет смысла. S>Ну ок. А сколько вы будете делать аналог библиотеки LevelDB? Она просто сортирует большой файл и находит бинарным поиском нужный ключ.
Я наверно откажусь от такой задачи, я же не гугл.
S>>>Вот это как бы вы решали? Искали бы готовую библиотеку или же писали вручную? Понятно что структура данных может усложняться. G>>Я бы готовый вариант взял через полчаса гугления. S>Почему именно пол часа?
Я думаю за полчаса можно найти любой вменяемый код, если он есть.
S>А если бы не нашлось ничего — то сколько писать вручную?
Я думаю для сортировки файла есть готовый код.
S>>>Все же нет — анализ требований — это четкое понимание что мы хотим получить на выходе. G>>И чего мы хотим получить на выходе "анализа требований" ? S>Требования — это описание того что мы хотим получить в результате работ. Можно словами, можно добавить таблицы, диаграммы, схемы и пр.
Ну и? Что это будет? В каком объеме? В какой структуре? Ведь начиная какую-то работу нужно понимать когда она сделана, я пока не вижу границ того, что вы описали.
G>>>>Я думаю в масштабах достаточно крупного проекта (см выше) займет незаметно малую величину. S>>>Вы убегаете от ответа таким образом. Хотите размазать истину. G>>Это вы хотите свою идею подогнать под условия, я не хочу этим заниматься. S>Допускаете ли вы, что займет значительно дольше чем кажется?
Что именно? Сортировка файла — вряд ли. Проект который изначально планировался на год одного разработчика может по трудозатратам в итоге составить от 50% до 1000%
G>>Я сам назову и цену, и состав работ. Зачем мне что-то для этого анализировать? S>Потому что без анализа требований — ты не будешь знать что именно нужно сделать.
С чего это?
S>Вот я тебе говорю — нужна 1 страница с 1 полем и 1 кнопкой. По нажатию на кнопку просто вывести список их текстов, где встречается введенные 2-3 слова.
Это финальная задача для программиста, или предложение поговорить?
Если если финальная задача, то кто-то уже сделал 85% работы (или думает что сделал).
Если предложение поговорить, то я бы предложил воспользоваться готовыми системами поиска, их десятки как минимум.
S>Много еще требований нужно?
Нет.
S>Что тут займет основное время?
Выбор подходящей системы, которая решает задачу.
G>>Разработка ПО это не НИОКР уже давно. Даже не инженерия вида "построить мост". Это скорее ремесло как "сшить костюм". С одной стороны у заказчика есть требования, с другой стороны уже миллионы костюмов были сшиты за всю историю, да и вы сами скорее всего уже не один костюм сшили. Весьма вероятно что мастер даже гораздо лучше заказчика знает какой костюм надо сшить. Что ему помешает назвать цену? По короткому, даже устному, брифу будет понятно какой костюм нужен. Также и в ПО.
S>Глупости. Костюм — это натянуть дизайн на готовый движок и максимум подправить пару мелочей.
Твоя задача про поиск полностью подходит под это определение
S>Я же говорю о проектах, которые пишут с нуля.
С нуля написать поиск могут позволить себе гугл или на худой конец яндекс, хотя в последнем я не уверен. Все остальные пользуются готовыми системами\библиотеками.
S>>>Представить все алгоритмы в виде квадратиков. Представить все состояния в виде диаграмм... G>>Зачем это делать? S>Ну это можно назвать анализом и систематизацией требований. Тогда да — займет и больше времени чем кодирование. Но не видел чтобы так делали.
Я же говорю, что назвать анализом требований можно что угодно. Это максимально абстрактное понятие, без формализации которого в каждом конкретном случае говорить не о чем.
G>>Можно ли "проще и быстрее" сделать UI в коде и не заниматься рисованием прототипов\интерфейсов? S>UI это больше к дизайнерам.
То есть в коде не "проще и быстрее" ?
Re[7]: Сбор, систематизация и анализ требований vs кодирован
K>>Чтобы понимать, что и как разрабатывать и какой код писать программисту. При том, что по трудоемкости этот код будет плюс-минус укладываться в полученную ранее оценку, но нюансы реализации могут уже сильно варьироваться.
S>Как же дали первоначальную оценку, не понимая до конца что нужно сделать?
Первоначальную оценку дали понимая не до конца, а в общих чертах. Этого достаточно.
S>Вот дали вам задание — 1 простая Web-страница с 1 полем и 1 кнопкой, после нажатия кнопки выводит список.
S>Какие требования вам нужно собрать? Много ли их будет?
Ну как минимум надо узнать насколько навороченная нужна форма, откуда берутся данные для списка, много ли этих данных, часто ли они меняются, есть ли особые требования по быстродействию, совместимости, безопасности и т.п.; предполагаются ли какие-то сопутствующие работы вроде внедрения, обучения персонала или авторского сопровождения; ну и как быстро заказчику эта форма нужна — это то, о чем надо договариваться на берегу.
А более детальные требования, такие как дизайн формы, параметры источника данных, форматы представления данных и т.п. — можно уже решить позже в рабочем порядке
S>И потом сколько вы будете это делать?
Порядок величины зависит от основных требований.
А от более детальных требований зависят уже мелкие флуктуации.
K>>На большую часть придется последующий более детальный анализ требований, проектирование, всякие там согласования и утрясания, отладка, тестирование, документирование и т.п. А непосредственно кодирование займет меньшую часть.
S>Не думаю что более детальный анализ отнимет много времени. Время занимает именно разработка — не только написание кода, но и нахождение подходящих библиотек, алгоритмов, решений.
Детальный анализ может занять очень дохрена времени. Особенно если этот анализ завязан на взаимодействие с другими людьми. Этот анализ может выглядеть как-то так: состыкуйся вот с теми чуваками, обсуди с ними в каком формате они будут предоставлять данные, дождись пока они родят описание и примеры своих данных в этом формате, и уже потом подумай как адаптировать свой софт под этот формат.
Re[10]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
DP>Приведите уже конкретный пример, пожалуйста. Чтобы предметнее говорить: что за задача/продукт и о каких библиотеках идет речь. Необязательно именно ваши (если NDA), можно сопоставимые по размеру и сложности.
Примеры появляются только когда начинаешь реализацию. В теории все просто. По этому назвать что-то абстрактное без раскрытия деталей реального проекта не просто.
Вот из проекта. Нужно записи в базе привязать скрипт на одном из популярных ЯП с возможностью передавать в него данные строковые и возможностью в скрипте основных операций со строками и числами а так же делать определенные запросы к разрешенным сайтам. Нужно гарантировать что скрипт не выполнит вредоносных действий.
Может уже есть что-то готовое. Может есть почти готовое. А может придется писать с нуля, тогда масштаб работ меняется.
И вопрос тут не в детализации требования а в поиске решения. Сначала поиск готовой библиотеки, потом поиск наиболее близкой, потом поиск алгоритмов готовых и уже самое сложное — изобретение новых алгоритмов.
Время уходит на это, а не на требования.
DP>Ну вот вам навскидку — 2 недели на все про все. Это очень грубая первая оценка. Дальше вы можете уже предметнее со мной говорить (это я сейчас для примера), показав макет вашей страницы или список требований, если это умещается на 1 страницу. Можно будет сделать оценку и бесплатно, т.к. тогда это мелкий проект. А если описание/ТХ больше чем на страницу, тогда уже тут скорее всего речь будет идти о реализации дольше чем 2 недели + оплата проработки ТЗ/оценке сроков.
Ну вот вы взялись за 2 недели делать Гугл без рекламы.
Требование простое и записать можно кратко — сделай интернет поисковик аналогичный Гуглу, но без рекламы.
Re[11]: Сбор, систематизация и анализ требований vs кодирован
S>Вот из проекта. Нужно записи в базе привязать скрипт на одном из популярных ЯП с возможностью передавать в него данные строковые и возможностью в скрипте основных операций со строками и числами а так же делать определенные запросы к разрешенным сайтам. Нужно гарантировать что скрипт не выполнит вредоносных действий.
Это всего-навсего юзер стори, одна мелкая деталь проекта, а проект — часть продукта. Эта юзер стори рисерчится, если надо, потом оценивается командой и впоследствии делается. И, честно говоря, я не понял суть задачи. Либо вы опечатались в нескольких местах, либо неправильно расставили падежи, но там чисто из текстового описания непонятно, что требуется.
S>Может уже есть что-то готовое. Может есть почти готовое. А может придется писать с нуля, тогда масштаб работ меняется.
Энивей, этот масштаб — работа команды над фичей, 2-4 недели. Помимо этого еще какие-то фичи будут делаться.
S>И вопрос тут не в детализации требования а в поиске решения. Сначала поиск готовой библиотеки, потом поиск наиболее близкой, потом поиск алгоритмов готовых и уже самое сложное — изобретение новых алгоритмов.
Имхо, вы как-то сильно усложняете. Могу ошибаться, но то, что вы пишите, больше похоже на программирование ради программирования, а не ради разработки продукта.
S>Время уходит на это, а не на требования.
Вы все верно говорите применительно к кодированию. Но речь в изначальном топике шла о продукте. Продукт включает в себя очень много всего. Непосредственно разработка в нем, условно, 30-50%. В эти проценты входит, помимо самого кодирования: тестирование, дизайн архитектуры, выбор решений, багфиксинг, написание тестов, какая-то работа по релиз-менеджменту, и прочее. Потому в рамках всего выпуска продукта само кодирование — маленькая его часть.
S>Ну вот вы взялись за 2 недели делать Гугл без рекламы.
Нет, не взялся. Вот же написано: DP>>А если описание/ТХ больше чем на страницу, тогда уже тут скорее всего речь будет идти о реализации дольше чем 2 недели + оплата проработки ТЗ/оценке сроков.
Если бы вы сразу сказали, что это поисковик, то разговор был бы другой.
Патриот здравого смысла
Re[8]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, maxkar, Вы писали:
S>> Вот ту же библиотеку LevelDb, которая, по сути, тоже делает лишь сортировку — вы бы за сколько написали? M>Она не делает "лишь ту же сортировку": M>
M>LevelDB is an open-source on-disk key-value store ...
M>It supports batching writes, forward and backward iteration, and compression of the data ...
Так а что, из-за компрессии данных — уже не сможете за пол дня сделать? Сложно добавить 1 строчку кода gZip?
Поймите что я таких как вы уже не первого наблюдаю — причем некоторые с 15 летним опытом. Думают что все легко и просто, пока не коснется практики.
M>Wiki. M>Это не сортировка. Так что не надо подменять требования на ходу (здесь будет долгий разговор с заказчиком о том, что "может быть через 10 мы будем делать ххх но пока не уверены" — это тоже очень важная информация для принятия решений на текущем этапе). В таких требованиях — за неделю не напрягаясь. Может она будет не очень быстрая, но это уже другой вопрос. Здесь мы опять переходим к выяснению требований. Хотя... Не, давайте напишу за день. "Хранилище" — это каталог. Ключ записи — имя файла. Данные могут сжиматься при записи (gzip). Итерация — через чтение списка каталогов. Если файлов много (и их список в память не влезает), используем внешнюю сортировку оглавления каталога. Вроде удовлетворяет всем требованиям
Т.е. вы предлагаете не писать а использовать готовый инструмент — сортировку B-tree, которую использует ОС для файловой системы? Есть ли у вас осознание что именно вы предложили? Операционная система — это тоже всего лишь программа. И вызывать ее функции — это тоже вызов своего рода библиотеки.
Однако же вам нужно исследовать эту библиотеку, чтобы понять корректно ли она работает, к примеру, с большим количеством файлов в одной папке.
В идеале вообще ничего писать не нужно — просто найти готовую систему. Второй случай — собрать систему из готовых библиотек. Третий случай — доработать готовые библитеки. Четвертый — писать самому.
Re[2]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, AleksandrN, Вы писали:
AN>Чем крупнее проект и чем выше цена ошибки, тем больше времени тратится на сбор требований и системную аналитику.
А как же время на тестирование — если цена ошибки высока? Почему именно сбор требований?
Re[2]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Sharov, Вы писали:
S>Это во всех книжках пишут, вроде Роберт Гласс в какой-то из своих писал, то ли в книге "программист-прагматик". Это общее место, что кодирования не S>самая главная и долгая часть, тестирование и отладка дольше. Сбор, систематизация и анализ требований -- кмк, это самый важный этап. Чем тщательнее этот S>этап проработан, тем легче будет далее.
Тестирование еще можно согласится — что для важных систем будет балласт в виде автоматических тестов по размеру в 2-3 раза выше размера основного кода.
Re[10]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, gandjustas, Вы писали:
S>>>>Вот это как бы вы решали? Искали бы готовую библиотеку или же писали вручную? Понятно что структура данных может усложняться. G>>>Я бы готовый вариант взял через полчаса гугления. S>>Почему именно пол часа? G>Я думаю за полчаса можно найти любой вменяемый код, если он есть.
Ну вот нашли вы 15 библиотек опенсорсных. Даже просто по 1 минуте посмотреть каждую из них — это 15 минут. А нужно не просто посмотреть.
S>>А если бы не нашлось ничего — то сколько писать вручную? G>Я думаю для сортировки файла есть готовый код.
А для чего нет готового кода?
S>>Требования — это описание того что мы хотим получить в результате работ. Можно словами, можно добавить таблицы, диаграммы, схемы и пр. G>Ну и? Что это будет? В каком объеме? В какой структуре? Ведь начиная какую-то работу нужно понимать когда она сделана, я пока не вижу границ того, что вы описали.
Суть вот в чем — требования не описывают как достичь — описывают что нужно. А вот как сделать то что нужно — это уже большая работа и выполнить ее без кодирования может только гений (или тот, кто уже делал аналог проекта и помнит как).
Вот требование — сделать поисковик по интернету аналог гугл и бинг. Все! Это достаточно четкое требование. Только дурак может прикинуться что ничего не понял.
А вот уже раскрыть тех. детали — каким образом мы сможем сделать такой поисковик — это не сбор и анализ требований.
G>>>Я сам назову и цену, и состав работ. Зачем мне что-то для этого анализировать? S>>Потому что без анализа требований — ты не будешь знать что именно нужно сделать. G>С чего это?
А с того — требования описывают что хотим получить. Если ты не знаешь что от тебя требуют — то цену чего будешь называть? Просто с потолка?
S>>Вот я тебе говорю — нужна 1 страница с 1 полем и 1 кнопкой. По нажатию на кнопку просто вывести список их текстов, где встречается введенные 2-3 слова. G>Это финальная задача для программиста, или предложение поговорить?
G>Если если финальная задача, то кто-то уже сделал 85% работы (или думает что сделал). G>Если предложение поговорить, то я бы предложил воспользоваться готовыми системами поиска, их десятки как минимум.
Вы лучше назовите хотя бы одну систему, которых уже не написали десятки.
Re[11]: Сбор, систематизация и анализ требований vs кодирован
S>Вот требование — сделать поисковик по интернету аналог гугл и бинг. Все! Это достаточно четкое требование. Только дурак может прикинуться что ничего не понял.
Это не требование. Уж во всяком случае не требование в том смысле, каким оно подразумевается в этой теме. Это бизнес-идея.
S>А вот уже раскрыть тех. детали — каким образом мы сможем сделать такой поисковик — это не сбор и анализ требований.
Это как раз уточнение требований, включая, но не ограничиваясь, требованиями по нагрузке (должно держать 100К рпс), по SLA (99.99999%), по затратам в месяц (не более $30000 на железо), должно поддерживать HTTPS, поддерживать 3 языка (английский, русский, французский) и т.д.
А как мы это будем делать — уже технические детали. Что не отменяет предварительной оценки от разработчиков.
Вы б лучше привели более конкретный пример. Сделать поисковик — такой себе пример для обсуждения. Тут ясно, что это на годы работы. Обсуждать на этом примере сложно.
Патриот здравого смысла
Re[12]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
DP>Это всего-навсего юзер стори, одна мелкая деталь проекта, а проект — часть продукта. Эта юзер стори рисерчится, если надо, потом оценивается командой и впоследствии делается.
Вот то то и оно — именно исследования занимают все время. И это не сбор и не анализ требований. Требования понятны — не ясно как это сделать на практике.
DP>И, честно говоря, я не понял суть задачи. Либо вы опечатались в нескольких местах, либо неправильно расставили падежи, но там чисто из текстового описания непонятно, что требуется.
Скриптовый язык, который поддерживает основные операции со строками (поиск, конкатенация и т.д.), числами и возможность GET-запросов, но больше ничего не дозволяющий.
S>>Может уже есть что-то готовое. Может есть почти готовое. А может придется писать с нуля, тогда масштаб работ меняется. DP>Энивей, этот масштаб — работа команды над фичей, 2-4 недели. Помимо этого еще какие-то фичи будут делаться.
2-4 недели — это уже существенное время в рамках даже 1-2 лет.
DP>Нет, не взялся. Вот же написано: DP>>>А если описание/ТХ больше чем на страницу, тогда уже тут скорее всего речь будет идти о реализации дольше чем 2 недели + оплата проработки ТЗ/оценке сроков.
DP>Если бы вы сразу сказали, что это поисковик, то разговор был бы другой.
Почему другой?
Re[12]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
DP>Это как раз уточнение требований, включая, но не ограничиваясь, требованиями по нагрузке (должно держать 100К рпс), по SLA (99.99999%), по затратам в месяц (не более $30000 на железо), должно поддерживать HTTPS, поддерживать 3 языка (английский, русский, французский) и т.д.
Сказав что аналог гугл и бинг — уже получили достаточное описание, из которого только дурак не поймет нужна ли поддержка HTTPS. Требования достаточно точно выражаются этой короткой фразой.
DP>А как мы это будем делать — уже технические детали. Что не отменяет предварительной оценки от разработчиков.
DP>Вы б лучше привели более конкретный пример. Сделать поисковик — такой себе пример для обсуждения. Тут ясно, что это на годы работы. Обсуждать на этом примере сложно.
Почему ясно что на годы? А если готовую библиотеку взять?
Re[13]: Сбор, систематизация и анализ требований vs кодирован
S>Вот то то и оно — именно исследования занимают все время. И это не сбор и не анализ требований. Требования понятны — не ясно как это сделать на практике.
Вот смотрите: даже сейчас нам понадобилось несколько сообщений туда-сюда, чтобы уточнить требования. И они все еще ясно не прописаны.
Вот это S>Вот из проекта. Нужно записи в базе привязать скрипт на одном из популярных ЯП с возможностью передавать в него данные строковые и возможностью в скрипте основных операций со строками и числами а так же делать определенные запросы к разрешенным сайтам. Нужно гарантировать что скрипт не выполнит вредоносных действий.
И это S>Скриптовый язык, который поддерживает основные операции со строками (поиск, конкатенация и т.д.), числами и возможность GET-запросов, но больше ничего не дозволяющий.
Ну сильно отличающиеся вещи. Теперь стало более понятно что делать, но все-равно не до конца. Я бы, например, уточнил, какой список операций нужен? Что скрывается за и т.д.? Числа с плавающей точкой надо предусмотреть? Какие будут максимальные числа? Отрицательные могут быть? Только GET запросы? Что значит не дозволяющий? Должен выдавать ошибку? Какую? Что по скорости работы? Какие планы по дальнейшему расширению? Нудна ли интеграция? Куда это будет встраиваться/интегрироваться? Какие ОСи поддерживать? Это должна быть CLI или прямо интерпретатор языка со своей грамматикой?
Это я все для примера. Не надо на них отвечать, пожалуйста.
И таких итераций много. И это мы с вами достаточно быстро все решили. А представьте, что встречи с заказчиком проходят 1 раз в неделю.
S>2-4 недели — это уже существенное время в рамках даже 1-2 лет.
Я ж написал, что будут и другие фичи. 2-4 недели половины или трети команды на отрезке в 2 года — не так уж и много.
DP>>Нет, не взялся. Вот же написано: DP>>>>А если описание/ТХ больше чем на страницу, тогда уже тут скорее всего речь будет идти о реализации дольше чем 2 недели + оплата проработки ТЗ/оценке сроков.
DP>>Если бы вы сразу сказали, что это поисковик, то разговор был бы другой.
S>Почему другой?
Потому что вот что я написал:
А если описание/ТХ больше чем на страницу, тогда уже тут скорее всего речь будет идти о реализации дольше чем 2 недели + оплата проработки ТЗ/оценке сроков.
А вот что изначально написали вы:
Да причем тут 10 страниц? Сколько будет стоить написать сайт с 1 страницей, 1 полем и 1 кнопкой? Отож.
Вот как раз чтобы выудить из заказчика все нюансы и требования, и надо достаточно много времени. И это будет сделано не вами еще до того, как техническая задача на разработку дойдет до вас как разработчика/архитектора/тимлида.
Патриот здравого смысла
Re[13]: Сбор, систематизация и анализ требований vs кодирован
S>Сказав что аналог гугл и бинг — уже получили достаточное описание, из которого только дурак не поймет нужна ли поддержка HTTPS. Требования достаточно точно выражаются этой короткой фразой.
Имхо, вот тут основная особенность, почему возникла эта тема и почему вы не понимаете и не слышите, что вам говорят тут нескольких человек. Дальше можно не продолжать.
Патриот здравого смысла
Re[13]: Сбор, систематизация и анализ требований vs кодирован
S>>>Вот требование — сделать поисковик по интернету аналог гугл и бинг. Все! Это достаточно четкое требование. S>>Это не требование. Это хотелка.
S>Достаточно для того, чтобы сказать сделана работа или нет.
Это смешно. Это даже не студенческий уровень, тк даже там в лабораторных работах будет более четкое условие. А в реальном же мире с такими "требованиями" и "приемками" никто не работает.
Патриот здравого смысла
Re[11]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>>>Вот это как бы вы решали? Искали бы готовую библиотеку или же писали вручную? Понятно что структура данных может усложняться. G>>>>Я бы готовый вариант взял через полчаса гугления. S>>>Почему именно пол часа? G>>Я думаю за полчаса можно найти любой вменяемый код, если он есть. S>Ну вот нашли вы 15 библиотек опенсорсных. Даже просто по 1 минуте посмотреть каждую из них — это 15 минут. А нужно не просто посмотреть.
А что еще нужно?
S>>>А если бы не нашлось ничего — то сколько писать вручную? G>>Я думаю для сортировки файла есть готовый код. S>А для чего нет готового кода?
Для любого сценария использования например.
S>>>Требования — это описание того что мы хотим получить в результате работ. Можно словами, можно добавить таблицы, диаграммы, схемы и пр. G>>Ну и? Что это будет? В каком объеме? В какой структуре? Ведь начиная какую-то работу нужно понимать когда она сделана, я пока не вижу границ того, что вы описали. S>Суть вот в чем — требования не описывают как достичь — описывают что нужно. А вот как сделать то что нужно — это уже большая работа и выполнить ее без кодирования может только гений (или тот, кто уже делал аналог проекта и помнит как).
Открою тайну: подавляющее большинство того что называют "требованиями" как раз не описывают что нужно. Именно поэтому 85% времени уходит не на создание продуктивного кода. Именно поэтому нужна очень высокая квалификация чтобы помочь программистам не тратить свои 85% времени.
S>Вот требование — сделать поисковик по интернету аналог гугл и бинг. Все! Это достаточно четкое требование. Только дурак может прикинуться что ничего не понял.
Взяться за такой проект может гугл, майкрософт или больной на голову и очень богатый человек. Это не значит что у него не получится, это значит что у тебя и всех тут присутствующих не получится.
S>А вот уже раскрыть тех. детали — каким образом мы сможем сделать такой поисковик — это не сбор и анализ требований.
Алгоритмическая часть поисковика уже многократно реализована. Причем как сам инвертированный индекс, так и алгоритмы релевантности типа page rank, нейросетей и прочих индексов цитирования.
Если вдруг ты достаточно богатый и больной на голову и захочешь сделать свой поисковик, то 85% времени ты потратишь не на алгоритмы TF-IDF или page rank, а на то, чтобы:
— сделать обходчик, который с одной стороны не слишком агрессивный и не будет отрезаться как ДДОС, а с другой стороны сможет контент держать в достаточной свежести
— сделать хранилище, которое сможет сохранить индекс всего интернета и будет достаточно отказоустойчивым
— защититься от возможных атак на твой индекс (покупных ссылок, фейковых страниц с ключевыми словами итд)
— научить движок запросов определять тему и синонимы, чтобы он понимал чем отличаются C# C Sharp и Си-бемоль
Причем каждое из этих требований займет 85% времени на анализ и лишь 15% на реализацию.
Пойми наконец, что в любой достаточно крупной программе алгоритмы — не самая большая часть.
G>>>>Я сам назову и цену, и состав работ. Зачем мне что-то для этого анализировать? S>>>Потому что без анализа требований — ты не будешь знать что именно нужно сделать. G>>С чего это? S>А с того — требования описывают что хотим получить. Если ты не знаешь что от тебя требуют — то цену чего будешь называть? Просто с потолка?
А с чего ты взял что я не знаю? Я сделал программ гораздо больше чем любой заказчик. Если он просто озвучит свою проблему, то я смогу придумать её решение лучше чем он сам.
Ты мыслишь как программист, который может накодить по ТЗ, поэтому тебе сложно понять процессы разработки программ за пределами кодинга.
S>>>Вот я тебе говорю — нужна 1 страница с 1 полем и 1 кнопкой. По нажатию на кнопку просто вывести список их текстов, где встречается введенные 2-3 слова. G>>Это финальная задача для программиста, или предложение поговорить?
G>>Если если финальная задача, то кто-то уже сделал 85% работы (или думает что сделал). G>>Если предложение поговорить, то я бы предложил воспользоваться готовыми системами поиска, их десятки как минимум.
S>Вы лучше назовите хотя бы одну систему, которых уже не написали десятки.
Я вот много лет занимался SharePoint, там есть поисковый движок и той самой одной страницей и с одной кнопкой. Аналоги есть у оракла, IBM, гугла и я думаю даже у яндекса.
Есть и подешевле вариант — elasticsearch.
А если вдруг твой поиск это часть большого приложения со своим хранилищем, разграничениями доступа итд, то можно воспользоваться Lucene(.NET).
Еще раз повторю: писать свой поиск может 5-10 компаний в мире или очень богатые и не совсем здоровые люди.
Re[14]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
S>>Вот то то и оно — именно исследования занимают все время. И это не сбор и не анализ требований. Требования понятны — не ясно как это сделать на практике.
DP>Вот смотрите: даже сейчас нам понадобилось несколько сообщений туда-сюда, чтобы уточнить требования. И они все еще ясно не прописаны.
Вы понимаете разницу между сбором требований и нахождением путей решения? Что, по вашему мнению, занимает больше времени?
DP>Вот это S>>Вот из проекта. Нужно записи в базе привязать скрипт на одном из популярных ЯП с возможностью передавать в него данные строковые и возможностью в скрипте основных операций со строками и числами а так же делать определенные запросы к разрешенным сайтам. Нужно гарантировать что скрипт не выполнит вредоносных действий.
DP>И это S>>Скриптовый язык, который поддерживает основные операции со строками (поиск, конкатенация и т.д.), числами и возможность GET-запросов, но больше ничего не дозволяющий.
DP>Ну сильно отличающиеся вещи. Теперь стало более понятно что делать, но все-равно не до конца.
Это не сложно детализировать, причем делается все быстро.
А вот потом как решить — как воплотить в жизнь — это уже время.
DP>Я бы, например, уточнил, какой список операций нужен? Что скрывается за и т.д.?
Вот этот список операций со строками: https://metanit.com/java/tutorial/7.2.php
DP>Числа с плавающей точкой надо предусмотреть? Какие будут максимальные числа? Отрицательные могут быть?
Целые 64 битные со знаком. Основные 4 арифметические операции. Так же преобразование в/из строки.
DP>Только GET запросы? Что значит не дозволяющий? Должен выдавать ошибку? Какую?
Любую ошибку, не важно какую. Допустим Interpretation Error.
DP>Что по скорости работы? Какие планы по дальнейшему расширению? Нудна ли интеграция? Куда это будет встраиваться/интегрироваться? Какие ОСи поддерживать? Это должна быть CLI или прямо интерпретатор языка со своей грамматикой?
Скорость не критична. Развитие не требуется. Вызывать нужно из .Net Core на Ubuntu.
Все! Мы все требования собрали. 2 минуты ушло. А теперь подумайте сколько времени уйдет на реализацию!!!
DP>Это я все для примера. Не надо на них отвечать, пожалуйста.
Нет уж, я ответил и вы поймете что это много времени не займет. Время займет это сделать — ответил я бесплатно и спросили вы бесплатно. А теперь попробуйте сделать ЛЮБОЕ решение, которое удовлетворяет озвученным требоаниям!!! Фигли!!!
DP>И таких итераций много. И это мы с вами достаточно быстро все решили. А представьте, что встречи с заказчиком проходят 1 раз в неделю.
Это не занимает много времени. То что раз в неделю — это сугубо проблемы вашей организации.
DP>Вот как раз чтобы выудить из заказчика все нюансы и требования, и надо достаточно много времени. И это будет сделано не вами еще до того, как техническая задача на разработку дойдет до вас как разработчика/архитектора/тимлида.
Нет, не много и это делать легко. Вы только что у меня все узнали бесплатно. И я ответил бесплатно.
Станете ли вы бесплатно это выражать в коде? Фигли. Это работа надолго, а собрать требования — 3 минуты.
Re[14]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
DP>Имхо, вот тут основная особенность, почему возникла эта тема и почему вы не понимаете и не слышите, что вам говорят тут нескольких человек. Дальше можно не продолжать.
абсолютно бесплатно. И я вам ответил, много времени не ушло.
А теперь подумайте сколько нужно времени, чтобы эти требования реализовать!!! Понимаете что реализовать намного сложнее и дольше — что это действительно работа, которую никто делать бесплатно не будет.
Re[14]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
DP>Это смешно. Это даже не студенческий уровень, тк даже там в лабораторных работах будет более четкое условие. А в реальном же мире с такими "требованиями" и "приемками" никто не работает.
Здравствуйте, gandjustas, Вы писали:
S>>Ну вот нашли вы 15 библиотек опенсорсных. Даже просто по 1 минуте посмотреть каждую из них — это 15 минут. А нужно не просто посмотреть. G>А что еще нужно?
Вникнуть в принципы работы, прочесть документацию, прочесть отзывы, собрать из исходников, создать тестовую среду и оценить какая лучше. Легко уходит неделя-две.
G>Открою тайну: подавляющее большинство того что называют "требованиями" как раз не описывают что нужно. Именно поэтому 85% времени уходит не на создание продуктивного кода. Именно поэтому нужна очень высокая квалификация чтобы помочь программистам не тратить свои 85% времени.
Даже если собрать точные требования — на реализацию все равно уйдет намного больше сил и времени. Да, не каждый может собрать. Часто и заказчик сам не знает что лучше — часть осознанно делают эксперименты и выкидывают решения, если не понравились на практике.
G>Причем каждое из этих требований займет 85% времени на анализ и лишь 15% на реализацию.
А что вы вкладываете в понятие "анализ требования"?
Re[15]: Сбор, систематизация и анализ требований vs кодирован
S>Вот этот список операций со строками: https://metanit.com/java/tutorial/7.2.php
Даже для юзер-стори нужно прописывать конкретный список.
S>Любую ошибку, не важно какую. Допустим Interpretation Error.
Вот тут нужно еще уточнять, даже в рамках юзер-стори.
S>Все! Мы все требования собрали. 2 минуты ушло. А теперь подумайте сколько времени уйдет на реализацию!!!
Мы собрали требования для одной юзер-стори, как я уже говорил. Такое делает команда технических инженеров и ПМа в рамках регулярных встреч (ака груминг/планирование/you name it). В рамках продукта это какая-то одна из сотен фич.
DP>>И таких итераций много. И это мы с вами достаточно быстро все решили. А представьте, что встречи с заказчиком проходят 1 раз в неделю.
S>Это не занимает много времени. То что раз в неделю — это сугубо проблемы вашей организации.
Причем тут моя организация?
Патриот здравого смысла
Re[15]: Сбор, систематизация и анализ требований vs кодирован
абсолютно бесплатно. И я вам ответил, много времени не ушло.
S>А теперь подумайте сколько нужно времени, чтобы эти требования реализовать!!! Понимаете что реализовать намного сложнее и дольше — что это действительно работа, которую никто делать бесплатно не будет.
Коллега, возможно, вам не хватает признания от коллег/руководства вас как разработчика. Так вот, могу с уверенностью сказать: работа программиста, и ваша, в частности, очень важна для любой компании! Она непростая и занимает много времени. И немногие могут с ней справиться.
Патриот здравого смысла
Re[16]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
DP>Мы собрали требования для одной юзер-стори, как я уже говорил. Такое делает команда технических инженеров и ПМа в рамках регулярных встреч (ака груминг/планирование/you name it). В рамках продукта это какая-то одна из сотен фич.
Собрали требования мы бесплатно. Это мизер времени. Ну даже минут 15 если займет от силы — и то вряд ли.
А теперь подумайте сколько займет реализация. Отож — может легко занять и день, если найдете подходящее готовое решение, может занять и неделю — если решения не найдете.
В любом случае анализ требований — это процентов 5 работы. Обычно даже меньше.
Никто не спорит что это важно и может сэкономить время, если грамотно составлены требования и заказчик сам точно знает что нужно. Часто сам точно не знает и уже в процессе рождаются лучшие решения. Однако же не отменяет того факта, что сбор выполнить быстро и легко, а вот воплотить слова в жизнь — сложно и долго.
Re[16]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
S>>А теперь подумайте сколько нужно времени, чтобы эти требования реализовать!!! Понимаете что реализовать намного сложнее и дольше — что это действительно работа, которую никто делать бесплатно не будет.
DP>Коллега, возможно, вам не хватает признания от коллег/руководства вас как разработчика. Так вот, могу с уверенностью сказать: работа программиста, и ваша, в частности, очень важна для любой компании! Она непростая и занимает много времени. И немногие могут с ней справиться.
DP>
Это просто суровая реальность. Высказать требования к любому проекту — да, важно и это экономит много средств. Однако же реализация — это основная часть времени и сил.
Даже житейский пример. Ремонт квартиры. Можете заказать детальный анализ ремонта на основе опыта бывалых, небезызвестный Земсков давно толкает такую услугу. Ну да, купите проект — так сказать анализ ваших требований. Возможно это и поможет сэкономить, однако же реальная работа — это сам ремонт, а не красивый анализ на бумаге. Более того — в процессе могут прийти решения лучшие, более подходящие.
Re[17]: Сбор, систематизация и анализ требований vs кодирован
S>Собрали требования мы бесплатно. Это мизер времени. Ну даже минут 15 если займет от силы — и то вряд ли.
S>А теперь подумайте сколько займет реализация. Отож — может легко занять и день, если найдете подходящее готовое решение, может занять и неделю — если решения не найдете.
S>В любом случае анализ требований — это процентов 5 работы. Обычно даже меньше.
S>Никто не спорит что это важно и может сэкономить время, если грамотно составлены требования и заказчик сам точно знает что нужно. Часто сам точно не знает и уже в процессе рождаются лучшие решения. Однако же не отменяет того факта, что сбор выполнить быстро и легко, а вот воплотить слова в жизнь — сложно и долго.
Это вы все про разработку. В нашем примере — разработку одной фичи из сотен.
А теперь еще раз обращаю ваше внимание, третий раз: изначально речь шла про разработку продукта, а не про кодинг. Разработка продукта состоит из разработки + другое. Разработка состоит из кодинга + другое.
Патриот здравого смысла
Re[16]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, Shmj, Вы писали: M>Не верите? Архитектура и реализация следующая. Я пишу систему, которая через http принимает запросы с выражениями для вычисления (плюс basic authorization) и сохраняет их в базу. Я раз в день читают очередные запросы и очень тщательно лично выполняю (интерпретирую) их на бумажке. Могу curl'ом делать GET-запросы. Потом записываю результат выполнения скрипта в базу, где его может опросить скрипт. Все крутится в AWS (Postgresql RDS + Beanstalk + ELB). Помощь коллег будет нужна на написание клиента, который будет вызывать мой сервис и периодически опрашивать результаты. Собственно, всё. Эта архитектура удовлетворяет всем требованиям. Какие требования — такое и решение. Ничего особо сложного.
Свести к абсурду приёмами демагогии можно все что угодно. Есть здравый смысл и людям не нужно уточнять миллионы деталей, потому что пределы здравого смысла и так ясны.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Ну вот нашли вы 15 библиотек опенсорсных. Даже просто по 1 минуте посмотреть каждую из них — это 15 минут. А нужно не просто посмотреть. G>>А что еще нужно? S>Вникнуть в принципы работы, прочесть документацию, прочесть отзывы, собрать из исходников, создать тестовую среду и оценить какая лучше. Легко уходит неделя-две.
Если требуется столько времени значит не подходит.
Ты же сам ссылался на задачу с сортировкой файла, там решение на leveldb требует 10 строк кода и один package-install для решения этой задачи.
Если у тебя "готовое" решение требует примерно столько же времени, сколько написание с нуля, то оно не готовое и точно не подходит.
G>>Открою тайну: подавляющее большинство того что называют "требованиями" как раз не описывают что нужно. Именно поэтому 85% времени уходит не на создание продуктивного кода. Именно поэтому нужна очень высокая квалификация чтобы помочь программистам не тратить свои 85% времени. S>Даже если собрать точные требования — на реализацию все равно уйдет намного больше сил и времени.
Что ты понимаешь под "точными требованиями"? Мне кажется то, что ты понимаешь как раз не является точными, поэтому "на реализацию все равно уйдет намного больше сил и времени".
S>Да, не каждый может собрать. Часто и заказчик сам не знает что лучше — часть осознанно делают эксперименты и выкидывают решения, если не понравились на практике.
Это тоже способ сбора и анализа требований, это и занимает 85% времени. Причем времени программистов, которое очень дорогое.
G>>Причем каждое из этих требований займет 85% времени на анализ и лишь 15% на реализацию. S>А что вы вкладываете в понятие "анализ требования"?
Это зависит от контекста.
— Прототипы интерфейса, по возможности интерактивные, и\или описание api вплоть до примеров вызовов в postman.
— Функциональные спецификации как Спольски завещал.
— Опционально технические спецификации, те самые таблицы и диаграммы, но в терминах программы, а не пользователя.
Re[14]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, gandjustas, Вы писали:
G>- Опционально технические спецификации, те самые таблицы и диаграммы, но в терминах программы, а не пользователя.
Это самое сложное и зачастую легче просто написать программу, чем сначала написать спецификации в терминах программы. Это и есть методы нахождения решений.
Более того — даже по готовой программе написать спецификацию — это очень трудоемкий процесс. Это как бы два раза выразить одно и тоже — сначала на ЯП, потом на языке диаграмм.
Re[14]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, gandjustas, Вы писали:
G>Если требуется столько времени значит не подходит. G>Ты же сам ссылался на задачу с сортировкой файла, там решение на leveldb требует 10 строк кода и один package-install для решения этой задачи. G>Если у тебя "готовое" решение требует примерно столько же времени, сколько написание с нуля, то оно не готовое и точно не подходит.
LevelDB писать с нуля — не неделя-две — а требует квалифицированного программиста и стоит это около несколько десятков тысяч долларов.
То решение что я быстро набросал — на самом деле задачу не решает — там неправильная сортировка и не учитываются дубликаты. Нужно думать как сделать, может даже проще написать мердже-сорт с нуля. Может быстрее будет а может и нет — не знаю. Думаю что и вы не знаете без исследования.
Re[2]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Dym On, Вы писали:
DO>Кроме того, хорошо прописанные требования это почти готовая программа, ее осталось перевести с естественного языка на формальный язык программирования.
Почти готовая программа — это не требования а описание методов реализации требований. К примеру, будет ли в вашей "почти готовой программе" описано какую библиотеку применить для того или иного решения?
Re[16]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
S>>LevelDB писать с нуля — не неделя-две — а требует квалифицированного программиста и стоит это около несколько десятков тысяч долларов. DP>Написание ни одной СУБД не стоит таких маленьких денег. Если это не лабораторная/курсовая/дипломная работа. Думаю, вы ошиблись на 1-2 порядка, если говорить о коммерческом продукте.
Это почему вы так думаете? Что считать СУБД? Сколько строк кода в LevelDB?
Re[18]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
S>>Это почему вы так думаете? Что считать СУБД? Сколько строк кода в LevelDB?
DP>http://rsdn.org/forum/job/8345884.1:
Здравствуйте, Shmj, Вы писали:
S>К примеру, будет ли в вашей "почти готовой программе" описано какую библиотеку применить для того или иного решения?
Это зависит от условий договора, лицензирования и т.п. У меня был случай, когда в договоре был прописан запрет на использование СУБД, любой, и был зафиксирован перечень exe-файлов и dll с именами. IT спецы заказчика потом сами ставили софт на чистую ОС и мониторами смотрели куда она тыкается. Что любопытно на открытых исходниках они не настаивали. Очень причудливо все бывает.
Счастье — это Glück!
Re: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы. S>Согласны с этим или нет? Что по вашему опыту?
Да
S>То с чем я сталкивался — никто не проводил детального анализа до написания кода. Система обычно известна в общих чертах, примерно что хотят получить на выходе. Могут нарисовать и попытаться с умным видом описать детали — в при соотнесении с реальностью все рушится как карточный домик. S>И только когда идея получает выражение в коде — только тогда появляются четкие вопросы, осознаются реальные проблемы и ищутся пути решения.
Если у исполнителя нет опыта в решении задач которые ставит заказчик, так и будет.
Просто не надо нанимать такого исполнителя, который не знает как решать твою задачу и какие там есть подводные камни.
Для того чтобы понимать реальные проблемы и подбирать работающие решения до написания кода, существуют специально обученные люди.
Re[15]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>- Опционально технические спецификации, те самые таблицы и диаграммы, но в терминах программы, а не пользователя. S>Это самое сложное и зачастую легче просто написать программу, чем сначала написать спецификации в терминах программы. Это и есть методы нахождения решений.
Поэтому и опционально. Зачастую действительно программу написать проще.
Re[4]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, AleksandrN, Вы писали:
AN>Роль тестирования для таких проектов тоже возрастает. Но тема про сбор требований, про него и написал AN>А тест-кейсы создаются на основе требований.
И что? Время и ресурсозатраты на тесты — не входят в учет времени на сбор и анализ требований.
Re[5]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
AN>>Роль тестирования для таких проектов тоже возрастает. Но тема про сбор требований, про него и написал AN>>А тест-кейсы создаются на основе требований.
S>И что? Время и ресурсозатраты на тесты — не входят в учет времени на сбор и анализ требований.
Речь же была не про требования только, а про весь проект
Написание кода — как правило, малая его часть
Если в проекте распределение ролей, понятно что разработчик будет в основном писать код,
другую работу будут делать другие люди.
Re[6]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
bnk>>Речь же была не про требования только, а про весь проект bnk>>Написание кода — как правило, малая его часть
S>Написание кода совмещено с поиском решений. А поиск решений — это основная часть. Уже две недели ищем решение коллективно для простой задачи
Здравствуйте, bnk, Вы писали:
bnk>Речь скорее всего про разные вещи. bnk>Задача "сортировка файла" проектом не является, это же просто задача.
Проект состоит из таких вот задач. И на поиск решения для некоторых из них — троится немало времени.
Да, можно согласится что время тратиться на написание документации, тесты, создание авто-тестов. Но никак не на сбор и анализ требований — это вообще 1% от проекта.
Re[7]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
S>Как можно этого не видеть и не понимать?
Рискну предположить, что вам никогда не приходилось самостоятельно вести проект начиная от самого первого общения с заказчиком и до внедрения. Или, если вы работаете в продуктовой разработке, никогда не приходилось вести разработку продукта от идеи до состояния продаваемой "коробки".
"Вести" в смысле управлять и отвечать за результат.
Или приходилось?
Re[15]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
DP>>Вот смотрите: даже сейчас нам понадобилось несколько сообщений туда-сюда, чтобы уточнить требования. И они все еще ясно не прописаны. S>Вы понимаете разницу между сбором требований и нахождением путей решения? Что, по вашему мнению, занимает больше времени?
Чем подробнее соберете требования, тем меньше будете искать решение или кодировать. Думаю можно утверждать, что время кодирования обратно пропорцианально
времени сбора требований. Чем меньше одно, тем больше другое.
Кодом людям нужно помогать!
Re[17]: Сбор, систематизация и анализ требований vs кодирован
S>Никто не спорит что это важно и может сэкономить время, если грамотно составлены требования и заказчик сам точно знает что нужно. Часто сам точно не знает и уже в процессе рождаются лучшие решения. Однако же не отменяет того факта, что сбор выполнить быстро и легко, а вот воплотить слова в жизнь — сложно и долго.
А может попробовать наоборот -- сбор выполнить сложно и долго, а зато потом воплотить слова в жизнь -- быстро и легко. Почему нет?
Кодом людям нужно помогать!
Re[18]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Sharov, Вы писали:
S>Чем подробнее соберете требования, тем меньше будете искать решение или кодировать. Думаю можно утверждать, что время кодирования обратно пропорцианально S>времени сбора требований. Чем меньше одно, тем больше другое.
Нет — требования и так понятны — обычно проблема как реализовать. Вот привел конкретную задачу — уже 2 недели никто не может толкового решения найти.
Re[16]: Сбор, систематизация и анализ требований vs кодирован
S>Чем подробнее соберете требования, тем меньше будете искать решение или кодировать. Думаю можно утверждать, что время кодирования обратно пропорцианально S>времени сбора требований. Чем меньше одно, тем больше другое.
Бывает и такое, что в ходе обсуждения задачи с ПМами выясняется, что эту юзер-стори вообще делать не нужно, или нужно, но у нее настолько низкий приоритет, что она забудется где-то там внизу бэклога. А бывает, наоборот, делаешь большую задачу в соответствии со всеми мельчайшими деталями спеки, а потом этим никто не пользуется. Лично сталкивался с обоими ситуациями.
Патриот здравого смысла
Re[17]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Чем подробнее соберете требования, тем меньше будете искать решение или кодировать. Думаю можно утверждать, что время кодирования обратно пропорцианально S>>времени сбора требований. Чем меньше одно, тем больше другое.
S>Нет — требования и так понятны — обычно проблема как реализовать. Вот привел конкретную задачу — уже 2 недели никто не может толкового решения найти.
А кто-то искал две недели? Ты денег предложи — сразу найдут.
Re[3]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали: S>А как же время на тестирование — если цена ошибки высока? Почему именно сбор требований?
А если цена ошибки высока — то тогда требования еще важнее. Тестировние в обычном понимании, когда программист или его коллега пишет юнит тесты на основе кода и дизайна, не является самым важным, но может присутствовать как часть разработки. Тест кейсы должны быть написаны не из кода а исходя из требований на систему, и тестирование должно доказать что все требования были выполнены верно и даже бывает доказать что весь код при этом выполнялся, т.е. что там нет ничего ненужного, типа заделов на будущее или левой копипасты из интернета. Да и сам код кстати тоже должен быть разработан исходя из подробных требований а не как какой-то программист типа подумал что будет хорошо.
Re[18]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, qqqqq, Вы писали:
Q>А если цена ошибки высока — то тогда требования еще важнее. Тестировние в обычном понимании, когда программист или его коллега пишет юнит тесты на основе кода и дизайна, не является самым важным, но может присутствовать как часть разработки. Тест кейсы должны быть написаны не из кода а исходя из требований на систему, и тестирование должно доказать что все требования были выполнены верно и даже бывает доказать что весь код при этом выполнялся, т.е. что там нет ничего ненужного, типа заделов на будущее или левой копипасты из интернета. Да и сам код кстати тоже должен быть разработан исходя из подробных требований а не как какой-то программист типа подумал что будет хорошо.
Во-первых, цена ошибки высока только в космических сервисах разве что, да и там можно предусмотреть откат.
Во-вторых, то что цена высока — это значит, что долго делать. Да, важно описать сервис. Но это не долго и не сложно — я готов бесплатно для простых сервисов. А вот найти как реализовать — это долго и сложно, бесплатно уже 2 недели никто не хочет для простого задания.
И еще. В большинстве случаев хорошие идеи приходят в момент воплощения — девелопер предлагает — а вот может давайте так сделаем — и все соглашаются что это лучше, т.к. на этапе составления требований об этом и подумать не могли.
Re[5]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
S>Во-первых, цена ошибки высока только в космических сервисах разве что, да и там можно предусмотреть откат.
Не только в космосе. Например: в финтехе ошибка может привести к большим убыткам, а системах управления электростанциями, промышленным оборудованием или в бортовом ПО самолёта — ещё и человеческим жертвам.
S>Во-вторых, то что цена высока — это значит, что долго делать. Да, важно описать сервис. Но это не долго и не сложно — я готов бесплатно для простых сервисов.
Дай определение простого сервиса.
S>А вот найти как реализовать — это долго и сложно, бесплатно уже 2 недели никто не хочет для простого задания.
Разработка программного продукта — процесс сложный на всех этапах жизненного цикла.
S>И еще. В большинстве случаев хорошие идеи приходят в момент воплощения — девелопер предлагает — а вот может давайте так сделаем — и все соглашаются что это лучше, т.к. на этапе составления требований об этом и подумать не могли.
Уточнение требований в процессе разработки — обычное дело. И, если сбором и анализом требований занимаются отдельные люди, то хорошо бы, обсуждать требования с программистами и тестировщиками не только, когда требования уже готовы, но и в процессе разработки требований.
Re[18]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, gandjustas, Вы писали:
S>>Нет — требования и так понятны — обычно проблема как реализовать. Вот привел конкретную задачу — уже 2 недели никто не может толкового решения найти. G>А кто-то искал две недели? Ты денег предложи — сразу найдут.
Сколько нужно?
Re[19]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>А кто-то искал две недели? Ты денег предложи — сразу найдут.
S>А требования бесплатно и без денег напишут.
Дай мне контакт людей, которые бесплатно напишут
Re[19]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Нет — требования и так понятны — обычно проблема как реализовать. Вот привел конкретную задачу — уже 2 недели никто не может толкового решения найти. G>>А кто-то искал две недели? Ты денег предложи — сразу найдут.
S>Сколько нужно?
Я бы за десятку взялся.
Re[17]: Сбор, систематизация и анализ требований vs кодирован
S>Нет — требования и так понятны — обычно проблема как реализовать. Вот привел конкретную задачу — уже 2 недели никто не может толкового решения найти.
Так вы ж сами привели решение. Плюс еще кто-то даже ссылку на решение в своем гитхабе выложил. Что еще надо?
Задача лично для меня интересная. Но мотивации нет ее делать. И тут дело даже не в деньгах. Если уж совсем нечем будет в плане программинга заняться, то можно будет. Я даже порывался пару раз начать...
Патриот здравого смысла
Re[18]: Сбор, систематизация и анализ требований vs кодирован
S>>А вот найти как реализовать — это долго и сложно, бесплатно уже 2 недели никто не хочет для простого задания. AN>Разработка программного продукта — процесс сложный на всех этапах жизненного цикла.
Здесь обсуждается вопрос — какое затраты на сбор и анализ требований в сравнении с другими этапами.
Re[20]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здесь обсуждается вопрос — какое затраты на сбор и анализ требований в сравнении с другими этапами.
Для сферической задачи в вакууме, затраты тоже сферические. Затраты на этап аналитики, по сравнению с другими этапами разные для разных проектов и могут сильно отличатся в зависимости от многих факторов:
Насколько типовой проект.
Насколько хорошо заказчик понимает, что должно получится и насколько детальное описание бизнес-требований у него есть.
Сколько заинтересованных лиц есть со стороны заказчика, если нужно учесть пожелания нескольких отделов, время на сбор и анализ требований может сильно увеличиваться.
Нужна ли интеграция со сторонними системами, если нужна — потребуется обсудить, как это делать и заранее подумать, как такую интеграцию тестировать.
Как нужно действовать в случае сбоя на компе, на котором ПО работает. Если можно день подождать, пока комп починять, можно вообще не задумываться над вопросом, а для системы, которая должна работать 24/7 требуется заранее подумать над отказоустойчивостью.
Есть ли к тому софту, ТЗ для которого пишется, какие-то требования со стороны регулирующих органов.
.
