[gosha-z 3]

14 hours ago, DeadCadDance said:

Родили ТЗ. Объёмом где-то 150 страниц.

ПМИ там была?

[a123-flex 0]

15 часов назад, andrey_p сказал:

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

 

Заказчик хочет сделать "чтобы было зашибись". Свои пожелания он излагает в кратком документе (1-2 страницы) "своими словами". Этот документ называется WP (White Paper) и/или VoC (Voice of the Customer).

 

Действия исполнителя (сначала потенциального исполнителя):

1. На основе WP / VoC создаётся HLSA (High Level Solution Approach). Обычно HLSA делается в виде презентации для демонстрации заказчику с целью согласования единого видения функционала. Причём техническая часть презентации создаётся группой системных инженеров / архитекторов (эта группа тесно связана с "продаванами"). В некоторых случаях проводится НИОКР.
2. По результатам обсуждения HLSA с заказчиком вырабатывается общее понимание. HLSA может итеративно дорабатываться исполнителем в ходе обсуждения.
3. На основании HLSA создаётся TRD (Technical Requirements Document). Это те самые высокоуровневые требования, под которыми подписывается заказчик и по которым делается оценка. На основании TRD заказчик будет проводить приемо-сдаточные испытания.
4. На основании TRD исполнитель создаёт SRD (System Requirements Document), включающий внутренние требования, невидимые заказчику. Это часть очень важна, так как требования в TRD являются слишком высокоуровневыми для создания системы. Количество требований в SRD может в десятки раз превышать количество требований в TRD. Делается TM (Tracability Matrix) из TRD в SRD.
5. На основании SRD делается SAD (System Architecture Document), описывающий декомпозицию и интерфейсы между компонентами. Делается TM из SRD в SAD.
6. На основе SAD для каждого компонента делаются BR (Box Requirements) и TM из SAD/SRD в BR. BR используется тестировщиками для создания документов по тестированию, а затем и самих тестов. Создаются TM до самых тестов.
7. На основе SAD для каждого компонента делаются HLD/LLD (High Level Design / Low Level Design) со сквозными ТМ. Создаются сами компоненты.
8. Низкоуровневые части компонентов тестируется разработчиками на основании HLD/LLD (Unit Testing)
9. Каждый компонент проверяется соответствующей группой тестирования на соответствие конкретному BR.
10. Вся система тестируется на соответствие SRD. Этот этап разделяется на два: системная интеграция / системное тестирование SI/ST (System Integration / System Testing)
11. Система передаётся заказчику для приемо-сдаточных испытаний (по TRD)

Писал по памяти, но, вроде, ничего не упустил:)

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

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

Мне удалось поработать на всех этапах, кроме последнего (11) и мне очень хорошо знаком этот процесс изнутри.

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

Мне кажется, что разработать описываемую Вами систему без подобного процесса невозможно в принципе.

Я вот из этой темы получил один интересный пост. Спасибо.

Не зря говорится видимо, что жемчужину где угодно можно найти) 

 

Что интересно, на моей первой работе, в НИИ Духова, я видел разработку ТЗ на систему в исполнении своего начальника. 

Насколько я понимаю, он в одиночку выпустил SAD и BR спецификации проекта. Он сидел год или 2, сделал талмуд листов на 500.

 

Но вот такое вот: TM (Tracability Matrix) из TRD в SRD - этого совершенно точно не было. И большой вопрос, было ли само SRD. Правда и система та была относительно простой - жестких требований по реальному времени не было.

 

В АСУТП станций уже был другой уровень, и там уже TRD точно было, а проработкой SRD занимались целые коллективы.

Временные спецификации системы обсасывались несколько лет.

[a123-flex 0]

15 часов назад, Eddy_Em сказал:

Когда пишешь в ТЗ, что итоговый продукт должен быть построен так, чтобы была возможна его поддержка и развитие исключительно собственными силами работников предприятия, многие подобные "инсаты" моментально сливаются! Ведь это придется давать расширенную документацию, полную расшифровку протоколов обмена данными, а зачастую — еще и исходные коды (что до меня, так я бы еще и требовал все исходные коды исключительно под лицензией GPLv3)!

Я здесь рискую встать на позицию своего противника, но буду помягче)

 

Способ передачи исходника существенно зависит от способа оплаты проекта) Если вы по какойто причине взялись сделать чтото за 1/10 цены, вы же должны потом каким-то образом получить свои 19/10 ??

 

Бизнес может работать в убыток, но очень недолго((

 

[jcxz 242]

16 часов назад, Eddy_Em сказал:

а зачастую — еще и исходные коды (что до меня, так я бы еще и требовал все исходные коды исключительно под лицензией GPLv3)!

А зачем? Думаете вы в них разберётесь? 

[a123-flex 0]

Только что, jcxz сказал:

А зачем? Думаете вы в них разберётесь? 

НИИ Духова примерно на такой мотивации получило от немцев часть исходников их АСУТП Teleperm. За исключением ключевых узлов системы.

Мало того, что исходники подняли, ключевые узлы воспроизвели, так еще и модернизацию успешно выполнили)

И, немцев немножечко подтерли.

[syoma 1]

16 hours ago, andrey_p said:

• На основе WP / VoC создаётся HLSA (High Level Solution Approach). Обычно HLSA делается в виде презентации для демонстрации заказчику с целью согласования единого видения функционала. Причём техническая часть презентации создаётся группой системных инженеров / архитекторов (эта группа тесно связана с "продаванами"). В некоторых случаях проводится НИОКР.
• По результатам обсуждения HLSA с заказчиком вырабатывается общее понимание. HLSA может итеративно дорабатываться исполнителем в ходе обсуждения.
• На основании HLSA создаётся TRD (Technical Requirements Document). Это те самые высокоуровневые требования, под которыми подписывается заказчик и по которым делается оценка. На основании TRD заказчик будет проводить приемо-сдаточные испытания.
• На основании TRD исполнитель создаёт SRD (System Requirements Document), включающий внутренние требования, невидимые заказчику. Это часть очень важна, так как требования в TRD являются слишком высокоуровневыми для создания системы. Количество требований в SRD может в десятки раз превышать количество требований в TRD. Делается TM (Tracability Matrix) из TRD в SRD.
• На основании SRD делается SAD (System Architecture Document), описывающий декомпозицию и интерфейсы между компонентами. Делается TM из SRD в SAD.
• На основе SAD для каждого компонента делаются BR (Box Requirements) и TM из SAD/SRD в BR. BR используется тестировщиками для создания документов по тестированию, а затем и самих тестов. Создаются TM до самых тестов.
• На основе SAD для каждого компонента делаются HLD/LLD (High Level Design / Low Level Design) со сквозными ТМ. Создаются сами компоненты.
• Низкоуровневые части компонентов тестируется разработчиками на основании HLD/LLD (Unit Testing)
• Каждый компонент проверяется соответствующей группой тестирования на соответствие конкретному BR.
• Вся система тестируется на соответствие SRD. Этот этап разделяется на два: системная интеграция / системное тестирование SI/ST (System Integration / System Testing)
• Система передаётся заказчику для приемо-сдаточных испытаний (по TRD)

Да, так оно и есть. Это V-модель. У нас TRD называется User Requirement Specification (URS), а SRD называется System Requirement Specification (SRS). Traceability Matrix из URS в SRS. Потом еще есть Component Requirement Specification (CRS).

 

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

[a123-flex 0]

Только что, syoma сказал:

Народ хочет чтобы 9 женщин за месяц родили одного ребенка.

народ хочет чтобы 0.09 женщины за месяц родило 1 ребенка

 

Только что, syoma сказал:

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

Syoma давайте, научите нас, какая система дает результат быстрее и лучше)

[syoma 1]

18 minutes ago, a123-flex said:

Syoma давайте, научите нас, какая система дает результат быстрее и лучше)

Если вас устроит примерно 30%-ный просчет по срокам и превышение бюджета примерно на столько-же по сравнению с планируемыми- то пожалуйста. Это лучшие результаты, что я достигал на этом поприще. Надо ими гордиться, наверное.

[jcxz 242]

39 минут назад, a123-flex сказал:

Мало того, что исходники подняли, ключевые узлы воспроизвели, так еще и модернизацию успешно выполнили)

И, немцев немножечко подтерли.

Ладно если оно действительно работает и без косяков. А то ведь часто в таких случаях получается как в известной истории с Левшой и блохой: Подковать-то подковали, но скакать она перестала. 

Даже тут на форуме уже неоднократно наблюдаю повторяющуюся историю: выкладываю простой код, всего из нескольких строчек, а и то многие не понимают как оно работает. Что уж тут о целой АСУТП говорить... 

[a123-flex 0]

6 часов назад, syoma сказал:

Если вас устроит примерно 30%-ный просчет по срокам и превышение бюджета примерно на столько-же по сравнению с планируемыми- то пожалуйста. Это лучшие результаты, что я достигал на этом поприще. Надо ими гордиться, наверное.

Неплохой результат. 

Наше дело как устроено ? Если все пошло по плану, можно и в смету лечь. А если нет - можно и в 3 не попасть. Значит, у вас пошло все по плану -  значит что тот кто планировал знал задачу.

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

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

 

5 часов назад, jcxz сказал:

Ладно если оно действительно работает и без косяков. А то ведь часто в таких случаях получается как в известной истории с Левшой и блохой: Подковать-то подковали, но скакать она перестала. 

Я не понял Вы выражаете недоверие коллективу НИИ Духова, или вообще любому большому коллективу ?)

 

И чисто чтобы расширить мой кругозор: может назовете, хоть один большой продукт, без ошибок и проблем ?

 

Цитата

Даже тут на форуме уже неоднократно наблюдаю повторяющуюся историю: выкладываю простой код, всего из нескольких строчек, а и то многие не понимают как оно работает. Что уж тут о целой АСУТП говорить... 

Здесь не все программисты...

[Droid 77 0]

06.07.2020 в 23:57, nbn сказал:

Автор пишет фантастический рассказ?

Это было видно еще по первой странице темы :)

[nbn 1]

Надо спросить у Семёновой.

 

[DeadCadDance 0]

8 часов назад, Droid 77 сказал:

Это было видно еще по первой странице темы :)

Вы хотите сказать, что для всех, кроме меня, очевидно, что таких фирм в России нет?

[nbn 1]

3 минуты назад, DeadCadDance сказал:

Вы хотите сказать, что для всех, кроме меня, очевидно, что таких фирм в России нет?

Очевидно, что это тупиковая ветвь развития. Но Вы верьте в этот спектакль от начальства.

[HardEgor 87]

40 минут назад, DeadCadDance сказал:

Вы хотите сказать, что для всех, кроме меня, очевидно, что таких фирм в России нет?

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