Этапы разработки ПО. Научите, как работает профессионал.

[Igors]

Android, сетевой дурак, школьники на уроках играют через wi-fi/bluetooth. Монетизация через показ рекламы или покупка за 50 центов отключалки рекламы.

Вот, уже "теплее". Но тогда почему проект начинается с какого-то задрипаного примера, а не с изучения аналогов, платформ, конкурентов? Где "features list", чем собрались завоевывать рынок?

И тут начинается типа "ну он же маленький еще, только учитЬся". И 8Observer8 охотно подхватывает, мол, да, это же "для примера", "фикция".  Ну так ведь и результат такая же "фикция", смысла в таких цацках-пецках никакого. Как можно научиться программировать если все время жалеть себя и отлынивать от работы под предлогом "я только учуся"? Зато как охотно впитывает витиеватый сынтаксыс! 

[Old]

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

И да синтаксис витиеватый только для вас, но с этим уже ничего не поделать.

[Igors]

А это я написал для вас, вы же не могли представить, как на этом можно заработать.

Ну а чего же Вы сами-то не пытаетесь? Наверное понимаете что труда придется вложить немало, а вот отдача сомнительна. Так чем же Ваши выводы отличаются от моих? 

Да, согласен с Вами, пусть ТС вообще ХОТЬ ЧТО-ТО напишет. О каких-то там "этапах", "профессионализме" говорить явно рано. Но вот странное дело - писать (в смысле программировать) он не хочет. А хочет "выучить". Но, как ни странно, чем больше заучено - тем хуже результат.

[Old]

Ну а чего же Вы сами-то не пытаетесь? Наверное понимаете что труда придется вложить немало, а вот отдача сомнительна. Так чем же Ваши выводы отличаются от моих? 

Почему вы так думаете? Я задумываюсь о выходе на этот рынок и задумываюсь все больше и больше.
То, что я не делаю это с наскока... ну так возраст уже не тот. Я изучаю рынок, смотрю, в общем учусь...
Так что, все будет, идеи есть.

Но вот странное дело - писать (в смысле программировать) он не хочет.

Ну так бурча на него, вы все равно не заставите его программировать.

[Hrundel]

Old, вы не совсем правы, на мой взгляд. Тема действительно об этапах разработки. А он их не выполняет.

И да синтаксис витиеватый только для вас, но с этим уже ничего не поделать.

Нет. Для меня тоже витееватый. Чем проще написано - тем меньше ошибок!!!

[Old]

Так в чем моя не правота? Что вы предлагает делать, что бы он соблюдал?

[Hrundel]

Ну, пусть напишет техническую задачу, и спецификацию. А потом попробует жестко ей следовать. Тогда не будет спонтанного развития проекта, и он сможет понять, что он не учитывал в самом начале.
В одном из сообщений ТС пишет, что даже не подумал о том, что программа должна отслеживать правила игры. То есть, он берется за имплементацию, даже не имея приблизительного плана в голове. А, значит, ему нужно составить для начала четкий план на бумаге. С чего начать? Чем закончить?

Например, как в типовых проектах.

(UseCase Nr 1)
1. Программа должна хранить и читать данные.
      Значит, сначала пишу класс со структурой данных,
      потом пишу интерфейс ввода данных,
      потом пишу сериализацию данных.  

(UseCase Nr 2)
2. Програма должна отображать данные
     Пишу интерфейс отображения данных.
     потом пишу GUI под интерфейс.
     *(можно сначала GUI потом интерфейс, если знаешь какие данные будут выводиться)

и т.д. и т.п.

Но для начала нужно все эти Use Cases на бумаге написать и лучше всего в виде UML диаграммы

0. Начать сетевой сеанс
1. Пользователь залогинен
2. Пользователь включен в игру
3. Принять ставку
4. Раздать карты и начать игру
5. Передать ход игроку
6. Получить карту от игрока
7. Проверить правила
8. Очистить игровой стол
9. Сменить счет
10. Определить победителя
11. Перевести выигрыш на счет победителя
12. Предложить новую игру
13. Разлогинить пользователя
14. Закончить сетевой сеанс

А дальше детально описать, что необходимо учесть и написать, чтобы каждый из Use Cases выполнил свою работу. Это и будет ТЗ и спецификация. ТЗ - грубое описание. Спецификация - очень подробное, пошаговое описание с примерами GUI из прототипа или набросков от руки.

Спонтанное развитие проекта всегда приводит к непредсказуемым, трудно определяемым ошибкам.

[Hrundel]

Кстати, забыл сказать, что есть два пути:
от частного к общему *(как я описал выше)
и от общего к частному

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

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

[Bepec]

Второй метод работает с идеальным заказчиком и идеальной архитектурой. Т.е. в 99% случай первый

[Hrundel]

Второй метод работает с идеальным заказчиком и идеальной архитектурой. Т.е. в 99% случай первый

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

[Old]

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

Потому что подготовкой ТЗ будет заниматься отдел по работе с клиентами в контакте с отделом разработки ТЗ, под контролем и с непосредственным участием группы архитекторов с участием ведущих программистов.

[8Observer8]

Потому что подготовкой ТЗ будет заниматься отдел по работе с клиентами в контакте с отделом разработки ТЗ, под контролем и с непосредственным участием группы архитекторов с участием ведущих программистов.

Мне придётся сначала самому научиться писать ТЗ. Хочу быть фрилансером

Я расписал этапы разработки. Пока застрял на первом:

- на примере карточной игры, создать подробное ТЗ

- создать тесты (для демонстрации основной функциональности методов классов, в том числе демонстрация с помощью тестов защиты методов от "дурака")

- реализовать приложение

- создать документацию с помощью Doxygen

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

А вообще все гораздо проще - есть ли хоть какие-то шансы на этом что-то заработать? Лично я их в упор не вижу. Ну значит и пример этот столь же бесполезен как и книжка из которой он списан  

Я долго думал, что потом дальше делать. Вот какие мысли пришли:

Дополнительный заработок:
- Либо создать красивый сайт посвящённый приложению, выложить в свободный доступ исполняемый файл, исходный код, тесты и документацию. Расположить кнопку "Donate".
- Либо создать красивый сайт посвящённый приложению, организовать покупку приложения пользователями.

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

[OKTA]

1. Совершенство недостижимо 
2. Фриланс не любит ленивых
3. Даже для собственных разработок, сайтов и т.д. нужны $ 

А вообще, зачем мусолить и без того замусоленную тему? Чему учиться в написании ТЗ? ТЗ должно быть таким, как ноты произведения. Если ноты все перед тобой - играешь по ним и не задумываешься, а если каких-то нот нет, то все, провал и импровизация, которая успешна только при наличии большого опыта.
Хочешь научиться писать ТЗ? Научись расписывать любую задачу до мельчайших деталей и научишься.
Простой пример из жизни. План "как сходить в туалет"
1. Захотелось
2. Определил как далеко до туалета
3. Нашел туалет
4. определил платный он или нет
5. Пробрался внутрь
6. Определил наличие туалетной бумаги -
7. Закрылся (нет замка - забарикодировался)
8. Определился с ширинкой - на молнии или на пуговицах
9. Снял штаны
10. Сделал дела
11. использовал бумагу
12. одел штаны
13. вышел из туалета
14. помыл руки, если есть где
15. mission accomplished

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

[OKTA]

Да, и пример из жизни, связанный с силиконовой долиной и ТЗ)))
Есть там одна фирма очень крупная.. Одно из подразделений этой фирмы занимается разработкой некоего SDK. Сделали, все проверили, выложили в интернет и только через год поняли, что одна  из библиотек внутри SDK оказалось пустой - прописаны только функции без реализации 
А сколько человек попробовало и положило болт, увидев, что не работает - неизвестно  Спасибо первому, кто додумался сказать о том, что почему-то странно себя ведет библиотека  Вот так вот бывает с ТЗ, где нет пункта проверить релизную версию, выкладываемую в интернет 

[8Observer8]

1. Совершенство недостижимо 

К нему надо стремиться Иначе деградация и смерть. Хорошо, что недостижимо. Можно бесконечно развиваться

2. Фриланс не любит ленивых

Нас ленивых никто не любит ну, кроме родителей...

3. Даже для собственных разработок, сайтов и т.д. нужны $ 

Какие деньги? Есть бесплатные хостинги, даже без рекламы: http://www.freewebhostingarea.com/

А методики написания ТЗ - это уже второй вопрос.

Вот об этом и речь. Мне нужна методика составления ТЗ, на примере карточной игры. Составлю, а потом перейду к этапу разработки.