Регламент разработки и внедрения программных продуктов (для собственного ИТ отдела предприятия)

07.06.12

Бизнес-анализ

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

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

 

1. Общие положения

 

1.1. Настоящий регламент имеет целью определить правила организации и проведения работ по разработке и внедрению собственных программных продуктов в ОАО «ХХХ» (далее – Предприятие).

1.2. Основными задачами настоящего регламента в рамках регулирования деятельности по разработке и внедрению программных продуктов являются:

– определение сферы применения;

– описание системы, включая процессы, участников и схему их взаимодействия;

– определение требований к процедурам деятельности;

– разграничение прав и обязанностей участников деятельности;

– закрепление ответственности участников деятельности.

1.3. Определения:

1.3.1. АИС – Информационная система, созданная для решения задач автоматизации деятельности и бизнес-процессов Предприятия, в рамках которой осуществляется внедрение Программного продукта.

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

1.3.3. Проект – задача на разработку и внедрение Программного продукта, регулируемая Техническим заданием.

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

– служебные записки – основания разработки (изменения) Проекта;

– план внедрения Проекта;

– технические задания;

– протоколы тестирования Программного продукта;

– акт внедрения Программного продукта;

– иные документы, регулирующие процесс внедрения конкретного проекта.

1.3.5. Техническое задание – основной документ Проекта, содержащий описание задачи, цель и способы ее внедрения, а также требования к Программному продукту и АИС.

1.4. Деятельность Предприятия по разработке и внедрению программных продуктов регулируется:

– настоящим регламентом;

– утвержденными Техническими заданиями;

– другими нормативными документами Предприятия.

1.5. Участниками деятельности по разработке и внедрению программных продуктов являются:

– лица, заинтересованные в создании (изменении) функционала АИС;

– руководитель деятельности по разработке и внедрению программных продуктов;

– руководители проектов;

– исполнители работ;

– администраторы АИС.

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

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

1.5.3. Администратор АИС – лицо, ответственное за функционирование действующей АИС. Администратор АИС единолично несет ответственность за АИС и в рамках настоящего регламента выполняет следующие задачи:

– при необходимости обеспечивает руководителя проекта и исполнителей работ копиями АИС для разработки Программного продукта;

– интегрирует готовый Программный продукт в АИС.

1.6. Разработка и внедрение программных продуктов включает следующие процедуры:

1) постановка задачи и запуск Проекта;

2) написание и утверждение Технического задания;

3) выполнение работ по проектированию Программного продукта;

4) окончательное тестирование и приемка Программного продукта;

5) внедрение Программного продукта в АИС.

 

2. Постановка задачи и запуск проекта

 

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

– АИС, которую необходимо создать (модифицировать);

– деятельность (процессы), подлежащие автоматизации;

– требования к функционалу АИС;

– срочность реализации с указанием обоснования реализации Проекта в срочном порядке;

– другую информацию, способную повлиять на разрабатываемый Программный продукт или АИС.

Если служебная записка не удовлетворяет требованиям настоящего пункта, то процедуры, предусмотренные настоящим регламентом, к ней не применяются.

2.2. Сферой действия настоящего регламента является автоматизация следующих задач:

– проекты на разработку и внедрение новых АИС;

– проекты на разработку и внедрение Программных продуктов, существенно изменяющих (дополняющих) функционал действующих АИС.

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

2.3. Основаниями для признания существенными изменений (дополнений) функционала действующих АИС являются следующие условия:

– важность Проекта (о потребностях в реализации Проекта в письменной форме заявило несколько лиц, заинтересованные в создании (изменении) функционала АИС, из различных подразделений Предприятия);

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

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

2.5. Если Проект не попадает в сферу применения настоящего регламента, то принятие решений о реализации Проекта настоящим регламентом не регулируется.

2.6. План внедрения проекта должен содержать, как минимум, следующую информацию:

– перечень работ;

– ответственных за выполнение работ;

– при необходимости исполнителей работ;

– оценки объема работ в часах;

– нормативные сроки завершения работ.

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

2.7. Руководитель проекта выполняет следующие функции:

– анализ возможностей и способов внедрения Проекта;

– организация процессов, необходимых для внедрения Проекта;

– координация действий участников внедрения Проекта;

– проведение консультаций с участниками внедрения для решения спорных вопросов;

– назначение исполнителей работ по Проекту;

– тестирование Программного продукта.

 

3. Техническое задание

 

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

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

3.3. Техническое задание должно содержать в себе, как минимум, следующую информацию:

– цель автоматизации;

– наименование и краткую характеристику АИС;

– назначение и функции предмета разработки;

– требования к предмету разработки (Программному продукту), в т.ч. к функциональным характеристикам, надежности, справочной информации и др.;

– требования к АИС, в т.ч. технические требования (аппаратные и системные требования и т.п.), условия работы (требования к квалификации пользователей, порядок обслуживания и т.п.) и др.;

– требования к информационной и программной совместимости;

– требования к защите информации отдельно для АИС и предмета разработки;

– требования к первичному заполнению информационной базы (по необходимости);

– порядок выполнения работ по Проекту с указанием содержания работ и оценки объема работ (в часах);

– особые требования к проведению приемки работ (по необходимости);

– условия взаимодействия с другими проектами (по необходимости);

– другая необходимая информация.

3.4. Под требованиями к предмету разработки (Программному продукту) понимаются условия, выполнение которых необходимо для достижения целей автоматизации и предполагает выполнение работ в рамках данного Проекта.

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

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

– перечень автоматизируемых операций;

– создаваемые (модифицируемые) объекты АИС, их состав и правила функционирования;

– методология автоматизации для каждой операции и создаваемого (модифицируемого) объекта АИС;

– принципы организации работы пользователей в АИС, связанные с внедрением Программного продукта.

3.7. Требования к надежности предмета разработки (Программного продукта) должны содержать информацию о принципах организации контроля и об автоматизированных методах предотвращения, выявления и устранения ошибок в АИС, закладываемые в предмет разработки (Программный продукт).

3.8. Требования к справочной информации должны содержать принципы организации справки к предмету разработки (Программному продукту), в т.ч.:

– виды планируемых пользовательских инструкций (руководств);

– планирование встроенной справки для объектов АИС, создаваемых (модифицируемых) предметом разработки (Программным продуктом);

– планирование встроенной справки к АИС в целом.

3.9. Требования к информационной и программной совместимости должны содержать, как минимум, следующую информацию:

– поддерживаемые форматы загрузки и выгрузки данных (требования к выгружаемым и загружаемым файлам);

– правила проведения загрузки и выгрузки данных (поля, отбор, группировка, сортировка таблиц при загрузке и выгрузке);

– единицы измерения, методики расчета числовых показателей и др.

3.10. Требования к защите информации включают следующее:

– правила ограничения доступа к данным для пользователей АИС;

– использование средств криптографической защиты;

– использование защищенных каналов связи для АИС и др.

3.11. Требования к первичному заполнению информационной базы должны содержать указания на информацию, которая подлежат заполнению в автоматизированном режиме до интеграции предмета разработки в АИС. Если первичное заполнение информационной базы проводится на основании нормативных документов, то Техническое задание должно содержать ссылки на такие документы, в остальных случаях информация для ввода в АИС должна прилагаться к Техническому заданию.

3.12. Техническое задание подписывают следующие лица:

– разработчик технического задания (автор);

– руководитель проекта (требуется согласование, если руководитель проекта не является разработчиком технического задания);

– исполнитель (требуется ознакомление, если исполнитель не является руководителем проекта или разработчиком технического задания);

– руководитель деятельности по разработке и внедрению программных продуктов (утверждение).

 

4. Порядок выполнения работ и внедрения программных продуктов

 

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

4.2. В процессе выполнения работ по разработке Программного продукта необходимо соблюдать требования к разработке и руководствоваться следующими принципами:

– эффективности (экономия рабочего времени пользователей в результате выполнения работ должна существенно превосходить затраты времени разработчика);

– оптимальности (информация в информационной базе должна храниться и структурироваться таким образом, чтобы минимизировать вычислительные ресурсы, требуемые для ее использования);

– быстродействия (программный код процедур и функций на встроенном языке, а также код на языке запросов, должны строиться таким образом, чтобы минимизировать в первую очередь затраты рабочего времени пользователей АИС, во вторую очередь время выполнения автоматизированных операций, в третью очередь сетевой трафик, в четвертую очередь потребление оперативной памяти, в пятую очередь потребление памяти жесткого диска);

– исполнительности (нарушения утвержденного Технического задания допускаются в порядке исключения, если приводят к улучшению характеристик предмета разработки (Программного продукта) относительно запланированных);

– эргономичности (пользовательский интерфейс и диалоговые формы должны быть интуитивно понятными и удобными для пользователя).

4.3. Исполнитель работ по техническому заданию готовит справочную информацию к предмету разработки (Программному продукту), если этого требует Техническое задание. Справочная информация должна включать следующее:

– описание предмета разработки (Программного продукта) и всех его объектов;

– инструкции (руководства) пользователей АИС по эксплуатации предмета разработки (Программного продукта);

– историю изменений Программного продукта от версии к версии.

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

4.4. Исполнители работ обязаны проводить отладку предмета разработки (Программного продукта), с целью минимизации ошибок, и несут ответственность за соблюдение требований соответствующего Технического задания и настоящего регламента.

4.5. Тестирование, предшествующее приемке Программного продукта, проводит руководитель проекта, который проверяет:

– выполнение требований технических заданий;

– соблюдение общих принципов и требований к разработке, вытекающих из настоящего регламента;

– отсутствие ошибок в работе Программного продукта.

4.6. По итогам проведения тестирования руководитель проекта принимает одно из следующих решений:

– Программный продукт соответствует предъявляемым требованиям и готов к внедрению в АИС (в этом случае следующей процедурой является приемка Программного продукта);

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

– Программный продукт не соответствует предъявляемым требованиям и возвращается на доработку.

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

– заключение о соответствии Программного продукта предъявляемым требованиям;

– наличие необходимости в доработке Программного продукта;

– перечень необходимых исправлений с указанием нарушенных требований (при наличии нарушений);

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

4.8. После завершения процедуры тестирования проводится приемка Программного продукта, предшествующая его внедрению в АИС. Приемку осуществляет приемная комиссия (как минимум, из трех человек), состав которой для каждого проекта определяет руководитель деятельности по разработке и внедрению программных продуктов.

4.9. В приемную комиссию могут включаться следующие лица:

– руководитель деятельности по разработке и внедрению программных продуктов;

– лица, заинтересованные во внедрении Программного продукта;

– представители руководства Предприятия.

Руководитель проекта и исполнители работ по проекту в состав приемной комиссии включаться не могут.

4.10. Приемная комиссия определяет пригодность Программного продукта для внедрения в АИС и соответствие функционала Программного продукта предъявляемым требованиям. По результатам приемки приемная комиссия принимает одно из следующих решений:

– Программный продукт допускается к использованию;

– Программный продукт не допускается к использованию.

4.11. Если Программный продукт не допускается к использованию в АИС, то он возвращается на доработку, что отражается в протоколе тестирования, который дополнительно подписывает руководитель деятельности по разработке и внедрению программных продуктов. Если Программный продукт допускается к использованию в АИС, то составляется акт внедрения, который подписывает руководитель проекта, ответственный за внедрение, и члены приемной комиссии, ответственные за приемку. Акт внедрения составляется в двух экземплярах: один экземпляр включается в Документацию проекта, а второй отдается руководителю проекта.

4.12. Интеграция Программного продукта в работающую АИС до завершения процедуры приемки и составления акта внедрения не допускается. По окончании процедуры приемки внедрение Программного продукта в АИС осуществляет администратор АИС.

4.13. Документация проекта сшивается и сдается на ответственное хранение в отдел информационных технологий аппарата управления Предприятия. Хранение документации проекта осуществляется до завершения использования Программного продукта в деятельности Предприятия.

 

См. также

Как реорганизовать работу проектного департамента, чтобы быть №1

Внедрение изменений Бесплатно (free)

Методики быстрореагирующего производства и QRM-ячейки применимы не только к станкам, но и к проектным командам. О том, как за счет разделения проектного офиса на многофункциональные QRM-ячейки обеспечить равномерную загрузку работу сотрудников, вырасти в два раза и существенно повысить лояльность заказчиков и коллектива, пойдет речь в статье.

14.02.2024    553    0    user1270271    2    

7

Управление ожиданиями на проекте

Работа с заинтересованными сторонами Бесплатно (free)

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

08.02.2024    451    0    izybaevda    0    

5

Как внедрить 1С:ERP за 2 года и не сойти с ума

Анализ предметной области Анализ потребностей и поиск решений Внедрение изменений Бесплатно (free)

Для руководителей подразделений новые проекты вызывают желание получить максимальный эффект от реализации идей, а также опасения, верно ли выбран ориентир нововведений. О том, как справиться с трудностями, дойти до цели и внедрить 1С:ERP на производственном предприятии, ежедневно выпускающем десятки тысяч единиц готовой продукции, расскажем в статье.

30.01.2024    6695    0    user1578851    16    

16

Свободное программное обеспечение в крупной компании – миф или реальность? Как мы переводили 2500 пользователей на Linux

Внедрение изменений Бесплатно (free)

Переход на свободное программное обеспечение – серьезное испытание и для бизнес-пользователей, и для ИТ-подразделения. Нужно учесть много факторов, найти компромиссы и поменять привычки. О «пяти стадиях принятия неизбежного» и успешном преодолении трудностей при переводе ИТ-инфраструктуры автодилерских центров на Linux расскажем в статье.

29.01.2024    2415    0    user1063453    2    

5

Зачем нужны аналитики на проектах автоматизации

Анализ потребностей и поиск решений Бесплатно (free)

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

18.01.2024    1589    0    user1754524    19    

12

Радио "Аналитик", 7 выпуск 2 сезона. Про работу аналитика с бизнесом и повышение бизнес-компетенций с Константином Семёновым

Анализ предметной области Работа с заинтересованными сторонами Анализ потребностей и поиск решений

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

28.11.2023    413    0    Radio_Analyst    0    

2

Радио "Аналитик", 4 выпуск 2 сезона. Про решение проблем с Анастасией Московкиной

Анализ потребностей и поиск решений

В четвертом выпуске второго сезона подкаста Радио “Аналитик“ поговорили, как анализировать и приоритизировать проблемы, как работать с неопределенностью и решениями, которые приняли без нас.

17.10.2023    357    0    Radio_Analyst    0    

2
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. tango 506 07.06.12 10:29 Сейчас в теме
многа букав, нечитабельно, вода, документ в себе
не ставлю минус за энтузиазм
ОАО ХХХ - далее ОАО (начнем с малого :))
**
с разделом не угадал, здесь нет о программировании, это - в раздел проектов
2. serega3333 07.06.12 14:05 Сейчас в теме
жалко ваш ИТ-отдел, раз вы такими регламентами занимаетесь
jobkostya1c_ERP; +1 Ответить
3. mosAdm 135 09.06.12 11:57 Сейчас в теме
Плюс за новацию. Кому из нас не приходиться писать всякую ... тот не в теме. Если на ИС будет отдельная рубрика по таким публикациям инструкциям пользователя, регламентам, положениям, она ИМХО будет пользоваться популярностью.
shastin87; E_Babaylova; +2 Ответить
4. mpei198 12.06.12 11:22 Сейчас в теме
5. ander_ 13.06.12 06:39 Сейчас в теме
ИМХО как-то это все оторвано от жизни. Абстрактно слишком.
И еще "глаз зацепился" за обязанности руководителя заниматься тестированием.
Помоему что-то здесь не так.
6. proger1c81 18.06.12 01:02 Сейчас в теме
мне этот регламент разработки очень полезен. Хотя внедрял до этого проекты и без всякого регламента, но клиенты бывают разные, может и пригодиться. Когда никогда таким регламентом ткнуть в лицо клиенту, что и у него имеют обязанности.
7. vano-ekt 123 11.06.13 12:46 Сейчас в теме
8. pt_olga 61 12.08.13 17:49 Сейчас в теме
"АИС – Информационная система"
а вот и нет)) Правильно: "ИС – Информационная система"

Вообще в документе на мой взгляд смешаны и "кони и люди" из немного разных регламентов и уровней автоматизации.

"Проект – задача на разработку и внедрение Программного продукта, регулируемая Техническим заданием."
Это как проект может регулироваться ТЗ?
Проект может состоять из нескольких этапов (вех), в каждом этапе может быть много задач, а под каждую задачу составляется отдельное ТЗ.

"1.3.4. Документация проекта – пакет документов, непосредственно связанных с разработкой и внедрением Программного продукта, включающий в себя следующее:
– служебные записки – основания разработки (изменения) Проекта;
– план внедрения Проекта;
– технические задания;
– протоколы тестирования Программного продукта;
– акт внедрения Программного продукта;
– иные документы, регулирующие процесс внедрения конкретного проекта."

А почему не Инициативного предложение, Устав, Бюджет, План?

изобретение велосипедов как правило экономически не оправдано, когда существуют готовые методики и правила.
Разве что в Вашей компании приняты ("исторически сложились") именно такие подходы к проектным работам, а Вы их героически попытались описать. :)
Тогда + за усердие))
9. acuta 29.09.13 21:20 Сейчас в теме
Регламент действительно сырой. Но сам факт его наличия, говорит о том, что товарищи задумались о систематизации своей работы. Т.к. программист это не свободный художник, который может писать только по вдохновению и по своему видению... Программист, это скорее строитель, который строит в рамках проекта и по строгим регламентам.
ivangrant; +1 Ответить
10. jobkostya1c_ERP 100 10.01.16 16:52 Сейчас в теме
Проверял я это дело на себе (причем буквально). Мягко говоря "регламент есть, а делать некому".
Прикрепленные файлы:
11. zubr74 11.04.18 13:50 Сейчас в теме
Хорошие регламенты можно посмотреть здесь http://templatedoc.ru/polozheniya-i-reglamenty-it

Отличные образцы; можно сразу брать за основу.
12. kudlach 12 11.04.18 14:00 Сейчас в теме
(11) вот только там они все платные без возможности превью и "тест-драйва" ))
Отличный вариант для лохотрона - повесить пустые ценники.
13. zubr74 11.04.18 17:13 Сейчас в теме
Превью есть в виде png файлов. Какой смысл выкладывать превью документа в 4-6 страниц?!
14. Miracle180882 7 04.01.20 08:36 Сейчас в теме
Добрый день, коллеги! Пункт 3.1, стоит обозначить критерий выполнения данного пункта или исключить, так как есть 3.12 приём тз где подписанты могут оценить в том числе эффективность предлагаемой реализации.
Оставьте свое сообщение