Образец технического задания на закупку программного обеспечения для скорой помощи

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

Сохрани ссылку в одной из сетей:

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

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

Требования к поставляемойпродукции

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

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

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

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

Требования по гарантийномуи послегарантийному обслуживанию

Гарантийное обслуживаниепоставляемого товара должно осуществлятьсябез затрат со стороны Заказчика в течение1 (Одного) года.

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

Продолжительность техническойподдержки программного обеспечениядолжна составлять не менее 3 (Трех)месяцев с момента поставки программногообеспечения.

Поставщик должен продемонстрироватьвозможность удаленного (через сетьInternet) доступа к ресурсам техническойподдержки.

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

Срок поставки программногообеспечения не может превышать 1 (одного)месяца с момента подписания договора.

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

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

Спецификация программногообеспечения

Источник: https://gigabaza.ru/doc/78182.html

Стандарты и шаблоны для ТЗ на разработку ПО

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её.

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

Придется сделать такую статейку самому… И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification): • Гост 34 • Гост 19 • IEEE STD 830-1998 • ISO/IEC/ IEEE 29148-2011 • RUP • SWEBOK, BABOK и пр.

Гост 34

Гост 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно Гост 34 техническое задание должно включать следующие разделы: 1. Общие сведения 2. Назначение и цели создания (развития) системы 3. Характеристика объектов автоматизации 4. Требования к системе 5. Состав и содержание работ по созданию системы 6.

Порядок контроля и приемки системы 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие 8. Требования к документированию 9.

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

Гост 19

“Гост 19.

ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.

Согласно Гост 19.201-78 Техническое задание, требования и оформлению техническое задание должно включать следующие разделы:

1. Введение; 2. Основания для разработки; 3. Назначение разработки; 4. Требования к программе или программному изделию; 5. Требования к программной документации; 6. Технико-экономические показатели; 7. Стадии и этапы разработки; 8. Порядок контроля и приемки; 9. Приложения. Естественно Гост 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании: Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS.

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

• 1. Назначение
• 2. Область действия
• 3. Определения, акронимы и сокращения
• 4. Ссылки
• 5. Краткий обзор

2. Общее описание

• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователя
• 4. Ограничения
• 5. Допущения и зависимости

3.

Детальные требования (могут быть организованы по разному, н-р, так)

• 1. Требования к внешним интерфейсам
  • 1. Интерфейсы пользователя
  • 2. Интерфейсы аппаратного обеспечения
  • 3. Интерфейсы программного обеспечения
  • 4. Интерфейсы взаимодействия
• 2. Функциональные требования
• 3.

  Требования к производительности

• 4. Проектные ограничения (и ссылки на стандарты)
• 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
• 6. Другие требования

4. Приложения 5.

Алфавитный указатель

На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который легко найти в Интернете. Как и примеры, правда, на англ. языке.

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

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований: • System requirements specification (SyRS) • Software requirements specification (SRS) System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека.

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

Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в Гост 34. SyRS может содержать следующие разделы: 1. Введение

• 1. Назначение системы
• 2. системы (границы системы)
• 3. Обзор системы
  • 1. системы
  • 2. Функции системы
  • 3. Характеристики пользователей
• 4. Термины и определения

2. Ссылки 3. Системные требования

• 1. Функциональные требования
• 2. Требования к юзабилити
• 3. Требования к производительности
• 4. Интерфейс (взаимодействие) системы
• 5. Операции системы
• 6. Состояния системы
• 7. Физические характеристики
• 8. Условия окружения
• 9. Требования к безопасности
• 10. Управление информацией
• 11. Политики и правила
• 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
• 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3) 5. Приложения

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в Гост 19, а по структуре очень напоминает SRS из стандарта IEEE 830. SRS может содержать следующие разделы: 1.

Введение

• 1. Назначение
• 2. (границы)
  • 3. Обзор продукта
  • 1. Взаимодействие продукта (с другими продуктами и компонентами)
  • 2. Функции продукта (краткое описание)
  • 3. Характеристики пользователей
  • 4. Ограничения
• 4. Термины и определения

2. Ссылки 3. Детальные требования

• 1. Требования к внешним интерфейсам
• 2. Функции продукта
• 3. Требования к юзабилити
• 4. Требования к производительности
• 5. Требования к логической структуре БД
• 6. Ограничения проектирования
• 7. Системные свойства ПО
• 8. Дополнительные требования

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3) 5. Приложения

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

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

RUP

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт. • Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases): 1. Введение.

• 1. Цель.
• 2. Краткая сводка возможностей.
• 3. Определения, акронимы и сокращения.
• 4. Ссылки.
• 5. Краткое содержание.

2. Обзор системы

• 1. Обзор вариантов использований.
• 2. Предположения и зависимости.

3. Детальные требований

• 1. Описание вариантов использования.
• 2. Дополнительные требования.
• 3. Другие функциональные требования.
• 4. Нефункциональные требования.

4. Вспомогательная информация.

Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP.

SWEBOK, BABOK и пр

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

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр.

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

А как же agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места. Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.

Заключение

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

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

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

Также рекомендую ознакомиться со следующими материалами:

Источник: https://habr.com/post/328822/

Все, что нужно знать об импортозамещении ПО

Статья актуальна на 1 января 2020

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

Есть закон

1 января 2016 года вступил в силу 188-ФЗ, который дает российским разработчикам преимущество перед иностранными при участии в госзакупках. Если у иностранного софта есть российский аналог, который занесен в специальный реестр, заказчик обязан купить именно его.

Закон определяет такие критерии для российского ПО:

• исключительное право на него должно принадлежать РФ или субъекту РФ, муниципальному образованию, российской коммерческой или некоммерческой организации,  в которой больше 50% принадлежит России, российским организациям или гражданам;
• организацию-правообладателя не должно контролировать иностранное лицо;
• выплаты в пользу иностранных организаций не должны превышать 30% всех платежей за ПО;
• ПО должно находиться в свободной продаже, сведения о нем не должны быть гостайной.

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

Действует постановление № 1236 от 16.11.2015

Документ содержит:

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

Заработал реестр отечественного ПО

До недавнего времени госзаказчики могли работать по принципу «нет реестра — нет ограничений», но с 20 февраля 2016 реестр начал наполняться. В него уже попали приложения ABBYY, «1С», Dr.Web, Касперский, «Барс», «Гарант» и другие.  Всего в реестре 6182 продукта, в том числе аналог «Microsoft Office» — программа «Мой офис» от российского разработчика «Новые облачные технологии».   

Отдельно создан реестр ПО из стран ЕАЭС.

Как поступают заказчики?

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

2. Объявляют тендер не на закупку ПО, а на закупку компьютеров с предустановленной программой, например, с тем же  «запрещенным» Microsoft Office, дополняя закупку формулировкой «эквивалент невозможен в связи с необходимостью обеспечения совместимости с уже имеющимся ПО заказчика».
3. Обосновывают невозможность закупки российского ПО. Например, как в этой закупке.

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

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

Нина Васильевна Шараева, начальник отдела закупок ИММ УРО РАН:

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

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

Ирина Яворская, руководитель компании GosTrader, занимающейся тендерным сопровождением заказчиков и поставщиков:

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

Если вы продавец ПО

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

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

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

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

Ирина Яворская, GosTrader:

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

Если вы производитель-правообладатель

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

Иностранные производители готовятся адаптировать свои продукты к новым правилам, например, создавать совместные разработки с российскими производителями, переносить «производство» в Россию. Так поступила компания Eset, которая начала совместную работу с российской компанией «Код безопасности», чтобы выпускать свою продукцию в пределах РФ.

Источник: https://Zakupki.Kontur.ru/site/articles/1098-importozameschenie-po

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

1. Введение 1.1. Наименование программы 1.2. Назначение и область примененияпрограммы2. Требования к программе 2.1. Требования к функциональным характеристикампрограммы2.2. Требования к надежностипрограммы2.2.1. Требования к обеспечению надежного функционирования программы 2.2.2.

Время восстановления программы после отказа 2.2.3. Отказы программы из-за некоректных действий оператора 3. Условия эксплуатации программы3.1. Климатические условия эксплуатации программы 3.2. Требования к квалификации и численности персонала 3.3. Требования к составу и параметрам технических средств 3.4.

Требования к информационной совместимости 3.4.1. Требования к информационным структурам и методам решения 3.4.2. Требования к исходным кодам и языкам программирования 3.4.3. Требования к программным средствам, используемым программой 3.4.4. Требования к защите информации и программ 3.5. Специальные требования

4.

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

4.1. Предварительный состав программной документации 5. Технико-экономические показатели 5.1. Экономические преимущества разработкипрограммы6. Стадии и этапы разработкипрограммы6.1. Стадии разработкипрограммы6.2. Этапы разработкипрограммы6.3. работ по этапам 7. Порядок контроля и приемки 7.1. Виды испытаний

7.2. Общие требования к приемке работы

1. Введение

Наименование программы: «Тестовая программа»

1.2. Назначение и область применения

Программа предназначена для…

2. Требования к программе

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

2.2.1 Требования к обеспечению надежного функционирования программы

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

б) использованием лицензионного программного обеспечения;

в) регулярным выполнением рекомендаций Министерства труда исоциального развития РФ, изложенных в Постановлении от 23 июля 1998 г.

Об утверждении межотраслевых типовых норм времени на работы посервисному обслуживанию ПЭВМ и оргтехники и сопровождению программныхсредств»;

г) регулярным выполнением требований ГОСТ 51188-98.

Защитаинформации. Испытания программных средств на наличие компьютерныхвирусов

2.2.2. Время восстановления после отказа

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

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

2.2.3. Отказы из-за некоректных действий оператора

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

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

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

3.2. Требования к квалификации и численности персонала

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

Системный администратор должен иметь высшее профильноеобразование и сертификаты компании-производителя операционной системы.

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

г) задача создания резервных копий базы данных.

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

3.3.1. В состав технических средств должен входить IВМ-совместимыйперсональный компьютер (ПЭВМ), выполняющий роль сервера, включающий всебя: 3.3.1.1. процессор Pentium-2.0Hz, не менее; 3.3.1.2.

оперативную память объемом, 1Гигабайт, не менее; 3.3.1.3. оперативную память объемом, 1Гигабайт, не менее; 3.3.1.4. операционную систему Windows 2000 Server или Windows 2003; 3.3.1.5.

операционную систему Windows 2000 Server или Windows 2003;

3.3.1.6. Microsoft SQL Server 2000

3.4.1. Требования к информационным структурам и методам решения

База данных работает под управлением Microsoft SQL Server.Используется много поточный доступ к базе данных. Необходимо обеспечитьодновременную работу с программой с той же базой данной модулейэкспорта внешних данных.

3.4.2. Требования к исходным кодам и языкам программирования

Дополнительные требования не предъявляются

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

Системные программные средства, используемые программой, должны бытьпредставлены лицензионной локализованной версией операционной системыWindows 2000 Server или Windows 2003 и Microsoft SQL Server 2000

3.4.4. Требования к защите информации и программ

Требования к защите информации и программ не предъявляются

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

Специальные требования к данной программе не предьявляются

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

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

4.1.3. руководство оператора;

5. Технико-экономические показатели

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

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

Разработка должна быть проведена в три стадии: 1. разработка технического задания; 2. рабочее проектирование;

3. внедрение.

6.2. Этапы разработки

На стадии разработки технического задания должен быть выполнен этапразработки, согласования и утверждения настоящего технического задания. На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ: 1. разработка программы; 2. разработка программной документации; 3. испытания программы.

На стадии внедрения должен быть выполнен этап разработки подготовка и передача программы

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы: 1. постановка задачи; 2. определение и уточнение требований к техническим средствам; 3. определение требований к программе; 4.

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

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

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

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

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

Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний

7.2. Общие требования к приемке работы

На основании Протокола проведения испытаний Исполнитель совместно сЗаказчиком подписывает Акт приемки-сдачи программы в эксплуатацию.

МИНИСТЕРСТВО НАУКИ И ОБРАЗОВАНИЯ

РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОУ ВПО «АДЫГЕЙСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

ФИЗИЧЕСКИЙ ФАКУЛЬТЕТ

КАФЕДРА АСОИУ

ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ ПРОГРАММНОГО

ПРОДУКТА

ВВЕДЕНИЕ…………………………………………….…………………………. … 3

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

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

1.2. Организация, утвердившая основание разработки, и дата его утверждения4

1.3. Наименование темы разработки…………….………………………………….4

2. НАЗНАЧЕНИЕ РАЗРАБОТКИ……………….…………………………………..5

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

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

3. ТРЕБОВАНИЯ К ПРОГРАММЕ…………………………….……………………6

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

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

3.1.2 Организация входных и выходных данных…………………….…………….6

3.1.3 Временные характеристики и размер занимаемой памяти……..……………6

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

3.2.1 Требования к надежному функционированию……………………….………6

3.2.2 Контроль входной и выходной информации……………………………..…..7

3.2.3 Время восстановления после отказа……………………………………….….7

3.3 Условия эксплуатации……………………………………………………………7

3.4 Требования к составу и параметрам технических средств……………………7

3.5 Требования к языкам программирования……………………………………….8

3.6 Требования к программным средствам, используемым программой…………8

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

4. ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ………………………… ….. 9

5. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ………………………………………………9

6. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ……………………………………………9

6.1 Виды испытаний…………………………………………………………………..9

6.2 Общие требования к приёмке…………………………………………………..10

7. ЭТАПЫ ВНЕДРЕНИЯ……………………………………………………………10

ВВЕДЕНИЕ

Полное наименование программной разработки: «Программа К», в дальнейшем именуемая как «программа». Краткое название программы – «ПК».

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

Разрабатываемая программа применяется на любом предприятии, где имеется рабочий персонал.

Разработчик данного программного продукта — студент группы 4А1 Иванов А.В. в дальнейшем именуемый как «разработчик «.

Заказчик программного продукта – ОАО «РТС», в лице директора А.М. Гутенко.

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

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

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

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

Задание утверждено и выдано начальником технического отдела ОАО «РТС» Козаковым А.В.

Козаков А.В.

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

Наименование темы разработки – «Учёт рабочего времени».

2 НАЗНАЧЕНИЕ РАЗРАБОТКИ

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

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

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

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

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

Технология создания программы в визуальных средах программирования делает ее интерфейс универсальным и совместимым с операционными системами Windows 95/98/2000/XP.

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

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

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

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

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

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

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

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

Кому поручить написание ТЗ на программу

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

Источник: https://telebrands24.ru/provoloka/sample-specifications-for-the-development-of-the-program-write-a-technical-assignment/

Рекомендации по подготовке технического задания на проектирование медицинских учреждений

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

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

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

Три этапа разработки медико-технического задания

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

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

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

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

3. Непосредственно разработка медико-технического задания на проектирование поликлиники, больницы или другого ЛПУ.

Разработка техзадания на проектирование ЛПУ всегда включает зонирование территорий с учетом противопожарных требований

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

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

Общие сведения:

1. Месторасположение объекта (почтовый адрес, телефон, e-mail, если есть).
2. Основание для проектирования, например, решение государственного органа о строительстве.
3. Данные о заказчике.
4. Источник финансирования.

5. Вид строительства (новое, реконструкция или капитальный ремонт).
6. Стадийность проектирования.
7. Очередь строительства.
8. Сведения о земельном участке.
9. Назначение объекта, его структура, пропускная способность.

10. Сроки выполнения работ и др.

В перечне основных требований освещают:

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

  ;

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

Медико-техническое задание на проектирование больницы включает расчет инженерных коммуникаций

В «дополнительных требованиях» прописывают договорные обязательства сторон, например:

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

Как правильно формулировать требования к помещениям

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

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

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

Существуют ли типовые медико-технические задания?

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

В зависимости от вида работ (новое строительство, капитальный ремонт или реконструкция), структура документа меняется. Для функционирующих объектов акцент ставится на перепланировку с целью перепрофилирования помещения, для новых – на необходимость разрабатывать инженерные коммуникации «с нуля». Это значит, что структура техзадания на проектирование ЛПУ будет разной.

Может ли заказчик вносить корректировки в готовый документ?

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

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

В случае с частным заказчиком нюансы проговариваются заранее.

Задача проектировщика – не «угодить» заказчику, а составить такую проектно-сметную документацию, которая пройдет проверку в органах госэкспертизы на соответствие действующему законодательству. Если все сделано грамотно, результатом станет положительное заключение с первого захода.

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

Выводы

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

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

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

Источник: http://osnova-pro.ru/stati/rekomendatsii-po-podgotovke-tekhnicheskogo-zadaniya-na-proektirovanie-meditsinskikh-uchrezhdeniy/