И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):
ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр.
Согласно ГОСТ 34 техническое задание должно включать следующие разделы:
1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки
При разработке ТЗ для государственных проектов Заказчики, как правило, требуют соблюдение именно этого стандарта.
1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.
Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.
Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS. Данная рекомендуемая методика имеет своей целью установление требований к разрабатываемому программному обеспечению, но также может применяться, чтобы помочь в выборе собственных и коммерческих программных изделий.
Согласно стандарту техническое задание должно включать следующие разделы:
1. Введение
На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который . , правда, на англ. языке.
Ну а кто дочитал до конца - тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).
Как составить техническое задание на разработку сайта, чтобы не переделывать сайт заново? На самом деле у заказчика и исполнителя всегда существует вероятность неправильно понять друг друга.
К примеру, у клиента в голове появилось определенное представление, каким бы он хотел видеть сайт, и пытается объяснить это разработчикам. Но разработчики неверно трактовали «на пальцах» пожелания. Плачевный итог – клиент получил совсем не то, что представлял себе. Силы, время исполнителей и клиента были потрачены зря.
В этой статье вы узнаете, как правильно составить техническое задание на создание сайта, чтобы все остались довольны проделанной работой.
Техническое задание (ТЗ) – документ, содержащий требования заказчика к сайту. Заказчик и исполнитель должны правильно понимать друг друга, поэтому лучше подробно расписать все требования. Четко составленное ТЗ увеличивает шансы того, что заказчик будет доволен получившимся результатом, а исполнитель не будет переделывать ресурс 2-3 раза.
В хорошо составленном техническом задании четко указаны структура, функционал и все элементы. Если заказчик захочет изменить какую-то поставленную задачу, то вы можете смело отказать ему, ссылаясь на то, что в техническом задании такой пункт не прописан.
Техзадание может составить и заказчик, но все же у веб-студии опыта гораздо больше. При этом заказчик должен принимать участие в процессе составления ТЗ. Лучше всего, если будет заполнен опросный лист со следующими моментами:
Важно также учитывать на этапе подготовки ТЗ, так как это поможет сделать продукт для целевой аудитории в первую очередь, а не «для себя».
Забудьте о прилагательных красивый, инновационный, современный, надежный, длительный. Ведь у каждого человека свои представления значения этих слов. Для кого-то красивым будет сайт с обилием анимаций и ярких цветов, другой же сочтёт за красоту минимализм.
Главный критерий качества ТЗ - чёткие формулировки, отсутствие двусмысленных трактовок.
Конкретика в техническом задании - главное условие качества, например:
Обязательно согласуйте с клиентом инструменты, которые будут использоваться, движки и требования к хостингу. Пропишите в своём ТЗ, что ваш ресурс должен работать во всех браузерах, быть адаптивным для всех видов устройств, должен быть устойчив к нагрузкам и защищен от хакерских DDoS атак.
Структура сайта – фундамент. Решите, какие страницы необходимо создать и продумайте навигацию на них. По нашему опыту клиент проще воспринимает блок-схему, нарисованную в XMind. Но если вы считаете, что работа в XMind займет слишком много времени, то просто перечислите секции в word файле. Кстати, не лишним будет предварительно собрать , которое поможет в определении структуры и разделов на основании реальных запросов потенциальных клиентов в вашем сегменте.
Данные формулировки подходят для преамбулы приложения по техническому заданию к договору услуг. Важно прописать структуру, блоки и элементы, чтобы обозначить рамки работ и понять итоговую стоимость. Ниже пример составления структуры для ТЗ.
Страница «Главная»
Если вы также заказываете уникальный дизайн, то структуру страниц можно строить по предварительному прототипу. Ниже пример прототипа сайта, который можно прикрепить к техническому заданию на разработку. Определите вид главной страницы. Решите, где будет заголовок, пропишите основные элементы, на чём сделать акцент и так далее.
Функционал - отдельная история. Если вы хотите получить гибкий и функциональный сайт, который можно легко поддерживать в будущем, то обязательно пропишите в техническом задании технические аспекты проекта. В противном случае вы рискуете получить просто набор строчек когда, который может поддерживаться только программистом в штате. Что относится к функционалу:
К технической части относятся требования хостингу и его настройкам. Советуем выбирать проверенный и быстрого хостинг-провайдера с приемлемыми тарифами на обслуживание. Мы используем в проектах вот этот хостинг. Стоимость всего 2500 в год, домен в зоне.ru можно купить за 179 руб. Вот пример функционального описания для технического задания.
| Подключение и настройка CMS системы 1С Битрикс | Исполнитель настраивает CMS систему управления сайтом 1С Битрикс. Лицензия «1С-Битрикс: Управление сайтом» оплачивается Заказчиком самостоятельно. |
| Наполнение контентом | Наполнение текстом и фотографиями указанных выше страниц. Текст и фотографии предоставляет Заказчик. Исполнитель в праве использовать также контент с сайта заказчика. Расположение блоков на страницах выводится в рамках структуры страниц шаблона. |
| Настройка ролей доступа | Добавление роли «Администратор» с возможностью администрирования CMS, роли редактора (для отдела закупок) с возможностью добавления информации. |
| Адаптация для мобильных устройств и планшетов | Широкоэкранная верстка и адаптация под более мелкие разрешения экрана, сайт должен корректно отображаться на экранах шириной от 1920 до 320 пикселей, появление горизонтальной прокрутки недопустимо. |
| Подключение дополнительных модулей CMS | Исполнитель также вправе добавлять модули CMS и функциональные элементы на своё усмотрение, если они улучшают работоспособность сайта по согласованию с Заказчиком, платные модули оплачиваются Заказчиком. |
| Подключение домена и хостинга Заказчика | Исполнитель подключает домен и хостинг Заказчика для веб-сайта. Производится парковка домена с указанием адресов ns1, ns2. Включается версия PHP не ниже 7.0. |
| Настройка базы данных MySQL | Исполнитель создает базу данных MySQL на хостинге заказчика для размещения данных веб-сайта. Доступы к базе данных передаются Исполнителем Заказчику по электронной почте. |
| Видеофон на главной странице | Вывод подложки с видеорядом Заказчика в первом блоке главной страницы сайта. Должна присутствовать затемняющая подложка для повышения читабельности текста. |
| Вывод модальных окон и отправка данных | Каждая из кнопок должна вызывать соответствующее модальное окно с формой обратной связи. Данные с формы в корректном виде должны отправляться на почту Заказчика. |
| Вывод форм обратной связи | Форма обратной связи должна выводиться на каждой странице. В форме обратной связи должны присутствовать: форма поля ввода номера телефона и кнопка «отправить заявку». Данные с формы должны передаваться на электронный адрес администратора, а также дублироваться на адрес [email protected]. |
| Подключение Яндекс карты c ГЕО-метками | На страницах выводится Яндекс.Карта с ГЕО меткой расположения / адреса Заказчика. Заказчик устанавливает метку на собственном аккаунте Яндекс. |
| Подключение статистики Яндекс.Метрика | Сервис сбора данных о посещаемости и поведении пользователей. Заказчик предоставляет Яндекс почту, на которую Исполнитель подключает сервис. |
| Настройка целей в Яндекс.Метрика | Исполнитель настраивает цели в Яндекс.Метрика. Цели сообщают в статистике о том, с какой конкретно формы была отправлена заявка. |
| Вывод H1 и МЕТА-описаний страниц согласно ключевому запросу веб-страницы | Каждая страница веб-сайта должна иметь заголовок и МЕТА-описание в соответствии с содержимым страницы. |
| Кроссбраузерная оптимизация сайта | Сайт должен корректно открываться в последних актуальных версиях существующих браузеров. |
| Настройка файлов sitemap.xml | Исполнитель выводит карту сайта в отдельный раздел sitemap.xml с указанием существующих страниц для индексации. |
| Добавление «хлебных крошек» | Исполнитель выводит в каждый раздел навигационную цепочку («хлебные крошки», англ. Breadcrumbs) с адресом страницы формата: Главная → Раздел → Подраздел → Текущая страница. |
| Настройка файла robots.txt | Исполнитель настраивает текстовый файл, который содержит параметры индексирования сайта для роботов поисковых систем. |
| Настройка файла.htaccess | Исполнитель настраивает специальный файл, позволяющий редактировать конфигурации и настройки веб-сервера. |
| Настройка ЧПУ адресов страниц в формате domen.ru/arenda-sklada | Адрес каждой страницы должен содержать корректное описание для поисковых систем и посетителей на латинице. |
| Настройка 404 и 303 страниц | Настройка корректной выдачи ошибки 404, настройка 303 переадресации на страницы, которые изменили свой адрес. |
| Оптимизация программного кода HTML/CSS/PHP и скриптов | Исполнитель выполняет оптимизацию программного кода страниц сайта для повышения скорости загрузки страниц и веб-сайта в целом. При необходимости Исполнитель переносит загрузку.js скриптов в «подвал» сайта, настраивает кеширование страниц и сжатие CSS / HTML. |
| Оптимизация размера изображений и графического контента | Исполнитель сжимает изображения и видео, размещаемые на страницах веб-сайта для повышения скорости загрузки страниц ресурса. |
| Тестирование и поддержка в течение 1-го месяца после запуска | После приемки и запуска веб-сайта Исполнитель оказывает услуги по технической поддержке, устраняет технические ошибки и корректирует работу сайта при необходимости. |
Отдельно.
Помните, что сайт - это техническое и программное обрамление контента. Если контент (фото и видео) не очень, то и сайт будет таким же.
Отдельно стоит уделить внимание качеству фото и видео. Мы всегда рекомендуем заказать фото и видео съёмку клиентам, если нет презентабельного фото и видео контента для сайта.
Что относится к оформлению: оформление кнопок и элементов взаимодействия - ссылки, кликабельные стрелки слайдера, формы заявок и так далее. Продумайте цветовую гамму и пропишите гарнитуры шрифтов. У вас есть брендбук? Отлично, вы можете взять из него основные цвета и стили шрифтов для заголовков и основного текста и прописать всё это в техническом задании. Помните, что хорошее оформление зависит от качества исходного контента. Если у вас будут неказистые фото, то красивые кнопочки не помогут.
Кстати, многие клиенты путают понятие оформления и дизайна. Дизайн - это структура страниц от слова design (проектировать). Дизайн страниц должен содержать ключевые блоки и элементы, которые они содержат. Дизайн - это логика построения страниц.
Итак, что должно содержать в себе хорошее техническое задание, которое обезопасит вас от недопонимания с исполнителем. Вот перечень:
Вы можете сами продолжить этот список, ведь каждый проект индивидуальный. Сайт компании всегда зависит от особенностей самого бизнеса и должен передавать его суть через контент и функциональные элементы. Узнайте также, который способен повысить прибыль компании и узнаваемость бренда?
Если вам нужен новый сайт, то вы можете создание сайта или технического задания в нашей веб-студии.
При разработке любого проекта. Как оформляется этот документ? Об этом будет рассказано в статье.
Прежде чем приступить к разработке того или иного проекта, вначале должен быть составлен план. Строительство, предпринимательство, жилищные работы - абсолютно любая трудовая сфера требует разработки соответствующего плана. При этом совершенно неважно, насколько сложной или серьезной является та или иная работа. Разработка технического задания, а, по сути, обыкновенного плана действий, является здесь ключевым этапом.
Техническое задание нужно сразу обеим сторонам рабочего процесса: и исполнителю, и заказчику. Зачастую между этими двумя лицами возникают ссоры, конфликты и недопонимание. Грамотно составленный план действий поможет строго регламентировать все обязательства каждой стороны.
Как уже было сказано, разработка технического задания - это необходимый процесс, полезный для обеих сторон трудового договора. Однако сейчас стоит рассказать о том, для чего представленный документ нужен непосредственному заказчику.
Самое важное, что можно отметить, это тот факт, что техническое задание разрабатывается только заказчиком. Это своего рода план действий, договор о предоставлении услуг. С помощью этого документа исполнители могут четко определить свои рабочие функции, а также то, что именно от них требуют. Рассматриваемый документ всегда должен разрабатываться очень качественно и внимательно. Так, заказчик должен учитывать все основные тезисы и пункты, а также не допускать противоречивых моментов. Если документ составлен грамотно, то заказчик всегда сможет указать недовольному исполнителю на определенный пункт договора.
Исполнитель получает образцы технических заданий перед началом выполнения той или иной работы. Трудящееся лицо обязано очень внимательно ознакомиться со всеми пунктами, что имеются в документе. Этот шаг поможет избежать манипуляций со стороны заказчика. Так, многие начальствующие лица могут требовать от работников чего-то такого, о чем не шла речь в техническом задании.
Исполнитель должен уточнить все необходимые моменты и насчет суммы оплаты. Так, стоит убедиться, что денежные выплаты касаются только тех моментов, что оговорены в документе. В противном же случае невнимательные исполнители могут поработать бесплатно.
Таким образом, исполнитель должен обращать внимание на образцы технических заданий как можно чаще. Это поможет ему избежать лишних проблем и недопонимания.
С чего стоит начать заполнение документа? Техническое задание на выполнение работ всегда должно начинаться с общих положений и целей. Что входит в общие положения? Во-первых, небольшой глоссарий. Конечно же, это не обязательное условие. Однако если документ узконаправленный, а потому изобилует специфической терминологией, то небольшой словарик закрепить все же стоит. Во всяком случае это будет еще одним шагом на пути к взаимопониманию заказчика и исполнителя. Во-вторых, общие положения должны содержать данные о сторонах договора.
Что входит в цели технического задания? Наверное, догадаться несложно. Так, необходимо кратко обозначить, что за проект находится в разработке, зачем он нужен и как можно достичь конечного результата. Все задачи и цели должны быть расписаны как можно более подробно и ясно. Такой подход позволит наладить взаимопонимание между сторонами договора.
В обязательном порядке любое техническое задание на выполнение работ должно содержать определенные требования, а также четко установленные сроки. Со сроками все относительно понятно. Хотя стоит отметить, что время лучше брать с некоторым запасом. К тому же скорость исполнения заказа не должна повлиять на качество. В случае если исполнитель нарушит установленные сроки исполнения, в договоре должны содержаться определенные санкции на этот случай.
А что можно рассказать о требованиях? Заказчик должен помнить, что все требования делятся на два основных типа: специальные и функциональные. Функциональные требования являются в некоторой степени наглядными, образными. Это определенные изображения, элементы, зарисовки того, что заказчик хотел бы увидеть. Специальные же требования - жестко регламентированные, с указанием определенных задач и способов исполнения. Естественно, специальные должны значительно преобладать. В противном случае исполнитель может попросту не до конца понять, что же именно от него хотят.
Еще о двух важнейших элементах, которые должны содержать абсолютно любые образцы технических заданий, стоит рассказать чуть подробнее. Речь идет об ответственности сторон и об отчетности. Что представляет собой каждый из этих элементов?
Отчетность желательно формировать поэтапно, в особенности если техническое задание большое. Как только был завершен определенный этап работы, можно подавать (требовать) отчетность. К тому же подобная система позволяет держать исполнителя в тонусе. В противном же случае он может сделать все в последний момент, а стало быть, крайне некачественно.
Что можно сказать об ответственности сторон? Сразу стоит отметить, что подобный пункт не является обязательным. Однако многие заказчики все же находят нужным регламентировать основные виды штрафов, наказаний и санкций за различные нарушения. Желательно указывать основные элементы ответственности в таких документах, как техническое задание на закупку, на транспортировку и т. д.
Любое техническое задание (на поставку, строительство, транспортировку и т. д.) необходимо очень грамотно и качественно оформлять. Это нужно, во-первых, для того, чтобы в дальнейшем не возникало судебных разбирательств, споров и конфликтов из-за недопонимания сторон. А во-вторых, для простого удобства. Грамотно оформить техническое задание способен далеко не каждый заказчик. Зачастую для этого дела нанимаются юристы, хотя в этом и нет особого смысла.
Просто стоит запомнить несколько простых правил:
Все те советы, что были даны выше - лишь малая часть из того, о чем можно было бы рассказать. Однако все еще можно дать заказчикам пару указаний. Так, техническое задание (на техническое обслуживание или на строительство) может быть построено по шаблону. При этом необязательно брать этот шаблон откуда-то; так, если написание договора на оказание услуг - довольно частая обязанность, то выстроить для себя пару клише будет не так уж и сложно.
Стоит напомнить и о том, насколько важно сверяться с нормами: будь то ГОСТ, нормативные или правовые акты, локальные акты и т. д.
ЛАБОРАТОРНАЯ РАБОТА № 1.
Этапы разработки программного обеспечения при структурном подходе к программированию. Стадия «Техническое задание»
Цель работы: ознакомиться с правилами написания технического задания.
Теоретическая часть. Разработка технического задания
Техническое задание представляет собой документ, в котором сформулированы основные цели разработки, требования к программному продукту, определены сроки и этапы разработки и регламентирован процесс приемосдаточных испытаний. В разработке технического задания участвуют как представители заказчика, так и представители исполнителя. В основе этого документа лежат исходные требования заказчика, анализ передовых достижений техники, результаты выполнения научно-исследовательских работ, предпроектных исследований, научного прогнозирования и т. п.
Порядок разработки технического задания
Разработка технического задания выполняется в следующей последовательности. Прежде всего, устанавливают набор выполняемых функций, а также перечень и характеристики исходных данных. Затем определяют перечень результатов, их характеристики и способы представления.
Далее уточняют среду функционирования программного обеспечения: конкретную комплектацию и параметры технических средств, версию используемой операционной системы и, возможно, версии и параметры другого установленного программного обеспечения, с которым предстоит взаимодействовать будущему программному продукту.
В случаях, когда разрабатываемое программное обеспечение собирает и хранит некоторую информацию или включается в управление каким-либо техническим процессом, необходимо также четко регламентировать действия программы в случае сбоев оборудования и энергоснабжения.
Общие положения
Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата А4 и АЗ по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.
Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78. Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.
Для внесения изменений и дополнений в техническое задние на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
Техническое задание должно содержать следующие разделы:
введение;
наименование и область применения;
основание для разработки;
назначение разработки;
технические требования к программе или программному изделию;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки;
приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них. При необходимости допускается в техническое задание включать приложения.
Введение должно включать краткую характеристику области применения программы или программного продукта, а также объекта (например, системы), в котором предполагается их использовать. Основное назначение введения - продемонстрировать актуальность данной разработки и показать, какое место эта разработка занимает в ряду подобных.
В разделе «Наименование и область применения» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
В разделе «Основание для разработки» должны быть указаны:
документ (документы), на основании которых ведется разработка. Таким документом может служить план, приказ, договор и т. п.
организация, утвердившая этот документ, и дата его утверждения;
наименование и (или) условное обозначение темы разработки.
В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.
Раздел «Технические требования к программе или программному изделию» должен содержать следующие подразделы:
требования к функциональным характеристикам;
требования к надежности;
условия эксплуатации;
требования к составу и параметрам технических средств;
требования к информационной и программной совместимости;
требования к маркировке и упаковке;
требования к транспортированию и хранению;
специальные требования.
В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. п.
В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечение устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т. п.).
В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т. п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.
В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их технических характеристик.
В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования. При необходимости должна обеспечиваться защита информации и программ.
В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.
В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.
В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей.
В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.
В приложениях к техническому заданию при необходимости приводят:
перечень научно-исследовательских и других работ, обосновывающих разработку;
схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
другие источники разработки.
В случаях, если какие-либо требования, предусмотренные техническим заданием, заказчик не предъявляет, следует в соответствующем месте указать «Требования не предъявляются».
Порядок выполнения работы
Разработать техническое задание на программный продукт (см. варианты заданий в приложении 1).
Оформить работу в соответствии с ГОСТ 19.106-78.
Сдать и защитить работу.
УТВЕРЖДАЮ
Зав. каф. ПЗ,
д.т.н., проф. ___________
ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ Техническое задание
Руководитель
к.т.н., доц. ХХХХХХХ
Исполнитель
ст. гр. ____ ХХХХХХХ
Винница, 20__
Введение
Настоящее техническое задание распространяется на разработку программы сортировки одномерного массива методами пузырька, прямого выбора, Шелла и быстрой сортировки, предназначенной для использования школьниками старших классов при изучении курса школьной информатики.
Основание для разработки
Программа разрабатывается на основе учебного плана кафедры «Программного обеспечения».
Наименование работы:
«Программа сортировки одномерного массива».
Исполнитель: компания ХХХХХХХ.
Соисполнители: нет.
Назначение
Программа предназначена для использования школьниками при изучении темы «Обработка одномерных массивов» в курсе «Информатика».
Требования к программе или программному изделию
Требования к функциональным характеристикам
Программа должна обеспечивать возможность выполнения следующих функций:
ввод размера массива и самого массива;
хранение массива в памяти;
выбор метода сортировки;
вывод текстового описания метода сортировки;
вывод результата сортировки.
Исходные данные:
размер массива, заданный целым числом;
Организация входных и выходных данных
Входные данные поступают с клавиатуры.
Выходные данные отображаются на экране и при необходимости выводятся на печать.
Требования к надежности
Предусмотреть контроль вводимой информации.
Предусмотреть блокировку некорректных действий пользователя при работе с системой.
Требования к составу и параметрам технических средств.
Система должна работать на IBM-совместимых персональных компьютерах.
Минимальная конфигурация:
тип процессора. Pentium и выше;
объем оперативного запоминающего устройства 32 Мб и более;
объем свободного места на жестком диске 40 Мб.
тип процессора. Pentium II 400;
объем оперативного запоминающего устройства 128 Мб;
объем свободного места на жестком диске 60 Мб.
Требования к программной совместимости.
Программа должна работать под управлением семейства операционных систем Win 32 (Windows 95/98/2000/МЕ/ХР и т. п.).
Разрабатываемые программные модули должны быть документированы, т. е. тексты программ должны содержать все необходимые комментарии.
Разрабатываемая программа должна включать справочную информацию о работе программы, описания методов сортировки и подсказки учащимся.
В состав сопровождающей документации должны входить:
Пояснительная записка на пяти листах, содержащая описание разработки.
Руководство пользователя.
Министерство образования Украины
Винницкий национальный технический университет
Кафедра программного обеспечения
УТВЕРЖДАЮ
Зав. каф. ПЗ,
д.т.н., проф. ___________
на разработку «ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ»
Винница 20__
Работа выполняется в рамках проекта «ХХХХХХХХХХХХХХХХХХ».
Основание для разработки
Основанием для данной работы служит договор № ХХХХ от __ _____ 20__ г.
Наименование работы:
«ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ».
Исполнители: ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ.
Соисполнители: нет.
Назначение разработки
Создание модуля для контроля и оперативной корректировки состояния основных параметров теплообеспечения.
Технические требования
Требования к функциональным характеристикам.
Состав выполняемых функций.
Разрабатываемое ПО должно обеспечивать:
сбор и анализ информации о расходовании тепла, горячей и холодной воды по данным теплосчетчиков 5А-94 на всех тепловых выходах;
сбор и анализ информации с устройств управления системами воздушного отопления и кондиционирования типа РТ1 и РТ2 (разработки кафедры СММЭ и ТЦ);
предварительный анализ информации на предмет нахождения параметров в допустимых пределах и сигнализирование при выходе параметров за пределы допуска;
отображение текущего состояния по набору параметров - циклически постоянно (режим работы круглосуточный), при сохранении периодичности контроля прочих параметров;
визуализацию информации по расходу теплоносителя:
текущую, аналогично показаниям счетчиков;
с накоплением за прошедшие сутки, неделю, месяц - в виде почасового графика для информации за сутки и неделю;
суточный расход - для информации за месяц.
Для устройств управления приточной вентиляцией текущая информация должна содержать номер приточной системы и все параметры, выдаваемые на собственный индикатор.
По отдельному запросу осуществляются внутренние настройки.
В конце отчетного периода система должна архивировать данные.
Организация входных и выходных данных.
Исходные данные в систему поступают в виде значений с датчиков, установленных в помещениях института. Эти значения отображаются на компьютере диспетчера. После анализа поступившей информации оператор диспетчерского пункта устанавливает необходимые параметры для устройств, регулирующих отопление и вентиляцию в помещениях. Возможна также автоматическая установка некоторых параметров для устройств регулирования.
Основной режим использования системы - ежедневная работа.
Требования к надежности.
Для обеспечения надежности необходимо проверять корректность получаемых данных с датчиков.
Условия эксплуатации и требования к составу и параметрам технических средств.
Для работы системы должен быть выделен ответственный оператор.
Требования к составу и параметрам технических средств уточняются на этапе эскизного проектирования системы.
Требования к информационной и программной совместимости.
Программа должна работать на платформах Windows .
Требования к транспортировке и хранению.
Программа поставляется на лазерном носителе информации.
Программная документация поставляется в электронном и печатном виде.
Специальные требования:
программное обеспечение должно иметь дружественный интерфейс, рассчитанный на пользователя (в плане компьютерной грамотности) квалификации;
ввиду объемности проекта задачи предполагается решать поэтапно, при этом модули ПО, созданные в разное время, должны предполагать возможность наращивания системы и быть совместимы друг с другом, поэтому документация на принятое эксплуатационное ПО должна содержать полную информацию, необходимую для работы программистов с ним;
язык программирования - по выбору исполнителя, должен обеспечивать возможность интеграции программного обеспечения с некоторыми видами периферийного оборудования (например, счетчик 5А-94 и т. п.).
Требования к программной документации
Основными документами, регламентирующими разработку будущих программ, должны быть документы Единой Системы Программной Документации (ЕСПД): руководство пользователя, руководство администратора, описание применения.
Технико-экономические показатели
Эффективность системы определяется удобством использования системы для контроля и управления основными параметрами теплообеспечения помещений Московского института, а также экономической выгодой, полученной от внедрения аппаратно-программного комплекса.
Порядок контроля и приемки
После передачи Исполнителем отдельного функционального модуля программы Заказчику последний имеет право тестировать модуль в течение 7 дней. После тестирования Заказчик должен принять работу по данному этапу или в письменном виде изложить причину отказа принятия. В случае обоснованного отказа Исполнитель обязуется доработать модуль.
Календарный план работ
Сидоров С. В.
|
Название этапа |
Сроки этапа |
Чем заканчивается этап |
|
|
Изучение предметной области. Проектирование системы. Разработка предложений по реализации системы |
01.02.200_-28.02.200_ |
Предложения по работе системы. Акт сдачи-приемки |
|
|
Разработка программного модуля по сбору и анализу информации со счетчиков и устройств управления. Внедрение системы для одного из корпусов МИЭТ |
01.03.200 -31.08.200_ |
Программный комплекс, решающий поставленные задачи для пилотного корпуса МИЭТ. Акт сдачи-приемки |
|
|
Тестирование и отладка модуля. Внедрение системы во всех корпусах МИЭТ |
01.09.200 -30.12.200_ |
Готовая система контроля теплообеспечения МИЭТ, установленная в диспетчерском пункте. Программная документация. Акт сдачи-приемки работ |
Руководитель работ
Контрольные вопросы
Приведите этапы разработки программного обеспечения.
Что включает в себя постановка задачи и предпроектные исследования?
Перечислите функциональные и эксплуатационные требования к программному продукту.
Перечислите правила разработки технического задания.
Назовите основные разделы технического задания.
ЛАБОРАТОРНАЯ РАБОТА № 2.
Структурный подход к программированию. Стадия «Эскизный проект»
Цель работы: научиться создавать формальные модели и на их основе определять спецификации разрабатываемого программного обеспечения.
Теоретическая часть.
Разработка спецификаций
Разработка программного обеспечения начинается с анализа требований к нему. В результате анализа получают спецификации разрабатываемого программного обеспечения, строят общую модель его взаимодействия с пользователем или другими программами и конкретизируют его основные функции.
При структурном подходе к программированию на этапе анализа и определения спецификаций разрабатывают три типа моделей: модели функций, модели данных и модели потоков данных. Поскольку разные модели описывают проектируемое программное обеспечение с разных сторон, рекомендуется использовать сразу несколько моделей, разрабатываемых в виде диаграмм, и пояснять их текстовыми описаниями, словарями и т. п.
Структурный анализ предполагает использование следующих видов моделей:
диаграмм потоков данных (DFD - Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;
диаграмм «сущность-связь» (ERD - Entity-Relationship Diagrams), описывающих базы данных разрабатываемой системы;
f V
диаграмм переходов состояний (STD - State Transition Diagrams), характеризующих поведение системы во времени;
функциональных диаграмм (методика SADT);
спецификаций процессов;
словаря терминов.
Спецификации процессов
Спецификации процессов обычно представляют в виде краткого текстового описания, схем алгоритмов, псевдокодов, Flow-форм или диаграмм Насси - Шнейдермана.
Словарь терминов
Словарь терминов представляет собой краткое описание основных понятий, используемых при составлении спецификаций. Он должен включать определение основных понятий предметной области, описание структур элементов данных, их типов и форматов, а также всех сокращений и условных обозначений.
Диаграммы переходов состояний
С помощью диаграмм переходов состояний можно моделировать последующее функционирование системы на основе ее предыдущего и текущего функционирования. Моделируемая система в любой заданный момент времени находится точно в одном из конечного множества состояний. С течением времени она может изменить свое состояние, при этом переходы между состояниями должны быть точно определены.
Функциональные диаграммы
Функциональные диаграммы отражают взаимосвязи функций разрабатываемого программного обеспечения.
Они создаются на ранних этапах проектирования систем, для того чтобы помочь проектировщику выявить основные функции и составные части проектируемой системы и, по возможности, обнаружить и устранить существенные ошибки. Для создания функциональных диаграмм предлагается использовать методологию SADT .
Диаграммы потоков данных
Для описания потоков информации в системе применяются диаграммы потоков данных (DFD - Data flow diagrams). DFD позволяет описать требуемое поведение системы в виде совокупности процессов, взаимодействующих посредством связывающих их потоков данных. DFD показывает, как каждый из процессов преобразует свои входные потоки данных в выходные потоки данных и как процессы взаимодействуют между собой.
Диаграммы «сущность-связь»
Диаграмма сущность-связь - инструмент разработки моделей данных, обеспечивающий стандартный способ определения данных и отношений между ними. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют требованиям, предъявляемым к ИС.
Порядок выполнения работы
На основе технического задания из лабораторной работы № 1 выполнить анализ функциональных и эксплуатационных требований к программному продукту.
Определить основные технические решения (выбор языка программирования, структура программного продукта, состав функций ПП, режимы функционирования) и занести результат ты в документ, называемый «Эскизным проектом» (см. приложение 4).
Определить диаграммы потоков данных для решаемой задачи.
Определить диаграммы «сущность-связь», если программный продукт содержит базу данных.
Определить функциональные диаграммы.
Определить диаграммы переходов состояний.
Определить спецификации процессов.
Добавить словарь терминов.
Контрольные вопросы
Назовите этапы разработки программного обеспечения.
Что такое жизненный цикл программного обеспечения?
В чем заключается постановка задачи и предпроектные исследования?
Назовите функциональные и эксплуатационные требования к программному продукту.
Перечислите составляющие эскизного проекта.
Охарактеризуйте спецификации и модели.
ЛАБОРАТОРНАЯ РАБОТА № 3. Структурный подход к программированию. Стадия «Технический проект»
Цель работы: изучить вопросы проектирования программного обеспечения.
Лабораторная работа рассчитана на 4 академических часа.
Подготовка к лабораторной работе
Ознакомиться с лекционным материалом по теме «Этапы разработки программного обеспечения. Проектирование программного обеспечения» учебной дисциплины «Технология разработки программного обеспечения».
Изучить соответствующие разделы в изданиях .
Ознакомиться с разд. 4.1-4.3 настоящего пособия.
Теоретическая часть. Составляющие технического проекта
ПРОЕКТ ТЕХНИЧЕСКИЙ - образ намеченного к созданию объекта, представленный в виде его описания, схем, чертежей, расчетов, обоснований, числовых показателей.
Технический проект
Цель технического проекта - определение основных методов, используемых при создании информационной системы, и окончательное определение ее сметной стоимости.
Техническое проектирование подсистем осуществляется в соответствии с утвержденным техническим заданием.
Технический проект программной системы подробно описывает:
выполняемые функции и варианты их использования;
соответствующие им документы;
структуры обрабатываемых баз данных;
взаимосвязи данных;
алгоритмы их обработки.
Технический проект должен включать данные об объемах и интенсивности потоков обрабатываемой информации, количестве пользователей программной системы, характеристиках оборудования и программного обеспечения, взаимодействующего с проектируемым программным продуктом.
При разработке технического проекта оформляются:
ведомость технического проекта. Общая информация по проекту;
пояснительная записка к техническому проекту. Вводная информация, позволяющая ее потребителю быстро освоить данные по конкретному проекту;
описание систем классификации и кодирования;
перечень входных данных (документов). Перечень информации, которая используется как входящий поток и служит источником накопления;
перечень выходных данных (документов). Перечень информации, которая используется для анализа накопленных данных;
описание используемого программного обеспечения. Перечень программного обеспечения и СУБД, которые планируется использовать для создания информационной системы;
описание используемых технических средств. Перечень аппаратных средств, на которых планируется работа проектируемого программного продукта;
проектная оценка надежности системы. Экспертная оценка надежности с выявлением наиболее благополучных участков программной системы и ее узких мест;
ведомость оборудования и материалов. Перечень оборудования и материалов, которые потребуются в ходе реализации проекта.
Структурная схема
Структурной называют схему, отражающую состав и взаимодействие по управлению частями разрабатываемого программного обеспечения. Структурная схема определяется архитектурой разрабатываемого ПО.
Функциональная схема
Функциональная схема - это схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств.
Разработка алгоритмов
Метод пошаговой детализации реализует нисходящий подход к программированию и предполагает пошаговую разработку алгоритма.
Структурные карты
Методика структурных карт используется на этапе проектирования ПО для того, чтобы продемонстрировать, каким образом программный продукт выполняет системные требования. Структурные карты Константайна предназначены для описания отношений между модулями (см. разд. 4.2).
Техника структурных карт Джексона основана на методе структурного программирования Джексона, который выявляет соответствие между структурой потоков данных и структурой программы. Основное внимание в методе сконцентрировано на соответствии входных и выходных потоков данных (см. разд. 4.3).
Порядок выполнения работы
На основе технического задания из лабораторной работы № 1 и спецификаций из лабораторной работы № 2 разработать уточненные алгоритмы программ, составляющих заданный программный модуль. Использовать метод пошаговой детализации.
На основе уточненных и доработанных алгоритмов разработать структурную схему программного продукта (разд. 4.1.1).
Разработать функциональную схему программного продукта (разд. 4.1.2).
Представить структурную схему в виде структурных карт Константайна (см. разд. 4.2).
Представить структурную схему в виде структурных карт Джексона (см. разд. 4.3).
Оформить результаты, используя MS Office или MS Visio в виде технического проекта.
Сдать и защитить работу.
Защита отчета по лабораторной работе
Отчет по лабораторной работе должен состоять из:
Структурной схемы программного продукта.
Функциональной схемы.
Алгоритма программы.
Структурной карты Константайна.
Структурной карты Джексона.
Законченного технического проекта программного модуля. Защита отчета по лабораторной работе заключается в предъявлении преподавателю полученных результатов (на экране монитора), демонстрации полученных навыков и ответах на вопросы преподавателя.
УТВЕРЖДАЮ
Руководитель (заказчика ИС)
Личная подпись Расшифровка подписи _
Печать Дата « » 20__ г.
УТВЕРЖДАЮ
Руководитель (разработчика ИС)
Личная подпись Расшифровка подписи
Печать Дата « » 20__ г.
Эскизный проект на создание информационной системы
Система Управления Базой Данных
(наименование вида ИС)
ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ
(наименование объекта информатизации)
СУБД «Библиотека»
(сокращенное наименование И С)
На 8 листах
Основное назначение технического задания — четко определить и зафиксировать требования к объекту закупки. Закон устанавливает, что наименование закупки указывается в соответствии с (ч. 4 ст. 23). Каталог утвержден постановлением правительства от 08.02.2017 № 145.
При наличии описания закупаемой продукции в КТРУ заказчик обязан:
Формулировку требований заказчик составляет на основе правил описания объекта закупки (ст. 33). Выделим некоторые обязательные условия:
1. Составить список терминов, определений и сокращений, которые будут использоваться в документе.
2. Предоставить полную информацию о заказчике:
3. Предусмотреть в информации о закупке сведения:
4. Перечислить сведения о госзакупке:
5. Перечислить требования к участникам: деловая репутация, наличие у них производственных мощностей.
6. Указать исходные условия: справочная, производственная, опытная информация, которые оказывают влияние при исполнении контракта. Например, обслуживать закупаемую технику только в утренние часы.
7. Привести сведения об особенностях производственного процесса или архитектурного объекта заказчика, которые повлияют на процесс исполнения контракта. Например, при составлении технического задания на может понадобиться указать, что при доставке необходим подъем на третий этаж вручную из-за отсутствия лифта.
8. Указать точное местоположение объекта, а при необходимости — его полное описание. Это потребуется, например, для проектирования инженерных коммуникаций или для точного расчета стоимости ремонта.
9. Привести желаемые результаты (какую проблему хочет решить заказчик).
10. Указать источник финансирования.
11. Установить для участников требование соблюдать определенную нормативно-правовую базу, в том числе относящуюся к предмету контракта, условиям исполнения, срокам, гарантийным обязательствам.
12. Определить условия госзакупки (ч. 1 ст. 19).
13. Указать наименование и обоснование объекта госзакупки.
14. Максимально точно и детально описать объект госзакупки (ст. 33).
15. Определить экологические особенности закупаемого объекта.
16. Уточнить объем закупаемых товаров, периодичность и срок поставки.
17. Определить гарантийный срок и объем предоставляемых гарантий.
18. Установить требования к упаковке, маркировке, какие условные и специальные обозначения должны быть на ней.
19. Обязать предоставлять подтверждение нового товара или потребности в товаре иного состояния.
20. Определить расходы на эксплуатацию.
21. Определиться, нужны ли монтаж и наладка.
22. Установить порядок поставки и приемки.
23. Указать на необходимость провести испытания, обучение лиц, которые будут использовать закупаемый товар.
Помните, что универсальный образец технического задания по ФЗ-44 не разработан, к каждой закупке требуется индивидуальный подход. Только так учитывайте все потребности и особенности заказчика. В качестве ориентира вы можете использовать этот пример технического задания по 44-ФЗ (образец).
Образец техзадания на выполнение работ по ФЗ-44 вы можете найти в материале о или системы .
