2)Построение ролевой модели
Следующий шаг – создание ролевой модели на основе модели структурной. Суть всего второго этапа состоит в том, чтобы для выделенных процессов определить исполнителей, а также характер и круг их взаимодействия с другими сотрудниками и подразделениями, вид источников дополнительной информации. Ролевая модель является необходимым дополнением к модели процессной. Также как структурная модель должна дополнять и выполняться процессной моделью. Фактически ролевая модель представляет собой структурную модель в динамике. Но здесь имеется в виду уже не временная динамика, а система взаимоотношений между сотрудниками по ходу осуществления бизнесс-процесса.
Процессно-ролевая модель компании, как и организационная модель, создается путем совмещения двух предшествующих моделей данного этапа бизнесс-моделирования. Целью процессно-ролевой модели является создание проекции бизнесс-процессов на организационную структуру компании при помощи приписывания исполнителем конкретных ролей по отношению к данному бизнесс-процессу. Сведения и соответствия, устанавливаемые в данной модели, необходимо задокументировать и сделать доступной для всех ли имеющих отношение к выполнению процесса внутри компании. Это поможет выработать стандарт эффективного поведения в рабочих ситуациях, с которыми сталкиваются сотрудники при выполнении обязанностей, сделает более ясными и понятными информационные потоки внутри компании.
3)Количественная модель бизнес-процесса.
Создание количественной модели – это следующий уровень детализации модели компании, раскрывающий более подробно процессно-ролевую модель компании. В конечном результате компания ориентируется на количественные показатели своей деятельности, и именно эти показатели используются для оценки эффективности деятельности. На предыдущих этапах количественные показатели отсутствовали, так как целью этих этапов было создание системы функций и построение последовательности работ, но в целях планирования и контроля для логического завершения процесса бизнесс-моделирования необходимо внести в построенные ранее модели бизнес-процессов количественные показатели. Очевидно, что различные процессы будут характеризоваться различными количественными показателями. Поэтому, в отличие от предыдущих, количественная модель относится не к компании в целом, а к определенным бизнес-процессам. В процессе производства, например, значимой может быть оценка материальных затрат на каждой стадии процесса, поэтому при построении количественной модели бизнес-процесса производства используются различные техники учета затрат. В логических цепочках также важной характеристикой является время, затраченное на каждом этапе, поэтому в число методик количественной оценки логических цепочек входят различные методики сетевого планирования. Количественная модель компании отвечает на вопрос «сколько» и призвана отобразить формирование себестоимости затрат, времени издержек на рабочую силу. С учетом этих данных можно найти узкие места в процессе. Например, те этапы, на которые затрачивается не пропорционально много ресурсов, обнаружить необязательные простои и т.д.
Использование бизнесс-моделирование для реструктуризации управления компании.
Бизнесс-моделирование позволяет зафиксировать состояние компании на текущий момент и представить его в простом и строгом формальном виде. Но поскольку бизнес не стоит на месте то целью бизнес-моделирования не является создание статичной модели. Бизнесс-модель компании может быть использована, во-первых, как отправная точка при разработке тактики реструктуризации управления и, во-вторых, как основа для оценки качества реструктуризации. Особенно это относится к сравнению отличий количественных моделей. Реагируя на изменения внешней среды, компании вынуждены изменять свои стратегии и цели что приводит к необходимости изменять организационную и процессно-ролевую структуры компании. Изменения неизбежно определяются и на третьем уровне бизнесс-модели компании, изменяя финансовые и прочие результаты деятельности. Бизнесс-моделирование может успешно использоваться при реструктуризации управления компании. Так как удобно реструктуризацию управления сначала сымитировать на бизнесс-модели, разработать различные тактики и оценить различные стратегии реструктуризации и методику ее внедрения в компанию. И уже затем, оценив и взвесив различные варианты, можно приступать к реструктуризации компании. Таким образом, руководство компании в какой-то мере застраховано от риска принятия неверных управленческих решений. Кроме того, бизнесс-моделирование позволяет провести имитацию сравнительно быстро. Процесс формальной имитации реструктуризации управления компанией называется бизнес-инжинерингом. В основе бизнес-инженеринга лежит процесс бизнес-моделирования. Стандартным алгоритмом моделирования, структурного изменения компании является следующая последовательность:
создание модели AS IS, описывающей текущее состояние структуры управления компании
создание модели TO BE, описывающей видение руководством структуры управления измененной в соответствии с требованием рынка, а также построение процесса перехода от модели AS IS к модели TO BE. Возможно, создание нескольких промежуточных разнесенных по времени и по осуществлению моделей.
Обычно сначала строится модель существующей организации, работы AS IS, анализ которой позволяет определить:
наиболее слабые места
преимущество новых бизнес-процессов
глубину изменений, которым подвергнется существующая структура организации бизнеса.
Признаками неэффективной работы деятельности компании могут быть:
бесполезные неуправляемые дублирующие работы
неэффективный документооборот
отсутствие обратных связей по управлению
отсутствие обратных связей по входу
Найденные в модели AS IS недостатки можно исправить при создании модели TO BE, которая нужна для анализа альтернативных путей выполнения работы и документирования того, как компания будет делать бизнес в будущем. При создании модели AS IS разработчиком может быть допущена распространенная ошибка – создание идеализированной модели, то есть модели созданные на основе знаний руководителя, а не конкретного исполнителя работ. Такая модель несет ложную искаженную информацию и называется SHOULD BE. Иногда текущая модель AS IS и будущая модель TO BE различаются очень сильно, так что переход от начального состояния к конечному становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального состояния системы к конечному. Существуют различные мнения относительно того, какие модели и в каком состоянии должны создаваться в компании. Однако многие специалисты признают, что постоянное наличие и мониторинг описания компании AS IS и закрепление его во внутрифирменных документах вместе с использованием современных программных средств моделирования значительно увеличивают скорость и эффективность процесса изменения компании. Последовательность AS IS, промежуточные этапы TO BE являются классической. Но в зависимости от ситуации некоторые этапы могут быть исключены. Например, этап AS IS не является обязательным, если целью моделирования является радикальная трансформация бизнесс-модели. В данном случае создание модели существующего положения будет лишней тратой средств, так как от нее все равно придется отказаться. Моделирование AS IS разумно в тех случаях, когда речь идет лишь о посредственном совершенствовании уже налаженного процесса стабильной внешней среде. Бизнесс-инженеринг начинается со стратегического моделирования, и сюда входят определения миссий, целей и стратегий компании. Этот уровень бизнесс-инженеринга называется концептуальным моделированием, то есть направление развития компании определяется на уровне концепций. Сделать это можно различными способами на основе изучения внешней среды, получение соответствия эталонным отраслевым моделям и при помощи различных методов. Миссия – это то, от чего должно отталкиваться руководство компании при планировании любых изменений, особенно если они затрагивают все уровни в организации. Соответственно является базой для дальнейшей разработки целей, стратегий, функций, процессов, должностных инструкций. Фактически бизнесс-инженеринг представляет собой бизнесс-моделирование, основанное не на существующем положении вещей, а на разработанных на основе миссий, целей и стратегий, что является нулевым этапом моделирования изменений. Сам по себе процесс выработки и формулирования миссии достаточно сложен и включает в себя несколько элементов характеризующих то, как компания видит свою деятельность на рынке относительно конкурентов, поставщиков, заказчиков, а, кроме того, определяются возможности компании, тенденции развития требования рынка. Разработка миссии основывается на понимании рынка и его потребности и фактически является результатом определения места компании среди других участников рынка. На основе сформулированной миссии руководство компании далее должно детализировать ее, разработав приоритетные цели и стратегии. Планируемые изменения на стратегическом уровне далее должны быть преобразованы в изменения функциональной и структурной модели. Основной чертой бизнесс-моделирование является устранение взаимосвязей меду различными этапами развития компании и формальным их описанием. Когда такие связи установлены, любое изменение на верхнем стратегическом уровне вызывает изменения на всех взаимосвязанных с ними параллельных и зависимых уровнях. Имея на руках бизнесс-модель компании, руководство может достаточно быстро проанализировать все те изменения, которые повлекут за собой их управленческие решения. И таким образом принять необходимые меры для активизации структуры управления в условиях планируемых изменений. Бизнесс-моделирование является одной из перспективных инженеринговых методик применяемых при управлении компанией.
Информационное моделирование.
Информационная структура данных создается в несколько этапов, на каждом из которых необходимо согласовать структуру данных с заказчиком и провести экспертизу этой структуры внутри команды, которая создает систему. Представление данных должно быть простым и понятным всем заинтересованным лицам. Именно потому наибольшее распространением получило представление базы данных под названием «сущность-связь» или ER-диаграмма. На использовании разновидностей ER-моделей основано большинство подходов к проектированию реляционных баз данных. Моделирование предметной области базируется на использовании графических диаграмм, включающих наибольшее число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE-средств, поддерживающих автономное проектирование реляционных баз данных. ER-диаграммы были приняты в качестве основы для создания стандарта IDEF1X. ER-диаграммы используются для разработки данных и представляют собой стандартный способ определения данных и отношений между ними. Таким образом, осуществляется детализация хранилищ данных. ER-диаграмма содержит информацию о сущностях системы и способах их взаимодействий, включает идентификацию объектов, важных для предметной области, идентификацию свойств этих объектов, а также их отношения с другими объектами. Во многих случаях информационная модель получается очень сложной и содержит множество атрибутов и связей. С развитием компьютерных технологий и появлением CASE-моделирования возникла потребность в инструментах, которые поддерживали бы стандарты моделирования. Современный инструмент моделирования баз данных должен удовлетворять следующим требованиям:
позволять разработчику сконцентрироваться на самом моделировании, а не на проблемах с графическим отображением диаграммы. Инструмент должен автоматически размещать сущности на диаграмме, иметь развитые и простые в управлении средства визуализации создания представлений модели.
инструмент должен проверять диаграмму на согласованность автоматически отправляя и устраняя несоответствие. Однако инструмент должен быть настраиваемым и при желании предоставлять разработчику право самому устранять несоответствие или разрешать отступление от методологии.
инструмент моделирования должен поддерживать как логическое, так и физическое моделирование
современный инструмент должен автоматически генерировать базу данных на СУБД назначения
Методология IDEF1X определяет стандарты, терминологии, используемые при информационном моделировании и графическом изображении типовых элементов на диаграммах. Возможны две точки зрения на информационную модель и соответственно два уровня модели.
Первый уровень – логический (точка зрения пользователя). На этом уровне описываются данные, задействованные в бизнесе предприятия.
Второй уровень – физический. Определяет представление информации в базах данных, CASE-средства должны иметь возможность объединять эти уровни в единую диаграмму.
Основой любой реляционной модели являются сущности, то есть множества индивидуальных объектов. Функциональная зависимость между сущностями – это связь. Процесс построение информационной модели состоит из следующих шагов:
определение сущностей
определение зависимостей между сущностями
задание первичных и альтернативных ключей
определение атрибутов сущностей
приведение модели требуемому уровню нормальной формы
переход к физическому описанию модели, то есть назначение соответствий имя сущности и имя таблицы, атрибуты сущности и атрибуты таблицы, а также задание тригеров, процедур и ограничений.
генерация базы данных
Таким образом, создается визуальное представление или модель данных для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения как часть документации необходимой в цикле разработки.
Тестирование и отладка программ.
Тестирование – процесс выполнения программ, с целью обнаружения ошибок.
Методика, которая используется для тестирования программ, с начала 90-ч годов была разработана фирмой Microsoft – Zero Defect Minister. Основная идея – качество программ проверяется не после их написания, а в процессе разработки. Программист не может перейти к разработке нового функционального блока, если существуют известные ошибки высокого приоритета в частях, разработанных им ранее. Данная методика предъявляет высокие требования к квалификации инженера-тестирования, так как производится функциональное тестирование и тестируется организация процесса разработки.
Долгое время основным методом тестирования было тестирование методом «чёрного ящика» – программе подавались определённые данные на вход и проверялись результаты, при этом считалось несущественным, как работает программа.
Недостатки:
Невозможность найти взаимно уничтожающиеся ошибки.
Некоторые возникают достаточно редко и их трудно найти.
Потом появились методы тестирования, которые изучаю внешнее поведение программ и исходные тексты. Такие методики называю тестирование методом «белого ящика».
Основная трудность – сложность отслеживания вычислений времени выполнения программы.
Тестирование максимально эффективно в тех случаях, когда программы проверяются не только путём запуска, чтения, статистических проверок, моделирование и т. д. тестирование любая деятельность, направленная на обнаружение ошибок в программном продукте. Тестирование – затратная деятельность, поэтому в большинстве случаев разработчики ПО заранее формулируют критерий качества созданных программ, то есть определяют планку качества, добившись выполнения критерия и прекращение тестирования – концепция получившая название – Good Enouse Quality.
Best Possible Quality – более жёсткий критерий качества.
Количественный критерий качества тестирования.
Чем больше времени затрачено на разработку, тестирование и отладку, тем лучше качество программы, однако, так же существенна точка оптимального соотношения цена/качество/программа.
Проекты с небольшим количеством допустимых ошибок, являются проектами с минимальным временем выполнения.
В проектах, в которых ошибок больше минимально допустимого, тратится много времени на исправление ошибок. Оптимальное качество ПО соответствует исправлению 95% ошибок.
Практически доказано, что в проектах с высокими требованиями по времени возникает в 4 раза больше ошибок, чем обычно. Обеспечение качества продукта должно быть с начала разработки проекта, а не на последней стадии.
Концепция абсолютного качества – то есть требования к обнаружению и исправлению более 98% ошибок, замедляет проект. Оно имеет смысл, только для проектов с повышенными требованиями к надёжности.
6 (шесть сигма) – – единица стандартного отклонения при нормальном распределении в процессе или продукте. Она фиксирует максимально допустимое соотношение, количества допущенных ошибок к общему количеству возможно допустимых ошибок. Чаще всего этот критерий формулируют в терминах максимально допустимых ошибок на объём строк. Для того что бы можно было сравнивать плотность ошибок в программе, написанных на разных языках программирования, исходный код приводят к эквивалентному Assembler’овскому коду, путём применения стандартных масштабных коэффициентов.
Наиболее распространённые критерии завершения тестирования:
Истечения времени, отведённого на тестирование.
Все тесты выполнены без выявления ошибок.
Критерии, основанные на использовании определённых методологий позволяют провести исчерпывающее тестирование программных модулей. Существует несколько методов тестирования всех функций:
Метод функциональных диаграмм.
Метод анализа граничных значений.
Метод предположения об ошибке.
Полезные критерии окончания тестирования:
График ошибок.
Стоимость затрат на исправление ошибок.
Метод подсадки ошибок.
Метод тестирования двумя группами.
В
се
они основаны на статических предсказаниях
количества неисправленных или ненайденных
ошибок.
Отладка – процесс обнаружения причин возникновения ошибки и последующие исправления. В отличие от тестирования, отладка – процесс обнаружения самого факта существования ошибки. Включает в себя элементы тестирования и разработки. На некоторых проектах отладка может занимать до 50% всего времени разработки. При соответствующем подходе количество ошибок, требующих отладки, должно сократиться. Отладка не является способом улучшения качества ПО. Это способ исправления дефектов в программе. Качество программы должно обеспечиваться тщательным анализом требований, прототипированием и т. д.
Ряд исследований, подтверждающих общий принцип качества – повышение качества снижает стоимость разработки.
Критерии качества: стоимость и время могут быть оптимизированы одновременно.
При изучении своих ошибок в программе программист должен:
Понять программу, над которой работает.
Осознать свои типичные виды ошибок.
Оценить удачность подхода к решению проблем.
Оценить удачность подхода к исправлению ошибок.
Обобщённый подход к отладке программ может быть сформулирован:
Сбор данных через повторяемые эксперименты.
Создание гипотезы отражения максимума доступных данных.
Разработка эксперимента для проверки гипотезы.
Подтверждение или опровержение гипотезы.
Повторение при необходимости предыдущих шагов.
Этот подход находит отражение в отладке:
Стабилизация ошибки.
Обнаружение точного места ошибки.
Исправление ошибки.
Тестирование исправлений.
Поиск похожих ошибок.
Если проблема возникает нестабильно, то её невозможно диагностировать. Поэтому вначале стабилизируют ошибки, минимизируют тест и переходят к нахождению причины ошибки. При поиске ошибок могут быть предложены рекомендации:
Использовать все доступные данные при выдвижении гипотезы.
Минимальные тесты, показывающие ошибки.
Воспроизведение ошибок различными способами.
Использовать результаты негативных тестов.
Сужать подозрительные элементы кода, проверять процедуры, в которых встречаются ошибки.
Проверять недавние исправления.
Поставить временное ограничение.
Искать типичные ошибки.
Рассказать о проблеме кому-нибудь.
Отдохнуть.
Исправление ошибок – относительно простая задача, нужно учитывать, что 50% исправлений неправильны. Существую рекомендации по исправлению ошибок:
Разобраться в проблеме, прежде чем её исправлять.
Разобраться в самой программе.
Убедиться в правильности диагноза до исправлений.
Сохранить исходную версию кода.
Вносить изменения по одному и тогда, когда вы уверены.
Проверять все исправления.
Искать похожие ошибки.
Существует много средств, которые могут помочь при отладке, например отдатчики, они могут:
Создавать точки останова на конкретных строках кода.
Останавливаться на i-ой операции цикла.
Останавливаться при изменении значения переменной.
Останавливаться при присваивании конкретного значения.
Исследовать все данные в программе, включая типы, определённые пользователем.
Присваивать новые значения переменным.
Покоммандно выполнять программу.
Результаты исследований подтверждают общий принцип качества. Улучшение качества снижает стоимость разработки. Критерии качества: стоимость и время - могут быть оптимизированы одновременно.
При изучении своих ошибок в программах программист должен: 1)понять программу, над которой работает; 2) осознать свои типичные виды ошибок; 3)оценить удачность своего подхода к решению проблем; 4) оценить удачность своего подхода к решению ошибок.
Обобщенный подход к отладке программ может быть сформулирован следующим образом.
1)Сбор данных через повторяемые эксперименты.
2) Создание гипотезы, отражающей максимум доступных данных.
3) Разработка эксперимента для проверки гипотезы.
4) Подтверждение или опровержение гипотезы.
5) При необходимости повторение предыдущих шагов.
Этот подход находит следующее отражение в отладке:
1)Стабилизация ошибки.
2) Обнаружение точного места ошибки.
3) Исправление ошибки.
4) Тестирование, исправление.
5) Поиск похожих ошибок.
Если проблема возникает нестабильно, те ее практически невозможно диагностировать, поэтому сначала необходимо стабилизировать ошибку, минимизировать тест, а затем перейти к нахождению причины ошибки.
При поиске ошибок могут быть предложены следующие рекомендации:
1)Использовать все доступные данные при выдвижении гипотез.
2) Минимизировать тесты, показывающие ошибки.
3) Воспроизвести ошибку различными способами.
4) Использовать результаты негативных тестов.
5) Сужать подозрительные фрагменты кода.
6) Проверить процедуры, в которых уже встречались ошибки.
7) Проверить недавние исправления.
8) Поставить временные ограничения.
9) Искать типичные ошибки.
Исправление ошибок – относительно простая задача, но нужно учитывать, что примерно 50% исправлений неправельны, поэтому существуют следующие рекомендации по исправлению ошибок:
1)Разобраться в проблеме, прежде чем ее исправлять.
2) Разобраться в самой программе.
3) Необходимо убедиться в правельности диагноза до исправления.
4) Необходимо сохранять исходную версию кода.
5) Необходимо вносить изменения по одному и только тогда, когда вы уверены.
6) Необходимо проверять все исправления.
7) Необходимо искать похожие ошибки.
Существует множество средств, которые могут помочь при отладке. В первую очередь это отладчики, которые могут:
Создавать точки останова на конкретных точках кода.
Останавливаться на I-ой операции цикла.
Останавливаться при изменении переменных.
Останавливаться при присваивании конкретного значения .
Исследовать все данные в программе, включая типы, определенные пользователями.
Присваивать новое значение переменным.
По командно выполнять программу.