Описание и анализ проекта. Что да как?

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

Теми: архітектура, проєкт

Ctrl + Enter

Denis Kuzin Сhief software engineer в EPAM 06.09.2011 20:33

Мы обычно действуем следующим образом:
1. Список функций — общий список со всеми функциями системы. Он не фиксируется и дополняется по мере надобности уже в ходе работы над проектом. (доступ общий для всех, если всех сильно много, то периодически просматривается и режется откровенный творческий бред)
2. Планирование первого выпуска. Из первого листа технично вырезаем минимальный набор функций позволяющий получить выполняющую свои задачи систему без наворотов и излишеств. Фактически это первая бета. Набор функций стараемся ограничить месячным объемом работы (если за это время не получилось чего-то рабочего мотивация начинает падать и резко, что в свою очередь сильно гасит скорость работы)
3. На базе второго пункта включается разработчик интерфейса (попутно неплохо если у него перед глазами лежит первый лист). Он набрасывает блочную структуру без отрисовки и визуализации (тупо на листе бумаги блоками).
4. В тоже время что и пункт 3 с тем же набором данных готовится БД.
5. После 3,4 БД шлифуется и если необходимо проверяются запросы, возникшие вопросы и так далее на мусорных данных. Здесь же рисуется интерфейс.
6. Собственно формирование тудушек, написание кода, рисование, верстка в общем создаем первичный продукт
7. Тестирование, допиливание и так далее.
8. Релиз, раздача слонов, фонтаны радости и пива.

9. Идем на шаг 2 и строим следующую итерацию.

ps Пункт 1 пополняется по ходу работы. При переходе к следующей итерации вместо разработки и рисования подразумевается допилка и модернизация имеющегося.

Відповісти

Підтримати

Andy 04.09.2011 06:39

Подскажите книги какие по этой тематике.

Scott Berkun. Making Things Happen. Книга в принципе про проект-менеджмент, и немного суховата, но пара глав посвящена именно этой тематике — анализу, работе с требованиями и дизайну, достаточно полно изложено что, когда и зачем.

AGS 03.09.2011 22:25

начинай с требований. Вигерс Карл Разработка требований к программному обеспечению. 575 стр из них воды примерно 70%. зато все в месте. правда я прочитал только первую часть.

Mykolai Miasnikov Software Developer 03.09.2011 09:28

+1 Это большая тема. Термины для гугления:
RUP
ICONIX

управление требованиями в Agile

Ruslan Shevchenko Researcher 02.09.2011 22:26

Ну это большая тема .... начать наверное лучше всего с чтения Alistair_Cockburn — Writing Effective Use-Cases (есть русский перевод)

anonymous 02.09.2011 12:10

Может проще заказать разработку техзадания с добавлением analytic stages ?

Andrii Muzychuk Salesforce Engineer в InCountry 02.09.2011 21:24

Нет не проще. Я сам себе напишу ТЗ и буду по нему идти. Если найду помощников, то они по этому ТЗ должны будут легко всё делать.

И вообще, я хочу сам поучиться это делать.

anonymous 02.09.2011 22:21

Тогда и флаг в руки, и непонятно тогда к чему сей топик. Если пишете сами задание — то однозначно знаете как это делать. Если не знаете — платите людям которые не одну собаку сьели. А на пальцах или в форумах таким вещам не обучают, это к бабушке не ходи ...

Andrii Muzychuk

Andrii Muzychuk Salesforce Engineer в InCountry 03.09.2011 04:30

Выше я изложил суть данной темы.
Я и не просил обучить. Я хочу чтоб меня направили в нужное русло.

Вооот. А каким людям надо платить? Как узнать, что они не одну собаку съели именно в том, что мне надо? Что мне надо? ;-)

anonymous 03.09.2011 09:14

Вас уже как-бы направили, перечитайте внимательно треды еще раз ;)

Andrii Muzychuk Salesforce Engineer в InCountry 03.09.2011 21:03

А вы на других не смотрите ;-) За себя отвечайте ;-) Ничего не можете добавить? Зачем что-то писать не по теме? Я и так вижу, что мне поотвечали и я это принял к сведению. И даже это отметил «поддержкой». Так что я за своей темой слежу.

Alex Fruzenshtein Director of Engineering в VidIQ 02.09.2011 10:22

Есть хороший сайт для таких вопросов: lmgtfy.com

Будьте сознательней

Andrii Muzychuk Salesforce Engineer в InCountry 02.09.2011 21:26

Это замечательный сайт. Мне он не интересен в данном вопросе. Мне хочется обсуждения и как можно большего количества мнений.

reality_hacker 02.09.2011 07:11

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

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

Архитектуру обычно описывают в техническом дизайне, который описывает систему из различных ракурсов: какие слои есть у системы, как они общаются, по каким протоколам или апи, диаграмму классов каждого слоя, с коротким описанием алгоритма кто че делает, диаграму взаимодействия основных компонентов/классов, схему БД, диаграму деплоймента, и требования к выч ресурсам, требования к потенциальным нагрузкам и как эт будет тестироваться, секьюрити аспекты. В инете можно найти шаблоны этого дела. Можно забить и написать эссе в произвольной форме выделив основные моменты. Можно понадеятся на итеративный аджайл рефакторинг tdd подход и хорошее качество откоментированного кода, который сам расскажет все сам за себя.

Серебрянных пуль и универсальных рецептов думаю не существует.