добрый день всем.
Кто что может подсказать по теме документации по проекту. Интересет как это вообще делается. Пока сижу все на коленях делаю. Может у кого есть подобный опыт?

не уверен, но посмотри  такое

Str!pe, "на коленях" - это без документации?

Могу дать полный набор заготовок с пояснениями для RUP.
на аглицком.
Но, боюсь, что это обилие инфы просто завалит тебя и нихрена не поможет.
"Иногда гвозди всё-таки лучше забивать гвоздём а не свайной машиной"  

Опиши размер проекта, что предполагется, сколько людей писать будут и кто заказчик(перед кем отчитываться). И вообще -суть проекта. Будет ли он меняться в корне, что-то вполне конкретное .или тёмная лошадка. Может тебе много чего и не понадобится.

Добавлено @ 16:23 

Да-да! Что именно на коленях делаешь?   
Творение творишь? Или документацию наобум сляпываешь?

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

в больших конторах используется человеческий компилятор документации - "технический писатель"


имхо всё конечно.

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

Знаем мы что ты на коленях делаешь  Уж точно не молишься 

Думал над темой документации, читал книги, и вот к какому выводу пришёл. Какие бы системы ни пришлось для этого использовать, основная суть все равно идёт от создателя системы. Так чего думать то, пиши, так как единственный выход улучшить этот процесс это поручить его другому. 

Сори за то что задал вопрос и пропал.


Есть прочтенный "Мифический человеко месяц" и никакого опыта.  Задача формулируется так: Описать проект и задать задачу программисту и дизайнеру. 


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


Вполне конкретная тематика.


документацию сляпываю 


Во! А как его составить?


Она от меня идет! От остальных корректировки которые я могу и отклонить без обьяснения причин.

Добавлено через 36 секунд

А где это взять? И мануалы к ней....

Добавлено через 1 минуту и 48 секунд

Не оно :(

Гм.... ну чтоб вот так сразу уже на ходу и не возиться с проджект планами, конфигурейшн планами и проч(если проект не растягивается на долгое время и не окажется что это всё неплохо бы было иметь).
А также, если эта дока будет нужна только вам.

Описание общего видения системы, требования к функциональности, производительности, заделы для расширения.

Опиши требования(юзкейсы) к каждой функциональности. Чтоб человек брал требование и начинал писать(допроектировать) некий подмодуль уже по нему.

Опиши список задач и укажи в пределах какой задачи что будет выполнено. Наметь сроки(учти что фиг угадаешь со сроками обычно сразу  )

Опиши список тестируемых функциональностей и тестов, коотрые должны работать(опираясь на юзкейсы).

Опиши требуемую конфигурацию для всех (мини конфигурейшн план). То есть "такой-то томкат, такая-то версия того-то, установлено так и так, бежит под такой-то осью". Иначе потом начнётся "а у меня под виндой работало... ничё не знаю." Там же укажи где и как хранятся сорцы, как и что можно изменять, какие настройки, их изменение и вообще, работа с ними

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

Юзкейсы и тестовые планы описывай от руки, как Бог на душу положит - чтоб вам всем было понятно и больше конкретики.  То есть, не пиши "должно примерно так работать....", а пиши "то и то. Вызвали то - отработало вот так. при вызове - не должен изменяться такой-то объект и бла-бла". То есть учти сразу где может быть излишний полёт фантазии. Если полёт всё-таки есть - документируйте его, т.е. изменяйте требования.

Есть ещё куча всего, но, думаю, сейчас тебе это будет только в напряг.

Моно хоть какой то примерчик, кусок выдраный хоть откуда, даж если не настоящий?


Что за зверь?

Str!pe, http://www.gatherspace.com/static/use_case_example.html

arilou, 
Вот не учил я, не учил английский, теперь придется! Спасибо, буду разбираться что это такое 

Это сообщение отредактировал(а) Str!pe - 27.3.2007, 10:09

Str!pe, по-русски это называется вроде "прецеденты использования", или что-то вроде.

Например модуль "банки"

Он отвечает за хранение, предоставление, изменение информации о банках в системе
источник данных - такие-то таблицы в общей БД(может какие-то требования или указание конкретной СУБД) или такая-то специальная БД, механизм выборки и обработки реализован в фасаде или таком-то модуле, он должен интергироваться с тем-то, так-то (и всё что полезно разработчику знать)

кэйсы:

Получить "банк" - такой-то метод с такими то аттрибутами банка, такие-то аттрибуты важны, влияют(может быть) таким-то образом. 
UI должен: вызывать этот метод, отображать то и то, отображать результаты в таком виде(или таком, или настраиваться так и так)
Можно вплоть до скриншотов 

Создать - так и так, этот аттрибут обязателен, эти данные доизвлекаются из такого-то модуля таким-то образом, УИ - оповещение о создании, отображение созданного, такие-то подсказки и словари данных и др и др..

Изменить

Удалить

Не допускать того-то
Испоьлзовать тот и тот модуль

То есть вам будет полезен документ где описано видение функционала, ограничения, требования пользователя. С этим девелопер может начинать детально проектировать модуль, подгонять его под остальные и общие, разрабатывать части и одновременно тестер может описывать тест-кэйсы по этому документу. Кроме того, полезно описать программные интерфейсы для взаимодействия модулей



То есть писать Какие действия надо протестировать, какие вараинты входных данных, ожидаемые результаты и проч и проч.
Аутомейтед-тестер может начинать писать автоматические/юнит-тесты
И в момент когда выйдет первый релиз модуля оба могут сразу упрогнать тесты и показать разработчику что пошло не так, чтоб он ориентировался уже на реалии, а не писал с закрытыми глазами тонны кода дальше


Кроме того, вам полезно будет описать общий документик(можно это всё в один слить)
туда внести
code conventions(требования к форматированию кода, именованию переменных, общих принципов проектирования классов, методов и подмодулей) - (если надо).
общие соглашения по УИ или внешним неким интерфейсам - тем самым избаляешь разработчиков от львиной доли колебаний при решении какую картинку поместить на форму, как распоолжить поля, как спроектировать и назвать некие внешине методы програмного интерфейса.

пардон, времени мало...

Сейчас все мои действия сводятся к том что я делаю полностью макет страницы с расположением элементов. Все собираю в HTML - получается наглядный рабочий вариант, но без минимального дизайна. Каждый модуль разобран в отдельной странице по пунктам:

• Список вывода
• Динамика
• Коментарии

Указания выдаются только таким образом и дизайнеру и программисту...
Фактически стараюсь делать полностью работоспособный проект (стандартными Дримуверовскими скриптами) который описываю, что не могу сделать просто обьясняю на пальцах...

делает ли кто ни будь так же? И в чем собирает прототипы проекта?

Фактически, у тебя получается functional spec. Однако неплохо бы еще иметь документ с описанием требований.

буду знать как называется 

Поточнее если можно.

В принципе, точнее некуда - описание требований является одним из фундаментальных понятий. Посмотри ссылки на литературу, там немало книг по вопросу работы с требованиями.

Str!pe, для создания прототипов попробуй Axure Pro. 

не дочитал до конца...

Но мне очень понравилось, как всё расписано на Иреоне - http://ireon.org
По-моему это то, что нужно.
Я там одно время переводил всякие документы, очень серьёзный с виду подход.

Это сообщение отредактировал(а) arilou - 10.4.2007, 12:48

Str!pe, у нас создаются:

1. Устав проекта
2. Иерархическая структура работ
3. Расписание проекта
4. Список контрольных событий
5. Реестр рисков 
6. Планы реагирования на риски
7. План завершения проекта
8. План управления коммуникациями 
9. План управления изменениями

Первые четыре - всегда, остальные - в зависимости от сложности проекта.
Причем это только документы по управлению проектом. Есть еще отдельно - при анализе, при тестировании, и т.д.

А если вам нужно поставить задачу, лучше наймите аналитика. Например меня 

Экспериментировать в таких вещах нельзя. Я написала больше двух десятков ТЗ, и только на середине пути стала толком понимать, как это делается. Вы верите, что у вас это получится с первого раза?.... 

Это сообщение отредактировал(а) ida - 10.4.2007, 11:13

Мона и нуна  Как он тогда научится без экспериментов? 

Кста, не забудь про Configuration Management Plan

Спасибо всем за помощь, разбираюсь понемногу 

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

В аттаче заархивированный набор темплейтов. Вместо самого содержимого - описания того, что должно быть в содержимом.
7z архиватор(лично я не знал о таком  )

Присоединённый файл ( Кол-во скачиваний: 16 )
 rup_wd_tmpl.7z 191,54 Kb

Уважаемый chief а чем это открывать


Я такого формата не видел а вот 7z вполне распространенный формат его винрар последней версии берет спокойно )

???
там один архив 7z. семьзетом открывается. Что и где не так идёт?

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

Они самые

Все окей, забыл что офиса нет на компьютере. Разбираемся с содержимым..

Дежурная библиотека шаблонов
http://www.tenstep.com.ua/open/miscpages/9...rnerLibrary.htm

 На этой странице приведен список шаблонов, служащих дополнительной помощью для менеджеров, руководителей проектов и участников команд проектов.

1.0 Сокращенный паспорт проекта (также известен как Сокращенный устав проекта) 
1.0 Паспорт проекта (также известен как Устав проекта) 
1.0 Заявка на обслуживание 
2.0 План работ по управлению проектом (MS Project) 
4.0 Журнал учета вопросов/проблем 
4.0 Форма регистрации вопроса/проблемы 
5.0 Журнал запросов на изменение 
5.0 Форма запроса на изменение объема    
6.0 Персональный статус-отчет    
6.0 Отчет по состоянию проекта    
9.0 Программа качества проекта    
10.0 Карта показателей проекта    
10.0 Анкета удовлетворенности заказчика 

!  arilou

пользователь zbuk получил читательский билет на 5 дней и премодерацию на 20 дней за рекламу