Разработка веб-приложений для электронных заметок

Размещено на http://allbest.ru

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

Брянский государственный технический университет

Кафедра «ИиПО»

РАСЧЕТНО-ГРАФИЧЕСКАЯ РАБОТА

Разработка веб-приложений для электронных заметок

Студент гр. 09-МОА

Ефименкова Е.В.

Преподаватель

Азарченков А.А.

Брянск 2014



Содержание

1. Анализ предметной области

1.1 Описание аналогов

1.1.1 Редактирование Together

1.1.2 Редактор Yojimbo

1.1.3 Редактор Microsoft One Note

1.1.4 Сравнивание аналогов

Выводы

2. Расчет прогнозируемого числа строк исходного кода, разрабатываемого ПС

3. Оценка трудозатрат для разработки нового программного обеспечения на основе модели СОСОМО

4. Определение трудоемкости разработки ПС на основе модели вариантов использования

5. Распределение трудозатрат по видам работ

6. Техническое задание

6.1 Назначение разработки

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

6.2.1 Требования к функциональным характеристикам системы

6.2.2 Требования к надежности системы

6.2.3 Требования к параметрам и составу технических средств

6.2.4 Требования к информационной и программной совместимости

6.2.5 Требования к программной документации

7. Архитектура ПС



1. Анализ предметной области

Необходимо разработать web-сервис ведения электронных заметок с поддержкой структурирования, поиска и совместного редактирования.

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

Сервис должен иметь многопользовательскую структуру.

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

Сервис должен предоставлять пользователям возможность создания своего личного кабинета.

Сервис должен предоставлять пользователям возможность создания и управления заметками.

Сервис должен каталогизировать (структурировать) заметки пользователя.

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

Сервис должен предоставлять пользователям возможность полнотекстового поиска заметок (по тексту заметки).

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

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

Сервис должен предоставлять пользователям возможность просмотреть список контактов.

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

Сервис должен предоставлять возможность отправки заметок пользователям, находящимся в списке подписок.

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

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

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

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

Основными функциями сервиса естественно является создание и управление заметками. При создании и редактировании заметок необходимо обеспечить drag-and-drop работу с файлами. Это удобно и занимает меньше времени, чем передача файлов через диалоговые окна добавления. В заметки должна быть возможность хранения текста, фото, аудио и видео файлов. Должны быть предоставлены функции форматирования текста. Заметка должна хранить информацию об авторе, датах создания и редактирования, название заметки, а так же индекс или название элемента каталога, в который она вложена. При удалении заметок необходимо запрашивать у пользователя подтверждение.

Структурирование заметок предполагается двухуровневое. Верхним уровнем иерархии будет являться «Книга», которая будет содержать «Темы», а они в свою очередь заметки. К тому же, могут существовать заметки, не привязанные к темам, но находящиеся в книгах, а так же заметки, не привязанные ни к одному элементу иерархии. Общий доступ пользователь может открыть или запретить как к конкретной заметке, так и к элементам иерархии: темам или книгам. Все элементы иерархии должны хранить информации о датах создания и редактирования, авторе и имени, а так же количестве вложенных элементов.

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

Обмен заметками возможен, только если пользователи являются подписчиками друг друга. Заметки пользователя, не находящего в списке подписчиков можно только просматривать и только при условии, что к ним открыт общий доступ для всех пользователей. Если пользователь находится в списке подписчиков, то можно только просмотреть заметки находящиеся в общем доступе для всех пользователей и для подписчиков. Редактировать заметки других пользователей можно только в случае отправки этой заметки для редактирования. Механизм подписок предполагается организовать в виде кнопки «Подписаться», размещенной в личном кабинете пользователей.

Общий доступ к заметкам, а так же элементам иерархии можно открыть или закрыть для всех пользователей или для всех подписчиков или только для некоторых пользователей. Это обеспечит сохранность и конфиденциальность данных пользователей.

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

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

Для написания основной программы предполагается использовать технологию Microsoft ASP.NET. Основным критерием для выбора этой платформы является высокая скорость разработки, функциональность данной платформы, а так же возможность использования языка С#.

Для осуществления передачи данных через сеть предполагается использовать технологию web socket. Основными преимуществами web socket является полная асинхронность. Во-вторых, web socket это постоянное ТСР соединение, а не сессионное как в HTTP. В-третьих, событийная модель, которая позволяет уровнять в правах клиент и сервер. Данные можно отсылать в ответ на событие на другом конце и не ожидать подтверждения, которое может не прийти.

При разработке сервиса возникает ряд проблем. Большие объемы данных будут храниться в базе данных, поэтому следует продумать механизм их хранения так, чтобы не возникало больших задержек в работе приложения.

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

Для передачи данных по сети планируется использовать протокол web socket. Это влечет за собой проблему совместимости, как с браузерами, так и с программным обеспечением серверов, где будет размещен сервис. Так же необходимо следить за безопасностью передачи данных, так как web socket в настоящее время не может гарантировать 100% безопасности канала передачи данных.

1.1 Описание аналогов

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

1.1.1 Редактор Together

Данный редактор предоставляет пользователю огромное количество функций. Здесь и довольно серьезные для заметок возможности редактирования текста и даже редактор изображений. Пользователь может добавить надпись или подрисовать что-то на изображении самостоятельно.

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



Рис. 1. Внешний вид главного окна редактора Together

Так же данное приложение ориентировано в основном на работу с файлами мультимедиа и изображениями. Данный ресурс разработан для применения на мобильных устройствах, базируется на операционной системе МАС-ОС. В приложении реализовано несколько моделей структурирования данных: стандартное дерево каталогов по темам или дате, как пожелает пользователь, а так же Together сортирует сами данные во всех заметках, создавая библиотеки текста, видео, музыки и графики.

1.1.2 Редактор Yojimbo

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

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

Рис. 2. Внешний вид главного окна редактора Yojimbo

К достоинствам данного редактора так же стоит отнести устройство его дерева каталогов. Собственно говоря, их всего четыре Архивы, заметки, изображения и помеченные флагами записи. Так же стоит отметить удобное расположение «Корзины», что облегчает удаление файлов, и дает возможность не лишиться сразу же ценной информации удаленной по ошибке. Данный ресурс разработан преимущественно для применения на мобильных устройствах, в настоящее время ведется работа над версией для «рабочего стола». Ресурс базируется на операционной системе МАС-ОС.

1.1.3 Редактор Microsoft One Note

На сегодняшний день OneNote (рис. 3) является одним из самых популярных редакторов заметок, не малую роль в этом играет распространение Windows и Microsoft Office в частности. Но не стоит думать, что его используют из-за отсутствия должной конкуренции.

Рис. 3. Внешний вид главного окна редактора Microsoft OneNote

Редактор очень удобен, немалую роль играет в этом продуманная панель инструментов Microsoft Office 2010. К тому же на основную панель вынесены минимальные настройки текста, все же остальное ждет своего часа во вкладках панели. А доступные средства редактирования, как текста, так и других видов данных достаточно масштабны. Не стоит забывать, что речь идет о заметках, а не о полноценном редакторе мультимедиа файлов.

Интерфейс приложения прост, понятен и удобен. Открытая для редактирования заметка напоминает обычную записную книжку с разделителями. Приложение ориентировано на настольное применение, создано на базе операционной системы Windows.



1.1.4 Сравнение аналогов

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

Таблица 1. Сравнительная характеристика программ-аналогов

Критерии сравнения	Редактор Together	Редактор Yojimbo	Редактор ОneNote
Предназначен для настольного применения	Не предназначен	Не предназначен, но ведется разработка версии для «рабочего стола»	Предназначен для настольного использования
Предназначен для использования на мобильных устройствах	Предназначен для использования на мобильных устройствах	Предназначен для использования на мобильных устройствах	Не предназначен
Используемая операционная система	МАС-ОС	МАС-ОС	Windows
Удобность интерфейса	Интерфейс удобен и понятен, но сложен в эксплуатации для начинающих пользователей	Интерфейс прост, понятен, удобен, не перегружен	Имеет настраиваемую панель инструментов, стандартная панель удобна, понятна и не перегружена
Особенности редактора	Большие возможности редактирования мультимедиа файлов. Двойная иерархия.	Возможность хранить файлы архивов и ставить особые метки к записям	Схожесть интерфейса с обычной записной книжкой.



Выводы

На основе проведенного анализа предметной области и сравнения аналогов разрабатываемой системы, можно сделать вывод о том, что разработка сервиса является актуальной. Так как рассмотренные аналоги не удовлетворяют всем требованиям системы такого вида. Редактор Together предоставляет широкие возможности редактирования файлов всех видов, но при этом интерфейс перегружен элементами управления. Редактор Yojimbo предоставляет, по сравнению с другими аналогами, достаточно скромные средства редактирования, однако имеет простой понятный интерфейс. Редактор OneNote наряду с достаточными возможностями редактирования предоставляет удобную настраиваемую индивидуально панель инструментов.

Но ни один из аналогов не предоставляет возможности совместного редактирования файлов между пользователями приложения.

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

2. Расчет прогнозируемого числа строк исходного кода, разрабатываемого ПС

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

1. Применить метод функциональных точек

2. Определить границы ПС

3. Выполнить идентификацию и оценку функциональности данных (ILF, ELF).

4. Выполнить идентификацию и оценку функциональности транзакций (EI, EO, EQ).

5. Определение значения нормирующего фактора (VAF).

6. Подсчет нормированного количества функциональных точек.

7. Оценить количество строк исходного кода необходимое для создания ПС бэкфайер-методом.

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

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



Рис. 4. Границы ПС

1. Данные о пользователе: 13 переменных типа текст, 1 переменная числового типа.

2. Данные о заметке: 4 переменных типа текст, 2 переменных типа дата, 4 переменных числового типа.

3. Данные о теме: 3 переменных типа текст, 2 переменных типа дата, 1 переменная числового типа.

4. Данные о книге: 3 переменных типа текст, 2 переменных типа дата, 2 переменных числового типа.

5. Данные об изображении: 3 переменные типа текст, 1 переменная типа дата.

6. Данные о видео: 3 переменные типа текст, 1 переменная типа дата.

7. Данные об аудио: 3 переменные типа текст, 1 переменная типа дата.

8. Вспомогательные данные: 2 переменные типа текст.

Всего 46 переменных, 3 типа данных - средний уровень сложности.



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

Данные о заметке: 4 переменных типа текст, 4 переменных числового типа.

Всего 8 переменных, 2 типа данных - низкий уровень сложности.

Выполняя идентификацию и оценку функциональности транзакций, будем последовательно определять внешний ввод (EI), внешний вывод (EO) и внешний запрос (EQ).

Внешний ввод содержит данные, вводимые в систему пользователем

1. Данные о пользователе: 2 переменных типа текст.

2. Данные о заметке: 2 переменных типа текст, 3 переменных типа файл.

3. Данные о теме: 1 переменная типа текст.

4. Данные о книге: 1 переменная типа текст.

Всего 9 переменных, 2 типа данных - средний уровень сложности.

Внешний вывод содержит данные, выводимые системой.

1. Данные о заметке: 3 переменных типа текст, 2 переменных типа дата, 4 переменных типа файл.

2. Данные о теме: 2 переменные типа текст, 2 переменные типа дата, 1 переменная числового типа.

3. Данные о книге: 2 переменные типа текст, 2 переменные типа дат, 2 переменные числового типа.

4. Данные о пользователе: 10 переменных типа текст, 1 переменная числового типа, файл.

Всего 31 переменная, 4 типа данных - высокий уровень сложности.

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

1. Ввод внешнего запроса: 7 переменных типа кнопка.

Всего 7 переменных, 1 тип данных - низкий уровень сложности (EI = 3).

2. Вывод внешнего запроса: 3 переменных логического типа

Всего 3 переменных, 1 тип данных - низкий уровень сложности (EO = 4)

Значение EQ выбирается как максимальное из EI и EO.

Далее необходимо определить ненормированное количество функциональных точек:

Определение значения нормирующего фактора VAF зависит от 14 основных характеристик ПС:

1. Обмен данными = 4.

2. Распределённые функции = 1.

3. Производительность = 4.

4. Интенсивно используемая конфигурация = 0.

5. Интенсивность транзакций = 4.

6. Диалоговый ввод данных = 1.

7. Эффективность для конечного пользователя = 3.

8. Оперативное обновление = 1.

9. Сложность обработки данных = 5.

10. Повторное использование = 0.

11. Лёгкость установки = 3.

12. Простота в использовании = 4.

13. Распространенность = 5.

14. Лёгкость изменения = 1.

Далее необходимо определить нормированное количество функциональных точек:

Бэкфайер-метод, предназначенный для оценки количества строк исходного кода, необходимого для создания ПС, строится на значении языкового множителя языка программирования (LM). В нашем случае возьмем LM = 29 (С#).



Таким образом, искомое значение будет найдено как:



3. Оценка трудозатрат для разработки нового программного обеспечения на основе модели СОСОМО

Для расчета трудоемкости и сроков реализации ПС с использованием модели СОСОМО необходимо выполнить следующие действия:

1. Определить входные данные.

2. Рассчитать ненормированные трудозатраты на создание ПС.

3. Рассчитать ненормированную длительность разработки ПС.

4. Оценить стоимостные факторы проекта.

5. Рассчитать коэффициент нормирования.

6. Рассчитать нормированные трудозатраты на создание ПС.

7. Рассчитать нормированную длительность разработки ПС.

8. Выполнить распределение полученных нормированных трудозатрат и сроков разработки по основным этапам жизненного цикла ПО.

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

Количество строк кода, необходимого для кодирования ПС было рассчитано выше и с учетом того, что предполагается использовать язык программирования С# составило 907,99.

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

Ненормированные трудозатраты на создание ПС можно рассчитать по формуле:

(человеко-месяца)

Ненормированную длительность разработки ПС можно рассчитать по формуле:

(месяца)

Отметим, что в данных случаях значение нормировочного коэффициента принят равным 1.

Теперь необходимо оценить стоимостные факторы проекта. Всего их 15, они разделены на 4 группы. Ниже приведен список факторов и их оценок.

Характеристики продукта:

1. Требуемая надежность ПО (RELY) - «очень низкий» 0.75;

2. Размер БД приложения (DATA) - «D/P>=1000» 1.16;

3. Сложность продукта (CPLX) - «номинальный» 1.00;

Характеристики аппаратного обеспечения:

4. Ограничения быстродействия при выполнении программы (TIME) - «высокий» 1.11;

5. Ограничения оперативной памяти (STOR) - «номинальный» 1.00;

6. Неустойчивость окружения виртуальной машины (VIRT) - «очень низкий»;

7. Требуемое время отклика системы (TURN) - «низкий» 0.87

Характеристики персонала:

8. Аналитические способности (ACAP) - «очень низкий» 1.46;

9. Квалификация программистов (PCAP) - «низкий» 1.13;

10. Опыт работы в данной области (AEXP) - «номинальный» 1.00;

11. Опыт разработки на используемом языке программирования (LEXP) - «номинальный» 1.00;

12. Опыт использования виртуальных машин (VEXP) - «очень низкий» 1.21;

Характеристики проекта:

13. Использование программных инструментов при разработке ПО (TOOL) - «очень высокий» 0.83

14. Применение современных методов программирования ПО (MODP) - «номинальный» 1.00;

15. Ограничение сроков разработки (SCED) - «номинальный» 1.00;

На основе произведенных оценок вычислим нормировочный коэффициент:

Теперь можем рассчитать нормированные трудозатраты на создание ПС и нормированную длительность разработки ПС.

=2.89*1.39=4.0171 (человеко-месяца)

= 3.74*1.39 = 5.1986 (месяцев)

Распределение трудозатрат (табл. 2) и сроков разработки (табл. 3) по основным этапам жизненного цикла ПО выполним в виде таблиц.



Таблица 2. Распределение трудозатрат по основным этапам ЖЦПО

Распределение трудозатрат	Размер проекта
Тип проекта	Этап	Маленький
		Процентная доля от общих трудозатрат на разработку ПС	Трудозатраты на данный этап
Распространенный	1. Проектирование	16	0,642736 (чел.-мес.)
	2. Программирование	68	2,731628 (чел.-мес.)
	2.1 Детальная обработка	26	1,044446 (чел.-мес.)
	2.2 Кодирование и тестирование	42	1,687182 (чел.-мес.)
	3. Интеграция и тестирование	16	0,642736 (чел.-мес.)

Таблица 3. Распределение сроков разработки по основным этапам ЖЦПО

Распределение сроков разработки	Размер проекта
Тип проекта	Этап	Маленький
		Процентная доля от общих сроков на разработку ПС	Сроки на данный этап
Распространенный	1. Проектирование	19	0,987734 (мес.)
	2. Программирование	63	3,275118 (мес.)
	3. Интеграция и тестирование	18	0,935748 (мес.)



4. Определение трудоемкости разработки ПС на основе модели вариантов использования

Для расчета трудоемкости разработки ПС на основе модели вариантов использования необходимо выполнить следующие действия:

1. Построить модель вариантов использования заданной предметной области.

2. Классификация вариантов использования по степени сложности.

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

4. Расчёт суммарного числа точек нескорректированных вариантов использования (UUCP).

5. Определение рейтинга технических факторов.

6. Расчет коэффициента технической сложности (TCF).

7. Определение рейтинга факторов окружения.

8. Расчет фактора окружения (EF).

9. Расчет окончательного числа точек вариантов использования (UCP).

10. Оценить трудоемкость работ.

Основываясь на анализе предметной области, была построена следующая модель вариантов использования (рис. 5).

Анализируя диаграмму, видим, что все варианты использования относятся к простым, следовательно, каждому из них присваивается числовой коэффициент - 5.

Исходя из чего, UUCP можно рассчитать по следующей формуле:

Рис. 5. Диаграмма вариантов использования

Определение рейтинга технических факторов для большей наглядности проведем в виде таблицы (табл. 4):

Таблица 4. Оценка технических факторов

Фактор	Оценка	Вес
Распределенная система	0	2
Требования быстрого ответа и высокой пропускной способности	5	1
Эффективность оперативной работы конечного пользователя	0	1
Сложная внутренняя обработка	1	1
Требование повторного использования кода	0	1
Простота установки	0	0,5
Простота использования	5	0,5
Переносимость	1	2
Легкость изменений	0	1
Параллельное выполнение	3	1
Включение специальных средств безопасности	3	1
Прямой доступ к программам независимых производителей	0	1
Специальные средства обучения пользователей	0	1

Исходя из проведенной оценки, и весов факторов рассчитаем TFactor по формуле:

Теперь можем рассчитать коэффициента технической сложности TCF по формуле:

Определение рейтинга факторов окружения так же проведем в таблице (табл. 5):

Исходя из проведенной оценки, и весов факторов рассчитаем ЕFactor по формуле:

Таблица 5. Оценка факторов окружения

Фактор	Оценка	Вес
Знакомство с технологиями интернета	5	1,5
Опыт в прикладной области	3	0,5
Опыт объектно-ориентированного программирования	5	1
Способности ведущего аналитика	5	0,5
Мотивация	3	1
Стабильные требования	3	2
Персонал с частичной занятостью	0	-1
Сложный язык программирования	0	-1

Теперь можем рассчитать коэффициента технической сложности ЕF по формуле:

Теперь можем рассчитать окончательное число точек вариантов использования UCP по формуле:

Оценить трудоемкость работ можно путем назначения определенного количества человеко-часов на каждую UCP. Для данного проекта будем использовать 20 человеко-часов для каждой UCP. Тогда трудоемкость работ будет равна 3886,3 человеко-часов.



5. Распределение трудозатрат по видам работ

Из общего списка работ, представленных в стандарте ГОСТ Р ИСО/МЭК 12207-99, выберем необходимые для разработки сервиса ведения электронных заметок и распределим для этих работ трудозатраты и сроки выполнения, вычисленные ранее. Для большей наглядности представим результаты в виде таблицы (табл. 6).

Таблица 6. Распределение трудозатрат и сроков выполнения

Этап ЖЦПО	Работы	Трудозатраты	Сроки выполнения
Проектирование	Подготовка договора	0,114245 (чел.-мес.)	0,259244 (мес.)
	Проектирование системной архитектуры	0,264245 (чел.-мес.)	0,364245 (мес.)
	Проектирование программной архитектуры	0,264245 (чел.-мес.)	0,364245 (мес.)
Кодирование	Программирование и тестирование программных средств	1,639403 (чел.-мес.)	0,655023 (мес.)
	Сборка программных средств	0,076325 (чел.-мес.)	0,15 (мес.)
	Тестирование программных средств	0,026325 (чел.-мес.)	0,1 (мес.)
	Сборка системы	0,096325 (чел.-мес.)	0,15 (мес.)
	Тестирование системы	0,026325 (чел.-мес.)	0,15 (мес.)
Интеграция и тестирование	Верификация	0,214245 (чел.-мес.)	0,311916 (мес.)
	Аттестация	0,214245 (чел.-мес.)	0,311916 (мес.)
	Приемка	0,214245 (чел.-мес.)	0,311916 (мес.)

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

Рис. 6. Диаграмма Гранта

6. Техническое задание

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

6.1 Назначение разработки

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

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

Для системы должен быть разработан удобный понятный интерфейс. Он не должен быть перегружен элементами управления и меню.

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

К разрабатываемой системе предъявляются требования следующих видов.

6.2.1 Требования к функциональным характеристикам системы

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

– Создание электронных заметок в среде редактора.

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

– Редактирование электронных заметок в среде редактора.

– Возможность редактирования в области заметок изображений и/или файлов мультимедиа.

– Настраиваемая панель инструментов приложения.

– Возможность «подписаться» на заметки и/или тему заметок другого пользователя системы. То есть обозначить для себя пользователей, заметки которых вы хотели бы просматривать.

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

– Оповещения пользователей системой в случаях:

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

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

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

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

– Возможность поиска заметок по нескольким критериям: по названию, теме, автору, дате создания заметок, а так же по полному тексту заметок.

– Удаление электронных заметок.



6.2.2 Требования к надежности системы

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

– Данные, заносимые в систему должны сохраняться без потерь и корректно (предусмотреть решение проблем, связанных с сохранением больших объемов данных).

– Данные должны корректно пере сохраняться в базе данных.

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

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

– Обеспечить сохранность личных данных пользователей при регистрации и авторизации в системе.

6.2.3 Требования к параметрам и составу технических средств

Данная система предназначена для эксплуатации в сети Internet с помощью браузеров: Chrome начиная с версии 4.0.249.0 и выше, Mozilla Fire Fox начиная с версии 4 и выше, Opera начиная с версии 10.70.9067 и выше, Internet Explorer начиная с версии 10.РР5 и выше, Apple Safari начиная с версии 5.0.7533.16 и выше, в среде Microsoft Windows ХР и выше.

6.2.4 Требования к информационной и программной совместимости

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

Программные коды должны быть написаны на языках: JavaScript, C#, XML.

6.2.5 Требования к программной документации

Программную документацию можно условно разделить на две части: Инструкции для пользователей и документация для разработчиков.

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

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

7. Архитектура ПС

Для выбора архитектуры ПС нам необходимо определить основные требования к ней. Система предназначена для работы в среде Internet, соответственно следует отталкиваться от стандартной архитектуры веб приложения (рис. 7). электронные заметки программный приложение

Рис. 7 Архитектура веб приложения

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



Рис. 8 Архитектура нагруженного веб приложения

Рассмотрим некоторые из блоков, представленных на данном рисунке подробнее.

Приложение в реальной системе будет представлять собой сервер приложений (mvc). Его архитектура (рис. 9) проста, назначение его в том, чтобы разгрузить сервер базы данных от обработки лишних запросов, связанных с работой приложения. Стрелками на рисунке указаны процессы взаимодействия элементов архитектуры.

1. Пользователь взаимодействует с контроллером, совершая действия с элементами управления приложения.

2. Как реакция на действия пользователя контроллер обновляет представление модели приложения.

3. Действия пользователя могут привести к смене модели представления приложения. Контролер манипулирует этими изменениями.

4. Для формирования представления модели могут потребоваться данные из базы данных. Модель представления взаимодействует с базой данных.

5. Представление модели показывается пользователю.

Рис. 9 Архитектура сервера приложений.

Статика. В реальной системе этот блок будет представлен сервером статических данных. Выше говорилось о том, что модель представления приложения может обращаться к базе данных с целью получения необходимой для формирования представления информации. Допустим, что пользователь активен и совершает множество действий в системе. Его действия в программе интерпретируются в SQL-запросы к базе данных. Эти запросы можно разделить на две группы: запросы, связанные с функциональными возможностями системы, то есть создание и редактирование заметок, и запросы, связанные с изменениями представления приложения, так как выше описанная модель сервера приложений связана с базой данных. Чем активнее пользователь, тем больше запросов, причем обоих типов. Это перегружает сервер базы данных. Данные, необходимые модели представления, как правило, однотипны и не очень вариативны. Однако, если моделей в системе множество, то количество таких побочных данных резко возрастает. Это сокращает как полезное место в базе данных, так и замедляет ее работу в виду увеличения количества запросов к ней. Что же делать? Решение просто. Необходимо вынести эти побочные данные на отдельный сервер и разгрузить сервер основной базы данных системы.

База данных. О перегрузках базы данных в виду большого количества запросов говорилось много. Даже если вынести всю информацию кроме той, которой заполняют ее пользователи, тем самым уменьшить количество запросов, все равно их число останется внушительным. С ростом количества запросов начнется снижение времени отклика приложения, что вызовет недовольства пользователей. Понятно, что ни одна система не в состоянии обрабатывать больше двух-трех запросов одновременно. В системе формируется очередь запросов, и с течением времени эта очередь переполняется, и запросы начинают теряться. Проблему может решить размножение серверов с базами данных, однако необходим механизм, позволяющий распределять запросы между этими серверами. Таким механизмом служит сервер балансировки (рис. 10).

Рис. 10 Работа сервера балансировки



Теперь, разобравшись в компонентах системы, сформируем ее окончательное подробное представление (рис. 11).

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

Рис. 11 Архитектура системы

Размещено на Allbest.ru

...