В жизни часто так бывает, что человек не может объяснить, что хочет от другого. А когда дело доходит до постановки задачи программисту и вовсе вызывает ступор. Есть метод в программировании, который называется «разделяй и властвуй»- дословно можно перевести как разделяй задачу на более мелкие блоки и властвуй (управляй) подзадачей. Для заказчика это метод тоже применим: если у тебя есть ряд «хотелок», то необходимо их разделить на подзадачи и формализовать (описать).
2. Зачем нужно техническое задание
Любые доработки и изменения в программе 1с должны сопровождаться техническим заданием. Во первых, этот документ решает все спорные моменты и здесь будут отражены задача и сроки ее реализации. Во вторых, так можно себя обезопасить фразой «а мы Вам говорили…». Писать или не писать ТЗ- дело каждого, но это помогает избежать недопонимания в постановке задачи.
3. Кто должен писать ТЗ
Идеально, если техническое задание для программиста будет писать заказчик, только он знает чего хочет и чего ожидает от действий программы. Но на практике это далеко не так, связано это может быть с отсутствием должных навыков или банально нехваткой времени у заказчика. Чаще всего ТЗ готовит сам программист 1С или помощник со слов заказчика. Моя любимая «история» по этому поводу, представлена ниже.
Составление ТЗ на разработку программисту 1С // Демо-занятие курса «Бизнес-аналитик 1С»
Рис1. Техническое задание -глазами участников проекта.
Поэтому над заданием для программиста должны участвовать все участники проекта: от руководителя до конечного пользователя.
4. Что должно содержать в себе техническое задание
Обязательными полями в документе должны быть:
цель- описание результата, который мы получим после внедрения доработок;
описание- краткое описание изменений, необходимые для достижения цели;
способ реализации- здесь требуется описание на техническом уровне, как будет выполнена та или иная задача, какие внутренние объекты будут затронуты: справочники, документы, регистры и т.д. Как правило, этот пункт пишут технические специалисты;
оценка стоимости- оценка трудозатрат и их стоимости;
Пример технического задания: скачать документ
Вывод
Техническое задание на доработку 1С-является важным документом взаимодействия между заказчиком и исполнителем проекта. Не стоит пренебрегать им, особенно если дело касается проектной работы. Лучше все вопросы обсудить «на берегу», что бы не получилось как в той самой истории.
Подробнее о наш возможностях здесь >
Источник: delta-don.ru
Как правильно написать ТЗ на систему или доработку системы 1С
Для того, чтобы Вам как заказчику, консультанту или методологу понять, что нужно разработчику 1С для того, чтобы доработать Вашу систему или разработать новую, нужно понимать, какими категориями информации он оперирует в ходе своей работы. Это сильно упростит программисту понимание того, что же от него хотят.
Этап проектирования и техническое задание (ТЗ) в проектах по автоматизации
В данной статье я постараюсь кратко и, при этом, достаточно полно объяснить, что Вам нужно написать в техническом задании помимо общих разделов с глоссарием, титульным листом и описанием бизнес-требований.
Данные правила легко соблюдать даже при написании кратких пользовательских историй, если Вы создаете их в рамках проекта SCRUM / Agile.
Итак, приступим.
Для начала вы должны понимать, что же на самом деле в 90% случаев программирует программист 1C:
- Формы ввода информации
- Контрольные процедуры
- Модель данных
- Алгоритмы автоматического заполнения данных
- Формы вывода информации
Формы ввода информации
Это могут быть как формы ввода в систему какой-либо информации (документы, элементы справочников, таблицы с данными), так и формы загрузки этих данных откуда-нибудь по шаблону (например, Excel или XML и другие форматы для интеграции с другими системами).
Не забывайте указывать перечень кнопок-команд, которыми пользователь должен командовать Вашей системой.
Если техническое задание не содержит продуманного Вами заранее прообраза таких форм или шаблонов, то программист будет придумывать их по своему усмотрению, а Вы будете жаловаться, что вам это неудобно в работе.
Контрольные процедуры
В бизнес-процессах эти процедуры являются предварительными контролями, чтобы вам было понятно. Т.е. это такие контроли, которые система делает сама в тот момент, когда пользователь с той или иной ролью пытается работать с системой, и выдает предупреждение или намеренно прерывает работу пользователя, не позволяя ему выполнить задуманное.
В эту категорию попадают:
- Матрицы ролевого доступа
- Правила предоставления доступа к полям форм и данных
- Проверки корректности заполнения данных в формах ввода
- Процедуры сверки данных
Модель данных
Конечно, программист сделает модель данных так, как ему подскажет его опыт на текущий момент. Если программист опытный, он сделает эффективную структуру данных. А если не очень — то не очень.
Если Вы тоже «не очень» программист, то единственное полезное, что Вы сможете в этой части написать для программиста, это будут базовые характеристики модели данных:
- Перечень бизнес-объектов, с которыми имеет дело пользователь и отношения между ними, ссылки на какие объекты в каких объектах должны храниться
- Состав полей данных (табличка в эксель) по каждому бизнес-объекту, у которого есть форма ввода
- Поддержка иерархичности — нужна или нет
- Сколько данных планируется хранить
- Регулярность ввода и изменения этих данных
- Нужно ли хранить в одном объекте несколько таблиц данных, и если да, то с какими аналитиками, будет ли какой-либо другой объект ссылаться на записи этих таблиц
- Поддержка хранения данных с историей по датам — нужна или нет
- Поддержка расчета итогов на какую-либо дату, или оборотов за период — нужна или нет
- Поддержка двойной бухгалтерской записи — нужна или нет
- Поддержка вытесняющих графиков величин во времени — нужна или нет
- Поддержка процессов взаимодействия пользователей по объекту — нужна или нет
Алгоритмы автоматического заполнения данных
Если у Вас формы ввода содержат много полей или таблиц, Ваши пользователи вряд ли захотят каждый раз заполнять все поля с чистого листа.
Здесь Вы должны продумать, какие поля или таблицы могут быть заполнены по другим полям или таблицам этого или других бизнес-объектов.
Так же, здесь Вы продумываете зависимые автоматические заполнения форм ввода в зависимости от только что измененных полей пользователем. Например, после выбора номенклатуры пользователю не надо выбирать ее основную единицу измерения, система подставит ее по-умолчанию сама.
Формы вывода информации
В эту категорию попадают отчеты и формы объектов «на просмотр» или «выбор». Понятное дело, программист не должен сам придумывать форму отчета, которую Вы представляете себе совершенно определенным образом.
Нарисуйте прообраз такого отчета в Excel, желательно, с формулами и комментариями, откуда брать информацию, и вложите в ТЗ. Этого достаточно.
Так же сюда попадают формы выгрузки данных в Excel или XML и другие форматы для интеграции с другими системами.
Формы ввода и вывода часто могут объединяться с алгоритмами заполнения данных и контрольными процедурами в функциональные интерактивные АРМы пользователей, дополняться кнопками, вызывающими определенные действия и события в системе. Тем не менее, к ним применимы те же самые принципы написания технического задания, с учетом этих особенностей.
Обеспечив программиста этим нехитрым набором сведений в техническом задании, вы на 90% застрахуете себя от того, что он сделает что-то не то.
P.S. Ну разве что у Вас работает не настоящий программист 1С. Может он лучше пишет на python?
Источник: habr.com
1С. Автосервис. Техническое задание. Техническое задание Автосерис 1С. Техническое задание на разработку программы «автодоктор» Содержание
Единственный в мире Музей Смайликов
Самая яркая достопримечательность Крыма
Скачать 22.3 Kb.
| УТВЕРЖДАЮ |
| Председатель ПЦК |
| ____________ Коновец Т.Е. |
| “_____”____________200__ |
1. Введение
1.1. Наименование программы
1.2. Назначение и область применения
2. Требования к программе
2.1. Требования к функциональным характеристикам
2.2. Требования к надежности
2.2.1. Требования к обеспечению надежного функционирования программы
2.2.2. Время восстановления после отказа
2.2.3. Отказы из-за некорректных действий пользователей системы
3. Условия эксплуатации
3.1. Климатические условия эксплуатации
3.2. Требования к квалификации и численности персонала
3.3. Требования к составу и параметрам технических средств
4. Требования к программной документации
4.1. Предварительный состав программной документации
5. Технико-экономические показатели
5.1. Экономические преимущества разработки
6. Стадии и этапы разработки
6.1. Стадии разработки
6.2. Этапы разработки
6.3. Содержание работ по этапам
7. Порядок контроля и приемки
7.1. Виды испытаний
7.2. Общие требования к приемке работы
8. Стоимость работ
1.1. Наименование программы
Наименование программы: «АвтоДоктор»
1.2. Назначение и область применения
Программа предназначена для автоматизации работы сотрудников автосервиса, содержащей следующие данные:
1.2.1. Справочник «Каталог услуг»
1.2.2. Справочник «Клиенты»
1.2.3. Справочник «Поставщики»
1.2.4. Справочник «Сотрудники»
1.2.5. Документ «Заявка на ремонт»
1.2.6. Документ «Диагностика»
1.2.7. Документ «ЗаказНаряд»
1.2.8. Документ «ЗакупкаЗапчастей»
1.2.9. Документ «ПлатёжкаЗарплата»
Программа предоставляет возможность вести учёт ремонта автомобилей, а также контролировать денежные обороты автосервиса.
2. Требования к программе
2.1. Требования к функциональным характеристикам
Программа должна обеспечивать возможность выполнения перечисленных ниже функций:
2.1.1. Печать необходимых документов, таких как:
2.1.1.1. Выплата зарплаты сотруднику
2.1.1.2. Квитанция о выполненной диагностики автомобиля
2.1.1.3. Квитанция о выполненном ремонте автомобиля
2.1.2. Контроль финансов автосервиса
2.1.3. Просмотр и печать отчётов автосервиса, таких как:
2.1.3.2. Отчёт об оборотах автосервиса за определённый период
2.1.4. Автоматическое заполнение полей при выборе клиента
2.1.5. Автоматический подсчёт стоимости ремонта.
2.2. Требования к надежности
2.2.1 Требования к обеспечению надежного функционирования программы
Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:
а) организацией бесперебойного питания технических средств;
б) использованием лицензионного программного обеспечения;
в) регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
г) регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов
2.2.2. Время восстановления после отказа
Время восстановления после отказа, вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы, не должно превышать 30-ти минут при условии соблюдения условий эксплуатации технических и программных средств.
Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств.
2.2.3. Отказы из-за некорректных действий пользователей системы
Отказы программы вследствие некорректных действий пользователя при взаимодействии с программой не должны влиять на функционирование и нормальную работу программы.
3. Условия эксплуатации
3.1. Климатические условия эксплуатации
Климатические условия эксплуатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации
3.2. Требования к квалификации и численности персонала
Минимальное количество персонала, требуемого для работы программы, должно составлять не менее одной штатной единицы — конечный пользователь программы, выполняющий функции администратора и оператора. В перечень задач, выполняемых оператором (администратором), должны входить:
а) задача поддержания работоспособности технических средств;
б) задачи установки (инсталляции) и поддержания работоспособности системных программных средств — операционной системы;
3.3. Требования к составу и параметрам технических средств
3.3.1. Программа должна функционировать на IВМ-совместимом персональном компьютере (ПЭВМ) с параметрами не ниже следующих:
3.3.1.1. Процессор с тактовой частотой 2.5 ГГц или выше;
3.3.1.2. Оперативную память объемом 2 Гб или выше;
3.3.1.3. Жесткий диск объемом 128 Гб и выше;
3.3.1.4. Видеокарта с объемом памяти 2 Гб и выше;
3.3.1.5. Операционную систему Windows 7, либо Windows 8, либо Windows 10;
4. Требования к программной документации
4.1. Предварительный состав программной документации
Состав программной документации должен включать в себя:
4.1.1. техническое задание;
4.1.2. программу и методики испытаний;
4.1.3. руководство пользователя.
5. Технико-экономические показатели
Ориентировочная экономическая эффективность не рассчитываются. Аналогия не проводится ввиду уникальности предъявляемых требований к разработке.
6. Стадии и этапы разработки
6.1. Стадии разработки
Разработка должна быть проведена в три стадии:
1. разработка технического задания;
2. рабочее проектирование;
3. внедрение.
6.2. Этапы разработки
На стадии разработки технического задания должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания.
На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:
1. разработка программы;
2. разработка программной документации;
3. испытания программы.
На стадии внедрения должен быть выполнен этап разработки подготовка и передача программы.
6.3. Содержание работ по этапам
На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:
1. постановка задачи;
2. определение и уточнение требований к техническим средствам;
3. определение требований к программе;
4. определение стадий, этапов и сроков разработки программы и документации на неё;
5. согласование и утверждение технического задания.
На этапе разработки программы должна быть выполнена работа по программированию (кодированию) и отладке программы.
На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями к составу документации.
На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:
1. разработка, согласование и утверждение, и методики испытаний;
2. проведение приемо-сдаточных испытаний;
3. корректировка программы и программной документации по результатам испытаний.
На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах Заказчика
7.1. Виды испытаний
Приемо-сдаточные испытания должны проводиться на объекте Заказчика в оговоренные сроки.
Приемо-сдаточные испытания программы должны проводиться согласно разработанной Исполнителем и согласованной Заказчиком Программы и методик испытаний.
Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний.
7.2. Общие требования к приемке работы
На основании Протокола проведения испытаний Исполнитель совместно с Заказчиком подписывает Акт приемки-сдачи программы в эксплуатацию.
И.о. директора ЦБС Т.Е. Коновец
Исп. Д.Ф.Павлов
Источник: topuch.com