Техническое задание (приложение к государственному контракту на выполнение работ в области технического регулирования)

Содержание

Техническое задание на разработку приложения

Техническое задание (приложение к государственному контракту на выполнение работ в области технического регулирования)

ТЗ на разработку — а оно нам надо?

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

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

Он тоже заинтересован в успехе вашего сотрудничества.

1 шаг. Идея разработки мобильного приложения

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

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

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

Возможно, что-то вы сможете сделать сильно лучше, и как итог — переманить клиентов у конкурентов.

2 шаг. Вопросы, с которых начинается ТЗ

Чтобы составить ТЗ, для начала нужно ответить на несколько вопросов:1. Для кого это приложение? Для ваших клиентов, будущих или потенциальных, или для всех сразу? Или для ваших сотрудников?2.

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

В устройствах каких марок вы планируете поселить ваше приложение? От этого зависит, какую платформу для приложения вы выберите — iOS, Android, Windows.5. Когда вы хотите получить готовое приложение? То есть сроки.6.

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

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

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

3 шаг. Настало время ТЗ!

ТЗ – индивидуальный документ, и каждый раз составляется заново под каждый проект. Это также зависит и от разработчика, к которому вы обратились.

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

1. Терминология.

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

2. Цель создания системы, то есть приложения. Здесь вы подробно описываете, что пользователь сможет делать в приложении, какие действия и какой результат он получает. В общем, для чего ваше приложение будут скачивать люди в свои смартфоны. Если у вас приложение для магазина, то вы должны решить, к примеру —пользователь будет просто просматривать каталоги, узнавать о наличии товаров в магазинах или сразу покупать и заказывать доставку?
3. Требования к приложению. Самая сложная часть техзадания, где технические термины льются как из рога изобилия. Написать это самому нереально. Но важно понимать, что каждый шаг будущего пользователя должен быть продуман до технических мелочей. К примеру, из тз должно быть четко ясно, что случится, если нажать на вот эту красную кнопочку.
4. Сценарии использования. Что происходит, когда человек впервые заходит в приложение? Нужно ли регистрироваться? А что произойдет, когда он зайдет повторно? Все эти пути важно описать в тз, ведь это поможет выявить, какие функции нужны приложению и что именно должно в нем происходить.
5. Описание экранов. Некоторые тз содержат прототипы экранов, если они уже готовы. В некоторых есть даже первичный дизайн. В любом случае описать экраны хотя бы словами просто необходимо. Ведь для многих пользователей приложение – это и есть экран. Именно с ним он имеет дело, и что толку от функции регистрации, к примеру, если ни на одном экране нет такой кнопки?
6. Требования к платформе, CMS, архитектура системы… и еще много страшных слов, если вы не разработчик или технический писатель.
Ваше ТЗ может не содержать тех или иных разделов только в том случае, если это не существенно именно для вашего проекта. Но узнать, что именно существенно, а что нет, вы сможете только от разработчика.

Начните прямо сейчас!

На самом деле, написать хорошее ТЗ — просто, если подойти к этому делу с умом. И не возлагать на себя одного это нелегкое дело. Ведь ТЗ нужно для результативного взаимодействия.

А значит, в составлении ТЗ должны принимать участие обе стороны и… та-дам! Основные технические трудности мы берем на себя!
Как говорится, глаза боятся — а руки-то вот они. Тут важно начать. Часто, это главная заминка в начале успешного проекта.

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

Источник: https://punicapp.com/blog/pages/332/tehnicheskoe-zadanie-na-razrabotku-prilozheniya/

Об утверждении рекомендуемых форм государственных контрактов, договоров и дополнительных соглашений на выполнение работ за счет средств федерального бюджета (с изменениями на 5 мая 2009 года), Приказ Росстандарта от 26 февраля 2009 года №633

Техническое задание (приложение к государственному контракту на выполнение работ в области технического регулирования)

(с изменениями на 5 мая 2009 года)

____________________________________________________________________
Документ с изменениями, внесенными:
приказом Ростехрегулирования от 5 мая 2009 года N 1683.
____________________________________________________________________

Для организации деятельности Федерального агентства по техническому регулированию и метрологии по реализации постановления Правительства Российской Федерации от 24 декабря 2008 года N 987 “О мерах по реализации Федерального закона “О федеральном бюджете на 2009 год и на плановый период 2010 и 2011 годов” (Собрание законодательства Российской Федерации от 5 января 2009 года N 1 ст.141), в соответствии с подпунктом 5.1 и абзацем 2 пункта 7 Положения о Федеральном агентстве по техническому регулированию и метрологи, утвержденного постановлением Правительства Российской Федерации от 17 июня 2004 года N 294,
приказываю:

1.

Утвердить прилагаемые к настоящему приказу рекомендуемые формы: государственных контрактов на выполнение:

работ в области технического регулирования (приложение 1), научно-исследовательских и опытно-конструкторских работ (приложение 2), работ в области каталогизации продукции для федеральных государственных нужд (приложение 3), работ по Премии Правительства Российской Федерации в области качества (приложение 4), работ в рамках федеральной целевой программы “Развитие инфраструктуры наноиндустрии в Российской Федерации на 2008-2010 годы” (приложение 5), работ в рамках федеральной целевой программы “Глобальная навигационная система ГЛОНАСС” (приложение 6); работ “На финансирование объекта за счет государственных капитальных вложений” (приложение 7);

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

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

2. Контроль за исполнением настоящего приказа оставляю за собой.

РуководительФедерального агентстваГ.И.Элькин

Приложение 1. Государственный контракт на выполнение работ в области технического регулирования

Приложение 1к приказу Федерального агентствапо техническому регулированию иметрологииот 26 февраля 2009 года N 633

(в редакции приказа Ростехрегулирования
от 5 мая 2009 года N 1683 –

см. предыдущую редакцию)

Лот N
(наименование темы*)
от “г.N

________________
* Строго по названию лота в протоколе или приказе.

Федеральное агентство по техническому регулированию и метрологии (Ростехрегулирование), действующее от имени Российской Федерации, именуемое в дальнейшем “Государственный заказчик” в лице заместителя Руководителя Федерального
агентства по техническому регулированию и метрологии,
действующего на основании Доверенности от “г. N,
с одной стороны, и,
(наименование организации-исполнителя)
именуемый в дальнейшем – “Исполнитель”, в лице,
(Ф.И.О., должность)
действующего на основании, с другой стороны, именуемые в
дальнейшем “Стороны”, заключили настоящий государственный контракт о нижеследующем:

I. Предмет государственного контракта

1.1. “Исполнитель” обязуется выполнить и сдать “Государственному заказчику” в соответствии с утвержденными и согласованными сторонами техническим заданием (приложение N 1), календарным планом (приложение N 2), протоколом согласования цены (приложение N 3) и сметой расходов (приложение N 4), составляющими неотъемлемую часть настоящего государственного контракта, а последний обязуется принять и оплатить работу по
(наименование лота)
Основание для заключения контракта
(наименование, номер и дата документа)
протокол конкурсной комиссии (приказ Федерального агентства) N.
1.2. и сроки выполнения отдельных этапов работы определяются календарным планом (приложение N 2) и техническим заданием (приложение N 1), составляющими неотъемлемую часть настоящего государственного контракта. 1.3. Требования и содержание технического задания могут уточняться и дополняться путем подписания Дополнений к техническому заданию. “Государственный заказчик” имеет право проверять ход и качество выполнения работы, предусмотренной государственным контрактом, а также целевое расходование средств.

II. Стоимость и сроки выполнения работ, порядок расчетов

2.1. Контрактная цена в соответствии с Протоколом согласования цены на выполнение работ по государственному контракту (приложение N 3) установлена в сумме ___________________________________________________тысяч (________) рублей, в том числе НДС 18% – ______________________________ рублей. Срок выполнения работы _______________________________.

2.2. Источник финансирования расходов, предусмотренных настоящим государственным контрактом – федеральный бюджет (раздел 04 “Национальная экономика”, подраздел 01 “Общеэкономические вопросы”, целевая статья 3400101 “Техническое регулирование”, вид расходов 012 “Выполнение функций государственными органами”, статья расходов 226 “Прочие работы, услуги”).

2.3. Расчеты за выполняемую по настоящему государственному контракту работу производятся между “Государственным заказчиком” и “Исполнителем” по выполненным и сданным этапам в размере их цены.

2.4. Аванс на выполнение работ (этапов работы) составляет до 30% от годовой стоимости работы.

2.5. Оплата стоимости работ или отдельного этапа работы производится по окончании работ или отдельного этапа работы на основании актов сдачи – приемки работ в течение 15 дней после их утверждения “Государственным заказчиком” за вычетом полученного аванса.

2.6. “Исполнитель” обязан обеспечить у себя надлежащий бухгалтерский учет и анализ фактической стоимости выполняемой работы в разрезе этапов.

2.7. Финансирование государственного контракта за счет федерального бюджета может быть приостановлено, уменьшено или прекращено в случае неполного выделения “Государственному заказчику” бюджетных ассигнований или невыполнением “Исполнителем” своих обязательств по государственному контракту, о чем “Государственный заказчик” уведомляет “Исполнителя”.

III. Порядок сдачи-приемки работ по государственному контракту

3.1. По окончании выполнения работ и отдельных этапов работы “Исполнитель” представляет “Государственному заказчику” акты сдачи-приемки работ и отчетные документы в соответствии с календарным планом (приложение N 2) на бумажном носителе и в сканированном виде на электронном носителе (флэш-памяти или дискете).

3.2. Приемка работ и отдельных этапов работы осуществляется в соответствии с техническим заданием (приложение N 1).

3.3. “Государственный заказчик” в течение 10 календарных дней со дня получения отчетных документов обязан рассмотреть результаты работ и отдельных этапов работы и направить “Исполнителю” утвержденные акты сдачи-приемки или мотивированный отказ в приемке работ.

3.4. В случае мотивированного отказа “Государственного заказчика” в приемке работ (отдельных этапов работы), “Сторонами” составляется двухсторонний акт с перечнем необходимых доработок и сроков их выполнения. “Исполнитель” обязан произвести необходимые исправления без дополнительной оплаты.

IV. Ответственность Сторон

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

4.2. “Исполнитель” несет ответственность перед “Государственным заказчиком” за нарушение государственного контракта, если не докажет, что нарушение произошло не по его вине (ст.401 Гражданского кодекса Российской Федерации).

4.3. “Исполнитель” обязан возместить убытки, причиненные им “Государственному заказчику”, в пределах стоимости работ, в которых выявлены недостатки (реальный ущерб).

4.4.

За нарушение установленного по настоящему государственному контракту срока выполнения отдельных этапов работы, определенных календарным планом, “Исполнитель” уплачивает “Государственному заказчику” неустойку в размере одной трехсотой действующей на день уплаты неустойки (штрафа, пеней) ставки рефинансирования Центрального банка Российской Федерации за каждый день просрочки (ч.9 ст.9 Федерального закона от 21.07.2005 N 94-ФЗ).

Источник: http://docs.cntd.ru/document/902146512

Пример тз на разработку программного обеспечения, как написать техническое задание

Техническое задание (приложение к государственному контракту на выполнение работ в области технического регулирования)

Написание технического задания — один из первых этапов работы над проектом. Он предваряет разработку самой системы.

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

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

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

Мы используем термины «Бизнес-требования» (BRD — Business requirements document), «Функциональные требования» (FRD – Functional requirements document) и Технико-архитектурные требования (TAD – Technical Architecture document).

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

Документ, который мы в большинстве случаев используем для взаимодействия с заказчиками состоит на 70% — из бизнес-требований, на 20% из функциональных требований и только на 10% — из технико-архитектурных требований. Конечно, эта пропорция варьируется в зависимости от специфики и технической сложности системы.

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

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

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

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

Структура технического задания

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

1. Оглавление 2. История изменений документа 3. Участники проекта 4. Назначение документа 5. Терминология

6. Общий контекст

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

В разделе «Терминология» технического задания на баннерную систему мы определяем такие понятия как Показы, Клики, CTR, Охват, Частота контакта, Файл бронирования и т.

п, а в разделе «Общий контекст» — описываем основные бизнес-процессы компании-заказчика, относящиеся к размещению баннерной рекламы, а также — системное окружение, текущие роли менеджеров компании и права доступа. Стоит отметить, что в данном конкретном случае система строилась не на пустом месте.

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

7. Система размещения баннеров
8.

Взаимодействие с биллингом 9. Banner Engine

10. Техническое описание компонента Banner Engine

Самый объемный раздел описываемого нами технического задания – «Система размещения баннеров»; он посвящён ядру разрабатываемой системы и содержит все требования непосредственно к системе управления рекламными местами.

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

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

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

Каждое техническое задание отличается по размеру, числу иллюстраций, количеству версий. Для примера, документ на баннерку представлен на 44 страницах и содержит 15 иллюстраций. Процесс подготовки этого документа занял около месяца и включал около 8 итераций с заказчиком.

Бизнес vs Функциональные требования

В техническом задании регистрируются как бизнес-требования к системе, так и функциональные требования:

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

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

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

Пример бизнес-требования:

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

Пример функционального требования:

«Для решения этой задачи [какой – см. выше] предполагается использовать внешний сервис, к которому баннерные сервера будут обращаться при каждом показе баннера. Поскольку данный сервис является точкой отказа, баннерные сервера должны корректно обрабатывать ситуацию когда внешний сервис недоступен или отвечает с задержками».

Обычно мы включаем

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

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

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

Название сценария: Создание рекламного места

Роль: Администратор

Пример функционального требования:

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

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

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

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

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

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

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

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

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

Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.

Основные принципы

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

В данном контексте, мы видим своей целью т.н. рисование ТЗ, т.е.

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

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

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

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

Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.

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

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

Опыт в предметной области

Большое значение при создании технического задания имеет опыт разработки похожих систем. Он помогает быстрее вникать в бизнес-процессы и потребности заказчика, делать «по аналогии» многие вещи, которые ранее казались бы нам сложными.

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

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

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

Источник: https://steptosleep.ru/%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5-%D0%B7%D0%B0%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BD%D0%B0-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%83/

Договор на разработку технического задания

Техническое задание (приложение к государственному контракту на выполнение работ в области технического регулирования)

ДОГОВОР

НА РАЗРАБОТКУ ТЕХНИЧЕСКОГО ЗАДАНИЯ

1

Санкт-Петербург

«31» декабря  2014 г.

Общество с ограниченной ответственностью «Компания 1» (сокращенное наименование ООО«Компания 1»), именуемое в дальнейшем Заказчик, в лице генерального директора Братчикова Станислава Вячеславович, действующего на основании Устава, с одной стороны, и Общество с ограниченной ответственностью «Компания 2» (сокращенное наименование ООО «Компания 2»), именуемый в дальнейшем Исполнитель, в лице генерального директора Иванова Ивана Ивановича, действующего на основании Устава, с другой стороны (далее по тексту договора по отдельности именуемые – «Сторона», а совместно – «Стороны»), заключили настоящий Договор (далее по тексту – «Договор») о нижеследующем:

1.              ПРЕДМЕТ ДОГОВОРА

1.1.

         Заказчик поручает и оплачивает, а Исполнитель обязуетсясогласно требованиям Заказчика разработать Техническое задание на разработку системы X (далее СX) согласно серверной архитектуре указанной в Приложении №1, включающее: web-сайт системы, программный комплекс системы мониторинга, взаимодействие модулей системы, интеграция с внешними системами, мобильные приложения под Android, iOS.

1.2.         Перечень и стоимость работ представлены в Приложении № 3 к настоящему Договору.

2.              ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТ

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

2.2.         Исполнитель разрабатывает Техническое задание системы в срок определённый в Приложениях 3,4 к настоящему Договору, и предоставляет на утверждение Заказчику.

2.3.         Обязательства Исполнителя по Договору считаются выполненными после подписания Сторонами Акта сдачи-приемки работ.

Заказчик в течении 5 (пяти) рабочих дней со дня получения Акта сдачи-приемки работ по настоящему Договору обязан направить Исполнителю подписанный Акт сдачи-приемки работ или мотивированный отказ от приемки работ.

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

2.4.         Принятое Заказчиком Техническое задание подтверждается письмом в адрес Исполнителя и, в случае необходимости, дорабатывается окончательно на основании замечаний Заказчика, после чего Стороны подписывают Акт сдачи-приёмки работ.

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

2.6.         Договор считается выполненным после подписания Актов сдачи-приёмки работ.

2.7.         Акт сдачи-приёмки работ предоставляется Заказчику в течение 5 (Пяти) рабочих дней с момента предоставления Исполнителем результатов работ.

2.8.         Если в течение 5 (пяти) рабочих дней с момента получения Акта сдачи-приёма, данный Акт не будет подписан Заказчиком, и не будут отправлены в адрес Исполнителя мотивированные возражения, работы считаются выполненными надлежащим образом и принятыми.

2.9.         Право собственности на результат работ, выполненных Исполнителем, становится собственностью Заказчика, в момент подписания Сторонами Акта сдачи-приемки работ.

2.10.      Вместе с подписанным Сторонами Актом сдачи-приемки работ, Заказчик получает от Исполнителя все необходимые материалы, которые являются результатом проведения работ Исполнителем.

3.              Стоимость работ и порядок оплаты

3.1           Сумма настоящего Договора соответствует Перечню и стоимости работ, указанных в Приложениях № 2,3, и включает в себя сумму НДС 18%.

3.2           Оплата работ по Договору производится на условиях 100% постоплаты в течение не более 5 рабочих дней со дня подписания Заказчиком Акта сдачи-приемки работ.

3.3           В платёжных документах сумма НДС (18%) выделяется отдельной строкой.

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

3.5           В случае отказа Заказчика от услуг Исполнителя, добросовестно выполняющего свои обязательства, оплаченная сумма не возвращается Заказчику.

4.              СРОК ДЕЙСТВИЯ ДОГОВОРА

4.1.         Настоящий Договор вступает в силу с момента подписания и действует до исполнения Сторонами принятых на себя обязательств.

5.              ОТВЕТСТВЕННОСТЬ СТОРОН

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

5.2.         За просрочку оплаты Исполнитель вправе потребовать от Заказчика уплатить неустойку в размере 0,1% от неуплаченной суммы за каждый день просрочки, но не более 10% от размера неуплаченной суммы.

5.3.         За неисполнение работ в срок Заказчик вправе потребовать от Исполнителя неустойку в размере 0,1% от стоимости настоящего Договора за каждый день просрочки, но не более 10% от стоимости настоящего Договора.

5.4.         Оплата неустойки осуществляется на основании письменного требования пострадавшей Стороны и ее признания виновной Стороной с даты, указанной в требовании.

5.5.         Оплата неустойки не освобождает Сторону от исполнения обязательств по настоящему Договору.

6.              КОНФИДЕНЦИАЛЬНОСТЬ

6.1.

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

6.2.         Обязательства конфиденциальности продолжают действовать в течение 1 (Одного) года после истечения срока данного Договора на предоставление услуг.

7.              ФОРС-МАЖОР

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

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

Также Исполнитель не несет ответственности за работоспособность средств связи Заказчика.

8.              ПРОЧИЕ УСЛОВИЯ

8.1.         В случае возникновения разногласий между Сторонами по вопросам, предусмотренным настоящим Договором или возникшим в связи с его исполнением, Стороны принимают меры к их разрешению путем переговоров.

Оставшиеся неурегулированными разногласия передаются на рассмотрение Арбитражного суда Санкт-Петербурга и Ленинградской области на основании ГПК РФ или АПК РФ на русском языке и на основании настоящего Договора.

8.2.         Недействительность какого-либо из условий Договора не влечет за собой недействительности всего Договора в целом.

9.        РЕКВИЗИТЫ СТОРОН

ИСПОЛНИТЕЛЬ

ООО «Компания 1»

ИНН

КПП

Индекс, Страна, Город,

Адрес

ОГРН

р/сч

в Ст.-Петербургском ф-ле

ОАО «банк» г.Санкт-Петербург

БИК

К/с

_____________________/ Петров П.П.

 М.П.

ЗАКАЗЧИК

ООО «Компания 2»

ИНН

КПП

Индекс, Страна, Город,

Адрес

ОГРН

р/сч

в Ст.-Петербургском ф-ле

ОАО «банк» г.Санкт-Петербург

БИК

К/с

______________/ Иванов И.И.

 М.П.

Приложение N1 к Договору

№ 1 от «31»декабря 2014 года

Архитектура системы X

Описание…

Исполнитель                                                                                                                                         Заказчик

________________/ Петров П.П.                                 ______________/ Иванов И.И.

М.П.                                                                                             М.П.    

Приложение N2 к Договору

№ 1 от «31»декабря 2014 года

Описание компонентов архитектуры системы указанной в Приложении №1

  1. База данных – в качестве СУБД используется MySQL.
  2. Модуль безопасности – данный компонент обеспечивает авторизацию и аутентификацию пользователей в системе. В модуль входит такие сущности как «Роли», «Пользователь», «Права». Модуль имеет только локальный API, для обеспечения доступа к нему только локальным подсистемам.
  3. Модуль оповещения – данный компонент обеспечивает посылку сообщений пользователям, платежным системам и т.д. Поддерживает протоколы E-mail, SMPP, SMTP, HTTP. Модуль имеет только локальный API, для обеспечения доступа к нему только локальным подсистемам.
  4. Аналитика и отчеты – компонент обеспечивает подготовку и демонстрацию отчетов. Анализ данных, поиск зависимостей, поиск аномалий и т.д. Оповещение администрации об аномалиях. Модуль имеет только локальный API, для обеспечения доступа к нему только локальным подсистемам.
  5. Web приложение – компонент обеспечивающий связь пользователя и функциональными компонентами. Получает запросы по протоколу HTTP, обрабатывает их, при необходимости обращается к функциональным компонентам, формирует ответ и отправляет его по HTTP. Состоит из разделов, которые соответствуют функциональным компонентам.
  6. Интеграция – компонент обеспечивает передачу финансовой информации в 1С-Бухгалтерию на уровне проводок.
  7. Сервер приложений – .
  8. Web сервер-1 – Apache
  9. Web сервер-2 – Apache
  10. CMS – сайт компании, включает в себя новости, блог и т.д. Используется язык PHP, framework yii.
  11. CMS DB – Maria DB

Related Posts via Categories

Источник: http://pm-notes.ru/contract_development_technical_specifications/

Поделиться:
Нет комментариев

    Добавить комментарий

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.