Аналитическая часть (анализ предметной области)
2.1 Описание предприятия, являющегося объектом исследования ВКР
В качестве предметной области (объекта автоматизации или информатизации) может выступать:
- предприятие (организация, учреждение, фирма, объединение и т.п.);
- подразделение предприятия;
- отдельный вид деятельности (бизнес-процесс).
Организационно-экономическая характеристика предметной области должна включать:
- наименование, организационную форму, юридический статус и миссию предприятия;
- его организационную структуру (с указанием общей численности работающих);
- краткую характеристику технико-экономических аспектов подразделений.
Миссия организации.
Под миссией предприятия понимается основная общая цель или задача предприятия, четко выраженная причина его существования. Она обобщает и унифицирует такие понятия, как предназначение, стратегическая установка, кредо, политика, бизнес-идея и др. Миссия объединяет задачу и коренную причину, оправдывающую существование данного конкретного предприятия, она позволяет потребителю отличить одно предприятие от другого, занимающегося аналогичной деятельностью.
Миссия должна удовлетворять основным требованиям:
- указывать на сущность и назначение предприятия, давать представление об основных его свойствах, причине возникновения и смысле существования;
- говорить о перспективности предприятия, какими видами деятельности оно собирается заниматься и каков долгосрочный курс;
- формулировать идеи и понятия, лежащие в основе бизнеса, определяющие группы покупателей, их потребности;
- включать понятие миссии-ориентации, уточняющее характер поведения предприятия и раскрывающее систему ценностей, которых придерживается руководство и персонал;
- информировать общество о политических установках.
В ВКР рекомендуется приводить фактическую миссию предприятия-объекта из его официальных документов. В случае отсутствия или недоступности таковой, рекомендуется предложить свой вариант миссии.
Организационная структура.
Организационная структура – это распределение ответственности, полномочий и взаимоотношений между работниками предприятия.
Как правило, наилучшим способом отображения организационной структуры является организационная диаграмма в виде многоуровневого дерева (графа). Рекомендуется использовать инструментарий MS Visio, График Студио Лайт.
Технико-экономические аспекты подразделений.
Технико-экономическими аспектами являются:
- основные задачи;
- тип производства (услуг);
- номенклатура готовой продукции (услуг);
- номенклатура материалов и ресурсов.
Характеризуя предприятие, необходимо акцентировать внимание на тех его структурных компонентах, в которых будут использованы результаты ВКР. Необходимо указать, если есть, головную организацию и дочерние организации.
Для коммерческих предприятий следует показать положение на рынке: основные конкуренты, аналогичные предприятия, масштабы деятельности, сфера влияния, доля рынка.
Необходимо установить базовые экономические и другие показатели, характеризующие деятельность предприятия (например, прибыль, рентабельность, число обслуживаемых клиентов в единицу времени, скорость выполнения задачи или услуги и т.п.). Далее описать основные тенденции развития предприятия в виде таблицы с динамическими рядами основных ее технико-экономических показателей за последние 3–5 лет.
2.2 Описание бизнес-архитектуры и уровня развития информационных технологий
Стратегия развития и бизнес-архитектура предприятия.
При описании стратегии рекомендуется использовать распространенные методики «послойного» анализа архитектур бизнеса и информационных технологий, например, методологию Захмана. Важно показать, как стратегия и бизнес-архитектура предприятия определяет стратегию и развития и оперативные задачи ИТ. Рекомендуется максимально использовать документы стратегического характера, имеющиеся на фирме. Самостоятельная разработка моделей такого рода очень трудоемка.
Состояние и стратегия развития информационных технологий.
При описании состояния ИТ на предприятии рекомендуется привести фактическую структуру корпоративной ИС или ее отдельных элементов, а также перечень используемых программных продуктов, технологий и т.д.
Если на предприятии имеется корпоративная информационная система управленческого класса (ERP, MRPII, CRM, например, SAP R/3 или 1С: Комплексная автоматизация 8), то рекомендуется описать ее функциональность, особенности эксплуатации, проблемы, возникающие в связи с ее использованием.
Стратегия развития ИТ должна вытекать из бизнес-архитектуры. Как правило, на малых и средних предприятиях целостная ИТ-стратегия отсутствует. В этом случае, рекомендуется такую стратегию разработать и рассматривать как в качестве важного результата ВКР.
2.3 Функциональная модель и/или процессная модель предприятия «AS-IS»
Процессная модель предприятия служит системной основой для любых действий по автоматизации. Правильное описание и анализ системы основных и вспомогательных процессов является необходимым условием эффективного внедрения ИС. Следует различать функциональный и процессный подходы в управлении. В явном виде процессный подход практикуется далеко не во всех предприятиях. В этом случае, вклад автора ВКР в создание процессной системы управления может стать очень существенным компонентом ВКР. Описание ситуации и рекомендации по оптимизации следует дать максимально полно, с использованием любых средств моделирования и визуализации результатов.
При анализе ситуации рекомендуется опираться на стандарты управления качеством (TQM, Total Quality Management). Оптимальными являются нотации IDEF0, SwimLane, IDEF3, диаграммы групп UML, ARIS, BPMN. Желательно при описании функциональности использовать объектный подход – нотации диаграммы классов и объектов (UML), а также составить детальную понятийную модель (тезаурус, онтологию).
Модель потоков данных «AS-IS» должна отражать информационные потоки, обеспечивающие бизнес-процессы и бизнес-функции организации.
Информационные системы отражают деятельность предприятия в терминах потоков информации: управленческих документов, данных, обеспечивающих принятие оперативных решений, аналитических информационных выборок, необходимых для стратегического анализа. Поэтому модель информационных потоков – это основа для информатизации любого рода.
Рекомендуется использовать нотации DFD, ERD, диаграммы классов UML. Важнейшие первичные документы (шаблоны или образцы) желательно привести в приложениях. Особенно важно описать в формате AS-IS структуру существующих баз данных.
2.4 Анализ проблем предметной области и обоснование решения по оптимизации бизнес-процессов
Анализ проблем предметной области.
Анализ проблем предметной области представляет собой анализ «узких мест» с точки зрения бизнес-целей предприятия.
Следует выявить связи базовых технико-экономических показателей предметной области со средствами их улучшения. Для этого надо провести анализ целей предприятия (предметной области) и ее проблем.
Анализ целей предметной области начинается с формулировки основной цели, которая, как правило, имеет следующую структуру: глагол-действие, пояснение, объект-цель.
Построение «дерева целей» начинается с процедуры структуризации: декомпозиции основной цели на составные элементы, называемые подцелями, каждая из которых является средством, направлением или этапом ее достижения. Затем каждая из подцелей в свою очередь рассматривается как цель и разделяется на компоненты.
Затем проводится анализ проблем предметной области. Вначале выбирается и сжато формулируется одна (или несколько) из ключевых проблем достижения целей. При этом главная проблема (проблема в вершине «дерева проблем») не должна быть главной проблемой достижения высшей цели: необходимо найти на дереве целей наиболее проблемные подцели (достижение которых вызывает наибольшие трудности).
Следует сделать акцент на проблемах и недостатках, устранение которых предполагается осуществить в проекте, например:
- несовершенство организации сбора и регистрации исходной информации;
- невозможность расчета показателей, необходимых для управления объектом из-за сложности вычислений или большого объема информации;
- высокая трудоемкость обработки информации (привести объемно-временные параметры);
- низкая оперативность, снижающая качество управления объектом;
- невысокая достоверность результатов решения задачи из-за дублирования потоков информации;
- несовершенство процессов сбора, передачи, обработки, хранения, защиты целостности и секретности информации и процессов выдачи результатов расчетов конечному пользователю и т.д.
Обоснование решения по оптимизации бизнес-процессов.
По результатам проблемного анализа определяются конкретные цели оптимизации бизнес-процессов. Рекомендуется построение целевых («TO-BE») моделей улучшенных процессов в любых нотациях (IDEF, UML, ARIS, BPMN).
На основе построенных целевых моделей бизнес-процессов определяется конфигурация проекта, ориентированного на решение задач и достижение целей. Рекомендуется в данном подразделе кратко прокомментировать основные разделы технического задания.
2.5 Концептуальное обоснование проекта
2.5.1 Цели и бизнес-требования проекта
Возможно как качественное описание результатов, так и оценка финансового результата. Рекомендуется методология BSC (Balanced Scorecard, метод сбалансированных показателей) и KPI (Key Performance Indicators, метод ключевых показателей). В любом случае, информационные технологии должны определяться бизнес-целями, а ИТ-стратегия вытекать из бизнес-стратегии.
Типичными целями могут быть:
Финансовые цели:
- освоить Х% рынка за Y месяцев;
- увеличить сектор рынка в стране X на Y% за Z месяцев;
- достигнуть объема продаж X единиц или дохода, равного $Y, за Z месяцев;
- получить Х% прибыли или дохода по инвестициям в течение Y месяцев;
- достигнуть положительного баланса по конкретному продукту в течение Y месяцев;
- сэкономить $Х в год, которые в настоящий момент расходуются на обслуживание системы;
- уменьшить затраты на поддержку на Х% за Z месяцев;
- получить не более X звонков в службу обслуживания по каждой единице товара и Y звонков по гарантии каждой единицы товара в течение Z месяцев после выпуска товара;
- увеличить валовую прибыль для существующего бизнеса с Х до Y%.
Нефинансовые цели:
- достигнуть показателя удовлетворения покупателей, равного по крайней мере X, в течение Y месяцев со времени выпуска товара;
- увеличить производительность обработки транзакций на Х% и снизить уровень ошибок данных до величины не более Y%;
- разработать надежную платформу для семейства связанных продуктов;
- разработать специальную базовую технологическую основу для организации;
- получить X положительных отзывов в отраслевых журналах к определенной дате;
- добиться признания продукта лучшим по надежности в опубликованных обзорах продуктов к определенной дате;
- соответствовать определенным федеральным и государственным постановлениям;
- уменьшить время обработки до X часов на Y% звонков покупателей в службу поддержки.
2.5.2 Классы и характеристики пользователей
Для любого ИТ-проекта определяющим фактором являются особенности заказчика, потенциальных пользователей и заинтересованных лиц (stakeholders).
В качестве заказчика, как правило, выступают топ-менеджеры предприятия. Они формулируют общие требования к результатам проекта, осуществляют согласование. Рекомендуется четко определить заказчика, его юридический или иерархический статус и вклад в формулирование требований.
Понятие «пользователь» не совпадает с понятием «заказчик». Пользователям предстоит эксплуатировать разработанную или внедренную систему. Рекомендуется классифицировать пользователей на категории (например, операторы и администраторы), и в дальнейшем указывать требования соответствующего класса при определении бизнес-логики.
Заинтересованные лица проекта (stakeholders) – это, например, юридические и физические лица, финансирующие проект, предоставляющие временные трудовые ресурсы. В рамках ВКР достаточно их перечислить с указанием конкретных степеней заинтересованности.
2.5.3 Описание требований и ограничений проекта
Описание методологии и техник выявления требований.
Рекомендуется охарактеризовать методики выявления и спецификации требований в рамках ВКР. Как правило, используются:
- различного рода анкетирования специалистов (желательно привести в приложениях разработанные анкеты), подразумевающие статистическую или неформальную обработку результатов;
- круглые столы и мозговые штурмы;
- интервьюирования специалистов;
- согласования промежуточных моделей и сценариев.
Практически всегда используется большое количество нотаций для представления результатов в модели «AS-IS»: группа диаграмм IDEF, различные виды диаграмм UML, бизнес-моделирование BPMN и др. Желательно кратко обосновать выбор тех или иных средств.
Описание бизнес-логики и функциональных требований.
Стоит определить тип проектируемой системы. Это может быть:
- система электронной обработки данных;
- информационно-поисковая система;
- диалоговая система решения задачи и ли обработки транзакций;
- система поддержки принятия решений;
- автоматизированное рабочее место (АРМ);
- автоматизированная система управления.
В выпускной квалификационной работе автору необходимо решать выявленные проблемы предметной области, поэтому цели проекта можно разделить на две группы подцелей:
1) достижения улучшения экономических показателей: выполнения выбранной функции управления или работы рассматриваемого подразделения или всего предприятия в целом (например, увеличение выпуска продукции, снижение ее себестоимости, снижение финансовых потерь, сокращение простоев и т.д.);
2) улучшения значений показателей качества обработки информации (например, сокращение времени обработки и получения оперативных данных для принятия управленческих решений; повышение степени достоверности обработки информации, степени ее защищенности, повышение степени автоматизации получения первичной информации; увеличение количества аналитических показателей, получаемых на базе исходных и т.д.).
Далее следует определиться с задачами ВКР, которые вытекают из необходимости проектирования ИС/подсистем ИС.
Постановка задачи на разработку ИС или на адаптацию и внедрение существующего программного продукта обязательно подразумевает максимально полное и однозначное описание функциональных требований. Рекомендуется разбить их на блоки по важности: абсолютно необходимая функциональность, желательная функциональность, возможная функциональность и исключенные из рассмотрения функции (модель MoSCoW – Mast Have, Should Have, Could Have и Would’t Have). Обобщенно такой набор требований считается бизнес-логикой проектируемой системы.
Наиболее важные направления бизнес-логики:
- сценарные модели и схемы взаимодействия с разрабатываемой системой бизнес-пользователей;
- требования прикладных интерфейсов и экранных форм (включая макеты, стандарты шрифтов, значков и цветовых характеристик, ограничения разрешения экрана, быстрые клавиши, специальные возможности для пользователей с проблемами со зрением);
- требования к хранилищам данных и серверной логике (максимально полное описание баз данных в ERD-формате, требования к целостности данных, распределение функциональности между «клиентом» и «сервером», необходимость и спецификация организации витрин данных (Data Marts) и т.д.);
- шаблоны выходных документов и отчетных форм (рекомендуется описать и привести в приложениях все основные отчетные документы, которые создает программа);
- форматы и интерфейсы обмена данными между программами и в сетевой среде (основные протоколы, необходимость подключения стандартных программ, необходимость XML-формата и т.д.);
- требования к защите данных и контролю доступа (степень важности и уязвимости данных, особенности разграничения доступа к информации, необходимость шифрования, необходимость и особенности авторизации при входе в систему и т.д.).
При описании общей логики функциональности рекомендуется использовать UseCase и SwimLane (SADT). При описании отдельных функций системы рекомендуется использовать инструментарий UML: диаграммы активности, диаграммы последовательностей и диаграммы состояний.
Анализ нефункциональных требований.
Существенным элементом бизнес-логики являются нефункциональные требования:
- требования к производительности: рекомендуется определить количество транзакций в секунду, время ожидания и отклика, характеристики пиковых нагрузок и количества одновременно работающих в системе (особенно важно для OLTP-систем);
- требования к операционной среде (локальная, сетевая, Интернет) и пропускной способности каналов связи с серверами;
- требования к точности вычислений;
- требования к оперативной и долговременной памяти;
- требования к технической безопасности и надежности системы (наработки на отказ, необходимость резервирования данных и т.д.);
- требования к технической и сопроводительной документации, обучению пользователей (включая особенности и желательный формат help-систем).
Анализ проектных ограничений.
Рекомендуется описать факторы, которые ограничивают возможности проектирования и программирования. Ограничения могут быть:
- определенные технологии, средства, языки программирования и базы данных, которые следует использовать или избегать;
- ограничения, налагаемые операционной средой продукта, например типы и версии установленных Web-браузеров;
- обязательные соглашения или стандарты разработки (в частности, требования к организации, планированию и управлению проектом);
- совместимость с продуктами, выпущенными ранее;
- ограничения, связанные с оборудованием, ограничения памяти или процессора, размер, вес, материалы или затраты.
2.5.4 Анализ рисков, определение метрик для мониторинга риска.
Основными документами данного раздела, как правило, являются:
- главная таблица рисков;
- паспорта основных рисков (включая планы мероприятий по предотвращению важнейших рисков и по устранению последствий).