Конструктивная модель стоимости

В данной модели для вывода формул использован статистический подход, в котором учитывались реальные результаты огромного количества проектов. Автор оригинальной модели – Барри Боэм (1981) – дал ей название COCOMO ( Co nstructive Co st Mo del). Совершенная модель COCOMO II ориентирована на применение в программной инженерии XXI века. Данная модель содержит:

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

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

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

COCOMO II – авторитетная и многоплановая модель, позволяющая решать самые разнообразные задачи управления программным проектом.

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

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

Новое программное обеспечение стоит дорого, и чтобы оправдать затраты, программные продукты должны находиться в использовании достаточно долго. От многих из таких программных продуктов зависит деятельность крупных компаний, и малейшая ошибка в системе приводит к сбою их деловой активности. Именно такие системы и получили название наследуемых (legasi system).

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

Распространенная проблема при использовании унаследованной системы - это трудности в понимании, что она делает и как она это делает. В основном эта проблема возникает при отсутствии подробной документации. Использование унаследованной системы становится намного проще, если при ее создании учитывались опыт и методики по применению ранее разработанного кода, а также применение порождающего программирования, как части программной инженерии [24].

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

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

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

Структура наследуемых систем

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

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

Социотехническая система

БИЗНЕС ПРОЦЕССЫ

ПРИКЛАДНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

ПРОГРАММНЫЕ СРЕДСТВА ПОДДЕРЖКИ

АППАРАТНЫЕ СРЕДСТВА

Рис.8.6. Многоуровневая модель наследуемой системы

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

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

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

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

Существует несколько стратегических подходов к процессу модернизации ПО:

- сопровождение ПО, заключающееся в изменении отдельных частей ПО, в ответ на растущие требования, но с сохранением основной системной структуры;

- эволюция системной архитектуры – существенные изменения в программной системе;

- реинжениринг ПО – модернизация не путем внесения каких-либо новых компонентов, а наоборот, упрощением системы и удалением из нее всего лишнего. При этом, возможны изменения в архитектуре, но без серъезных переделок.

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

⇐ Предыдущая24252627282930313233Следующая ⇒

Поделиться: