ddintsis.files.wordpress.com … · Web viewБраузер Web пользователя5. Мобильное устройство ... Мобильное приложение –

УТВЕРЖДАЮ ПРИНИМАЮЗаказчик Разработчик

___________________2009 года ___________________2009 года

План управления проектом (SPMP)

для

Версия 4.0

Выполнено Д.Ю. Динцис

05.02.2011

Copyright © 2011.

ИсторияизмененийИмя Дата Причина изменения Версия

Данил Динцис 05.02.2011 Корректировка в связи с изменением состава и приоритета разработки

4.0

Copyright © 20092011.

Содержание

1. Введение

1.1. Обзор проекта

1.2. Результирующие артефакты проекта

1.2.1. Программный код модулей (исходный и скомпилированный):

1.2.3. Руководства пользователей по сервисам:

1.2.4. руководства по эксплуатации (администратор и оператор со стороны заказчика):

1.3. Развитие SPMP

1.4. Ссылочные материалы

1.5. Определения и аббревиатуры (Глоссарий)

2. Организация процесса

2.1. Модель процесса

2.2. Организационная структура

2.3. Организационные рамки и взаимосвязи

2.4. Ответственность за проект

3. Управляющий процесс

3.1. Цели и приоритеты

3.3. Управление рисками

3.4. Механизм мониторинга и контроля

3.5. План расстановки кадров

4. Технический процесс

4.1. Методы инструменты и технологии

4.2. Документация ПО

4.3. Функции сопровождения проекта

5. Распределение работ, план-график и бюджет

5.1. Распределение работ

5.2. Зависимости

5.3. Потребности в ресурсах


1. Справочник виртуальных имен

2.3. Сервис баннеропоказа, статистики и биллинга

2.1. Служба DTN - имен

2.2. Web сервис клиентов/ партнеров

2. 4 Сервис абонентов

3. Сервис отдачи мобильного контента (отгрузки)

2. Серверная часть

4. Браузер Web пользователя

5. Мобильное устройство абонента

1. Введение

1.1. Обзор проекта

Проект DTN (Domain Telephone Name) основан на Патенте № … и представляет собой новую систему адресации и поиска телефонных номеров в привязке к e-mail или доменным именам их владельцев с последующей возможностью совершить звонок в том числе средствами IP телефонии.

Целью данного проекта является реализация программно-технического комплекса F&C (Find and Call) и проведение его пилотного тестирования с привлечением широкой аудитории сторонних пользователей.

Целью реализации программно-технического комплекса F&C является получение доходов Заказчиком за счет предоставления сервисов (услуг) на его базе:

- поиск телефонных номеров по системе DTN адресации и звонки на них с использованием IP каналов связи партнера – провайдера услуг;

- предоставление рекламных площадок клиентам и партнерам;

- оплата отказа от просмотра рекламы.

Программно-технический комплекс F&C реализуется в виде взаимодействующих модулей, как показано на рис. 1.

Рис. 1а


Сервис мониторинга

Сервис баннеропоказа, статистики и биллинга

Сервер отгрузки приложений

Веб-сервис клиентов и партнеров

Сервер абонентов

Справочник виртуальных имен

DTN сервер

Рис. 1б.

1.2. Результирующие артефакты проекта

1.2.1. Программный код модулей (исходный и скомпилированный):

- DTN сервер

- сервис баннеропоказа, биллинга и статистики

- сервис абонентов

- сервис клиентов и партнеров, включая веб-сайт продукта

- сервис отгрузки приложений

- справочник виртуальных имен

- приложения для мобильных клиентов (iPhone, Symbian)


1.2.2. Документация на проект в соответствии со стандартами и спецификациями IEEE: SPMP, SQAP, SVVP, SRS, SCMP, STD, диаграмма Гантта по исполнению плана проекта; архив трекера.

1.2.2.1. ДП-1. Структура и вид документации

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

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

1.2.2.2. ДП-2. Содержание документации

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

1.2.3. Руководства пользователей по сервисам:

- Сервис абонентов

- сервис баннеропоказа, статистики и биллинга

- сервис клиентов и партнеров, включая веб-сайт

- сервер отгрузки приложений

- мобильные приложения (iPhone, Symbian)

1.2.4. руководства по эксплуатации (администратор и оператор со стороны заказчика):

- Сервер DTN

- Сервис абонентов

- сервисы баннеропоказа, статистики и биллинга

- Справочник виртуальных имен

- сервис клиентов и партнеров, включая веб-сайт

- сервер отгрузки приложений;

- требования к составу, настройкам и эксплуатации аппаратной части на 1 год эксплуатации

1.3. Развитие SPMP

Данный SРМР в основном следует стандарту IEEE 1058.1-1987, поддерживается, и изменяется по ходу реализации проекта его координатором.

1.4. Ссылочные материалы


Бредихин А.Ю. и Сергейчев Н.Е. Логическая структура сервера DTN-имен. Версия 1.0 Бредихин А.Ю. и Сергейчев Н.Е. DTN. Концепция. Версия 1.0

3. Спецификации и «Общая часть»

4. Бредихин А.Ю. и Сергейчев Н.Е. Структура WEB-сервиса пользователя. Верисия 1.0 5.

Стандарты ведения программных проектов IEEE6. Система управления проектом (redmine): http://team.llx.ru/redmine/

1.5. Определения и аббревиатуры (Глоссарий)

Абонент – пользователь терминала мобильной связи, который выполняет поиск и инициирует голосовой вызов посредством своего терминала связи, с помощью клиентской программы продукта или клиентского wap-сайта.Артефакт — окончательный или промежуточный материал проекта (например, документ, исходный код, объектный код, результат теста). Исполнители работ (ИР) – непосредственные исполнители работ по производству продукта и контролю качества продукта.Пользователь системы – любой человек, который воспользовался одним из сервисов системы F&CРуководство проекта (РП) – заказчики работ по проекту, осуществляющие контроль исполнения и качества работ.

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

DTN имя – буквенная последовательность, составленная по принципу доменных имен или адресов E-mail, используемых в Интернете.

Сервер DTN – имен (DTNS) – организованный по принципу DNS сервис, сопоставляющий DTN-имена с реальными телефонными номерами и осуществляющий переадресацию на них.

SLB – (англ. Service Load Balancer) – распределенная служба балансировки нагрузки, выполняющая функции диспетчера, особенностью службы является ее распределенное построение.

Доме́н — область (ветвь) иерархического пространства доменных имён сети Интернет, которая обозначается уникальным доменным именем.

Доме́нное имя — символьное имя домена. Должно быть уникальным в рамках одного домена. Полное имя домена состоит из имён всех доменов, в которые он входит, разделённых точками. Например, полное имя dennyoi.j-net.ru. (с точкой в конце) обозначает домен третьего уровня dennyoi, который входит в домен второго уровня j-net, который входит в домен ru, который входит в корневой домен. Доменное имя служит для адресации узлов сети Интернет и расположенных на них сетевых ресурсов (веб-сайтов, серверов электронной почты, других служб) в удобной для человека форме.

Доме́нная зона — совокупность доменных имён определённого уровня, входящих в конкретный домен.

Гарантированная анонимность (ГА) – сохранение конфиденциальности телефонного номера, который привязан к DTN-имени. Достигается посредством осуществления


звонка через промежуточную систему голосовой связи с возможностью переадресации звонка (IVR, IP, SIP).

Гарантированная анонимность звонящего (ГАЗ) – сохранение конфиденциальности телефонного номера Абонента, звонящего на DTN-имя. Достигается посредством осуществления звонка через IVR-платформу партнера.

Привязка телефонного номера к DTN-имени типа «название домена» (Н-НД) – привязка одного телефонного номера международного формата к доменному имени любого порядка.

Привязка телефонного номера к DTN-имени типа «адрес E-mail» (Н-НЕ) – привязка одного телефонного номера международного формата к адресу E-mail.

Территориальный фильтр (ТФ) – возможность привязки нескольких номеров телефонов к одному DTN-имени, которые выбираются системой, в зависимости от места нахождения абонента, звонящего на данное DTN-имя.

Временной фильтр (ВФ) – возможность привязки нескольких номеров телефонов к одному DTN имени, которые выбираются системой, в зависимости от времени суток и дня недели совершения звонка абонентом на данное DTN-имя.

Виртуальный номер (ВН) – возможность вместо телефонного номера прописать любой доступный идентификатор голосовой системы общения (например: SIP, Skype и т.д.)

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

Детальная статистика по результатам использования DTN-имени (ДСт) – подробная информация о попаданиях DTN-имени в результаты поиска, просмотрах деталей DTN-имени, запросах номера по DTN-имени и входящим звонкам на DTN-имя за определенный промежуток времени. Предоставляется информация о времени звонков на данное DTN-имя, о номерах на которые производился дозвон, номер абонента, регионах (городах), откуда исходил звонок, графики активности звонков по времени и территории.Корпоративное управление именами верхнего уровня (КУ) – управление несколькими DTN-именами одного класса (например: адреса E-mail одного домена или домены третьего уровня одного домена второго уровня) по одному паролю доступа. Данному управлению не поддаются доменные имена первого уровня, некоторые имена второго уровня, например com.ua; также данное управление не может распространяться на адреса E-mail бесплатных почтовых серверов типа mail, rambler, gmail и т.д.

СУБД – система управления базами данных, специализированная программа (чаще комплекс программ), предназначенная для организации и ведения базы данных.

Справочник виртуальных имен – специализированный поисковик, который ищет в WEB доменные имена и адреса почты, определяет по контенту страниц связанные с ними телефонные номера и заполняет базу DTN-имен.

Сервис билинга - (англ. billing — составление счёта) — в некоторых видах бизнеса, в частности в телекоммуникациях — автоматизированная система учёта предоставленных услуг, их тарификации и выставления счетов для оплаты.

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


Сервис абонентов – сервис системы, обслуживающий запросы от абонентов системы.

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

Сервис WEB-пользователей – сервис системы, обслуживающий запросы от клиентов системы.

Поисковый индекс – (индекс поисковой машины) — процесс собирания, разбора и сохранения данных с целью облегчить быстрый и точный поиск информации. Цель использования индекса — в улучшении скорости и быстродействия при поиске релевантных документов по поисковому запросу. Без индекса поисковая машина должна была бы сканировать каждый документ в корпусе, что потребовало бы большого количества времени и вычислительной мощности. Например, в то время как индекс 10 000 документов может быть опрошен в пределах миллисекунд, последовательный просмотр каждого слова в 10 000 больших документов мог бы занять часы. Дополнительное хранилище, требуемое для хранения индекса, а также значительное увеличение времени, требуемого для его обновления, являются компромиссом за экономию времени при поиске информации.

Релевантность поискового запроса - (англ. relevant) — применительно к результатам работы поисковой системы и экспертной системы — степень соответствия запроса и найденного, то есть уместность результата. В более общем смысле, одно из наиболее близких понятию качества «релевантности» — «адекватность», то есть оценка степени соответствия, но и степени практической применимости результата, а также степени социальной применимости варианта решения задачи.

МЭ - (Межсетевой экран или сетевой экран) — комплекс аппаратных или программных средств, осуществляющий контроль и фильтрацию проходящих через него сетевых пакетов на различных уровнях модели OSI в соответствии с заданными правилами.

Пользователь системы – абонент или клиент системы.CMM - Capability Maturity Model — модель зрелости процессов создания ПО: эволюционная модель развития способности компании разрабатывать программное обеспечение. STD – Software Test Documentation. Документация по тестированию.

SCMP - Software Configuration Management Plan.SDD – Software Design Description. Описание структуры продукта.SRS – Software Requirement Specification. Требования к проекту, Техническое Задание.SPMP – Software Project Management Plan. План управления проектом.

SVVP - Software validation & verification plan. План валидации и верификации.Пользователь системы – абонент или клиент системы.Модератор домена - корпоративный клиент - администратор домена.Технический модератор - клиент системы и сотрудник владельца системы, который имеет возможность управлять созданными другими клеинтами сущностями (DTN-именами, дополнительной инофрмацией, рекламными кампаниями, и т.д.)супермодератор - клиент системы и сотрудник владельца системы, который имеет возможность управлять всеми сущностями системы.Интерфе́йс — совокупность средств и методов взаимодействия между элементами системы.Графи́ческий интерфе́йс по́льзователя (ГИП) — разновидность пользовательского интерфейса, в котором элементы интерфейса (меню, кнопки, значки, списки и тп.), представленные пользователю на дисплее, исполнены в виде графических изображений.


2. Организация процесса

2.1. Модель процесса

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

Таблица итераций работ и соответствие им тестов

Этап Результат Кто тестирует Типы тестирования

Разработка (протототипы)Альфа версия 0.1 – 0.9

Прототипы на разных уровнях детализации

Программисты. Представители заказчика.На определенном этапе подключается команда тестировщиков

Функциональное

Альфа 0.9 Рабочий прототип всей системы

Группа тестированияПредставители заказчика

ЮнитНагрузочноеФункциональное

Развертывание на «боевом» оборудованииБета 1 Рабочая версия

системыГруппа тестирования.Привлечение доверенных пользователей

ЮнитНагрузочноеФункциональное

Бета 2 Рабочая версия системы

Группа тестирования.Привлечение расширенного круга заинтересованных пользователей

Функциональное

Релиз-кандидат Релиз 1.0 Пилотное тестирование.Рекламная кампания.Открытое бесплатное использование системы

Пилот

2.2. Организационная структура

Команда проекта состоит из:

- Группы Заказчика, включая Лидера проекта

- Координатора проекта

- группы разработки веб-сервиса клиентов и партнеров, включая веб-сайт сервиса DTN


- сотрудника разработки справочника виртуальных имен

- группы разработки сервера отгрузки. Работы выполнены и приняты 07.2010

- внешней компании по разработке юзабилити. Работы выполнены и приняты 08.2010

- 2 группы по разработке клиентских приложений: iPhone и Symbian. Работы выполнены 01.2011

- группы системного анализа и тестирования


Заказчик

(Лидер проекта)

разработк справочника виртуальных именГруппа разработки ,Включая сайт findandcall.comГруппа разработки сервера отгрузки

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

Группа

тестирования

Компания по юзабилити

2.3. Организационные рамки и взаимосвязи

Структура взаимосвязей показана на рис. 2

Рис. 2.

2.4. Ответственность за проект

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

Ответственность за координацию работ, сроков и их соблюдение лежит на координаторе проекта.

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


Легенда:О – Ответственный

У – участник работ (исполнитель или консультант)

И – сотрудник должен быть проинформирован о результатах работ

Таблица 1

Группа

Справочника виртуальных

имен

Группа сервера

отгрузки

Группа разработки

сервера ДТНи веб-разработки

Группа тестиров

ания

Компания юзабилити

Сервер DTN И - О УСервис баннеропоказа, статистики и биллинга

- И У У О

Сервис абонентов

- И У У

Серверная часть сервиса клиентов и партнеров

И - У У

Веб-сайт, включая открытую и закрытую (клиентскую) области

И И О У = П О – в части разработки юзабилити

Сервер отгрузки приложений

- О И У О – в части разработки юзабилити

Мобильное приложение для iPhone

И И У У О – в части разработки юзабилити

Мобильное приложение – Java апплет

И И У У О – в части разработки юзабилити

Сервис мониторинга

- - И У

3. Управляющий процесс

3.1. Цели и приоритеты

Высший приоритет имеет достижение заданного уровня качества в соответствии с содержанием продукта, описанным в Техническом задании (SRS, ТЗ сервер отгрузки, ТЗ сайта).


На втором месте по приоритетности стоит выполнение проекта в срок. Допустимой считается задержка, не превышающая 10% от запланированной на момент утверждения SRS длительности.

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

3.2. Допущения зависимости и ограничения

Отклонения («нуль-дефекты»):

По срокам: до 10% от запланированного графика при соблюдении заданного уровня качества в соответствии с SRS

По качеству: до 15% от показателей, установленных в описании содержания проекта (документ SRS)

3.3. Управление рисками

В управление рисками должны быть вовлечены все участники команды проекта.

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

При управлении рисками члены команды проекта должны вести учет рисков, реагирования на них и достигнутых результатов/последствий рисков в файле RiskMatrix.xls (или ods) следующего формата:

Назв

ание

рис

ка

Опис

ание

во

змож

ного

эф

фек

та

(биз

нес-

эфф

ект)

Веро

ятно

сть

(р)

Степ

ень

возд

ейст

вия

(i) Оцен

ка р

иска

(e) =

p*

i

Триг

гер

(иде

нтиф

ицир

ующ

ее

собы

тие)

Мер

опри

ятия

по

пред

отвр

ащен

ию

риск

а (П

реве

нтив

ные)

Мер

опри

ятия

по

комп

енса

ции

наст

упив

шег

о ри

ска

Отве

тств

енны

й

Стат

ус р

иска

Дата

акт

уали

заци

и

Резу

льта

т

Вероятность и Степень воздействия оцениваются экспертно. Степень воздействия оценивается по шкале от 1 до 5, где 1 – незначительное воздействие на проект, 5 – критичное, могущее привести к неудаче проекта.

Статус риска = Выявленный/Игнорируемый/Неактуальный/Наступивший

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

Мероприятия по предупреждению или компенсации рисков оформляются в системе Trac как тикеты.

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

- Высокоприоритетные риски

- Новые риски


- Наступившие риски

- Преодоленные риски (ставшие неактуальными в результате выполненных мероприятий)

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

Лидеры групп формируют отчеты в рамках своих работ. Координатор проекта формирует сводный синтетический отчет.

3.4. Механизм мониторинга и контроля

3.4.1. Любые артефакты проекта считаются принадлежащими к проекту, если они зафиксированы в системе redmine по адресу:

3.4.2. Текущий контроль и мониторинг проводят лидеры групп (см. Таблицу 1)

3.4.3. Координатор проекта проводит еженедельный контроль артефактов на предмет их соответствия документации проекта (SPMP, SRS, SQAP, SVVP, SCMP)

3.4.4. Лидеры проекта проводят обсуждение (очное, дискуссии в redmine, скайп, эл. почта) по результатам итераций и вех с принятием решений о корректировке и продолжении работ (см. документ SQAP).

3.5. План расстановки кадров

Проект реализуется помодульно (сервисно) с привлечением 4 групп разработки и группы тестирования. Состав групп показан на рис. 1б. Ответственность групп по сервисам приведена в Таблице 1.

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

4. Технический процесс

4.1. Методы, инструменты и технологии

Разработка ведется итерационным методом

Основной инструмент управления и контроля разработки – система redmine

Хранилище документов – система redmine Хранилище исходного кода -

Технологии:

Операционная система для серверного оборудования Debian GNU/Linux 5.2 (Lenny) или Ubuntu server 9.04; Межсетевой экран iptables; Веб-сервер nginx; Среда разработки и эксплуатации (фреймворк): Виртуальную java-машину для запуска приложений Sun Java VM 6 или Jrocket; Cистему контроля версий Subversion; Cистему мониторинга состояния программного и аппараного обеспечения Nagios 3; Систему управления базами данных Postgresql 8.3 и выше;


Систему кластеризации дла Postgresql Slony-I версии 2 и выше; Систему распределения нагрузки для Postgкesql pgbouncer; Систему поиска BING;

4.2. Документация ПО

4.2.1. Проектная документация в соответствии с разделом 4.2. документа SQAP

4.2.2. Документация на ПО в соответствии со стандартом IEEE (руководства для разработчика, оператора/администратора, пользователя)

4.2.3. Отчеты по достижению вех проекта

4.3. Функции сопровождения проекта

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

5. Распределение работ, план-график и бюджет

5.1. Распределение работ

Распределение работ по группам приведено в Таблице 1. Распределение работ внутри группы является задачей ее лидера.

5.2. Зависимости

5.2.1. Итерационная зависимость

Состав работ в итерации n зависит от результатов итерации n-1. Окончательное утверждение состава работ итерации n производится в итоговом отчете по итерации n-1.


Группа справочника виртуальных имен Группа сервера отгрузки(+ юзабилити)

Группа Веб - разработки

Группа Грувител

Взаимодействие с БД и слоем бизнес-логики

Запись в БД виртуальных DTN имен

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

Учет и контроль версионности приложений абонентов

5.2.2. Функциональная зависимость

Функциональная зависимость – это зависимость работ группы Х от результатов работ группы У. Схема зависимостей приведена на рис. 3. и строится на основе Таблицы 1.

5.3. Потребности в ресурсах

Спонсор проекта – 1Лидер проекта – 1Координатор проекта – 1Группа Грувител – 5Группа веб – разработки - 3Группа справочника виртуальных имен – 1Группа сервера отгрузки – 2(аутсорс)Группа тестирования – 3Компания по разработке юзабилити


5.4. План-график

КАЛЕНДАРНЫЙ ПЛАН

г. Москва «12» ноября 2009 г.

Текущая редакция от «30» января 2010 г.

Текущая редакция о т «02» апреля 2010 г.

п/п Задача Начало Окончание Исполнитель

1(Статистика) Построить Базу Данных системы статистики (БД) 16.11.09 18.11.09

2(Билинг) Разработать программный интерфейс взаимодействия с сервисом баннеропоказа 16.11.09 23.11.09

3 (Статистика) Реализовать внутреннюю систему логирования 18.11.09 25.11.09

4 (DTNS) Разработать интерфейс регистрация DTN-имени 16.11.09 30.11.09

5(Статистика) Реализовать внесение данных по результатам поиска DTN-имен 25.11.09 04.12.09

1-вирт Реализовать 1-й вариант справочника виртуальных имен 05.12.09

1-тестПровести тестирование поиска по справочнику виртуальных имен 08.12.2009 10.12.09

2-тестПровести тестирование поиска и внесения данных на DTN сервере

6 (Билинг) Разработать модуль движения средств по счету 30.11.09 09.12.09

7(DTNS) Действия с регистрационными данными пользователей 30.11.09 11.12.09

8(Статистика) Реализовать внесение данных о просмотре информации по DTN-имени 04.12.09 15.12.09

3-тестПровести тестирование поиска данных с последующим контролем информации о просмотре DTN имени

9(Билинг) Разработать модуль протоколирования движения средств 09.12.09 21.12.09

10 (Статистика) Реализовать внесение данных о звонке 15.12.09 24.12.09

1-сайтБэк-офис сайта: роли Модератор и технический модератор домена 24.12.09

11(DTNS) Разработать взаимодействие сервиса абонентов с абонентскими приложениями 11.12.09 25.12.09

14 (Билинг) Разработать модуль конвертирования валют 14.12.09 22.12.09

12(Билинг) Разработать модуль периодического списания средств (абонентская плата) 25.01.09 05.02.10

1-инфрастр. Исследование вариантов построения инфраструктуры 18.11 30.12.09Окончание этап 1 (Предварительная готовность продукта) 31.12.09 31.12.09

4-тест Провести тестирование версии А 0.1 10.01.10 20.01.10

13(DTNS) Разработать взаимодействие сервиса абонентов с сервисом DTN-имен 14.12.09 22.01.10

15(Интерфейсы) Создать административный интерфейс системы 11.12.09 26.01.10

0-отгрузка Usability пользовательских интерфейсов сервиса отгрузки 29.12.2009

1-отгрузка Готовность сервера отгрузки 15.01.2010 27.02.10

5-тестПротестировать взаимодействие бэк-офиса сайта с результатами поиска DTN-сервера 27.01.10 30.01.10

16(DTNS) Разработано взаимодействие сервиса абонентов с рекламной платформой 20.01.10 26.01.10

17(DTNS) Разработано взаимодействие сервиса DTN-имен с сервисом статистики 26.01.10 29.01.10

6-тест

Протестировать взаимодействие поиска и статистики, включая бэк-офис сайта (модератор, технический модератор, пользователь клиента) 22.01.10 29.01.10

18(Билинг) Сопряжение биллинга с AAA-сервером FreeRADIUS 25.01.10 29.01.10

19 (Билинг) Функциональное тестирование билинга 29.01.10 04.02.10

20 (Статистика) Реализовать выдачу данных 24.12.09 09.02.10


D, 30.01.10,

Срыв сроков на 1 неделю. Риск № 7


21 (DTNS) Разработан поиск и индексация 26.01.10 22.02.10

2-вирт(Вирт. имена) Разработан и наполнен справочник виртуальных имен 25.02.10

3-виртОтработан механизм перевода доменных имен из виртуальных в DTN-имена 01.03.10

2-сайт Концепция юзабилити сайта 11.01.10 15.02.10

3-сайт1-я версия ТЗ (SRS) на сайт findandcall.com

21.01.2010 07.02.2010

4-сайт

SRS или ТЗ на сайтИзменение: ТЗ разрабатывается параллельно с юзабилити и разработкой 11.01.2010

15.02.201015.04.2010

4-сайт

Готовность юзабилити сайтаИзменение: ТЗ разрабатывается параллельно с юзабилити и разработкой 15.02.10

15.03.1015.04.2010

2-инфрастр. Разработана промышленная инфраструктура (прототип) 26.02.2107-тест Провести тестирование сервера отгрузки 01.03.2010 15.03.10

22 (DTNS) Провести функциональное тестирование 22.02.10 26.02.10

Окончание этапа 2 (Окончательная готовность продукта) 26.02.10 26.02.10

8-тест Тестирование Заказчика 15.03.1030.03.10

05.04.2010

9-тест Стрессовое нагрузочное тестирование 01.02.10 05.02.1010-тест Анализ результатов тестирования 01.04.10 10.04.210

Доработка по результатам тестирования 12.04.210 20.05.1023-1 Usability Symbian 11.01.10 03/02.10

23 (Symbian) Создать Symbian-клиент 03.02.10 28.05.10

11-тестПровести функциональное тестирование Symbian – клиента, включая совместимость с сервером отгрузки 22.05.10 31.05.10

12-тест Провести юзабилити-тест Symbian – клиента 22.05.210 31.05.10общие Получение статуса разработчиков Apple 15.01.2010 15.02.2010

24 (iPhone) Создать iPhone-клиент 29.01.10 22.03.1025 Размещение iPhone клиента в Apple Appstore 01.03.10 20/05.101-

сопровождение Общий порядок и шаблоны документов по сопровождению 01.03.2010 19.03.2010

5-сайт

Готовность сайта (сборка: верстка, подключение функционала)Изменение: сайт разрабатывается параллельно с ТЗ и с юзабилити по мере выдачи экранов

15.03.1025.03.2010

15.04.1030.05.2010

13-тест

Тестирование сайтаПеренесено из-за изменения порядка разработки сайта на параллельно с юзабилити 11.05.10 30.05.10

14-тестПровести функциональное тестирование iPhone – клиента, включая совместимость с сервером отгрузки 12.03.10 31.03.10

15-тест Провести юзабилити-тест iPhone – клиента 12.03.10 31.03.10Готовность системы биллинга 20.02.2010 15.04.2010

2 - сопровождени

еДокументы по сопровождению. Предварительный состав команды сопровождения. 15.04.2010 31.05.2010

3-сопровождени

е Раздел поддержки на сайте 15.06.201016-тест Функциональное тестирование продукта (сквозное) 01.06.210 15.06.10

Окончание этап 3 (Готовность клиентских приложений) 26.05.10 26.05.10

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

4-инфрастр. Развертывание на промышленной инфраструктуре

17-тестБета тестирование с привлечением доверенных пользователей 15.06.10 30.06.10

26 Доработка по результатам бета-тестирования 01.07.10 15.07.10

18-тестТестирование релиз-кандидата, включая сопровождение и поддержку пользователей 15.07.10 15.08.10


D, 20.03.10,

Сроки расширены из-за сдвига подготовки группы тестирования


27Доработка (debug) по результатам эксплуатации релиз-кандидата 01.08.10 25.08.10

4-сопровождение

Доработка режима сопровождения и поддержки. Подбор и инструктаж группы поддержки 01.08.10 25.08.10

Запуск системы F&C01/09/201

1


Documents

ddintsis.files.wordpress.com … · Web viewБраузер Web пользователя5. Мобильное устройство ... Мобильное приложение –