Программа обследования предприятия зао «Альфа»

№ п/п	Наименование вопроса		Источник информации			Получатель информации
1	Цель функционирова-ния объекта		Руководитель предприя-тия			Руководитель проекта
2	Основные параметры объекта		Руководитель предприя-тия			Руководитель проекта
3	Организационная структура объекта		Секретарь руководителя			Зам. руководителя проекта
4	………
План-график выполнения работ
№ п/п	Наименова-ние работы	Код работы		Исполнитель	Дата начала		Длитель­ность	Дата оконча-ния
1	Определение целей и па-раметров объекта	001		Рук. проекта И.И.Иванов	01.03		2	02.03
2	Определение организа-ционной структуры предприятия	002		Зам. руководи­теля проекта П.П. Петров	03.03		1	03.03
3	……

Рис. 9.4. Документы, формируемые для обследования предприятия

В ходе обследования выполняется сбор материала, анализ требований к ИС, построение модели, исследуемой ИС, разработка документации.

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

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

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

Кроме бизнес-аналитиков в обследовании обязательно участвуют представители руководства заказчика ИС, ответственные за деятельность обследуемого объекта, поскольку обследование экономического объекта в подавляющем большинстве случаев ведет к оптимизации существующих бизнес-процессов и модификации технологий обработки информации. Эти решения не могут быть приняты и реализованы без участия руководства. Также в группу обследования входят эксперты и специалисты в предметной области исследуемого объекта и пользователи будущей ИС.

Сбор материалов обследования может выполняться различными методами, характеристика которых представлена в табл. 9.5.

Таблица 9.5 Методы сбора материалов обследования

Название метода |	Характеристика метода
Методы сбора материалов, выполняемые силами проектировщиков
Метод бесед, опро-сов и семинаров с руководителями предприятия и его подразделений	Проводится в форме обычной беседы с руководителями пред­приятий и подразделений или в форме деловой консультации-семинара со специалистами по вопросам, которые имеют общий характер и относятся к определению стратегии развития и управления предприятием
Метод опроса ис-полнителей на ра-бочих местах	Проводится в форме устной беседы, анкетирования или использования опросников для специалистов и исполнителей на рабочих местах
Метод анализа опе-раций	Заключается в декомпозиции рассматриваемого делового процесса или работы на ее составные части: задачи, расчеты, операции и элементы операций. Проводится анализ каждой части в отдельности, выявляется повторяемость отдельных операций, многократное обращение к одной и той же операции, степень их зависимости друг от друга
Метод фотографии рабочего дня ис-полнителя	Заключается в наблюдении и измерении затрат рабочего вре-мени на выполняемые работы, при этом полученные данные заносятся в специальный лист фотографии рабочего дня
Метод выбороч-ного хронометража отдельных работ	Основан на проведении измерения длительности выполнения операций с использованием специального секундомера и поз-воляет установить нормативы на выполнение отдельных опе-раций
Метод личного наблюдения	Заключается в наблюдении проектировщиком хода выполне-ния операций и применяется, если изучаемый вопрос понятен по существу и необходимо лишь уточнение деталей
Расчетный метод	Характеризуется выполнением расчетов для определения тру-доемкости и стоимости работ, подлежащих автоматизации, а также для установления объемов работ по отдельным опера-циям
Метод анализа представленного материала	Характеризуется извлечением необходимой информации из предоставленных документов на бумажных носителях и в электронной форме
Метод аналогии	Основан на отказе от детального обследования какого-либо подразделения или какой-либо работы, а также на использо-вании результатов сбора материалов тождественного объекта
Методы сбора материалов, выполняемые силами специалистов предметной области
Ведение индиви-дуальных тетра-дей-дневников	Заключается в записи исполнителя в дневнике о каждой про-веденной работе (цель, содержание, длительность) в течение определенного срока (например, месяца)
Метод самофотог-рафии рабочего дня	Заключается в регистрации исполнителем каждой проведенной работы в специальном наблюдательном листе с указанием цели, содержания и длительности в течение рабочего дня
Метод докумен-тальной инвента-ризации управлен-ческих работ	Основан на ведении специальных карт обследования на каждую работу, в которых приводятся все данные о работе и составляемых документах

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

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

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

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

Системные аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

• функции — информация о событиях и процессах, которые происходят в бизнесе;

• сущности — информация о вещах, имеющих значение для организации и о которых что-то известно.

При проведении анализа целесообразно классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации — метод MuSCoW, предложенный в 1994 г. Эта аббревиатура расшифровывается следующим образом:

• Must have — необходимые функции обеспечивают критичные для успешной работы системы возможности;

• Should have — желательные функции, т.е. при создании проекта разрабатываются те функции, которые необходимы с учетом временных и финансовых возможностей предприятия;

• Could have — возможные функции вытекают из желательных в порядке их приоритета для предприятия и также ограничиваются временными и финансовыми рамками;

• Won't have — отсутствующие функции позволяют обозначить границы проекта и набор функций, которые будут отсутствовать в системе.

На стадии анализа происходит уточнение выбранных для конечной реализации аппаратных и программных средств. Для этого могут привлекаться группы тестирования, технические специалисты. При проектировании информационной системы важно учесть и дальнейшее развитие системы, например рост объемов обрабатываемых данных, увеличение интенсивности потока запросов, изменение требований надежности информационной системы.

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

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

Построение модели исследуемой ИС является результатом проведенного сбора и анализа информации. Модель ИС может составляться для всего исследуемого объекта в целом или для его отдельных структурных подразделений.

Обычно модель деятельности исследуемого объекта создается в двух видах:

1. Модель AS-IS (модель «как есть»), которая отражает существующие в организации бизнес-процессы и их взаимодействие;

2. Модель ТО-ВЕ (модель «как должно быть» или «как будет»), которая отражает необходимые изменения в функционировании обследуемого объекта после внедрения ИС.

Разработка документации. Результаты проведения обследования объекта и анализа требований отражаются в документах — технико-экономическом обосновании (ТЭО) и техническом задании (ТЗ).

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

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

На основе ТЭО разрабатываются основные требования к будущему проекту ИС и составляется техническое задание согласно ГОСТ 34.602-89.

Техническое задание — документ, который содержит цели и обоснование проектирования, а также определяет основные требования к информационной системе и исходные данные, необходимые для ее разработки.

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

2. Этап проектирования дает ответ на вопрос: «Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?» Задачей этого этапа является исследование структуры системы и логических взаимосвязей ее элементов. Проектирование определяется как итерационный процесс получения логической модели системы вместе со строго сформулированными целями, поставленными перед нею, а также написания спецификаций физической системы, удовлетворяющей этим требованиям.

В соответствие с ГОСТ 34.601-90 выделяют эскизное и техническое проектирование.

Эскизное проектирование проводится для сложных систем, не имеющих аналогов. Здесь рассматривают варианты структурной схемы, состав и способы формирования ИО, укрупненные схемы алгоритмов обработки данных. Эскизный проект — это документированное описание предлагаемой информационной системы. Его подготовка позволяет тщательнее провести начальные этапы проектирования, представить заказчику в удобной форме намечаемые основные проектные решения. Если принято решение о разработке эскизного проекта, он должен быть согласован и утвержден заказчиком.

На этапе эскизного проектирования определяются: функции ИС; функции подсистем, их цели; состав комплексов задач и отдельных задач; концепция информационной базы, ее укрупненная структура; функции системы управления БД; состав вычислительной системы; функции и параметры основных программных средств.

Техническое проектирование — это проектирование архитектуры системы, включающее разработку структуры и интерфейсов компонентов, согласование функций и технических требований к компонентам, методам и стандартам проектирования, производство отчетных документов. На этапе технического проектирования разрабатываются решения по функциональной структуре системы, функциям персонала и организационной структуре, структуре ТС, алгоритмам решения задач и применяемым языкам, организации и ведению информационной базы, системе классификации и кодирования информации, программному обеспечению.

Технический проект оформляется в соответствии с ГОСТ 34.201 и включает в себя разделы:

• общая структура системы с указанием подсистем и общих принципов функционирования;

• перечень задач с набором параметров;

• схемы документооборота между подсистемами;

• общие принципы математического обеспечения системы;

• укрупненная структура комплекса технических средств;

• основные мероприятия по подготовке объекта к внедрению ИС (подготовка персонала, организация нормативной базы и т.д.);

• расчет экономической эффективности системы;

• укрупненный график разработки и внедрения системы.

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

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

3. Этап реализации проекта — это детальное проектирование, включающее разработку программ ИС, выбор, адаптацию и (или) привязку приобретаемых программных средств, разработку спецификаций каждого компонента, интерфейсов между компонентами, разработку требований к тестам и плана интеграции компонентов. Рабочий проект, разрабатываемый на этапе реализации, должен содержать все необходимые и достаточные сведения для обеспечения выполнения работ по вводу ИС в действие и ее эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, ее оформление, согласование и утверждение.

4. Этап тестирования проекта, как правило, выполняется в определенной последовательности. Когда генерация модулей ИС завершена, выполняют автономный тест, который преследует две основные цели:

• обнаружение отказов модуля (жестких сбоев);

• соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).

После того как автономный тест прошел успешно, группа сгенерированных модулей проходит тесты связей, которые должны отследить взаимное влияние модулей.

Далее группа модулей тестируется на надежность работы, т.е. проходят два вида тестирования:

• тестирование имитации отказов системы, которое показывает, насколько хорошо система восстанавливается после сбоев программного обеспечения, отказов аппаратного обеспечения;

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

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

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

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

• отдельного компонента информационной системы;

• группы компонентов информационной системы;

• основных модулей информационной системы;

• операционной системы;

• «жесткий» сбой (отказ питания, жестких дисков).

Эти тесты позволяют оценить качество подсистемы восстановления корректного состояния ИС и служат основным источником информации для разработки стратегий предотвращения негативных последствий сбоев при промышленной эксплуатации.

Чем сложнее проект, тем больше возникает потребность в автоматизации системы хранения ошибок. Такая автоматизация обеспечивается специализированной системой — bug tracking. Подобная система обеспечивает следующие функции:

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

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

• отчеты об актуальных ошибках по компонентам системы, интервалам времени, по группам разработчиков и разработчикам;

• информация об истории ошибки (в том числе отслеживание похожих ошибок, отслеживание повторного возникновения ошибки);

• правила доступа к ошибкам тех или иных категорий;

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

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

5. Ввод в эксплуатацию ИС представляет собой постепенный переход от существующей системы управления к автоматизированной. При этом не только повышается степень использования ТС для обработки данных, но и соответствующим образом меняются сами методы управления.

Стадия ввода в эксплуатацию включает в себя опытную эксплуатацию комплексов задач и прием их в промышленную эксплуатацию после проведения приемо-сдаточных испытаний. В промышленную эксплуатацию всю систему принимают после завершения приема в эксплуатацию всех комплексов задач.

Одной из важных особенностей ввода системы в эксплуатацию является наличие некоторого периода, в течение которого осуществляется параллельная работа существующей системы и новой ИС. В технических системах одно устройство заменяют другим чаще всего последовательно во времени. Иногда новое оборудование устанавливают на место старого — в этом случае в течение некоторого времени не работает ни новое, ни старое оборудование. Если новое вступает в строй раньше, чем прекращает работать старое, то они работают независимо друг от друга.

Однако при вводе в эксплуатацию ИС организационного типа принципиально невозможна ситуация, при которой хотя бы кратковременно не работала ни старая, ни новая система. Более того, для проверки правильности всех заложенных решений ввод в эксплуатацию новой системы осуществляется постепенно во время опытной эксплуатации следующими шагами:

1. Проверка подсистемы или комплекса задач на полном объеме реальных данных, но не в реальные сроки, необходимые для управления.

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

3. Переход на управление по результатам новой системы при сохранении в работе старой системы на случай возможных сбоев и непредвиденных ситуаций.

4. Окончательный переход на работу новой системы.

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

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

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

• Выход системы на проектную мощность — это исправление ряда мелких ошибок, оставшихся после первых двух фаз опытной эксплуатации.

Для планирования проведения всех видов испытаний разрабатывают документ «Программа и методика испытаний». Разработчик документа устанавливается в договоре или ТЗ. Программа и методика испытаний должны устанавливать необходимый и достаточный объем испытаний, обеспечивающий заданную достоверность получаемых результатов.

При проведении всех видов испытаний проверке или аттестации подвергаются:

• комплекс программных и технических средств — качество выполнения функций, возложенных на эти средства в соответствии с ТЗ;

• персонал — оценивается знание персоналом эксплуатационной документации и наличие у него навыков, необходимых для выполнения установленных функций во всех режимах функционирования ИС, согласно ТЗ;

• эксплуатационная документация, регламентирующая деятельность персонала при функционировании ИС — проверяется полнота содержащихся указаний персоналу по выполнению им функций во всех режимах функционирования ИС согласно ТЗ;

• ИС в целом — количественные и качественные характеристики выполнения функций информационной системы в соответствии с ТЗ.

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

По результатам опытной эксплуатации принимают решение о возможности предъявления частей ИС и системы в целом на приемочные испытания. Работа на стадии опытной эксплуатации завершается оформлением акта о завершении опытной эксплуатации и допуске системы к приемочным испытаниям.

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

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

На втором этапе проводят проверку взаимодействия задач в системе и выполнение требований ТЗ к системе в целом. Кроме того, приемо-сдаточные испытания включают проверку выполнения каждого требования, относящегося к интерфейсу системы и проверку работы персонала в интерактивном режиме. Проверке подлежит:

• полнота сообщений, указаний и запросов, доступных оператору, и их достаточность для эксплуатации системы;

• сложность процедур диалога, возможность работы персонала без специальной подготовки, реакция системы и ее частей на ошибки оператора, средства сервиса и т.д.

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

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

Работа завершается оформлением акта о приемке информационной системы в промышленную эксплуатацию.

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