На рисунке 4.8 показано, как используется SID в разработке нового проекта. В проекте применялись рекомендации ТМ Forum по расширению модели SID. Расширения на этом рисунке обведены овалом. Приведенная на этом же рисунке диаграмма классов показывает, каким образом новые сущности встраивались в существующие сущности SID (в дан­ном случае — ResourceSpecification). SID использовалась также в другом новом […]

Поскольку MetaSolv — не поставщик услуг, она не могла применить еТОМ, как это делали обычно другие операторы, в качестве карты процессов. Од­нако еТОМ охватывает всю корпоративную среду MetaSolv — от продаж и управления продуктами до разработки. еТОМ внедряли несколькими спосо­бами, в частности: • как прототипную структуру (pre-SID) для организации бизнес-сущнос­тей (см. выше); • как карту, […]

Для разработки своих программ MetaSolv использует так называемый Уни­фицированный процесс разработки (Rational Unified Process, RUP). На рис. 4.4 представлены его фазы и разделы. RUP — это итеративный процесс разра­ботки приложений, опирающийся на концепцию сценариев использования. Это значит, что он обладает двумя важнейшими характеристиками жизнен­ного цикла NGOSS. Хотя RUP также позволяет строить модели классов, этот метод […]

Если компания не являлась поставщиком услуг, она использовала еТОМ (первоначально — предшествующая модель, ТОМ) с некоторыми ограниче­ниями. С помощью еТОМ решались две задачи: • демонстрировалось, как приложения покрывают бизнес-процессы еТОМ; • обеспечивалась структура для организации бизнес-сущностей SID. Многие независимые поставщики программного обеспечения использу­ют еТОМ для представления бизнес-процессов, поддерживаемых их прило­жениями. До появления NGOSS программы ТОМ […]

В этой главе представлен опыт внедрения NGOSS независимыми поставщи­ками программного обеспечения. Компания MetaSolv Software входит в команду по разработке программы NGOSS. Будучи давним приверженцем принципов NGOSS; MetaSolv начала использовать артефакты NGOSS, как только они стали доступны. Применяя их, MetaSolv удалось оценить многие преимущества программы NGOSS: в частности, сократить время, затрачива­емое на разработку, и время, необходимое […]

В этом разделе приводятся некоторые рекомендации относительно внед­рения других аспектов технологически нейтральной архитектуры. Имею­щийся опыт реализации большинства этих принципов пока невелик. Поэто­му рекомендаций по внедрению можно предложить немного. Это, в частности, следующие аспекты: • отделение бизнес-процесса от реализации компонентов, • наличие архитектуры, ориентированной на безопасность, • наличие архитектуры, основанной на политиках, • унифицированная среда информации […]

О важности сценариев использования и контрактов уже говорилось в пре­дыдущей главе. Эти два артефакта технологически нейтральной архитектуры всегда необходимо принимать во внимание при внедрении NGOSS. Кроме того, необходимо иметь в виду и такой артефакт, как диаграммы последова­тельностей, поскольку они могут служить связующим звеном между сцена­риями использования и контрактами. В этой главе дается также краткое описание […]

По мере того как все большее число операторов адаптируют под себя струк­туры еТОМ и SID, они начинают требовать, чтобы независимые поставщи­ки программного обеспечения (ISV) и партнеры по бизнесу (В2В) также соответствовали принципам, изложенным в NGOSS. Заложенные в NGOSS критерии соответствия могут быть использованы для оценки совместимос­ти ПО от независимых поставщиков и модели SID. Чем выше […]

Домены и АВЕ структуры SID Framework могут использоваться также для упорядочения существующих информационных моделей. Структура SID Framework предоставляет инструмент, позволяющий последовательно упо­рядочить и в то же время привнести в существующую модель единый словарь для описания объектов и их взаимосвязей. Оценка степени соответствия модели SID с использованием критериев NG0SS Стратегия проверки соответствия модели SID опирается на […]

Шаблон «спецификация сущности/сущность» используется в модели S1D повсюду. Как правило, большинство основных бизнес-сущностей (то есть тех, которые не зависят ни от каких других объектов в пределах данной АВЕ, — таких как Клиент, Продукт или Услуга) имеют свои инвариантные атрибуты, методы, отношения и ограничения, определенные спецификациями, напри­мер спецификацией продукта (Product Specification) или спецификацией услуги (Service Specification). […]