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

[Bepec]

Угум. У вас дробление задачи идет. Тоже необходимая вещь

[Hrundel]

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

[8Observer8]

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

В моей задаче этой проблемы у разработчика нет, так как заказчику нужна сетевая игра. Ботов в ТЗ нет А вот какие будут проблемы - это с опытом приходит. Как я могу предвидеть с какими проблемами столкнусь в данном проекте?

[Hrundel]

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

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

и прочее, прочее.

Все это нужно протоколировать в логе проекта, спецификациях и в UseCases.

Как я могу предвидеть с какими проблемами столкнусь в данном проекте?

Если не можете предвидеть - значит не сможете составить спецификацию. Без нее серьезный заказчик не будет с вами продолжать проект.

А вот какие будут проблемы - это с опытом приходит.

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

[Bepec]

to Hrundel - дёргался, дёргаюсь и буду дёргаться. Увы, так устроен человек

[Hrundel]

to Hrundel - дёргался, дёргаюсь и буду дёргаться. Увы, так устроен человек

Да я понимаю - сам такой  

[Bepec]

Ссылочку приведите аль ещё как направьте меня на путь изучения данной методике. И чтоб именно баварского университета
PS я серьёзно ^.^ Полезно знать много.

[Igors]

В моей задаче этой проблемы у разработчика нет, так как заказчику нужна сетевая игра. Ботов в ТЗ нет А вот какие будут проблемы - это с опытом приходит. Как я могу предвидеть с какими проблемами столкнусь в данном проекте?

Что-то я не понял, как/куда Вы "проецируетесь" Вы сами себе разработали и утвердили ТЗ? Такой вариант возможен, но это другая модель: "выпуск продукта в надежде что его купят", к работе с конкретным заказчиком это отношения не имеет. И до этого варианта далеко как до небес.

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

С этой точки зрения Вы избираете наихудший вариант - заявляете что "ботов в игре нет". Ну на нет и суда нет, заказчику (мне) остается только удалиться. На мне Вы ничего не заработали.

[8Observer8]

Что-то я не понял, как/куда Вы "проецируетесь" Вы сами себе разработали и утвердили ТЗ? Такой вариант возможен, но это другая модель: "выпуск продукта в надежде что его купят", к работе с конкретным заказчиком это отношения не имеет. И до этого варианта далеко как до небес.

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

Вы сами себе разработали и утвердили ТЗ?

Я сделал только набросок (см. Ответ #9)

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

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

P.S. Это всего лишь мои фантазии. Я, на самом деле, не знаю, как это в реальности.

[Hrundel]

Что значит без бота? Уже одно то, что програма пользуется некиим генератором для случайной раздачи карт - это уже бот.
Кроме того, ваша програма обязана следить за правилами в игре. То есть некиий искусственный интелект должен присутствовать обязательно. Ходы, конечно, будут делать игроки, но это не значит, что ваша програма должна остаться без AI.
А сделать виртуального игрока, там будет, уже, не проблема. Просто, ему нужно будет включить алгоритм анализа лучшего хода. Вот вам и весь бот.
Опять таки, а что если в сети никого нет. Например, два дня. Сайт, допустим, еще не раскручен. Что делать? Не играть? Значит, заказчик потерял деньги. Клиент не играл и ушел. А мог бы сыграть на доллар другой.

[8Observer8]

В программе используется shuffle для deque<card> deck

А вот про правила я не подумал Спасибо! Будем считать, что "разработчик" и "заказчик" взяли таймаут

В самом первом моём сообщении этой темы есть пример, файл play.h В этом файле располагаются три класса: Card (Карта), Deck (Колода) и Player (Игрок). Как Вы думаете, оставить эти классы в файле play.h или раскидать по разным файлам?

[Hrundel]

Наверное в зависимости от того сколько в них методов. Если обозримость не потеряете - оставляйте в одном файле. Это уже дело вкуса и внутренней организации.

[8Observer8]

Спасибо! Пока оставлю в одном файле

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

Вполне логично Я думаю, что разработчику и заказчику надо работать очень тесно, чтобы требования можно было вносить в проект. То что Вы написали, для меня было совсем неочевидно. Да, может и для заказчика тоже. Заказчики же так же бывают мало опытные Проект уже начался и вдруг заказчику пришла отличная мысль! При тесном взаимодействии (обратной связи) все новые требования будут вноситься с наименьшими затратами для обоих

P.S. Опять же, не знаю, как на практике общаются заказчик и разбработчик. В типичной ситуации, возможно ли взаимодействие с обратной связью? Или они общаются только в начале и в конце проекта? Принята же какая-то культура? Я  про фриланс.

[Igors]

Хочу смоделировать ситуацию взаимодействия заказчика и разработчика.

Ага, значит я все-таки отвечаю в тему  

Этот пример - всего лишь фикция. Для упрощения - не буду углубляться в разработку бота и красивого интерфейса. Если мне удастся сформировать чёткие требования для этого упрощённого примера, то я смогу продвинуться дальше. Если я буду усложнять задачу, то не смогу довести её до конца. Пусть мой заказчик получает промежуточные версии, которыми он сразу начнёт пользоваться.

Конечно было бы прекрасно, просто замечательно если бы заказчик удовольствовался именно и только тем что Вы предложили. Но у меня года так с 1995-го такого еще не случалось. Выдвигает (ах паразит) свои требования - и приходится потеть их выполняя. А другими способами зарабатывания денег я не владею.

Если я буду усложнять задачу, то не смогу довести её до конца.

Вот этим и отличается любитель (пусть безумно талантливый) от профи (пусть явно тупого). Один делает "что хочет", другой "за что платят".

[Hrundel]

P.S. Опять же, не знаю, как на практике общаются заказчик и разбработчик. В типичной ситуации, возможно ли взаимодействие с обратной связью? Или они общаются только в начале и в конце проекта? Принята же какая-то культура? Я  про фриланс.

Безконечные звонки друг - другу и емайлы. А иногда и по нескольку раз на день. В игрушках наверное не так интенсивно. Там фазы чуть длиннее, а в остальных проектах очень интенсивное общение  с заказчиком.