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

thomas, не совсем понятно, что именно вам не совсем понятно в планировании этих этапов?

Я так понял - просто рабочий план. Типа теория - хорошо, а поглядеть на реальный план - лучше. 

arilou, 
Приветствую.
Что планировать в разделе разработка(третий этап) я знаю. Что планировать в разделе анализ(второй этап) я примерно представляю.
Анализ:
- представление системы;
- анализ требований;
- анализ use-case;
- моделирование процессов;
- моделирование данных.
Тут наверное возможны подпункты. Какие, я пока не знаю. Надеюсь, что подскажите.
А вот с первым разделом - планирование, совсем завал.
Что тут то надо планировать?   
И по теории, этот этап занимает 15% времени работы над всем проектом.

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

Во, в точку.   

Гм. Рабочий я не выложу - не приветствуется.
Поищу старых проектов - может завалялся. Хотя там субплан многолетнего проекта... тебе серединка вряд ли интересна будет

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

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

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



Отталкивайся от реалий. Может у тебя проект ясный как пень и там планировать/проектировать особото и нечего, а ты "по теории" проворонишь 15% времени на путание в шнурках на этапе "планирования планирования плана".

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

chief39, 

Было бы не плохо. Повторюсь, в принципе мне нужно посмотреть на первую часть плана - планирование.
Остальное более мение ясно и понятно.


Тут все равно подпункты писать придется. Нужно выдержать требования к составлению плана.
Про процессы и данные тут тоже более мение все нормально.
На программу получено подробное ТТЗ.
 

В "буржуинстве" такое не прокатит.     При старте проекта подписывается контракт, а к нему есть приложение(ТТЗ) с подробным описанием требований и ожиданий клиента.
После подписания контракта изменения и дополнения не "канают". После утверждения плана тем более.
Если уж что-то кардинально хотят поменять. Стоп машина, дым в трубу, дрова в исходное. Начинаем по-новой, с новыми требованиями.

Самая засада, это составить красивый план в соответствии с теорией. 

Ещё как прокатит.

Даже при обычном плановом подходе к процессу разработки в процессе просмотра одной из промежуточных версий (или "просто так") у клиента могут возникнуть дополнительные требования. Если компания не идёт навстречу пожеланиям клиента, этот клиент редко приходит в ту же компанию с проектом второй раз.
Сам подумай. Ты клиент. Заказал фирме, чтобы тебе собрали оригинальный кузов авто. В договоре описал всё, что пришло в голову. Через месяц в голову пришло, что неплохо бы ещё сверху прилепить мигалку, а кроме зеркала заднего вида присобачить ещё и зеркало переднего вида. Приходишь к "прорабу" (хз, как они там называются в автомастерских), а он тебе - "мы на такое не договаривались, так что будет без мигалки и зеркала". И какое у тебя будет мнение по поводу этой фирмы?

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

Это сообщение отредактировал(а) mindflyer - 25.9.2007, 08:41

nornad, 
mindflyer, 
ОК, ОК.
Вопрос то не в этом.
Вопрос какие пункты включить в раздел планирование?
С разделом анализ я почти разобрался.
С третьим и четвертым проблем тоже нет.   
А вот планирование планирования вызывает трудности.   

"Лабаю" это дело в MS Project 2007. (причем на Фламандском   )

Так что уважаемое сообщество, не будем обсуждать будут меняться требования клиента или нет, просто подскажите, что
спланировать в разделе планирование.

Заранее спасибо и наилучшие пожелания.   

+1. 

+2  

Добавлено через 12 минут и 29 секунд
thomas, планирование - это то, чем ты сейчас занимаешься -- разбираешься, что включить в другие стадии плана проекта и сколько туда положить времени. как пример, можно посмотреть MSF или RUP описание первого этапа и его deliverables.

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


Просто так - не канают. Я говорю об измененниях с их стороны.


не кардинально. Просто с другими "округлостями".


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

Я бы делал так: Неделя(полторы) - "ПЛАНИРОВАНИЕ" - и пошли другие задачи.
Сейчас у нас проект. Короткий. Требования - просты как кирпич. Аналог есть. Переписать на другой технологии. К окончанию прототипа системы дорасчехлили что и как на самом деле хотелось, после двухдневного личного плотного общения с буржуинами.
Допланировали. После "расчехления" - два дня - "анализ итерации прошедшей", два дня - "планирование следующей итерации" - и пагнали!!!
Нам проце - уже всё ясно более менее, два дня на оценку задач и прикидки - доста.
Ты же - впиши "от недели" одну задачу "Планирование". Ничего толковей придумать не могу.

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

Странно.
Если я правильно поняла, то планирование - это оценка трудозатрат? На основе которых потом план составляется? Тогда включайте сюда время на то, чтобы с проектом познакомились разработчики, тестировщики и внедренцы, и сказали, сколько времени им понадобится на разработку, тестирование, внедрение. Это и будет планирование.

Только толку от такого плана - разве что зад подтереть. Потому что оценить сроки и трудозатраты можно только по ТЗ или хотя бы списку требований. А они-то на этапе анализа и появляются.

Это сообщение отредактировал(а) ida - 11.10.2007, 10:26

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

шэф пишет об agile planning, насколько я его понимаю.