Проектирование системы. Проектирование систем. Проектирование информационных систем ( на примере методов структурного системного анализа)
 Скачать 1.64 Mb.
|
|
Структурный аспект предполагает построение: 1) организационной структуры, отражающей взаимодействие организаци- онных единиц предприятия и персонала в процессах; 2) функциональной структуры, отражающей взаимосвязь функций (дей- ствий) по преобразованию объектов в процессах; 3) информационной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной обла- сти; 4) технической структуры, описывающей топологию расположения и спо- собы коммуникации комплекса технических средств. 5) структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов. 153 Для отображения структурного аспекта моделей предметных областей в основном используются графические методы, как наиболее емкий способ представления информации о системе. Главное требование к графическим ме- тодам документирования – простота. С моделированием связана проблема выбора языка моделирования. Язык моделирования – это нотация, в основном графическая, которая используется для описания проектов. Нотация представляет собой совокупность графических объектов, используемых в модели и является синтаксисом языка моделирова- ния. Язык моделирования, с одной стороны, должен делать решения проекти- ровщиков понятными пользователю, с другой стороны, предоставлять проекти- ровщикам средства формализованного и однозначного представления проекта, подлежащего дальнейшей программной реализации. Выбор языка моделирования является одной из первых задач процесса проектирования системы (см. гл. 1.6). Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, которые включают также косвенные показатели эффективности, такие, как объ- емы производства, производительность труда, оборачиваемость капитала, рен- табельность и т.д. Для расчета показателей эффективности, как правило, используются статические методы функционально-стоимостного анализа (ABC) и динами- ческие методы имитационного моделирования. Моделирование процессов, как правило, выполняется с помощью CASE- средств. К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0); моделирование рабочих потоков (IDEF3); диаграммы потоков данных (DFD). 154 3.5. Оценка эффективности и целесообразности ИТ-проекта Подходы к оценке эффективности ИТ -проекта Первичные цели автоматизации – ускорение выполнения процессов, раз- грузка персонала, удешевление производства, улучшения качества информация для принятия решения. Тенденция в развитии ИТ на фазе роста – непрерывное усложнение технологий, а также методик проектирования и требования к си- стемам (достаточно взглянуть на группы ГОСТов Союза ССР групп 24 и 34). В результате (ради ускорения бизнес-процесса) тратится огромное количество времени на проектирование и разработку ПО (правда один раз). Разгрузка пер- сонала (пользователей системы) при выполнении работ становится несравнима с загрузкой проектировщиков и программистов. Мы имеем удешевление произ- водства, с одной стороны, и колоссальные затраты на стадии проектирования, разработки, внедрения и поддержки системы, с другой. Уменьшается штат про- изводственного персонала, при этом неимоверно разрастаются отделы АСУ, за- траты на труд ИТ-специалистов по непрерывной поддержке и модернизации системы часто несравнимы с эффектом от использования ИС. Иногда отказ от технологии является выходом из ситуации. Оценка целесообразности внедре- ния ИТС до начала проектных работ помогает избежать потерь. В современной практике существуют два основных метода оценки эф- фективности проекта, реализуемых на действующих предприятиях: метод рас- чета по предприятию в целом и приростной метод. Расчет по предприятию в целом рекомендуется производить, сопостав- ляя варианты проекта развития предприятия в целом «с проектом» и «без про- екта» (далее соответственно «основной» и «нулевой» варианты). Формирование основного варианта производится путем внесения соответствующих корректи- ровок в показатели нулевого варианта. Если внедрение ИТС оказывает влияние на различные стороны деятельности предприятия, могут измениться технико- 155 экономические и финансовые показатели работы предприятия в целом. Такая ситуация может возникнуть при внедрении интегрированных корпоративных систем управления. При этом необходимо сопоставить перспективные показа- тели работы предприятия при условии реализации ИТС-проекта, связанного с внедрением интегрированных корпоративных систем управления и при условии отказа от него. Такое сопоставление выполняется на основе метода расчета по предприятию в целом. Для оценки эффективности инвестиционных проектов внедрения ИТС, имеющих локальный характер на предприятии, используется приростной ме- тод, основная идея которого состоит в определении изменений притоков и от- токов денежных средств, обусловленных реализацией проекта. Главная про- блема, которая возникает при применении приростного метода, − точное вы- явление факторов, определяющих эффективность проекта (например, уменьше- ние трудоемкости выполнения операции, сокращение количества работающих и т. д.) и правильная количественная оценка изменений финансовых затрат и результатов с учетом указанных факторов. Фактическим стандартом при расчете стоимости ИС стал метод TCO (совокупная стоимость владения), предложенный компанией Gartner. Позже многие крупные поставщики ИТ представили свои версии данного метода. Но TCO оценивает только затратную часть, не учитывая преимуществ от внедре- ния. Поэтому эта методика в чистом виде применима только для оценки реше- ний, обеспечивающих сходную функциональность. Метод ROI (отдача от инвестиций) дает возможность определить, какой фи- нансовый результат обеспечивает каждый рубль, инвестированный в проект, но не дает четкого и ясного способа определить абсолютную величину этого результата. Определение качественных и финансовых эффектов наилучшим образом обеспечи- вается системой сбалансированных показателей (Balanced ScoreCard, BSC), но для ее внедрения необходима длительная подготовительная работа, зачастую требую- щая изменения существующих подходов к управлению компанией. 156 Более простая и доступная для использования методика, но в то же время дающая четкие и обоснованные результаты, была разработана компанией Microsoft − методика «быстрого экономического обоснования (Rapid Economic Justification, REJ). Методика быстрого экономического обоснования Методика «быстрого экономического обоснования» (Rapid Economic Justification, REJ, Microsoft) позволяет преодолеть языковый барьер между ИТ- специалистами и исполнителями бизнеса и продемонстрировать выгоду от ин- вестиции в ИТ. Заинтересованные лица (Stakeholders): • Генеральный директор − CEO (Chief Executive Officer). • Финансовый директор − CFO (Chief Financial Officer). • Вице-президент – VP. • Директор по информационным технологиям − CIO (Chief Information Officer) − сотрудник корпорации, исполнитель высшего ранга; отвечаю- щий за приобретение и внедрение новых технологий, управление инфор- мационными ресурсами. • ИТ-персонал − IT stuff. • Торговые посредники – Resellers-фирмы, специализирующиеся на опто- вых поставках и торговом посредничестве. • Поставщики – Suppliers. Шаг 1. Обследование объекта (Understand the Business). Исследование начинается с определения ключевых проблем предприятия и поиск ИТ- решения, которое будет способствовать устранению этих проблем и позволит предприятию добиться успеха. На этой стадии определяются критические фак- торы успеха предприятия и их показатели, а также составляется план их дости- 157 жения. Для этого исследуют стратегический план развития компании, бизнес- план, проводят консультации с руководством компании, руководителями функ- циональных подразделений и ключевыми специалистами. Шаг 2. Выбор технических решений (Understand the Solutions). На этой стадии проектная команда работает с владельцами ключевых бизнес-процессов, используя схемы процессов в организации, функционально-структурные схемы и диаграммы причинно-следственных связей с целью определения способов применения ИТ-решений для повышения их соответствия критическим факто- рам успеха организации. Для каждой работы, определенной на предыдущем шаге, необходимо найти, с использованием каких ИТ можно улучшить ее эф- фективность. Шаг 3. Вычисление разницы между доходами и расходами (Understand the Benefit/Cost Equation). После того как возможные технические решения вы- браны, команда аналитиков вычисляет потенциальную прибыль от их внедре- ния и необходимый объем капиталовложений для каждого проекта. Шаг 4. Выявление рисков (Understand the Risks). Многие сначала эко- номически оправданные ИТ-проекты после внедрения не соответствуют ожи- даниям руководства и других заинтересованных лиц. Анализ потенциальных рисков инвестиций в ИТ может помочь избежать провала путем выявления раз- личных форм риска, разработки решения о их смягчении и подгонки прибыли к затратам. Существуют различные категории рисков: • риск соответствия. Чем жестче соответствие ИТ-проекта целям пред- приятия, тем меньше риск. Необходимо заметить, что для некоторых про- ектов установление четкого соответствия технологий стратегическим це- лям бизнеса — задача сложно выполнимая (например, усовершенствова- ние инфраструктуры информационной системы), однако инвестиции в них являются необходимыми для дальнейшего развития информацион- ных технологий; 158 • реализационный риск. Учитывает возможность того, что действительная стоимость реализации проекта будет отличаться от расчетной; • операционный риск. Учитывает возможность того, что стоимость функ- ционирования системы будет отличаться от предполагаемой; • технологический риск. Чем больше известно о выбранном решении и чем лучше проработаны выбранные технологии, тем меньше этот риск. Одна- ко проекты с малым значением технологического риска не всегда обеспе- чивают достаточно высокие потенциальные преимущества и, наоборот, чем выше риск, тем выше возможная прибыль; • риск денежных потоков. Учитывает возможность недостоверного опре- деления выгод от проекта и неточного расчета положительных денежных потоков, а также возможность появления других непредвиденных финан- совых проблем. Например, будет принято решение увеличить капитали- зацию бизнеса или другие, более важные с точки зрения руководства, проблемы потребуют отвлечения средств от рассматриваемого проекта, в результате чего не удастся достичь предполагаемых выгод в полном объ- еме. Риски могут быть описаны как количественно, так и качественно. Шаг 5. Расчет финансовых показателей (Understand the Financial Met- rics). На основе полученных дисконтированных денежных потоков, скорректи- рованных с учетом рисков, рассчитываются финансовые показатели, принятые на данном предприятии. Такими показателями могут быть чистый приведенный доход (Net Present Value, NPV), внутренняя норма доходности (Internal Rate of Return, IRR), добавленная стоимость (Economic Value Added, EVA), срок окупа- емости, возврат от инвестиций и другие. 159 4. СТРУКТУРНЫЙ АНАЛИЗ И СТРУКТУРНОЕ ПРОЕКТИРОВАНИЕ 4.1. Основные понятия структурного анализа и структурного проектирования Определения понятий Структурным анализом принято называть метод исследования системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру с все большим числом уровней. Решение трудных проблем путем их разбиения на множество меньших независимых задач (так называемых «черных ящиков») и организация этих задач в древовидные иерар- хические структуры значительно повышают понимание сложных систем. В инженерии ПО (software engineering), Структурный анализ (Structured Analysis, SA ) и одноименное с ним Структурное проектирование (Structured Design, SD) – это методы для анализа и преобразования бизнес-требований в спецификации и, в конечном счете, в компьютерные программы, конфигурации аппаратного обеспечения и связанные с ними ручные процедуры. Структурный анализ, СА (Structured Analysis, SA) и Структурное проек- тирование, СП (Structured Design, SD) являются фундаментальными инстру- ментами системного анализа и развивались из классического системного ана- лиза 1960-70-х годов (см. гл. 1.1). Структурный подход заключается в поэтапной декомпозиции системы при сохранении целостного о ней представления Основные принципы струк- турного подхода (первые два являются основными): 1) принцип «разделяй и властвуй» – принцип решения сложных проблем пу- тем их разбиения на множество меньших независимых задач, легких для понимания и решения; 160 2) принцип иерархического упорядочивания – принцип организации состав- ных частей проблемы в иерархические древовидные структуры с добав- лением новых деталей на каждом уровне. 3) принцип абстрагирования – заключается в выделении существенных ас- пектов системы и отвлечения от несущественных; 4) принцип формализации – заключается в необходимости строгого методи- ческого подхода к решению проблемы; 5) принцип непротиворечивости – заключается в обоснованности и согласо- ванности элементов. История структурного анализа и проектирования Структурный анализ – это часть серии структурных методов, представ- ляющих набор методологий анализа, проектирования и программирования, ко- торые были разработанны в ответ на проблемы, с которыми столкнулся мир ПО в период с 1960 по 1980 гг. В этот период большинство программ было создано на Cobol и Fortran, потом на C и BASIC. Это было новым положительным сдвигом в направлении проектирования и программирования, но при этом не было стандартных методологий для доку- ментирования требований и самих проектов. По мере укрупнения и усложнения систем, все более затрудниельным становился процесс их разработки. Когда большинство специалистов билось над созданием программного обеспечения, немногие старались разрешить более сложную задачу создания крупномасштабных систем, включающих как людей и машины, так и про- граммное обеспечение, аналогичных системам, применяемым в телефонной связи, промышленности, управлении и контроле за вооружением. В то время специалисты, традиционно занимавшиеся созданием крупномасштабных си- стем, стали осознавать необходимость большей упорядоченности. Таким обра- зом, разработчики начали формализовать процесс создания системы, разбивая его на следующие фазы: 161 1) анализ – определение того, что система будет делать; 2) проектирование – определение подсистем и их взаимодействие; 3) реализация – разработка подсистем по отдельности; 4) объединение – соединение подсистем в единое целое; 5) тестирование – проверка работы системы; 6) установка – введение системы в действие; 7) функционирование – использование системы. Эта последовательность всегда выполнялась итерационно, потому что си- стема полностью никогда не удовлетворяла требованиям пользователей, по- скольку их требования часто менялись. И, тем не менее, с этой моделью созда- ния системы, ориентированной на управление, постоянно возникали сложно- сти. Эксплуатационные расходы, возникавшие после сдачи системы, стали су- щественно превышать расходы на ее создание и продолжали расти с огромной скоростью из-за низкого качества исходно созданной системы. Некоторые счи- тали, что рост эксплуатационных расходов обусловлен характером ошибок, до- пущенных в процессе создания системы. Исследования показали, что большой процент ошибок в системе возник в процессе анализа и проектирования, гораз- до меньше их было допущено при реализации и тестировании, а цена (времен- ная и денежная) обнаружения и исправления ошибок становилась выше на бо- лее поздних стадиях проекта. Например, исправление ошибки на стадии проек- тирования стоит в 2 раза, на стадии тестирования – в 10 раз, а на стадии эксплу- атации системы – в 100 раз дороже, чем на стадии анализа. На обнаружение ошибок, допущенных на этапе анализа и проектирования, расходуется пример- но в 2 раза больше времени, а на их исправление – примерно в 5 раз, чем на ошибки, допущенные на более поздних стадиях. Кроме того, ошибки анализа и проектирования обнаруживались часто самими пользователями, что вызывало их недовольство. Традиционные подходы к созданию систем приводили к возникновению многих проблем: 1) не было единого подхода; 162 2) привлечение пользователя к процессу разработки не контролировалось; 3) проверка на согласованность проводилась нерегулярно или вообще от- сутствовала, результаты одного этапа не согласовывались с результатами других; 4) процесс с трудом поддавался оценкам, как качественным, так и количе- ственным. Утверждалось, что когда создатели систем пользуются методологиями типа структурного программирования и проектирования сверху вниз, они решают либо не поставленные задачи, либо плохо поставленные, либо хорошо поставленные, но неправильно понятые задачи. Кроме того, ошибки в создании систем станови- лись все менее доступны выявлению с помощью аппаратных средств или про- граммного обеспечения, а наиболее катастрофические ошибки допускались на ранних этапах создания системы. Часто эти ошибки были следствием неполноты функциональных спецификаций или несогласованности между спецификациями и результатами проектирования. Проектировщики знали, что сложность систем возрастает и что определены они часто весьма слабо. Рост объема и сложности си- стем является жизненной реалией. Эту предпосылку нужно было принять как неизбежную. Но ошибочное определение системы не является неизбежным: оно – результат неадекватности методов создания систем. Вскоре был выдвинут тезис: совершенствование методов анализа есть ключ к созданию систем, эффективных по стоимости, производительности и надежности. Для решения ключевых проблем традиционного создания систем широкого профиля требовались новые методы, специально предназначенные для использования на ранних стадиях процесса. Для помощи в управлении большим и сложным ПО с конца 1960 годов появляется множество разнообразных структурных методов программирова- ния, проектирования и анализа. Эти методы на начальных этапах создания си- стемы позволяют гораздо лучше понять рассматриваемую проблему. А это со- кращает затраты как на создание, так и на эксплуатацию системы, а кроме того, повышает ее надежность. |