Файл: 1 разработка сценария внедрения.pdf

104 оценки времени их выполнения и распределение членов команды разработчиков по отдельным этапам.
7. Механизмы мониторинга и контроля за ходом выполне- ния проекта. Описываются предоставляемые руководителем от- четы о ходе выполнения работ, сроки их предоставления, а также механизмы мониторинга всего проекта.
План должен регулярно пересматриваться в процессе реали- зации проекта. Одни части плана, например, график работ, изме- няются часто, другие более стабильны. Для внесения изменений в план требуется специальная организация документопотока, по- зволяющая отслеживать эти изменения.
6.2.3 Общие сведения о требованиях к информационным
системам
Проблемы, которые приходится решать специалистам в процессе создания программного обеспечения, очень сложны.
Природа этих проблем не всегда ясна, особенно если разрабаты- ваемая программная система инновационная. В частности, труд- но чѐтко описать те действия, которые должна выполнять систе- ма. Описание функциональных возможностей и ограничений, на- кладываемых на систему, называется требованиями к этой систе- ме, а сам процесс формирования, анализа, документирования и проверки этих функциональных возможностей и ограничений – разработкой требований.
Требования подразделяются на пользовательские и систем- ные. Пользовательские требования – это описание на естествен- ном языке (плюс поясняющие диаграммы) функций, выполняе- мых системой, и ограничений, накладываемых на неѐ. Системные требования – это описание особенностей системы (архитектура системы, требования к параметрам оборудования и т. д.), необхо- димых для эффективной реализации требований пользователя.
Первые шаги по разработке требований к информационным системам – анализ осуществимости.
Разработка требований – это процесс, включающий меро- приятия, необходимые для создания и утверждения документа, содержащего спецификацию системных требований. Для новых программных систем процесс разработки требований должен на-

105 чинаться с анализа осуществимости. Началом такого анализа яв- ляется общее описание системы и ее назначения, а результатом анализа – отчет, в котором должна быть четкая рекомендация, продолжать или нет процесс разработки требований проектируе- мой системы. Другими словами, анализ осуществимости должен осветить следующие вопросы.

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

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

4. Что произойдет с организацией, если система не будет введена в эксплуатацию?
5. Какие текущие проблемы существуют в организации и как новая система поможет их решить?

6. Каким образом система будет способствовать целям биз- неса?
7. Требует ли разработка системы технологии, которая до этого не использовалась в организации?
Далее необходимо определить источники информации. Это могут быть менеджеры отделов, где система будет использовать- ся, разработчики программного обеспечения, знакомые с типом будущей системы, технологи, конечные пользователи и т. д.

106
После обработки собранной информации готовится отчет по анализу осуществимости создания системы. В нем должны быть даны рекомендации относительно продолжения разработки сис- темы. Могут быть предложены изменения бюджета и графика ра- бот по созданию системы или предъявлены более высокие требо- вания к системе.
6.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ
Данное практическое занятие предполагает выполнение следующих этапов:
– изучить методические указания;
– составить подробное описание информационной систе- мы;
– провести анализ осуществимости;
– распределить роли в группе;
– заполнить разделы плана;
– ответить на контрольные вопросы.
6.4 КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Перечислите сложности при управлении программными проектами.

2. В чем заключается этап написания предложений?
3. Поясните этап мониторинг проекта.

4. Для чего используется неформальный мониторинг?
5. Поясните анализ осуществимости.

6. Что понимается под пользовательскими требованиями?
7. Что понимается под системными требованиями?

107 7 РАЗРАБОТКА ПЕРЕЧНЯ ОБУЧАЮЩЕЙ ДОКУМЕНТАЦИИ
НА ИНФОРМАЦИОННУЮ СИСТЕМУ
7.1 ЦЕЛЬ РАБОТЫ
Цель работы – изучить вопросы, которые охватывает план документирования и перечень необходимой документации.
7.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ
Начальным этапом проекта внедрения компьютерно- интегрированных систем (КИС) является подготовка. В контексте данной фазы формулируются цели и задачи, а также готовятся шаблоны документов и укрупненный план-график проекта.
Основным документом этапа служит устав, определяющий цели проекта, а также содержащий его функциональный, органи- зационный, технический и методологический объемы. Кроме то- го, документ описывает участников проекта и задает порядок со- гласования соответствующей документации.
Подготавливается концепция обучения проектной группы, включающая предлагаемый подход к обучению команды внедре- ния КИС заказчика. Шаблоны документов, используемые для подготовки документации на последующих этапах проекта, фор- мируются здесь же.
Документатор должен подготовить план документирования, в котором должны быть определены задания, выполняемые при создании конкретной документации. Данный план должен быть официально согласован заказчиком, что подтверждает полный учет в этом плане всех требований заказчика.
Обычно план документирования должен охватывать весь комплект документации, например руководства пользователя, диалоговую документацию, справочные тексты и краткие спра- вочные карты.
В плане документирования должны быть четко описаны об- ласть применения и ограничения по использованию планируемой документации, а также основные решения по анализу и проекти- рованию этой документации. В плане также должны быть опре-

108 делены процессы и проверки, выполняемые при разработке до- кументации.
План документирования должен охватывать следующие во- просы (но не ограничиваться ими):
1) Рабочее наименование, назначение, область применения и ограничения по использованию планируемой документации.
2) Спецификацию стиля.
3) Определение аудитории пользователей.
4) Обоснование причин использования документации дан- ной аудиторией и ее целевое назначение.
5) Содержание (план-проспект) документации, с оценкой ее постраничного объема, и соответствующие уточнения для других машинных носителей документации.
6) Номенклатуру поставки – число печатных копий, нали- чие электронных копий, форматы дисков и файлов (включая вер- сии программных средств) и откуда они могут быть поставлены.
7) Установление собственника авторских прав на докумен- тацию и любых других прав собственности. Вопрос прав собст- венности является сложным. Во всех договорах на документацию должны быть указаны собственники соответствующих прав. При этом может быть указана последующая возможность передачи авторских прав от документатора к заказчику. Передача автор- ских прав целесообразна при определении места и способа тира- жирования документации.
8) Обеспечение перевода документации на другие языки.
9) Уровни (грифы) секретности и конфиденциальности (при необходимости).
10) Процедуры и проверки, могущие влиять на процесс разработки документации, включая, при необходимости, хране- ние, поиск, резервирование, передачу и оценку качества.
11) Методы и средства производства (тиражирования) и используемые версии данных средств.
12) Структуру коллектива разработчиков документации и, возможно, плана выбора данной структуры. Конкретные лица привлекаются на различных этапах написания и производства
(тиражирования) документации в зависимости от уровня своего опыта и знаний. Например, может быть необходимым хорошее знание автором документируемой системы и опыт в написании

109 документации; для редактора может потребоваться только опыт редактирования, но не знание системы; от компоновщика (офор- мителя) может не требоваться других знаний кроме знания средств оформления.
13) Взаимосвязи (подчиненности) проекта.
14) Почасовую загрузку и зарплату персонала.
15) Требования к проектным ресурсам, включая информа- ционные и прочие ресурсы, представляемые заказчиком, и сро- кам их представления.
16) Метод передачи документатору информации об изме- нениях программного средства в процессе его разработки.
17) Планы контроля изменений и сопровождения докумен- тации.
18) Планы проверки документации после ее создания.
19) Календарное планирование (графики) по контрольным точкам (milestones), включая (при необходимости):
– утверждение плана документирования,
– подготовку, проверку и корректировку проекта каждого документа,
– тестирование на практичность,
– подготовку оригиналов фотошаблонов,
– распечатку, переплетение и распространение документа- ции.
При необходимости каждый из пунктов плана должен быть описан для каждого элемента документации.
Полезно также включить в план документирования образцы аналогичной документации, выпускаемой документатором или другими сторонами, чтобы показать ее стили и компоновку.
План документирования должен быть подготовлен и утвер- жден до начала разработки документации, чтобы гарантировать согласование всеми сторонами поставленных задач и используе- мых методов. После утверждения плана он должен быть доведен до всех заинтересованных сторон, включая персонал разработчи- ков документации, а также заказчика и субподрядчиков (напри- мер, печатников, наборщиков, переводчиков).
План документирования должен включать определение ау- дитории(й) пользователей документации, уровня образования, способностей, подготовки, опыта данных пользователей и других

110 характеристик, связанных с содержанием, структурой и исполь- зованием документации.
Обычно имеется ряд различных групп пользователей, пре- следующих различные цели при использовании конкретной до- кументации. Каждый тип пользователей, включая их характери- стики и задачи, решаемые ими при помощи документации, дол- жен быть определен отдельно.
Данные об определении аудитории пользователей могут быть получены из:
– результатов изучения аудитории, проведенного заказчи- ком или документатором;
– описаний, представляемых заказчиком;
– определений аудитории, полученных из других источни- ков.
По возможности персонал разработчиков документации должен организовать встречи с типовыми пользователями в их рабочей обстановке и обследовать их работу.
Создание такого плана требует выполнения следующих за- дач:
– идентификация конечных пользователей и определение с помощью матрицы Job Role необходимого каждому отдельному пользователю объема обучения;
– определение требований к пользовательской документа- ции;
– распределение ответственности за подготовку материа- лов и составление графика.
Все эти действия выполняются на основе плана документа- ции, подготовленного на этапе концептуального планирования.
Для облегчения этой задачи в SAP предусмотрены шаблоны процедур для конечных пользователей, которые подготавливают- ся на основе более шестисот заранее стандартных ВРР (см. раздел
«Подготовка плана обучения пользователей и пользовательской документации»).
Обучение конечных пользователей имеет огромное значение для успешного запуска системы, причем деятельность по подго- товке обучения в первую очередь связана с созданием пользова- тельской документации, для чего необходимо выполнить сле- дующие задачи:

111
– идентифицировать методику обучения и необходимые материалы;
– распределить ответственность и утвердить график со- ставления обучающих материалов;
– распределить ответственность и утвердить график со- ставления материалов для инструкторов, которые будут прово- дить обучение;
– распределить ответственность и утвердить график прове- дения обучения;
– организовать оповещение конечных пользователей об обучении и их регистрация.
Обучение в зависимости будущих обязанностей пользовате- ля можно организовать, используя Информационную базу дан- ных (Information Database, InfoDB), в которой содержится список курсов и соответствующие роли пользователей системы.
Подготовка материалов для обучения включает в себя соз- дание обучающих слайдов, распечатку экранов, подготовку уп- ражнений и буклетов и т. д.
Для конечных пользователей необходимо подготовить пол- ный комплект дополнительных материалов, подсказок, сборни- ков часто задаваемых вопросов и т. д.
7.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ
Данное практическое занятие предполагает выполнение следующих этапов:
– изучить методические указания;
– ответить на контрольные вопросы.
7.4 КОНТРОЛЬНЫЕ ВОПРОСЫ

1. Что включает план документации для конечных пользо- вателей?
2. Какие задачи решаются при создании пользовательской документации?
3. Типовые этапы реализации проектов по внедрению ИС.

4. Что могут включать материалы для обучения?
5. Какие вопросы должен охватывать план документирова- ния?