Заказать звонок

Дмитрий (Все сообщения пользователя)

Форум » Пользователи » Дмитрий

Внимание! У нас сбои с почтовым сервером! Если не пришло письмо о регистрации или смене пароля напишите нам на info@techwriters.ru! 
@twriters
 obmen_soobsheniyami.pngчат для технических писателей в Telegram

 Зарегистрируйтесь
Выбрать дату в календареВыбрать дату в календаре

Страницы: 1 2 След.
нумерация документов
 
А в чем собственно проблема с кодом документа? Вообще обозначение необычное (или Вы не дописали чего-то, или это не по ГОСТу - но это дело Вашей фирмы), но несмотря на это никто Вам не мешает делать так (предполагая что "вин"-это сервер, а "веб" - это клиент или как там у Вас):
1. <Название программы>.<Серверная часть>.<Руководство пользователя>
2. <Название программы>.<Серверная часть>.<Руководство администратора>
3. <Название программы>.<Клиентская часть>.<Руководство пользователя>
4. <Название программы>.<Клиентская часть>.<Руководство администратора>.
Делать разное обозначение для клиентской части и серверной (или как Вы ее там называете) совсем не обязательно. Кстати вопрос:  а зачем Вы делали разное обозначение для админки и пользовательской части, обычно удобнее под одним обозначением, т.е. это некий программный комплекс, а глубже разделения не делаем (так рекомендуют в частности некоторые сертифицирующие организации).
ТЗ на создание сайта
 
Я бы использовал 19-й ГОСТ:
1) потому как ГОСТ это лишь конва, которую имеет смысл учитывать, но не забывать про здравый смысл. 19 на эту роль вполне подходит;
2) у Вас наверняка будет не только HTML-ки. С большой долей вероятности будет некое серверное наполнение типа БД и бизнес-логики (сервлеты, EJB и т.д.), а это уже ПО.
4 уровень отсутствия НДВ
 
1) На сертификацию идет готовое изделие, соотвественно должен быть штамп ОТК и ВП, именно поэтому в комплект документации включается формуляр, в котором и проставляются все перечисленные отметки (по крайней мере так требуют). Кстати у кого Вы сертифицируетесь (как фирма называется)?
2) В спецификациии пишутся вcе программые документы (кроме спеки и ТЗ согласно ГОСТу на спеку), а не только то, что перечисленно в РД (Руководящий документ "Защита от НСД. Часть 1").
3) Нет компонентов=>не пишите, но аккуратнее с названиями, потому как на то, что называется "комплекс", могут попросить спецификацию и полный комплект документации.
Кто присваивает код ОКНО?
 
Если ОКП, то конечно разработчик прибора (должен сам выбрать код по классификатору), иначе получается, что он делает сам не зная что.
Документ "Методика апробации", что это?
 
Делайте его как "документы прочие" (код "Д.."). В определенном смысле Вам удобнее - можете Сами структуру продумать, т.е. обойтись без маразма.
ГОСТ 19.404-79. Пояснительная записка
 
Я так понимаю Вы отбиваетесь от лишней работы :).
В определенном смысле то, о чем Вы написали также является алгоритмом (с точки зрения пользователя), поэтому пишите это. Если Заказчик вредный - попросят расписать подобнее.
Добавьте общее описание функционирования ПО в целом, и получиться похоже на среднестатистичекое описание (ну может и не среднестатистический вариант, но такие документы мне встречались - попробуйте).
ГОСТ 19.404-79. Пояснительная записка
 
Идеальный вариант (с Вашей точки зранения) - пусть программисты это формулируют (а лучше и пишут), предложите начальнику, м.б. он вменяемый человек и поддержит здоровую инициативу.
К сожалению часто это "не царское дело", т.е. либо не ответят, либо ответят так, что придется самому разбираться (забавно выглядит когда программисты не могут сказать что они сделали).
Но это лирика. Советовать сложно поскольку незнаю особеннстей проекта, но у меня есть предположение, что сильно подробное описание Вам не нужно, поэтому предлагаю воспользоваться формулировкой ГОСТа и написать именно "функционирование программы", т.е. схема со стрелочками и как это работает. В довесок можно привести отдельные места поподробнее (если Заказчики попросят).
ГОСТ 19.404-79. Пояснительная записка
 
Это один из самых неприятных моментов в этом документе. Проблема в том, что вообще-то это описание должно быть достаточно низкоуровневое (т.е. в идеале практически на уровне кода). Но многим заказчикам этого не нужно и  бывает достаточно общего описания функционирования. Совет: если есть время лучше написать поподробнее.
ГОСТ 19.404-79. Пояснительная записка
 
1)Как правило пищет как про существующую систему.
2) Пишите то, что есть (т.е. нет методов=> ничего не пишем);
3) По хорошему нужно обоснование (да еще и с расчетами). Если несильно следовать "букве закона" можно привести описание того, какие варианты рассматривались (выбирите аналогичные) , пояснить, что выбранный Вами вариант лучший потому-то...
ТЗ на разработку и интеграцию
 
Под вашу задача более подходит комплекс стандартов ЕСПД (программная документация). У Вас видимо все-таки не система, а программный комплекс или компонент (определение см. ГОСТ 19.101, раздел 1). 34-е ГОСТы это ГОСты на автоматизированные системы. По ГОСТ 34.003 автоматизированная система это-"система, состоящая из персонала и комплекса средств автоматизации его деятельности..." (т.е. ПО+аппаратура+персонал). Аккуратнее с терминами, так можно случайно подписаться на лишнюю работу. Посему для ТЗ берите ГОСТ 19.201.
P.S. По поводу оценки времени на ТЗ к ответам пред. оратора добавлю - учите еще тот момент, что наверняка будет парочка итерраций, т.е. "Заказчик посмотрел - попросил поправить" и т.д. И еще - если на текущий момент неясно, что писать в ТЗ (в части отдельных требований), пропишите в ТЗ, что эти требования будут оформлены на таком-то этапе отдельным дополнением к ТЗ.
Разработка ТУ на программный продукт
 
Оформлять по требованиям ЕСПД (т.е. без рамок).
Описание процедур по ГОСТ
 
Как правило описание логики (алгоритмы, связи по данным и т.д.) приводят в документе "Описание программы" (гост 19.402). В документе "текст программы" (гост 19.401) приводят непосредственно текст. Можно расширять номенклатуру документов, т.е. добавлять документы от себя и самому придумывать их содержание- бывает удобнее поступить именно так. Выбор за Вами.
Разработка ТУ на программный продукт
 
В номенклатуре ЕСПД документа ТУ нет. Поэтому берите ГОСТ 2.114 и по подобию делайте. Проверено.
Формуляр (ГОСТ 19.501-78)
 
1) Если по правильному (насколько я помню), то на упаковку делают документацию.
2) Если хочется побыстрее, то вписать в ТУ общую фразу про "...должно соответствовать ГОСТ 21552-84...", но это вариант халтурный. Выбор за Вами.
Формуляр (ГОСТ 19.501-78)
 
1)"Сведения об упаковке и маркировке"- просто заполните форму 4. Там больше ничего не нужно.
2)"Сведения о хранении" - просто табличка, ее заполняет персонал при эксплуатации.
3)"Периодический контроль" - например: проверка контрольных сумм комплекта дистрибутива, объем свободного дискового пространства
пространства,  а также просмотр логов на предмет нежелательных событий.
Оценка производительности труда технического писателя
 
1) под отчетами я понимал документ, поэтому и написал что он необязателен. Тот факт, что контроль необходим очевиден и неоспорим.  Для контроля выполнения работ нужно проверять реальное состояние работ, т.е. "рождающуюся документацию", стадию готовности материалов, "узкие" места. Нужны контрольные точки, в которых должен быть достигнут определенный результат. Решение вопроса о том, как именно контролировать определяется исходя из Ваших приоритетов. Если он недостигнут => Ваш ход: определение причины и выбор лечения. На мой взгляд выбор частоты контроля и его объема зависит от конкретного специалиста (исполнителя), а также от Вашего знания собственных подчиненных. Таким образом управление (любое) это не формальность, это ежедневная, непрерывная работа, и  ежемесячный отчет Вас не спасет.

2) Планирование работ и отчеты - принципиально разные вещи.  
3)  Про второй вариант довольно ясно написано, что им не следует пользоваться, поэтому замечание про "русский авось" только подтверждает сказанное.
4) Критика это замечательно, но только тогда, когда предлагается некоторое решение..
Спецификация (ГОСТ 19.202-78)
 
Вообще-то описание программы и пояснительная записка не являются эксплуатационными документами, поэтому их в ведомость ЭД вносить не стоит, если конечо нет какого-нибудь спец. замысла.
Спецификация (ГОСТ 19.202-78)
 
Второй раздел я бы тоже не заполнял - иначе получается что комплекс входит сам в себя.
Оценка производительности труда технического писателя
 
На отчеты лучше не полагаться, во всяком случае я бы не стал (хотя бы на первых порах). А то отчеты будут красивые, а что по на деле непонятно.
Варианты контроля по максимуму - проверять все самому;
Вариант контроля по минимуму - Заказчик принял? Ну и хорошо...

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

P.S. Как говорил И.В. Сталин: "Кадры решают все".
Спецификация (ГОСТ 19.202-78)
 
Можно поступить следующим образом:
вы пишете спецификацию только на то, что разрабатываете (т.е. на то, что программируете), а остальное (ОС, СУБД и т.д.) называете общесистемным программным обеспечением, описываете (в смысле перечисляете) все это в поясн. записке (например), а в спецификацию эти вещи не включаете. Т.е. Вы поставляете свой продукт, а для его работы необходимо то-то и то-то. В эксплуатаицонной документации ссылаетесь на экпл-ю документацию общесистемного ПО. Такое решение обычная практика.
Программа, программный комплекс или автоматизированная систе
 
1) Строго говоря  АС (см. ГОСТ 34.003) - система состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая инф. технологию выполнения установленных функций.  У вас видимо все-таки программный комплекс (см. определения по ГОСТ 19.101). Видимо поэтому просят использовать ГОСТы 19.XXX.
2) формально в номенклатуре документации ЕСПД не указаны тех. условия, но есть момент: если посмотреть требования к документу "формуляр" (это фигня чуть сложнее паспорта изделия), который по-хорошему нужно выпускать на изделие, то можно увидеть, что там ТУ упоминается, т.е. его придется делать, если заказчики требуют, поэтому за основу брать ГОСТ 2.114.
Вариант ухода от исполнения - для продукции народно-хозяйственного применения ТУ допускается не выполнять (по-моему это там же в ГОСТ 2.114).
Спецификация (ГОСТ 19.202-78)
 
Существует понятие основного программного документа их два вида: для комплексов - спецификация, для компонентов - текст программы (т.е. то, что написали программисты). Кстати определение комплекса и компонента см. ЕСПД. Фактически параллель идет из ЕСКД, где для детали (например для гайки) основной документ это чертеж, а для сборочной единицы (например для самолета) - спецификация. Спецификация определяет состав изделия (состав всей рабочей документации), а ведомость ЭД более узкий документ - он определяет лишь состав эксплуатационной документации на изделие, кот входит в состав рабочей документации.
ГОСТ 19.104-78
 
1) Литера (т.е. просто буква) обозначает сдатию документации, которая присваивается после приема этапа работ. ПОсмотрите для примера ГОСТ 2.902. А в принципе если работа гражданская, то часто литерность не учитывают.
2) В советское время подразумевался единый классификатор на все предприятия. Сейчас каждая контора сама выдумывает себе обозначение. Выбирите 4 буквы и используйте. Кстати, обозначение страны не пишите - такова практика, т.е. пишем обозначение изделия например так:    АБВГ.00001-01.
Оценка производительности труда технического писателя
 
Скажу как руководитель - возможно имело бы смысл платить зарпату из двух частей - оклад (не очень крупный) и премия, так чтобы в сумме прилично получалось. Поясню почему так: дело в том, что если человек начинает работать "тухло" (к сожалению такое не редкость), то остается рычаг воздействия его к порядку, т.е. он остается без премии и  либо уходит, либо начинает Работать. Премии по-моему нужно платить по окончанию (успешному) этапа или работы целиком, иначе как у А. И. Райкина:"К пуговицам притензии есть?..". Выделять показатели только для техписателей в отрыве от оставшегося коллектива вероятно сложно, надумано и ненужно (я пишу по тому, как видится проблема у меня на работе и не исключаю, что в других контроах все иначе).
Как заставить начальника купить программное обеспечение
 
Развесить по конторе содержание ст. 146 УК РФ:). А если серьезно, то это конечно свинство со стороны начальника - хотим делать серьезные вещи ворованным инструментом (тем более для фирмы такая сумма не велика).
Страницы: 1 2 След.

Рейтинг@Mail.ru