Реинжиниринг бизнес-процессов.

Тема 9. Проектирование КИС.

 

1. Жизненный цикл КИС. Модели жизненного цикла КИС: каскадная, спиральная.

2. Этапы проектирования КИС.

3. Реинжиниринг бизнес-процессов.

4. Моделирование бизнес-процессов.

5. Обзор систем автоматизированного проектирования КИС. CASE-технологии.

 

Жизненный цикл КИС. Модели жизненного цикла КИС: каскадная, спиральная.

 

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

Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 "Information Technology -Software Life Cycle Processes" (ISO - International Organization for Standardization - Международная организация по стандартизации, IEC – International Electrotechnical Commission — Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. В данном стандарте ПО (или программный продукт) определяется как набор компьютерных программ, процедур и, возможно, связанной с ними документации и данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами. Каждый процесс разделен на набор действий, каждое действие — на набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения (естественно, при сохранении связей по входным данным).

В соответствии со стандартом ISO/IEC 12207 все процессы ЖЦ ПО разделены на три группы:

1. пять основных процессов (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

3. четыре организационных процесса (управление, создание инфраструктуры, усовершенствование, обучение).

Под моделью ЖЦ ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Модель ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПО. Стандарт Жизненный цикл описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ любого конкретного ПО ЭИС определяет характер процесса его создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ, выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям. Под стадией создания ПО понимается часть процесса создания ПО, ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта (моделей ПО, программных компонентов, документации), определяемого заданными для данной стадии требованиями. Стадии создания ПО выделяются по соображениям рационального планирования и организации работ, заканчивающихся заданными результатами. В состав жизненного цикла ПО обычно включаются следующие стадии:

1. Формирование требований к ПО.

2. Проектирование.

3. Реализация.

4. Тестирование.

5. Ввод в действие.

6. Эксплуатация и сопровождение.

7. Снятие с эксплуатации.

В однородных КИС 70-х и 80-х гг. прикладное ПО представляло собой единое целое. Для разработки такого типа ПО применялся каскадный подход (другое название — водопад (waterfall)). Принципиальной особенностью каскадного подхода является следующее: переход на следующую стадию осуществляется только после того, как будет полностью завершена работа на текущей стадии, и возвратов на пройденные стадии не предусматривается. Каждая стадия заканчивается получением некоторых результатов, которые служат в качестве исходных данных для следующей стадии. Требования к разрабатываемому ПО, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является точность выполнения спецификаций технического задания.

При этом основное внимание разработчиков сосредоточивается на достижении оптимальных значений технических характеристик разрабатываемого ПО: производительности, объема занимаемой памяти и др.

Преимущества применения каскадного способа заключаются в следующем:

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

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

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

Для преодоления перечисленных проблем в середине 80-х гг.была предложена спиральная модель ЖЦ.

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

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

 

Этапы проектирования КИС.

 

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

Документ, полученный в результате проектирования, носит название проект.

Цель проектирования – подбор технического и формирование информационного, математического, программного и организационно-правового обеспечения.

Этапы развития КИС:

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

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

1. Анализ первичных требований и планирование работ.
         Оценить 1) преимущества внедрения данной системы
                        2) временные затраты
                        3) обосновать стоимость

2. Проведение обследования деятельности предприятия.
         Определение организационной и топологической структуры предприятия, бизнес-процессов, анализ распределения функций по подразделениям и сотрудникам, уровня автоматизации и др.

3. Построение и анализ моделей деятельности предприятия.
         Строятся 2 модели на языке IDEF0 – „модель как есть“ и «модель как будет». Переход от одной модели к другой осуществляется обычно 2-мя путями:
          1) совершенствованием технологии на основе оценки эффективности («мягкий» реинжениринг)
           2) радикальным изменением технологии и переосмыслением бизнес-процесса («жесткий» реинжениринг).

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

Разделы технического задания:

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

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

Этап разделяется на 2 стадии:

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

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

1. Создание рабочего проекта.

На данном этапе осуществляется:
1) разработка рабочей документации:

– пояснительной записки
    – функциональной и организационной структуры

– должностных инструкций

– инструкций по заполнению входных оперативных документов

– инструкций по использованию выходных документов

– инструкции по организации и ведению нормативно-справочной документации

– инструкции по организации хранения информации в архиве

– инструкции по подготовке информации к вводу в ПК

– Расчет экономической эффективности системы

– мероприятия по подготовке объекта к внедрению

– ведомость документов.

2) разработка программных средств

разрабатывается новое ПО или производится привязка и адаптация приобретенного ПО к конкретным условиям

 

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

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

 

 

Реинжиниринг бизнес-процессов.

 

Мы имеем производство и хотим сделать его еще лучше. В каком смысле лучше? Больше продукции за меньшее количество времени? Высококачественная продукция с меньшим количеством несоответствий? Более высокая удовлетворенность потребителя? Более высокая рентабельность? Меньше стадий обработки? Больше продукции на одного рабочего? И т.д., и т.п. Все это аспекты лучшего производства. Как всего этого добиваться? Для этого надо думать о производстве в целом как о системе. Система – совокупность взаимосвязанных частей, объединенных по признаку описываемого процесса. В процессе и системном подходе заключается ключ к пониманию. В соответствии с концепцией менеджмента качества и реинжиниринга путь к улучшению производства кроется в совершенствовании процессов, а условием его улучшения являются его «прозрачность». Это объединяет менеджмент качества и реинжиниринг деловых процессов.

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

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

В Японии эти подходы к управлению компанией получили название «кайцен» и «кайрио» соответственно. Очевидно, что их нельзя ставить на один уровень и соответственно сравнивать, какой подход лучше. Менеджмент качества первичен по отношению к реинжинирингу бизнес процессов. Реинжиниринг эффективен только тогда, когда «внутренние резервы» исчерпаны, т.е., когда невозможно «здесь и сейчас» предложить более высокое качество за более низкую цену. Налицо циклическая схема руководства организацией, использующая оба этих подхода:

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

·   затем, когда К.П.Д. процессов доведен до 100%, т.е. из процессов «выжато» все, что можно, следует вторая фаза – реинжиниринг, как кардинальная перестройка делового процесса.

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

Майкла Хаммер и Джеймс Чампи в книге «Реинжиниринг корпорации: Манифест революции в бизнесе», адресованной, прежде всего, предпринимателям и управляющим, показывают, что конкурентоспособность и экономическая жизнестойкость компаний должна быть основана на принятии новых моделей и практики управления, и промышленной организации. В качестве метода воссоздания существующих корпораций авторы предлагают реинжиниринг бизнеса, который, по их мнению, для новой революции в бизнесе означает то же, что специализация труда означала для предыдущей.

 

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

В этом определении содержатся четыре ключевых слова.

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

Осуществляя реинжиниринг, предприниматель должен поставить на повестку дня основополагающие вопросы, касающиеся его компании и характера ее деятельности: «Почему мы занимаемся тем, чем занимаемся? И почему мы это делаем именно так?». Задаваясь подобными фундаментальными вопросами, люди часто бывают вынуждены новыми глазами взглянуть на сложившиеся негласные правила и предположения, исходя из которых они руководят своим бизнесом.

Второе ключевое слово в определении — это «радикальный», которое является производным от латинского «radix», что значит «корень». Радикальное перепроектирование означает обращение к самым корням явлений: не проведение косметических изменений и не перетасовку уже существующих систем, а решительный отказ от всего отжившего. Радикальное перепроектирование при реинжиниринге сбрасывает со счетов все существующие структуры и методы и предполагает изобретение совершенно новых способов работы. Осуществить реинжиниринг бизнеса — это все равно что создать бизнес заново.

Третье ключевое слово — это «существенный». Реинжиниринг не имеет ничего общего с небольшими частичными или приростными улучшениями, он призван обеспечить общий мощный рост результативности. Если показатели компании лишь на 10% отстают от намеченных, если ее затраты превышаются на 10%, а качество оказывается на 10% ниже положенного, если обслуживание клиентов должно осуществляться на 10% оперативнее — такая компания вовсе не нуждается в реинжиниринге. Из этой десятипроцентной ямы компанию вполне могут «вытащить» более традиционные методы, например, призыв к подразделениям разработать программы по улучшению качества и так далее. Реинжиниринг нужен только тогда, когда ощущается потребность осуществить серьезный прорыв.

Четвертое ключевое слово в определении, данном авторами, — «процессы» — будучи наиболее важным, однако является именно тем понятием, которое представляет главную трудность для большинства руководителей корпораций. Основная часть бизнесменов вовсе не «ориентирована на процесс»: они сосредоточены на задачах, на отдельных операциях, на людях, на структурах, но никак не на процессах.

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

 


Дата добавления: 2018-04-15; просмотров: 185; Мы поможем в написании вашей работы!

Поделиться с друзьями:




Мы поможем в написании ваших работ!