Требования к проектам

Требования к формату результатов

Программа должна быть оформлена в виде "дистрибутива" (для бабушки) и инструкцией по установке (readme). По желанию: инсталлятор с установкой в "Пуск".

Пояснительная записка должна быть распечатана.

Программа, пояснительная записка и презентация записываются на CD-диск, который сдается.

Результаты работы должны быть выложены на Github:

  • исходники в репозитории;
  • дистрибутив в виде "релиза";
  • краткое описание проекта и полиморфизма в нем - в README.md;
  • руководство пользователя и руководство программиста - в wiki на Github'е (по желанию);
  • по желанию, там же весь остальной материал: описание требований, use case диаграммы, архитектура, диаграмма и описание классов.

Требования к программе

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

Должна быть написана на C++ или Java с использованием парадигмы ООП. Обязательно должен быть полиморфизм.

Требования к презентации

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

Требования к пояснительной записке

Сдается в распечатанном виде, с титульной страницей. Объем: 10 - 30 страниц. К ней прилагается CD-диск с программой, ее исходниками и электронной версией пояснительной записки.

Те, кто не совсем уверен в своей творческой фантазии, могут скачать шаблон оформления.

Коротко: обязательные компоненты:

  • Vision (1-2 с)
  • Feature set (2-8 с (с картинками))
  • Class diagrams (2-6 с (с описаниями))
  • User manual (3-10 с (с картинками))
(абсолютный минимум - 10 страниц).

1 Inception

1.1 Visionидение)

Какие проблемы/желания имеются у потенциальных пользователей данной программы?

Как с помощью данной программы вы собираетесь решить эти проблемы? (удовлетворить желания)

Короткая формулировка цели проекта.

Основные возможности программы: что она умеет и чего она не умеет (scope).

Опционально:

Какие имеются существующие решения? Чем они плохи?

Чем ваше решение будет отличаться от существующих?

Ссылки:

http://en.wikipedia.org/wiki/Vision_document

Project Overview + http://readyset.tigris.org/nonav/templates/proposal.html (Project Proposal)

http://www.scrumalliance.org/community/articles/2009/january/the-product-vision

1.2 User Requirements (URD/user needs/требования пользователей)

Цель проекта (повторяется). Видение цели разными заинтересованными сторонами (см. ниже).

Окружение (environment): где система будет установлена, из каких частей состоять (с точки зрения пользователя), какие люди с ней будут работать.

Список заинтересованных сторон (разработчики, их компания, компания-заказчик, ее сотрудники, ее клиенты, налоговая и пожарная инспекции, владельцы патентов и торговых марок и т.д.)

Список требований каждой из заинтересованных сторон к Вашей системе.

Результаты интервью с пользвателями (если таковые проводились).

User stories ("бухгалтер тетя Маша раньше 2 полных дня перед каждой выдачей зарплаты занималась подготовкой платежных ведомостей, в теперь она будет тратить по 10 минут каждый день на ввод данных в компьютер, и ведомости будут генерироваться автоматически").

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

Ссылки:

http://readyset.tigris.org/nonav/templates/user-needs.html (см. Stakeholders / Actors, User Stories, Performance and Capacity Needs)

2 Elaboration

2.1 Software Requirements Document (SRS/спецификация требований)

2.1.1 Feature Set (функциональные требования)

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

Список всех планируемых возможностей программы, разбитый по категориям.

Также желательно указать приоритеты возможностей (критическая возможность, важная, необязательная, дополнительная).

2.1.2 Use Case Suite (Use Case Diagram/диаграмма прецедентов)

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

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

Рисуем диаграммы с человечками.

2.2 Class Diagram (диаграмма классов)

Диграмма классов + текстовое описание "концепции" каждого класса.

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

Ссылки:

http://ru.wikipedia.org/wiki/Диаграмма_класов / Рэмбо. Блаха. Глава 12.2.

Ларман. Глава 10.

http://readyset.tigris.org/nonav/templates/design.html

http://ru.wikipedia.org/wiki/Диаграмма_состояний(UML) / Рэмбо. Блаха. Глава 12.3.

http://ru.wikipedia.org/wiki/Диаграмма_пакетов

http://ru.wikipedia.org/wiki/Диаграмма_последовательности / Рэмбо. Блаха. Глава 7.2.

Рэмбо. Блаха. Глава 14.4. Разбиение системы на подсистемы.

Рэмбо. Блаха. Глава 4.12. Распространенные архитектурные стили.

2.3 Activity Diagrams (диаграммы деятельности)

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

Некоторые "фичи" (см. п. 2.1.1) могут быть достаточно нетривиальны в реализации. В таких случаях нужно на диаграмме пояснить алгоритм их работы.

Ссылки:

http://ru.wikipedia.org/wiki/Диаграмма_деятельности

Рэмбо. Блаха. Глава 7.3. Модели деятельности.

3 Construction

3.1 User Manual (руководство пользователя)

Описание, что можно делать в Вашей системе разным категориям пользователей и на какие кнопки им для этого давить (с картинками!).

TIP: Consider providing both tutorial (step-by-step) and reference material. You can organize the user guide by features, by use cases, by roles, or in other ways.

3.2 Implementation Notes (или: руководство программиста)

Если Вы уволитесь с работы, надо объяснить тому, кто будет вместо Вас поддерживать данный проект, как он устроен.

Лучший способ - воспользоваться утилитой javadoc или Doxygen.

4 Transition

(отсутствует)

ĉ
Dima Litvinov,
15 мая 2014 г., 08:50
Comments