А не поделится ли кто примером Технического Задания?

[max99]

Искал в интернете, есть много документов на эту тему, различные планы, описания, а вот найти готовое ТЗ на разработку функциональности не получилось.
Не поделится кто таким документом?

Да, и еще вопрос, есть ли методика по оценке доработки (в данном случае на доработку функциональности аксапты)? Или все действуют на глазок?

[dmit2604]

Интересный вопрос. Насколько я понимаю, методология у всех разная. То есть, вроде бы все одно и то же делают, но каждый в соответствии со своими корпоративными стандартами и предпочтениями. Есть, конечно, стандарты. Установите себе RUP и посмотрите на темплейты там. Уверен, что что-то подобное разработано и под SADT. Для Аксапты я лично некий суррогат сочинял. Важнее всего, чтобы затраты на написание документации не превзошли пользы от ее использования. Думаю, Вы понимаете о чем я. А еще я видел, как народ прямо по Requirements Specification пишет. Требования просто сплошной прозой написанные. Тут уж как кому удобно

[mad_pilot]

могу поделиться формулой определения срока внедрения:

(количество направлений в холдинге)*(среднее кол-во компаний в группе)*( 1 + 2,5^(коэфф. сложности номенкл. единицы))*(1 + 3^(коэффициент дурости руководсва))*3 =
кол-во месяцев потребных на внедрение командой их 3-х аналитиков.

0<= (коэфф. сложности номенкл. единицы) <= 100
0<= (коэффициент дурости руководсва) <= 100


))

[komar]

А что такое "среднее количество компаний в группе"? Точное неизвестно? И какую среднюю брать?

[mad_pilot]

очепятка:

среднее кол-во компаний в направлении

[DTD]

Quote:

Изначально опубликовано dmit2604
А еще я видел, как народ прямо по Requirements Specification пишет. Требования просто сплошной прозой написанные. Тут уж как кому удобно

А если не рассматривать вариант по Requirements Specification, в каком виде примерно должен быть design документ ? Структуру я представляю, а содержание ... (вариант когда много доработок, фактически как новое решение на базе Аксапты)? Тут все таки немого отличается от разработки обычного ПО, - там design документ - это постановкa задачи девелоперам, а в случае ERP, как я понимаю ее еще нужно клиенту подписывать давать, наверное не стоит перегружать теxническими терминами ?

[Тимур]

Документ будет полезен, если он будет разбит на бизнес-процессы. А каждый процесс будет разбит на шаги со ссылкой на автоматизированные процедуры.

[БП]

Quote:

Изначально опубликовано max99
Искал в интернете, есть много документов на эту тему, различные планы, описания, а вот найти готовое ТЗ на разработку функциональности не получилось.
Не поделится кто таким документом?

Да, и еще вопрос, есть ли методика по оценке доработки (в данном случае на доработку функциональности аксапты)? Или все действуют на глазок?

Плохо искал - "Яndex - Найдеццо фсё". Про методику - есть, почитай BPH.

[vasiliy]

А чего никто не хочет пример ТЗ выкладывать?
Я так думаю если выложить ТЗ на одно изменение оно пользы конкурентам все равно не принесет?

[Андре]

Quote:

Я так думаю если выложить ТЗ на одно изменение оно пользы конкурентам все равно не принесет?

Зато будет повод постебаться

Вот
здесь есть неплохой пример задания. Да и вообще, статья полезная.

[2A]

Quote:

Изначально опубликовано vasiliy
А чего никто не хочет пример ТЗ выкладывать?
Я так думаю если выложить ТЗ на одно изменение оно пользы конкурентам все равно не принесет?

У MSBS есть соответсnвующая методология внедрения Axapta.
Там есть и шаблоны различных документов.

[vasiliy]

Quote:

Изначально опубликовано 2A


У MSBS есть соответсnвующая методология внедрения Axapta.
Там есть и шаблоны различных документов.

А где можно посмотреть?

[Serge Kotov]

Quote:

Изначально опубликовано max99
Искал в интернете, есть много документов на эту тему, различные планы, описания, а вот найти готовое ТЗ на разработку функциональности не получилось.
Не поделится кто таким документом?

Да, и еще вопрос, есть ли методика по оценке доработки (в данном случае на доработку функциональности аксапты)? Или все действуют на глазок?

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

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

Оценка времени на доработку производится после подготовки ТЗ и его оценки разработчиком модификации. В случае оутсорсинга время переводим в деньги разумеется. Это верно для небольших модификаций.

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

[2A]

Quote:

Изначально опубликовано vasiliy


А где можно посмотреть?

Если Вы - партнер MBS , то они предоставят его.
Если нет - то сам партнер, внедряющий у Вас
может предоставтить.

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