С. В. Чувиков Метрология и сертификация программного обеспечения Учебное пособие

Вид материала

Учебное пособие

Содержание Внутри каждой фазы и в целом по проекту процессы организованы в пять групп Процессы Инициирования Процессы Окончания Начало Время Окончание На какие основные области разбиваются процессы с точки зрения «управления проектами»? Неудачи реализации всех проектов обычно имеют общую природу. Наиболее характерные причины Старт проекта Стадийный контроль Управление соз-данием продукта Запуск проекта Процесс управления границами Процесс стадийного контроля Процесс управления созданием продукта Процесс завершения проекта Процесс планирования Методология совершенствования бизнес-процессов. Фаза ПЕРЕПРОЕКТИРОВАНИЯ БИЗНЕС ПРОЦЕССОВ Международный стандарт ИСО-ИЭК 15504. Информационные Процессы создания (разработки) Поддерживающие процессы ... Полное содержание

Подобный материал:

• М. В. Ломоносова Кафедра стандартизации и сертификации Федорина Л. И., Хомутова, 1360.41kb.
• Методические указания «Выполнение практических заданий по дисциплине «Метрология, стандартизация, 636.89kb.
• Учебное пособие, 2003 г. Учебное пособие разработано ведущим специалистом учебно-методического, 794.09kb.
• Учебное пособие, 2003 г. Учебное пособие разработано ведущим специалистом учебно-методического, 454.51kb.
• Учебное пособие, 2003 г. Учебное пособие разработано ведущим специалистом учебно-методического, 783.58kb.
• Метрология, стандартизация и сертификация. Вопрос № «Предмет и задачи метрологии»., 380.7kb.
• Метрология и качество программного обеспечения, 39.54kb.
• О. В. голуб Стандартизация, сертификация и метрология Учебное пособие, 3396.24kb.
• Рабочей программы дисциплины Метрология, стандартизация и сертификация (наименование), 31.06kb.
• Вопросы по дисциплине «Метрология, стандартизация и сертификация» для подготовки, 69.28kb.

Как правило, для удобства управления, проекты разбиваются на несколько фаз. Все фазы вместе называются Цикл Жизни Проекта (Project Life Cicle).

Внутри каждой фазы и в целом по проекту процессы организованы в пять групп:

1.	Процессы Инициирования	• принятие решения о начале проекта или фазы
2.	Процессы Планирования	• создание и поддержка рабочей схемы для достижения бизнес-целей проекта
3.	Процессы Выполнения	• координация людских и других ресурсов в соответствии с планом
4.	Процессы Управления	• мониторинг хода выполнения и принятие необходимых действий по корректировке
5.	Процессы Окончания	• формальное принятие решения о завершении фазы или проекта

Рисунок 3 показывает наложение групп процессов в пределах одной фазы.


Методология управления проектами PRINCE/PRINCE2

Методология управления проектами PRINCE/PRINCE2 является стандартом управления проектами в Великобритании, ее применение обязательно в государственных проектах. Столь необычное название методологии является аббревиатурой от ее полного названия Projects In Controlled Environents, и ее название отражает ее предназначение – управление проектами и группами проектов внутри организации. Метод управления проектами PRINCE2 определяет организацию, управление и контроль над исполнением проектов. PRINCE2 был разработан агентством ССТА (Central Computer and Telecommunications Agency) в 1989 как правительственный стандарт Великобритании для управления проектами в информационных технологиях. В настоящее время PRINCE2 применяется в качестве стандарта управления проектами в Великобритании, Бельгии, Нидерландах, Люксембурге, Австралии, Новой Зеландии, Гонконге, Сингапуре, Малайзии, ЮАР, Хорватии, Польше и некоторых других странах. Наибольшее распространение PRINCE2 получил в государственном секторе, в финансовой, телекоммуникационной и электронной отраслях. Важной особенностью стандарта PRINCE2 является именно его изначальная ориентация на управление IT – проектами.

Неудачи реализации всех проектов обычно имеют общую природу. Наиболее характерные причины:

• недостаток координации ресурсов и действий;

• слабые связи с заинтересованными сторонами, что приводит к неудовлетворенности клиентов:

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

• неадекватное планирование ресурсов и действий;

• некачественный мониторинг проекта, отклонения выявляются слишком поздно;

• недостаточный контроль качества продукта.

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

• проект представляется конечным процессом с определенным временем старта и завершения;

• проект всегда требует управления для достижения успешных результатов;

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

Основными особенностями PRINCE2 являются:

1. планирование, основанное на продуктовом подходе,

2. деление проекта на управляемые и контролируемые стадии,

3. гибкость применительно к масштабам проекта,

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

PRINCE2 включает в себя восемь основных компонент:

1. организация,

2. планирование,

3. контроль,

4. стадийность,

5. управление рисками,

6. качество,

7. управление конфигурациями,

8. управление изменениями.

Кроме вышеперечисленного, данный стандарт описывает следующие основные процессы:

1. начало проекта,

2. инициация,

3. управление,

4. контроль стадий,

5. управление продуктом,

6. управление границами стадий,

7. закрытие проекта,

8. планирование.

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

Руководство корпорацией или программой

«Навигация» в ходе проекта

Проектные полномочия

Старт проекта

Инициация проекта

Стадийный контроль

Управление гра-ницами стадий

Завершение проекта

Управление соз-данием продукта

Планирование

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

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

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

1. обеспечение проектной группы доступом к необходимой информации;
   
2. создание группы руководства проектом;
   
3. создание плана стадии инициации.
   

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

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

• создание стабильной управленческой основы для исполнения проекта;

• подготовка ресурсов для первоначальной стадии проекта;

• контроль планирования трудоемкости и эффективных затрат времени в ходе проекта.

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

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

• определения подлежащих решению задач,

• сбора информации о ходе выполнения соответствующей работы,

• фиксирования изменений,

• обзора ситуации,

• предоставления отчетов,

• предпринятия необходимых корректирующих действий.

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

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

• производится контроль за процессом создания,

• производится последовательная корректировка прогнозов по времени выполнения (срокам выполнения),

• действует контроль качества,

• создаваемые продукты представляются для одобрения заказчиком.

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

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

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

• Управляемыми и организованными началом, серединой и завершением;

• Корректной и своевременной информацией о ходе работ по проекту во временных контрольных точках;

• Автоматическим управлением любыми отклонениями от плана;

• Вовлечением управленцев и исполнителей в проект в нужное время и в нужном месте;

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

Вопросы:

Перечислите основные, возможные причины неудач реализации процессов.

Какие основные принципы заложены в методологии PRINCE2?

Какими особенностями обладает PRINCE2?

Какие основные компоненты и процессы описывает стандарт PRINCE2?

На чем базируется работа над процессом?

Какие цели ставит перед собой инициализация проекта?

Чем обеспечивает стандарт PRINCE2 проекты?


Методология совершенствования бизнес-процессов.

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

Изменение процессов необходимо, если выполнено хотя бы одно из следующих условий:

У предприятия значительно изменились или расширились цели;

4. Существенно изменились нужды, требования или желания клиентов;
   
5. Критерии эффективности показывают, что производительность существенно ниже текущих стандартов.
   

На рисунке 5 изображена зависимость основных процессов ВРI от внешних факторов:

Внешняя Среда - процессы, находящиеся за пределами влияния процессов ВРI;

Организационная Инфраструктура поддерживается существующими процессами;

Технологическая Инфраструктура обеспечивает информационную платформу и коммуникации для существующих процессов.

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


Вешняя среда

Организационная инфраструктура

Фаза ОГРАНИЗАЦИОННЫХ ИЗМЕНЕНИЙ

Фаза стра-теги-ческо-го и бизнес плани-рова-ния

Фаза реали-зации проек-та

Фаза ПЕРЕПРОЕКТИРОВАНИЯ БИЗНЕС ПРОЦЕССОВ

Фаза СОЗДАНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

Фаза ТЕХНИЧЕСКИХ ИЗМЕНЕНИЙ

Технологическая инфраструктура.

Социально-экономическая Геополитическая Технологическая.


Рисунок 5 – Этапы (фазы) совершенствования бизнес-процессов

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

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

В зависимости от результатов анализа, выбирается один из трех уровней совершенствования бизнес-процессов:

• непрерывное улучшение;

• модернизация бизнес-процессов;

• перепроектирование (радикальное совершенствование).

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

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

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

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

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

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

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

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

Идеология непрерывного совершенствования подразумевает установление системы руководства и управления, культуры функционирования бизнес-процессов, обращенных в первую очередь на удовлетворение требований клиентов. Обычно методологию непрерывного совершенствования процессов связывают с технологией общего управления качеством (Total Quality Management – TQM), еще одним, наряду с перепроектированием бизнес-процессов, подходом к преобразованию предприятий в рамках данной методологии. Технология управления качеством призывает не дожидаться, пока проблема возникнет, но предотвратить ее.

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

Вопросы:

При каких условиях необходимо изменение бизнес-процессов предприятия?

Назовите три основных условия совершенствования бизнес-процессов?


Технология CASE проектирования информационных систем и методология IDEF моделирования бизнес-процессов (Computer Aided System Engineering (CASE) Integrated DEFinition (IDEP)).

Современное проектирование сложных информационных систем использует новые информационные технологии и программные средства поддержки системного инжиниринга – CASE технологии и средства.

В основе CASE технологий лежат соответствующие методы и методики, описывающие различные свойства систем, важные, например, с точки зрения их автоматизации, а также позволяющие количественно оценить параметры проектов. Следует отметить, что спектр, свойств систем различного назначения очень широк, и не все они к настоящему времени отражены в адекватных моделях. В то же время для класса информационных систем организационного типа (Management Information Systems - MIS) адекватные модели разработаны и поддерживаются соответствующими средствами автоматизации.

Методология IDEF моделирования. Взаимная совокупность методик и моделей концептуального проектирования IDEF (Integrated DEFinition) разработана в США по программе Integrated Computer-Aided Manufacturing. В настоящее время имеются методики функционального, информационного и поведенческого моделирования и проектирования, в которые входят IDEF-модели, приведенные ниже.

Название	Назначение
IDEF0	Функциональное моделирование (Function Modeling Method)
IDEF1 и IDEF1X	Информационное моделирование (Information and Data Modeling Method)
IDEF2	Поведенческое моделирование (Simulation Modeling Method)
IDEF3	Моделирование деятельности (Process Flow and Object Stale Description Capture Method) деятельности
IDEF4	Объектно-ориентированное проектирование (Object-oriented Design Method)
IDEF5	Систематизация объектов приложения (Ontology Description Capture Method)
IDEF6	Использование рационального опыта проектирования (Design Rational Capture Method)
IDEF8	Взаимодействие человека и системы (Human-System Interaction Design)
IDEF9	Учет условий и ограничений (Business Constraint Discovery)
IDEF14	Моделирование вычислительных сетей (Network Design)

IDEF0 реализует методику функционального моделирования сложных систем. Наиболее известной реализацией IDEF0 является методология SADT (Structured Analysis and Design Technique), предложенная еще в 1973 г. Д. Россом и впоследствии ставшая основой стандарта IDEF0. Эта методика рекомендуется для начальных стадий проектирования сложных искусственных систем управления, производства, бизнеса, включающих людей, оборудование, программное обеспечение.

IDEF1X и IDEF1 реализуют методики инфологического проектирования баз данных. В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях, так называемый язык диаграмм "сущность-связь" (ERD - Entity-Relations Diagrams). Разработка информационной модели по IDEF1X выполняется в несколько этапов:

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

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

• выявляются и определяются основные отношения, результаты представляются графически в виде так называемых ER-диаграмм;

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

• определяются атрибуты сущностей.

IDEF2 и IDEF3 реализуют поведенческое моделирование. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопрос: "Что делает эта система?", то в этих методиках детализируется ответ: "Как система это делает". В основе поведенческого моделирования лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри, возможно применение модели конечного автомата, описывающей поведение системы как последовательность смен состояний. Перечисленные методики относятся к так называемым структурным методам.

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

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

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

IDEF8 предназначен для проектирования диалогов человека и технической системы.

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

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

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

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

Информационная модель отображает отношения между элементами системы в виде структур данных (состав и взаимосвязи).

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

Вопросы:

Что лежит в основе CASE-технологий?

Перечислите и охарактеризуйте каждый из видов методологии IDEF моделирования?

Какие этапы включает в себя разработка информационной модели по IDEF1Х?

Что описывает функциональная модель системы?

Что описывает информационная модель системы?

Чем характеризуется поведенческая модель системы?


Международный стандарт ИСО-ИЭК 15504. Информационные

технологии – оценка процессов разработки программного обеспечения.

Данный стандарт предназначен для оценки процессов, так или иначе

связанных с ПО.

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

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




Определяет подлежит Определяет

изменения в… рассмотрению подходящие…







руководит руководит




мотивирует





Рисунок 6 Оценка процессов разработки программного обеспечения.


Рассмотрим, каким образом делятся процессы в соответствии со стандартом ИСО-ИЭК 15504:

Архитектура процессов:

Процессы Заказчик-Поставщик: • Заказ (выбор поставщика, управление, подтверждение);

• Поставка;

• Определение требований.

Процессы создания (разработки):

• Разработка (анализ требований к системе, анализ требований к ПО, проектирование, разработка ПО, интеграция ПО, тестирование ПО, интеграция и тестирование системы);

• Поддержка системы и ПО.

Поддерживающие процессы:

• Документирование;

• Управление конфигурацией;

• Обеспечение качества;

• Проверка и подтверждение;

• Совместный обзор;

• Аудит;

• Разрешение проблем;

• Повторное использование процессов.

Организационные процессы:

• Совершенствование (определение, оценка и улучшение);

• Управление людскими ресурсами;

• Инфраструктура.

Управление:

• Управление проектами;

• Управление качеством;

• Управление риском.

Вопросы:

Для чего предназначен стандарт ИСО-ИЭК 15504?

Каким образом подразделяются процессы на предприятии в соответствии со стандартом ИСО-ИСЭ 15504?


Международный стандарт ИСО - ИЭК 12207.

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

ПО представляет собой немаловажную самостоятельную часть современных продуктов и систем. Как и в любой другой области, отсутствие единой дисциплины производства ПО приводит к снижению качества продукта, необоснованному увеличению цены и сроков. Для решения этих проблем в 1987 году «Интернациональная Организация по Стандартизации» (ISO) приступила к разработке единого стандарта на разработку ПО, охватывающего весь жизненный цикл программных продуктов. Труды экспертов, представляющих транснациональные корпорации, национальные академии и правительственные организации, опирающиеся на опыт работы предприятий ведущих стран мира, воплотились в этом стандарте. Трудоемкость проекта составляет более 17,000 человеко-часов, его стоимость превышает 1.5 миллиона долларов.

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

Процесс заказа

З
П

О

Д

Д

Е

Р

Ж

И

В

А

Ю

Щ

И

Е


П

Р

О

Ц

Е

С

С

Ы


аказчик

Поставщик Контрактный вид

Процесс поставки

Процесс функционирования

Оператор

Пользователь Операционный вид

Процесс поддержки

Процесс разработки

Разработчик

Поддержка Инженерный вид

Документирование Управление конфигурацией Обеспечение качества Проверка и Подтверждение Совместный обзор Аудит Разрешение проблем

Сотрудники

Поддержки Поддерживающий вид

Организационные процессы

Менеджер Корпоративный вид

Рисунок 7 Процессы жизненного цикла программного обеспечения

Основные процессы жизненного цикла ПО:

1. Основные (базовые) процессы:

• Процесс заказа;

• Процесс разработки;

• Процесс поставки;

• Процесс сопровождения.

2. Процессы, поддерживающие жизненный цикл:

• Процесс документирования;

• Процесс управления конфигурацией;

• Процесс обеспечения качества;

• Процесс проверки соответствия;

• Процесс объединенных обзоров;

• Процесс ревизии;

• Процесс решения проблем.

3. Организационные процессы жизненного цикла:

• Процесс управления;

• Процесс поддержки инфраструктуры;

• Процесс совершенствования;

• Процесс обучения.

Вопросы:

Для чего предназначен стандарт ИСО-ИЭК 12207?

Перечислите основные процессы жизненного цикла ПО в соответствии со стандартом ИСО-ИЭК 12207?


Концепции ERP, MRP, MRPII, CSRP в современных информационных системах.

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

Система качества как часть системы управления предприятием может эффективно работать и приносить наибольшую выгоду, если ее поддерживают современные информационные системы поддержки принятия управленческих решений, разработанные и внедренные на предприятии в строгом соответствии со спецификой его запросов, уровнем развития, а внедрение АСУ и системы качества происходит взаимоувязано. Современные системы должны поддерживать концепции ERP, MRP, MRPII, CSRP – технологий. Основная цель концепции MRP заключается в минимизации издержек, связанных со складскими запасами (в том числе и на различных участках производства). В основе этой концепции лежит понятие ВОМ (Bill Of Material – спецификация изделия, ответственность за которую возложена на конструкторский отдел), отражающее зависимость спроса на сырье, полуфабрикаты и другие продукты от плана выпуска готовой продукции. При этом очень важную роль играет время, для учета которого необходимо иметь четкое представление о технологической цепочке выпуска продукции, то есть знать, какова последовательность и длительность операций.

Однако у концепции MRP есть серьезный недостаток. Дело в том, что при расчете в рамках этой концепции потребности в материалах не учитываются ни имеющиеся производственные мощности, ни их загрузка, ни стоимость рабочей силы. Этот недостаток был исправлен в концепции MRPII (Manufacturing Resource Planning – планирование производственных ресурсов). MRPII позволяла учитывать и планировать все производственные ресурсы предприятия – сырье, материалы, оборудование, персонал и т.д. По мере развития концепции MRPII к ней постепенно добавлялись возможности учета

остальных затрат предприятия. Так появилась еще одна концепция – ERP (Enterprise Resource Planning – оценка ресурсов предприятия), называемая иногда также планированием ресурсов в масштабе предприятия (Enterprise-wide Resource Planning). В основе ERP лежит принцип создания единого хранилища данных (депозитария), содержащего всю деловую информацию, накопленную организацией в процессе ведения бизнеса, в частности финансовую информацию, данные, связанные с производством, управлением персоналом, и любые другие данные. Наличие депозитария избавляет от необходимости передавать данные от приложения к приложению. Кроме того, любая часть информации, которой располагает данная организация, становится одновременно доступной для всех работников, обладающих соответствующими полномочиями.

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

В настоящее время практически все современные западные системы управления производством базируются на концепции ERP и отвечают ее рекомендациям. Эти рекомендации вырабатываются американской общественной организацией APICS, объединяющей производителей, консультантов в области управления производством, а также разработчиков ПО. К сожалению, большинство современных российских систем управления производством не отвечают даже требованиям MRP, не говоря уже о других, более сложных концепциях.

Самый новый из стандартов систем управления предприятиями – CSRP (Customer Synchronized Resource Planning), помимо всего прочего, охватывает и взаимодействие с клиентами, оформление нарядов/заказов и технических заданий, поддержку заказчика на местах и т.д. Таким образом, если стандарты MRP, MRPII и ERP ориентированы на внутреннюю организацию предприятия, то стандарт CSRP включает в себя полный цикл – от проектирования будущего изделия, с учетом требований заказчика, до гарантийного и сервисного обслуживания после продажи. Суть концепции CSRP главным образом состоит в том, чтобы интегрировать заказчика (клиента, покупателя) в систему управления предприятием. Согласно данной концепции не отдел сбыта, а непосредственно сам покупатель размещает заказ на изготовление продукции, сам отвечает за правильность его исполнения и, при необходимости, отслеживает соблюдение сроков производства и поставки. При этом само предприятие может очень четко отслеживать тенденции спроса на его продукцию.

На мировом рынке сейчас предлагается свыше 500 систем класса MRPII –ERP. Развитие этого рынка идет очень быстрыми темпами – число внедрений таких систем в мире растет на 35-40% в год. На отечественном же рынке сейчас присутствуют около десятка западных систем и три–четыре отечественные системы класса КИС (корпоративные информационные системы).

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

Для компаний среднего уровня (или имеющих не слишком диверсифицированный бизнес) больше подходят другие системы класса ERP. До последнего времени поступающая о них информация была довольно скудной, и их потенциальные потребители чаще всего не знали, на кого они рассчитаны. Здесь речь идет о западных продуктах для самого массового сегмента рынка – среднего и малого бизнеса, то есть для компаний с годовым оборотом от 5 до 10 млн. долл. и количеством работающих от 100 до 1000 человек. Основное отличие ERP-систем среднего уровня от ERP-систем для крупных предприятий состоит в ограниченности решаемых задач и относительной простоте используемых технологий. Обычно эти системы поддерживают несколько определенных видов промышленной деятельности и имеют ограниченное число возможных пользователей. Однако и стоимость проекта по внедрению такой системы составляет от 50 до 250 тыс. долл., что вполне соответствует масштабам бизнеса малых и средних предприятий.

Любое предприятие представляет собой сложную систему. Даже небольшую компанию нелегко увидеть во всех деталях. Более крупные предприятия фактически непостижимы: никто не имеет достаточно ясной картины, охватывающей абсолютно все детали. Поистине удивительно, что крупные компании могут довольно успешно функционировать. Впрочем, тому можно найти несколько причин. Самая главная из них состоит в том, что компании, несмотря ни на что, меняются довольно медленно (инерционно) и согласованно. По мере того как сами люди совершенствуются, происходят перемены в компании, причем лишь в той степени, в какой люди чувствуют себя способными осознать последствия. До тех пор пока компания не меняется радикально, свойственная ей инерция помогает ей функционировать. Но если компания встречается с трудностями, и ей предстоят радикальные перемены, то существует серьезная опасность, что люди не смогут как следует понять, «что они делают», «почему они делают это», «могут ли они делать что-либо другое».

Государственные и отраслевые стандарты определяют порядок реализации бизнес-процессов в соответствии с государственной нормативной базой и спецификой конкретной отрасли.

В ряде случаев, соблюдение отдельных ГОСТов и ОСТов является обязательным требованием при реализации информационных проектов.

К ГОСТам определяющим порядок и требования создания информационных систем относятся, в частности ГОСТ 34.602-89 "Информационная технология. Техническое задание на создание автоматизированной системы", ГОСТ 34.601-90 "Информационная технология. Автоматизированные системы. Стадии создания", ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных систем».

Вопросы:

В чем заключается основная цель концепции MRP на предприятии?

В чем заключается отличия между MRP и MRPII концепций?

Что содержится в основе создания концепции ERP?

Охарактеризуйте отличительные свойства концепции CSRP от других концепций.


Современные системы проектирования, обеспечивающие соответствие разработанной модели предприятия принципам стандартов качества.


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

1) состав и структура данных, описывающих атрибуты класса и соответствующих объектов;

2) совокупность методов – процедур, определяющих взаимодействие объектов этого класса с внешней средой.

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

Хорошие методы моделирования и инструментальные средства значительно уменьшают риск ошибочного построения информационной модели (ИМ) предприятия. Для описания архитектуры используют понятие «подсистема». Если бизнес очень большой, имеет смысл определить несколько уровней подбизнеса – функций. Подсистема должна включать в себя функционально близкие объекты и (или) подсистемы. При этом объект или подсистема не может принадлежать более чем к одной подсистеме. Деление на подсистемы следует проводить тогда, когда бизнес настолько велик, что его необходимо моделировать не весь сразу, а постепенно. Кроме того, выделение подсистем целесообразно использовать, чтобы сделать модель понятнее. Подсистемы можно использовать для объединения объектов в модули, соответствующие полномочиям некоторого специалиста, отвечающего за одну или более задач.

При разработке подсистем бизнеса можно показать используемые общие бизнес-объекты, но нельзя вносить в них какие бы то ни было изменения. Можно изменять только свои собственные объекты, т.е. объекты, реализующие данную бизнес-подсистему. Если должен измениться общий бизнес-объект, то все бизнес-подсистемы, использующие этот объект, должны быть одновременно изменены. Для обеспечения всех функций предприятия необходима мощная технология разработки информационных систем, которая должна включать в себя методики распределенных систем – от простых «клиент-сервер» приложений до сложных географически распределенных систем. Созданные на основе этой технологии информационные системы должны быть гибкими и легко модифицируемыми, позволяющими отслеживать непрерывные изменения в бизнесе. В настоящее время общепризнанно, что при построении и внедрении информационных систем необходимо использовать объектно-ориентированную технологию.

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

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

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

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

– элементы модели – фундаментальные концепции моделирования и их семантику;

– нотацию – визуальное предоставление элементов моделирования;

– принципы использования – правила применения элементов в рамках построения тех или иных типов моделей ИС.

Среди современных средств визуального моделирования наиболее известны и применяемы следующие: ERwin LinkObject API, ERwin Examiner, ModelMart, Paradigm Plus, Arena, Rational Rose.

ERwin LinkObject API – новый продукт CA, позволяющий обращаться к моделям ERwin, хранящимся в ModelMart или ERI-файлах из приложений. ERwin API – независимый от языка программирования, основанный на технологии СОМ программный интерфейс, который предоставляет эффективный доступ к моделям ERwin с использованием сервисов Model Management Services. Он предоставляет полный доступ (read/write) к метаданным ERwin, и, поскольку он базируется на СОМ, то позволяет пользователям выбрать тот язык программирования, который лучше подходит для их приложений.

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

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

ModelMart – это первая многопользовательская среда моделирования со свойствами реального мира, которая обеспечивает координацию крупномасштабного моделирования. ModelMart позволяет координировать действия руководителя проекта, проектировщиков на ERwin и BPwin и администраторов путем предоставления сервисов, включая разрешение конфликтов, контроль версий, безопасность и стандартизацию.

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

Arena – разработанное компанией Systems Modeling Corporation программное обеспечение для имитационного моделирования позволяет создавать подвижные компьютерные модели, используя которые можно адекватно представить очень многие реальные системы. Самая первая версия этой системы увидела свет в 1993 г. Arena снабжена удобным объектно-ориентированным интерфейсом и обладает удивительными возможностями по адаптации ко всевозможным предметным областям. В целом система исключительно проста в использовании. В ней удачно соединены интерфейсные возможности среды Windows и присущая Arena легкость иерархического построения модели и ее последовательного приближения к реальному объекту.

Rational Rose – средство визуального моделирования объектно-ориентированных информационных систем компании Rational Software Corp. Работа продукта основана на универсальном языке моделирования UML (Universal Modeling Language). Благодаря уникальному языку программирования Rose способна решать практически любые задачи в проектировании информационных систем: от анализа бизнес-процессов до кодогенерации на определенном языке программирования. Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое.

Вопросы:

В чем состоят преимущества визуальной информационной модели предприятия?

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

Метрология и сертификация программного обеспечения

Учебное пособие


Чувиков Сергей Владимирович

Ответственная за выпуск

директор издательства РГЭУ Смейле В. Е.

Лицензия ЛР № 020276 от 18.02.97 г.

Государственного Комитета Российской Федерации по печати

Изд. № Подписано к печати Объем 3 уч.-изд. л.

Бумага офсетная. Печать офсетная. Формат 60 x 84 / 16.

Гарнитура Таймс. Заказ № . Тираж экз. «50 » .

344007, Ростов-на-Дону, ул. Б. Садовая, 69, РГЭУ. Издательство.

Отпечатано в ОПП при издательстве.