Файл: Пример Технического задания.doc — Страницы №№1-4

Задание

1. Разработка и проектирование программного продукта магазина аудио-видео продукции.

Теоретический материал

Как писать техническое задание на программный продукт или
что значит фраза «по форме ГОСТ 19.201-78»

Рассмотрим, как правильно составить техническое задание на разработку программного продукта.

1. ОБЩИЕ ТРЕБОВАНИЯ
1.1 Техническое задание оформляется в соответствии с ГОСТ 19.106-78 на листах формата А4 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.
1.2 Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78. Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.

1.3. Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
1.4. Техническое задание должно содержать следующие разделы:
— введение;
— основания для разработки;
— назначение разработки;
— требования к программе или программному изделию;
— требования к программной документации;
— технико-экономические показатели;
— стадии и этапы разработки;
— порядок контроля и приемки;
в техническое задание допускается включать приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них.

2. СОДЕРЖАНИЕ РАЗДЕЛОВ
2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

2.2. В разделе «Основания для разработки» должны быть указаны:
— документ (документы), на основании которых ведется разработка;
— организация, утвердившая этот документ, и дата его утверждения;
— наименование и (или) условное обозначение темы разработки.
2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.
2.4. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:
— требования к функциональным характеристикам;
— требования к надежности;
— условия эксплуатации;
— требования к составу и параметрам технических средств;
— требования к информационной и программной совместимости;
— требования к маркировке и упаковке;
— требования к транспортированию и хранению;
— специальные требования.
2.4.1. В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. п.
2.4.2. В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).
2.4.3. В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.
2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.
2.4.5. В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования я программным средствам, используемым программой.
При необходимости должна обеспечиваться защита информации и программ.
2.4.6. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.
2.4.7. В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.
2.5а. В разделе «Требования к программной документации» должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней.
2.5. В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
2.6. В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки я определяют исполнителей.
2.7. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.
2.8. В приложениях к техническому заданию, при необходимости, приводят:
— перечень научно-исследовательских и других работ, обосновывающих разработку;
— схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
— другие источники разработки.

---

пример заполненного ТЗ.

Техническое задание на разработку модели системы дистанционного обучения с применением технологии «клиент-сервер».

1. Введение

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

2. Основания для разработки

Основанием для разработки является учебный план кафедры ИУ6 на 11-й семестр, утвержденный заведующим кафедрой.

3. Назначение разработки

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

4. Требования к программе или программному изделию.

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

Разрабатываемая модель должна обладать следующими функциями:

• Работать под управлением ОС Windows 95/98 или Windows NT/2000.

• Использовать для соединения и обмена данными протокол TCP/IP.

• Использовать свой протокол, как надстройку над TCP/IP для передачи данных и команд.

• Иметь доступный и простой интерфейс пользователя.

• Иметь гибкую систему настроек.

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

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

• Серверная часть должна поддерживать соединение до 32000 пользователей одновременно.

• Клиентская часть должна хранить базу данных адресов серверов для подключения.

  4.2 Требования к надежности.

Надежность системы в целом зависит от надежности используемой операционной системы. Серверная часть должна обслуживать без сбоев одновременное подключение и работу до 32000 пользователей. Обе части должны без потерь передавать информацию по каналу связи между клиентом и сервером.

4.3 Условия эксплуатации.

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

4.4 Требования к составу и параметрам технических средств.

---

Для нормальной работы как серверной, так и клиентской частей необходимо:

• Компьютер с процессором Intel Pentium-100 или 100%- совместимым.

• Оперативная память не менее 16 Мb.

• Жесткий диск объемом не менее 1 Gb.

• Наличие адаптера подключения к сети (сетевой карты, модема и т.п.).

• Установленная ОС Windows 95/98/NT/2000.

• Настроенный протокол TCP/IP.

4.5 Требования к информационной и программной совместимости.

Модель системы должна работать под управлением ОС Windows 95/98/NT/2000, поэтому требуется совместимость исполняемого модуля и библиотек динамического подключения стандартам, используемым этими ОС на платформе IBM PC. Модель должна использовать свой протокол передачи данных высокого уровня как надстройку над TCP/IP. Для хранения информации требуется использование баз данных формата MDB (Microsoft Access).
Для доступа к базам данных Microsoft Access 97 требуется наличие установленного ядра работы с БД Microsoft JET DAO версии 3.5. В качестве средства разработки требуется использовать интегрированную среду разработки Borland Delphi 5, включающую редактор исходных текстов, компилятор, компоновщик и отладчик.
В качестве средства проектирования структуры базы данных и создания файла базы данных требуется использовать Microsoft Access 97.

4.6 Требования к маркировке и упаковке.

Не предъявляются.

4.7 Требования к транспортированию и хранению.

Не предъявляются.

4.8 Специальные требования.

Не предъявляются.

5. Требования к программной документации.

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

6. Стадии и этапы разработки.

№	Содержание работы	Срок	Исполнитель этапа разработки
1	Исследование концепций дистанционного обучения и имеющихся на сегодняшний день решений.	1-2 недели	Цыганов П.В., Кузнецов Д.Д.
2	Выработка своего решения	3-я неделя	Цыганов П.В., Кузнецов Д.Д.
3	Выработка технического задания	4-я неделя	Цыганов П.В., Кузнецов Д.Д.
4	Разработка протокола прикладного уровня “DECSS Protocol” для передачи команд и данных между клиентом и сервером. Создание библиотеки классов, реализующей разработанный протокол.	5-7 недели	Цыганов П. В.
5	Принятие решения по разработке формата файлов для хранения учебных курсов. Разработка библиотеки классов для поддержки принятого формата.	5-7 недели	Кузнецов Д.Д.
6	На основе разработанного протокола создание «скелета» серверной и клиентской части модели.	8-10 недели	Цыганов П.В.|
7	На основе созданной библиотеки классов для работы с файлом учебного курса создание средств просмотра курса.	8-10 недели	Кузнецов Д.Д.
8	Объединение разработанных частей в единую модель.	11 неделя	Цыганов П.В., Кузнецов Д.Д.
9	Сдача и защита курсового проекта.	12 неделя	Цыганов П.В., Кузнецов Д.Д.

---

7. Порядок контроля и приемки.

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

• Запуск серверной и клиентской частей.

• Соединение клиента (-ов) с сервером, проверка правильности обработки сервером соединения.

• Аутентификация пользователя на сервере. Проверка изменения состава зарегистрированных пользователей и групп.

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

• Просмотр учебного курса с клиентского рабочего места.

• Завершение сеанса связи.

---

Карта сайта

Карта сайта

Веб-разработка Корпоративные сайты Личные кабинеты Интернет-магазины Сложные сайты Маркетплейсы Проектирование сайтов Шаблоны и готовые решения Чат-боты Разработка мобильных приложений Landing page Интернет-маркетинг Продвижение для B2B Контекстная реклама Продвижение интернет-магазинов Поисковое продвижение (SEO) SEO-аудит Веб-аналитика Email-маркетинг Таргетинг SMM Развитие проектов Технический аудит сайта Техническая поддержка сайтов Решения для Госсайтов CRM Битрикс24 HR-порталы Аренда проектной команды Сложные внедрения CRM для отдела продаж Аудит Согласование документов Перенос Битрикс24 Сложные доработки Первая HR-платформа 1С Внедрение 1С 1С и интернет-магазин Интеграция с Битрикс24 Доработка 1С Обновление 1С Сопровождение 1С Расширение 1С Реальная автоматизация IT-консалтинг от Степана B2B-платформа HR-порталы Маркетплейсы

Кто мы Портфолио На этой странице вы найдете портфолио разработанных сайтов, а также отзывы клиентов компании ИНТЕРВОЛГА. В каждом портфолио упакован бизнес клиента и описана работа, которую реализовали разработчики ИНТЕРВОЛГИ. Вакансии Вакансии для программистов Стажировка Импортозамещение Salesforce CRM и Cloud marketing Oracle Siebel CRM Oracle Siebel Loyalty Oracle HCM Cloud SAP SAP Ariba SAP Success Factors SAP SD Terrasoft Creatio Блог На этой странице вы найдете экспертные статьи и кейсы разработчиков и специалистов компании ИНТЕРВОЛГА о веб-разработке, интернет-маркетинге, внедрении, настройках и интеграции Битрикс24 и 1С, а так же кейсы и примеры Цены Отзывы На этой странице вы найдете отзывы клиентов компании ИНТЕРВОЛГА. Там указана компания и работа, которая была выполнена, а так же контакты лица, который оставил этот отзыв. Контакты

Подготовка технического задания для проекта по развитию ИТ АКА 6 шагов к новой информационной системе, интернет-магазину или сети

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

1. Кратко запишите справочную информацию о проекте.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

3. Подумайте о требованиях к вашему проекту и запишите их.

 

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

 

У большинства веб-сайтов обычно всего несколько требований, в то время как у интернет-магазинов, приложений и особенно информационных систем их больше. Требованиями могут быть, например, выбор языка (независимо от того, должно ли быть 1, 3 или 10 разных языков), функциональные возможности, требуемые пользователями, требования доступности, требования к нагрузке и т. д.

 

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

 

Чем больше интерфейсов и чем они сложнее, тем выше объем разработок и стоимость проекта.

 

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

 

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

 

4. Затем продумайте и запишите, кто ваши типичные пользователи (персоны).

 

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

 

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

 

5. Если возможно, нарисуйте первоначальный прототип.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

В Trinidad Wiseman мы можем помочь вам на каждом этапе проекта и провести анализ, дизайн UX / UI, брендинг, разработку, тестирование и обслуживание. В любом случае, я призываю вас написать нам, даже если техническое задание еще не ясно.

 

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

 

 

Техническое задание | Министерство бизнеса, инноваций и занятости

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

Роль и функции Совета

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

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

В частности, Совет будет:

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

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

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

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

Роль Председателя

Председатель Совета отвечает за:

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

Членство

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

Министр экономического и регионального развития может путем письменного уведомления назначить:

• любое физическое лицо в качестве члена
• любого члена в качестве председателя или заместителя председателя.

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

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

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

Совет классифицируется как орган Группы 4 Уровня 3 в соответствии с Концепцией сборов Кабинета министров. Члены несут ответственность за уплату всех налоговых отчислений, других налогов и сборов Корпорации по возмещению несчастных случаев в отношении вознаграждения и выплат. Члены, представляющие государственные учреждения или юридические лица короны, назначаются в качестве представителей и не имеют права на какое-либо дополнительное вознаграждение. Ежедневное вознаграждение для всех остальных будет требоваться в соответствии с инструкциями Кабинета министров.

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

Роль Министерства бизнеса, инноваций и занятости

Министерство бизнеса, инноваций и занятости обеспечит секретариат Совета. Секретариат:

• отвечает за все административные задачи, связанные с Советом, включая организацию встреч, предоставление документов, координацию поездок и организацию оплаты их гонораров и расходов.
• будет присутствовать на собраниях и составлять протоколы и действия в течение десяти рабочих дней после собрания.
• сопоставлять и представлять рекомендации Совета лицам, принимающим решения, и отчитываться перед Советом о принятых решениях и любой соответствующей обратной связи от лиц, принимающих решения. 902:30

Права на принятие решений и протокол консультаций

При рассмотрении и предоставлении рекомендаций по любому предложению, которое ему предлагается рассмотреть, Совет может с ведома и согласия министра:

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

Совет с письменного согласия министра экономического и регионального развития будет документировать системы и процессы, которые он будет использовать для работы, включая:

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

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

Собрания

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

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

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

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

Приглашенные эксперты

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

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

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

Обязательства

При выполнении своих функций Совет будет:

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

Члены Совета должны:

• действовать добросовестно, проявлять честность, добросовестность, открытость и подотчетность в отношениях друг с другом
• действовать в соответствии со Стандартами честности и поведения государственного сектора
• предоставлять бесплатные и откровенные консультации по вопросам, рассматриваемым Советом, сохраняя при этом свободу действий в отношении этих рекомендаций и их поведения в бизнес-сообществе 902:30
• следуйте согласованным протоколам связи, прежде чем делать публичные заявления по любому аспекту Совета.

Закон об официальной информации 1982 года

Закон об официальной информации применяется к документам Совета.

Пункт о конфиденциальности

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

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

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

Члены Совета будут делать публичные комментарии только после того, как уведомят Министра экономического и регионального развития через Председателя о своем намерении сделать это. Председатель информирует непосредственно Министра о своем намерении выступить с публичными комментариями. Этот судебный запрет будет применяться независимо от того, согласны или не согласны члены с действиями правительства, которые они комментируют.