1.1. Наименование системы 1.1.1. Полное наименование системы Например:Полное наименование: Факультет дистанционного образования 1.1.2. Краткое наименование системы Например:Краткое наименование: ФДО. Система 1.2.
Основания для проведения работ Перечень документов, на основании которых создается система, кем и когда утверждены документы. Указывается шифр темы или шифр (номер) договора, дата договора. Например:Работа выполняется на основании договора № 123456 от 30.10.2014 между Финансовый университет и ООО «ВКУЛ». 1.3. Наименование организаций – Заказчика и Разработчика 1.3.1.
Заказчик Заказчик: Федеральное государственное образовательное бюджетное учреждение высшего профессионального образования «Финансовый университет при правительстве Российской Федерации» Адрес юридический: г. Москва Ленинградский проспект д 49. Телефон / Факс: +7 (499) 9439829 1.3.2. Разработчик Разработчик: ООО «Всё как у людей» Адрес фактический: г. Москва Ясный проезд д 15.
Телефон / Факс: +7 (495) 4773491 1.4. Плановые сроки начала и окончания работы 30.10.2014 начало работы и окончание работы 25.12.2014 1.5. Источники и порядок финансирования Согласно договору № 123456 от 30.10.2014 между «Финансовый университет» и ООО «ВКУЛ». 1.6.
Этап проектирования и техническое задание (ТЗ) в проектах по автоматизации
Порядок оформления и предъявления заказчику результатов работ Определяется порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы. Например:Работы по созданию информационно системы дистанционного обучения сдаются Разработчиком в конце работы согласно условиям Договора. По окончании Разработчик сдает Заказчику соответствующие отчетные документы, состав которых определены Договором.
2. Назначение и цели создания системы
2.1. Назначение системы
- Образовательная
- Контролирующая
Источник: studfile.net
Разработка технического задания
Целью разработки системы является автоматизация получения и обработки заявок от абонентов.
Данная система будет использоваться в подразделении ПНР.
Базовая концепция бизнес решений представлена на рисунке 13.
Рисунок 13. Базовая концепция бизнес решений
Последовательность действий выполнения бизнес-процесса после автоматизации будет следующей:
1. Просмотр принятых системой заявок от абонентов.
2. Составление отчетной таблицы.
3. Вывод таблицы для просмотра.
4. Принятие заявок на обработку (удаление из базы данных системы).
5. Вывод заявок в текстовые файлы, отсортированные по дате получения заявки.
Бизнес требования к системе разделяются на функциональные и нефункциональные.
ТОП-5 ошибок при автоматизации бизнес-процессов. Почему нет результата? //16+
Функциональные бизнес требования:
· Ввод данных абонентом: название предприятия, описание проблемы, имя, контактный e-mail, телефон/факс, дата заключения договора и его номер.
· Сохранение данных в БД системы.
· Вывод данных в удобной табличной форме.
Нефункциональные бизнес требования:
· Одновременно с системой может работать до 1000 пользователей (ограничение обусловлено работой MySQL — максимальное количество записей одновременно хранимых в базе данных);
· ограничение (снизу) на используемое аппаратное обеспечение: не менее 512Мбайт оперативной памяти, процессор не ниже Pentium III, Windows XP, сервер Apache, MySQL сервер.
Данная работа будет выполнена на основе архитектурной серверной базы данных MySQL Server, Apache, phpMyAdmin и специализированного пакета разработки NuSpherePHP.
Проектные требования к системе:
Ограничение (снизу) на используемое аппаратное обеспечение для клиента:
§ не менее 512Мбайт оперативной памяти,
§ процессор не ниже Pentium III,
§ Интернет со скоростью соединения — не менее 64 kbit/sec.
Ограничение (снизу) на используемое аппаратное обеспечение для сервера:
§ не менее 1024MB DDR2 оперативной памяти,
§ процессор не ниже Intel Quad-Core Xeon E5405 (2GHz),
§ Windows Server Enterprise 2003,
§ Пропускная способность канала Internet — не менее 15 Gbit/sec.
Ограничение на уровень подготовки персонала, эксплуатирующего систему, не накладываются, так как система проста в использовании.
Определение приоритетов разработки.
Существует три категории приоритетов: «оптимизация», «ограничение».
К категории «оптимизация» относятся следующие:
· Ввод данных от пользователя в базу данных
· Вывод данных в табличной форме
· Анализ данных инженерами отдела
К категории «ограничение» относится вывод отчетов из БД системы, содержащий всю информацию по полученной заявке.
Данная информационная система будет построена на основе клиент серверной архитектуры.
Исследование технологии разработки: использование PhpED от корпорации NuSphere.
PhpED — Интегрированная среда разработки для PHP (PHP IDE), HTML, CSS, XML, SMARTY, XHTML и др.
Сбалансированная комбинация усовершенствованного редактора кода, надежная программа отладки, продуктивный клиент соединения с базой данных делают PhpED идеальным приложением для самого искушенного разработчика.
В стремлении идти навстречу растущим потребностям пользователей, NuSphere усилил PhpED теми функциями, которых им не хватало.
Функции и свойства стандартной версии:
· Автоматическая проверка правописания (в режиме реального времени на многих языках).
· Шаблоны кода (завершение, свертывание).
· Просмотр страниц в реальном времени.
· Всплывающие подсказки для функций.
· Линейный анализ ошибок для PHP и HTML.
· Рекламные версии PHP DBG Debugger.
· Локальный PHP Debugger.
· Определение точек прерывания.
· Инструмент запуска страниц.
· Встроенные интернет-браузеры Mozilla и Internet Explorer.
· Работает с любыми внешними браузерами.
· Поддерживает 370 международных групп символов, включая 16 версий UTF, UCS и другие типы кодовых страниц.
· Встроенный SRV- веб-сервер для локальной проверки кода.
· Bundled PHP4 and PHP5, NuSoap библиотека для построения SOAP серверов и клиентских частей.
· NuSphere Technology Platform — комплексное внедрение Apache, Perl, и PHP.
На рисунке 13 представлен интерфейс программы.
Рисунок 13. Интерфейс программы PhpED от NuSphere
Разработка прототипов компонентов.
В данной работе будет использована клиент-серверная технология.
Серверная компонента будет состоять из таблицы, представленной на рисунках 14, 15.
База данных системы содержит три таблицы «org», «main», в которые сохраняются все данные полученные с форм, а так же скрытые служебные данные.
Рисунок 14. Состав базы данных MySQL
Поле id — идентификатор заявки, автоинкримент, имеет первичный ключ, не должно быть пустым, тип integer.
Поле org_name — наименование организации, перехватывает введенные данные с поля ввода на странице добавления записи, тип varchar, максимальная длина 50 байт, не должно быть пустым, уникально.
Рисунок 15. Состав базы данных MySQL
Поле id — идентификатор заявки, автоинкримент, имеет первичный ключ, не должно быть пустым, тип integer.
Поле date — дата получения заявки, носит скрытый характер, добавляется автоматически при отправке данных, используется для сортировки данных при выводе, тип date, не должно быть пустым.
Первое, что видит клиент при входе в систему — это приветственное окно, представленное на рисунке 16.
Рисунок 16. Страница начала работы с системой
На данной странице предлагается перейти к заполнению формы заявки (ссылка «Начать работу с системой») или же на страницу просмотра записей (ссылка «Просмотр записей»).
После нажатия на ссылку «Начать работу с системой» клиент перейдет к следующей странице системы, представленной на рисунке 17.
Рисунок 17. Страница подачи заявки
На данной странице вниманию клиента представлены два текстовых поля. Одно поле «Введите название организации» — однострочное, вмещающее до 100 знаков, второе поле «Введите Вашу проблему с подробным описанием» — многострочное, вмещающее до 10000 знаков. Так же есть две кнопки — «Послать» (отправляет данные из форм в базу данных, прикрепляя к каждому отправленному сообщению дату отправки) и «Очистить» (очищает все текстовые поля без предупреждения сразу после нажатия). При успешном добавлении записи в БД будет выведено сообщение «Ваша запись успешно добавлена». Для корректного заполнения форм вверху страницы представлена ссылка «Пример заполнения формы» (рисунок 18).
Рисунок 18. Страница с примером заполнения форм
На данной странице клиент увидит инструкции по работе с системой. Так же на странице имеются ссылки для перехода по страницам системы — «На главную» (возвращает клиента на главную страницу системы) и «Добавить заявку» (возвращает клиента на страницу добавления заявки).
При нажатии на ссылку «Просмотр записей» на главной странице клиент переходит на страницу просмотра записей.
Будущие инвестиции — данная система будет занимать одно из ключевых мест при принятии заявки от клиента. Так как скорость работы персонала отдела напрямую влияет на конкурентную способность всего предприятия в целом.
Источник: studbooks.net
Значение технического задания при внедрении Битрикс24
Техническое задание — это документ, в содержании которого описываются основные положения; приводится детальное описание функций и опций работы внедряемой CRM, ERP или др. системы в компании. Наша компания считает, что без технического задания очень трудно, а в некоторых случаях (проект трудоемкий и требует вовлечения специалистов из разных областей) просто не реализуем.
Техническое здание пишут специалисты, которые имеют непосредственное отношение к внедрению или дальнейшему использованию CRM, ERP или другой системы. Если техническое задание пишется сотрудниками предприятия-заказчика, то оно, чаще всего, носит формальный характер и не отвечает большой глубиной, т.к. сотрудники не имеют больших познаний во внедряемом продукте. Обычно, в таком техническом задании содержится описание необходимого функционала и даются указания по ключевым моментам внедрения.
- Никто не знает специфику лучше, чем клиент.
- Во время составления технического задания клиент начинает видеть слабые места своего проекта.
- Составляя техническое задание, клиент лучше вникнет в возможности продукта и поймет его полезность, а значит, проще будет проводить внедрение.
- Процесс внедрения начнется с момента начала написания технического задания.
- Не понимая устройства продукта клиент может захотеть того, что на практике либо трудно реализуется, либо вообще нет возможности такое реализовать.
- Зачастую, сроки такого варианта сильно завышаются, т.к. ответственный сотрудник вынужден выделять под данный процесс время и не всегда его будет достаточно.
Не редко бывает так, что клиенты просят компанию-исполнителя самостоятельно разработать техническое задание под их специфику. Этот вариант тоже имеет свои плюсы и минусы.
Давайте их рассмотрим:
- Исполнитель очень хорошо знает весь функционал продукта и может написать максимально подробное техническое задание с учетом особенности внедряемой системы CRM, ERP или другой.
- Сроки написания будут минимальными, т.к. сотрудник компании-исполнителя делает это в рамках своего полноценного рабочего дня и не имеет ограничений и он мотивирован поскорее закрыть данный проект.
- Очень редко компания исполнитель обладает знаниями специфики работы каждого предприятия и поэтому может не учесть при разработке системы CRM, ERP или др. важных элементов (бизнес-процессов).
- Внедрять чужие мысли всегда тяжелее, т.к. очень часто, сотрудники компании-заказчика начинают выискивать изъяны и всячески саботируют процесс.
- Увеличиваются сроки согласования технического задания.
Лучшее решение данного вопроса всегда находится посередине, т.е. необходимо участвовать в написании технического задания двум сторонам в равной или примерно в равной пропорции. Логично предположить, что большая нагрузка придется на компанию-исполнителя, т.к. она владеет большей информацией о продукте и может своевременно вносить необходимые коррективы для выбора оптимального решения при дальнейшем внедрении. Наша практика показала, что соотношение 70:30 (70% исполнитель и 30% заказчик) является самым эффективным и менее затратным по времени, отведенным на реализацию проекта в целом.
В рамках совместной работы быстро проверяются многие вопросы до момента внедрения. Сотрудники компании лучше относятся к внедряемому продукту, т.к чувствуют свою причастность к его разработке. Давайте рассмотрим, что же должно включать в себя техническое задание. Первое, о чем стоит сказать — это цели, которые четко обозначат критерии любого успешного проекта по внедрению.
Китайская мудрость гласит: «Если ты не знаешь куда идешь, то как ты узнаешь, что ты уже пришел?». Помимо основных целей внедрения системы CRM, ERP и др. в техническом задании должны указываться и критерии, по которым можно будет судить об успешности внедрения продукта.
Сразу после стратегической части технического задания идет его тактическая часть, в которой рассказывается о процессе внедрения и обозначаются примерные сроки, которые потребуются для всех этапов в развернутом виде по каждой операции в частности. За тактической частью идет техническое описание всех бизнес-процессов и их исполнение в конкретном продукте (CRM, ERP или др. системе). Немаловажным моментом является назначение ответственных лиц как за весь проект, так и за каждый бизнес-процесс в частности. Если учесть в своем техническом задании все вышеперечисленные моменты, то процесс внедрения пройдет максимально легко и в кратчайшие сроки.
Источник: kosas.ru
