Как разработать Техническое задание. Часть 2. Виды работ при сборе требований к системе учета и информации для описания бизнес-процессов.

Публикация № 124723

Методология - Проектирование - Техническое задание

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

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

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

Как это происходит в большинстве проектов

Шаги

Как это происходит

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

Как это может происходить при более грамотной организации работ

Шаги

Как это происходит

Решение принято, проекту быть! Тут ничего не меняется относительно первого варианта, эмоции никто не отменял
Провели совещание с руководителями, собрали некоторую информацию об их видении результата. Этот шаг тоже остается, и он имеет большое значение. Но основное назначение первой встречи (или нескольких встреч) с руководителями и собственниками это знакомство. Знакомство в первую очередь с людьми и компанией. Сформулированные цели и пожелания на таких общих встречах могут быть самими различными, в том числе фантастическими. Все они будут, конечно же, выслушаны, но не факт, что будут реализованы. При более глубоком погружении в бизнес компании будут как появляться другие цели, так и отвергаться предыдущие. Я это к тому, что из предварительных встреч нельзя сформулировать четкие цели, все это потребует тщательной проработки.На таких встречах необходимо конспектировать все посылы от собственников и первых лиц, чтобы потом можно было к ним вернуться и обсудить, когда будет собрано достаточное количество информации. Даже простое на первый взгляд требование может оказаться нереализуемым либо очень трудоемким.
Формирование рабочей группы от Заказчика и Исполнителя, распределение ролей Необходимо определиться, кто будет работать над проектом как со стороны Заказчика, так и со стороны Исполнителя. Несмотря на кажущуюся простоту данного этапа, он имеет очень большую роль. Если не зафиксировать четко, кто за что отвечает, в ходе реализации работ Вы рискуете столкнуться с неразберихой. Если со своей стороны Вы можете всегда конкретизировать роли в своей команде, то у Заказчика с этим могут возникнуть проблемы. На что следует обратить внимание: в состав рабочей группы Заказчика обязательно должны войти те люди, которые будут в дальнейшем хоть как-то влиять на принятие результата. Если допустить ситуацию, что при сдаче работ подключатся сотрудники Заказчика, которые не принимали участие в работах по формированию целей и выявлению требований, то проблемы гарантированы. Возможна даже такая абсурдная ситуация, что все, оказывается, сделано не так, как требовалось.В моей практике я сталкивался с такой ситуацией не раз.Поэтому, Вы себя можете обезопасить, если оговорите и зафиксируете документально, что никто, кроме рабочей группы Заказчика не может принимать участие в приемке-сдаче работ. А лучше всего, прописать такое в договорных условиях (В договоре или Уставе проекта).Помню, был такой случай: в одном крупном проекте учредитель решил подключиться к процессу (уж не знаю почему, скучно видать стало) и посетил одну из рабочих встреч, где обсуждался вопрос формирования счетов клиентам. Он с удивлением для себя узнал, что счет клиенту выставляет менеджер по продажам. В его представлении счет должен выставлять бухгалтер, и никак иначе. Но на самом деле бухгалтер вообще не представлял, о чем идет речь, а менеджер не мог себе представить, как так работать, если за каждым счетом бегать к бухгалтеру. В результате потеряли кучу времени, но ничего не поменялось, счет по-прежнему выставлял менеджер. А учредитель остался при своем мнении, но больше в процесс не вмешивался.На этом же этапе целесообразно разработать Устав проекта, в котором зафиксировать роли участников, порядок коммуникаций, регламент и состав отчетности, а также все остальное, что следует прописать в Уставе. Разработка Устава проекта это тема опять же отдельная.
Обучение проектной команды методикам и инструментам работы, согласование правил работы, видов и состава документации Во-первых, необходимо разъяснить проектной команде все, что прописано в Уставе, как это будет применяться на практике.Во-вторых, проектную команду Заказчика необходимо обучить тем методам работы, которые Вы собираетесь использовать на всех последующих этапах. Имеет смысл обсудить форматы документов, которые будут использоваться, рассмотреть образцы. Если будут применяться какие-либо правила описания моделей или бизнес-процессов, то надо обсудить и эти правила, чтобы они были понятны.
Анкетирование Этап анкетирования позволяет сравнительно быстрым способом получить достаточно достоверный срез информации о компании. Качество такой информации будет определяться тремя факторами:
  1. В первую очередь тем, как Вы обучили проектную группу Заказчика. Они должны четко понимать, как происходит процесс анкетирования и уметь донести информацию до всех участников
  2. Сама форма анкет. Анкеты должны быть понятными. Желательно, чтобы была инструкция по заполнению анкет. Еще лучше, если будет пример заполнения.
  3. Состав участников. Необходимо правильно выбрать состав участников. Если ограничиться только руководителями, собрать достоверную информацию не получится. Я рекомендую включать в состав анкетирования всех, кто будет в будущем являться пользователем конечных результатов. Например, если речь идет о внедрении автоматизированной системы, то стоит включить всех, кто будет являться пользователем. Бывают случаи, когда из 10 сотрудников одной должности найдется один, который выполняет какую-нибудь особенную функцию, о которой никто из оставшихся 9-ти больше не знает (например, готовит особый отчет для руководства). Если речь идет о дальнейшем перераспределении обязанностей или разработке должностных инструкций, следует поступить аналогично.
Обращаю внимание, что методика анкетирования для последующей внедрения автоматизированной системы или описания бизнес-процессов в правильном случае различается. Конечно, структура анкет может быть и одинаковая, но это не самый лучший вариант. Когда мы описываем бизнес-процессы, то анкеты обычно носят более общий характер, т.к. неизвестно точно, с чем придется столкнуться. Если же речь идет о внедрении конкретной автоматизированной системы, то лучше иметь анкеты, учитывающие особенности этой системы. При таком подходе можно сразу выявить все узкие места системы, которые не подходят для данного предприятия. Как правило, методики внедрения готовых систем предусматривают наличие таких анкет. Такие анкеты могут разрабатываться либо по отдельным областям учета (например, учет заказов, продажи, ценообразование), либо для конкретных должностей (финансового директора, например). Состав вопросов примерно одинаковый.
Опросы Опросом называется проведение устного собеседование со специалистами с целью выяснить особенности отдельных процессов. Необходимо организовать опрос так, чтобы он не выглядел как просто «встретились-поговорили», а более организовано. Для этого необходимо подготовить так называемый план опроса. В него можно включить те части анкеты, которые у Вас вызывают вопросы, противоречат сведениям других анкет или информация представлена поверхностно. Целесообразно добавить вопросы и просто из личного опыта.Ответы надо конспектировать в обязательном порядке. Идеально, если Вы договоритесь о ведении аудиозаписи.На этом же этапе следует проследить за полнотой предоставленной информации о документообороте (как форм первичных документов, так и различных отчетов)
Выделение ключевых бизнес- процессов или областей автоматизации После анкетирования и опроса можно обосновано считать, что информации достаточно, чтобы делать выводы о выделении ключевых бизнес-процессов. На самом деле, уже можно выделить не только ключевые бизнес-процессы, но и практически все (если состав участников был выбран правильно). Вопрос выделения бизнес-процессов это тема совсем отдельная и не простая. Научиться тут сложно и вырабатывается в основном опытом.Из выделенных бизнес-процессов следует составить перечень (классификатор). Затем можно будет принимать решения, какие из них следует исследовать более глубоко, какие нет, а также выделять приоритеты.
Формулирование ключевых требований к системе, целей, критериев успешности проекта, процессов для детального изучения К этому этапу должна быть собрана вся первичная информация о деятельности компании, составлен перечень бизнес-процессов.Теперь в самое время вернуться к целям, конкретизировать их, при необходимости обсудить с первыми лицами компании.При формулировке целей следует учесть конкретные показатели, при достижении которых будем считать проект успешным.Если речь идет о внедрении автоматизированной системы, то отдельным перечнем можно выделить требования к системе от ключевых пользователей. Я это делаю в виде отдельной таблицы, где все требования сгруппированы по подсистемам, для каждого требования указывается автор требования, формулировка и приоритет. Данную информацию можно будет использовать для составления плана развертывания системы (последовательности внедрения отдельных подсистем), а также для предложений по дальнейшему развитию системы (если отдельные подсистемы в текущем проекте внедрять не планируется).Если необходимо описать бизнес-процессы, принимаются решения о тех процессах, которые необходимо исследовать более детально.
 
Вот и добрались до вопроса «Что дальше?». Дальше будем рассматривать задачи описания бизнес-процессов и разработки Технического задания отдельно. Я не случайно рассматриваю эти задачи параллельно. Между ними действительно много общего, что я и хочу продемонстрировать. Сначала рассмотрим последовательность работ при описании бизнес-процессов.
  
 

Шаги

Что и как делать

Выделяем бизнес-процесс Из общего перечня бизнес-процессов, полученного на предыдущих этапах, выделяем один (по приоритету) для детальной проработки. С остальными затем поступаем аналогично.
Детальное изучение бизнес- процесса Выделенный бизнес-процесс подвергаем детальному изучению: анализируем полученные первичные документы, отчеты и их структуру, используемые в процессе программы, различные файлы (например, Excel), разговариваем с конечными исполнителями. Собираем различные идеи о том, как можно улучшить процесс. Очень полезно, если удастся понаблюдать за процессом именно в тех условиях, в которых он выполняется (не многие любят, когда за ними наблюдают, но что делать)
Графическое и/или текстовое описание бизнес-процесса (первичное) Полученную подробную информацию начинаем описывать.Прежде чем описывать процесс, надо определиться, потребует ли он графического описания. Если процесс простой и понятный, функций в нем мало, и, графическое представление не улучшит его понимание или восприятие, то не надо тратить на это время. В этом случае достаточно описать его в текстовом виде в табличной форме.Если же процесс сложный, с различными логическими условиями, то лучше привести его графическую схему. Диаграммы всегда воспринимаются легче. Если Вы решили описать процесс в графическом виде, это вовсе не означает, что не надо приводить его текстовое описание. Т.е. текстовое описание процесса должно быть в любом случае, причем выполненное по одинаковой схеме. Удобно это делать в виде таблицы, в которой указать: исполнителей каждого шага, какую информацию они получают на входе, описание каждого шага, какую информацию формируют на выходе. Ниже мы посмотрим на примере, как это может выглядеть.
Согласование с исполнителями и владельцем бизнес-процесса Лучший способ понять, насколько удачно вы выбрали стиль изложения информации, это показать результат пользователям (исполнителям) процесса.На самое главное в такой демонстрации это понимание того, насколько правильно Вы поняли, как процесс выполняется.Если обучение проектной команды прошло успешно, то можно ожидать от исполнителей вполне адекватной обратной связи. А если им станет интересно, то продвигаться все начнет гораздо быстрее.Выявленные уточнения и несоответствия необходимо отразить в описании (актуализировать), при необходимости операцию повторить.
Выделение показателей бизнес-процесса После того, как выработано правильное понимание, как выполняется бизнес-процесс, надо подумать над показателями, которыми можно измерить качество или скорость выполнения процесса. Это не просто, но необходимо. Показатель должен быть измеряемым, т.е. выражен в числовом выражении и должен существовать простой способ эту величину получить. Если измеряемый показатель выделить невозможно, есть риск того, что бизнес-процесс выделен неудачно. Кроме того, не будет возможности понять (измерить ведь нельзя), приведут ли изменения процесса к его улучшению или нет.
Окончательное документирование бизнес-процесса После того, как мы убедились в правильном понимании, как процесс выполняется (или должен выполняться), можно включать его в документацию.
Дальнейшие действия (или их отсутствие), в зависимости от целей проекта Дальше возможны варианты: рассматриваемые процессы будут анализироваться и оптимизироваться, разрабатываться должностные инструкции, приниматься решения о необходимости автоматизации отдельных процессов и т.д.Это может быть и отдельный проект: описание бизнес-процессов.
 
Теперь рассмотрим, как будет выглядеть подход к изучению требований к информационной системе с дальнейшим их отражением в Техническом задании
 
 
 

Шаги

Что и как делать

Выделяем бизнес-требование/область автоматизации Выделение в качестве требований целой области автоматизации (например, «Складские запасы») на практике используется, однако, это не самый эффективный способ детализации требований. Область автоматизации представляет собой группу требований, и рассматривать их лучше каждое в отдельности. Например, «Учет поступления материала на склад»
Детальное изучение бизнес-требования Под детальным изучением бизнес-требования понимается то, как это хочет видеть и будет использовать конечный пользователь (разумеется, в соответствии с целями проекта). В технологиях разработки программного обеспечения это часто называют «вариант использования». Таким образом, детальное изучение бизнес-требования сводится к проработке вариантов использования. Пример такого варианта приведен в приложении 2 к статье. В простейших случаях варианты использования вовсе не обязательно рисовать в виде графических схем, можно ограничиться и текстовой формулировкой. Например, требование «При вводе номенклатуры цена должна рассчитаться как цена закупки +20%» рисовать не имеет смысла. В виде диаграммы имеет смысл представлять требования, объединенные до области автоматизации, как показано в примере в приложении 2.
Моделирование требований в информационной системе Вот оно! Как Вы наверное помните, я уже обращал внимание на этот важнейший элемент в методике разработки Технических заданий. «Построй модель – получишь результат!»А что надо моделировать? Моделировать надо варианты использования, полученные на предыдущем этапе. Что должно быть на выходе моделирования? Должна получиться демонстрационная программа, в которую внесены пользовательские данные, причем желательно привычные его (пользователя) слуху, с учетом отраслевой специфики, актуальных проблем. И не просто так внесены, а должно быть понятно, откуда эти данные взялись, как рассчитались. В этом месте у читателя должны возникнуть вопросы:
  1. А что, если планируется разработка новой системы и моделировать попросту не в чем?
  2. Что, если для демонстрации не хватает функциональности, и систему надо дорабатывать?
Конечно, Вы должны столкнуться с такой ситуацией, и это нормально. Что делать? Если система совсем новая (как говорится «с нуля»), то моделировать придется по большей части на бумаге, тут Вам диаграммы вариантов использования очень помогут. Частично имеет смысл набросать некоторые экранные формы, которые предполагается разработать (прямо в той среде, в которой будет вестись разработка), т.к. рисовать их в каком–нибудь редакторе будет дольше и эта работа скучная. Если внедряется готовая система, и в ней не хватает функциональности, то ничего страшного нет, данные вносятся руками, а пользователю так и рассказывается, что после необходимых доработок должно рассчитаться так-то и так (и он это видит). Целесообразно сопроводить такую модель текстовым описанием, пусть даже кратким, чтобы пользователь мог самостоятельно попробовать поработать с моделью в свободное время. В этом же описании можно формулировать требования к доработкам.
Демонстрация информационной модели рабочей группе Полученную модель показываем Заказчику и рассказываем, как все должно работать.Демонстрацию модели лучше проводить по подсистемам, т.е. по группам требований. В случае, если выяснится, что у клиента предлагаемая схема работать не будет, надо подумать о других вариантах использования, внести изменения в модель и показать еще раз. Только если есть уверенность, что планируемая модель у данного клиента «будет жить», можно считать модель удачной.
Разработка тестов Зачем нужны тесты? То, как мы смогли реализовать требования, нужно будет проверять. Соответственно, на все ключевые участки, сложные алгоритмы и пр. тесты желательно сделать. В том числе эти тесты могут быть использованы при сдаче работ. Вовсе необязательно делать тесты на каждую функцию системы, везде должен быть здравый смысл. Если речь идет о готовой системе, то делать тест на «ввод нового элемента в справочник клиентов» будет выглядеть глупо и бесполезной тратой сил и времени. А вот если это совсем новая система, такое вполне возможно.Зачем делать тесты, если еще нет системы?Во-первых, разработчику будет понятнее, чего от него хотят добиться. Во-вторых, мы облегчаем жизнь тестировщику (кто-то ведь будет тестировать результат разработки). Вообще, тестирование это отдельная дисциплина, весьма не простая с множеством методик. На практике, как правило, все равно используются самые простые методы тестирования.
Документирование требований в виде Технического задания Собранная информация на предыдущих этапах будет являться как раз тем, что и должно войти в основу документа «Техническое задание» в раздел с требованиями.Так что остается все это грамотно оформить.
Дальнейшие действия (или их отсутствие), в зависимости от целей проекта Дольше может начаться процесс разработки, поиск партнеров для проекта, тендер и т.д., все зависит от ситуации.
 
Да, разработка Технического задания процесс трудоемкий, а значит и затратный. Но если он сделан грамотно, то избавляет Заказчика от не сбывшихся ожиданий. Исполнителю приходится делать то, что требуется Заказчику и не переделывать сто раз одно и тоже. Да и вообще, придает всему проекту прозрачность.
 

Приложение 1. Описанный бизнес-процесс в нотации EPC.

Приложение 2. Вариант использования подсистемы « Заказы»

 

141

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Boroda 90 11.04.12 13:17 Сейчас в теме
Круто! И оформлено великолепно... за одно оформление "плюс" поставить уже можно...
2. Арчибальд 2708 12.04.12 18:00 Сейчас в теме
Хорошо, когда есть бизнес-требование.
Где бы его взять только...
8. chavalah 961 13.04.12 15:00 Сейчас в теме
(2) Арчибальд, А как его может не быть? :)
Если нет требований как таковых, значит и делать ничего не надо.
Другое дело, что Заказчик не может их ясно выразить, что часто случается.
Тут есть разные мнения:
- не надо с такими Заказчиками работать. Красиво звучит, не далеко от реальности
- надо помочь им эти требования сформулировать. Я придерживаюсь второго варианта. Главное, чтобы эти требования не оказались навязанными со стороны консультанта.
3. new_user 173 12.04.12 20:03 Сейчас в теме
НАконец-то я ещё даже не читал статьи но уверен - полезной информации в ней навалом! Спасибо за статью!!!
9. chavalah 961 13.04.12 15:01 Сейчас в теме
(3) new_user, Интересное мнение:)
4. fishca 1156 12.04.12 20:09 Сейчас в теме
(0) спасибо, не останавливайся на достигнутом!
5. awk 692 12.04.12 23:03 Сейчас в теме
(0) Про семинар. Я если в Питере, то я с удовольствием поучаствую. Можно и вебинар организовать.
10. chavalah 961 13.04.12 15:02 Сейчас в теме
(5) awk,
Про семинар. Я если в Питере, то я с удовольствием поучаствую

вот, один желающий уже есть! Думаю, что к лету должно получиться.
6. romansun 189 13.04.12 00:13 Сейчас в теме
Спасибо!

Есть пара вопросов:

более приземленный - какой используете софт для рисования диаграмм?

менее приземленный - есть ли в планах что-нить рассказать про тестирование?

Было бы интересно прочитать про методики тестирования на уровне разработчиков (юнит-тестирование, 1С-ное "Сценарное тестирование", еще какие-либо варианты), про тест-кейсы (может быть примеры тест-кейсов), про схему взаимодействия разработчик-тестировщик, про приёмку работ на основании результатов тестирования заказчиком и т.п.

В принципе, информации по тестированию в интернете много, но обычно практическая её часть к 1С отношения не имеет, поэтому приходится ограничиваться теоретическими материалами :).

Да и в целом, по 1С вся инфа (сайты, литература) почти исключительно прикладного характера по поддержке типовых конфигураций, а вот каких-то материалов по организации, управлению 1С-проектами, по методикам разработки, тестирования, документирования, по выстраиванию отношения с заказчиком в рамках, опять же, 1С-проектов очень и очень мало.. Поэтому, спасибо еще раз.
11. chavalah 961 13.04.12 15:12 Сейчас в теме
(6) romansun,
более приземленный - какой используете софт для рисования диаграмм?


Существует много разного софта, но лично я остановился на самых простых и доступных инструментах.
Visio для схем, Word и Excel для всего остального.

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

менее приземленный - есть ли в планах что-нить рассказать про тестирование?

Если прочитать о чем моя рассылка, то конечно же да.
Кстати, я не делаю акцента, что используется именно 1С, я стараюсь рассматривать более общие методики, применимые независимо от платформ. Хотя сам я большую часть времени работал с 1С (да и сейчас тоже).
Что касается сценарного тестирования от 1С, давно хотел его испытать на практике. Признаться, не знаю лично ни одного специалиста кто его использовал. Вероятно, это связано с высокой трудоемкости. Когда доберусь до описания методик тестирования, обязательно об этот подумаю.
13. awk 692 13.04.12 15:59 Сейчас в теме
(11)
я остановился на самых простых и доступных инструментах
Упал под стол от смеха.

Это точно не простые и не доступные инструменты. В последнее время пользуюсь OpenOffice + Dia + Planner.
18. chavalah 961 20.04.12 08:42 Сейчас в теме
(13) awk,
Это точно не простые и не доступные инструменты. В последнее время пользуюсь OpenOffice + Dia + Planner.


я считаю, что MS Office вполне можн считать общедоступным инструментом. Вероятность, что о окажется у клиента в наличии очень высокая.А значит он сможет пользоваться результатами нне устанавливая дополнительного ПО, изучая его и пр.
Некоторые считаюи и BPWin доступным :)
20. awk 692 20.04.12 08:53 Сейчас в теме
(18) Ну у меня пиратского софта уже года четыре нет. Так что вероятность того что у меня окажется продукт с сомнительным соотношением цена/качество/(нужный мне функционал) ~= 0 :)))
17. romansun 189 18.04.12 19:20 Сейчас в теме
(11)

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


Сценарное пробовали у себя внедрять в конторе. Да, трудоёмкость ого-го. Пробовали именно бизнес-цепочки описывать тестом. Т.е., например, "принятиеОС-модернизацияОС-перемещениеОС-СписаниеОС".

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

Через полгода где-то забросили это дело. Но, возможно, в том или ином виде вернемся к этой теме - заказчик требует тестирование :)
7. ValeraEm 140 13.04.12 10:40 Сейчас в теме
Благодарю. Буду ждать продолжение.

Про вычленение/детализацию бизнес-процессов ... Сначала мы описываем существующую схему, потом формулируем как должно быть в результате автоматизации (исключение дублирования работы/участков бизнес-процессов, перераспределение полномочий, появление новых ... где мы получаем выигрыш, где наоборот потребуются дополнительные трудозатраты ... ) - нужны схемы/описания охватывающие бизнес-процессы в достаточно широкой области.
12. chavalah 961 13.04.12 15:14 Сейчас в теме
(7) ValeraEm,
Про вычленение/детализацию бизнес-процессов ... Сначала мы описываем существующую схему, потом формулируем как должно быть в результате автоматизации (исключение дублирования работы/участков бизнес-процессов, перераспределение полномочий, появление новых ... где мы получаем выигрыш, где наоборот потребуются дополнительные трудозатраты ... ) - нужны схемы/описания охватывающие бизнес-процессы в достаточно широкой области.


это мысли вслух или подразумевается какой-то вопрос?
14. ValeraEm 140 14.04.12 19:37 Сейчас в теме
(12) мысли вслух, что бывает уместно и укрупнение
15. rasswet 82 18.04.12 10:31 Сейчас в теме
подписался на Вашу рассылку. а одним файликом не выкладывали? чтобы с форматированием скачать и изучить на досуге.
19. chavalah 961 20.04.12 08:45 Сейчас в теме
(15) rasswet,
а одним файликом не выкладывали? чтобы с форматированием скачать и изучить на досуге.


Спасибо за идею, так и сделаю в ближайшее время, пусть будет архив статей в формате Word - скачал и читай. К тому же я и так все делаю сначала в нем, а потом переношу
21. rasswet 82 20.04.12 08:58 Сейчас в теме
34. romankoav 27.04.18 15:02 Сейчас в теме
(19) Надеюсь не в ворде, rtf или pdf хотя бы
16. diarki 18.04.12 15:11 Сейчас в теме
Спасибо за статью - подчеркнул многое и наконец таки упорядочил у себя в голове как это должно на самом деле выглядеть.
22. Gandalf Белый 20.04.12 10:02 Сейчас в теме
Большое спасибо! Очень интересная и позновательная статья!
Прочел первую часть и вот наконец то вторая!!!
Очень порадовали хорошии илюстрации к статье!
23. Sairys 26.04.12 18:05 Сейчас в теме
Чувак ты круто оформил статью, пока что ещё не читал, но думаю будет реально интересно
24. LaNaite 134 09.06.12 15:54 Сейчас в теме
Хороший материал, доступно изложен. Спасибо!
25. eugen91 10.06.12 14:03 Сейчас в теме
Интересная статья! Спасибо большое. Тема очень актуальная. Автор разложил все по полочкам. В общем красавец!
26. chavalah 961 19.08.12 21:53 Сейчас в теме
Как и обещал, анонсирую семинар на данную тему: про семинар
27. sergey_irk 12.11.12 14:05 Сейчас в теме
хорошая помощь в работе
28. sergey_irk 12.11.12 14:06 Сейчас в теме
да и еще бы соединть две части
29. Evgen.Ponomarenko 542 30.07.13 00:11 Сейчас в теме
Замечательное продолжение! Делай раз, делай два,делай три! Обязательно вернусь перечитать перед следующим проектом.
30. alekseies 30.07.13 11:19 Сейчас в теме
Статья интересная, прочту на досуге ............... пока нет времени ......
31. zavyzka 49 24.08.13 12:49 Сейчас в теме
Прочитал. Для себя не уяснил следующее:
- Если Приложение 2 иллюстрирует на выходе шаг "Детальное изучение бизнес-требования", то какой шаг изображён в Приложении 1.
- По каким принципам/нотациям составлялась схема из приложения 2? Мне (без подготовки) эта схема показалась почти не читабельной, в отличии от схемы из приложения 1 (EPC), где всё красиво и понятно.
За статью, спасибо.
netview1; zavyzka1; +2 Ответить
Оставьте свое сообщение

См. также

Impact mapping: чем он может быть вам полезен 29

Статья Бизнес-аналитик Руководитель проекта Стажер Нет файла Бесплатно (free) Техническое задание

Привет, коллеги! Сегодня хочу поговорить про один из инструментов Владельца продукта - Impact mapping (карта влияния). Чем он хорош и почему его стоит использовать.

26.07.2019    2893    slozhenikin_com    14       

Как проектировать отчетность 12

Статья Программист Бизнес-аналитик Пользователь Руководитель проекта Нет файла v8 УУ Бесплатно (free) Техническое задание Управление проектом Управленческие

Эта статья написана по итогам мастер-класса для руководителей проектов и аналитиков, в рамках перехода на продуктовый подход к разработке. В ней мы постарались ответить на вопрос: "Как снизить риск потери доверия к данным информационной системы со стороны топ-менеджмента, грамотно выстроив процесс проектирования и разработки отчетности?"

16.10.2018    5252    weissfeuer    2       

На чьей стороне мячик? Алгоритм определения исполнителя задачи 5

Статья no Нет файла Бесплатно (free) Техническое задание Управление бизнес-процессами (BPM)

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

14.08.2018    4926    itriot11    42       

Первый шаг к успешному проекту автоматизации 11

Статья no Нет файла Россия Бесплатно (free) Техническое задание Управление бизнес-процессами (BPM) Управление проектом

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

30.03.2018    7986    Апрель-С    1       

Должностная инструкция специалиста по 1С 59

Статья Системный администратор Программист Пользователь Руководитель проекта Нет файла Бесплатно (free) Техническое задание

Описание функциональных обязанностей для трёх категорий специалистов 1С: Администратор платформы, Программист, Администратор конфигурации (Методист).

14.12.2017    19245    Vikki-di    20       

Внедрение МСФО: план-график выполнения проекта по автоматизации МСФО 13

Статья no Нет файла БУ МСФО (GAAP) Бесплатно (free) Техническое задание Управление проектом

В данной статье будут детально рассмотрены задачи, которые предстоит выполнить в процессе запуска проекта автоматизированной подготовки отчетности МСФО

23.10.2017    7553    user743750    0       

Систематизация опыта подготовки технического задания 102

Статья no Нет файла 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free) Техническое задание

Решил «закинуть» на портал свою статью пяти-шестилетней давности. Статья писалась для внутреннего употребления в нашей компании – обобщил и систематизировал свой опыт. Думаю, кому-то она будет полезной. В процессе подготовки статьи немного отредактировал первоначальный вариант.

26.04.2017    21409    Soliton    32       

Что такое функциональное моделирование в 1С или ином программном обеспечении 4

Статья no Нет файла Бесплатно (free) Техническое задание Управление бизнес-процессами (BPM) Управление проектом

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

06.04.2017    13120    Gavrik    2       

Концепция автоматизации многопрофильного Холдинга в системе АУБ на платформе 1С 8

Статья Программист Бизнес-аналитик Пользователь Нет файла v8 Россия УУ Финансовый учет и бюджетирование (FRP) Управление холдингом (CPM) Учетная политика Бесплатно (free) Техническое задание Управление проектом Управленческий учет (прочее) Бухгалтерский учет

Это схема и обоснование концепции системы АУБ (Автоматизация Управления Бизнесом, авторская разработка) для автоматизации многопрофильного холдинга на платформе 1С. Система изначально проектировалась для многопрофильного холдинга, что определило особенность ее концепции - три уровня автоматизации. Система АУБ не является готовым решением, это определенная концепция (видение, подход) к автоматизации управленческого учета и расширяемый базис наработок реализованных в этой концепции. В конкретном проекте автоматизации, с учетом специфики управления предприятием, делается индивидуальная «функциональная сборка» с использованием готовых, существенно модифицируемых и заново разрабатываемых подсистем. Таким образом, концепция и расширяемый базис наработок системы АУБ, представляют своего рода конструктор, из которого компонуется решение в конкретном проекте, при этом заново разрабатывается лишь функционал, отражающий новую специфику. На практике концепция использовалась, например, в отраслевом решении для производства ЖБИ и добычи нерудных материалов.

02.03.2017    14775    aaw    3       

Про спагетти, или как исследовать бизнес-процессы организации 36

Статья no Нет файла Бесплатно (free) Техническое задание Управление бизнес-процессами (BPM) Управление проектом

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

23.02.2017    24189    Gavrik    9       

Как самим написать техническое задание 13

Статья no Нет файла Россия Бесплатно (free) Техническое задание

Как показывает практика, под заветной аббревиатурой «ТЗ» понимаются совершенно разные по сути, содержанию, оформлению и детализации документы. 

21.02.2017    12583    user694964_olamikyw    6       

Проектное внедрение прав доступа в системах 1С 18

Статья Системный администратор Нет файла v8::Права 1cv8.cf Бесплатно (free) Техническое задание Управление бизнес-процессами (BPM) Управление проектом

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

17.01.2017    14817    Gavrik    4       

Наблюдения, которые указывают на решимость предприятия к изменениям 45

Статья no Нет файла Бесплатно (free) Техническое задание Управление бизнес-процессами (BPM) Управление проектом

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

06.12.2016    16703    Gavrik    19       

Технические проблемы взрывного роста компании 23

Статья no Нет файла Бесплатно (free) Техническое задание Управление проектом

Хочу рассказать об очень интересном проекте, с которым мы недавно столкнулись. В этом проекте необходимо было сделать огромный объем работы за очень короткий промежуток времени, поэтому мы его условно назвали «Марафон со спринтерской скоростью».

26.09.2016    12784    R.Tsarenko    27       

Дропшиппинг или "виртуальные" склады поставщиков в 1С 19

Статья Бухгалтер Пользователь Руководитель проекта Нет файла v8 УТ10 УУ Оптовая торговля Розничная торговля Учет ТМЦ Бесплатно (free) Техническое задание

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

02.09.2016    22484    de0nis    16       

Как оценивать задачи программисту 1С 184

Статья Программист Нет файла Россия Бесплатно (free) Техническое задание

Оценивать задачу всегда сложно. У меня не всегда получается оценивать задачи адекватно (во всяком случае, не всегда моё ощущение адекватности совпадает с ощущениями других участников процесса). Именно по причине того, что вопрос для меня актуальный, хочу поделиться своими размышлениями, субъективным опытом в этом вопросе. Речь пойдет только о технической оценке.

11.08.2016    29000    SamBadi    52       

Как заставить разработки работать 34

Статья Программист Нет файла 1С:Франчайзи, автоматизация бизнеса Бесплатно (free) Техническое задание Управление проектом

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

30.03.2016    19170    liurn    26       

Предприятие требует проект автоматизации? Начните правильно! 37

Статья no Нет файла 1С:Франчайзи, автоматизация бизнеса Бесплатно (free) Техническое задание Управление проектом

На нулевом этапе мы не имеем никакого представления о порядке работ, бюджете и сроках достижения статуса «Работает как надо!». Единственное, чем мы можем обладать, — пониманием, что бизнес-процесс работает неэффективно. К сожалению, часто руководители этого не видят или не хотят видеть. Работу необходимо начинать с составления Технических требований проекта 1С автоматизации (оптимизации или бережливого производства).

23.12.2015    21176    Gavrik    5       

Большой проект: документация 60

Статья no Нет файла Windows Бесплатно (free) Техническое задание Управление проектом

Оставим за рамками нашей темы поиск потенциального клиента. Мы его нашли. Вот он - Большой клиент. Чего мы хотим? Хотим заработать. И чтобы этот Большой клиент был у нас не один. А к нам большинство таких клиентов пришли по рекомендации, а для рекомендаций положительных нужно, чтобы Большой клиент был очень доволен сотрудничеством с нами. Но и мы хотели бы быть довольны работой с ним. Вот о том, какими документами мы этого добиваемся, я и попытаюсь рассказать. *** Статья написана на основе доклада, прочитанного на Конференции IE 2013 Revolution (7-8 ноября 2013 года). Также она опубликована в журнале Инфостарта № 3

23.03.2015    18978    UR1    5       

Автоматизация работы фрилансера 46

Статья Программист Нет файла УУ Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Техническое задание Управление проектом

Появилось желание рассказать о социальном интранете - Битрикс24. Я опишу опыт внедрения и использования данного продукта от лица фрилансера 1С.

25.09.2013    23523    randa    45       

Алгоритм работы с техническим заданием заказчика 68

Статья Программист Нет файла Windows Бесплатно (free) Техническое задание

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

24.09.2013    29095    Neti    21       

Пример ТЗ и ТП на небольшую доработку 38

Статья Программист Пользователь Нет файла v8 БП2.0 Россия Windows Бесплатно (free) Техническое задание

Привожу пример технического задания и технического проекта на небольшую доработку к БП. Документы делались исходя из схемы: Обследование- ТЗ - ТП - Разработка.

14.12.2012    57641    SergAn    10       

Направления работы программиста 1С 140

Статья Программист Нет файла Бесплатно (free) Техническое задание

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

08.11.2012    40274    adhocprog    58       

Разработка технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть? 259

Статья Программист Пользователь Нет файла Россия Бесплатно (free) Техническое задание

В данной статье я попытался подробно рассмотреть проблему разработки Технических заданий. Тема стара, как и проблема. Но она до сих пор часто решается "как получится". Как сказал Генри Шоу "Мелочи тревожат нас больше всего: легче увернуться от слона, чем от мухи".

03.04.2012    69334    chavalah    55       

РД 50-34.698-90 - АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ 7

Статья Программист Пользователь Архив с данными Россия Бесплатно (free) Техническое задание

Методические указания распространяются на автоматизированные системы (АС), используемые в различных сферах деятельности (управление, исследование, проектирование и т. п.), включая их сочетание, и устанавливают требования к содержанию ВСЕХ документов, разрабатываемых при создании АС.

06.01.2010    14208    225    nnn123    1       

ГОСТ 34.602-89 (Техническое задание на создание автоматизированной системы) 18

Статья no Нет файла 1С:Франчайзи, автоматизация бизнеса Россия Производство готовой продукции (работ, услуг) Бесплатно (free) Техническое задание Управление проектом

"Листая старые страницы" времен универа нашел несколько, которыми можно поделиться, не рискуя получить по бошке. :) В общем-то, ничего нового, но думаю, многим может пригодиться.

08.06.2009    28925    Оболтус    20       

7 Граблей или история одного IT-директора 60

Статья Программист Пользователь Нет файла Россия Бесплатно (free) Техническое задание

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

08.06.2009    33651    GSoft    82       

Переход с 1С:Предприятие 7.7 на 8.0. Всегда ли это нужно? 74

Статья Программист Нет файла Россия Бесплатно (free) Техническое задание О жизни Перенос данных из 1С7.7 в 1C8.X

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

06.02.2008    26495    O-Planet    74       

Жизнь без технического задания 24

Статья Программист Нет файла Россия Бесплатно (free) Техническое задание

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

05.04.2007    21090    support    5       

ГОСТ 34.602-89. ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ 30

Статья Программист Пользователь Нет файла Россия Бесплатно (free) Техническое задание

Настоящий стандарт распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы» (далее - ТЗ на АС). Дата введения с 01.01.1990г

29.06.2005    33686    support    11       

ГОСТ 24.201-79. ТРЕБОВАНИЕ К СОДЕРЖАНИЮ ДОКУМЕНТА «ТЕХНИЧЕСКОЕ ЗАДАНИЕ» 18

Статья Программист Пользователь Нет файла Россия Бесплатно (free) Техническое задание

Постановлением Государственного комитета СССР по стандартам от 31 января 1979 г. № 383 срок введения установлен с 01.07 1980 г. Настоящий стандарт распространяется на техническую документацию на автоматизированные системы управления (АСУ) всех видов, разрабатываемые для всех уровней управления народным хозяйством (кроме общегосударственного), и устанавливает общие требования к содержанию документа «Техническое задание» (ТЗ) на создание АСУ, кроме АСУ технологическими процессами. В зависимости от вида и назначения АСУ требования, устанавливаемые в настоящем стандарте, допускается конкретизировать в нормативно-технической документации.

29.06.2005    23807    support    6       

ГОСТ 19.201-78. ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ. 23

Статья Программист Пользователь Нет файла Россия Бесплатно (free) Техническое задание

Настоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения. Стандарт полностью соответствует СТ СЭВ 1627-79.

29.06.2005    31193    support    4