|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
В рамках разработки системы или ее доработки, что первичней из бизнес-процессов: Разработка прототипа, интерфейса и т.д. ИЛИ Разработка функциональной спецификации? Как НАДО ДЕЛАТЬ? Как делают мы все уже знаем-))кому как удобней и кто что успевает.... ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2007, 17:19 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
И то и другое.. Все зависит от. Ответьте для себя на вопрос: для чего будет использоваться функциональная спецификация и кем? Если есть четкое представление, то надо так, как целесообразно. То, что правильно для одно7го, для другого бесполезно. Те же рассуждения касаются и макетирования-прототипирования. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2007, 17:35 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
Прототипирование меня не интересует, меня интересует как по ГОСТу (по времени выполнения) разрабатывается эта самая спецификация?Ведь есть же все-таки какой то регламент! ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2007, 18:07 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
LOKI-85В рамках разработки системы или ее доработки, что первичней из бизнес-процессов: Разработка прототипа, интерфейса и т.д. ИЛИ Разработка функциональной спецификации? Как НАДО ДЕЛАТЬ? Как делают мы все уже знаем-))кому как удобней и кто что успевает.... IMHO разработка функциональной спецификации первичнее. Иначе эта спецификация не нужна. Но это не означает, что спецификацию разрабатывают только один раз и навсегда. Чаще всего идёт такой цикл: - разработка функциональной спецификации - проектирование - планирование - программирование - тестирование - внедрение - переработка функциональной спецификации по отзывам заинтересованных лиц. Длина цикла может быть разной, от часов до лет. Циклы могут быть вложенными, но с "самоподобием". В конце каждого цикла, после внедрения (будь это внедрение многомиллионным моголетним мероприятием или 15-минутным показом приложения заинтересованному лицу), функциональная спецификация проверяется корректируется. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2007, 18:21 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
В ГОСТе нет термина "функциональная спецификация". Смотря что конкретно Вы понимаете под этой спецификацией. Если брать ближе к RUP, то сначала будут тексты Use Case, если потребуется отдельный пересчет функциональных требований, то они появятся параллельно (и будут связаны с) требованиями к интерфейсу (включая макеты форм) Если пытаться грести ближе к ГОСТ, то требования к функционированию войдут в ТЗ и туда же войдут требования к входным и выходным данным, удобству и надежности - суть требования к интерфейсу (опять же, если надо, включая макеты форм). По всему выходит, что опять параллельно. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2007, 19:04 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
нет чётких правил в ГОСТе. - спец-я может идти как приложение к ТЗ а может и не идти (в ТЗ указывается). - спец-я просто расширение ТЗ для того чтобы он не был "монстром". IMHO можно перевести как "приложение" ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2007, 12:19 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
Все очень и очень размыто. Да и кстати, может мы все по разному понимаем слово "спецификация"? Поскольку даже само определение трудно где-либо нормальное найти.А программеры, да и заказчики вегда смешивают спецификацию с ТЗ. Вот и ваши рассуждения смешиваются в одну кучу. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2007, 16:05 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
Спецификация - описание функциональности с перечнем модулей, систем и подсистем с приложенной документацией к ней. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2007, 16:07 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
LOKI-85Спецификация - описание функциональности с перечнем модулей, систем и подсистем с приложенной документацией к ней. спецификация - это "список (приложение)" и может быть к любому документу http://www.arbinada.com/modules.php?name=News&file=print&sid=116 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2007, 16:38 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
LOKI-85Прототипирование меня не интересует, меня интересует как по ГОСТу (по времени выполнения) разрабатывается эта самая спецификация? Ведь есть же все-таки какой то регламент!Ну а в чём проблема? 1 ГОСТ 34.601-90 «Стадии создания автоматизированной системы» Устанавливает стадии, этапы и содержание работ при создании автоматизированной системы (АС) 2 ГОСТ 34.201-89 «Виды, комплектность и обозначения документов при создании АС» 3 ГОСТ 34.602-89 «ТЗ на создание АС» 4 РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов» Всё мгновенно находибельно Гуглом. Только вот слово "спецификация" вы там найдёте лишь во фразе "спецификация оборудования". Думаю, это не то, что вы имели в виду на само деле. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2007, 19:28 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
LOKI-85В рамках разработки системы или ее доработки, что первичней из бизнес-процессов: Разработка прототипа, интерфейса и т.д. ИЛИ Разработка функциональной спецификации? Как НАДО ДЕЛАТЬ? Как делают мы все уже знаем-))кому как удобней и кто что успевает....Во-первых, применительно к процессу разработки ПО традиционно не применяют термин "бизнес-процесс", а, например, в Госте пользуются терминами "этап", "стадия", в современных методиках разработки - "фаза", "дисциплина", "поток работ", "попдроцесс" и "подпроцесс". Во-вторых, слово "спецификация" не является сильноустоявшимся, и в разных контекстах понимается по-разному. Если посмотреть в корень, в семантику, то "спецификация" - это ничто иное, как "указания", "детализация", т.е. детальная и подробная расшифровка чего-то более общего. В разработке ПО обычно детализируются характеристики продукта/системы, если детализируются внешние характеристики, более близкие к исходным требованиям и целям системы, то это "спецификация требований", requirements specification, на профжаргоне - "specs". Если детализируются внутренние свойства, более близкие у решениям, то это "спецификации решения". Если это уж совсем описания уровня реализации, как на самом деле всё будет создаваться, то "спецификации реализации". Т.е. прототип конечно делается на основе требований, возможно, детальных (спцификации требований). Дальнейшая детальная проработка прототипа может порождать спецификацию решения и далее, реализации. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2007, 19:40 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
LOKI-85Спецификация - описание функциональности с перечнем модулей, систем и подсистем с приложенной документацией к ней. Как минимум Леффингуэлл, Коберн и Вигерс сходятся в том, чтонужно отделять спецификацию функционала (требования, UC) от спецификации архитектуры (в т.ч. "перечня модулей, систем и подсистем"). Первая идёт от заказчика, если не выполнить - не заплатят денег. Вторая идёт от архитекторов и разработчиков, и в большинстве случаев на заказчику почти безразлична. Возможно, Вы совмещаете роли аналитика и архитектора. Но даже в этом случае нужно понимать: один и тот же функционал можно реализовать по-разному. И на этапе выявления функциональной спецификации трудно принять правильное архитектурное решение, даже если оно кажется очевидным. Чтобы сделать это, необходимо (но не достаточно) учитывать все функциональные требования. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2007, 11:46 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
AlexTheRaven И на этапе выявления функциональной спецификации трудно принять правильное архитектурное решение, даже если оно кажется очевидным. Чтобы сделать это, необходимо (но не достаточно) учитывать все функциональные требования. Функциональные треб-я в виде специфик. ----> ВИ/Преценденты/USE CASE паральлельно с архитектурой? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2007, 12:16 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
AlexTheRaven...на этапе выявления функциональной спецификации трудно принять правильное архитектурное решение, даже если оно кажется очевидным. Чтобы сделать это, необходимо (но не достаточно) учитывать все функциональные требования.Саша, давай всё-таки помнить, что архитектура делается главным образом на основе нефункциональных требований :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2007, 12:25 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
Майевтик AlexTheRaven...на этапе выявления функциональной спецификации трудно принять правильное архитектурное решение, даже если оно кажется очевидным. Чтобы сделать это, необходимо (но не достаточно) учитывать все функциональные требования.Саша, давай всё-таки помнить, что архитектура делается главным образом на основе нефункциональных требований :) с чего бы это? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2007, 13:41 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
Майевтик AlexTheRaven...на этапе выявления функциональной спецификации трудно принять правильное архитектурное решение, даже если оно кажется очевидным. Чтобы сделать это, необходимо (но не достаточно) учитывать все функциональные требования.Саша, давай всё-таки помнить, что архитектура делается главным образом на основе нефункциональных требований :) Денис, Мы, наверное, понимаем под архитектурой разные вещи :) . Для меня архитектура - всё, что лежит между требованиями и UC с одной стороны, и TC с другой стороны. В т.ч. class model, component model, deployment model, сама реализация, настройки. Ну например: UC: "Оператор отдела логистики определяет маршрут следования груза"=> Class Model: "Перемещение", "Пункт", "Груз" Component Model: "Интерфейс оператора отдела логистики", "Подсистема поиска оптимального маршрута" Deployment Model: "Рабочее место оператора логистики", "Вычислительный сервер поиска оптимальных маршрутов" точно также, как и Formal Requirement: "Система должна поддерживать одновременно 10000 пользовательских сессий"=> Class Model: "Вычислительный сервер поиска оптимальных маршрутов", "Сервер БД", "Канал связи", "Нагрузка" Component Model: "Подсистема балансировки нагрузки" Deployment Model: "Рабочее место оператора логистики", "Вычислительный сервер поиска оптимальных маршрутов", "Сервер БД". ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2007, 00:02 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
LOKI-85В рамках разработки системы или ее доработки, что первичней из бизнес-процессов: Разработка прототипа, интерфейса и т.д. ИЛИ Разработка функциональной спецификации? Как НАДО ДЕЛАТЬ? Как делают мы все уже знаем-))кому как удобней и кто что успевает.... Если спецификация достаточно очевидна, то нафиг тебе прототипы и т.д.. Пишешь спецификации, делаешь продукт. Другое дело, когда требования не ясны, или есть сомнения в их достоверности или реализуемости. Тогда по делаем спецификации какие есть, по ним строим модели, прототипы системы, на них обкатываем требования, делаем уточнённые спецификации и т.д. итерационно. В любом случае сначала нужно хотя бы приблизительно сформулировать что мы хотим получить, а потом разрабытывать. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2007, 19:52 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
LOKI-85Прототипирование меня не интересует, меня интересует как по ГОСТу (по времени выполнения) разрабатывается эта самая спецификация?Ведь есть же все-таки какой то регламент! Регламентов люди всяких много понапридумывали. Вопрос только, какую часть этих регламентов целесообразно исполнять. ИМХО, обязательно только с пользователями пообщаться перед разработкой ПО, иначе можно совсем направление потерять. Всё остальное - по ситуации. На исполнение любого регламента тратится время, соответственно, если не видите от него конкретной практической пользы - лучше забить. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2007, 22:43 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
AlexTheRavenДенис, Мы, наверное, понимаем под архитектурой разные вещи :) . Для меня архитектура - всё, что лежит между требованиями и UC с одной стороны, и TC с другой стороны. В т.ч. class model, component model, deployment model, сама реализация, настройки.Что значит "для меня", "для тебя"? Читаем класегов и точка. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2007, 01:54 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
Майевтик AlexTheRavenДенис, Мы, наверное, понимаем под архитектурой разные вещи :) . Для меня архитектура - всё, что лежит между требованиями и UC с одной стороны, и TC с другой стороны. В т.ч. class model, component model, deployment model, сама реализация, настройки.Что значит "для меня", "для тебя"? Читаем класегов и точка. Господа, "из разных кланов", сможете вы договорится кто важнее ? ;-) Agile методологии в некоторых случаях предлагают вообще обходиться без проектирования, но если это рассказать архитектору - он подумает, что вы хотите лишить его работы :) Мне понравилось про спецификации и прототипы. Вопрос в том - что когда создавать. На начальных этапах нам мало что известно, а вот потом заказчик потребует четких описаний! :) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2007, 22:54 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
ИМХО, спецификация не нужна только в одном случае: когда постановка задачи, замысел и реализация - в одной голове. Когда есть разделение труда - без спецификации не обойтись. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2007, 04:30 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
CodenamedИМХО, спецификация не нужна только в одном случае: когда постановка задачи, замысел и реализация - в одной голове. Когда есть разделение труда - без спецификации не обойтись. Нужно различать спецификацию, как проектный документ и как неформальный набор описаний. Сначала появляется неформальный набор описаний. Затем эти описания можно формализовать и записать в виде документа или комментариев к коду или оставить в одной голове. Как правило между идеей и реализацией приходится создавать несколько промежуточных представлений системы с разных точек срения. Идеальная программирующая машина должна непосредственно понимать неформальные спецификации, создавать по ним код и вытавать технические спецификации относящиеся к различным аспектам системы, чтобы пользователь мог удостовериться, что машина поняла его правильно или уточнить свои требования. Наиболее точной технической спецификацией программного продукта является код, но его сложно понимать. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2007, 16:03 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
mcureenabНаиболее точной технической спецификацией программного продукта является код, но его сложно понимать. +1 :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2007, 16:59 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
> Наиболее точной технической спецификацией программного продукта является код Код не является технической спецификацией. Код есть пример субъективного понимания спецификации кодером. Следствие субъективности - ошибки, которых в спецификации может не быть. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2007, 17:05 |
|
Что первичней:разработка или создание спецификации к ней?
|
|||
---|---|---|---|
#18+
guest_20040621Код не является технической спецификацией. Код есть пример субъективного понимания спецификации кодером. .... если его кодирует кодер, отличающийся от автора спецификации. Код "от автора спецификации" есть воплощенная спецификация, с поправкой на "не умею сказать то, что хочу". С этим же связана знакомая всем ситуация вида "написать код быстрее, чем объяснить, как же его писать". ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2007, 19:22 |
|
|
start [/forum/topic.php?fid=33&fpage=52&tid=1549090]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
14ms |
get forum data: |
2ms |
get page messages: |
77ms |
get tp. blocked users: |
2ms |
others: | 266ms |
total: | 424ms |
0 / 0 |