2020-01-14
110
Данный документ констатирует факт выполнения (частичного выполнения или невыполнения) Исполнителем своих обязательств по конкретному этапу и является основанием для выплаты Заказчиком установленной суммы денег за проведенные Исполнителем работы. Акт обязательно визируется обеими сторонами.
В случае частичного выполнения или невыполнения Исполнителем своих обязательств, к Акту прилагается «Протокол испытаний» [3.5.9] с выводами о неполном соответствии выполненных работ требованиям Заказчика.
Протокол испытаний
В документе фиксируется содержание испытаний, обнаруженные ошибки выполнения программы, несоответствия функциональности программы требованиям ТЗ и другие проблемы ее эксплуатации.
Протокол служит основанием для отказа в выплате Заказчиком оговоренной суммы денег по закрываемому этапу или обоснованием ее частичной выплаты.
Рабочая документация
Рабочей документацией будем считать внутрифирменную документацию, которую готовят сотрудники фирмы. В ее состав входит:
|
|
|
· Проектная документация – ее разрабатывают аналитики и передают далее программистам, тестировщикам, и внедренцам (последними могут быть как собственные сотрудники, так и персонал Заказчика) для использования на этапах Реализации и Внедрения.
· Задания и отчеты – документы, которые готовятся и используются во время тестирования и внедрения.
Рабочая документация, в принципе, не является формой отчетности перед Заказчиком, но, тем не менее, он может потребовать ее предоставления, например, модель данных и отчеты по испытанию и внедрению (это оговаривается в Договоре).
Протоколы интервью
Документ «Протоколы интервью» содержит протоколы интервьюирования экспертов по различным аспектам предметной области (главным образом, сотрудников предприятия-заказчика), выполненные по установленной форме, а также копии некоторых из предоставленных этими экспертами документов (например, телефонный справочник сотрудников, примеры технологических схем, легенды и пр.).
Протоколы могут также оформляться как приложение к документу «Модель предметной области».
Рекомендуется следующая форма протокола:
ИНТЕРВЬЮ
| Имя: | Смирнов Валентин Петрович |
| Организация: | АК «Трансгаз» |
| Подразделение: | Управление информационных технологий |
| Должность: | Начальник управления |
| Дополнительно: | Эксперт имеет 15-летний опыт работы в данной сфере |
| Интервьюер: | Георгиев И.К. |
| Дата/Время: | 24.07.2001 |
| Тема: | Организационная структура компании |
| Тип интервью: | Обзорное |
| Место проведения: | Офис АК «Трансгаз» |
| Предоставленные документы: | Телефонный справочник сотрудников |
|
|
|
Вопрос: Какова структура компании по регионам?
Ответ: Компания имеет 4-уровневую региональную структуру. Первый уровень – Центральный офис компании (ЦО). Второй – дочерние компании (ДО). Третий – районные газопроводные управления и производственные объединения (РГУ, ПО). Четвертый – линейные службы (ЛПДС и пр.) …
2. Вопрос: …
Ответ: …
…
Резюме: (обобщающие выводы, планирование следующих тем и вопросов и пр.)
Модель предметной области
Документ состоит из следующих разделов (некоторые из них, при необходимости, могут оформляться как отдельные документы):
· «Обзор предметной области». Содержит краткое описание деятельности предприятия, его основных задач и стоящих проблем.
· «Организационная структура». Содержит следующее:
· Региональная иерархия - описание организационных уровней (центральный офис, дочерние предприятия, производственные управления, локальные службы и бригады).
· Внутренние подразделения (отделы) для каждого уровня.
· Группировка внутренних подразделений (отделов) по бизнес-процессам.
· «Объекты учета». Содержит описание производственных, технологических и других объектов, учет которых необходимо вести в системе – их состава, взаимосвязей, место в общей структуре, статистику и т.п.
· «Эксплуатируемые информационные системы». Описывает сферы деятельности предприятия, подлежащие автоматизации и реализованные в этих сферах информационные системы.
· «Бизнес-процессы». Содержит описание бизнес-процессов предметной области, потоков данных и управлений между ними, регистрируемых событий и пр. с прилагаемыми бизнес-диаграммами. Диаграммы рекомендуется выполнять в формате IDEF0, но можно использовать также средства Oracle Process Modeler, ARIS или UML. Формат описания БП можно заранее оговорить в «Договоре о проведении обследования».
· «Терминологический словарь». Рекомендуется разбивать по бизнес-процессам (или по подразделениям). Содержит не только интерпретацию термина, но и краткий обзор, т.е. является краткой «энциклопедией» по предметной области. В этом его отличие от «Глоссария» к «Спецификации на программирование», где приводятся только используемые в этой Спецификации термины и их точная интерпретация.
Обзорный документ по рынку систем
Документ «Обзор существующих на рынке систем» содержит обзор достоинств и недостатков других систем (используемых в данной предметной области или которые можно использовать), и обоснование принципиального достоинства предлагаемой системы или подходов к ее проектированию. Само название документа может быть более конкретно (и по отношению к типу системы и к предметной области), например: «Использование ГИС в нефтегазовой промышленности».
Названный документ содержит, например, следующие разделы:
· Общие представления о ГИС.
· ГИС в нефтегазовой промышленности (цели и задачи, сферы использования, структура и состав данных).
· Примеры практического использования ГИС в нефтегазовой промышленности.
· Программное обеспечение для магистральных трубопроводов.
· Программные решения корпорации ORACLE для нефтегазовой отрасли.
· Выводы (что должна делать ГИС, к чему это приведет).
Концепция
Документ «Концепция» предназначен для определения стратегии проектирования, реализации, внедрения и дальнейшего развития системы. Также можно использовать названия: «Устав проекта», «Описание проекта», «Спецификация границ проекта», «Документ по стратегии» [20].
Документ содержит следующие разделы:
· Анализ существующих на рынке систем:
· Обзор существующих на рынке систем.
· Обоснование используемых подходов (т.е. целесообразности использования этих систем или применяемых в них подходов или создания новой системы).
|
|
|
· Уточнение системных требований (на основе анализа предметной области):
· уточнение границ по задачам;
· уточнение границ по структурным подразделениям;
· анализ бизнес-процессов (выявление дополнительных функций, отсутствующих в ТЗ);
· описание регистрируемых событий;
· описание технологических объектов и особенностей их информационной структуры (паспортов);
· описание существующих информационных систем;
· уточненные требования к системе: к границам, функциям, архитектуре, регистрации событий, взаимодействию с системами, технической архитектуре.
· Направления проектирования - собственно концепция, т.е. стратегия проектирования системы (фактически, наметки ко всем будущим проектным документам).
· Концепция архитектуры (состав компонентов).
· Концепция ядра (структуры данных для реализации механизмов, названных в «Концепции архитектуры»).
· Общий план внедрения системы.
· Направления развития системы.
· Используемые стандарты.
Модель данных
Документ «Модель данных» содержит следующее:
· Архитектура базы данных (методы построения БД и методы доступа к данным и механизмы репликации данных). Этот раздел раньше был в Программной архитектуре. Впрочем, его можно сделать отдельным документом.
· Входные и выходные данные:
· Входные данные (сигналы, сообщения, документы).
· Выходные данные (сигналы, сообщения, документы).
· Описание сущностей и связей (концептуальная ER-модель):
· Определения сущностей и атрибутов концептуальной модели данных (с фрагментами ER-диаграмм).
· Описание доменов типов данных.
· ER-диаграммы концептуальной модели данных (в формате IDEF1x).
· Диаграммы таблиц физической модели данных.
· Сценарии (скрипты) для генерации базы данных.
