Добрый день, друзья!

Начал семинары по технологиям разработки программных продуктов. Хочу разделить студентов на группы по 5 человек и  дать им проекты. Например, книжный магазин или библиотека.

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

Вопрос в том, как именно они должны данный проект реализовать. Сейчас в голове у меня какая-то такая схема:

Этап 1.

Сначала нам надо понять какие бизнес-процессы происходят в организации:

1. определение концепции продукта;
2. сбор бизнес-требований;
3. построение диаграммы бизнес-юзкейсов.

Далее, по идее можно выделить те бизнес-юзкейсы, которые можно автоматизировать(компьютеризовать).

Этап 2.
После того, как появится некое формализованное представление о бизнес-процессах в организации(скажем, в книжном магазине), то можно начать анализировать собственно информационную систему, которая должна автоматизировать часть процессов, перевести большинство из них в виртуальную среду.

1. сбор требований(функциональные и нефункциональные);
2. построение диаграмм юзкейсов на основе требований, каждый юзкейс связать с функциональным требованием;
3. построение списка фич на основе юзкейсов;
4. рисование прототипов на основе фич или диаграмм юзкейсов(это ещё вопрос).


Мне непонятно как связать первый этап со вторым. И вообще, насколько правильно моё представление обо всём этом. 

У Вас небольшие команды. Поэтому можно имитировать нечто вроде SCRUM, т.е. вся команда отвечает за все работы, а следовательно, сначала они планируют что им нужно сделать, пишут список работ- backlog - и делают работы. Это например первая итерация. Далее планируем вторую и т.д. Ясно, что работы не сделанные на предыдущей итерации придется делать в последующих. Выделять четко этапы бизнес-анализа, сбора требований, проектирования и реализации, возможно и не следует. Пусть они будут все сразу, но с тем или иным акцентом. Сначал будет больше аналитической работы, выявление требований, потом больше проектной и конструкторской.

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

Если Вы под "концепции продукта" понимает "выделить те бизнес-юзкейсы, которые можно автоматизировать(компьютеризовать)", то как Вы делаете одно на много раньше второго?

А почему если это семинары по

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

не использовать информацию из ГОСТ 19.102-77. ЕСПД. Стадии разработки.
- Устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения

Это же программный продукт? Т.е вы собираетесь создать программный продукт для автоматизации какого либо процесса.

1 этап - назовем это ТЗ (техническое задание).
2 этап -  Проект (эскизный , технический). Как назовешь.
 Как раз на втором этапе анализируется, чтобы все требования Заказчика  были "преобразованы" в решение.
3 этап - Программирование.

Т.е как было сказано уважаемым Эдуардом

..сначала они планируют что им нужно сделать, пишут список работ- backlog - и делают работы..

.

Теперь про книжный магазин.
К примеру, есть процесс поступили книги - записали в тетрадке - покупатель приобрел - вычеркнули из тетради учета.
Можно все это перевести на автоматизированные рельсы.
С помощюь ПО , которое реализует данные операции.
Т.е. получается поступили - занесли в компьютер (БД программы) - +поиск для покупателя - пометка в системе что купили.

И еще, прошу уточнить Ваш вопрос  (

...как именно они должны данный проект реализовать...

)
Получается Вам нужен универсальный алгоритм на выполнение любого проекта?
Или способ (способыы) сравнить требования ТЗ и описание проекта?

Если Вы под "концепции продукта" понимает "выделить те бизнес-юзкейсы, которые можно автоматизировать(компьютеризовать)", то как Вы делаете одно на много раньше второго?

Под концепцией понимается определение целей продукта, обзор конкурентов, сроки, бюджеты и т.д.

А почему если это семинары по не использовать информацию из ГОСТ 19.102-77. ЕСПД. Стадии разработки.
- Устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения

Это же программный продукт? Т.е вы собираетесь создать программный продукт для автоматизации какого либо процесса.

Да, но как мне кажется использовать ГОСТы слишком сложно для них. Нужно действовать по упрощённой схеме.

Теперь про книжный магазин.
К примеру, есть процесс поступили книги - записали в тетрадке - покупатель приобрел - вычеркнули из тетради учета.
Можно все это перевести на автоматизированные рельсы.
С помощюь ПО , которое реализует данные операции.
Т.е. получается поступили - занесли в компьютер (БД программы) - +поиск для покупателя - пометка в системе что купили.

Это-то понятно. Вопрос в том, стоит ли для начала описывать бизнес-процессы конторы или же сразу приступить к сбору требований к продукту.

И еще, прошу уточнить Ваш вопрос  ()
Получается Вам нужен универсальный алгоритм на выполнение любого проекта?
Или способ (способыы) сравнить требования ТЗ и описание проекта?

Смотрите выше.

Это-то понятно. Вопрос в том, стоит ли для начала описывать бизнес-процессы конторы или же сразу приступить к сбору требований к продукту.

А что означает сразу приступить к сбору требований? Кто носитель требований у Вас? Вы сами? Конкретная организация?  Или некая умозрительная абстракция?

Если студенты будут придумывать для себя требования, то не все ли равно придумать сначала БП, а потом придумать требования? Все равно будет нечто далекое от действительности

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

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

А что означает сразу приступить к сбору требований? Кто носитель требований у Вас? Вы сами? Конкретная организация?  Или некая умозрительная абстракция?

Если студенты будут придумывать для себя требования, то не все ли равно придумать сначала БП, а потом придумать требования? Все равно будет нечто далекое от действительности

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

Носитель требований - я. Я выступаю как в роли заказчика, так и в роли product manager'a.

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

1. как вы будете разрешать проблемы связанные с недостаточностью информации
2. как вам следует реагировать, если студент интерпретирует некоторую недостающую информацию своим способом
3. какова степень свободы студента в рамках придумывания БП и требований к самому себе
4. если вы позволяете это, то как студент должен доказать обоснованность и т.п.

1. Я буду исчерпывающим источником
2. Буду проверять её на валидность и принимать меры(поощрение, наказание).
3. Главное, чтобы они удовлетворяли меня в некоторых рамках.
4. Только здравый смысл, оптимальность и удобство.

Спасибо за Ваш ответ, Эдуард.

Носитель требований - я. Я выступаю как в роли заказчика, так и в роли product manager'a.

Это хорошо

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

Мне почти никогда не удается заставить студентов узнавать тонкости БП и требований у заказчика, т.е. меня

1. Я буду исчерпывающим источником

Это потребует от вас мужеста и сил

2. Буду проверять её на валидность и принимать меры(поощрение, наказание).

Установите для себя критерии, иначе постепенно в силу многих причин ваши критерия будут усиливаться, студенты будут в растерянности

3. Главное, чтобы они удовлетворяли меня в некоторых рамках.

Вот вот -эти рамки для себя определите Но будьте готовы, что Вы тоже ошибаетесь!

4. Только здравый смысл, оптимальность и удобство.

Это не измеримые критерии, а следовательно плохие Здравый смыл он у всех разный, оптимальность тоже, а уж удобство вообще

Под концепцией понимается определение целей продукта, обзор конкурентов, сроки, бюджеты и т.д.

Как можно понять цели продукта (Системы), а тем более сроки, бюджеты и т.д, когда даже не понятны БП?? Какая-то каша у вас ...

для начала литературой надо обзавестись