В заключительной части курса речь пойдет о ряде подходов к управлению, в том числе командой разработчиков и на чем собственно следует сконцентрироваться, в каких рамках понятийного каркаса мы будем находиться. Прежде всего, нужно напомнить о том, что методологии — это каркасы процессов, имеющие разную гибкость, как гибкие методологии, так методологии строгие. То есть более или менее формальные рамки имеют эти самые процессы. Процесс, как таковой, будем понимать как последовательность шагов, которая ведет к определенному результату. Под результатом можно понимать – артефакты или рабочие продукты, то есть это могут быть фрагменты кода, могут быть результаты тестирования, могут быть таблицы, графики, документация. Все что угодно, но важно, что это определяется процессом, условиями входа и выхода каждого шага из этого процесса, которые должны быть, естественно, четко сформулированы. Таким образом, мы получаем некое подобие матрицы, где у нас на каждом этапе или в каждой ячейки этой матрицы, с одной стороны имеется шаг процесса, с другой стороны, имеется роль, а на пересечении получается артефакт. При этом, естественно, крайне важно соблюдать стандарты, это методики, следовать руководствам, технологиям и применять нужные инструменты, о которых мы, в данной части курса в основном и будем говорить, о технологиях, о методиках и об инструментах. Таким образом, все дальнейшие рассуждения, мы строим, так сказать, в системе координат — процесс, роль, артефакт. При этом мы рассмотрим несколько методологий, технологий или моделей, можно называть их по-разному, это оптимизированная спиральная модель, с которой мы начнем. Затем для корпоративной инфраструктуры, мы посмотрим, как работает многослойная модель, посмотрим, как работает матрица корпоративной архитектуры на уровне процессов, данных и компонент программных систем. А так же особенности разработки, с точки зрения субъектной ориентированности и адаптивности. Первым технологическим подходом, который мы рассмотрим, будет так называемая оптимизированная или усовершенствованная спиральная модель, которая позволяет строить конгломераты или корпоративные программные комплексы на основе гетерогенных программных систем или разнородных программных систем по данным. Под гетерогенностью понимаются, как минимум два аспекта, это архитектурный и структурный. Архитектурная гетерогенность – здесь речь идет об интеграции модулей или подсистем, которые основаны на различных архитектурных принципах. Это унаследованные системы, можно даже сказать устаревшие системы, которые тем не менее поддерживают ключевые бизнес-процессы в корпорациях. Это файл-серверы, это клиент серверы, это интернет и облачные технологии, сервисные технологии. Что касается структурной гетерогенности, здесь речь идет о разнородных объектах данных с точки зрения степени их структурированности. Хорошо структурированные реляционные таблицы, слабо структурированные аудио-видео данные, отсканированные документы и другие подобные объекты данных. Что касается оптимизированной спиральной модели, здесь мы имеет конвейер. То есть несколько этапов и несколько уровней на каждом этапе процессов разработки, которые мы рассмотрим чуть более подробно далее, с возможностью реинжиниринга или двунаправленной разработки, как в прямом так и в обратном направлении, для программных продуктов. При этом на выходе открывается возможность согласованности данных и контроля целостности. В результате получаются открытые расширяемые комплексы программных систем, которые функционируют в глобально открытой сервисной среде. Рассмотрим процессную диаграмму оптимизированной спиральной модели, которая представлена на слайде шестиугольником и включает, соответственно, шесть этапов представленных на слайде секторами и шесть уровней, которые детализированы внутри каждого сектора. При этом проектирование программной системы, с точки зрения процессов разработки, начинается по аналогии с часовым цифровым циферблатом в прямом направлении в 12 часов и движется по часовой стрелке. В обратном направлении реинжинирингом, возможность восстановления системы модели по существующей системе в обратном направлении. Шесть этапов, которые перечислены на схеме, включают, прежде всего, следующее – это концептуальную схему данных, схему данных – терминов традиционных CASE-средств, схему при этом, как на уровне базы данных, так и базы знаний или мета-данных. И для каждого из шести этапов, которые причислены на схеме, имеются шесть уровней. Это объекты связей, средства описаний и средства управлений или манипулирование объектами данных, которые также детализированы на схеме. К особенностям подхода следует отнести его преемственность с традиционно объектоориентированным подходом и со спиральной моделью. Возможность замкнутого перехода от концептуальной модели к схемам данных в терминах традиционных CASE-средств, двунаправленность триинжиниренгом. То есть возможностью расширения, развития, доработки существующих программных комплексов на основе тех систем, которые уже были разработаны ранее.
