Technical Task

Техническое задание
на разработку программного обеспечения баз данных
1. Термины, используемые в техническом задании
1. Программное обеспечение (ПО, программа для ЭВМ, приложение) – это объективная форма представления совокупности данных и команд, предназначенных для функционирования электронных вычислительных машин (ЭВМ) и других компьютерных устройств с целью получения определенного результата. Под программой для ЭВМ подразумеваются также подготовительные материалы, полученные в ходе ее разработки, и порождаемые ею аудиовизуальные отображения.
2. База данных – представленная в объективной форме совокупность самостоятельных материалов, систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ).
3. Сервер – компьютер (или специальное компьютерное оборудование), выделенный и/ или специализированный для выполнения определенных сервисных функций.
4. Пользователь – человек, работающий с ПО.
5. Администратор – пользователь, обладающий максимальными правами по работе с
ПО, в частности по настройке ПО.
6. Система управления базами данных (СУБД) – совокупность программных и
лингвистических средств общего или специального назначения, обеспечивающих
управление созданием и использованием баз данных.
7. Рабочая станция – стационарный компьютер в составе локальной вычислительной
сети (ЛВС), на котором решаются прикладные задачи.
8. Спецификация ПО – документ, содержащий полное и точное описание функций и
ограничений разрабатываемого программного обеспечения, а также требования, предъявляемые к техническим средствам, надежности, информационной безопасности и т.д.
9. Руководство разработчика – документ, содержащий информацию, необходимую для дальнейшего развития функциональности разрабатываемого программного обеспечения. Может содержать описание скриптов, динамических библиотек и программных модулей, классов, функций, параметров, структур, констант, а также примеры их использования; сведения по настройке программы.
10. Руководство администратора – документ, в котором содержаться инструкции по установке и настройке приложения.
11. Руководство пользователя – документ, в котором содержатся инструкции для пользователей по работе с приложением.
2. Введение
2.1. Наименование программы: HeyWork.
2.2. Назначение и область применения: сервис поиска специалистов.

 3. Основания для разработки
3.1. Документ (документы), на основании которых ведется разработка: Договор на создание программного обеспечения No 2 от 08.09.2020 г.
3.2. Наименование и (или) условное обозначение темы разработки: Веб-серивс
4. Назначение и цели создания системы
4.1. Назначение разработки: Создание сервиса для поиска специалистов в сфере программирования.
4.2. Цели создания: Сделать сервис для публикации программистами своего портфолио, чтоб заказчики могли находить и выбирать специалистов по навыкам и опыту в соответствии с требованиями.
5. Требования к надежности
5.1. Требования к обеспечению надежного функционирования:
Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением «Заказчиком» совокупности организационно-технических мероприятий, перечень которых приведен ниже:
а) организацией бесперебойного питания технических средств;
б) использованием лицензионного программного обеспечения;
в) регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. "Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств";
г) регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов.
5.2. Время восстановления после отказа:
Время восстановления после отказа, вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы, не должно превышать 30-ти минут при условии соблюдения условий эксплуатации технических и программных средств. Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств.
5.3. Отказы из-за некорректных действий пользователей системы:
Отказы программы возможны вследствие некорректных действий оператора (пользователя) при взаимодействии с операционной системой. Во избежание возникновения отказов программы по указанной выше причине следует обеспечить работу конечного пользователя без предоставления ему административных привилегий.


 6. Условия эксплуатации
6.1. Требования к квалификации и численности персонала:
Администратор, регулирующий возможные конфликты между пользователями(на начальной версии программы необходим только 1, контакты которого будут указываться в foottere).
Модератор, следящий за корректностью отзывов о разработчике от заказчика. Модератора можно привлечь при закрытии заказа если обе стороны не могут прийти к соглашению о проделанной работе или заказчик описывает работу разработчика нецензурными выражениями.
Пользователь программы должен обладать практическими навыками работы с графическим пользовательским интерфейсом операционной системы, имеет возможность создать портфолио в соответствии с шаблоном сервиса или заключить сделку с человеком, предоставившим своё портфолио.
Поиск необходимых людей будет осуществляться по технологиям, которые указал разработчик в своей анкете. Заказчики публиковать вакансии не могут.

7. Требования к защите информации и программ
7.1. Требования к защите информации от несанкционированного доступа:
Система должна быть защищена от проникновения посредством шифрования пароля
7.2. Требования к сохранности информации:
При отказе технических средств(в том числе - потеря питания) обеспечена сохранность информации в системе.
8. Требования к программной документации
8.1. Предварительный состав программной документации. Состав программной документации должен включать в себя:
Readme GitHub, описание архитектуры системы, описание схемы базы данных
10. Стадии и этапы разработки
10.1.Стадии разработки:
Разработка должна быть проведена в четыре стадии:
1. Анализ
2. Разработка
3. Рефакторинг
4. Внедрение
10.2.Этапы разработки:
На стадии анализа должны быть выполнены перечисленные ниже этапы работ: 1.Анализ программы
На стадии разработки должны быть выполнены перечисленные ниже этапы работ:
1. разработка бэк-энда;
2. разработка макетов страниц;
3. испытания программы.
На стадии рефакторинга должны быть выполнены перечисленные ниже этапы работ: 1. Улучшение кода.
2.Улучшение визуальной составляющей страниц.
3.Подкрепление документации.
На стадии внедрения происходит показ готового проекта заказчику
11. Порядок контроля и приемки
11.1. Виды испытаний:
Приемо-сдаточные испытания должны проводиться на объекте "Заказчика" в оговоренные сроки. Приемо-сдаточные испытания программы должны проводиться согласно разработанной "Исполнителем" и согласованной "Заказчиком" Программы и методик


 испытаний. Ход проведения приемо-сдаточных испытаний "Заказчик" и "Исполнитель" документируют в Протоколе проведения испытаний.
11.2. Общие требования к приемке работы:
На основании Протокола проведения испытаний "Исполнитель" совместно с "Заказчиком" подписывает Акт приемки-сдачи программы в эксплуатацию.
12. Разработка проекта системы базы данных
12.1. Требования к составу данных:
- непротиворечивые, удовлетворяющие условиям целостности БД
- предметно ориентированные и актуальные, представляющие реальную информацию о мире, пользователях и товарах выбранной предметной области
- возможности изменения данных при необходимости
12.2. Требования к представлению информации:
Пользовательский интерфейс сайта должен обеспечивать наглядное,
интуитивно понятное представление структуры размещенной на нем
информации, быстрый и логичный переход к разделам и страницам.
Система должна обеспечивать навигацию по всем доступным пользователю
ресурсам и отображать соответствующую информацию. Для навигации должна
использоваться система меню. Меню должно представлять собой список
гиперссылок на определённые страницы (в зависимости от утвержденного дизайна). 
Навигационные элементы должны обеспечивать однозначное
понимание пользователем их смысла:
- ссылки на страницы должны быть снабжены заголовками
- условные обозначения соответсвовать общепринятым
Для разделов, содержащих подразделы, должно быть предусмотрено подменю
2го уровня, а остальные уровни отображаются в рабочем поле. При выборе
какого-либо из пунктов меню пользователем должна загружаться
соответствующая ему информационная страница, а в блоке меню открываться
список подразделов выбранного раздела.

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


12.3. Требования по применению СУБД :
- в проекте используется СУБД MYSQL по причине необходимости соответствия требованию ACID.
- развертывание системы и СУБД происходит на операционной системе MacOS
13. Заполнение базы данных информацией
13.1. Требования к заполнению базы данных:
- данные поступают с веб-интерфейса на сервер, далее записываются в БД - на запись в базу поступают только верифицированные данные необходимых типов
Данные представляют из себя 3 вида анкет:
- Анкета разработчика включающая в себя ФИО, краткая информация о себе, фото, опыт работы, технологии, которыми владеет разработчик, опыт работы, завершённые заказы, отображать анкеты в общем списке или нет.
- Анкета заказчика включающая в себя ФИО, фото, компания или стартап к которой относится данный заказчик.

Аккаунт модератора включающий в себя ФИО и фото.

Так же данными являются заказы которые включают себя заказчика(только 1 человек), исполнителя(только 1 человек), краткое описание заказа, отзыв заказчика, дедлайн по выполнению, выставляемый заказчиком(опционально).
Заказ считается выполненным, если заказчик написал отзыв на разработчика(письменный и в 5 балльной шкале) и оба участника согласны с данным отзывом.
13.2. Требования к источникам информации:
- Источниками информации являются пользователи при регистрации, изменении данных своей анкеты, создании/завершении договоров между пользователями.
14. Разработка технической документации
14.1. Разработка Описания базы данных. Общее описание программных и лингвистических средств. Соответствие требованиям ГОСТ 7.70-96, ГОСТ 19.506-79.
14.2. Разработка Описания базы данных. Сведения о структуре таблиц базы данных. Соответствие требованиям ГОСТ 7.70-96
14.3. Указать соответствие требованиям ГОСТ
15. Разработка пользовательской документации
15.1. Разработка Описания применения. Соответствие требованиям ГОСТ 19.502-78.
15.2. Разработка Руководства администратора. Соответствие требованиям РД 50-34.698-90.
15.3. Разработка Руководства пользователя. Соответствие требованиям ГОСТ 34.201-89, РД 50-34.698-90.
15.4. Указать соответствие требованиям ГОСТ
  

 16. Установка созданной базы данных на сервер и рабочие станции Заказчика
16.1. Указать требования по установке созданной базы данных на сервер и рабочие станции
17. Учебно-консультационные услуги
17.1 .Обучение администратора.
Администратор сервиса должен пройти базовое обучение по поддержке сервиса 17.2. Обучение пользователей.
Пользователь должен владеть базовыми навыками работы с компьютером
Подписи сторон:


От имени Заказчика От имени Исполнителя __________________ / М.В. Коровкин/ __________________ / _______________ /