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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


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

Информация:

Тип работы: контрольная работа. Добавлен: 14.10.2012. Сдан: 2012. Страниц: 17. Уникальность по antiplagiat.ru: < 30%

Описание (план):


?Лабораторная работа №1 (4 час).
Тестирование программного обеспечения.
Описание тестируемой системы и ее окружения.
 

Теоретическая часть.

 
После согласования «Документа Бизнес-Требований», необходимо представить бизнес-требования в виде, понятном для команды разработчиков. С этой целью создается «Спецификация Требований к ПО» или ее упрощенный аналог – «Функциональная Спецификация». Основная задача этих спецификаций – представить требования к системе с точки зрения функционала, который система должна реализовать. «Техническая Спецификация» создается на основании «Функциональной Спецификации» и ее основная задача – определить и задокументировать архитектуру разрабатываемой системы. «Техническая Спецификация» спецификация служит основанием для начала непосредственной разработки системы.
«Документ Бизнес-Требований» представляет требования к системе с точки зрения бизнеса. На основании «Документа Бизнес-Требований» аналитик должен сформировать «Спецификацию Требований к ПО» или ее упрощенный вариант «Функциональную Спецификацию».
«Спецификация Требований к ПО» описывает поведение системы и ее функционал используя функциональные требования. Помимо этого Спецификация содержит нефункциональные требования, или требования к качеству сервиса.
Функциональные требования определяют, какие функции система должна реализовывать и предоставлять пользователям или внешним системам. Функциональные требования также называются сценариями использования (use cases). Они могут определять требования как к внешнему функционалу (видимому пользователям и внешним системам), так и к внутреннему функционалу (внутренние сервисы системы, например, аудит изменений, журнал событий и т.п.).
Нефункциональные требования, или требования к качеству сервисов, определяют ограничения, накладываемые на функциональные требования к системе, или условия, в которых система должна будет функционировать. Примеры нефункциональных требований: пропускная способность сети, производительность системы, доступность, условия лицензирования и т.п.
Структура Спецификации может быть следующей:
1.                   Название документа и его версия;
2.                   Название проекта и код;
3.                   История Изменения Документа: дата, автор, краткое описание изменения, измененные разделы;
4.                   Список Согласования: ФИО, роль в проекте, подпись, дата (в случае использования системы электронного документооборота и системы электронной подписи последние два атрибута могут быть опущены);
5.                   Оглавление;
6.                   Перечень Рисунков;
7.                   Перечень Таблиц;
8.                   Введение: краткое описание целей создания документа и его содержания. Необходимо дать ссылку на «Документ Бизнес-Требований» и его версию, который использовался при создании Спецификации;
9.                   Функциональные Требования:
1) Код и название требования;
2) Описание;
3) Входные/Выходные Данные;
4) Интерфейс Пользователя: описание требований к интерфейсу пользователя с макетами экранов;
5) Системный Интерфейс: описание требований к интерфейсу системы, который будет использоваться внешними системами;
6) Зависимости: ссылки на функциональные требования, которые зависят от данного требования. Можно создать «Матрицу Трассировки Функциональных Требований», подобную описанной в статье «Управление Требованиями». В этом случае данную секцию можно опустить;
10.               Нефункциональные Требования:
1) Код и название требования;
2) Описание;
11.               Предположения и Ограничения: результаты уточнения деталей реализации требований, которые по явным причинам не были покрыты в «Документе Бизнес-Требований», должны быть указаны в этом разделе;
12.               Открытые Вопросы: все открытые вопросы, возникающие в процессе формирования документа, должны быть перечислены в этом разделе с указанием разделов, где они покрыты;
13.               Ссылки на дополнительные материалы (функциональные модели, модели данных и т.п.).
«Функциональная Спецификация» отличается от «Спецификации Требований к ПО» тем, что она не содержит нефункциональных требований. В силу этого, структура «Функциональной Спецификации» может быть следующей:
1.                   Название документа и его версия;
2.                   Название проекта и код;
3.                   История Изменения Документа: дата, автор, краткое описание изменения, измененные разделы;
4.                   Список Согласования: ФИО, роль в проекте, подпись, дата (в случае использования системы электронного документооборота и системы электронной подписи последние два атрибута могут быть опущены);
5.                   Оглавление;
6.                   Перечень Рисунков;
7.                   Перечень Таблиц;
8.                   Введение: краткое описание целей создания документа и его содержания. Необходимо дать ссылку на «Документ Бизнес-Требований» и его версию, который использовался при создании Спецификации;
9.                   Функциональные Требования:
1) Код и название требования;
2) Описание;
3) Входные/Выходные Данные;
4) Интерфейс Пользователя: описание требований к интерфейсу пользователя с макетами экранов;
5) Системный Интерфейс: описание требований к интерфейсу системы, который будет использоваться внешними системами;
6) Зависимости: ссылки на функциональные требования, которые зависят от данного требования. Можно создать «Матрицу Трассировки Функциональных Требований»;
10.               Предположения и Ограничения: результаты уточнения деталей реализации требований, которые по явным причинам не были покрыты в «Документе Бизнес-Требований», должны быть указаны в этом разделе;
11.               Открытые Вопросы: все открытые вопросы, возникающие в процессе формирования документа, должны быть перечислены в этом разделе с указанием разделов, где они покрыты;
12.               Ссылки на дополнительные материалы (функциональные модели, модели данных и т.п.).
«Техническая Спецификация» содержит описание архитектуры разрабатываемой системы. Это технический документ, который создается на основании «Функциональной Спецификации» архитектором системы. «Техническая Спецификация» служит основанием для начала разработки системы. Структура Спецификации может быть следующей:
1.                   Название документа и его версия;
2.                   Название проекта и код;
3.                   История Изменения Документа: дата, автор, краткое описание изменения, измененные разделы;
4.                   Список Согласования: ФИО, роль в проекте, подпись, дата (в случае использования системы электронного документооборота и системы электронной подписи последние два атрибута могут быть опущены);
5.                   Оглавление;
6.                   Перечень Рисунков;
7.                   Перечень Таблиц;
8.                   Введение: краткое описание целей создания документа и его содержания. Необходимо дать ссылку на «Функциональную Спецификацию» и ее версию, которая использовался при создании «Технической Спецификации»;
9.                   Архитектура Системы: техническое описание архитектуры системы;
10.               Системные Интерфейсы:
1) Используемые Интерфейсы: описание интерфейсов с внешними системами, используемых разрабатываемой системой;
2) Предоставляемые Интерфейсы: описание интерфейсов, предоставляемых внешним системам;
11.               Схема Базы Данных;
12.               Предположения и Ограничения: результаты уточнения деталей реализации требований, которые по явным причинам не были покрыты в «Функциональной Спецификации», должны быть указаны в этом разделе;
13.               Открытые Вопросы: все открытые вопросы, возникающие в процессе формирования документа, должны быть перечислены в этом разделе с указанием разделов, где они покрыты;
14.               Ссылки на дополнительные материалы (внешние файлы моделей, описание интерфейсов и т.п.).
 
 

Требования к отчету по лабораторной работе

Отчет должен содержать:
1.       Постановку задачи, согласно индивидуальному варианту.
2.       Технические требования (FS), оформленные по образцу приведенному в лабораторной работе.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ОБРАЗЕЦ
 
 
 
 
 
 
Документ-концепция разработки версии 2.1 системы MyProject
 
 
              Версия 2.13
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


История изменений
 
Дата
Версия
Описание
Автор
28 мая 2008 г.
1.0
Документ создан в первой редакции
Иванов
29 мая 2008 г.
1.0
Детализировано большинство требований на основе дополнительной информации
Иванов
9 июня 2008 г.
1.1
Добавлены общие требования по переносу телефонов в текст объявления
Иванов
11 июня 2008 г.
1.2
Добавлено требование по учету существующих платежей системы при разноске оплаты (Кавер И.)
Иванов
17 июня 2008 г.
1.3
Модифицированы и детализированы требования после обсуждения с заинтересованным лицом
Иванов
18 июня 2008 г.
1.4
Внесены поправки к требованиям верстки и создания счета
Иванов
26 июня 2008 г.
1.5
Добавлены требования по маркировке объявлений от рекламодателя, справке
Иванов
10 июля 2008 г.
1.6
Изменены требования по задаче авторубрик
Иванов
 
23 июля 2008 г.
1.7
Добавлены требования по  разработке функций, аналогичных функциям CompareMeaningful и Upper2,внедрению новой версии Stimulsoft Reports .NET, исправлению существующих ошибок, поддержке версий для шаблонов, внесению изменений в механизм аутентификации пользователей, дизайнеру формы ввода объявлений
Гальперин А.
8 августа 2008 г.
1.8
Внесена поправка в задачу замены функций CompareMeaningful и Upper2 по реализации средствами СУБД
Иванов
18 августа 2008 г.
1.9
Добавлено требование по конфигурированию прокси сервера и строки соединения с сервером
Иванов
22 августа 2008 г.
1.10
Изменены требования по импорту объявлений. Предполагается, что в счете всегда есть карта стоимости разных видов объявлений
Иванов
8 сентября 2008 г.
2.0
Изменены версия и название проекта. Проект – подсистема версии 2.1.
 
Добавлены и описаны итерации 2.1:
- Интеграция АРМ: выгрузка данных
- Автоматическое обновление клиента
- Автоматическое обновление сайта
- Поддержка фона объявлений
- Импорт модульных объявлений
- Поддержка импорта/экспорта MySQL
- Оптимизация nconvert
- Оптимизация упреждающего чтения
Иванов
25 сентября 2008 г.
2.1
Добавлены задачи 5.41 и 5.42, добавлено требование проверки даты при проверки совпадений номеров заявок при импорте
Иванов
29 сентября 2008 г.
2.2
Внесены дополнения к требованиям по поддержке операций ручной разноски на основе сведений заказчика
Иванов
1 октября 2008 г.
2.3
Добавлены требования по выбору главного регионального департамента при удаленной работе серверов
Иванов
1 октября 2008 г.
2.4
Модифицированы требования по хранению настроек соединения программы в задаче 5.32
Иванов
6 октября 2008 г.
2.5
Детализированы требования по импорту базы данных MySQL Ярославль
Иванов
13 октября 2008 г.
2.6
Внесены изменения и дополнения в требования привязки счета к объявлениям (5.7), в требования к верстке и настройке шаблонов системе верстки (5.41)
Иванов
16 октября 2008 г.
2.7
Дополнены требования по импорту объявлений 5.36 и 5.38
Иванов
17октября 2008 г.
2.8
Дополнены требования по поддержке типа объявления в конкретном выпуске объявлений 5.36 и 5.38
Иванов
20 октября 2008 г.
2.9
Добавлена задача 5.49 по оптимизации поиска объявлений по телефону
Иванов
21 октября 2008 г.
2.10
Модифицированы требования к задаче авторубрик (5.10)
Иванов
29 октября 2008 г.
2.11
Модифицированы требования к задаче автоматической генерации номеров счетов и заявок (5.44)
Иванов
6 ноября 2008 г.
2.12
По причине конфликта требований к поддержке введенных вручную платежных документов при разноске и повторной разноски фиктивных документов, задача замены фиктивных платежных документов удалена из 5.45.
Иванов
7 ноября 2008 г.
2.13
Учтены замечания по задаче 5.45 «Связывание счета на оплату с платежным документом и поддержка карты стоимости». Изменены требования по задаче.
Иванов
 
 
Содержание
 
 
1 Вступление
1.1 Назначение
1.2 Обзор проекта
2 Пользовательская среда
3 Основные потребности пользователя
4 Обзор проекта
4.1 Обзор возможностей системы и их атрибутов
4.1.1 Атрибуты функций системы
4.1.2 Функции системы
5 Задачи проекта
5.1              Настройки
5.2              Формы поиска
5.2.1              Общие модификации
5.2.2              Новые формы
5.4              Ввод единым текстом
5.8              Импорт объявлений из файла импорта
5.22              Исправление существующих ошибок
5.25              Дизайнер формы ввода объявлений.
5.49 Оптимизация поиска объявлений по телефону
6 Другие требования
6.1 Требования по производительности
6.2 Требования к инсталляции и развертыванию



 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

1 Вступление

 
Данный документ освещает набор требований верхнего уровня для расширения системы MyProject и ее оптимизации с точки зрения ввода объявлений. Оптимизация включает в себя разработку новых режимов ввода объявлений, более детальную настройку работы операторов, кэширование данных. К расширениям относятся модификации по разработке зависимых справочников, новых подвидов объявлений, специальных рубрик изданий, отчетов и функций импорта объявлений. Данная итерация проекта также включает в себя работы по разработке возможности верстки в новых системах и поддержке новых версий 1С.
 

1.1 Назначение

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

1.2 Обзор проекта

 
Данный документ включает описание новых функций, которые необходимо добавить к существующей информационной системе MyProject, в ходе проекта.
 
В рамках проекта необходимо осуществить следующий набор изменений в системе MyProject:
 
-                      Новые настройки для ускоренного ввода
-                      Формы быстрого ввода объявлений
-                      Ввод единым текстом
-                      Зависимые справочники для шаблонов ввода объявлений
-                      Вечные бесплатные объявления
-                      Контроль/проверка строчных объявлений перед публикацией
-                      Привязка счета на оплату к объявлению
-                      Импорт объявлений из файла импорта программы SM Realty и сайта job-box.ru
-                      Расчетные поля статистики
-                      Авторубрики и словари полей шаблона
-                      Новые отчеты
-                      Верстка в Corel Ventura и InDesign
-                      Поддержка введенных вручную платежных документов при разноске
-                      Поддержка 1С 8.1
-                      Кэширование загрузки данных для ввода объявлений и мониторинга
 

2 Пользовательская среда             

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

3 Основные потребности пользователя

 
Основная проблема, с которой сталкиваются пользователи в текущих версиях системы – скорость ввода объявлений. Новая версия имеет своей целью устранение этих проблем путем тонкой настройки процесса ввода для операторов, кэширования данных, обеспечением оптимальной работы с клавиатурой.
 
Также в новой версии учитываются потребности пользователей, использующих системы Corel Ventura и InDesign для верстки изданий.

4 Обзор проекта

4.1 Обзор возможностей системы и их атрибутов

4.1.1 Атрибуты функций системы

 
Каждая функция системы в дальнейшем будет иметь набор связанных атрибутов, определяющих важность, сложность и уровень риска для данной функции.
 
Важность. Атрибут показывает, насколько важна данная функция для продукта с точки зрения пользователей и маркетинга, а также других соображений касательно успеха или удобства продукта
 
Ниже приведен набор таблиц, определяющих возможные значения атрибутов с их описанием.
 
Таблица 1 – Уровни важности для функций программы
 
Уровни важности
Описание
Критическая
Критические функции определяют успех или провал проекта на рынке, или удовлетворение ключевых потребностей пользователей. Критические функции должны быть реализованы в первую очередь в ближайшей версии проекта.
Важная
Важные функции могут повлиять на успех продукта на рынке, и важны с точки зрения пользователя. Такие функции реализовываются с высоким приоритетом как можно раньше.
Желаемая
Желаемые функции позволяют получить более высокий уровень удобства при работе с ПО или делают его более функциональным, привлекательным. Такие функции разрабатываются в последнюю очередь и могут быть исключены из разработки по требованию заказчика.
 
Сложность. Атрибут определяет, насколько сложна  функция с точки зрения ее реализации.
 
Таблица 2 – Уровни сложности для функций программы
 
Уровни сложности
Описание
Высокий
Реализация функции требует использование сложных или трудоемких технологий, подразумевает разработку сложных алгоритмов.
Средний
Реализация требует использование технологий средней сложности или трудоемкости
Низкий
Реализация функции не требует использования сложных и трудоемких технологий и алгоритмов.
 
Уровень риска. Атрибут определяет, насколько реализация данной функция в будущем будет или может отвечать плановым показателям. Уровень риска меняется в зависимости от того, имеется ли опыт разработки таких функций с учетом особенностей разрабатываемого приложения и насколько вероятны задержки или усложнения разработки в силу технологических и др. факторов.
 
 
Таблица 3 – Уровни риска для функций программы
 
Уровни риска
Описание
Высокий
Реализация функции подразумевает использование новой не проверенной технологии, либо подразумевает учет условий, усложняющих ее работу. Также высокий уровень риска характерен для задач с недостаточным объемом входной информации.
Средний
Реализация функции может быть затруднена по причине недостаточных входных данных или сложности или новизны используемых подходов.
Низкий
Реализация функции требует использование проверенных технологий и имеет достаточно информации для точной плановой реализации.

4.1.2 Функции системы

 
Ниже приведен перечень всех функций системы входящих в рамки проекта по разработке подсистемы учета затрат MyProject.
 
Таблица 4 – Функции системы и их атрибуты
 
Функция
Описание
Важность
Сложн.
Риск
Дата
Новые настройки для ускоренного ввода
Разработка новых настроек, необходимых или применяемых для ускорения ввода объявлений операторами
Крит.
Низк.
Низк.
17.06.08
Формы быстрого ввода объявлений
Обеспечить разработку новых форм ввода для оптимизации ввода строчных объявлений
Крит.
Средн.
Средн.
17.06.08
Ввод единым текстом
Обеспечить настройки шаблона, обеспечивающие возможность ввода объявления заданного формата по полям шаблона без использования Tab
Важн.
Низк.
Низк.
17.06.08
Вечные бесплатные объявления
Возможность определения объявлений как вечные и полуавтоматического их продления
Важн.
Низк.
Низк.
17.06.08
Контроль/проверка строчных объявлений перед публикацией
Сводная таблица публикаций строчных объявлений по выбранной рубрики с возможностью модификации
Важн.
Низк.
Низк.
17.06.08
Привязка счета на оплату к объявлению
Возможность привязать счет на оплату к конкретному объявлению, а не только к бланку заявке
Важн.
Низк.
Низк.
17.06.08
Импорт объявлений из файла импорта программы SM Realty и сайта job-box.ru
Разработка специализированного импорта в модуле Импорт/Экспорт для двух новых форматов файлов.
Важн.
Средн.
Средн.
17.06.08
Расчетные поля статистики
Разработка расчетных полей для шаблона рубрики с возможностью задания аналитической формулы расчета значения
Важн.
Высок.
Высок.
17.06.08
Авторубрики и словари полей шаблона
Добавить возможность задания параметров для значений справочников полей шаблона объявлений. Параметры позволяют организовать объявления группы – авторубрики по значениям словарей
Важн.
Средн.
Средн.
17.06.08
Новые отчеты
Разработать набор новых отчетов
Важн.
Средн.
Низк.
17.06.08
Верстка в Corel Ventura и InDesign
Разработать плагины верстки для поддержки новых систем верстки
Важн.
Высок.
Высок.
17.06.08
Поддержка введенных вручную платежных документов при разноске
Для разноски платежей необходимо добавить учет платежных документов, занесенных в саму систему, а не только в 1С.
Жел.
Низк.
Низк.
17.06.08
Разработка справки
Разработать контекстно-зависимую справку для всех существующих модулей системы
Жел.
Низк.
Низк.
20.06.08
Маркировка объявлений по рекламодателю
Добавить возможность автоматической маркировки объявлений от определенных рекламодателей
Важн.
Средн.
Средн.
20.06.08
Модификации сайта 116й версии
Изменить сайт 116й версии в соответствии с новыми требованиями по дизайну и логике работы
Важн.
Низк.
Низк.
20.06.08
Исправление существующих ошибок
Исправление существующих ошибок в системе
Жел.
Низк.
Низк.
23.07.08
Поддержка версий для шаблонов
 
Добавить возможность сохранения измененной копии шаблона, если на основе редактируемого шаблона 
Важн.
Средн.
Средн.
23.07.08
Изменения в механизме аутентификации пользователей             
Внедрить механизм хранения паролей в виде хеша.
Важн.
Низк.
Низк.
23.07.08
Дизайнер формы ввода объявлений.
Добавление возможности редактирования формы для ввода  объявлений.
Жел.
Средн.
Низк.
23.07.08
 
 

5 Задачи проекта

5.1              Настройки

 
Для поддержки описанных в документе изменений предполагается добавить в систему набор настроек:
 
1.                    Рубрика по умолчанию для ввода рекламы. Если указана, рубрика и шаблон задаются для нового объявления автоматически. Если не указана, то ввод работает как обычно.
2.                    Размещение на сайте. Обязательна для задания. Наследуется при вводе нового объявления.
3.                    Источник. Если задан, то наследуется в формах ввода объявлений. Если не задан, то не применяется.
4.                    Ввод изданий одно/два/три/множество. Если указан тип «одно издание», то программа запрашивает издание, и указанное издание задается автоматически в новых формах быстрого ввода с таблицей ближайших выпусков. Для режимов два-три издания для каждого издания создается соответствующая закладка для каждого из изданий с выбранным по умолчанию изданием. Если установлен режим «множество», то в формах быстрого ввода отображается кнопка выпусков. В обычном вводе отображается кнопка публикаций. При удалении издания режим переходит в обычный. Для режимов в несколько изданий программа должна запрашивать каждое из изданий по умолчанию.
5.                    Режим ввода. Обычный (по умолчанию) или быстрый.
6.                    Количество выпусков для отображения при быстром вводе.
7.                    Режим ввода полей шаблона. Единый текст, обычный. В режиме единого текста используются свойства полей шаблона, относящихся к вводу единым текстом.
8.                    Режим ввода телефонов «Обычный» или «только цифры».
9.                    Минимальное количество цифр для режима «Только цифры».

5.2              Формы поиска

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

5.2.1              Общие модификации

 
Ниже описан набор общих модификаций существующих модулей системы. Группировка приведена исходя из разделения необходимых изменений с точки зрения этапов разработки.
 
Поиск
 
1.                    При входе в модули поиска объявлений, а также все модули с возможностью поиска, курсор должен ставиться в первое поле ввода панели поиска (для модулей ввода рекламы – поле Телефон).
2.                    При нажатии Enter производить поиск один раз, и не показывать сообщение о количестве найденных объявлений. Однако оставить сообщение о превышении количества найденных объявлений. Оставить сообщение об отсутствии результатов неизменным.
3.                    После окончания поиска необходимо сфокусировать первое найденное объявление.
4.                    Учесть настройку для ввода телефонов «Только цифры».
 
Ограничения ввода телефонов
 
5.                    Добавить настройку – флаг «Только цифры» для телефонов. В этом случае телефоны при вводе объявления могут содержать только цифры, а также символы «(», «)», «-», «,», «». Поля ввода Телефона при поиске могут включать только цифры. Тем не менее, при вводе данных в телефоны объявления во всех режимах ввода добавить возможность принудительно временно (до закрытия окна ввода) отключить режим ввода «Только цифры» путем выбора соответствующего флага над таблицей телефонов. В обычном режиме ввода телефонов флаг не отображается.
6.                    Добавить настройку минимального количества цифр в телефоне (только для режима Только цифры). Необходимо контролировать при вводе рекламы и при поиске.
 
 
Оптимизация ввода телефонов
 
7.                    Привести алгоритм перенесения телефонов из таблицы в текст рекламы к единой форме для всех модулей ввода. Разработать систему, которая будет автоматически вставлять телефоны в текст при вводе в таблицу, а также производить обратную операцию, проверяя имя поле на соответствие «Тел» или «Телефон» и предполагая, что телефоны разделены запятой.
 
Отображение результатов поиска и списков объявлений
 
8.                    В таблицах результатов поиска показывать не только номер рубрики, но и ее название.
 
Поддержка горячих клавиш
 
9.                    Добавить горячие клавиши для всех поисковых форм программы. F6 – очистка поисковой формы и установка курсора в первое поле. F2 или Enter – поиск.
10.                 На всех формах программы добавить стандартные горячие клавиши: Esc – закрытие диалога с отменой, Enter – закрытие диалога с сохранением (где возможно), F5 – сохранение, F9 – отмена, выбор рекламодателя – F3, издания и выпуски – F4.
11.                 Добавить горячие клавиши для всех окон программы по Alt+?. Необходима поддержка фокусировки полей и нажатия кнопок.
 
Управление рекламой
 
12.                 Кнопки управления объявлениями в модулях ввода. Необходимо добавить кнопки «Создать на основе», «Продлить». Для первой кнопки на основе выбранного объявления заполняются телефоны в новом. Для операции продления доступны лишь функции изменения будущих выходов. По нажатию на существующую кнопку клонирования должна быть создана копия выбранного объявления и открыта на редактирование.
 
Оптимизация ввода данных объявления
 
13.                 Если в фокус при создании нового объявления попадает в уже заполненное поле шаблона с телефоном по Tab, необходимо поставить фокус в следующее за ним поле.
14.                 Сделать проверку ввода хотя бы одного номера в таблице ввода телефонов.
15.                 В зависимости от введенных данных, необходимо отображать режим ценообразования и текущие параметры: количество строк, слов, символов.

5.2.2              Новые формы

 
Клиентская часть
 
1.                    Добавить новые формы ввода для режимов быстрого ввода.
2.                    Для режима ввода «одно издание» осуществлять указание выпусков в основной форме ввода. Выпуски отображаются для издания по умолчанию. Если указан тип «одно издание», то указанное издание задается автоматически в новых формах быстрого ввода с таблицей ближайших выпусков. Для режимов два-три издания для каждого издания создается соответствующая закладка для каждого из изданий с выбранным по умолчанию изданием. Если установлен режим «множество», то в формах быстрого ввода отображается выпадающий список над таблицей выпусков. В обычном вводе отображается кнопка публикаций.
3.                    Соблюсти переход по полям с клавиатуры, как показано на рис. 1 и 2 стрелкой для форм ввода бесплатных и платных объявлений.
4.                    Отображать N ближайших выпусков. Для выбора других изданий и выпусков сделать отдельную кнопку. N настраивается. Для определения следующих выпусков использовать дату сдачи номера (см. ниже).
5.                    При планировании выпусков добавить новый параметр – дата и время сдачи. В процессе автоматического планирования добавить поля ввода – сдача за N дней перед выходом, время сдачи. Использовать эти параметры для задания даты и времени сдачи при автоматическом планировании. После того, как эта дата и время проходит, выпуск считается прошедшим, и ввод данных в него запрещен. Учесть в существующих модулях системы.
6.                    Платные объявления. Для формы быстрого ввода платных строчных объявлений необходимо отображать единую скидку для всех выпусков, как показано на рис. 2 (скидка клиенту в текущей версии).
7.                    Объем скидки должен рассчитываться при изменении поля стоимость на основе прейскуранта. Также при изменении скидки автоматически должна меняться стоимость. В форме ввода можно менять вручную в каждом объявлении как стоимость одного выхода, так и скидку. Если изменили стоимость одного выхода, то и скидка должна поменяться. Если прайсовая стоимость 100 рублей, а оператор ввел 60 руб. - скидка должна стать 40%.
8.                    Для рекламодателя добавить возможность задания карты скидок по умолчанию для изданий. Это означает, что у каждого рекламодателя будет отдельное диалоговое окно для задания скидки в каждом из изданий системы. Для новых рекламодателей и новых изданий скидка везде изначально равна 0. Учесть в существующих модулях системы.
9.                    В случае размещения объявления в нескольких изданиях, следующие поля не отображаются и недоступны для ввода: Издание, Список выпусков, Позиция, Стоимость одного выпуска, Скидка, Тип стоимости, Количество, Цена. Однако отображается совокупная стоимость всех выпусков.
 

Рис. 1 - Ввод бесплатных объявлений
 

 
Рис. 2 - Ввод платных объявлений
 
 
Сайт
 
10.                 Внедрить учет даты и времени сдачи на сайте. Необходимо запрещать ввода в уже сданные номера.

5.4              Ввод единым текстом

 
Для полей шаблона необходимо добавить ряд свойств. Эти свойства используются только при использовании режима ввода полей шаблона единым текстом.
 
Свойства шаблона
 
1.                    Указывается, есть ли перенос строки при отображении полей шаблона ввода. По умолчанию всегда ставится перенос. Если переноса нет, то пол следующее ввода будет отображаться в шаблоне ввода в той же строке.
2.                    Указывается подпись поля. Подпись – это заголовок поля ввода в шаблоне ввода объявления. Необходимость ввода подписи (на данный момент уже существует параметр названия поля) обусловлена невозможностью задать пустое название. Подпись по умолчанию берется равной названию, однако может быть изменена пользователем на пустую, при необходимости.
3.                    Для полей, отображаемых в одну строку необходимо обеспечить возможность отображения подписей длины, равной длине содержащегося в них текста.
4.                    Указывается набор символов для перехода на следующее поле (строка-разделитель). По умолчанию это значение равно постфиксу поля. Однако, может быть изменено пользователем.
5.                    Однако, упомянутые поля применяются лишь в режиме ввода единым текстом. В обычном режиме они игнорируются.
 
Ввод единым текстом
 
6.                    Для режима ввода единым текстом необходимо отображать на экране строки-разделители полей как показано на рис. 3.
7.                    При вводе единым текстом, если обнаружена строка-разделитель, осуществляется удаление строки-разделителя из конца значения поля, автоматически осуществляется переход на следующее поле.
 

Рис. 3 – Ввод объявления единым текстом
 
Цель изменения – получить временной выигрыш при вводе объявлений строго определенного формата.

5.8              Импорт объявлений из файла импорта

 
В модуль импорты/экспорта добавить поддержку формата программы SM Realty. В данной версии разрабатывается поддержка только импорта.
 
Ниже приведено описание формата файла.
 
1-я строка: Дата в формате “dd.mm.yyy”
2-я строка: Время в формате “hh.mm.ss”
3-я строка: Название агентства (без кавычек)
 
Следующие строки – информация об объектах недвижимости:
В одну строку:
11.     Рубрика - (справочник)
12.     Подрубрика - (справочник)
13.     Выделение объявления (справочник)
14.     Микрорайон -  (текст)
15.     Населенный пункт -  (текст)
16.     Улица -  (текст)
17.     Телефон 1 -  (в любом формате)
18.     Телефон 2 -  (в любом формате)
19.     Дата постройки дома -  (год цифрами)
20.     Количество комнат -  (число)
21.     Этаж -  (число)
22.     Этажность -  (число)
23.     Материал - (справочник)
24.     Площадь «Всего» -  (дробное число, кв.м.)
25.     Площадь «Жилая» -  (дробное число, кв. м.)
26.     Площадь «Кухня» -  (дробное число, кв.м.)
27.     Площадь «Земельный участок» -  (текст)
28.     Санузел - (справочник)
29.     Обмен - (произвольный текст)
30.     «Адрес где» для куплю/сниму -  (произвольный текст)
31.     Цена у.е. -  (число) заполняется одно из двух полей «Цена»
32.     Цена руб. -  (число) заполняется одно из двух полей «Цена»
33.     Срочно - (0 или 1)
34.     Торг - (0 или 1)
35.     Долевое участие - (0 или 1)
36.     Дополнительная информация - (произвольный текст)<
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.