Общее описание задания

Весна, 2013 год

Введение

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

Важно, что это общение с заказчиком не ограничивается только техническими деталями проекта. Часто за заказчика нужно многое додумывать, связывать – в частности, определять его бизнес-случаи использования, связанные с сиcтемой. Последнее очень важно, поскольку, если эти use cases будут непонятыми (а часто их понять оказывается непросто!), то заказчик останется неудовлетворенным от разработанной системы, даже если она будет следовать формально согласованному ТЗ.

Open data

В настоящее время активно развиваются open data. В частности, различные государственные органы, в том числе и в России, публикуют различные данные. Более того, они поддерживают их в актуальном состоянии (последнее вкупе с первым и означает open data). И далее, государство заинтересовано в том, чтобы частные компании придумывали различные e-сервисы на основе этих данных, делегируя таким образом свои обязанности по созданию дополнительных услуг населению этим компаниям.

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

Итак, данная компания должна придумать идею сервиса, основываясь на использовании определенных данных из некоторой предметной области (точнее их приложение должно использовать эти данные). Компания также получает на вход некоторую «идею» сервиса, но в очень общем виде, скорее как наброски описаний предметной области….

Общее описание задания

Каждая группа на нашем курсе и будет такой компанией. Итоговый Award за сделанную работу – это оценка за курс и приз лучшая группа поедет осенью в ЛУТ (Лаппеенранта, Финляндия) и представит свои результаты финнам на английском языке.

Что требуется сделать? Нужен прототип, которые демонстрирует основную идею. Работающая и готовая оказывать услуги система не нужна. Поэтому в системе возможны самые разные заглушки. Система – это Web-сайт.

Но нужна еще также и сама идея, и притом разработанная. Сразу писать код – это порочно!

1.Нужно как описание идеи вашего сервиса. 3-7 страниц. Общее, речистое, красочное. Здесь и функциональность (в общем), и бизнес (как монетизировать услугу, кто ее будет покупать и почему), и интеграция с другими системами (например, соц. cети, другие известные или не очень Интернет-приложения). Помните – вам нужно получить, выиграть award!

2. Далее нужно описание видов пользователей и базовых сервисов, которые они будут получать от системы. 1 вид пользователя - 1-2 сервиса. Может быть 2-3 вида пользователей – данная модель не должна бать большой, ее не надо натягивать и высасывать из пальца. За каждым пользователем должен лежать реальный бизнес-case использования системы. Тщательно проработанный. Результат этой работы оформляется в виде диаграммы UML случаев использования. + подробный поясняющий текст. Output: документ из двух частей + use case diagram

3. Модель требований на основе Comapping и Mind Maps. Требования – это следующий шаг от идеи системы к ее разработке. Именно требования передаются разработчикам, согласуются с ними. Модели требований соответствует документ с подробным текстовым описанием этих самых, обозначенных в модели требований. Output: Mind Map +документ c требованиями

4. Архитектура системы – как она будет реализовываться: выбранная СМС, шаблон, места, будете писать/писали код руками, использованные open data, поддерживаемые браузеры и т.д. Возможно, с применением UML, но не обязательно. Output: документ + (возможно) 1-2 UML-диаграммы.

5. Прототип системы. Output: сайт, выложенный на сервер университета (в срок!).

6. Тестирование – нужно хотя бы минимальное/ Оно должно быть спланировано. Поэтому outputs: тест-план и тест-отчет – документы

Очень важно: все работы должны быть завершены до окончания семестра/ Дата окончания будет назначена/ Все не успевшие получат … более низкую оценку. Всей группой. Будут и промежуточные даты, которые также нельзя будет пропускать.

Задачи

Дата добавления: 2015-11-14