Объектно-ориентированный анализ и проектирование программного обеспечения для улучшения качества продуктов методом бенчмаркинга G3:ID

Таким образом, бенчмаркинг G3:ID позволяет формулировать задачи совершенствования системы не через  улучшение параметров, а через  перенос необходимых свойств  одной системы другой, через объединение  альтернативных систем. Это переводит процесс разработки продуктов на качественно новый уровень инноваций.

Бенчмаркинг G3:ID является уникальным инструментом, позволяющим  сравнивать конкурирующие системы  с учетом потенциала развития. Это  позволяет проводить сравнение систем, имеющих совершенно разный уровень развития, например, коммерческие продукты представленные на рынке с новейшими разработками, находящимися лишь на этапе опытных образцов [8].

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

1.3 Описание метода парного сравнения

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

Каждый из экспертов  заполняет матрицу парных сравнений  размером NxN, где N - количество альтернатив (таблица 2).

 

Таблица 2 – Матрица парных сравнений

	А1	А2	А3	…	Аn
А1	-	X12	X13	…	X1n
А2	X21	-	X23	…	X2n
А3	X31	X32	-	…	X3n
…	…	…	…	-	…
Аn	Xn1	Xn2	Xn3	…	-

 

Матрица заполняется  по следующим правилам: элемент X_ij указывает, в какой степени (по мнению эксперта) i-я альтернатива является более предпочтительной по сравнению с j-й. Если i-я альтернатива лучше j-й, то X_ij>0,5 (чем больше превосходство i-й альтернативы над j-й, тем ближе X_ij к единице). Если i-я альтернатива хуже j-й, то X_ij <0,5 (чем больше превосходство j-й альтернативы над i-й, тем ближе X_ij к нулю) [4].

Далее определяются оценки предпочтения альтернатив над другими по мнению каждого эксперта путём сложения элементов матрицы по строкам (1), (2).

                                                                                                  (1)

                                                                                                  (2)

Затем определяются обобщенные оценки предпочтения альтернатив над другими (с учетом мнения всех экспертов) суммированием оценок предпочтения альтернатив каждого эксперта (3).

,                                                                                               (3)

где

И находится сумма всех оценок (4).

                                                                                                                      (4)

Веса альтернатив находятся делением обобщенных оценок на сумму всех обобщенных оценок (5).

                                                                                                                      (5)

 

2 Проектирование объекто-ориентированной модели СИСТЕМЫ улучшения качества продуктов методом бенчмаркинга G3:ID

2.1 Анализ требований и моделирование контекста системы улучшения качества продуктов методом бенчмаркинга G3:ID

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

UML (сокр. от англ. Unified Modeling Language - унифицированный язык моделирования) - язык графического описания создания моделей. UML создавался для использования в процессе разработки программного обеспечения. Главной его целью было достижение единого видения разработчиков и пользователей на создаваемые программы [1].

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

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

Стандарт UML предлагает  следующий  набор  диаграмм для  моделирования [1]:

• диаграммы  вариантов  использования (use case diagrams) – для моделирования  бизнес-процессов  организации  и  требований к создаваемой системе);
• диаграммы  классов (class diagrams) –  для  моделирования статической структуры  классов системы и связей между ними;
• диаграммы поведения системы (behavior diagrams);
• диаграммы взаимодействия (interaction diagrams);
• диаграммы последовательности (sequence diagrams);
• кооперативные  диаграммы (collaboration diagrams) – для моделирования  процесса  обмена  сообщениями между объектами;
• диаграммы  состояний (statechart diagrams)  – для моделирования  поведения объектов  системы  при  переходе из одного состояния в другое;
• диаграммы  деятельностей (activity diagrams) – для моделирования  поведения  системы  в  рамках  различных вариантов использования, или моделирования деятельностей;
• диаграммы реализации (implementation diagrams);
• диаграммы  компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;
• диаграммы  развертывания (deployment diagrams) – для моделирования физической архитектуры системы.

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

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

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

Возможными вариантами отношений в диаграмме прецедентов  являются: отношение расширения, которое указывает, что один прецедент является разновидностью другого и отношение обобщения, которое используется для отражения наследования среди прецедентов [2]. На рисунке 1 представлены  функции и контекст системы, определены девять прецедентов, прецедент “QFD” связан отношением расширения с прецедентом “рассчитать весовые коэффициенты”. Здесь имеется в виду то, что весовые коэффициенты могут быть рассчитаны различными способами, в том числе с использованием алгоритма QFD (метод структурирования функции качества). Данный алгоритм применим в тех случаях, когда невозможно достоверно определить степень важности параметров продукта для потребителя. В остальных случаях используется описанный в первой главе метод парного сравнения. На рисунке отображены основные функции разрабатываемой системы, такие как вычисление интегрального показателя эффективности (ИПЭ), на основе которого производится выбор базовой системы (БС), отображение таблицы бенчмаркинга, представляющей проведенный анализ в наглядной форме, формулировка задач по оптимизации БС.

Таблица 3 – Описание функциональных требований предъявляемых к системе улучшения качества продуктов методом бенчмаркинга G3:ID

№	Требование	Субъект	Прецедент
1	Получить входные данные, на основании которых будет построена таблица бенчмаркинга. Сюда включаются такие данные как названия конкурирующих систем, характеристики и их оценки для каждой системы.	Пользователь/ автоматическая система  обработки информации	Ввести исходные данные
2	Определить весовые  коэффициенты методом парного сравнения на основе заполненных пользователем матриц парных сравнений.	Пользователь/ автоматическая система  обработки информации	Рассчитать весовые  коэффициенты (оценка степени важности параметров методом QFD)
3	Произвести ряд арифметических действий, направленных на вычисление интегрального показателя эффективности	автоматическая система  обработки информации	Вычислить ИПЭ
4	Вывести таблицу бенчмаркинга с исходными и рассчитанными  данными	автоматическая система  обработки информации	Отобразить таблицу  бенчмаркинга
5	Вывести рекомендации по результатам проведенного бенчмаркинга	автоматическая система  обработки информации	Сформулировать задачи по переносу свойств в БС (Определить БС)

 

 

2.2 Документирование прецедентов

Структура документа, описывающего прецеденты, может варьироваться, однако типичное описание должно содержать следующие разделы:

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

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

2. альтернативные потоки для определения исключительных ситуаций;

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

В таблице 4 приведена описательная документация одного из обозначенных прецедентов. Документ, содержащий описания прецедента, развивается по ходу разработки. На ранней стадии определения требований составляется только краткое описание. Остальные части документа создаются постепенно и итеративно. Полный документ возникает в конце этапа спецификации требований [3].

Таблица 4 - Спецификации прецедента «Заключение договора»

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

 

2.3 Моделирование структуры системы улучшения продуктов методом бенчмаркинга G3:ID  

Моделирование структуры  системы проводится с помощью  построения диаграммы классов. Диаграмма классов описывает статическую структуру символов в системе. Это графическое представление статического вида, отражающее совокупность декларативных (статических) элементов модели, например, классы, типы, и их содержимое и отношения. Классы систематизированы в иерархии, обладающие общей структурой и поведением, и ассоциированы с другими классами. Диаграмма классов может содержать некоторые поведенческие сущности, например операции, но их динамические свойства обычно отражаются в других диаграммах, например в диаграммах состояний и диаграммах коопераций [3].