Методы проектирования по доклад

Обновлено: 17.05.2024

Проектирование ПО - это процесс разработки, следующий за этапом анализа и формирования требований. Задача проектирования - это преобразование требований к системе в требования к ПО и построение архитектуры системы [4.16].

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

Основное условие построения архитектуры системы - это декомпозиция системы на компоненты или модули, а также

определение целей и проверка их выполнимости;
определение входных и выходных данных;
иерархическое представление абстракции системы и скрытие тех деталей, которые будут отработаны на следующих уровнях.

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

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

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

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

К методам проектирования относятся стандартный подход к проектированию, основанный на сформировавшейся общесистемной технологии традиционного проектирования программных систем.

4.2.1. Стандартный подход к проектированию

Разработка автоматизированных систем (АС) выполнялась на основе стандарта ГОСТ 34.601-90, регламентирующего стадии и этапы процесса разработки АС с учетом особенностей АС и средств объединения подсистем. Основание для разработки АС - это договор между разработчиком системы и заказчиком.

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

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

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

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

Данный стандарт обеспечивает:

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

Рассмотрим каждый вид проектирования более подробно.

При концептуальном проектировании определяются:

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

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

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

При архитектурном проектировании системы может применяться язык UML, который позволяет учитывать аспекты, свойственные действующим лицам, а также устанавливать форматы в меню и иконах интерфейсов [4.17].

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

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

Для уточнения поведения объектов используются диаграммы UML, отображающие различные аспекты взаимодействия объектов. Эти уточнения касаются интерфейсов и поведения объектов в сценариях, а также пересмотра моделей требований и состава объектов системы. Изменения начинаются с требований и поиска мест локации для внесения необходимых изменений в модель требований и их трассирование. Наряду с изменением требований к функциям системы могут изменяться нефункциональные требования, касающиеся ограничений на структуру системы и условий среды функционирования системы (отказоустойчивость и др.).

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

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

Зачем нужно проектирование программного обеспечения

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

Проектируя ПО заранее, разработчик получает возможность:

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

Подготовительный этап

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

При подготовке к проектированию решаются организационные вопросы:

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

Этапы и результаты проектирования

Что делаем (описание продукта, функционала, пользователей)?
Как делаем (архитектура)?
Как проверить, что цель достигнута (тестирование, критерии оценки)?

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

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

Минимально достаточное ТЗ должно:

полностью, чётко (инструкционно, без воды, возможности разночтения) и структурировано описывать будущий программный продукт (как должен выглядеть, как и с чем работать, каким требованиям отвечать) и процесс его разработки, чтобы у архитектора не возникало вопросов по реализации,
исключать противоречивые сведения,
быть юридически точным (следовать ГОСТ 34.602-89), поскольку вместе с контрактом и прочими документами ТЗ приобретает юридическую силу.

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

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

Примеры техзаданий на разработку ПО

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

ТЗ на программное обеспечение Protector

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

Объект ТЗ: создание образовательной системы

ТЗ на разработку ПО SMPP-шлюз

Объект ТЗ: разработка программного обеспечения SMPP-шлюза
Заказчик: IMT

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

Проектирование — для больших парней

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

Есть замечания по нашей методологии или вы хотите поделиться своим опытом? Рады будем пообщаться в комментариях, в нашей группе в Фейсбуке или во Вконтакте.

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

Подобные документы

Тестирование программного обеспечения как часть процесса создания программного продукта, требования к нему, этапы и закономерности. Его разновидности: регрессионное, автоматизированное. Возможность построения конфигураций для настройки LTE-сетей.

курсовая работа, добавлен 08.02.2017

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

дипломная работа, добавлен 01.10.2015

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

дипломная работа, добавлен 12.06.2013

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

статья, добавлен 12.03.2019

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

дипломная работа, добавлен 10.07.2017

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

отчет по практике, добавлен 19.11.2020

Тестирование программного обеспечения как средство выявления ошибок в работе программ. Исследование основных методов и принципы тестирования программных комплексов, применяемых в интересах оценивания и контроля безопасности автоматизированных систем.

статья, добавлен 07.03.2019

Общая характеристика и классификация программного обеспечения. Построение программного обеспечения информационных систем. Стадии разработки и жизненный цикл программного продукта. Рассмотрение методов оценки затрат на разработку программных средств.

учебное пособие, добавлен 03.03.2018

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

дипломная работа, добавлен 04.07.2018

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

В последние годы наибольшее развитие и использование получил объектно–ориентированный, компонентный, сервисно–ориентированный подходы. Для их поддержки Были разработаны и инструментальные средства (Rational Rose, Rational Software, RUP, Demral , OОram и др.). Инструменты рассматриваются в теме 10.

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

В данной главе представлено описание основ методов систематического и отдельных методов теоретического программирования для ознакомления студентов с теорией и практикой проектирования ПС.

Методы систематического программирования

К методам систематического программирования отнесены следующие методы:

– моделирование в UML,

Каждый метод имеет свое множество понятий и операций для проведения процесса разработки компонентов или ПС. Вновь появившиеся методы, например, генерирующее программирование использует возможности объектно–ориентированного, компонентного и аспектно–ориентированного методов.

Дадим краткую характеристику возможностей этих методов, необходимую студентам для ознакомления с общими аспектами проектирования ПС в рамках приведенных методов.

Структурный подход

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

В основу структурного подхода положены такие общие принципы:

– разбивка системы на множество независимых задач, легких для понимания и решения;

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

В основе этих принципов лежат операции:

– абстрагирования, т.е. выделения существенных аспектов системы и отвлечения от несущественных;

– формализации, т.е строгое методологическое решение проблемы;

– непротиворечивости, состоящей в обосновании и согласовании элементов системы;

– структуризации данных (т.е. данные должны быть структурированы и иерархически организованы).

При структурном анализе применяются в основном три вида наиболее распространённых моделей проектирования ПС:

SADT (Structured Analysis and Design Technique) модель и соответствующие функциональные диаграммы [1];

SSADM (Structured Systems Analysis and Design Method) – метод структурного анализа и проектирования [2];

IDEF0 (Integrated Definition Functions) метод создания функциональной модели, IDEF1 – информационной модели, IDEF2 – динамической модели и др. [3].

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

Метод функционального моделирования SADT. На основе метода SADT, предложенного Д. Россом, разработана методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

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

Основные элементы этого метода основываются на следующих концепциях:

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

– строгость и точность. Правила SADT строги и имеют ограничения на количество блоков на каждом уровне декомпозиции (от 3 до 6 блоков) и связность диаграмм через номера блоков;

– уникальность меток и наименований;

– разделение входов и управлений ( определение роли данных).

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

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

Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), осуществляющий операцию, представляется дугой, входящей в блок снизу (рис.5.1).

Рис. 5.1. Структура модели

Одной из наиболее важных особенностей метода SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.

Метод SSADMбазируется на таких структурных диаграммах: последовательность, выбор и итерация. Моделируемый объект задается их сгруппированной последовательностью, следующих друг за другом, операторами выбора элемента из группы и циклическим выполнением отдельных элементов.

Базовая диаграмма является иерархической и включает в себя следующие: список всех компонентов описываемого объекта; идентифицированные группы выбранных и повторяемых компонентов, а также последовательных компонентов. Модель процесса проектирования включает в себя:

– моделирование взаимосвязей событий и сущностей;

– логическое проектирование данных;

– логическое проектирование БД;

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

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

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

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

– спецификацию функций и схемы реализации компонентов функций,

– описание процедурных и непроцедурных компонентов и интерфейсов,

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

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

ГОСТ

Проектированием программного обеспечения является процесс создания проекта программного обеспечения (ПО), кроме того, под проектированием ПО понимают дисциплину, изучающую методы проектирования.

Проектирование программного обеспечения представляет собой частный случай проектирования процессов и продуктов.

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

Ход процесса проектирования ПО и его результаты будут зависеть не только от состава требований, но и от опыта проектировщика (разработчика) и от выбранной модели процесса проектирования.

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

При проектировании ПО заранее разработчик имеет возможность:

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

Подготовительный этап

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

Готовые работы на аналогичную тему

Подготовки.
Проектирования.
Создания, включающего дизайн, кодирование, тестирование, документирование.
Поддержки, включающей внедрение и сопровождение.

В процессе подготовки к проектированию должны быть решены организационные вопросы:

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

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

Этапы и результаты проектирования

Проектирование состоит из следующих этапов:

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

Что делать (содержит описание продукта, функциональных возможностей, категорию пользователей)?
Как делать (содержит описание архитектуры)?
Как проверить, достигнута ли цель (варианты тестирований, критерии оценки)?

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

Требования к ТЗ на разработку программного обеспечения

Приведем минимальные требования, достаточные для ТЗ, в соответствии с которыми оно должно:

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

В техническом задании должны содержаться:

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

В составе ТЗ важно уделить внимание описаниям:

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

Естественно, сроки и соответственно стоимость проекта будут зависеть от его сложности, чем сложнее, тем длительнее и дороже подготовка к нему. Время разработки небольших проектов занимает от недели до месяца.

Читайте также: