Выработан и регламентирован стандарт планирования и управления жизненным циклом проектов, в том числе процессы перехода между стадиями и итерациями в ходе проектов.
Разработаны регламенты ключевых процессов: разработки, сопровождения, контроля.
Сформирован комплект образцов документации, создаваемой во время жизненного цикла проекта.
Выработан ряд решений по управлению кадрами, в том числе должностные инструкции и квалификационные требования, решения по мотивации персонала и совершенствованию системы оплаты труда.
Определен ряд направлений, перспективных для последующей комплексной автоматизации с помощью системы управления предприятием.
1.Амблер С. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки. Библиотека программиста. СПб.: Питер, 2005.
2.Бек К. Экстремальное программирование. СПб.: Питер, 2002.
3.Браудэ Э. Технология разработки программного обеспечения. СПб.: Питер, 2004.
4.Даешь инжиниринг! М.: Издательство Эксмо, 2005.
5.Константайн Л., Локвуд Л. Разработка программного обеспечения. СПб.: Питер, 2004.
6.Крачтен, Филипп. Введение в Rational Unified Process. 2-е изд. М.: Издательский дом «Вильямс», 2002.
7.Кролл П., Крачтен Ф. Rational Unified Process – это легко. Руководство по RUP. М.: КУДИЦ-ОБРАЗ, 2004.
8.Липунцов Ю.П. Управление процессами. Методы управления предприятием с использованием информационных технологий. М.: Компания АйТи, 2003.
9.Хэлдман Ким. Управление проектами. М.: ДМК Пресс; Академия АйТи, 2007.
Приложение 1
Данный документ является уточняющим для документа «Техническое задание», составляется по каждой значимой функциональности и содержит более подробные описания бизнес-процессов, в т.ч. в нотации UML.
1. Основные сведения
- Название проекта, модуль
- Название функциональности
- Основания для разработки (контракт, пользователь, законодательство, и пр.)
- Необходимость распространения на другие проекты
2. Описание назначения
- Описание функциональности, ссылки на законодательство и пр.
3. Варианты использования
a. Название варианта использования, текстовое описание, UML-схема
b. Название варианта использования, текстовое описание, UML-схема
c. …
4. Диаграммы потоков данных
при необходимости
5. Диаграммы переходов состояний
при необходимости
6. Диаграммы классов
при необходимости
7. Проект пользовательского интерфейса
8. Ограничения
требования к аппаратному обеспечению, производительности и пр.
1. Основные сведения
- Номер заявки (из внутренней системы)
- Название проекта, модуль
- Основания для разработки
2. Описание заявки
- Текстовое описание содержания заявки, при необходимости – ссылки на скриншоты (для ошибок – обязательно)
3. Скриншоты
- копии экранов с выделенными и пронумерованными блоками (для ссылок в текстовом описании)
1. Основные сведения
- Номер заявки (из внутренней системы)
- Название проекта, модуль
- Название функциональности
2. Тестовые примеры
a. Тест 1
o Входные параметры: «название» = «значение»
o Последовательность действий пользователя
o Выходные параметры: «название» = «значение»
b. Тест 2
o Входные параметры: «название» = «значение»
o Последовательность действий пользователя
o Выходные параметры: «название» = «значение»
c. …
1. Основные сведения
- Номер заявки (из внутренней системы) – в случае выполнения разовой заявки
- Название проекта, модуль
- Название функциональности
2. Описание алгоритма
- Общее описание выбранных методов решения задачи
3. Реализация вариантов использования (если были указаны в «Постановке задачи»)
a. Название варианта использования, алгоритм реализации
b. …
4. Описание системных изменений
a. перечень измененных системных объектов (процедур, функций, модулей и пр.), при этом в коде указанных объектов обязательны следующие комментарии:
o дата создания, автор, назначение;
o все входные и выходные параметры, а также используемые внутри переменные должны иметь описание назначения;
o код должен быть разбит на логические блоки (при их наличии), снабженные комментариями об их назначении;
o при каждом изменении в начале после описания назначения должен вставляться комментарий с датой, автором и описанием изменения.
b. видимо, в основном для ИИС – перечень измененных классов, гридов, и пр.
5. Описание интерфейсных изменений
при изменении форм – скриншоты «что было» - «что стало» с выделением изменений
при добавлении форм – скриншоты этих форм
6. Диаграммы классов
при необходимости, видимо, в основном для ИИС
Документ «Краткое руководство» составляется в свободном стиле, при этом он должен отражать описание всех вариантов использования, реализованных для требования.
Данный документ составляется на основании «Программы и методики испытаний» либо «Тестового примера».
1. Основные сведения
- Номер заявки (из внутренней системы) – в случае выполнения разовой заявки
- Название проекта, модуль
- Название функциональности
- Дата тестирования, номер цикла тестирования
- Суммарные данные (% успешно пройденных тестов)
2. Тест 1: пройден/не пройден
- Должно быть:
o Входные параметры: «название» = «значение»
o Последовательность действий пользователя
o Выходные параметры: «название» = «значение»
- Получено:
o Выходные параметры: «название» = «значение»
- Комментарии
3. Тест 2: пройден/не пройден
- …
4. …
«Ведомость замечаний» составляется в двух случаях:
1. При проведении внутреннего тестирования на основании «Отчета о тестировании» составляется перечень замечаний, в который включаются все не пройденные тесты, а также дополнительно обнаруженные в ходе тестирования ошибки.
2. При внедрении и сопровождении системы.
Структура документа является следующей:
1. Основные сведения
- Название проекта
- Дата составления, последовательный номер, автор
- Ссылка на «Отчет о тестировании» либо период внедрения/сопровождения, за который получены указанные замечания
2. Таблица замечаний
| № п/п | Замечание | Комментарии |
| формулировка замечания | дополнительная информация, ссылка на скриншоты |
3. Скриншоты
- копии экранов с выделенными и пронумерованными блоками (для ссылок в комментариях)
1. Основные сведения
- Номер заявки (из внутренней системы) – в случае выполнения разовой заявки
- Название проекта, модуль
- Название функциональности
- Дата составления, последовательный номер
2. Таблица замечаний
| № п/п | Замечание | Дата устранения | Комментарии |
| формулировка замечания |
1. Основные сведения
- Номер обновления/дистрибутива (из внутренней системы)
- Название организации
- Дата установки, ФИО сотрудника, проводившего установку
- При установке у пользователя – ФИО пользователя, должность, комната, телефон
2. Сведения об ошибках в ходе установки
- допустимо использование скриншотов
1. Основные сведения
- Название организации, проекта
- ФИО сотрудника, проводившего обучение
2. Ведомость обучения
| № п/п | ФИО, должность пользователя | Дата обучения | Изученные разделы | Подпись пользователя |
Приложение 2
1. Общие положения
1.1. Данный документ описывает порядок сбора, обработки и хранения информации о контрактных обязательствах, а также регламент оперативного мониторинга хода исполнения контрактных обязательств ответственными исполнителями и руководителями.
1.2. Информационная поддержка указанных процессов осуществляется с использованием внутренней автоматизированной информационной системы (далее - система).
2. Ответственность и состав информации
2.1. Бухгалтерия организации является ответственной за ввод следующих данных:
- адресные данные юридических лиц;
- банковские реквизиты юридических лиц;
- сведения о подготовке счетов, счетов-фактур;
- сведения о поступлении оплаты по счетам.
2.2. Помощник генерального директора является ответственным за ввод следующих сведений:
- проекты контрактов и этапы в составе данных контрактов;
- сведения о порядке и сроках оплаты этапов контрактов;
- документы к контракту;
- сведения об отправке и получении отчетных документов по этапам работ.
2.3. Руководитель департамента/управления (либо заместитель руководителя) является ответственным за ввод следующих сведений:
- содержание работ по этапам контрактов (для последующего планирования работ начальником отдела).
2.4. Начальник отдела является ответственным за:
- планирование работ по этапам контрактов;
- контроль хода исполнения этапов;
- формирование отчета о ходе исполнения контрактных обязательств.
3. Регламент учета данных
3.1. Начальник отдела (либо по его распоряжению – заместитель начальника отдела) обязан за 15 дней (если не указано иное) до окончания срока этапа обеспечить подготовку отчет о ходе исполнения этапа с перечислением всех работ, проводившихся в рамках данного этапа.