Russian Qt Forum
Ноябрь 27, 2024, 06:04 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1] 2 3 ... 6   Вниз
  Печать  
Автор Тема: Этапы разработки ПО. Научите, как работает профессионал.  (Прочитано 39455 раз)
8Observer8
Гость
« : Апрель 19, 2014, 09:28 »

Привет!

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

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

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

Заказчик - выдуманный персонаж. Пусть у него нет жёстких требований и для него главное для начала, чтобы была такая игра и его устроит консольная версия. А потом заказчик будет менять требования, ну скажем, он захочет видеть не консольную программу, а с 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_;
};
 
Записан
Bepec
Гость
« Ответ #1 : Апрель 19, 2014, 09:52 »

Начинаем с взятия аванса.
После пункта "Решил перейти на ГУИ" требуем повышение оплаты (ведь раньше договаривались на консольную версию).
Если повышает, работаем. Если нет, говорим до свидания.
 
В вашем случае надо компилятором работать по превращению "бла бла" в ТЗ Улыбающийся Тоже нервная работа, но мне нравится Улыбающийся
Записан
8Observer8
Гость
« Ответ #2 : Апрель 19, 2014, 10:03 »

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

Я так понимаю, что ТЗ имеет две крайности:
1) Отсутствие ТЗ. Есть только короткое описание (одно два предложения)
2) ТЗ, которое описывает всё и по сути является рабочей программой. То есть исходник проекта - это и есть ТЗ
« Последнее редактирование: Апрель 19, 2014, 10:05 от 8Observer8 » Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #3 : Апрель 19, 2014, 10:36 »

Начинаем с взятия аванса.
Да кто ж Вам его даст  Непонимающий  Улыбающийся

После пункта "Решил перейти на ГУИ" требуем повышение оплаты (ведь раньше договаривались на консольную версию).
Если повышает, работаем. Если нет, говорим до свидания.
Эти "мячты" не имеют ничего общего с реальностью. Не надо мнить что Вы можете "требовать", "говорить до свидания" и.т.п. Пока Вы не заработали авторитет в глазах заказчика
Цитировать
ты никто и зовут тебя никак


Стандартный порядок на фрилансерских сайтах: заказчик переводит деньги на сайт и затем постит заказ. Это правильно т.к. иначе найдется масса желающих морочить голову мнимыми/тестовыми заданиями. В случае если исполнителя не найдется (или заказ не выполнен) деньги заказчику возвращаются. Фрилансеры на сайте подписываются, заказчик выбирает одного, "по рукам". ТЗ заказчика должно быть полностью выполнено в заданный срок. Если нет - исполнитель ничего не получит. Заказчик может поощрить оплатив сделанный этап, но только если захочет. Оба могут аппелировать в арбитраж, но это так, облегчить душу "сказав ему кто он такой"  Улыбающийся
Записан
Bepec
Гость
« Ответ #4 : Апрель 19, 2014, 10:41 »

Неправы по всем пунктам Улыбающийся

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

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

Код:
З  - хочу игру. 
Вы - давайте ТЗ.
З  - Нет тз, я просто хочу карточную игру.
Вы - Тогда цена выше и аванс сразу.
З  - А почему?
Вы - Потому что хрен знает чего вы хотите в конце.
З  - А если я тебе заплачу чтоб ты тз сделал?
Вы - Цена ещё повышается, ТЗ делать это тоже работа, причем нервная.
З  - Ну ладно, бум делать.
Вы - Аванс!
З - вот будет игра, тогда будут деньги.
Вы - до свидания.
Ну вариации могут быть - аванс после тестового наброска.

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

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

PS Igors вы правы, но только в случае если заключен договор и имеется серьезная репутация у заказчика. А если нет репутации ни у вас, ни у заказчика... Халявные работники везде нужны.
« Последнее редактирование: Апрель 19, 2014, 10:44 от Bepec » Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #5 : Апрель 19, 2014, 11:51 »

Я немного побыл фрилансером, но уже успел наслушаться про "заказчиков", которые не платят аванс, а после получения работоспособной версии оспаривают решение и возвращают себе деньги.
Обычное дело.
Еще одно популярное заблуждение, "вот видите, получил работоспособную версию - и не заплатил!!" (вот скотина какая).

От этой глупости избавитесь моментально, побывав всего лишь раз в роли заказчика (пусть для Вас этот вариант "гипотетический"). Техника примитивна до боли: вываливается "нечто", зачастую не имеющее ничего общего с ТЗ. Иногда это просто старый код с другой работы. В лучшем случае сделанное "как хочется", пофиг то ТЗ. При этом изо всех сил фиксируется момент "ага, заказчик ПОЛУЧИЛ" (неважно что). И дальше начинается протяжный вой "КИИИНУЛИ!!!!".

Работа недоделанная всего на 5% - уже серьезная проблема. Надо вникать в чужой код, фиксить, начинает клинить и.т.п. А если 15-20% то обычно проще начать с нуля. Так что заказчик ничего не получил и никак не "использовал" невинного программиста-жертву  Улыбающийся

Ты берёшься за заказ с авансом - ты мотивирован деньгами + морковкой спереди. Можно покушать.
Заказчик уже никуда не исчезнет на пару недель, ибо он уже вложил деньги + мотивация морковкой сзади (деньги заплатил уже, жаба задушит).
Цитировать
Ну съесть он бы конечно съел - да только кто ж ему даст?
Улыбающийся
Записан
Bepec
Гость
« Ответ #6 : Апрель 19, 2014, 11:57 »

Не будем развивать холивары Улыбающийся Правы оба только по своему. Есть так же целый цикл статей на хабре на эту тему.
Записан
Alex Custov
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2063


Просмотр профиля
« Ответ #7 : Апрель 19, 2014, 13:06 »

От этой глупости избавитесь моментально, побывав всего лишь раз в роли заказчика (пусть для Вас этот вариант "гипотетический"). Техника примитивна до боли: вываливается "нечто", зачастую не имеющее ничего общего с ТЗ. Иногда это просто старый код с другой работы. В лучшем случае сделанное "как хочется", пофиг то ТЗ. При этом изо всех сил фиксируется момент "ага, заказчик ПОЛУЧИЛ" (неважно что). И дальше начинается протяжный вой "КИИИНУЛИ!!!!".

Поддерживаю. Иногда работник работает на отъеб^W^W спустя рукава, ничего не тестирует, а потом думает, что его обманули. Это нужно сразу пресечь. Либо делать нормально, либо никак.
Записан
Bepec
Гость
« Ответ #8 : Апрель 19, 2014, 13:19 »

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

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

Это здравый смысл.
Записан
8Observer8
Гость
« Ответ #9 : Апрель 19, 2014, 14:00 »

Всем большое спасибо за информацию. По-моему, все по-своему правы Улыбающийся

Я начал сочинять примерный сценарий развития событий. Буду сам выступать в роли заказчика и разработчика. Подкидывайте, пожалуйста, пищу для размышлений. А я буду фантазировать дальше. Вот такое получилось ТЗ. Достаточно для начала разработки? Может типичный заказчик предоставляет больше информации?

Заказчик - З
Разработчик - Р

Р: Здравствуйте! Готов взяться за выполнение задания. Вышлите, пожалуйста, ТЗ
З: Здравствуйте!

Техническое задание

Название приложения: Fool

Краткое описание.
Карточная сетевая игра "Дурак"

Тип приложения.
Клиент-серверное, консольное.

Детальное описание.
Один из игроков запускает приложение. Приложение запрашивает у пользователя свой тип: сервер или клиент. Пользователь сервера сообщает остальным игрокам IP адрес и номер порта. К серверу могут подсоединиться до пяти игроков.

P.S. После того, как разработчик получил ТЗ, что он дальше делает? Является ли правилом хорошего тона начать уточнять детали? Может написать своё (дополненное) ТЗ, а не заваливать вопросами? И спросить: устраивает?
« Последнее редактирование: Апрель 19, 2014, 14:04 от 8Observer8 » Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #10 : Апрель 19, 2014, 14:11 »

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

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

Полагаю что этого будет достаточно. Ведь планировалась легкая прогулка (в расчете на свою молодую хорошую память), типа "пошуршать с сетью". А тут думать надо, упираться, да еще и не один день! Нееет. это не для нас, лучше создать новый блог. Или я ошибаюсь?  Улыбающийся
Записан
Hrundel
Гость
« Ответ #11 : Апрель 19, 2014, 14:43 »

Не заню как у вас - у нас учат так:

1. Анализ проблемы
2. Описание UseCases
3. Разработка технических условий на базе UseCases
4. Разработка спецификации  на базе технических условий
4а. Желательно сделать прототип и утвердить у заказчика, что не всегда возможно. Вместо прототипа можно утвердить GUI для всех или почти всех окон.
5. Имплементирование с параллельной разработкой архитектуры, или последовательно: архитектура, потом имплементирование.
6. Тестирование
7. Документация и справка.
8. Сдача
9. Поддержка и сервис

На каждой стадии необходимо беседовать с заказчиком.

Проект-менеджмент отдельная тема.

1. Составить калькуляцию времени и стоимости.
2. Составить план работы и утвердить с заказчиком.
3. Составить календарь встреч с заказчиком и утвердить.

и т.д.  и  т.п.
« Последнее редактирование: Апрель 19, 2014, 14:59 от Hrundel » Записан
Bepec
Гость
« Ответ #12 : Апрель 19, 2014, 14:51 »

А проблему откуда берут?
Записан
8Observer8
Гость
« Ответ #13 : Апрель 19, 2014, 14:53 »

Hrundel, спасибо огромное! Я позже проанализирую каждый этап и попробую применить к своему проекту. Выглядит довольно универсально Улыбающийся

Возвращаясь к теме
Буду выкладывать промежуточные варианты ПО. Вы только направляйте меня. Что делать дальше?
Да ничего. Проект созданный "просто так", из любопытства и "желания спробовать" не живет. Нет того самого профессионализма.
Есть же какие-то традиционные этапы разработки? "Что делать дальше?" - это значит в какую сторону копать, откуда танцевать, какой следующий шаг?

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

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

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

Поддерживаю. Иногда работник работает на отъеб^W^W спустя рукава, ничего не тестирует, а потом думает, что его обманули. Это нужно сразу пресечь. Либо делать нормально, либо никак.
Вы имеете ввиду модульное тестирование? Или ручное (кнопки потыкать, неправильные значения повводить, чтобы проверить защиту от дурака)? Если модульное, то заказчику Вы отдаёте тесты, чтобы он мог у себя "погонять"? Или тесты Вы пишите для себя? Или достаточно просто "потыкать"?
Записан
Hrundel
Гость
« Ответ #14 : Апрель 19, 2014, 14:55 »

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

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

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

То есть - разработчик, еще в самом начале проекта, должен точно представлять с каким кругом проблем он сталкнется.
« Последнее редактирование: Апрель 19, 2014, 15:01 от Hrundel » Записан
Страниц: [1] 2 3 ... 6   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.106 секунд. Запросов: 23.