Нестандартные расходы
|
Кто платит |
Детали расходов |
Цена |
Основные приобретения List any equipment that may need to be purchased for this contract |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Командировочные расходы Identify all trips that will be taken to support this contract |
|
|
|
|
|
|
|
|
|
|
|
Расходы на обучение Identify all training that will be taken to support this contract |
|
|
|
|
|
|
|
|
|
|
|
|
|
Всего цена |
N/A |
5.6 Расписание и распределение ресурсов
В первую очередь необходимо спроектировать модель базы данных, после чего приступить к разработке серверной части приложения, включающей в себя объекты доступа к данным и объекты реализующие бизнес-логику. После разработки серверной части следует разработать клиентскую часть приложения, включающую в себя объекты реализующие представление пользовательского интерфейса и объекты взаимодействия с серверной частью.
Весь исходный код в процессе разработки будет храниться в системе контроля версиями (SVN).
Сервер баз данных (MySQL) и сервер для развертывания приложения (Apache Tomcat) будет находиться на локальной машине разработчика, после успешного тестирования и релиза приложение будет развернуто на хостинге, поддерживающем используемые технологии.
Приложение 1
Общее описание функциональности
Календарь должен удовлетворять следующим требованиям:
Отображение событий, привязанных к конкретным датам;
Поддержка навигации по датам;
Ведение списка событий с атрибутами:
Наименование;
Описание;
Дата и время начала;
Дата и время окончания;
Список участников;
Место проведения;
Регистрация, авторизация пользователей.
Перечень реализуемых функций
Сервис реализует следующий набор функций:
Просмотр события;
Создание события;
Редактирование события;
Удаление события;
Управление режимом отображения событий в календаре.
Возможные режимы:
День;
Неделя;
Месяц;
В верхней части должен выводится текст, соответствующий режиму работы календаря:
День: <Число> <Наименование месяца> <Год>. По умолчанию выбирается текущая дата.
Неделя: С <Число> <Наименование месяца> <Год> по <Число> <Наименование месяца> <Год>. По умолчанию выбирается текущая неделя.
Месяц: <Наименование месяца> <Год>. По умолчанию выбирается текущий месяц.
Год: <Год>. По умолчанию выбирается текущий год.
Кнопка «Создать» используется для создания новых событий.
В ячейке даты должны отображаться события соответствующего дня.
При нажатии на событие должен осуществляться переход к соответствующей форме просмотра события.
Создание и редактирование события
При нажатии ссылки «Создать событие» открывается форма создания события (подобная форма также используется для редактирования параметров события).
Форма предлагает для заполнения следующие поля:
Наименование – краткое наименование события;
Описание – подробное описание события;
Участники – указывается список участников события. Участники выбираются из справочника, также возможен поиск по справочнику участников с использованием алгоритма нечеткой логики, и должна быть предусмотрена возможность указания электронного почтового адреса участника, отсутствующего в справочнике;
Дата и время начала – дата и время начала события;
Дата и время окончания – дата и время окончания события;
Место проведения - место проведения события. Место проведения может выбираться из справочника (также возможен поиск по справочнику с использованием алгоритма нечеткой логики) или задаваться новое место отсутствующее в справочнике.
При нажатии на кнопку «Сохранить» должен осуществляться контроль корректности ввода параметров, осуществляется сохранение.
При нажатии кнопки «Отмена» пользователь должен вернуться к списку событий без сохранения изменений (если не была нажата кнопка «Сохранить»).
Просмотр события
При выборе конкретного события из списка осуществляется переход на форму просмотра его свойств.
При нажатии кнопки «Вернуться» должен осуществляться переход к просмотру списка событий.
При нажатии кнопки «Изменить» должен осуществляться переход к форме редактирования свойств события.
При нажатии на кнопку «Удалить» должно отображаться всплывающее окно подтверждения удаления события и в случае подтверждения событие удаляется и пользователь возвращается обратно к списку событий.
Кнопки «Изменить» и «Удалить» доступны только автору события.
Приложение 2
Таблица 1. Выбор жизненного цикла
Критерий |
Водопадная модель |
V-модель |
Прототипная модель |
Инкрементная модель |
Спиральная модель |
Эволюционная модель |
Доступность ресурсов |
высокая |
низкая |
неизвестная |
неизвестная |
неизвестная |
низкая |
Сложность проекта |
низкая |
низкая |
средняя |
высокая |
высокая |
высокая |
Стоимость приложения |
низкая |
низкая |
низкая |
средняя |
высокая |
высокая |
Стоимость будущих обновлений |
высокая |
высокая |
низкая |
низкая |
низкая |
низкая |
Дискретные изменения требований |
большие |
большие |
малые |
малые |
малые |
малые |
Простота использования |
простая |
простая |
простая |
сложная |
сложная |
сложная |
Функциональные требования приложения |
определенные |
определенные |
неопределенные |
неопределенные |
неопределенные |
неопределенные |
Постепенное изменение требований |
малое |
малое |
малое |
большое |
большое |
большое |
Долговечность приложения |
длинная |
длинная |
короткая |
длинная |
длинная |
длинная |
Технологии проекта |
существуют |
существуют |
новые |
новые |
новые |
новые |
Производительность приложения |
высокая |
высокая |
низкая |
высокая |
высокая |
неопределена |
Точность результата |
повторная |
повторная |
единожды |
единожды |
единожды |
повторная |
Требования к стабильности |
низкие |
низкие |
низкие |
средние |
высокие |
средние |
Повторное использование продукта/документации |
низкое |
низкое |
низкое |
высокое |
высокое |
высокое |
Перспективы управления рисками |
нет |
нет |
да |
нет |
Да |
высокие |
Неопределенность требований |
нет |
нет |
да |
да |
Да |
да |
Неизвестные требования |
нет |
нет |
да |
да |
Да |
да |
Суммарное число выбранных ячеек |
7 |
7 |
11 |
9 |
8 |
5 |
Таким образом, следует выбрать прототипную модель жизненного цикла.
Таблица 2. Сложность проекта
Характеристики проекта |
Очки |
a. Сложность координации |
|
Команда разработчиков автономна и не требуется взаимодействие с людьми вне этой команды. |
1 |
Команда разработчиков взаимодействует с теми, кто находится в том же здании. |
2 или 3 |
Команда разработчиков взаимодействует с другими внешними группами разработчиков. Цели определены в местном масштабе. |
4 или 5 |
Команда разработчиков объединена с разработчиками из других команд. Цели являются общими. |
6 или 7 |
Команда разработчик вовлечена во внешние организации и контракты. |
8 |
Проект является объединенным между организациями. |
9 |
Проект является контрактом от внешней организации. |
10 |
|
|
b.Типы разработки |
|
Проект разрабатывается без требования к повторному использованию. |
1 |
Проект разрабатывается в соответствии с определенной концепцией продукта. |
2 |
Проект разрабатывается с участием группы тестировщиков. |
3 |
Проект заключается в обеспечении поддержки работы существующего продукта. |
4 |
Проект заключается в модификации какой-то функции существующего продукта. |
5 или 6 |
Проект заключается в создании какой-то функции существующего продукта. |
7 или 8 |
Проект заключается в в разработке нового продукта с использование 50% кода из предыдущего проекта. |
9 |
Проект заключается в разработке нового продукта с самого начала. |
10 |
|
|
c. Использование разработанного продукта |
|
Продукт содержит одноразовый код |
1 |
Продукт является инструментом разработчиков, использующемся в компании. |
2 |
Продукт является инструментом разработчиков, использующемся и в других компаниях. |
3 или 4 |
Продукт является прототипом с ограниченным функционалом |
5 |
Продукт предназначен для демонстрации заказчикам |
6 |
Продукт для полевых испытаний (бета-тестирование) |
7 |
Продукт для коммерческого использования и экспорта |
8,9 или 10 |
|
|
d. Длительность разработки |
|
< 3 месяцев штата |
1 |
> 3 месяцев штата to 6 месяцев штата |
2 |
> 6 месяцев штата to 9 месяцев штата |
3 |
> 9 месяцев штата to 12 месяцев штата |
4 |
> 12 месяцев штата to 15 месяцев штата |
5 |
> 15 месяцев штата to 18 месяцев штата |
6 |
> 18 месяцев штата to 21 месяцев штата |
7 |
> 21 месяцев штата to 24 месяцев штата |
8 |
> 24 месяцев штата to 27 месяцев штата |
9 |
> 27 месяцев штата |
10 |
|
|
e. Размер разработки |
|
< 5 KLOC |
1 |
> 5 KLOC TO 15 KLOC |
2 |
> 15 KLOC TO 25 KLOC |
3 |
> 25 KLOC TO 35 KLOC |
4 |
> 35 KLOC TO 45 KLOC |
5 |
> 45 KLOC TO 55 KLOC |
6 |
> 55 KLOC TO 65 KLOC |
7 |
> 65 KLOC TO 75 KLOC |
8 |
> 75 KLOC TO 85 KLOC |
9 |
> 85 KLOC |
10 |
|
|
Суммарно |
11 |
Очки |
Тип проекта |
5 - 20 |
Небольшой проект |
21 - 40 |
Средний проект |
41 - 50 |
Сложный project |
Таким образом, тип проекта – маленький проект (в диапазоне 5 – 20).
Таблица 3. Необходимые мероприятия
В соответствии с типом проекта ниже представлен список необходимых мероприятий.
Мероприятие |
Необходимость |
Предварительное планирование: Объем продукции и требования Оценка ресурсов ($) Оценка усилий Определение предварительных мероприятий / ролей Определение основных этапов Анализ рисков Определение потребности в обучении Утверждение основных документов |
Да Да Да Да Да Да Да Да |
Планирование и анализ требований: Определение процесса разработки проекта Высокоуровневая функциональная декомпозиция Разработки требований Финансовые оценки Комплектование штата сотрудников Структура работы / Расписание Анализ рисков Обучение планированию Выбор стандартов / инструменты План управления конфигурацией План по качеству Цели повторного использования Цели производительности План внедрения технологий (1) Патентные исследования (2) Определение конечного результата Установка репозитория Установка баг-трекера (3) Создание веб-страницы Создание книги записей для проекта Определить метрики проекта Разработка прототипа (4) Утверждение соответствующих документов |
Да Да Да Да Да Да Да Да Да Да Да Да Да Нет Нет Да Да Нет Да Нет Да Нет Да |
Подробный анализ требований* Определение детальных функциональных требований Разработка плана тестирования Анализ рисков Статус отслеживания / отчетности Проверка контроля Коллекция метрик Утверждение соответствующих документов |
Да Да Да Да Да Да Да |
Проектирование* Высокоуровневое проектирование Детальное проектирвоание Проектирование модульных тестов (5) Проектирование сценариев тестирования (6) Возможность оперативного контроля Анализ рисков Коллекция метрик Статус отслеживания / отчетности Утверждение соответствующих документов |
Да Да Нет Нет Да Да Да Да Да |
Реализация* Разработка кода Модульное тестирование Обзор стиля кодирования Кодовые инспекции Интеграционное тестирование Разработка процедуры испытания Разработка сценария испытания Разработка сценариев кодовых инспекций Обновление требований оперативного контроля Разработка пользовательской документации (7) Обновление архитектуры сценариев тестирования (8) Создание билда для нестандартных тестов (9) Анализ рисков Коллекция метрик Статус отслеживания / отчетности Утверждение соответствующих документов |
Да Да Да Да Да Да Да Нет Нет Нет* Нет* Нет* Да Да Да Да |
Системное тестирование: Подготовка билда для тестирования Подготовка к испытаниям Выполнение системного тестирования Лог с ошибками Отчет о тестировании Коррекция ошибок
Анализ рисков Коллекция метрик Статус отслеживания / отчетности Утверждение соответствующих документов |
Да Да Да Да Да Да
Да Да Да Да |
Релиз: Архив артефактов проекта Подготовка материалов для маркетинга (10) Подготовка материалов по правовым темам (11) Подготовка отчета о релизе Заключительный анализ Обсуждение релиза Развертывание релиза Утверждение соответствующих документов |
Да Нет Нет Да Да Да Да Да |
Поддержка: Приоритеты дефектов Оценка ресурсов $ Оценка усилий Структура работы / расписание Определение мероприятий / ролей Исправление кода Кодовые инспекции Обзор стиля кодирования Модульное тестирование Интеграционное тестирование Обновление документации Обновление процедуры тестирования Разработка сценариев тестирования Обновление требований оперативного контроля Все задачи из системной фазы тестирования Все задачи из фазы релиза (12) Анализ рисков Коллекция метрик Статус отслеживания / отчетности Утверждение соответствующих документов |
Да Да Да Да Да Да Да Да Да Да Да Да Да Да Да Да Да Да Да Да |
– используемые технологии достаточно просты, чтобы не разрабатывать специальный план внедрения;
– патентные исследования не требуются, проект небольшой и мало затратный;
– баг-трекер не нужен, т.к. проект небольшой и простой;
– на этапе планирования прототип не будем делать, поскольку в большей степени требования известны, а значит создание на этом этапе прототипа нецелесообразно;
– время на разработку ограничено, поэтому разработка модульных тестов будет «по ходу» разработки;
– такая же причина, что и в пункте 5;
– ограничение по времени и простота проекта позволяют оставить пользователя без документации;
– поскольку архитектуры сценариев не разрабатывалось, нечего будет и обновлять;
– ограничение по времени не позволит сделать билд для нестандартных тестов;
– маркетинг не требуется;
– правовых тем тоже не будем касаться;
- только те задачи, которые были обязательны в фазе релиза;
Приложение 3
