Техническое задание на компьютерную программу

ВолГТУ Кудряшов П.П., в дальнейшем именуемый как «разработчик «.

Заказчик программного продукта — кафедра САПР и ПК ВолГТУ, в лице

преподавателя Садовниковой Н.П.

2. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ

2.1. Документ, на основании которого ведётся разработка

Работа ведётся на основании задания на курсовое проектирование по

дисциплине «Технология программирования»

2.2. Организация, утвердившая этот документ, и дата его утверждения

Задание утверждено на заседании кафедры САПР и ПК __________ и выдано

преподавателем кафедры Садовниковой Н.П.

2.3. Наименование темы разработки

Наименование темы разработки – «Хранитель»

3. НАЗНАЧЕНИЕ РАЗРАБОТКИ

Данная разработка является семестровой работой по дисциплине «Технология

3.1. Критерии эффективности и качества программы

1) Социальный фактор. Данная программная разработка очень проста в

освоении и рассчитана не только на профессионалов, но и на рядовых

Этап проектирования и техническое задание (ТЗ) в проектах по автоматизации

пользователей, работающих под Windows. Удобный интуитивно понятный

интерфейс в сочетании с мощной системой вспомогательных рисунков и

всплывающих подсказок позволяют работать с программой без

2) Соответствие текущему состоянию на рынке ПО данного профиля. В

отличие от дорогих и сложных программ складского учета типа «1С-

Склад» и ей подобных, программа «Хранитель» идеально подходит для

представителей малого и среднего бизнеса, так как содержит все, что

им необходимо, но не перегружена бесполезными и ненужными

возможностями. Технология создания программы в визуальных средах

программирования делает ее интерфейс универсальным и совместимым с

операционными системами Windows 95/98/2000.

3) Экономические факторы. Программа представляет наилучшее соотношение

цены и предоставляемых ей возможностей и несомненно займет свою нишу

на рынке дешевых программ складского учета. Основными пользователями

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

могут заплатить за дорогие программы фирмы 1С и ей подобных.

3.2. Цели разработки программы

Создание данной программы преследует ряд технико-экономических целей:

1) Создание программного продукта, необходимого для учета товаров на

складах представителей малого и среднего бизнеса.

2) Создание дешевой альтернативы существующим в настоящее время дорогим

программам складского учета типа 1С-Склад и им подобным.

3) Создание интуитивно понятной программы с удобным и универсальным

Windows-интерфейсом для простого, но мощного и эффективного контроля

4. ТРЕБОВАНИЯ К ПРОГРАММЕ

4.1. Требования к функциональным характеристикам

4.1.1. Состав выполняемых функций

1) Программа должна работать с произвольным количеством складов, иметь

возможность вести статистику продаж (включает в себя стоимость

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

ТЗ для сайта: как составить документацию // #VA

с товаром) на складе и статистику продаж каждого из товаров в

2) Программа должна иметь возможность автозаполнения некоторых полей

(поля продавца и покупателя товара) для ускорения работы.

3) Программа должна предоставить возможность отслеживать перемещения

товаров между складами.

4) Программа должна искать товар на складе или операцию, произведенную с

ним по совокупности заданных пользователем полей.

5) Программа должна иметь возможность заменять названия товаров и валют

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

6) Программа должна иметь возможность списания остатка товара с

указанием лица, отдавшего такое распоряжение и суммы списания товара.

7) Программа должна иметь возможность выделения и копирования текстовых

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

обмена Windows с целью последующей вставки в любой документ,

допускающий подобную операцию (например, документ Microsoft Word или

8) Программа должна иметь возможность сортировки карточек товаров.

9) Программа должна иметь возможность использовать фильтр (специальная

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

склад, а только те, которые удовлетворяют настройкам фильтра,

например – отображать только товары стоимостью более 100 руб/ед),

настраиваемый пользователем для отображения товаров и операций,

удовлетворяющих параметрам фильтра.

10) Программа должна иметь возможность создания резервной копии в

автоматическом режиме (раз в неделю) и по желанию пользователя (в

любой момент времени, когда программа запущена).

11) Программа должна иметь возможность настройки пользовательского

интерфейса (шрифтов и цветов), а также параметров работы (учет и

процентная ставка НДС)

12) Внешний вид программы должен соответствовать макетам экранов,

предоставленных в ПРИЛОЖЕНИИ 1.

13) Список управляющих и быстрых клавиш программы должен соответствовать

14) Программа должна обеспечивать изменение уже имеющихся на диске баз

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

15) Программа должна обеспечивать вывод на принтер базы данных товаров на

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

4.1.2. Организация входных и выходных данных

Организация входных и выходных файлов должна соответствовать ПРИЛОЖЕНИЮ

В процессе работы программы входной информацией для программы должны

являться: файлы баз данных, манипуляции мышью, а также коды клавиш,

нажимаемых пользователем на клавиатуре ЭВМ, согласно режимам, определяемых

выходной экранной информацией. Перечень допустимых клавиш представлен в

4.1.3. Временные характеристики, и размер занимаемой памяти

Время реакции программы на нажатие любой из клавиш и манипуляции

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

О том, как качественно и понятно составить техническое задание рассказывает старший эксперт практики ERP SAP группы компаний Лига Цифровой Экономики, Екатерина Синица.

7706 просмотров
Типичные ошибки при составлении ТЗ

ТЗ предназначено для окончательного формулирования требований к продукту проекта, в нашем случае – к информационной системе (ИС). Большинство проблем, связанных с разработкой и согласованием ТЗ, вызвано неполным охватом всех видов требований при их анализе. Напомним, они делятся на функциональные (требования к тому, ЧТО должна делать ИС) и нефункциональные (требования к тому, КАК должна функционировать ИС).

При анализе функциональных требований аналитик сталкивается со всем многообразием проблем нечеткого и неполного формулирования требований заказчиком. Чтобы обеспечить их полноту и непротиворечивость, полезно выстраивать иерархию (дерево) требований, на вершине которой будет цель проекта, на следующем уровне – бизнес-требования (понимание, зачем данная ИС нужна и какие бизнес-потребности удовлетворяет), еще ниже, раскрывая каждое бизнес-требование, будут располагаться пользовательские требования (бизнес-сценарии, user stories или use cases), а в самом низу – детальные функциональные требования с описанием действий ИС в каждом конкретном сценарии.

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

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

Отдельная и очень большая проблема при анализе нефункциональных требований к ИС – работа с требованиями к интерфейсам. Здесь часто можно встретить слова об «удобстве», «эстетической привлекательности», «соответствии мировым тенденциям дизайна» и прочие образцы нечетких, субъективных, непроверяемых требований, реализовать и протестировать которые, вероятнее всего, не удастся. Лекарство от этой беды – детализация (попробуйте вместе с заказчиком расписать по пунктам, что означает требование «удобство для пользователя») и нахождение подходящих шкал для оценки степени реализации каждого такого требования. Иногда удается найти объективную, всеми признанную шкалу – например, взять цветовую схему интерфейса из корпоративного брендбука заказчика.

Частой ошибкой при разработке ТЗ является недостаточная детализация требований. Настройки и сценарии работы с ИС могут быть описаны слишком общо и поверхностно, целевые процессы формализуются на слишком высоком уровне. И когда дело доходит до реализации этих требований, у разработчиков возникает огромное количество вопросов. Чтобы дать максимально качественный результат этапа проектирования в виде ТЗ, целесообразно проводить:

1) Структурный анализ – моделирование структуры, понимание компонентов ИС и взаимосвязи между этими компонентами;

2) Анализ процессов – моделирование рабочего взаимодействия всех участников процесса, в котором предполагается задействовать ИС;

3) Функциональный анализ – моделирование всех возможных сценариев работы ИС и ее взаимодействия с акторами (пользователями) и смежными системами;

4) Информационный анализ – моделирование структуры данных (выделение объектов и их атрибутов, определение взаимосвязей между объектами) и потоков прохождения этих данных по процессам;

5) Анализ интерфейсов – моделирование (а в идеале прототипирование) пользовательских интерфейсов, проектирование рабочих мест пользователей.

Ошибки проектирования хорошо видны задолго до начала разработки, если мы пытаемся представить себе механизм их проверки. Неслучайно в ГОСТ 34.х документ «Программа и методика испытаний» является приложением к ТЗ. Настоятельно рекомендуется формировать сценарии тестирования ИС одновременно с фиксированием требований к этой ИС. Это позволит существенно повысить качество проектирования.

Как сделать ТЗ понятным для всех участников проекта

Отдельная большая проблема на этапе разработки ТЗ – это его согласование. заказчик, который не очень хорошо разбирается в технических аспектах ИС, скорее всего, будет испытывать большие опасения, подписывая обширное ТЗ. Опасения связаны с несколькими моментами:

1. Банальное непонимание технических нюансов. Заказчик не будет подписывать то, что ему непонятно. Он передаст ТЗ на согласование в смежные структуры, профильные подразделения, экспертам и специалистам всех смежных служб – и этот процесс может затянуться на несколько месяцев. Такой проблемы может не возникнуть, если до начала согласования ТЗ, а в идеале – до начала его разработки, вы с заказчиком договоритесь о формировании рабочей группы, в которую войдут специалисты всех служб клиента, с которыми нужно будет согласовать документ. Этих людей вы будете задействовать в качестве источников требований, их мнению основной заказчик сможет доверять.

2. Страх, что после утверждения ТЗ будет невозможно внести изменения в требования к результатам проекта. Чтобы снять эти опасения и иметь возможность делать проекты в постоянно меняющейся бизнес-среде, были сформулированы принципы гибкой разработки Agile Manifesto. Но не все заказчики знают эти принципы, и не все команды им следуют. Лучше в самом начале договориться с заказчиком о порядке управления изменениями в требованиях на протяжении всего проекта. Тогда и для вас, и для заказчика согласованное ТЗ станет основой, «печкой» для начала разработки ИС, но ни в коей мере не терминальным ограничением на ее функциональность.

3. Базовое недоверие к поставщику. Заказчик может бесконечно долго вычитывать и придираться к малейшим шероховатостям в тексте ТЗ только потому, что ему кажется, что исполнитель некомпетентен, неаккуратен и все сейчас сломает. Этот страх снимается только опытом взаимодействия с данным клиентом. Именно поэтому так важна лояльность старых заказчиков – с ними и ТЗ быстрее согласовываются, и проекты легче делаются. Работая с заказчиком впервые, не экономьте на прототипах – если он увидит, что вы и впрямь умеете делать крутые решения, доверие к вашей команде возрастет.

Подводные камни

Форматирование. Как ни странно, очень много сил и времени у команды может уйти на переделывание ТЗ в тот формат, который нужен заказчику. Рекомендуется заранее, до начала разработки ТЗ, согласовать с клиентом формат, а в идеале попросить в качестве шаблона ранее согласованное ТЗ по схожему проекту.

Забытые требования к эксплуатации. Мы, как правило, увлекаемся проектированием самой ИС, а на продумывание структуры пользовательской документации, программы обучения, подходов к миграции данных – всего того, без чего наша ИС никогда не сможет полноценно работать – времени часто не остается.

Внутреннее согласование. Очень часто разработчиков и тестировщиков не приглашают к согласованию ТЗ. А это неправильно, потому что только эти специалисты смогут вовремя заметить существенные ошибки, которые заказчик, весьма вероятно, пропустит.

Общая рекомендация – если вы хотите, чтобы разработка, согласование и последующая реализация ТЗ не представляли собой череду неразрешимых проблем и мучений, используйте опыт предшественников, обобщенный в очень скучных, но таких полезных книжках, как:

a. ГОСТ серии 34.х и 19.х;

b. Стандарты ИСО/МЭК по системной инженерии;

c. Методологии внедрения конкретного ПО (ASAP, MSF, RUP и т. д.);

d. Рекомендации Свода знаний по бизнес-анализу (BABOK).

Источник: vc.ru

ТЗ на разработку программного обеспечения: стандарты и шаблоны технического задания

Технологии разработки программного обеспечения (ПО) появились вместе с программированием. Стало традицией совмещение двух процедур: как написать алгоритм о том, «как писать программу» и разработать этот проект, уточнив по ходу дела первый алгоритм. Если программу «исполняет» компьютер, то технологию написания программ «исполняет» человек.

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

Область применения и цель в ней

Программирование в любом контексте — это формализация знаний и умений разработчика (коллектива) в относительно точный алгоритм, записанный в формате технического задания (ТЗ) на разработку программного обеспечения (ПО) одной или множества программ.

Технический проект информационной системы – это проектная документация, в которой описываются.

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

Формулировка задачи всегда уточнялась, цель конкретизировалась, а требуемая функциональность порой определялась годами.

Построить космический корабль, спроектировать жилой дом или написать ТЗ на атомный подводный корабль — годы работы даже с учетом опыта многочисленных специалистов. Это понятно всем.

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

Определить пространство решений

Область применения всегда «знает» что именно нужно сделать, чтобы изменить ситуацию к лучшему, но специалист не сразу понимает, как это корректно сформулировать и реализовать.

Наверное, очень часто многие слышали о прикладном ПО. Не все, правда, четко себе представляют, что.

Современное программирование ушло из локального варианта в сетевой «распределенный» контекст. Сути это не изменило. Что взять за основу C#, C/C++ или комплект интернет-технологий HTML/CSS + JavaScript/PHP не имеет значения.

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

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

Пространство решений — это необходимый функционал, который описывает идею или обеспечение исполнения спектра требований, улучшающих работу пользователя (заказчика, потребителя ПО) в области применения.

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

Контрактура сустава представляет собой тяжелое заболевание, которое способно полностью обездвижеть.

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

Участники процесса и важные условия

Заказчик — физическое или юридическое лицо, заинтересованное в разработке информационной системы.

Исполнитель — физическое или юридическое лицо, способное организовать процесс и изготовить информационную систему.

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

Отношения при разработке информационной системы строятся на уровне Заказчик — Исполнитель: только письменная форма согласно действующего законодательства и заключенного договора.

Исполнитель — разработчик: только письменная форма согласно собственного руководства или общего ГОСТ на техническое задание на разработку программного обеспечения.

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

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

Разработчик нанимается на работу Исполнителем по мере необходимости для исполнения конкретных функций, задач, этапов. Определение компетенции и состава группы разработки — сфера интересов и ответственности Исполнителя.

Особенности ТЗ на разработку ПО

Предельная ясность! ТЗ — это строгий документ, четко определяющий что и на каком основании было формализовано:

• исходные данные;
• требуемые результаты и выходные данные;
• обоснование и перечень всех алгоритмов, подлежащих реализации.

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

Любое ТЗ на разработку (даже самой неказистой программы) — динамичный документ. Нельзя его фиксировать как нечто незыблемое. В программировании интеллект отражается как в зеркале. ТЗ — это процесс спиралевидного развития представлений об области применения и решаемой задаче.

Техническое задание на разработку программного обеспечения — это не карандаш и лист бумаги, а шариковая (чернильная) ручка и пачка испорченной бумаги.

Достойны уважения те разработчики, которые при написании ТЗ ориентируются на сохранение истории развития своих представлений об области применения и решаемой задаче.

Концептуальное представление об информационных системах

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

Все что разрабатывается (программируется) для управления цифровым вычислительным устройством — это информационная система (ПО, алгоритм, программа или база данных).

Информационная система — это:

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

Информационная система — это последовательность трансформации мыслительной деятельности человека:

• общее системное представление;
• формальное описание;
• конкретная разработка;
• система проверки функциональности;
• система внедрения;
• система сопровождения;
• система обновления (модернизации);
• основания и причины для прекращения использования.

Разработку информационной системы выполняет Исполнитель силами собственных или привлеченных специалистов. Авторское право и право собственности в процессе работы на результаты этапов оформляется согласно законодательству и по договоренности с заказчиком.

Развитие ТЗ при разработке ПО

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

Разработка осуществляется циклически, но по спирали:

• после тестирования (инициатива Исполнителя);
• после внедрения (инициатива Заказчика);
• при объективной необходимости обновления.

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

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

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

Развитие ПО на базе уже созданных решений

ПО используется во многих случаях в различных областях применения давно и накоплен большой опыт. Финансы, биржи, бухгалтерские решения, электронный документооборот, станки с числовым программным управлением и другие сферы.

Написать техническое задание на разработку программного обеспечения С1 — пример работы, которая формализуется на основании уже существующего ПО. Очень характерно, что бухгалтерия 1С, заявленная разработчиками как первая и единственная реализация комплексного бухгалтерского ПО была создана другими коллективами разработчиков в совершенно других программных продуктах. Совершенно очевидно, что существующие бухгалтерские программы не идеал и будут развиты существующие и созданы новые.

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

В отличии от 1С, работы по проектированию ТЗ для АИС и собственно самих автоматизированных информационных систем датируются началом 80-х годов прошлого века, но проблем от этого не стало меньше, а идей стало гораздо больше.

Развитие и динамика против классики и статики

Любая программа фиксирует знания и умения разработчиков (авторов). Заказчики и руководители программных проектов могут вносить свою лепту в ТЗ и результирующее ПО, но конкретные программисты по-прежнему переносят свои мысли (знания и умения) в статичный программный код. Даже когда программа может динамично адаптироваться к изменениям в области применения, современные технологии программирования не дают ей возможности выйти за пределы представлений программистов, за пределы выполненной реализации (решения) поставленной задачи.

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

Программирование — это не единичный факт: написано ТЗ, создано ПО и процесс завершен. Иной вариант: написано, сделано и начали все сначала. Идеально — не столько писать программу и уточнять как именно это делать, а формировать коллектив разработчиков программы и совершенствовать его знания и умения.

Создание технического задания выступает одним из первых и чрезвычайно важных этапов большинства проектов. Четкое и правильно составленное техзадание (ТЗ) позволяет внести ясность в отношения заказчика и исполнителя, сформулировать требования к .

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

На многих современных предприятиях используются системы автоматизированного проектирования, или САПР. Существует большое количество поставщиков подобных решений. Функции и возможности данных систем проектирования, в частности представленных .

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

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

Технический проект информационной системы – это проектная документация, в которой описываются проектные решения по созданию и эксплуатации информационной системы. Элементы и комплексы функциональной части ИС являются объектами проектирования.

Наверное, очень часто многие слышали о прикладном ПО. Не все, правда, четко себе представляют, что это такое на самом деле, относя к нему все приложения, установленные на компьютере. Попробуем разобраться в базовых понятиях.

Контрактура сустава представляет собой тяжелое заболевание, которое способно полностью обездвижеть человека, сделав его инвалидом. Оно с трудом поддается лечению, особенно на поздних стадиях развития. В основном осуществляется консервативное и операционное вмешательство. В качестве первого используется медикаментозное лечение, физиопроцедуры, ЛФК и занятия на тренажерах. Вид операции подбирается в зависимости от формы и тяжести заболевания.

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

Источник: autogear.ru