Лист требований 1с это

Обновлено: 30.09.2022

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

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

Данные правила легко соблюдать даже при написании кратких пользовательских историй, если Вы создаете их в рамках проекта SCRUM / Agile.

Итак, приступим.

Для начала вы должны понимать, что же на самом деле в 90% случаев программирует программист 1C:

  • Формы ввода информации
  • Контрольные процедуры
  • Модель данных
  • Алгоритмы автоматического заполнения данных
  • Формы вывода информации

Формы ввода информации

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

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

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

Контрольные процедуры

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

В эту категорию попадают:

  • Матрицы ролевого доступа
  • Правила предоставления доступа к полям форм и данных
  • Проверки корректности заполнения данных в формах ввода
  • Процедуры сверки данных

Модель данных

Конечно, программист сделает модель данных так, как ему подскажет его опыт на текущий момент. Если программист опытный, он сделает эффективную структуру данных. А если не очень — то не очень.

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

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

Алгоритмы автоматического заполнения данных

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

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

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

Формы вывода информации

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

Нарисуйте прообраз такого отчета в Excel, желательно, с формулами и комментариями, откуда брать информацию, и вложите в ТЗ. Этого достаточно.

Так же сюда попадают формы выгрузки данных в Excel или XML и другие форматы для интеграции с другими системами.

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

Обеспечив программиста этим нехитрым набором сведений в техническом задании, вы на 90% застрахуете себя от того, что он сделает что-то не то.

P.S. Ну разве что у Вас работает не настоящий программист 1С. Может он лучше пишет на python?

Что важно для руководителя IT.
За чем нужно следить ведущему программисту.
Что будет помогать программисту.
Что сэкономит вам массу времени.
Что сделает вашу работу профессиональнее.

Идея - Константин Илларионов, Глеб Дунаев

Краткая предыстория

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

Из чего состоит эта система?

1. Комментарии в коде

2. Справочная информация

3. Цифровые обозначения отчетов/обработок

4. Добавление/изменение объектов

5. Контроль за исполнением


А теперь детально, по пунктам:

1. Комментарии в коде

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

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

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

Наше решение. Сначала прошу сравнить комментарии трех программистов (примеры из рабочей базы):

Пример 1:

Пример 2:

Пример 3 (наше решение):

Проанализируем:

1. В первом примере видно:

- где начинается комментарий и где заканчивается

- кто сделал изменения

- когда сделаны изменения (правда ошибка в дате)

2. Во втором примере видно:

- кто сделал изменения

- когда сделаны изменения

3. В третьем примере (наше решение) видно:

- где начало комментария и где он заканчивается

- кто сделал изменения

- когда сделаны изменения

Очевидно что третий пример содержит более информативный комментарий, который в полной мере выполняет свою функцию. И самое главное, для чего собственно это всё нужно, оформляя внесенные изменения подобным образом, вы сохраняете их в одном месте. В самом надежном и доступном. В базе данных. Не в файликах Word и Excel, не в сторонних программах типа Итилиума, не в головах пользователей и программистов, а ВМЕСТЕ с вашей базой данных. И даже по прошествию нескольких лет, можно легко извлечь все изменения, провести "инвентаризацию" системы и понять как сейчас она работает!

Как реализовать:

1. Все комментарии делаем однотипными и начинаем строго с символов "//начало-" ( //начало-ДГ ). Таким образом можно легко найти комментарии ВСЕХ программистов. Если нужно найти комментарии только ОДНОГО программиста - в поиске задаётся "//начало-ДГ". "ДГ" - это инициалы фамилии и имени программиста.

(Примечание: а теперь представьте ситуацию где один программист пишет "begin-end", другой пишет "начало-конец", а третий вообще рисует символы ">> <. будет очень сложно их найти.)

2. Указываем дату изменения ( 08.04.2014 .) Иногда приходится доказывать пользователям что изменения начали работать с начала апреля, а не середины мая как они думают. Или нужно понять в какой последовательности изменения появлялись.

3. Указываем кто заказывал это изменение ( Заказчик Пономаренков П. ). По прошествии времени, очень часто забывается кто и зачем придумал это, указание заказчика поможет восстановить в памяти эту задачу. А если вы совсем забыли, или не участвовали в её реализации, можно получить дополнительную информацию непосредственно у заказчика :)

4. Даём краткое название задаче ( Запись реквизита ДД_Наименование_для_сайта_прайса ). Нужно для краткого указания того что делалось, какие были изменения (1) и для идентификации задачи (2). В этом примере, по краткому названию, видно что изменения касаются определенного реквизита (а не движений по регистру накопления например). А также краткое название позволяет найти ВСЕ места, где код менялся по этой задаче (используем копирование при вставке комментария).

5. Делаем подробное описание задачи ( //Нужно чтобы при любой записи элемента, в этот реквизит . и далее). Нужно для понимания того, что и для чего делалось. Для каждого изменения делается свой комментарий (но первая строка у всех одинаковая!), если требуется сделать общее описание, то оно делается в одном месте. Например:

2. Справочная информация

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

В чём проблема. У пользователей очень часто возникают вопросы типа: "откуда берет данные отчет", "как считает эта обработка", "что проверяется в документе" и т.д. А самое интересное то, что они уже не первый раз работают с этим отчетом/ обработкой/документом. они просто забыли. или сделали вид что забыли.

Как обычно решается. Что в таких случаях делает программист? Начинает вспоминать или лезет в конфигуратор. И хорошо если это делалось недавно, или алгоритм расчета какой-то простой. А если делалось давно, например несколько месяцев назад? Сколько времени надо потратить, чтобы полностью вспомнить реализованный функционал? Иногда до нескольких часов.

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

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

Справка в программе


Справка внешней обработки


3. Цифровые обозначения отчетов/обработок

О чём пойдёт речь. Поговорим о удобстве работы с внешними отчетами и обработками.

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

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

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

Наше решение.

1. Чтобы быстро и дентифицировать отчет (или обработку) мы присваиваем ему трехзначный цифровой код, где первая цифра закреплена за программистом, а две последующие - номер по порядку. А также присвается буквенное наименование показывающее назначение отчета. И когда пользователь говорит вам: "Посмотрите пожалуйста 516 отчет". Вы моментально находите его по цифре "516" и при этом знаете что под цифрой "5" у вас разработку ведет программист Иванов, к которому можно при случае обратиться за разъяснением.

2. Для понимания того как работает отчет, существует справочная информация, она записывается в сам отчет, а также в txt-файл. Файл этот нужен для просмотра справки без открытия отчета в 1С. В справке подробно описывается: принцип работы отчета (1), откуда берет данные (2), как их выводит (3), какие настройки нужно сделать (4), обязательные для заполнения поля (5), различные нюансы (6). В 90% случаев справочная информация позволяет дать ответ пользователю не прибегая к открытию отчета в конфигураторе.

Как реализовать:

1. Название (1), синоним (2), имя на форме (3), название каталога (4) и название txt-файл а (5) всегда должны быть одинаковы. Например: DD_UT_741_Установка_доп_прав_у_пользователей. Где: DD – название компании, UT – название конфигурации, 741 – цифровой код отчета/обработки, «Установка_доп_прав_у_пользователей» - что делает данная обработка. Для удобства копирования слова разделены не пробелами, а нижними дефисами (всё название выделяется одним кликом мыши).

2. Цифровой код состоит из двух частей: 7 – цифра закрепленная за определенным программистом, 41 – номер обработки/отчета по порядку. 1С-вские обработки (измененные типовые) начинаются с «0», обработки неизвестных программистов – начинаются с «8».

3. В каждой обработке/отчете должна быть справочная информация, которая должна быть описана в txt-файле. Также создан специальный каталог для разработчиков где хранятся каталоги с отчетами/обработками. См. скриншот:

Каталог с внешними отчетами и обработками



4. Добавление/изменение объектов


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

2. Все новые объекты (и реквизиты) добавляются с префиксом. Префикс всегда один и тот же и не привязан к программисту, нас это сокращенное название фирмы - "ДД_" . Например: «ДД_Заявка_покупателя». Благодаря префиксу мы сразу понимаем какой функционал задействован, наш или типовой. Измененные и добавленные объекты добавляются в отдельную подсистему.

3. После изменения типовых объектов (или добавления новых) , таких как справочники, документы – в них добавляется справочная информация с описанием произведенных изменений. Желательно вставлять их выше типовой справки, чтобы в первую очередь читались наши изменения.

5. Контроль за исполнением

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

- названия отчетов/обработок в каталоге

- запускается глобальный поиск инициалов/ФИО программистов

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


Ну и напоследок, вернемся к началу:

Нужно ли это руководителю IT. Что будет если уйдут программисты (или пользователи) "носители знаний"? Если возникнет разбирательство кто, зачем, когда внедрил функционал? Если нужно быстро провести ревизию конфигурации? Как быстро передать информацию другим специалистам?

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

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

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

Мы для себя давно ответили на эти вопросы. Теперь ваша очередь по новой взглянуть на них :)

Когда заказчики обращаются с запросами на разработку ПО, некоторые вопросы со стороны IT-команды вызывают у них уныние.

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

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

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

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

Чек-лист проработки требований к проекту состоит из нескольких крупных блоков.


1. Функциональные требования к "успешным" сценариям

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

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

2. Функциональные требования по обработке нештатных ситуаций

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

Обычно заказчик более или менее чётко представляет, как будет работать решение при позитивных сценариях.

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

3. Нефункциональные требования

a. Производительность и мощность

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

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

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

На самом старте важно объяснить заказчику, что на бумажном самолете пассажиров не увезешь.


b. Устойчивость

Выясняем ожидания по MTBF (mean time between failures — средняя наработка на отказ) при нормальной, критичной и закритичной нагрузке. На основе этого можно выбрать наиболее пригодный технологический стек и определить, нужно ли дополнять решение таким "побочным" функционалом, как расширенный мониторинг, самовосстановление, автомасштабирование.

Анализ проводится параллельно с пунктами a, c, e, f, g.

c. Надёжность и восстанавливаемость

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

d. Безопасность

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

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

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

e. Масштабируемость

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

f. Расширяемость

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

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

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


g. Обслуживаемость

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

Важно учитывать особенности системы: некоторые требуют доступности 99,999% времени, и больше чем на 8+ часов в год их не остановишь.

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

h. Эргономика

Выясняем требования к usability, accessibility, учитываем время на освоение системы среднестатистическим пользователем, простоту выполнения типичных сценариев, встроенную документацию (help). Если эргономика прорабатывается не на стороне клиента, то у нас этим занимаются UX-эксперты.

i. Графический дизайн

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

j. Документированность

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

k. Лицензионная чистота

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

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

l. Соответствие стандартам и законодательству

Что нельзя обойти вниманием в оценке IT-проекта? ФЗ о персональных данных, обязательное лицензирование отдельных видов деятельности, фискальный учёт, расположение серверов и хранение данных в определённых юрисдикциях. Самые чувствительные в этом отношении проекты связаны с хранением и безопасностью персональных данных.

Вместо заключения

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

Масштабируемость — это способность системы адаптироваться к расширению предъявляемых требований и возрастанию объемов решаемых задач.

Работа одного прикладного решения в разных условиях

Система «1С:Предприятие 8» имеет хорошие возможности масштабирования. Она позволяет работать как в файловом варианте, так и с использованием технологии «клиент-сервер».

Масштабируемость

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

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

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

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

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

Многопользовательская работа

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

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

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

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

Механизмы оптимизации

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

Управление блокировками в транзакции

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

Выполнение на сервере

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

Кэширование данных

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

Работа встроенного языка на сервере

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

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

Аналогично командный интерфейс формируется на сервере и отображается на клиенте. Также и отчеты формируются полностью на сервере и отображаются на клиенте.

Примеры технологических параметров внедрений решения «Управление производственным предприятием»

В этом разделе публикуется развернутая информация о технологических параметрах внедрений «1C:Предприятие 8. Управление производственным предприятием» на предприятиях различного масштаба и профиля деятельности.

Цель раздела — ознакомить ИТ- специалистов с данными о реально используемом оборудовании и с примерами нагрузки реальных внедрений «1С:Предприятия 8».

Также эта информация может быть полезна и для пользователей всех программ системы «1С:Предприятие 8».

1С:Центр управления производительностью — инструмент мониторинга и анализа производительности

1С:Центр управления производительностью (1С:ЦУП) — инструмент мониторинга и анализа производительности информационных систем на платформе «1С:Предприятие 8». 1С:ЦУП предназначен для оценки производительности системы, сбора подробной технической информации об имеющихся проблемах производительности и анализа этой информации с целью дальнейшей оптимизации. Подробнее…

1С:ТестЦентр — инструмент автоматизации нагрузочных испытаний

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

Внедрение корпоративных информационных систем на платформе «1С:Предприятие 8»

Опыт внедрения прикладных решений на платформе «1С:Предприятие 8» показывает, что система позволяет решать задачи различной степени сложности — от автоматизации одного рабочего места до создания информационных систем масштаба предприятия.

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

База знаний по технологическим вопросам крупных внедрений

Фирма «1С», совместно с сертифицированными «1С:Экспертами по технологическим вопросам» и другими техническими специалистами, ведет и регулярно обновляет базу знаний по технологическим вопросам крупных внедрений.

База знаний — это постоянно пополняемый информационный ресурс, который является основным источником информации по технологическим вопросам крупных внедрений:

Реестр документов из 1С может понадобиться многим пользователям — от рядовых сотрудников до налоговых органов. В этой статье покажем, как легко и быстро в 1С сделать реестр документов и справочников, используя типовые механизмы.

Реестр документов в 1С

Сформируйте реестр документов в 1С 8.3 Бухгалтерия, используя Журнал операций ( Операции – Журнал операций ), нажав кнопку Реестр документов .

  • настройками списка в журнале операций перед нажатием кнопки Реестр документов ;
  • непосредственно в отчете Реестр документов .


Рассмотрим настройки вывода информации в самом отчете.

Реестр можно сформировать за определенный период.


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


На вкладке Оформление выберите, какая информация выводится в отчет.


Отбор информации в реестр

Разберем основные механизмы:

  • отбор по дате;
  • отбор по параметрам (например, Тип документа ).

Отбор документов по временному промежутку


Установите временной промежуток нужных документов, используя кнопку
Установить период


Отбор документов по параметрам

Для приведения информации в нужный вид используйте команду Настроить список по кнопке Еще .

В открывшемся окне перейдите на вкладку Отбор для вывода нужной информации.


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

По кнопке Еще – Настройка списка запустите форму настройки списка и перейдите на вкладку Сортировка для настройки последовательности выводимой информации.


Любой реестр в 1С

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


См. также:

Если Вы еще не подписаны:

Активировать демо-доступ бесплатно →

или

Оформить подписку на Рубрикатор →

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

Помогла статья?

Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно

Читайте также: