Техническое задание определено рядом ГОСТов, как один из обязательных документов проекта, а некоторые заказчики считают выполнение ГОСТов обязательным условием. Кроме того, в случае низкой технической подготовки заказчика, ссылка на ГОСТЫ позволяет избежать произвола и формализовать отношения. ГОСТ 34.602 определяет, что техническое задание на автоматизированную систему, а как ее можно отнести к приложению интернета вещей, является основным документом определяющим требования и порядок создания, развития и модернизации автоматизированной системы. Соответственно, с техническим заданием, проводится разработка автоматизированной системы и ее приемка при вводе в действие. Техническое задание в соответствии с ГОСТом содержит следующие разделы, которые могут быть разделены на подразделы, это: общие сведения, назначения и цели создания, развития системы, характеристика объектов автоматизации, требования к системе, состав и содержание работ по созданию системы, порядок контроля и приемки системы, требования к составу содержанию работ по подготовке объектов автоматизации к вводу системы, в действие, далее идут требования к документированию и источники разработки. Видно, что если в зарубежной практике система документов проекта содержит его концепцию, варианты и сценарии использования, спецификацию, то техническое задание в отличие от спецификации, содержит не только требования к системе, но и требования к порядку ее создания и приемке. Какова же функция технического задания такого рода? Требования для анализа являются на этом этапе обобщенными и предполагают дальнейшую детализацию, в то время, как требования для разработки, могут быть непосредственно использованы разработчиками. Однако, на уровне технического задания, достаточно полно учтены лишь бизнес требования, а пользовательские требования приводится лишь на уровне перечня функций, но и то, тут в требованиях к системе уже фигурирует перечень подсистем, их назначения, основные характеристики, требования к числу и уровней иерархии и степень централизации системы, требования к способам и средствам связи для информационного обмена между компонентами системы, требования к режиму функционирования системы и так далее. Более того, по каждой подсистеме, должен быть приведен перечень функций, задач и их комплексов, подлежащих автоматизации. Временной регламент реализации каждой функции и задачи, требования к качеству реализации каждой функции и так далее. Ну все это предполагает понимание архитектуры системы, кроме того, техническое задание может содержать информацию о сроках создания, источниках финансирования, порядке ввода систему в эксплуатацию, что требует понимания деталей и реализации проекта. Поэтому естественно, что если техническое задание понимается, как задание от заказчика разработчику, то налицо явное противоречие, поскольку заказчики в общем случае представления о способе реализации заказываемой системы не имеют. Следствием этого кажущегося противоречия является то, что представителю сферы IT, часто приходится слышать, что техническое задание по ГОСТу, и вообще ГОСТ уже устарели, и вообще, что для IT-шной сферы они не подходят. Это совсем не так. Просто надо правильно понимать суть этих документов и правильно их использовать. Дело в том, что ГОСТы серии 19 или 34 рассчитаны не на модель заказчик-исполнитель, по которой работает большинство компаний в сфере IT, а на модель заказчик-архитектор-проектировщик-исполнитель. Практика отделения проектирования от реализации, чрезвычайно эффективна и по сути она стала залогом второй промышленной революции благодаря тому, что позволяет сделать деятельность более специализированной, а потом более производительной. Практика зарубежных компаний обычное дело, когда один архитектор или аналитик с теми же функциями, обеспечивает фронт работ 7-10 линейным программистом. У нас же довольно часто разработчик может быть одновременно и постановщиком задачи и разработчиком концепции, и архитектором, и кодером не говоря уж о тех случаях, когда концепция рождается прямо в процессе написания кода, а полученный результат уже постфактум документируется. А задание от заказчика, разработчику по ГОСТу, также есть, только оно называется по другому. Это заявка на разработку или тактико-техническое задание. Именно оно является результатом формирования требований к автоматизированной системе, как первый этап работ по проектам. Таким образом, организация работ по ГОСТу предполагает, что заказчик и архитектор тесно взаимодействуют друг с другом, выясняя требования и формируют предложения по концепции архитектуре решения. Согласованные видение, оформляется, как техническое задание проектировщику и в этом качестве, техническое задание становится частью соглашения между организацией заказчиком и организацией разработчиком, где определяются взаимные обязательства и оно уже является, юридически значимым документом. Соответственно, работа по ГОСТу может быть обязательной в случаях, когда, во-первых, это является требованием заказчика. Во-вторых, когда определяется принятый в организации и практикой, однако использование ГОСТа и в качестве основы может быть удобным в других случаях, например, чтобы формализовать отношения при работе с неквалифицированным заказчиком, чтобы задать единый контекст терминологии процедуры для организации работы в команде или взаимодействии с заказчиками имеющими разный опыт. Для разделения процессов разработки и изготовления системы в рамках одной компании, когда одно подразделение принимает на себя, проектировочные функции, а другие практическую реализацию или воплощение системы. Последний вариант становится все более популярным по мере того, как компании начинают брать разработчиков на удалёнке. Аутсорсер имеет подразделения в других регионах, тогда они получают к исполнению документ, функционально-аналогичный к заданию, пусть и в упрощенной форме. Вариант с работой, как в ГОСТЕ, становится полностью рабочим, когда заказчик обращается в одну компанию с разработкой аналитики, а к разработчикам приходит уже с готовым техническим заданием и вот этом случае, все детали, включая этап работ в порядке приемки, становятся вполне уместными. Наконец, частая разработка технического задания, является предметом деятельности аналитика. В этом случае, вполне возможно ориентироваться на те разделы ГОСТа, которые касаются требований к системе, в частности: концепция, требования к системам включая общие требования, требования к функциям, требования к видам обеспечения и функциональные требования, требования к документации и там, и так далее. Причем при таком оформлении, концепция обычно выносится в отдельный документ. В иных случаях, техническое задание по ГОСТУ, может стать, удобным шаблоном или чек листом, чтобы ничего не забыть, заготовка для повторного использования. Оно может задавать общий контекст, включая, терминологию для общения с заказчиком и разных разработчиков. Ссылкой на процессы, поскольку каждому документу соответствует процесс. И рад, что мы обсудили техническое задание по ГОСТу, упомянем им еще и эскизный технический проект по ГОСТу. Эти этапы работ по ГОСТу имеют примерно одинаковую структуру, но разработка идет с разным уровнем детализации. На данных этапах, происходит разработка проектных решений и разработка технической документации. В пояснительной записке к техническому или эскизному проекту, схемы организационные структуры комплекса технических средств, схемы функциональной структуры, схемы автоматизации, перечень входных и выходных сигналов и данных, описания автоматизированных функций и так далее. Рабочая документация, также согласовывается заказчиком и в индивидуальном порядке, фиксируются техзадании. Зачастую, проект рабочей документации ограничивают следующими документами, это: руководство пользователя или администратора, инструкция по эксплуатации, общее описание системы, причем в случае присутствия документа, пояснительная записка к техническому эскизному проекту, документ нецелесообразен, так как большинство разделов дублируются, ну и наконец программа и методика испытаний. И уже выше сказано, уже понятно, что применительно к разработке приложений интернета вещей стадия эскизного проекта, тут примерно соответствует разработке архитектуры проекта и высокого уровня его дизайна, а стадия технического, разработки и низкоуровневого дизайна, спецификаций, в том числе на использование сторонних комплектующих на согласование деталей их подключение, конфигурирования и так далее. На этом же этапе, производится детализация плана выполнения работ, производственных заданий для исполнителей и так далее. Можно считать, что переходом от стадии технического проекта, является спецификация требований, к программному обеспечению, дополненная в случае приложений интернета вещей, спецификации требований к вещам и другим внешним источникам, и потребителям данных. Международный стандарт определяет, что такая спецификация должна правильно определять все требования к программному обеспечению. Она не должна описывать детали разработки и реализации, они должны быть описаны на этапе разработки проекта. Она не должна налагать детальные ограничения на программное обеспечение. Эти ограничения надлежащим образом определяются в других документах таких, как плана обеспечения качества программных средств. Среди прочего, спецификация содержит требования к интерфейсам пользователей. Этот подраздел спецификации должен указывать следующее: логические характеристики каждого интерфейса между программным изделием и его пользователями, необходимое для выполнения требований к программному обеспечению, все объекты оптимизации интерфейса с пользователем, который должен использовать систему, они могут просто включать список разрешений и запрещения различных представлений, системы пользователю. К примеру, одним из таких примеров может быть требования, предъявляемые к опции длинных или коротких сообщений об ошибках. Подобно всем другим, эти требования должны быть проверяемые, например, там специалист такого то класса, может выполнить такую задачу через столько то минут тренировок, а не просто, что специалист может выполнить такую-то задачу. И разница между архитектором и дизайнером, как разработчиком концепции, инженером как разработчиком задания для исполнителя и исполнителем обсуждавшихся выше, здесь это достаточно наглядна. Видно, что между эскизным и техническим проектом происходит передача работ для дальнейшей детализации, от архитектора- проектировщику, от инженеров по требованию системных инженеров - к системным инженерам специалистам, от архитектора пользовательских взаимодействий- дизайнерам интерфейсов и так далее. Ориентация на проектный подход в разработке приложений интернета вещей, является тем более необходимой, чтобы отличие от разработчиков программного обеспечения, где проектировщики сами же себе и программисты, в создании системы принимают участие исполнители, разработчики, изготовители и монтажники физических устройств, поставщики данных и комплектующих и так далее. Они внешние по отношению к проектировщикам так же, как бригада маляров, каменщиков, электронщиков по отношению к проектному институту. Так что ориентация на организацию работ по ГОСТу тут более чем уместна. Итак, мы обсудили, то каким образом формируются требования к системе и разрабатывает свою концепцию, а дальше рассмотрим, как эти работы могут быть практически реализованы.
