Студент фит нгу > группа 5304 Версия 0 - davaiknam.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Название работы Кол-во страниц Размер
Теория систем и структурный подход к моделированию 3 556.2kb.
Программа проведения в ннц со ран мероприятий Франко-Сибирского научно-образовательного... 1 64.69kb.
Программа кандидата на должность ректора нгу аржанникова Андрея Васильевича 1 307.8kb.
Hsm rg7xx0 Новая базовая версия Firmware. Версия 0 0 1 65.47kb.
Лабораторная работа №1 «Изучение электронного осциллографа» Студент... 1 146.45kb.
Реферат типология предпринимательства студент: Егоров. А. А. 4 529.63kb.
Отчет по преддипломной практике студент группа ит москва 200 г 1 53.39kb.
Лабораторная работа по теме: общая характеристика системы windows... 1 52.46kb.
Кузнецова Екатерина Викторовна студент группа эо-3-09 1 87.01kb.
Подготовил: студент 3-го курса 1 группа фэапп голубев С. H 1 82.43kb.
Кжиштоф Яссем. Wspólny Język 2010 (Standard+ & Pro ) 18 4239.08kb.
Полная параллельная поддержка для систем планирования 1 35.35kb.
Направления изучения представлений о справедливости 1 202.17kb.

Студент фит нгу > группа 5304 Версия 0 - страница №1/1

Новосибирский Государственный Университет

Факультет Информационных Технологий






Студент ФИТ НГУ >

группа 5304

Версия 1.0.0

Содержание

1.Цель 2

1.1 3

1.1.1Компоненты сторонних производителей 4


Введение


  1. Цель


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

Область действия

Документ разработан в рамках проекта на основе стандартного шаблона Inteks SEP и предназначен для использования студентами ФИТ и преподавателями курса ООАД.

Определения и сокращения



[В этой таблице нужно перечислить все термины предметной области, используемые далее в документе. В тексте документа термины имеет смысл выделять курсивом. Текст, выделенный зеленым, является ПРИМЕРОМ, в вашем проекте он может и должен быть другим.

Этот и прочие комментарии, выделенные синим, в финальной версии документа нужно удалить]

Таблица : Определения и сокращения

Термин

Описание

ATM

Automated Teller Machine - банкомат

VISA

Система пластиковых карт VISA

Ссылки

В тексте содержатся ссылки на следующие документы:



  1. <Имя файла документа>, v<версия> - <описание документа>

Ссылки приводятся в виде [N], где N – номер документа в вышеприведенном списке.

Краткое описание

Содержание данного документа построено таким образом, чтобы дать ответ на следующие вопросы:


  • Какие проблемы предметной области должен решать будущий программный продукт

  • Посредством какой функциональности системы будут достигнуто решение проблем предметной области

  • Какова архитектура программного решения

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

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



Предметная область проекта

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

Существующие проблемы



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

  • Суть проблемы;

  • Порождающие ее причины и их влияние на участников (stakeholders) предметной области;

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

  • Предполагаемое решение

[Здесь необходимо кратко описать, как именно предполагается решить проблемы предметной области.]

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

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

Роли

Роль - это что-то (например: другая система) или кто-то (например: человек) вне системы, которые взаимодействуют с ней. В предлагаемой к разработке системе идентифицированы следующие роли:


  1. <Роль1> – <краткое описание роли>

  2. <Роль2> – <краткое описание роли>

  3. Функциональные требования для роли Роль1

[В этом пункте необходимо сделать описание требований к системе в соответствии с Use-Case моделью. Для каждой роли необходимо ввести отдельный пункт 2-го уровня, такой как 3]



[В этом пункте необходимо сделать описание данного Use-Case.]



[В этом пункте необходимо сделать описание данного Use-Case.]

Функциональные требования для роли Роль2



[В этом пункте необходимо сделать описание данного Use-Case.]



[В этом пункте необходимо сделать описание данного Use-Case.]

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



[В этом пункте необходимо описать нефункциональные требования, такие как:

  • Производительность

  • Масштабируемость

  • Ограничения по используемым компонентам

  • Необходимость миграции данных из legacy систем

  • И т.д.]

  • Обзор архитектуры

Этот раздел описывает архитектуру системы.

Компонентная модель системы

[Здесь приводится Component diagram - диаграмма компонентов системы, со связями между компонентами и интерфейсами между ними, а также описание их взаимодействия. Для каждого компонента дается краткое описание его места и предназначения в системе]

Компонент 1

[Здесь приводится более подробное описание предназначения компонента и Package diagram – диаграмма пакетов, из которых состоит данный компонент. Обязательно выделение на диаграмме интерфейсов пакета, служащих для связи с другими пакетами (фасад пакета), а также ключевых классов, используемых другими пакетами в use-case реализациях]

Компонент 2

[Здесь приводится более подробное описание предназначения компонента и Package diagram – диаграмма пакетов, из которых состоит данный компонент. Обязательно выделение на диаграмме интерфейсов пакета, служащих для связи с другими пакетами (фасад пакета), а также ключевых классов, используемых другими пакетами в use-case реализациях]

      1. Компоненты сторонних производителей


[Здесь приводится список использованных компонент сторонних производителей, использованных при разработке системы, с указанием их предназначения в системе]

Схема развертывания приложения

[Здесь приводится Deployment diagram - диаграмма развертывания системы, со связями между узлами и указанием способа связи (протокола). На диаграмме обязательно указать, какие компоненты находятся на том или ином узле]

Допущения и ограничения



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

Пример: При разработке проекта принято допущение, что число транзакций в единицу времени значительно (более чем в 10 раз) снижается в ночное время, что позволяет в период с 01:00 до 6:00 производить автоматическое обновление программного обеспечения системы, требующее полной перезагрузки и остановки сервиса на период до 5 минут.



Известные проблемы

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



Невысокая производительность приложения

Проблема

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

Ранг

10 (высокий)

Влияние на проект

Невозможность использования системы при числе пользователей более 10000.

Пути решения

Кластеризация веб-сервера и сервера базы данных, а также применение load balancer в точке маршрутизации запроса к веб-серверу.

Лист регистрации изменений

Дата

Версия

Описание

Автор





























































[В качестве описания версии можно указывать какие изменения/дополнения были сделаны в этой версии по отношению к предыдущей.]

Лист регистрации проверок

Дата

Версия

Описание

Автор





























































[Здесь описываются результаты проверки документа. Для каждой проверки указывается число, версия документа, описание результатов проверки и имя человека, который делал проверку.]




Если дипломат говорит «да», это значит: «может быть»; если он говорит «может быть», это значит «нет»; а если он говорит «нет», значит, он не дипломат.
ещё >>