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

На сегодняшний день рынок ПО предлагает следующие наиболее развитые CASE-средства:

• Vantage Team Builder,

• Designer 2000,

• Silverrun,

• ERwin, BPwin,

• S-Designer,

• CASE.Аналитик,

• Rational Rose,

• SQL, JAM.

Классифицировать CASE-средства можно по следующим признакам:

• ориентация на этапы ЖЦПО,

• степень независимости от СУБД.

• функциональная полнота,

• тип используемой модели разработки,

По ориентации на этапы ЖЦПО можно выделить следующие средства:

• анализа (для построения моделей) - ERwin, BPwin, Rational Rose,

• анализа и проектирования (для создания проектных спецификаций) - Vantage Team Builder, Silverrun, Designer 2000, CASE.Аналитик

• создания БД (для моделирования и разработки схем к основным СУБД) – SQL, ERwin, S-Designer,

• разработки приложений - SQL, JAM,Unifase, Delphi, Developer/2000,

• генераторы кодов - Vantage Team Builder, Silverrun,

• средства реинжиниринга - Silverrun, Vantage Team Builder, Designer 2000, S-Designer,

Rational Rose, Object Team.

- конфигурационного управления – PVCS, SCCS…

- планирования и управления проектом – Microsoft Project, SE Companion…

- тестирования – Quality Works….

По степени независимости от СУБД CASE-средства можно разделить на две группы:

• независимые, которые поставляются в виде автономных систем, не входящих в состав конкретных СУБД. Обычно они поддерживают несколько форматов данных через интерфейс ODBC ( ERwin, S-Designer, Silverrun,)

• встроенные поддерживают формат БД СУБД, в состав которых они входят (Designer 2000, входящая в состав СУБД Оracke)

По функциональной полноте можно выделить следующие типы:

• средства, используемые для решения частных задач на одном или нескольких этапах ЖЦПО ( ERwin, S-Designer, Silverrun, CASE.Аналитик)

• интегрированные системы, поддерживающие полный ЖЦПО (Vantage Team Builder, Designer 2000 с системой разработки приложений Developer/2000)

По типу используемой модели можно выделить три группы:

- структурные (Vantage Team Builder),

• объектно-ориентированные (Rational Rose, Object Team),

• комбинированные (Designer 2000).

2.5 Экстремальное программирование

История экстремального программирования началась в первой половине 90-х годов. Автор термина Кент Бек (Kent Beck) обдумывал новые подходы к созданию программ. Работая в группе разработчиков над очередным проектом, Кент заметил несколько приемов, благодаря которым удалось повысить эффективность труда. В марте 1996 года он попытался использовать накопленный опыт в работе над проектом, выполняемым по заказу фирмы “Даймлер Крайслер“. В результате он сформулировал положения, ставшие известными как методика экстремального программирования – Extreme Programming .

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

Что же такое Extreme Programming: набор отдельных правил и методик или полноценная методология? С чего начинается экстремальное программирование? С понимания того, что необходимо максимально снизить стоимость разработки. А для этого необходимо тесно сотрудничать с заказчиком, понимать его интересы и разработать программное обеспечение, полностью соответствующее его требованиям.

В ХР четко описаны все роли, каждая из которых предусматривает характерный набор правил и обязанностей. Существует две ключевые роли: заказчик и разработчик.

Заказчик – человек или группа людей, заинтересованных в создании конкретного ПП. Он имеет следующие права и обязанности:

- зафиксировать сроки выпуска продукции,

- принимать решения относительно запланированных компонентов программы,

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

• принимать бизнес решения,

• знать текущее состояние разработки,

• при необходимости изменять требования к системе.

Разработчик – может и должен:

• получить достаточно информации о предметной области разрабатываемой задачи,

• иметь возможность выяснять и уточнять детали в процессе разработки,

• предоставлять ориентировочные, но достаточно точные оценки трудозатрат на каждую функциональную часть,

• в процессе разработки уточнять предварительные оценки,

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

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

Роли стороны заказчика:

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

Приемщик – человек контролирующий правильность функционирования системы. Хорошо владеет предметной областью. Занимается написанием приемочных тестов.

General Boss – следит за работой всех звеньев. Контролирует внедрение системы и различные оргмоменты. Может быть инвестором проекта.

Роли стороны разработчика:

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

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

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

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

Внешние роли:

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

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

Что такое общение? Это очень просто. Общение - самое быстрое средство обмена информацией и опытом. Это очень важно, когда требуется максимальная скорость разработки. Но общение, как и любое другое полезное начинание, требует постоянной поддержки. Именно поэтому кто-то из команды должен стать дипломатом, то есть ответственным за общение.

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

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

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

А теперь рассмотрим основные методики экстремального программирования, которые позволяют реализовать эти принципы.