Оставить заявку

'Ася' (Все сообщения пользователя)

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

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

Страницы: 1 2 След.
Описание информационного обеспечения системы
 

Всем добрый день!

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

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

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

Принципы организации

Стандартно пишут, что есть внемашинное и внутримашинное.

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

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

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

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

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

описание решений: если ваша система с чем-то взаимодействует, то у вас наверняка какие-то стандартные форматы обмена информации. Так пишите- выбрали это, потому что это стандарт, или потому что уже так было реализовано до вас. Что у вас происходит, если у вас несколько трансляций идет, как вы переключаетесь между ними (так, как про вашу систему ничего не известно, то приходится придумывать), что со звуком происходит (если у вас изображение со звуком). Какие типы сигналов поддерживаете, есть ли в системе возможность выбрать тип сигнала/устройства? Есть ли возможность смотреть архив, если да как он организован, как запросить видео из архива.

Организация сбора и передачи информации

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

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

Построение системы классификации и кодирования

Ну скорее всего новых систем классификации и кодирования , классификаторов вы не создавали – так и пишите, не создавали.

База данных, ну если у вас файлы, например, складываются на сервер, имеют какой-то формат  name_01-11-2019_16_29 , так и описываете: файлы лежат там-то, имя файла состоит из номера, даты и времени получения изображения от камеры (это я сейчас фантазирую).

Либо база данных организована в виде набора таблиц, перечисляете таблицы, что в них содержится. Названия полей- расшифровка, чтобы было понятно, для чего они.

Внемашинная база

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

[B]Суть документа[/B] – тому, кто будет пользоваться вашей системой, должно быть понятно, откуда берутся данные для работы системы, где они хранятся и как/кем/че м они используются, и что в этой базе что. Потому что если, например таблица названа «cr_ex_328» и в документации не описано, что это за таблица и для чего она, то потом будет очень тяжело вспомнить, а что же в ней такое было и где она используется.

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

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

К рабочей (по ТЗ) отнесено руководство администратора и ведомость эксплуатационных документов.
Никакие другие [U]документы в ТЗ не указаны.[/U]

Вопрос: что писать в ведомости эксплуатационных документов в этом случае? Если эксплуатационные документы, под эксплуатационными я подразумеваю инструкцию или паспорт системы, не предусмотрены ТЗ?
И нужно ли [U]В[/U] ведомость технического проекта вписывать руководство админа и ведомость ЭД?

Читаю ГОСТ: РД 50-34.698-90
"2.1. Ведомость эскизного (технического) проекта
2.1.1. Ведомость содержит перечень всех документов, разработанных на соответствующих стадиях создания АС и применяемых из проектов других АС."

Т.е. я это понимаю так, что рабочая документация все-таки не вносится в ведомость ТП?  
Но и в ведомости эксплуатационной документации ее тоже быть не должно?
Т.е. ее вообще никуда не нужно вписывать или все-таки допускается вписать в ведомость ТП (находила такие варианты)?

Буду очень признательна за помощь.
Сомневаюсь в значимости должности техписа в конкретной компании - как быть?
 

Добрый день.

Я вижу как минимум две причины.

1-е По поводу «мало со мной контактируют, порой не отвечают на сообщения, не проверяют или очень вяло проверяют мою работу»  - возможно им просто некогда проверять за вами вашу работу или придумывать вам задание. К слову, задания вам должен все-таки выдавать ваш руководитель, а не другие сотрудники. Если есть система ведения задач, то максимум, что они могут делать (как мне кажется) накидать туда задач для вас: исправить там-то , переделать то-то.

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

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

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

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

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

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

Вот как-то так, удачи!

Единый реестр российских программ для ЭВМ и ПО
 
Коллеги, добрый день. была похожая тема [URL=https://techwriters.ru/forum/forum607/topic20221/]https://techwriters.ru/forum/forum607/topic20221/[/URL]
Но у меня вопрос такой: кто уже подавал документы? С чем сталкивались при подаче документации (подразумеваю :  Документация, содержащая описание функциональных характеристик программного обеспечения и информацию, необходимую для установки и эксплуатации программного обеспечения  и   Документация, содержащая описание процессов, обеспечивающих поддержание жизненного цикла программного обеспечения ....)  ?
Были ли какие-то замечания по оформлению? Как проверялась полнота документации?  
Были ли случаи отказов во внесении, с чем были связаны?
техписовские странности
 
Сталкивалась с таким...это
[LIST]
[*]или человек не знает как задать обтекание картинки текстом,
[*]или вариант когда у него картинка выглядит не по центру (например из за полей и "запихивая" ее в рамку, он таким образом задает ее размещение на странице
[*]или не умеет задавать рамку вокруг картинки и поэтому помещает ее в таблицу, типа "обводит".
[/LIST]
поэтому при получении документов от незнакомых людей, я выделяю все и включаю "Все границы"...такое иногда увидишь...
Новый госконтракт, Подготовка к новому госконтракту
 
Здравствуйте.
Новый контракт как правило еще месяца полтора будет подписываться (т.е. после того как выиграете- еще будут долго подписывать).
Не закладывайтесь на дату подписания контракта.  Не думайте, что вот сейчас подпишут и тогда приступите к работе.
Иногда- волшебным образом- срок первого этапа резко меняется с 3-х месяцев до 2-х недель.

Кстати... обычно перед контрактом еще предложения к тз нужно делать, это тоже работа на пару-тройку дней. Если не делали - спросите менеджера. Может вам их нужно делать?

Так как ТЗ еще пока примерное: то смысла пока что-то писать нет.  Если тз пишете не вы (а если вы тем более) -  то оценивайте то, что вы написали, с точки зрения того как вы потом будете демонстрировать, что достигнут нужный результат. Или вообще достигнут. Сильной конкретики не нужно.

Займитесь подготовкой шаблонов. Если это продолжение старого контракта, то нужно взять старые документы,скопировать и  почистить их .
Кому-то удобно все удалить (оставив только заголовки), кому-то удобно оставлять текст и потом уже удалять (ну чтоб было понимание, что вообще писать).
Таким образом вы будете понимать, какое наполнение будет в разделах  и какая дополнительная информация   от технических специалистов вам может понадобится.
Например: описании информационного обеспечения может понадобится схема БД, лучше предупредить заранее, что она будет нужна. (Специально ее никто не делает, как показывает практика.). После подготовки такой "рыбы"  становится видно какой документ с каким будет перекликаться.
Для новичка- это важно.
Т.е. вы уже будете представлять какие части из какого документа можно "дернуть".

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

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

Далее, как только выиграете...

Имея на руках утвержденное  ТЗ, вы уже можете заполнить часть пояснительной записки и прочих документов.

При этом вы должны мониторить дату подписания контракта, не оставляйте это на откуп менеджеру.
В моей практике был случай (в самом начале), когда меня не уведомили о том что контракт подписан, и сообщили об этом- та-а-да-ам!!- в день окончания первого этапа! Слава Богу, там  не было документов, только акты и дистрибутив. Все доки были во втором этапе. Но на них был отведено 2 месяца, а уложиться пришлось в один.Было обидно.

Так что постоянно интересуетесь- подписали ли контракт.
Как только узнаете дату подписания контракта, берете ТЗ ( и если у вас поэтапная сдача особенно) - сами просчитываете все даты.
За дату отсчета берете не день подписания контракта, а следующий за ним.Это будет первый день первого этапа. Считаете даты.
Внимательно смотрите в ГК (да скан ГК у вас должен быть!! как правило техпису его не дают, думают, что не нужен- но он вам нужен. Там сроки сдачи прописаны.): скорее всего по ГК документы вы должны сдать на 5-7 дней раньше окончания  этапа (для согласования).

Составляете такой список (числа для примера):
16.02.2016 - передача документов на согласование
20.02.2016 - окончание этапа, подписание актов

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

Вот с каким нюансами сталкиваюсь постоянно я:

1) Госзаказчик  за дату окончания этапа берет не ту дату , которая стоит в ТЗ, а ту - когда вы фактически сдали документы.

Например -окончание первого этапа у вас 20.02.2016.
Скорее всего в ГК будет написано, что сдать документы вы должны на 5-7 дней раньше  т.е. 15.02.2016.

Допустим второй этап у вас- 20 дней. Вот эти 20 дней они могут считать от 16.02.2016 (т.е. от штампа на сопроводительном письме).

Эти 20 дней (если бы вы считали от 20.02.2016) наступили бы 11.03.2016 года (считаем в календарных днях).
Опять же так как вы должны  за пять дней раньше сдать  - это было бы 07.03.2016.

Но....так как заказчик будет считать от 16.02.2016 (от даты передачи документов по первому этапу),  то смотрим, что мы получаем: 07.03.2016 -это 20 дней. Минус 5 дней - 02.03.2016. Вот это будет ваша дата сдачи документов по второму этапу ( а не 07.03.2016).


2) Если срок сдачи выпадает на субботу например. У нормальных людей в этом случае сроком сдачи считается первый рабочий день- т.е. понедельник. Госзаказчик может (и скорее всего потребует сдать в пятницу) - вот вам еще три дня "съестся" и соответственно сдвинется срок следующего этапа.

Т.е. ваша задача - помимо написания документов- следить за сроками, чтобы не было просрочки.
И пусть даже у вас документы будут с ошибками/опечатками- все равно отправляйте- чтобы не сорвать сроки. Пока они будут проверять неделю, а то и больше- исправите.

Поэтому: просчитываете сроки и отправляете их заказчику. Потом вешаете у себя перед компом этот список и мониторите даты.

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

Т.е. например:  испытания у вас на третьем этапе. Пусть окончание третьего этапа будет 20 марта. Это значит - что к 20 марта испытания должны быть успешно пройдены. Т.е. сами испытания должны быть где-то 15-17 марта, а программу и методику вы должны отправить с сопроводительным письмом ДО испытаний (т.е. хотя бы за 3-5 дней).  Я пишу по своей практике- может у кого-то по другому, но у нас вот так. Эти сроки тоже нужно учесть, хотя бы примерно. Потому что ПМИ - как правило - объемный документ.  Его тоже можно заранее подготовить : таблицу, выписать пункты ТЗ туда.

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

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

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

Нужно хорошо сделать программу и методику предварительных испытаний.
Опять же: не мудрите с таблицами, колонками и т.п.
Вам ее потом копировать в протокол, там какие-то столбцы придется удалять. Если будет много объединений ячеек- это будет сложно сделать.

Потом вы эту программу и методики скопируете еще раз и сделаете из неё программу и методику приемочных испытаний и протокол приемочных. Так что потратьте время на написание методики предварительных испытаний (этим документом вы фактически закроете еще 3 документа)

Ну в общем я думаю, надо начать с подготовки шаблонов документов и проработки сроков (когда будет известна дата подписания контракта).

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

Если у вас разработка ПО: вам будет потом нужно описание дистрибутива. Тоже позаботьтесь заранее: программистам надо еще его собрать будет. У нас например до недели уходит на это процесс.

Вот как-то так.
Какие средние сроки создания пакета документов?
 
Я отвечу из своего опыта подготовки документов по 34 ГОСТу.
В среднем я на один документ закладываю пару дней плотной безотрывной работы  (это при условии наличия у меня ВСЕЙ необходимой информации по проекту). Это будет первая итерация документов, к которой заказчик может давать замечания в зависимости от своей фантазии. С учетом того, что замечаний по существу документа как правило нет, и они носят характер: "запятая не того цвета" -  длительность стадии "улучшений" предугадать не получится.

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

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

+ в настройках файла поставьте автосохранение: у меня стоит 1 минута и я этого не замечаю. Если при каждом сохранении у вас все зависает минут на дцать... то... В общем: все должно летать :)).

Если тупо взять тз, поменять в нем слово "должно быть " на "сделано", "разработано" - то пояснительная записка будет готова за несколько часов. Не ведитесь на автозамену - может поменять там, где не ждете.
Лучше через F5: и по подсвеченным словам пройтись.

Но по поводу пояснительной записки: там внутри есть несколько крупных разделов, которые иногда выносят в отдельные документы: описание автоматизированных функций, описание информационного обеспечения и описание ктс. (Это как раз к вопросу о техпроекте:  у нас это записка, описание по, описание информ обеспечения и описание автоматизированных функций, описание комплекса технических средств. В ГОСт конечно документов больше - но заказчик хочет так).  

Описание автоматизированных функций: если вы будет писать в ключе, что пользователь нажал туда-то, программа сделала то-то - это одно.
Если от вас требуется писать в ключе, что пользователь нажал туда-то , сформировался запрос такой (пример строки запроса), в этом запросе содержатся такие-то параметры (перечень параметров и какой для чего нужен), запрос передается  в базу данных, в результате возвращается ответ вида (пример строки ответа)  - то лучше обратиться к программисту. Сделайте ему пример описания функции - и потом получившийся результат вставите в документ.Как правило - они работают в каком-нибудь опенофисе или либерофисе. Заложите время на перенос текста из документа в документ. Можно сделать копию с Word документа и отдать, но у моих коллег эти опенофисы, так портят вордовский документ, что на форматирование уходит дикое кол-во времени. Проще перенести.

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

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

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


Время написания  хорошего руководства пользователя с картинками и подписями к ним - зависит в том числе и от количества картинок в нем. В среднем на то, чтоб вставить одну картинку ( сделать скриншот, вставить в руководство, подписать её и сделать на неё ссылку в тексте через перекрестную ссылку) - у меня уходит от 30 секунд до минуты. Опять же в зависимости от того каким инструментом для снятия скриншота Вы пользуетесь и сколько картинок вы хотите вставить (потому что тогда список  картинок в перекрестной ссылке увеличивается и на выбор нужной ссылки тоже тратятся секунды) + быстродействие вашего компьютера.
Если Вы нажимаете PrintScreen и потом картинку обрезаете в Word - значит еще больше времени.Если сразу обрезаете нужную область (например,я пользуюсь Greenshot или ABBYY Screenshot Reader) - то быстрее.

Если у вас в руководстве 100 картинок- то это уже как минимум полтора часа на то, чтоб просто вставить картинки в документ,подписать их и сделать ссылку в тексте ( Я имею ввиду следующую ссылку: "...схема расположения оборудования представлена на рисунке ниже, Рисунок 1".).
Если программист параллельно с вами меняет интерфейс программы - можно заработать нервный срыв :)))
Накидываете время на то, если Вы на этих картинках еще что-то будете обводить ( ну например обвести кнопку на которую нажать и т.п.).
Поэтому когда надо быстро- жертвуйте картинками.
Само руководство: если у вас все работает и вы можете воспроизвести все действия пользователя- это одно время, если что-то ломается и Вы какую-то функцию не можете описать - другое.

Руководство админа: попросите выдать вам все характеристики рабочего места администратора - можно запросить у админа (ну или у разработчика, у тестера, смотря кто у вас там есть, кто устанавливал программу, настраивал её и т.п.)- в общем нужно посмотреть, какую информацию вам могут выдать заранее, а Вы её потом вставите в документацию и "причешете". Картинки: будете иллюстрировать каждый шаг - увеличиваете время подготовки документа. Тут еще такой момент: как правило, если кто-то вам устанавливает программу, то он очень быстро проскакивает все стадии установки- и вы остаетесь без картинок. Придется что-то повторять.
Желательно всегда писать про то, как проверить работоспособность установленной программы, и привести перечень сообщений которые может выдавать программа в случае ошибок и т.п. Тоже спрашивайте у программиста: учитываются ли у тебя какие-то ошибки, если- да как они обрабатываются, какое сообщение выдается на экран ( и выдается ли вообще). Если не выдается : пишите, что в случае неработоспособности обратитесь к системному администратору.

Программа и методика: ну полдня - день. Опять же от подробности документа зависит. От самого ТЗ конечно тоже: 3 функции там, или 133.
Частично программу и методику можно передрать из руководства пользователя, если проверяются какие-то пользовательские функции.
Объем Вы сами регулируете. Например в ТЗ у вас есть требование: "пользователь должен иметь возможность отправить письмо с несколькими вложенными файлами".

Вы можете написать:
Шаг 1:пользователь нажимает туда-то - открывается окно почты + картинка
Шаг 2:Пользователь нажимает туда-то, открывается окно для выбора файлов+картинка
Шаг 3:Пользователь нажимает туда-то, активируется инструмент прикрепления файлов+картинка
Шаг 4:Пользователь удерживает Shift и выбирает несколько файлов и т.д. и т.п.

А можете короче: пользователь открыл  окно почты и с помощью инструмента-такого-то (вставляете маленькую картинку кнопки прям  в предложение) прикрепляет нужные файлы , удерживая клавишу Shift нажатой.

Учитывайте, что обычно в ходе предварительных испытаний, возникают какие-то замечания. Поэтому лучше заранее обсудить с руководством, что вы будет вписывать в эти замечания ( как правило одно-два для приличия придется вписать). Или подойдите к программисту спросите: какие были косяки и как их исправили (конечно, это должно быть что-то простое). Но на это тоже нужно время: от "сразу" до нескольких часов. Хорошо если ведется трекер ошибок- он быстрее освежает память.

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

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

Акт сдачи-приемки выполненных работ готовит как правило бухгалтерия. Иногда: неправильно.Иногда проще самим подготовить, так как в акт надо  перенести РЕЗУЛЬТАТЫ работ из ТЗ.  Но не  у всех получается правильно перенести текст из одного документа в другой с первого  раза.
И не забыть еще напомнить секретарю  - чтоб сделали сопроводительное письмо, на то,что вы передаете заказчику. Тоже лучше список выдать, что будете передавать.А то всякое бывает....

ну вот как-то много у меня получилось текста... может быть что-то полезное всё-таки в нем есть :)))
Программа и методика: как оформлять
 
Коллеги, добрый день!
Два вопроса по документу программа и методика предварительных испытаний.
Есть ТЗ на систему, на первом этапе разработано детальное ЧТЗ. Т.е. в тз пункт звучит примерно так: функции модуля"А" должны работать. В ЧТЗ: функция один  модуля А должна работать, функция два модуля А должна работать и т.п.

1-й вопрос: В программу и методику нужно выписывать пункты по ТЗ (так как вроде это основной документ проверяьт на соответствие ТЗ) или выписывать пункты  по ЧТЗ (потому что проверять-то надо работоспособность каждой функции отдельно)? Если есть на эту тему какой-то руководящий документ, подскажите, пожалуйста какой. По моей логике: нужно писать по ЧТЗ.

2-й вопрос: проверяющий ввел какие-то обозначения  (показатели назначения), т.е. это таблица с перечнем проверок с такими столбцами:

Наименование проверки (например, Проверка реализации требований к режимам функционирования системы)- Обозначение показателя (например С1)-проверяемый номер пункта (ТЗ(или ЧТЗ) см 1-й вопрос) - номер методики (например В.1).
Опять же не найду как присваиваются эти значения показателей и почему например С1, почему В1?

Сталкивался ли кто-нибудь с этим и где можно посмотреть как правильно составить этот перечень проверок?

Спасибо!!
ТЭО, Что писать в разделе: Требования к характеристикам реализации функций?
 
Всем добрый день! Подскажите, пожалуйста, что нужно писать в  разделе: Требования к характеристикам реализации функций?
Можно ли туда перенести раздел из ТЗ, требования к функциям или речь о чем-то другом.
Как правильно писать программу и методику
 
Всем добрый день!
Подскажите пожалуйста, при написании  программы и методики в части общих требований к Системе (например требования к режимам функционирования, требования к диагностированию и т.п.)...нужно прям точь-в-точь из ТЗ переносить текст  или можно как-то выбирать? (не в том смысле что не указывать часть требований в программе и методике, а исключить тот текст, который скажем так сопроводительный (поясняющий требования))?
буду благодарна за разъяснения.
Как правильно составлять список сокращений и терминов
 
Спасибо!!
Как правильно составлять список сокращений и терминов
 
[url=http://techwriters.ru/forum/user/13391/]ADVANCED[/url], к сожалению, сразу не увидела ваше сообщение:
"Список должен быть одинаково актуальным. Но состав терминов должен соответствовать отдельному документу.  Т.е. не должно быть описания термина, которого нет в тексте"- да, наверное это более логично, чем "захламлять" документ лишними терминами...
тогда остается вопрос только по комплектации ( если все сшивать в одну книгу: оставлять один общий список или после каждого документа приводить свой).
Как правильно составлять список сокращений и терминов
 
всем помогающим- большое человеческое спасибо...

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

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

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

Если подскажете, где посмотреть правила оформления пояснительной записки  (когда пояснительная записка из нескольких документов сшивается в одну книгу - буду очень признательна).
Где-то я видела- но никак не найду где.
Как правильно составлять список сокращений и терминов
 
Уважаемые коллеги.
1) Прошу подсказать: как правильно составлять перечень сокращений и терминов?
Туда нужно выносить только то, что встречается по тексту документа?
Пример, в тексте встретилось сокращение HTML. При его расшифровке сразу всплывают такие понятия как браузер или веб-страница (которых в самом тексте документа нет).
Нужно ли описывать эти новые понятия (браузер, веб-страница)? Это ведь может быть бесконечный процесс…

2) И еще:

Этот список должен быть одинаковым для всех документов комплекта (и для пояснительной записки, и для описания программного обеспечения), или нужно его редактировать под каждый документ?
Так как в пояснительной записке терминов и сокращений больше чем в том же описании ПО. Как правильно?
Буду очень благодарна за ответ.
формулировка в ТЗ, формулировка в ТЗ
 
Здравствуйте, и снова я…..
Несколько раз в тексте присланного ТЗ встретила фразу «что данные в систему должны вводиться однократно»… что значит однократно? Планируется что разрабатываемая БД  периодически будет обновляться. Это все равно считается однократным вводом? Или однократный ввод – это когда вообще никогда не изменяется… что-то я совсем запуталась.
Подскажите, пожалуйста…
гензаказчик-заказчик-подрядчик: о ком писать ТЗ?
 
спасибо, попробуем написать так.
гензаказчик-заказчик-подрядчик: о ком писать ТЗ?
 
правомерно ли в ТЗ между подрядчиком и Заказчиком, упоминать Гензаказчика (так фактичесrим заказчиком работ является он).
И Гензаказчик сначала предоставляет исходные данные Заказчику (на основании договорных отношений с ним), а Заказчик передает данные подрядчику (на основании договорных отношений с ним).
Заказчик, опасаясь, что гензаказчик вовремя не передаст ему данные, в ТЗ для подрядчика исправил слово заказчик на Гензаказчик (т.е. теперь слово заказчик встречается только в самом начале тз , где заказчик и исполнитель, кстати про гензаказчика там тоже не слова).
И далее по тексту везде идет Гензаказчик.
Между подрядчиком и гензаказчиком напрямую договорных отношений нет!
Можно ли в ТЗ писать что гензаказчик должен что-то предоставить, или его обязательства полностью переходят к заказчику?
Мне кажется, что такое тз будет просто неправомерно, на что можно сослаться?
заранее благодарю за ответ.
Опытно-конструкторские работы
 
а если приемочные испытания были?
Т.е. по сути - это модернизация программного продукта.
Т.е. часть функций остается, а часть разрабатывается снова с нуля. Вот меня беспокоит насколько здесь присутствует эффект новизны: одна часть то уже точно не новая, как вот это с НИОКР?
Отличия в ГОСТ 34 и ГОСТ 2.105-95. Срочно!
 
Пожалуйста, если можно , перечислите, различия в оформлении документации по 34 госту и 2.105.
Насколько сильно они отличаются?
Как правильно оформить текстовый документ в Word?
 
Здравствуйте!

Хочу сделать некий внутренний шаблон, макcмаксимально приближенный к ГОСТУ.
Но не знаю как правильно оформить, нашла, что:
шрифт -12 TimesNew Roman
междустрочный интервал - 1,5.

И еще нашла В ГОСТ 2.105-95, что  "Абзацы в тексте начинают отступом, равным пяти ударам пишущей машинки (15 - 17 мм)", а по поводу всех остальных отступов?

какой должен быть абзацный отступ для Заголовка 1-го. 2-го и последующих уровней (5-6 го например)? В ГОСТ в п 4.1.2 написано, что "Разделы ...записанные с абзацевого отступа", а величина какая?
Какой отступ должен быть для списков 1-4 го уровней?
Где должно размещаться слово "Таблица": слева или справа над таблицей?
Где должно размещаться слова "Содержание", "Аннотация", "Приложение", "Список иллюстраций" и "Список таблиц"?
Какое должно быть расстояние между номером раздела и его названием, т.е. между "2." и "Р", например в названии "1.2. Раздел 2"?
Где правильно размещать номера страниц: в правом нижнем углу или вверху по центру листа?

Буду очень благодарна, если кто-нибудь сможет помочь.
Опытно-конструкторские работы
 
Может ли считаться опытно-конструкторскими работа по доработке программного продукта, если в неё добавляются новые функции?
Т.е. есть действующий вариант ПО, заказчик хочет новые функции добавить и назвать "старый продукт"+"новые функции"="опытный образец". Возможно ли такое?
Код документа для журнала эксплуатации
 
В госте 34  есть код для документа "программа и методика" - ПМ.
А для прочих документов (журнал опытной эксплуатации, протоколы, программа и методика для приемочных испытаний, программа опытной эксплуатации) существуют коды? Если да, то где их найти.
мы в ответе, за то что мы написали?, ответсвенность
 
мне просто казалось, что если продукт не доработан, а -например- программа опытной эксплуатации написана и подписана, и все последующие документы тоже, то это как-то ...не правильно что-ли.
т.е. продукта-то нет (он будет конечно, когда-нибудь), а документы уже есть, потому что "закрываться то надо".
мы в ответе, за то что мы написали?, ответсвенность
 
у вас случались ситуации, когда нужно было писать документацию на то, что как буд-то бы "сделано" , а ОНО еще "не сделано"/"никогда не будет делаться"/"сделано, но не так как надо" и т.д.
Стоит ли писать такие документы? Какую ответственность в данном случае несет писатель?
Изменено: '' - 22.05.2013 15:53:26
Как правильно оформлять таблицы, оформление таблиц
 
В ГОСТ  есть требование, что каждая таблица должна иметь заголовок и ссылку на неё в тексте.
А как быть, если эта таблица в приложении. Т.е. таблица и есть приложение?
Приложение оформляется буквами: Приложение А.
Далее идет таблица.
Этой таблице нужно придумывать название и перед таблицей добавлять какой-то текст, со ссылкой на таблицу? Хотя собственно это и есть само приложение, и никакого дополнительного текста не предполагается?
Тоже самое,если в разделе, есть только таблица, а текста не предполагается вообще?
Просто  получается «масло масленое».
Раздел 2: Перечень чего-то
Перечень чего-то приведен в таблице ниже, таблица «Перечень чего-то»
Таблица 1. Перечень чего-то.

И где-все таки должно располагаться наименование таблице (почему то в самих ГОСТАХ наименование выровнено по правому краю, а в тексте ГОСТА прост сказано, что "наименование должно располагаться сверху таблицы).
Страницы: 1 2 След.

Рейтинг@Mail.ru