| Deem |
| Отправлено: 06.07.2004, 12:13 |
|
Мастер участка
Группа: Участник
Сообщений: 327
|
Народ, расскажите, насколько подробным должно быть техзадание. Что в него обычно суют. И, если можно и нетрудно, подкиньте примерчик ТЗ для простенькой программки.
|
|
| olegenty |
| Отправлено: 09.07.2004, 10:50 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
Примера не приведу. Но!
1. 60-80% времени реализации проекта — разработка ТЗ.
2. В ТЗ должны быть указаны требования пользователя к качеству программного продукта, как то:
2.0. Перечень выполняемых продуктом функций
2.1. (Извечный вопрос) Быстродействие (в виде спецификации: функция — временной промежуток её выполнения от кол-ва секунд — до кол-ва секунд)
2.2. Количество пользователей от минимума и до максимума
2.3. Алгоритмы функций (не программных, а пользовательских, есс-но) — каким образом вход преобразуется в выход
2.4. Макеты форм, как ввода, так и вывода, и вообще — требования к интерфейсу.
2.5. Приём на поддержку (предполагается ли, что пользователю будут отданы исходники)
2.1 и 2.2 влияют, например, на выбор СУБД и пр...
2.5 влечет за собой требования к коду и, возможно, языку и среде разработки
2.4 чтобы, если пользователь не доволен интерфейсом, ткнуть его носом в подписанное его рукой ТЗ
готов подискутировать... 
|
|
| Deem |
| Отправлено: 12.07.2004, 10:37 |
|
Мастер участка
Группа: Участник
Сообщений: 327
|
Не.... ну 80% — это ты загнул. Я изучал этот вопрос: смелые самые говорят 30%. Потому как, ежели 80%, то это уже с названиями класов-методов, во всеми интерфейсами модулей и со всеми формами пользовательского, отчетами и пр., подробно описанными на бумаге.
В общем виде уже сделал техзадание, сервер БД выбран жизнью (FB, родимый, ессесна ). Я хотел глянуть или послушать, как делают профессиналы, пишущие не первый ТЗ. Я пишу уже не первый. Но между ними — месяцы. И наработок четки нет.
И еще: хотел стырить структуру документа, т.к. некоторые части пересекаются (интерфейс с релизацией, содержание базы и конкретная структура таблиц), и у меня проблемы с поиском и названиями разделов. Хотел смахлевать.
|
|
| Deem |
| Отправлено: 12.07.2004, 10:50 |
|
Мастер участка
Группа: Участник
Сообщений: 327
|
Да, техзадание ставит наша контора, поэтому легче. Реализация — as is Просто хочется сделать красиво, удобно, и чтоб (если получится) можно было прикинуть время разработки. Вот я и спрашиваю: что надо описать и насколько подробно?
Прога, вобщем-то, простая, прозрачная. Товарный склад. Таких много, но надо свою . Самое страшное в ней — система лицензирования  да налоговая накладная  .
Если кто хоочет помочь, пожалуйста. Кстати, я нет перерыл в поисках требований (или ГОСТа). Но что-то глухо. Нашел пару примеров на продукты и системы. Но они разные. Системы там нет. Я думаю, многим будет интересно. Предлагаю написать мне ТЗ  совобча.
"Я не халявщик. Я — партнер. " © МММ. Не хотите- не надо.
PS/
Сори, недопер. 30% от времени разработки. А при хорошем ТЗ, понятное дело, остается всег-ничего: не надо больше напрягаться, искать варианты.... все уже известо и понятно. Знай стучи по клаве.
Первый пункт я бы обозвал "Общие сведения". И запхал бы туда все.
Отредактировано Deem — 12/07/2004, 17:23
|
|
| AVC |
| Отправлено: 12.07.2004, 13:59 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
В моей практике ТЗ в 80% случаев пишется самим программистом примерно в середине опытной эксплуатации — когда цели и способы решения в конце концов определились. Один раз в жизни сталкивался с грамотно написанным ТЗ — работать было приятно, ни каких претензий и общение с заказчиком свелось к минимуму.
Делал такое приложение несколько лет назад — могу отдать Налоговую накладную на quick report'е (хотя бы текста набирать будет меньще)
|
|
| Deem |
| Отправлено: 12.07.2004, 16:29 |
|
Мастер участка
Группа: Участник
Сообщений: 327
|
to avc
Спасибо, канеша, за доброту. Но имеется ввиду РФ-накладная?
Да и с QReport-а я ушел. Он однажды как заглючил, уже на работающем проект, пришлось все репорты переделывать на свою систему.
У меня в FoxPro есть накладная своя, а толку он нее мало.
Да и это не главное на данном этапе. А хорошая ТЗ — вещь нужная. Для прошлых проектов писал уже по факту. Так проблем не было. Да и требовалось от нее уже мало-мало. А вот от впередсмотрящей надо очень много. Вот и хочу хорошо написать. 
|
|
| AVC |
| Отправлено: 12.07.2004, 16:42 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE | | Вот и хочу хорошо написать |
Удачи! |
|
| olegenty |
| Отправлено: 14.07.2004, 11:51 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
2Deem
ну ты тут хоть перечень функций пришли, которые должны выполняться, от этого ж плясать, если тут коллективно ТЗ писать.
|
|
| Lazy |
| Отправлено: 15.07.2004, 09:56 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 12
|
| QUOTE (Deem @ 12/07/2004, 11:39) | | хотел стырить структуру документа, т.к. некоторые части пересекаются (интерфейс с релизацией, содержание базы и конкретная структура таблиц), и у меня проблемы с поиском и названиями разделов. Хотел смахлевать. |
Может вот это поможет:
Здесь куча гостов
а здесь конкретно требования к содержанию ТЗ. |
|
| Deem |
| Отправлено: 16.07.2004, 10:45 |
|
Мастер участка
Группа: Участник
Сообщений: 327
|
To Lazy
Вот это вещь!
Мне показалось, что больше всего подходит этот стандарт
http://sysavt.h11.ru/docs/gost/34-602-89.htm
Там есть много чего лишнего. Но вцелом нормально. Хотя некоторые пункты надо расширить.
И многие пункты должны зависеть от того, каков профиль ПО: базы, АСУ, графика, игры ....
Тут тоже есть, но я понимаю, это аж 1978 год:
http://sysavt.h11.ru/docs/gost/19-201-78.htm
Себе я уже основу сделал. Остался интерфейс да время разработки расписать.
В ГОСТах про интерфейс, вроде, ничего нет. А для юзера это главное (тем более в Windows).
Привожу план, кому интересно
ПРОЕКТ системы складского учета
1. ОБЩЕЕ ОПИСАНИЕ
1.1. Назначение системы
1.2. Требования к системе
1.2.1. Технические требования
Для какой ОС, из скольки частей и каких пакет состоит, и т.д.
1.2.2. Требования к интерфейсу
Общие: язык, основная концепция организации интерфейса
1.2.3. Основные функциональные требования
Тут уже много чего: описание, чего должна уметь, в свободной форме
1.2.4. Дополнительные функциональные требования
Дополнительные фичи
2. ХРАНЕНИЕ ДАННЫХ
2.1. Поставщики/Контрагенты/Склады/Предприятия пользователя
Описание в общем виде, структура таблицы и ХР
2.2. Карточка предприятия
Описание в общем виде, структура таблицы и ХР
2.3. Накладные прихода, расхода, возврата, перемещения по складам
Описание в общем виде, структура таблицы и ХР
2.4. Акты уценки, списания
Описание в общем виде, структура таблицы и ХР
2.5. Категории товаров
Описание в общем виде, структура таблицы и ХР
2.6. Товары
Описание в общем виде, структура таблицы и ХР
2.7. Валюты
Описание в общем виде, структура таблицы и ХР
2.8. Единицы измерения
Описание в общем виде, структура таблицы и ХР
2.9. Банки
Описание в общем виде, структура таблицы и ХР
2.10. Должности
Описание в общем виде, структура таблицы и ХР
2.11. Месяцы
Описание в общем виде, структура таблицы и ХР
2.12. Справочники пользователя
Описание в общем виде, структура таблицы и ХР
2.13. Сотрудники
Описание в общем виде, структура таблицы и ХР
2.14. Пользователи программы и их права
Описание в общем виде, структура таблицы и ХР
3. ОБРАБОТКА ДВИЖЕНИЯ ТОВАРА
3.1. Товар
3.1.1. Приход от поставщика
Описание действий пользователя, программы
3.1.2. Внутреннее перемещение по складам
Описание действий пользователя, программы
3.1.3. Расход (уход к контрагенту)
Описание действий пользователя, программы
3.1.4. Уценка
Описание действий пользователя, программы
3.1.5. Списание
Описание действий пользователя, программы
3.1.6. Возврат
Описание действий пользователя, программы
3.1.7. Тара
Описание действий пользователя, программы
Далее описание печатных документов:
4. ДОКУМЕНТЫ
4.1. Печать
4.1.1. Приходные/расходные накладные
4.1.2. Внутренние накладные
4.1.3. Акты уценки
4.1.4. Акты списания
4.1.5. Справочники пользователя (для настраиваемых свойств товара)
4.1.6. Список поставщиков
4.1.7. Список контрагентов
4.1.8. Остатки товаров
4.1.9. Отправка/возврат тары
4.1.10. Список сотрудников (с фильтрацией по предприятиям)
5. АНАЛИТИКА
Это я еще не придумал. Описание интерфейса не знаю куда воткнуть. Может сделать отдельным разделом. А может в ОБРАБОТКА ДВИЖЕНИЯ ТОВАРА воткнуть. Там подразделы Примерно совпадают с отдельными формами (своя форма на все эти операции). Хотя есть еще формы настройки, формы фильтров, генераторы отчетов....
Пока соображаю.
А про совместное написание МНЕ ТЗ я пошутил. Думал, есть, может, какой коммерческий стандарт для ТЗ. Но пока подсказали где взять советский (бессмертный). А всякие девелоперы так и будут жаловаться друг другу, что заказчик не может составить ТЗ, он глупый и не знает, что хочет. Просто он должет иметь план этого задания, после заполнения которого разработчик будет знать, что ему делать.
А пока каждый пишет свое ТЗ, ситуация будет одинаковая.
|
|
| Asher |
| Отправлено: 16.07.2004, 12:23 |
|
Мастер участка
Группа: Модератор
Сообщений: 550
|
| QUOTE | | А всякие девелоперы так и будут жаловаться друг другу, что заказчик не может составить ТЗ, он глупый и не знает, что хочет. |
Никогда в жизни, ни в этой, ни в советсткой эпохе, заказчик ТЗ не составлял. Он давал только техническое предлжение и утверждал, после некоторых утрясок, написанное разработчиком-исполнителем ТЗ.
Потому как никто, кроме разработчика, не может учесть все имеющиеся возможности и невозможности.
P.S. Собственно по теме вопроса.
Время общения с заказчиком при сдаче обратно пропорционально подробности ТЗ. Вопросы типа "я имел в виду другое, когда говорил это" не возникают как класс.
Отредактировано Asher — 16/07/2004, 14:32
|
|
| Георгий |
| Отправлено: 17.07.2004, 22:02 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
| QUOTE | | И, если можно и нетрудно, подкиньте примерчик ТЗ для простенькой программки. |
Чёт вы тут перетрудились — то ТЗ, что Deem в последнем посте написал, вовсе не для простенькой программы, а для какого то монстра на 0.5 года работы или на 1-2 месяца работы типа "тяп-ляп"
Тем более подозреваю, что желание написать ТЗ и приход нового сотрудника тесно связаны
для простньких программ пишу простенькие ТЗ например вот с таким оглавлением:
ВВЕДЕНИЕ В ПРОБЛЕМУ
ВАРИАНТЫ РЕШЕНИЯ
ПРЕДЛОЖЕНИЕ ПО ОРГАНИЗАЦИИ ИНФОРМАЦИОННОЙ СТРУКТУРЫ
СТРУКТУРА ВЗАИМОДЕЙСТВИЯ
ПРЕДЛОЖЕНИЕ ПО РЕАЛИЗАЦИИ АЛГОРИТМИЧЕСКОЙ ЧАСТИ
ПРЕДЛОЖЕНИЕ ПО РЕАЛИЗАЦИИ СИСТЕМНОЙ ЧАСТИ
ПРЕДЛОЖЕНИЕ ПО РЕАЛИЗАЦИИ КОНФИГУРАЦИОННОЙ ЧАСТИ
кстати — обратил внимание, что ТЗ составленное в виде предложений, а не приказов куда лучше воспринимается.
ЗЫ. сомневаюсь, что может кому либо пригодиться, но то ТЗ, оглавление которого привёл выше, прикрепил к сообщению
|
|
| Deem |
| Отправлено: 19.07.2004, 09:49 |
|
Мастер участка
Группа: Участник
Сообщений: 327
|
Не все так страшно, как Георгий описал. Простенькая — это какая? Типа: введите а и б. С = а + б. Вывести С. ?
Как в ТЗ с рекомендациями указать сроки выполнения и контроля этапов разработки? И потом, заказчиком может выступать проект-менеджер (если глядеть со стороны кодера). А он-то должен разбираться "что можно, что — нужно". Я читал ТЗ на разные продукты (не ПО). В основном, его составляли не те, кто исполнял. А грамотный заказчик МОЖЕТ составить ТЗ. Другое дело, что ему облом этим заниматься.
У меня в данный момент заказчик — директора. Они в программировании , как таковом, ни бум-бум. Но с программами готовыми имеют дело. Соотв. знают, что можно-нельзя. Но писать ТЗ самим облом, тем более, что есть кого заставить. А задачу обрисовали довольно полно. Просто, когда укладываешь все на бумаге, находятся доп. вопросы, которые надо бежать уточнять.
А программа, описанная мной, не монстр. :0 Хотя откуда посмотришь.
Если со стороны пользователя смотреть, то, вроде, ничего сложного. Если изнутри — не быстро-решаемая задачка. Но и не на полгода. Полгода я делал прогу раза в три сложнее и запутаннее. 7 мес.
Но не надо напоминать мне лишний раз, что работаю забесплатно. Сам знаю. Диплом у меня, видите ли, не универ-политех. Так что.... Не об этом базар.
Не может ТЗ содержать рекомендации. А уж тем более для программы, разрабатываемой толпой программеров. Начнется "Кто в лес, кто по дрова". А заказчик, даже знающий, что ему надо, не знает, что надо разаработчику (сегодня так).
Хотя может я и ошибаюсь. Может и так: ТЗ составленное заказчиком содержит рекомендации; составленное разработчиком — конкретные директивы.
А написать ТЗ желание возникло после того самого проекта на 0.5 года: никто не предполагал такого срока. Хочу теперь сделать все правильно.
А сотрудника мне никак нйти не могут. Требования "крутые" , видимо.
Отредактировано Deem — 19/07/2004, 11:16
|
|
| Deem |
| Отправлено: 19.07.2004, 10:10 |
|
Мастер участка
Группа: Участник
Сообщений: 327
|
To Георгий
ТЗ Rezerv штука интересная. Мне такие задания давали, когда я в науке работал. Там касалось физики и математики, но подобное ТЗ составлял не разработчик, а заказчик. Понятно, что реализацию оставляли полностью мне. Но, как грица, заказчик заказчику рознь. С Заказчиком Обычным я мало знаком. Может отсюда и мое видение проблемы.
|
|
| Deem |
| Отправлено: 19.07.2004, 11:42 |
|
Мастер участка
Группа: Участник
Сообщений: 327
|
И еще: вид ТЗ (рекомендательный или жесткий) зависит, я бы сказал, от задачи, заказчика и исполнителя: 1. Если задача решается какая-нибудь научная, изыскательная, новое направление, то четким ТЗ быть не может. Это понятно. Хотя и не всегда. 2. Если заказчик хочет, чтобы продукт был "новым" во всех отношениях, а не склепан из старых кусков (и готов за это платить), надо дать волю фантазии разработчика. 3. Если заказчик знает, что разработчик все равно сделает по-своему, нет смысла жестко формулировать.
|
|
| vitavita |
| Отправлено: 21.07.2004, 07:11 |
|
Дежурный стрелочник
Группа: Участник
Сообщений: 59
|
Странно что здесь никто не упомянул UML .Ряд его диаграмм были бы полезны при написании ТЗ и для общения с заказчиком — Use case , Deployment . да и для себя может быть полезно.
Кстати Borland выпускает Together Правда я его не видел — на рынке нет ломанной .
А не подскажите никто не видел каких нибудь методик по оценке времени написания программ Как оценить возможное время изготовления программного продукта или все делают на глазок?
|
|
| Deem |
| Отправлено: 21.07.2004, 09:47 |
|
Мастер участка
Группа: Участник
Сообщений: 327
|
Да уж.... Мы тут по этой теме не один килобайт накоцали. Однако, пришли к выводу, что это сугубо индивидуально решается. И к этому моменту должно быть ТЗ. Кажися, чем оно подробнее, тем точнее прогноз времени создания ПО.
Тут у меня закралось подозрение, что иногда мы говорим о разных вещах: ТЗ — это как бы описание того, что надо сделать. А описание как сделать — может это уже не ТЗ, а другой документ? Какой нибудь план реализации или что-то подобное. Хотя в ГОСТах указано, что в ТЗ входит план сдачи и контроля частей проекта с датами. Т.е., как бы, уже известно должно быть, сколько надо времени. Так что, либо в ТЗ уже указано "как", либо время разработки берется из "того самого" документа, где говорится про "как".
|
|
| olegenty |
| Отправлено: 21.07.2004, 10:20 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
Одни и те же мысли в разное время посещают людей, задействованных в одной производственной области
У нас "как" называется "Постановка задачи"
Я же считаю, что "как" должно быть указано в ТЗ.
Остаётся только одна беда: НЕТ нормативов. Даже когда кодеру отдано подробное задание, не требующее от него ничего, кроме "тупого кодирования", нет нормативного документа, по кторому можно "прикинуть" сроки реализации.
|
|
| Deem |
| Отправлено: 22.07.2004, 10:31 |
|
Мастер участка
Группа: Участник
Сообщений: 327
|
Вот-вот. Когда-то я задал вопрос про нормативы, и тут началось...
Не будем повторяться. Все глубоко индивидуально как для человека, так и для конторы: уровень зарплат в конторах тоже в какой-то степени регламентирует скорость и качество разработки. Так что каждая контора, думается мне, если решила сурьезно заниматься девелоперством, должна собрать данные о скорости разработки различных модулей, компонентов, ТЗ (тоже надо) и целых проектов. Потом посчитать средние, максимумы и минимумы для разных людей, для разной зарплаты, для разных сред разработки ... Короче, целое изыскание провести. И только тогда можно будет иметь хоть какие-то нормативы. А все мои, например, поиски святого грааля так ни к чему и не привели.
Для себя решил, что чем меньше элемент, для которого я указываю время разработки, тем точнее (после суммирования) я буду знать время разработки всего проекта, т.к. он, этот проект, складывается из таких мелких вещей, как разработка пиктограммы для кнопаря (у некоротых прог такие противные картинки бывают!), расположение элементов управления на форме (тоже бывает мнооого времени сожрет) и т.д.
Короче, хорошо структурированное и подробное ТЗ может спасти отца русской демократии.
|
|
|
