Общая характеристика CASE-средств.

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

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

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

Основная сфера применения:

• бизнес-анализ (модели деятельности предприятий "как есть" и "как должно быть" строятся с применением методов структурного системного анализа и поддерживающих их CASE-средств);
• системный анализ и проектирование (практически любая современная крупная программная система разрабатывается с применением CASE-технологий по крайней мере на этапах анализа и проектирования, что связано с большой сложностью

данной проблематики и со стремлением повысить эффективность работ)

Эволюция CASE-средств

Этапы развития:

· ассемблеров, дампов памяти, анализаторов;

· компиляторов, интерпретаторов, трассировщиков;

· символических отладчиков, пакетов программ;

· систем анализа и управления исходными текстами;

· CASE-средств анализа требований, проектирования

спецификаций и структуры, редактирования интерфейсов

(первая генерация CASE-I);

· CASE-средств генерации исходных текстов и реализации

интегрированного окружения поддержки полного жизненного цикла

(ЖЦ) разработки ПО (вторая генерация CASE-II).)

CASE-модель жизненного цикла ПО

Основные достоинства CASE-средства:

· улучшают качество разрабатываемого программного приложения

за счет средств автоматического контроля и генерации;

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

что позволяет на ранних этапах оценить ожидаемый эффект;

· ускоряют процесс проектирования и разработки;

· возможность повторного использования компонентов разработки;

· поддержание адаптивности и сопровождения ИС;

· освобождают разработчиков от рутинной работы по

документированию проекта, так как при этом используется

встро-енный документатор;

· возможность коллективной разработки ИС в режиме реального

времени

Состав case-средств:

· Репозиторий (словарь данных) – специализированная БД,

предназначенная для отображения состояния проектируемой ИС в

каждый момент времени. Объекты всех диаграмм

синхронизированы на основе общей информации словаря данных.

Репозиторий содержит информацию об объектах проектируемой

ИС и взаимосвязях между ними.

· Графический редактор диаграмм предназначен для отображения

в графическом виде в заданной нотации проектируемой ИС.

· Верификатор диаграмм служит для контроля правильности

построения диаграмм в заданной методологии проектирования

ИС.

· Документатор проекта позволяет получать информацию о

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

· Администратор проекта представляет собой инструменты,

необходимые для выполнения административных функций.

· Сервис представляет собой набор системных утилит по

обслуживанию репозитория. Данные утилиты выполняют функции

архивации данных, восстановления данных и создания нового

репозитория.

Классификация case-средств:

I. Классификация по типам:

· Анализ и проектирование. Используются для создания спецификаций системы и ее проектирования. Их целью является определение системных требований и свойств, которыми система должна обладать, а также создание проекта системы, удовлетворяющей этим требованиям и обладающей соответствующими свойствами.

· Проектирование баз данных и файлов. Обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в 3НФ, автоматическую

генерацию схем БД и описаний форматов файлов на уровне программного кода.

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

· Сопровождение и реинжиниирнг: документаторы, анализаторы программ, средства реструктурирования и реинжиниринга. Окружение. Средства поддержки платформ для интеграции, создания и придания товарного вида CASE-средствам.

· Управление проектом. Средства, поддерживающие планирование, контроль, руководство, взаимодействие

II. Классификация по категориям:

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

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

или одного этапа разработки ПО.

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

системной информации между разработчиками и этапами разработки; организуют

поддержку практически полного ЖЦ (от анализа требований и проектирования ПО до

получения документированной выполняемой программы).

III. Классификация по уровням:

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

общего и частного механизмов функционирования, имеющихся возможностей,

ресурсов, целей проекта в соответствии с назначением фирмы.

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

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

значительное уменьшение времени на разработку, облегчение модификаций,

поддержка возможностей прототипирования.

 

1. Виды автоматизации управления предприятием

Кусочная автоматизация:

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

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

Автоматизация по участкам:

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

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

Автоматизация по направлениям:

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

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

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

Полная автоматизация управления предприятием:

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

Особенности комплексного подхода:

· повышенная экономическая эффективность этого подхода по

сравнению с другими (по участкам и по направлениям);

· чрезвычайно высокие требования к качеству управления

процессом внедрения системы

 

 

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

Основные компоненты процесса управления проекта:

• Управлениекоординацией (Project Integration Management)
• Управлениецелями (Project Scope Management)
• Управлениевременем (Project Time Management)
• Управлениестоимостью (Project Cost Management)
• Управлениекачеством (Project Quality Management)
• Управление человеческими ресурсами (ProjectHumanResourceManagement)

• Управлениекоммуникациями (Project Communication Management)
• Управлениерисками (Project Risk Management)
• Управлениепоставками (Project Procurement Management)

Группы процессов

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

• процессы инициации - принятие решения о начале выполнения проекта;
• процессы планирования - определение целей и критериев успеха проекта и

разработка рабочих схем их достижения;

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

поставленным целям и критериям успеха и принятие решений о необходимости

применения корректирующих воздействий;

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

согласование, утверждение и применение;

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

упорядоченному финалу

1. Процессы инициации

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

2. Процессы планирования

Основные процессы планирования:

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

Вспомогательные процессы планирования:

• планирование качества;
• планирование организации;
• назначение персонала;
• планирование взаимодействия;
• идентификация риска;
• оценка риска;
• разработка реагирования;
• планирование поставок;
• подготовка условий.

3. Процессы исполнения и контроля

Основные процессы планирования:

• сам процесс исполнения плана проекта

Вспомогательные процессы планирования:

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

4. Процессы анализа

Основные процессы планирования:

• анализ сроков;
• анализ стоимости;
• анализ качества;
• подтверждение целей

Вспомогательные процессы планирования:

• оценка исполнения;
• анализ ресурсов.

5. Процессы управления

Основные процессы планирования:

• общее управление изменениями;
• управление ресурсами;
• управление целями;
• управление качеством.

Вспомогательные процессы планирования:

• управление рисками;
• управление контрактами.

6. Процессы завершения:

• закрытие контрактов;
• административное завершение.

Виды деятельности, входящие в управление проектом:

• Управление содержанием проекта и качеством
• Управление ресурсами проекта
• Управление рисками
• Управление коммуникациями и информационное обеспечение проекта
• Управление конфигурациями и изменениями
• Управление проектной средой и технологиями
• Контроль и мониторинг состояния проекта

Управление содержанием проекта и качеством

Основные элементы содержания проекта следующие:

• Целевые критерии проекта
• Иерархическая структура работ (workbreakdownstructure)

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

Метрики ПО:

• размер программы в строках ее кода (linesofcode, LOC).
• функциональные точки (functionalpoints, FP)
• конструктивная модель стоимости версии II (ConstructiveCostModel II, СОСОМОII).

Размер программы в строках ее кода

Ее основное достоинство – понятность и простота вычисления.

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

Функциональные точки

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

COCOMOII

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

1. На самых ранних этапах, когда примерно известны только общие требования, а

проектирование еще не начиналось, используется мо-дель состава приложения

(ApplicationCompositionModel). В ее рамках трудоемкость проекта оценивается в

человеко-месяцах по формуле

Effort= A⋅Size

· Коэффициент А учитывает возможное переиспользование части компонентов и

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

инструментов и оцениваемую числом от 4 до 50

А=(100-процент переиспользования)/производительность

· Size представляет собой оценку размера в терминах экранов, форм, отчетов,

компонентов и модулей будущей системы. Каждый такой элемент оценивается с

коэффициентом от 1 до 10 в зависимости от своей сложности.

2. На следующих этапах, когда требования уже в основном известны и

начинается разработка архитектуры ПО, используется модель этапа

предварительного проектирования (EarlyDesignModel)

Для трудоемкости (в человеко-месяцах):

Effort = A * (Size)^B M_E+ трудозатраты на автоматически генерируемый код

Для времени (в месяцах): Time = T * Effort_S^{(0.28+0,2(B-1,01))} * Sced

· Коэффициент А считается равным 2,45, а Т считается равным 3,67.

· Size – оценка размера ПО в тысячах строк кода.

· В – фактор процесса разработки, который вычисляется по формуле

В=0,91+0,01*Σ_i=1..5 *W_i

• МЕ – произведение семи коэффициентов затрат, каждый из которых лежит в интервале от 1 до 6:
1. возможности персонала;
2. надежность и сложность продукта;
3. требуемый уровень повторного использования;
4. сложность платформы;
5. опытность персонала;
6. использование инструментов;
7. плотность графика проекта
• Efforts обозначает оценку трудоемкости без учета плотности графика, a Seed –требуемое сжатие времени выполнения проект

Управление ресурсами

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

Специфика управления персоналом:

• Производительность;
• Знания и умения;
• Мотивация персонала:
• пирамида Маслоу;
• деление людей на 3 типа:
1. люди с целевой ориентацией, получающие достаточно мотивации от решения задач, постановка которых им понятна;
2. люди с самоориентацией, стремятся к личному успеху и признанию и готовые работать для достижения личных целей;
3. люди с внешней ориентацией, мотивация которых определяется возможностью работать в коллективе единомышленников, решать общие задачи.

• теория справедливости
• теория ожиданий
• Построение сплоченной команды;
• Конфликты;
• Лидерство и влияние.

Управление рисками:

Риски проекта, влияющие на его ход:

• технологические риски
• кадровые риски
• риски требований
• коммерческие риски
• управленческие риски
• производственные риски

Риски продукта, влияющие на результаты проекта:

• технические риски
• эксплуатационные риски
• правовые и общественные риски

Бизнес-риски:

• контрактные риски
• инвестиционные риски
• сбытовые риски
• конъюнктурные риски

Управление коммуникациями и информационным обеспечением:

• Представительские связи
• Координация работ
• Обмен информацией внутри организации-исполнителя.
• Разведка и сбор внешней информации
• Составление предложений
• Ведение переговоров