Пояснительная записка по гост 34. Пояснительная записка

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

Что такое стандарты на документацию?

В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию:

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

Это базовый документ, в котором приводится полный перечень документации ГОСТ 34, рекомендации по кодированию документов, к каким стадиям проекта относятся документы (стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.

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

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

К стандарту РД 50-34.698-90 существует множество вопросов и трактовок его положений, которые ввиду их неконкретности, часто понимают по-разному заказчик и исполнитель или даже члены проектной команды. Но ничего более конкретного у нас, к сожалению, нет.

Рассмотрим теперь плюсы и минусы стандартов, начав традиционно с минусов.

Минусы стандартов

Основной минус всем очевиден - стандарты старые. В них заложено устаревшее представление об архитектуре автоматизированной системы. Например:

приложения двухуровневые, состоящие из клиентской программы и сервера СУБД (никаких трех- и более «уровневых» приложений, никаких Weblogic или JBoss)
структура таблиц базы данных, будучи описана, даст представление о логической модели данных (то, что между приложением и базой может находиться какой-нибудь Hibernate, тогда казалось нехорошим излишеством)
пользовательский интерфейс однооконный (а разве бывает другой? А что такое «браузер»?)
Отчетов в системе немного, все они бумажные и печатаются на матричном принтере
Разрабатываемая программа ориентирована на решение «задачи обработки информации», которая имеет четкий вход и выход и узко специализирована. В основе обработки информации лежит «алгоритм». Иногда «алгоритмов» бывает несколько. (Объектно-ориентированное программирование тогда делало лишь свои первые шаги и серьезно не рассматривалось).
администратор базы данных понимает, какая информация лежит в таблицах и активно участвует в редактировании системных справочников (а разве бывает один сервер СУБД для 50 разных приложений?)

Соответственно, в стандарте есть артефакты, наподобие следующего:

5.8. Чертеж формы документа (видеокадра)
В документе должно быть приведено изображение формы документа или видеокадра в соответствии с требованиями государственных стандартов унифицированной системы документации Р 50-77 и необходимые пояснения.

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

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

Сейчас уже нам ничего не говорят слова «машинограмма», «видеокадр», «АЦПУ». Я тоже их не застал в употреблении, хотя заканчивал профильный институт в 90-е. Это было время появления Windows 3.1, VGA дисплеев, трехдюймовых дискет и первых отечественных интернет-сайтов. Но в стандарте эти слова есть, и заказчик иногда капризно требует предоставить ему полный комплект документации в соответствии с ГОСТ 34.201-89. Более того, подобные формулировки в ТЗ кочуют из одного министерства в другое и стали уже неким негласным шаблоном, в который вбивают содержательную часть.

Так что документ с дурацким названием «Чертеж формы документа (видеокадра)» в проекте должен быть и должен быть не пустым.

Что в стандарте хорошо

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

А стандарты ГОСТ 34 хороши еще и тем, что они составлялись умными людьми, обкатывались годами и у них есть четкая цель - максимально полно описать на бумаге сложную абстрактную сущность, которую представляет собой любая АСУ.

Когда вам требуется грамотно поставить задачу западным подрядчикам, которые про наши ГОСТы слыхом не слыхивали, можно также опираться на эти стандарты, а точнее на их контент, смысловую составляющую. Потому что, повторюсь, гарантия полноты информации дорогого стоит. Как бы мы себя не тешили высоким уровнем своего профессионализма, мы можем забыть включить в состав наших требований элементарные вещи, тогда как тот же ГОСТ 34.602-89 «помнит» обо всем. Если вам непонятно, как должен выглядеть результат работы западных подрядчиков, посмотрите на требования к документированию, к рекомендуемым разделам. Уверяю вас, лучше не придумать! Скорее всего, есть западные аналоги наших стандартов, в которых все может быть полнее, современнее и лучше. К сожалению, я с ними не знаком, так как не было пока ни одного случая, чтобы наших ГОСТов было бы недостаточно.

Можно смеяться над тем, что создатели стандартов ничего не знали о java или.NET, о HD мониторах и Интернете, но я бы не советовал недооценивать масштаб проделанной ими работы и ее ценность для нашего профессионального сообщества.

Как читать и понимать стандарты документации по ГОСТ серии 34

Стандарт делит все документы по двум осям - время и предметная область. Если посмотреть таблицу 2 в ГОСТ 34.201-89, то хорошо видно это деление (колонки «Стадия создания» и «Часть проекта»

Стадии создания АСУ

Стадии создания определены в ГОСТ 34.601-90. Имеют отношение к документированию из них три:

Эскизный проект (ЭП)
Технический проект (ТП)
Разработка рабочей документации (РД)

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

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

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

Части (разделы) проектной документации по созданию АСУ

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

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

Для того, чтобы полностью описать этот «автомат», сделаны следующие разрезы (как в черчении):

Математическое обеспечение (МО) , отвечающее на вопросы: какая логика зашита внутри «черного ящика»? Почему выбраны именно эти алгоритмы, именно такие формулы и именно такие коэффициенты?

Математическое обеспечение ничего не знает ни о процессорах, ни о базах данных. Это отдельная абстрактная область, обитель «сферических коней в вакууме». Но математическое обеспечение бывает очень плотно связано с предметной областью, aka Реальная жизнь. Например, управляющие алгоритмы для систем управления дорожным движением требуется согласовать в ГИБДД перед тем, как их будет согласовывать заказчик. И тут понимаешь, зачем их выделяют в отдельную книжицу. Потому что в ГИБДД никому не интересно, на какой ОС будет работать сервер приложения, а вот какой знак и ограничение скорости выскочит на табло в дождь или в снег очень даже интересно. Они отвечают за свою часть, и ничего другого подписывать не собираются. С другой стороны, когда они подписали, не будет вопросов к технической стороне вопроса - почему выбрали те, а не другие табло или светофоры. Мудрость «предков» как раз и проявляется в таких вот практических кейсах.

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

Или вот «Ведомость машинных носителей информации». Понятно, что раньше в нем были номера магнитных барабанов или бобин с пленкой. А сейчас что туда вносить?

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

Программное обеспечение (ПО) . Любимая всеми часть проектной документации. Да хотя бы потому, что это всего один документ! И потом, всем понятно, что туда нужно записывать. Но я, все-же, повторю.

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

Техническое обеспечение (ТО) . Не менее любимая всеми часть проектной документации. Радужную картину омрачает только обилие документов, которые требуется разрабатывать. Всего по стандарту требуется разработать 22 документа, из них 9 на стадии ТП.

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

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

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

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

На стадии РД появляются другие, более интересные документы, которые мне бы хотелось рассмотреть отдельно.

Руководство пользователя . Комментарии излишни, я думаю.

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

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

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

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

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

Описание технологического процесса обработки данных (включая телеобработку) . Жалкий рудимент пещерного века, когда были специально выделенные «Операторы ЭВМ», скармливающие машине перфокарты и упаковывающие распечатку результата в конвертик. Эта инструкция - для них. Что в нее писать в XXI веке - я вам точно сказать не могу. Выкручивайтесь сами. Самое лучшее, это просто забыть про этот документ.

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

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

Варианты использования ГОСТ 34

Полное и точное следование стандарту . Добровольно никто, естественно, такую тучу документов писать не будет. Поэтому полный комплект документов готовится только по настоятельной просьбе заказчика, которую он закрепил в ТЗ и еще договором сверху придавил. В таком случае требуется понимать все буквально и отдать заказчику физические «книжки», на которых будут стоять названия документов из таблицы 2 ГОСТ 34.201-89 за исключением совсем уж ненужных, перечень которых вы обязательно должны обговорить и закрепить письменно. Содержание документов также должно без всякой фантазии соответствовать РД 50-34.698-90, вплоть до названия разделов. Для того, чтобы у заказчика взорвался мозг, иногда большую систему делят на подсистемы, и для каждой подсистемы выпускают отдельную проектную документацию. Выглядит это устрашающе и нормальному контролю при помощи земного разума не подлежит. Особенно в части интеграции подсистем. Что значительно упрощает приемку. Главное, чтобы вы сами при этом не запутались и чтобы ваша система все-таки заработала как надо.
Мы просто любим ГОСТы . В серьезных больших компаниях любят стандарты. Потому, что они помогают людям лучше понимать друг друга. Если ваш заказчик замечен в любви к порядку и стандартизации, постарайтесь придерживаться стандартной идеологии ГОСТ при разработке документов, даже если этого не требует ТЗ. Вас лучше поймут и одобрят согласующие специалисты, а вы сами не забудете включить в документацию важную информацию, лучше будете видеть целевую структуру документов, точнее планировать работы по их написанию и сэкономите себе и коллегам массу нервов и денег.
Нам плевать на документацию, лишь бы все работало . Исчезающий вид безответственного заказчика. Подобный взгляд на документацию пока еще можно встретить у небольших и бедных заказчиков, а также в оставшихся со времен перестройки авторитарных «идиотократиях», где босс окружен верными друзьями - директорами, и все вопросы решаются в личных беседах. Вы вольны в подобных условиях забивать на документирование вообще, но лучше, все таки, прицел не сбивать и хотя бы схематично наполнять содержимым документацию. Если не этому заказчику, так следующему передадите (продадите).

Заключение

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

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

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

Пояснительная записка является одним из важнейших документов технического проекта. Технический проект разрабатывают с целью выявления окончательных технических решений, дающих полное представление о конструкции изделия.
При разработке программы для создания пояснительной записки рекомендуется использовать ГОСТ 19.404-79 «Пояснительная записка. Требования к содержанию и оформлению» .

Для создания пояснительной записки к техническому проекту, описывающему автоматизированную систему (АС) рекомендуется использовать стандарт РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов» .

Многие разделы, приведенных документов, перекликаются, поэтому мы для примера рассмотрим документ Пояснительная записка, созданный на основании РД 50-34.698-90

1 Общие положения

1.1 Наименование проектируемой АС

Данный раздел документа Пояснительная записка содержит полное и краткое наименование АС.

Например: «В данном документе создаваемая система называется Корпоративный Информационный Портал. Также допускается использование сокращенного наименования КИП или Система ».

1.2 Документы, на основании которых ведется проектирование системы

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

1.3 Организации, участвующих в разработке системы

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

1.4 Цели разработки АС

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

Например: «Целью, создаваемой системы является:

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

1.5 Назначение и область использования разрабатываемой АС

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

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

Создание конференций для обсуждения вопросов;
Отправка/Получение электронных почтовых сообщений;
Обеспечение совместной работы над документами;
Согласование документов;
Ведение учета входящей и исходящей документации.»

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

В данном разделе следует указать стандарты, которые использовались при создании документа Пояснительная записка.

Например: «При проектировании использовались следующие нормативно-технические документы:

ГОСТ 34.201-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании автоматизированных систем»;
ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»;
ГОСТ 34.003-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»;
ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»;
РД 50-682-89 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Общие положения»;
РД 50-680-88 «Методические указания. Автоматизированные системы. Основные положения»;
РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов».»

1.7. Очередность создания системы

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

Например: «Реализация проекта Корпоративного информационного Портала планируется в две очереди.

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

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

2 Описание процесса деятельности

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

Для иллюстрации материала в пояснительной записке допускается использовать нотации UML , ARIS или IDF0, а также схематичные изображения, созданные при помощи стандартных приложений (Visio).

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

Например: «1. Пользователь формирует документ

Пользователь инициирует процесс передачи документа на согласование
Система изменяет статус документа на «на согласовании». »
Основные технические решения

2.1. Решения по структуре системы и подсистем.

В данном разделе документа Пояснительная записка приводятся решения по функциональной структуре системы и ее подсистем.

2.2. Средства и способы взаимодействия между компонентами системы. Взаимосвязь с внешними системами

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

Например: «В рамках взаимодействия КИП с внешними системами используются следующие технологии:
- «Бухгалтерия предприятия» - файловый обмен в установленном XML / Excel формате.»

2.3. Решения по режимам функционирования

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

2.4. Решения по численности, квалификации и функциям персонала АС

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

Например: «Администратор портала ответственный за:

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

2.5. Обеспечение заданных в техническом задании потребительских характеристик системы

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

Например: «Отказоустойчивость и работоспособность программных модулей КИП обеспечивается за счет применения промышленных программных платформ IBM WebSphere Portal, Enterprise Oracle 10g.»

2.6. Состав функций и комплекс задач, реализуемых системой

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

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

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

Требования к комплексу технических средств в пояснительной записке рекомендуется размещать в виде таблицы.
Например: «

Оборудование	Техническая характеристика
Сервер Базы данных
Исполнение для монтажа в стойку	Не более 4U
Архитектура процессоров	RISC (64-разрядная)
Частота процессора	не менее 1,5 ГГц
Кэш процессора	Не менее 1Мб
Операционные системы	Windows 2003 SP2
Возможное число устанавливаемых процессоров	Не менее 4
Число установленных процессоров
Объем возможной оперативной памяти	32 ГБ с ЕСС
Объем оперативной памяти	Минимум 8 ГБ
Наличие интерфейсов	10/100/1000 Base-T Ethernet интерфейсы 2 шт.; Ultra320 SCSI 2 шт.; USB 4 шт.; последовательный интерфейс 1 шт.; слоты расширения PCI 64-bit 6 шт.
Видео карта:	Не менее 8Мб.
Возможное число устанавливаемых жестких дисков	Не менее 4
Число установленных дисков
Устройство для считывания
Электрическое питание	Входные параметры: 200-240 В, частота тока: 50-60 Гц; максимальная входная мощность не более 1600 Вт; не менее 2х блоков питания обеспечивающих отказоустойчивость.

При описании размещения объектов комплекса технических средств в пояснительной записке необходимо руководствоваться требованиями СНиП 11-2-80 для зданий категории "В".

2.8. Объем, состав, способы организации, последовательность обработки информации

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

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

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

Например: «Входной информацией для подсистемы электронного документооборота является:

электронные версии документов производственного документооборота;
электронная цифровая подпись;

Выходной информацией для подсистемы электронного документооборота является:

журнал истории жизненного цикла документа;
журнал истории согласования документа;
файл электронной версии документа в формате RTF. »

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

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

Например:
«

Сервер базы данных: Oracle 10g
Портал: Websphere Portal Extend v6.0.
Бизнес-моделирование: ARIS

3 Мероприятия по подготовке объекта автоматизации к вводу системы в действие

В данном разделе документа Пояснительная записка описываются следующие мероприятия:

мероприятия по приведению информации к виду, пригодному для обработки на ЭВМ;
мероприятия по обучению и проверке квалификации персонала;
мероприятия по созданию необходимых подразделений и рабочих мест;
мероприятия по изменению объекта автоматизации;
другие мероприятия, исходящие из специфических особенностей создаваемых АС

Постановлением Государственного комитета стандартов Совета Министров СССР от 28 февраля 1973 г. № 502 срок введения установлен

с 01.01.74

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

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Технический проект разрабатывают, если это предусмотрено техническим заданием, протоколом рассмотрения технического предложения или эскизного проекта.Технический проект разрабатывают с целью выявления окончательных технических решений, дающих полное представление о конструкции изделия, когда это целесообразно сделать до разработки рабочей документации.При необходимости технический проект может предусматривать разработку вариантов отдельных составных частей изделия.В этих случаях выбор оптимального варианта осуществляется на основании результатов испытаний опытных образцов изделия.1.2. При разработке технического проекта выполняют работы, необходимые для обеспечения предъявляемых к изделию требований и позволяющие получить полное представление о конструкции разрабатываемого изделия, оценить его соответствие требованиям технического задания, технологичность, степень сложности изготовления, способы упаковки, возможности транспортирования и монтажа на месте применения, удобство эксплуатации, целесообразность и возможность ремонта и т.п.Перечень необходимых работ определяется разработчиком в зависимости от характера и назначения изделия и согласовывается с заказчиком, если изделие разрабатывается по заказам Министерства обороны.Примерный перечень работ для изделий народно-хозяйственного назначения приведен в приложении. Примечание. На стадии технического проекта не повторяют работы, проведенные на предыдущих стадиях, если они не могут дать дополнительных данных. В этом случае результаты ранее проделанных работ отражают в пояснительной записке.(Измененная редакция, Изм. № 4).1.3. Материальные макеты должны быть предназначены для проверки (в необходимых случаях – на объекте заказчика или потребителя) конструктивных и схемных решений разрабатываемого изделия и (или) его составных частей, а также для подтверждения окончательно принятых решений. Испытания макетов должны проводиться в соответствии с программой и методикой испытаний, разработанной по ГОСТ 2.106-96. Необходимость изготовления макетов и их количество устанавливаются организацией-разработчиком (если требуется, то совместно с заказчиком).(Измененная редакция, Изм. № 5).1.4. В технический проект включают конструкторские документы в соответствии с ГОСТ 2.102-68, предусмотренные техническим заданием и протоколом рассмотрения технического предложения, эскизного проекта. При выполнении документов в электронной форме электронная структура изделия и электронная модель изделия (сборочной единицы, комплекса) выполняются со степенью детализации, соответствующей стадии технического проекта.При разработке технического проекта могут быть использованы отдельные документы, разработанные на предыдущих стадиях, если эти документы соответствуют требованиям, предъявляемым к документам технического проекта или, если в них внесены изменения с целью обеспечения такого соответствия. Использованным документам присваивают литеру «Т».Конструкторские документы, разрабатываемые для изготовления материальных макетов, в комплект документов технического проекта не включают.(Измененная редакция, Изм. № 5).1.5. На рассмотрение, согласование и утверждение представляют копии документов технического проекта, скомплектованные по ГОСТ 2.106-96. Допускается по согласованию с заказчиком представлять подлинники документов технического проекта. 1.6. Форма представления документов технического проекта (бумажная или электронная), если она не указана в техническом задании или протоколах рассмотрения технического предложения или эскизного проекта, определяется разработчиком по согласованию с заказчиком. Допускается включать в комплект документов технического проекта документы в различных формах представления.(Введен дополнительно, Изм. № 5).

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

2.1. Чертеж общего вида или эквивалентная ему электронная модель сборочной единицы для технического проекта выполняют по ГОСТ 2.119-73. Кроме того, на чертеже общего вида (или эквивалентной ему электронной модели сборочной единицы) при необходимости приводят:указания о выбранных посадках деталей (наносятся размеры и предельные отклонения сопрягаемых поверхностей по ГОСТ 2.307-68);технические требования к изделию, например, о применении определенных покрытий, способов пропитки обмоток, методов сварки, обеспечивающих необходимое качество изделия (эти требования должны учитываться при последующей разработке рабочей документации);технические характеристики изделия, которые необходимы для последующей разработки чертежей или эквивалентных электронных моделей.(Измененная редакция, Изм. № 5).2.2. В ведомость технического проекта записывают все включенные в технический проект конструкторские документы в порядке, установленном ГОСТ 2.106-96. Допускается включать в комплект документов технического проекта документы в различных формах представления (в бумажной или электронной форме), при этом в графе «Примечание» рекомендуется указывать форму представления документа.(Измененная редакция, Изм. № 5).2.3. Пояснительную записку технического проекта выполняют по ГОСТ 2.106-96 с учетом следующих основных требований к содержанию разделов:а) в разделе «Введение» указывают наименование, номер и дату утверждения технического задания. Если разработка технического проекта предусмотрена не техническим заданием, а протоколом рассмотрения технического предложения или эскизного проекта, то делают запись по типу: «Разработка технического проекта предусмотрена эскизным проектом …» и указывают номер и дату протокола рассмотрения эскизного проекта;б) в разделе «Назначение и область применения разрабатываемого изделия» указывают:краткую характеристику области и условий применения изделия;общую характеристику объекта, для применения в котором предназначено данное изделие (при необходимости);основные данные, которые должны обеспечивать стабильность показателей качества изделия в условиях эксплуатации;в) в разделе «Техническая характеристика» приводят:основные технические характеристики изделия (мощность, число оборотов, производительность, расход электроэнергии, топлива, коэффициент полезного действия и другие параметры, характеризующие изделие);сведения о соответствии или отклонениях от требований, установленных техническим заданием и предыдущими стадиями разработки, если они проводились, с обоснованием отклонений;г) в разделе «Описание и обоснование выбранной конструкции» приводят:описание и обоснование выбранной конструкции, схем, упаковки (если упаковка предусмотрена) и других технических решений, принятых и проверенных на стадии разработки технического проекта. При необходимости приводят иллюстрации;данные сравнения основных технических характеристик изделия с характеристиками аналогов (отечественных или зарубежных) или дают ссылку на карту технического уровня и качества;оценку технологичности изделия, в том числе обоснование необходимости разработки или приобретения нового оборудования;оценку окончательных технических решений на соответствие требованиям по обеспечению патентной чистоты и конкурентоспособности;сведения об использованных изобретениях (номера авторских свидетельств или номера заявок на изобретения с указанием даты приоритета);результаты испытаний материальных макетов (если они изготовлялись), электронных макетов (если они разрабатывались), и данные оценки соответствия макетов заданным требованиям, в том числе эргономики, технической эстетики. При необходимости приводят фотографии материальных макетов. Для справок допускается указывать обозначения основных конструкторских документов, по которым изготовлялись материальные макеты, номер и дату отчета (или) протокола по испытаниям и др.;сведения о соответствии применяемых в изделии заимствованных (ранее разработанных) составных частей, покупных изделий и материалов разрабатываемому изделию по техническим характеристикам, режимам работы, гарантийным срокам, условиям эксплуатации;обоснование необходимости применения дефицитных изделий и материалов;сведения о транспортировании и хранении;сведения о соответствии изделия требованиям техники безопасности и производственной санитарии;д) в разделе «Расчеты, подтверждающие работоспособность и надежность конструкции» приводят:расчеты, подтверждающие работоспособность изделия (кинематические, электрические, тепловые, расчеты гидравлических и пневматических систем и др.);расчеты, подтверждающие надежность изделия (расчеты показателей долговечности, ремонтопригодности, сохраняемости и др.); Для каждого вида расчетов указываются средства программного и информационного обеспечения автоматизированных систем (в случае их применения для выполнения расчетов); сведения о безопасности изделия и воздействии его на окружающую среду; сведения по утилизации изделия»;При большом объеме расчетов они могут быть оформлены в виде отдельных документов; при этом в данном разделе приводят только результаты расчетов;е) в разделе «Описание организации работ с применением разрабатываемого изделия» приводят сведения об организации работ с изделием на месте эксплуатации, в том числе:описание специфических приемов и способов работы с изделием в режимах и условиях, предусмотренных техническим заданием;описание порядка и способов транспортирования, монтажа и хранения изделия и ввода его в действие на месте эксплуатации; оценку эксплуатационных данных изделия (взаимозаменяемости, удобства обслуживания, ремонтопригодности, устойчивости против воздействия внешней среды и возможности быстрого устранения отказов) ;сведения о квалификации и количестве обслуживающего персонала;ж) в разделе «Ожидаемые технико-экономические показатели» приводят: экономические показатели, необходимые расчеты;ориентировочный расчет цены опытного и серийного изделия и затрат на организацию производства и эксплуатацию; з) в разделе «Уровень стандартизации и унификации» приводят:сведения о стандартных, унифицированных и заимствованных сборочных единицах и деталях, которые были применены при разработке изделия, а также показатели уровня унификации и стандартизации конструкции изделия;обоснование возможности разработки государственных и отраслевых стандартов на объекты стандартизации, связанные с разработкой данного изделия, его составных частей и новых материалов.(Измененная редакция, Изм. № 1, 5) .2.4. В приложении к пояснительной записке приводят:копию технического задания, а также, при необходимости, данные (технические требования, правила приемки, методы контроля и другие сведения), подлежащие включению в технические условия, если последние на данной стадии не разрабатывались;материалы художественно-конструкторской проработки, не являющиеся конструкторскими документами;перечень работ, которые следует провести на стадии разработки рабочей документа ции;уточнение или разработку сетевого графика по дальнейшей разработке и внедрению в промышленное производство разрабатываемого изделия; перечень ис пользованной литературы и т.п.;перечень документов, используемых при разработке технического проекта и получаемых разработчиком изделия от других пр едприятий и организаций (авторские свидетельства, экс пертное заключение о патентной чистот е, справка потребителя о необходимом объеме производства разрабатываемых изд елий и т.п.) ; при этом документы в приложении к пояснительной записке не включают, но в пояснительной записке могут быть приведены н еобходимые сведения из этих документов (например, предмет изобретения потребные количества изделий на квартал, на год, на пятилетку), а также ном ер и дата документа или сопроводит ельного письма; перечень средств программного и информационного обеспечения автоматизированных систем, использованных при разработке технического проекта.(Измененная редакция, Изм. № 5).

ПРИЛОЖЕНИЕ

ПЕР ЕЧЕ НЬ РАБОТ, ВЫПОЛНЯЕМЫХ ПРИ РАЗРАБОТКЕ ТЕХНИЧЕСКОГО ПРОЕКТА

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

Пояснительная записка к техническому проекту.

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

- ос семейства Windows;
- 1С: Предприятие 8;

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

В системе реализованы три основные задачи:

- ведение справочников;
- ведение складов;
- регистрация продаж;
- вывод отчетов.

Приложение БД для ИС разрабатывается с помощью программной среды 1С: Предприятие 8. Для размещения системы используются персональные компьютеры, имеющиеся у ИП, для которого разрабатывается система.

Схема функциональной структуры

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

Таблица -2 Главный раздел сценария выполнения ВИ «Добавить данные справочников»

	Редактировать данные справочников
	Кладовщик, ИП
	Поддержание в актуальном состоянии сведений об объектах предметной области
Краткое описание	Пользователь добавляет новый элемент справочника и записывает его. Система сохраняет измененные данные в БД
Предусловие	1. Пользователь авторизован в системе. 2. У пользователя есть права на добавление данных в справочник
Постусловие	1. Элемент справочника записан в БД. 2. Элемент справочника отображен в форме списка справочника

Таблица -3 Типичный ход событий сценария выполнения ВИ «Добавить данные справочников»

Таблица -4 Исключения сценария выполнения ВИ «Добавить данные справочников»

Таблица -5 Главный раздел сценария выполнения ВИ «Установить цены номенклатуры»

Таблица - 6 Типичный ход событий сценария выполнения ВИ «Установить цены номенклатуры»

Таблица -7 Исключения сценария выполнения ВИ «Установить цены номенклатуры»

Таблица -8 Главный раздел сценария выполнения ВИ «Зарегистрировать поступление товаров»

Таблица -9 Типичный ход событий сценария выполнения ВИ «Зарегистрировать поступление товаров»

Действия актеров	Отклик системы

1. Кладовщик выполняет команду создания нового документа «Поступление товаров»	2. Система отображает форму документа
3. Кладовщик заполняет реквизиты шапки Исключение №1: Кладовщик вручную заполняет поле Номер
4. Кладовщик добавляет новую строку табличной части на странице Товары	5. Система отображает новую строку
6. Кладовщик заполняет колонку Номенклатура	7. Система подставляет значение колонок
8. Кладовщик заполняет колонку Количество	9. Система рассчитывает значение колонок Сумма,
10. Система отображает в подвале табличной части итоговые значения колонок Всего
11. Кладовщик вводит новый товар (возврат к пункту 4) или выполняет команду Записать Исключение №2: Значение поля Номер не уникально	12. Система записывает новый документ «Поступление товаров» в БД
13. Кладовщик выполняет команду Печать -	14. Система отображает заполненную печатную форму приходного ордера
15. Кладовщик выполняет команду Печать	16. Система выводит на печать приходный ордер
17. Кладовщик выполняет команду Закрыть печатной формы	18. Система закрывает печатную форму
19. Кладовщик выполняет команду Закрыть документа «Поступление товаров»	20. Система закрывает форму документа «Поступление товаров»

Таблица -10 Исключения сценария выполнения ВИ «Зарегистрировать поступление товаров»

Значения колонок сумма и всего рассчитываются по формуле:

Сумма = Количество * Цена

Таблица -11 раздел сценария выполнения ВИ «Совершение продаж»

Таблица -12 Типичный ход событий сценария выполнения ВИ «Совершение продаж»

Действия актеров	Отклик системы

Оплата одного документа «продаж»
1. Менеджер выполняет команду создания нового документа продаж	2. Система отображает форму документов «продаж»

4. Менеджер проводит документ
5. система проводит документ



9. Система выводит на печать

Таблица - 13 Исключения сценария выполнения ВИ «Зарегистрировать документ»

Таблица -14 раздел сценария выполнения ВИ «Резервирование»

Таблица -15 Типичный ход событий сценария выполнения ВИ «Совершение продаж»

Действия актеров	Отклик системы

Резервирование товара
1. Менеджер выполняет команду создания нового документа резервирования	2. Система отображает форму документов «резервирования»
3. Менеджер вносит данные о клиенте, о покупаемом товаре и приобретаемых услугах
4. Менеджер проводит документ Исключение №1 не все поля заполнены	5. система проводит документ
6. менеджер выполняет команду Печать	7. Система отображает заполненную печатную форму
8. Менеджер выполняет команду Печать	9. Система выводит на печать
10. Менеджер выполняет команду Закрыть печатной формы	11. Система закрывает печатную форму
11. Менеджер выполняет команду Закрыть документ «оказание услуг»	12. Система закрывает форму документа

Таблица - 16 Исключения сценария выполнения ВИ «Зарегистрировать документ»

Таблица -17 ВИ «Сформировать отчет»

Разработка структуры справочников

Справочник «Контрагенты» предназначен для хранения информации о клиентах, поставщиках.

Таблица -15 Реквизиты справочника Клиенты

Правовой статус имеет тип перечисление. Это значит что при выборе этого поля будет выпадать список из трех статусов: ИП, Физ. Лицо, Организация.

Создание справочника «Сотрудники» . Предназначен для хранения информации о сотрудниках организации. Позволяет привязывать продажу к конкретному сотруднику.

Таблица -16 Реквизиты справочника Сотрудники

Создание справочника «Склады» . Предназначен для определения места хранения товара. У ИП будут два склада это ТорговаяТочка1 и ТорговаяТочка2.

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

Создание справочника «Номенклатура» . Для учета товаров, приобретаемых у поставщика, создадим справочник «Номенклатура».

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

Таблица -17 Реквизиты справочника Номенклатура

Разработка структуры регистра сведений «Цены номенклатуры»

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

Таблица -18 Структура регистра сведений Цены

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

Разработка структуры документа «Поступление товаров»

Документ «Поступление товаров» предназначен для отражения факт поступления в организацию приобретенных товаров.

Таблица-19 реквизиты документа «Поступление Товаров (Приходная Накладная)»

Таблица -19 Реквизиты табличной части документа «ПоступлениеТоваров»

Написан код для автоматического расчета значений колонок Сумма, при изменении значений колонок Количество, Цена.

Форма документа будет иметь вид, изображенный на рисунке 2

Рисунок 2- Форма документа Поступление товаров

Разработка структуры документа «Продажи»

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

Таблица -20 Реквизиты документа «Продажи»

Таблица -21 Реквизиты табличной части документа Продажи

Разработка структуры документа «Резервирование»

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

Таблица -20 Реквизиты документа «Резервирование»

Таблица -21 Реквизиты табличной части документа Резервирование

Разработка структуры документа «Ввод начальных остатков»

Этот документ необходим для ввода в базу данных начальных остатков.

Его реквизиты схожи с документом «Приходная накладная».

Создание отчета «Товары»

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

В среде 1С Предприятие 8 есть построитель отчетов, который позволяет быстро разрабатывать отчет, формируя на основе таблиц запросы и оформление.

Создание отчета «РеестрДокументовПродажи»

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

Создание ролей и назначение их пользователям

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

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

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

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

- администратор - в системе 1С:Предприятие должна присутствовать роль, включающая в себя полные права на работу с данными ИБ;
- кладовщик;
- менеджер;
- ИП.

Присвоение ролей пользователям осуществляется через пункт главного меню Администрирование -> Пользователи.

Рисунок 3 - Создание пользователя «Администратор» с ролью «Администратор»

Рисунок 4 - Список пользователей системы

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

Редактирование командного интерфейса разделов и рабочего стола

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

Рассортируем команды в зависимости от приоритета и частоты использования по следующим группам:

- панель навигации.Важное;
- панель навигации.Обычное;
- панель навигации.См. также;
- панель действий.Создать и
- панель действий.Отчеты

Рисунок 5 - Командный интерфейс раздела «Учет материалов» пользователя с ролью «Кладовщик»

Рисунок 6 - Командный интерфейс раздела «ОказаниеУслуг» пользователя с ролью «Менеджер»

Рисунок 7 - Командный интерфейс раздела «Предприятие» пользователя с ролью «Директор»

Рисунок 8 - Командный интерфейс раздела «Розницы.Электроник» пользователя с ролью «Администратор»

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

Рисунок 9 - Рабочий стол для пользователя с ролью «Кладовщик»

Рисунок 10 - Рабочий стол для пользователя с ролью «Менеджер»

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