Федеральное агентство по образованию

__________________________________

Санкт-Петербургский государственный

электротехнический университет «ЛЭТИ»

____________________________________

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

по курсу «Технология разработки программного обеспечения»

Авторы: доцент кафедры МОЭВМ Самойленко В.П.,

ассистент кафедры МОЭВМ Чернокульский В.В.

e-mail - [e-mail]

Санкт-Петербург

Издательство СПбГЭТУ «ЛЭТИ»

20011 г.

1. Общие требования к курсовой работе

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

В рамках курсовой работы необходимо:

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

2. Определить требования к разрабатываемому приложению.

3. Разработать тесты, позволяющие контролировать требования.

4. Разработать графический интерфейс пользователя.

5. Согласовать требования и интерфейс с преподавателем («заказчиком»).

6. Разработать прототип приложения, реализующий его базовую функциональность.

7. Тестировать приложение.

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

2. Этапы выполнения курсовой работы

   1. Требования к программному продукту

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

• функциональные требования, которые определяют функции выполняемые приложением и зависят от потребностей пользователей и типа решаемой задачи;

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

Для спецификации требований могут быть использованы различные способы описания. Рекомендуется использовать:

• варианты использования (use-case) ‑ неформальное описание поведения системы при ее взаимодействии с внешним миром;

• истории пользователя (user story) ‑ описание требований к разрабатываемой системе, сформулированных как одно или более предложений на ежедневном или деловом языке пользователя.

Несмотря на схожесть определений, между двумя этими методами описания требований есть существенные различия:

• варианты использования имеют четкую структуру и заполняются в соответствии со специальным шаблоном;

• истории пользователя представляют собой простое словесное описание определенных функций системы.

1. Варианты использования

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

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

В процессе тестирования, описанные ранее варианты использования, позволяют проще оценить точность реализации требований пользователей и позволяют провести пошаговую проверку этих требований.

При описании вариантов использования рекомендуется придерживаться следующей структуры его оформления:

• название – это имя варианта использование, отражающее функциональность, которую он описывает;

• список ролей – здесь указывается список пользовательских ролей участвующих в варианте использования;

• предусловие ‑ описание состояния системы, при котором данный вариант использования может выполняться;

• основной поток событий ‑ пошаговое описание действий пользователя и реакции системы при нормальном их взаимодействии;

• альтернативный поток событий ‑ описание альтернативных действий пользователя и соответствующих реакций системы, отличных от “положительного” взаимодействия;

• постусловие ‑ перечисление возможных состояний системы, в которые система может перейти в конце выполнения варианта использования;

• специальные требования ‑ описание специфический условий и нефункциональных требований.

Пример

Название: Клиент заказывает товар.

Список ролей: Пользователь.

Предусловие:

(a) Пользователь зарегистрирован в системе.

(b) Пользователь произвел вход в систему.

Основной сценарий:

(a) Клиент выбирает товары и указывает их количество.

(b) Система выделяет для клиента требуемое количество каждого товара.

(c) Система получает заверенное разрешение на выписку счета.

(d) Клиент указывает место доставки.

(e) Система посылает инструкции по выбору товаров для распределения.

Альтернативный поток событий:

(a) – отсутствует.

(b) альтернативы:

i. Количество товара на складе не достаточно для выполнения заказа:

A. Клиент отменяет заказ.

ii. Товара нет на складе:

A. Клиент отменяет заказ.

(c) альтернативы:

i. Высокий кредитный риск у клиента.

(d) альтернативы:

i. Неправильное место доставки.

Постусловие:

(a) Клиент получает квитанцию с перечнем заказанных товаров и их стоимостью.

(b) В случае неудачи учетные данные клиента остаются неизменными, попытка транзакции записывается в журнал.

В приложении 1 приведен шаблон оформления варианта использования.