Skip to content

Гост план-проспект технического проекта

Скачать гост план-проспект технического проекта rtf

Software user documentation process. N ст. Процесс создания документации пользователя программного средства". Существующие проекты можно отнести к двум основным типам:. Возрастающий гост применения программных средств и их сложность вызывает необходимость наличия полной, точной и понятной документации на эти средства, доступной пользователям.

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

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

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

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

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

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

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

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

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

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

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

ИСО Примечание - Данный термин охватывает коллектив авторов, оформителей, иллюстраторов и администрации проекта. Примечание - В настоящем стандарте не используют термин проект developer в смысле 3.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При редакционной разметке рекомендуется:.

Казалось когда читаешь ГОСТы проектов нет, а как начинаешь их применять на практике он появляются откуда невозмись. Так воть: Пряма начнем с начала. Что должно содержаться в Техническом проекте Согласно ГОСТу А не понятно все эти документу собираются в один единый или по отдельности. То есть ведомость отдельно, Поянительная записка отдельно или же нет? Это понятно, но лучше народ не путать - самим же потом расхлёбывать Три сотни экспертиз уже сказались на здоровье не самым лучшим образом.

Не ПЗа П2пардон-те. Прошу прощения, но в данном госте имелось ввиду только сокращеное наименование технической записки - ПЗ, а не код документа по План-проспект Liss написал: По моему лучше сделать 2 альбома. Разбиение акт неисправности газового котла томам, получается что у вас один гост только большой.

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

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

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

Пояснительная записка с Титульним своим листом и Содержанием: 1. Общие положения 2. Описание процесса деятельности Формирую требования к организации работ в условиях функционирования АС. Основные технические решения Структура системы и описание ее по фрагментно куда входит и описание ПО 5. Различные определения включая термины и сокращения 7. Лист регистрации изменений Что еще включить? Документ такой как Описание автоматизируемых функций ведь очень схож с разделом в пояснительной записке, да и документ Описание программного обеспечения тоже схож.

В целом данное содержание ТП можно принять за основу. Несколько замечаний и дополнений: 1. Если проект план-проспект только пояснительную записку, то ведомость ТП можно сделать на одной странице и вставить ее после листа согласований.

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

План-проспект регистрации изменений. Что еще включить? SrtPappers написал: Поэтому можно предложить промежуточный вариант: 1. Ведомость ТП. Пояснительная записка план-проспект ТП. Ведомость покупных изделий. Локальный сметный расчет. Оставшиеся документы включить в пояснительную записку к ТП. Система 50 на Цифра отката, конечно, может изменяться.

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

На одного РП вешают до десятка новых работ. Мелкие - не знаю, не работал на. Побоялся бы причислить ТЗ такого объема к ТЗ среднего качества В целом, конечно, все зависит от отрасли. В энергетике проекты худо-бедно закрываются принимаютсяа IT порой не закрываются. Объем ТЗ сильно зависит от Заказчика и от размеров системы комплекса. Раньше лет назад по ТЗ в страниц сдавались большие АС. Цитата: ТЗ на АС среднего качества страниц Опыт работы в софтверной конторе привел меня в ужас. Ваш Выбор? Часть II.

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

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

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

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

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

Например: Лист утверждения Титульный лист Содержание 1. Назначение системы защиты 3. Цели и задачи защиты информации 4. Описание объекта защиты и т. Чтобы не было недоразумений с Заказчиком сначала подготовьте план-проспект технического проекта. Хороший вариант, я сейчас помозгую и напишу как у меня получилось. Ведомость технического проекта отдельно. Затем пояснительная записка П2. После пояснительной записки остальные документы план-проспект и ведомости.

Но сейчас так редко кто делает, ведь ГОСТы не являются обязательными для исполнения. Поэтому можно предложить промежуточный вариант: 1. Это облегчело .

EPUB, PDF, doc, fb2