Порядок производства работ

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

Взаимодействие между Заказчиком и  Разработчиком ведется по

e-mail:_______________, телефону:____________________________

Разработчик обязан предоставить календарный план график выполнения работ по ТЗ до ______________________________.

Раз в неделю (по пятницам) Разработчик присылает по e-mail отчет о проделанной работе.

Плановые сроки начала и окончания работ

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

5. Порядок контроля и приемки системы

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

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

 

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

В данном разделе следует: Указать последовательность сдачи-приемки работ Определить этапы работ Указать каким образом продукт передается Указать как продукт вводится в эксплуатацию.

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

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

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

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

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

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

Сроки и порядок комплектования штатов и обучения персонала

5. Требования к документированию

В данном разделе следует: Указать последовательность сдачи-приемки работ Определить этапы работ Указать каким образом продукт передается Указать как продукт вводится в эксплуатацию.

Рекомендации по ГОСТ Что с этим делать на практике Согласованный разработчиком и Заказчиком системы перечень подлежащих   разработке комплектов и видов документов Наличие   полноценной документации – важная часть результата. Все мы знаем, что   документирование чего-либо трудоемкий труд. Поэтому, необходимо заранее   оговорить с Заказчиком, какие виды документации будут разрабатываться, как   они будут выглядеть (содержание и желательно примеры).

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

Игнорирование   требований к документации очень часто приводит к самым неожиданным   последствиям на проектах. Например, все сделано и все работает. Пользователи   тоже умеют работать. Про документацию вообще не договаривались и не   разговаривали. И вдруг при сдаче работ кто-то из топ-менеджеров Заказчика,   который даже не участвовал в проекте, но участвует в приемке работ, Вас   спрашивает: «А где руководства пользователя?» И начинает Вас убеждать, что о   наличии руководств пользователя договариваться было и не нужно, это «само   собой» якобы подразумевается. И все, не хочет принимать у Вас работу. За чей   счет будете разрабатывать руководства?    На этот крючок попадали уже многие команды.

 

5. Источники разработки

В данном разделе следует: Указать документы и информационные материалы

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

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