Привет!

Пытаюсь разобраться, как разрабатывать ПО. С чего начинать и чем заканчивать. Как мне кажется, надо начинать с написания технического задания.

Я выбрал такое задание: разработать сетевую карточную игру "Дурак".

Начните, пожалуйста, писать обобщённый план или наброски ТЗ. Покажите с самого начала этапы разработки и взаимодействия с заказчиком. Чуть позже я начну составлять ТЗ. Но я пока не знаю, что такое ТЗ для ПО.

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

Буду выкладывать промежуточные варианты ПО. Вы только направляйте меня. Что делать дальше?

Заранее спасибо за помощь!

P.S. Я взял в качестве заготовки пример из книги А. Крупника "Изучаем C++". В этом примере создаётся колода, перемешивается, и карты раздаются игрокам.

main.cpp

C++ (Qt)
// А.Крупник "Самоучитель по С++" 
// Листинг 7.8. Раздача карт
#include <iostream>
#include <deque>
#include <algorithm>
using namespace std;
#include "play.hpp"
#define NOFP 4
#define NOFC 9
 
int main( ) {
    player pls[NOFP];
    deck mydeck;
    mydeck.ini( );
    for ( int i = 0; i < NOFP; i++ ) {
        pls[i].ini( );
        for ( int j = 0; j < NOFC; j++ )
            pls[i].add( mydeck.get( ) );
    }
    for ( int i = 0; i < NOFP; i++ )
        pls[i].show( );
}
 

play.hpp

C++ (Qt)
// А.Крупник "Самоучитель по С++" 
// Листинг 7.5. Игральная карта
string suits[4] = {"Б ", "Ч ", "П ", "Т "};
string
cds[9] = {"6 ", "7 ", "8 ", "9 ", "10", "В ", "Д ", "К ", "Т "};
 
enum suit {
    diamonds, hearts, spades, clubs
};
 
enum cname {
    six, seven, eight, nine, ten, jack, queen, king, ace
};
 
class card {
public:
 
    void set_suit( suit s ) {
        ms_ = s;
    }
 
    void set_cn( cname c ) {
        cn_ = c;
    }
 
    string get_suit( ) {
        return suits[ms_];
    }
 
    string get_cn( ) {
        return cds[cn_];
    }
private:
    suit ms_;
    cname cn_;
};
 
// Листинг 7.6. Колода
 
class deck {
public:
 
    void ini( ) {
        card tmp;
        for ( cname i = six; i <= ace; i = static_cast<cname> (i + 1) )
            for ( suit j = diamonds; j <= clubs; j = static_cast<suit> (j + 1) ) {
                tmp.set_suit( j );
                tmp.set_cn( i );
                tdeck_.push_back( tmp );
            }
        shuffle( );
    }
 
    void shuffle( ) {
        random_shuffle( tdeck_.begin( ), tdeck_.end( ) );
    }
 
    card get( ) {
        card tmp = tdeck_.front( );
        tdeck_.pop_front( );
        return tmp;
    }
private:
    deque<card> tdeck_;
};
 
 
// Листинг 7.7. Игрок
 
class player {
public:
 
    void show( ) {
        for ( unsigned i = 0; i < hand_.size( ); i++ )
            cout << hand_[i].get_cn( ) << " ";
        cout << endl;
        for ( unsigned i = 0; i < hand_.size( ); i++ )
            cout << hand_[i].get_suit( ) << " ";
        cout << endl << endl;
    }
 
    void ini( ) {
        hand_.clear( );
    }
 
    void add( card c ) {
        hand_.push_back( c );
    }
private:
    deque<card> hand_;
};
 

Аванс берут после написания ТЗ? А то получится, что я помогу составить человеку ТЗ, детально всё опишем, потрачу своё время, а он скажет "до свидания" (или не скажет). Аванс это оплата ТЗ? Или ТЗ это настолько мелкая вещь, что много времени на него не тратят и денег тоже?

Я так понимаю, что ТЗ имеет две крайности:
1) Отсутствие ТЗ. Есть только короткое описание (одно два предложения)
2) ТЗ, которое описывает всё и по сути является рабочей программой. То есть исходник проекта - это и есть ТЗ

Неправы по всем пунктам

Аванс берётся когда вы беретесь за работу и оплата вас устраивает. Если нет ТЗ, то вы не можете сказать человеку - а вот раньше мы делали дурака консольного, а сейчас ты требуешь ГУИ'шного. Так мы не договаривались, доплачивай.

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

Ну вариации могут быть - аванс после тестового наброска.

to Igors:
Я немного побыл фрилансером, но уже успел наслушаться про "заказчиков", которые не платят аванс, а после получения работоспособной версии оспаривают решение и возвращают себе деньги.
Обычное дело.
Ты берёшься за заказ без аванса - ты мотивирован морковкой спереди, но есть нечего.
Заказчик не мотивирован никак с тобой сотрудничать, окромя желания получить программу. Потому спокойно исчезает на пару недель-месяц и потом говорит "А что это ты программу не сделал?".

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

PS Igors вы правы, но только в случае если заключен договор и имеется серьезная репутация у заказчика. А если нет репутации ни у вас, ни у заказчика... Халявные работники везде нужны.

Не будем развивать холивары Правы оба только по своему. Есть так же целый цикл статей на хабре на эту тему.

А что поддерживаете то? сформулировать сможете?
Что аванса не давать? (при предоставлении опытного образца допустим)
Что не принимать неготовый продукт?
Или что нужно не давать денег за не готовый продукт?
Или что нужно проверять продукт?

ТЗ служит как раз для проверки требований. А Igors всё уводит в сторону - ай ай ай, вдруг он обманет.
Точно так же фрилансер требует ответственности и от заказчика. А то - ай ай ай, вдруг он обманет и скажет что не нужна программа уж.

Это здравый смысл.

Возвращаясь к теме
Да ничего. Проект созданный "просто так", из любопытства и "желания спробовать" не живет. Нет того самого профессионализма. Это легко проверить, напр

Вот я заказчик. Хорошо, понимаю, красивое UI - то уже др работа. Но вот сейчас, в консольном приложении я хочу иметь возможность установить level/skills игрока-машины. Напр если он тупо бьет шестерку семеркой - человек его легко обыграет. Или напр стОит ли бить козырем или лучше его сохранить. Или вообще машинный "магистр" который видит сквозь карты.

Полагаю что этого будет достаточно. Ведь планировалась легкая прогулка (в расчете на свою молодую хорошую память), типа "пошуршать с сетью". А тут думать надо, упираться, да еще и не один день! Нееет. это не для нас, лучше создать новый блог. Или я ошибаюсь?  

А проблему откуда берут?

Само задание и определяется как проблема.

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

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