ПРОЕКТ

Одеський національний політехнічний університет

МЕТОДИЧНІ ВКАЗІВКИ

ДО ОПИСУ ПРОГРАМНОЇ ЧАСТИНИ

КУРСОВИХ ТА ДИПЛОМНИХ РОБОТ (ПРОЕКТІВ)

для студентів спеціальності 7.05010101

Затверджено

на засіданні кафедри

інформаційних систем

протокол № від 2012 р.

2012

Методичні вказівки до опису програмної частини курсових та дипломних робіт (проектів) для студентів спеціальності 7.05010101 /Укл.: Б.Ф.Трофимов. – Одеса: ОНПУ, 2012. – 25 с.

Укладач: Трофімов Борис Федорович,

кандидат технічних наук, ст. викладач.

Описание и цель документа

Данный документ представляет собой методические указания для студентов по оформлению материалов курсовых и дипломных работ (проектов).

Аудитория, на которую рассчитан документ — студенты, выполняющие курсовые и дипломные работы (проекты), связанные с разработкой информационных систем (ИС).

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

1. Раздел диплома 1. Актуальность. Исследование. Постановка задачи

1. Цель и задачи информационной системы

Данная секция должна содержать:

• цель ИС. Должна быть сформулирована одним или двумя емким предложениями, отвечающим на вопрос «что делает данная ИС?».

• задачи ИС. Представляют собой простое перечисление ключевых бизнес требований ИС, которые по замыслу автора, представляют бизнес-ценность ИС.

• описание входных и выходных информационных потоков ИС.

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

Данная секция должна содержать всестороннее описание всех функциональных и нефункциональных требований ИС, давать ясное и полное представление об управлении ИС, входах и выходах ИС.

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

3. Типы пользователей

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

4. Функциональные требования

Вторая часть описывает функциональные требования к дипломному приложению. Функциональные требования описывают функции системы, а также ее поведение в ответ на реакцию пользователей (или некоторого события). При разработке требований, как правило, следует избегать технических деталей реализации тех или иных требований. Более подробная информация о функциональных требованиях доступна в [2].

Каждое функциональное требование должно предоставлять как можно более полную информацию о некоторой ОДНОЙ функции дипломного приложения. Полнота описания требования определяется присутствием следующих атрибутов:

• уникальный идентификатор требования;

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

• список вовлеченных пользователей (актеры-участники);

• связанный с требованием сценарий (если есть);

• предусловия, то, что ожидается, уже имеет место.

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

Минимальные гарантии, обозначают то, что получат актеры-участники, если цель не была достигнута (например, в случае ошибки аутентификации).

Для каждого требования указываются только значимые атрибуты.

При документировании требований следует учитывать следующую информацию:

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

• упорядочивание требований по категориям. Каждая категория может иметь свой уникальный номер, являющийся префиксом для идентификатора требования;

• верифицируемость требования. Каждое требование должно обладать свойством верифицируемости, т. е. для каждого требования должна существовать объективная процедура проверки достижимости требования приложением.

1. Моделирование прецедентов

Для каждого актера связанные с ним функциональные требования необходимо представить в виде UML диаграммы прецендентов (Use cases diagram). Диаграммы и функциональные требования должны быть синхронизированы. Важно понимать, что диаграмма является иллюстрацией и не может рассматриваться полноценным носителем информации.

5. Нефункциональные требования

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

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

Каждое нефункциональное требование должно включать следующую информацию:

• уникальный идентификатор требования;

• описание требования.

Обязательным нефункциональным требованием является охват платформ, на которых планируется выполнение ИС (например, .NET4 или JRE 1.6 или Windows7/64x, MacOS X 10.7.4 или Android 2.3 или iOS 6 и т.д.).

Для Rich Client Application и Mobile Application (см. ниже) достаточно перечислить целевые платформы, на которых будет выполняться приложение.

Для WEB Application (см. ниже) необходимо указать целевую платформу, на которой ожидается выполнение самого веб-приложения, а также список поддерживаемых WEB браузеров с указанием минимальных поддерживаемых версий.

Дополнительным нефункциональным требованием является указание средств разработки ИС.

6. Критерии качества требований

К требованиям предъявляются следующие критерии качества:

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

• упорядочивание требований по категориям. Каждая категория может иметь свой уникальный номер, являющийся префиксом для идентификатора требования;

• верифицируемость требования. Каждое требование должно обладать свойством верифицируемости, т.е. для каждого требования должна существовать объективная процедура проверки достижимости требования приложением;

• понятность и ясность каждого требования;

• полнота, вместе требования должны давать полное представление о приложении и его возможностях;

• непротиворечивость, требования должны быть логичными и не вступать в противоречие друг с другом.

7. Рекомендованная литература

• Карл И. Вигерс. Разработка требований к программному обеспечению.

• Алистер Коберн. Writing Effective Use Cases

Раздел диплома 2. Проектирование ис

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

Секция состоит из следующих подсекций:

• «Алгоритмическое обеспечение ИС»;

• «Идентификация архетипа приложения»;

• «Ключевые сценарии»;

• «Архитектурные представления»;

• «Атрибуты качества»;

• «Архитектурные артефакты»;

• «Список использованных технологий».

8. Алгоритмическое обеспечение ис

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

9. Идентификация архетипа ис

Секция содержит информацию о типе приложения, который может принимать следующие значения:

1. Rich Client Application (RCA). Приложение представляет собой, как правило, классическое инсталлируемое приложение, выполняющееся на персональных компьютерах под управлением одной из платформ Windows/Linux/Mac/Qt/JVM-J2SE/.NET;

2. Mobile Application (MA). Мобильное приложение, разработанное под одну из платформ Android/iOS/J2ME/Blackberry. Приложение, как правило, выполняется на устройствах с ограниченными аппаратными ресурсами;

3. Service Application (SA). Сервисное приложение, выполняющее функции сервера приложений, и представляющее внешний интерфейс по одному из протоколов REST/SOAP/RMI и др;

4. WEB Application (WA). Классическое WEB приложение, предоставляющее WWW интерфейс посредством HTML/DHTML;

5. Rich WEB Application (RWA). Специальный тип WEB приложения, основывающееся на HTML5+JavaScript, выполняющееся, как правило, на стороне клиента и использующее его процессорное время и ресурсы. Здесь необходимо учесть, что RWA приложение довольно часто состоит из двух частей – серверное и клиентское программное обеспечение, для каждой части необходимо привести отдельное описание следующих представлений «Алгоритмическое обеспечение», «Организация слоев ИС»;

6. Mixed Application (MA). Смешанное приложение, использует комбинацию из нескольких типов. В этом случае необходимо указать все вовлеченные типы приложений. Кроме того, для каждого приложения, входящего в состав MA, необходимо указать отдельное описание следующих представлений «Алгоритмическое обеспечение», «Организация слоев ИС».