CASE- технологииПрограммные средства для разработки ПО постоянно развиваются и совершенствуются. В истории их эволюции начиная с программирования в машинных кодах последовательно появлялись: ассемблер, компиляторы, интерпретаторы, трассировщики, отладчики, интегрированные оболочки. С развитием методов проектирования ПО неизбежно стали появляться программы, компьютезирующие и эту область деятельности. CASE (Computer Aided Software Engeneering)-технологии являются естественным продолжением эволюции всей отрасли разработки ПО. CASE-1: анализ требований, проектирование спецификаций и структуры, редактирования интерфейсов. CASE-2: генерации исходных текстов и реализация интегрированного окружения поддержки полного ЖЦ разработки ПО.Таким образом, CASE-средства являются результатом естественного эволюционного развития отрасли инструментальных (или технологических) средств. CASE-технологии начали развиваться с целью преодоления ограничений методологии структурного программирования. Некоторые исследователи считают, что появление этих технологий связано с достаточно развитым уровнем формализации структурного программирования, что позволяет автоматизировать выполнение рутинных работ. Как бы то ни было, разработка моделей предметных областей с помощью программных средств довольно быстро привела к созданию программ, позволяющих моделировать разнообразные области человеческой деятельности, не связанные с программированием. Прежде всего это бизнес-проекты, позволяющие моделировать структуру предприятий с различными компонентами и их взаимосвязями. Так что в настоящее время CASE-технологии используются не только для производства ПО, но и как мощный инструмент решения исследовательских и проектных задач (структурный анализ предметной области, моделирование деловых предложений с целью решения задач оперативного и стратегического планирования и управления ресурсами). Нас прежде всего интересует суть CASE-систем, которые предназначены для помощи в создании ПО. Назначение этих CASE-cистем:поддержка разработки моделей анализа и проектирования ПО;автоматизация процесса построения ПО;обеспечение функций реверсивного проектирования;обеспечение функций сопровождения ПО.Реверсивное программирование: от текста программы или структуры БД к проекту и идее используется для модификации программ.Истоками CASE вероятно является жажда разработчиков ПО и вообще проектировщиков всегда и всюду использовать различные схемы и рисунки. Визуальные изображения для многих людей играют роль опорных точек, за которые можно мысленно цепляться при анализе или конструировании сложных систем. К тому же с помощью рисунка гораздо проще передать свои мысли другому человеку. Вероятно графический “язык” по своей природе не слишком разнообразен. По сути – это всего лишь какие-то блоки типа прямоугольников или кругов и линиии между ними. Не удивительно, что возникла идея создать компьютерное средство, помогающее рисовать различные диаграммы. Неизбежная систематизация графических средств далее приводит к созданию “графических” языков, которые могут рассматриваться как языки более высокого уровня по отношению к текстам программ. Одно из наиболее важных достоинств таких языков – с одной стороны, их формальный характер, а с другой – интуитивная ясность для постановщиков задач в данной предметной области.^ Основными задачами, решаемыми с помощью CASE-систем, являются следующие:1. Разработка моделей предметной области, функциональной структуры системы, структур данных на графических языках.^ 2. Хранение моделей в единой базе данных – репозитории, доступном всем участникам разработки.3. Формальный анализ разрабатываемых моделей, позволяющий избегать некоторых семантических ошибок.^ 4. Автоматизированная генерация структур баз данных, приложений, текстов программ.5. Автоматизированная генерация документации на программные системы.^ 6. Обеспечение повторного использования наработок при модернизации, перепроектировании системы.Для того, чтобы более конкретно разобраться в сути современных CASE-систем, бросить на них взгляд сверху вниз, попробуем представить в несколько абстрактном виде структурный анализ - ту область деятельности, для работы с которой предназначены CASE-средства. В методологии структурного анализа наиболее часто и эффективно используются следующие средства:^ DFD (Data Flow Diagrams) - диаграммы потоков данных;ERD ( Entity-Relationship Diagrams) - диаграммы ‘сущность -связь’;STD (State Transition Diagrams) - диаграммы переходов состояний.Сами структурные методологии анализа и проектирования классифицируются по следующим признакам:по отношению к школам - Software Engineering (SE) и Information Engineering (IE);по порядку построения моделей - процедурно-ориентированные, ориентированные на данные и информационно-ориентированные;по типу целевых систем - для систем реального времени и для информационных систем.SE является нисходящим подходом к проектированию функций разрабатываемого ПО. Основой являются классические модели жизненного цикла: водопадная, итерационная , циклическая. Применяется при разработке как информационных систем, так и систем реального времени. По сравнению с IE появилась раньше и более апробирована.IE - более новая дисциплина. Она имеет более широкую область применения, поскольку является дисциплиной построения систем вообще, а не только систем ПО. Включает этапы более высокого уровня (например, стратегическое планирование). Во всех структурных методологиях используется одна и та же концепция : данные входят в систему, обрабатываются и выходят из системы (вход – обработка - выход). Отличаются технологии порядком построения модели ПО (как бы по разному решается вопрос: что раньше яйцо или курица?). Традиционный процедурно-ориентированный подход регламентирует первичность проектирования функциональных компонентов по отношению к проектированию структур данных: требования к данным раскрываются через функциональные требования. При подходе, ориентированном на данные, вход и выход являются наиболее важными - структуры данных определяются первыми, а процедурные компоненты являются производными от данных. Информационно-ориентированный подход, как часть IE-дисциплины, отличается от предыдущего подхода тем, что позволяет работать с неиерархическими структурами данных.Исходя из приоритетов, которых придерживается разработчик CASE, получаются по разному ориентированные CASE-системы.Типовая CASE-система включает в свой состав средства разработки различных моделей:- диаграммеры, - средства для конструирования пользовательского интерфейса,- генераторы приложений, - генераторы документации, - систему программирования,- центральную базу данных проекта – репозиторийERD-диаграммер - средство построения диаграмм «сущность – связь», генерирует SQL-скрипты и экранные формы. Репозиторий – БД, в которой содержится информация о проекте DFD-диаграммер – графическое средство построения диаграмм потоковых данных. SQL – язык управления данными, определяет структуру и операции, выполняемые над реляционными БД (БД табличного типа).Необходимо отметить, что наиболее просто автоматизируемыми фазами в CASE-технологии оказались контроль проекта и кодогенерация, хотя все другие фазы ЖЦ также поддерживаются CASE-средствами. Кроме изменения содержания фаз, существенно изменилось распределение трудозатрат по фазам, как показано в таблице Технология ^ Этапы разработки Анализ Проектирование Кодирование Тестирование Традиционная 20% 15% 20% 45% CASE-1 30% 30% 15% 25% CASE-11 40% 40% 5% 15% Основные CASE-средства: ERWIN (разработка ER-моделей), BPWIN (разработка диаграмм потоков данных), POWER DESIGNER, DESIGNER 2000, RATIONAL ROSE, PARADIGM+CASE-средства можно классифицировать по типам, отражающим функциональную ориентацию в технологическом процессе.^ Анализ и проектирование. Средства данной группы применяют для создания спецификаций системы и ее проектирования, они поддерживают методологии SE и IE:CASE- аналитик (Эйтекс);POSE (Computer Systems Advisers);Design/IDEF (Meta Software);BPWin (Logic Works);SELECT (Select Software Tools);CASE/4/0 (micro TOOl GmbH)и ряд других средств.^ Проектирование баз данных и файлов. Средства данной группы обеспечивают логическое моделирование данных, автоматическое моделей данных в третью нормальную форму, автоматическую генерацию схем БД и описаний форматов файлов на уровне программного кода. К таким средствам относятся:ERWin (Logic Works);S-Designor (SPD); Designtr/2000 (Oracle);Sillverrun (Computer Systems Advisers)/Программирование. Средства поддерживабют этапы программирования и тестирования, а также автоматическую кодогенерацию из спецификаций, получая полностью документированную выполняемую программу: COBOL 2/Workbench (Mikro Focus);^ DECASE (DEC);NETRON/CAP (Netron);APS (Sage Softwfre).Эти средства включают генераторы кодов, анализаторы кодов, генераторы тестов, анализаторы покрытия тестами, отладчики и средства интегрирования с результатами выполнения предыдущих этапов (диаграммеры для анализа спецификаций, средства поддержки работы с депозитарием (хранилище описаний данных, потоков и т.п.)).^ Сопровождение и реинжениринг. Сюда относят документаторы, анализаторы программ, средства реструктурирования: Adpac CASE Tools (Adpac);Scan/COBOL и SuperStructure (Computer Data Systems):Inshtctor/Recoder (language Tecnologe).Средства позволяют осуществлять поддержку всей системноц документации, включая коды, спецификации, наборы тестов, контролировать покрытие тестами для оценки полноты тестируемости, управлять функционированием смистемы.Особый интерес представляют средства обеспечения мобильности (в CASE они получили название: средства миграции), обеспечивающие перенос существующей системы в новое операционное или аппаратурное окружение.Обзор CASE-средств Фирма Computer Associated CASE-средства:AllFusion Process Modeler (ранее:BPwin) - моделирование бизнес-процессовAllFusion ERwin Data Modeler (ранее: ERwin) - моделирование данныхAllFusion Data Model Validator (ранее: ERwin Examiner) - проверка моделей данных.AllFusion Model Manager (ранее: ModelMart) - сервер для совместной работы пользователей ERwin и/или BpwinAllFusion Saphir Option - – средство просмотра структур данных широкого набора корпоративных информационных систем, включая PeopleSoft, SAP R/3, SAP BW и J.D. Edwards OneWorld, Siebel. AllFusion Saphir Option позволяет пользователям определять важные для бизнеса данные без необходимости изучения самих информационных систем. Продукт предоставляет возможность простой и интуитивно понятной навигации по детализированным метаданным систем.^ AllFusion Component Modeler (Paradigm Plus) - моделирование компонентов ПО Поскольку генерация кода реализована на основе знаний предметной области, а не на основе реляционной структуры данных, полученный код более полно отражает бизнес-логику. Rational Rose и Paradigm Plus поддерживают не только прямую генерацию кода, но и обратное проектирование, т. е. создание объектной модели по исходному коду приложения.^ ERwin имеет два уровня представления модели - логический и физический. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например "Постоянный клиент", "Отдел" или "Фамилия сотрудника". Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. Разделение модели данных на логические и физические позволяет решить несколько важных задач.^ Документирование модели. Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов - пробела и т. п.). Зачастую разработчики ИС имеют дело с нелокализованными версиями СУБД. Это означает, что объекты БД могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу предложением - только одним словом). Кроме того, проектировщики БД нередко злоупотребляют "техническими" наименованиями, в результате таблица и колонки получают наименования типа RTD_324 или CUST_A12 и т. д. Полученную в результате структуру могут понять только специалисты (а чаще всего только авторы модели), ее невозможно обсуждать с экспертами предметной области. Разделение модели на логическую и физическую позволяет решить эту проблему. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы - имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице CUST_A12 может соответствовать сущность Постоянный клиент. Такое соответствие позволяет лучше задокументировать модель и дает возможность обсуждать структуру данных с экспертами предметной области.Масштабирование. Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость - создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать физическую и логическую модель данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой. Например, можно перенести структуру данных с Oracle на Informix (или наоборот) или перенести структуру dbf-файлов в реляционную СУБД, тем самым облегчив решение по переходу от файл-серверной к клиент-серверной ИС.Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT - Structured Analysis and Design Technique. (Подробно методология SADT излагается в книге Дэвида А. Марка и Клемента Мак-Гоуэна "Методология структурного анализа и проектирования SADT" M.:Meтaтexнoлoгия, 1993.) В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF0.Альтернативой структурному подходу стали объектно-ориентированные методы разработки ИС. В первой половине 90-х годов был предложен разработанный на основе наиболее популярных объектных методов ОМТ (Rumbaudh), Booch и OOSE (Jacobsom) универсальный язык объектного проектирования - Unified Modeling Language, UML (The Unified Method, Draft Edition (0.8). Rational Software Corporation, October 1995). Существует несколько CASE-средств, поддерживающих язык UML. Наиболее известными являются: CASE-средства, поддерживающие UML:Paradigm Plus фирмы PLATINUM technology (Computer Associated).Rational Rose фирмы Rational Software.SELECT фирмы SELECT SoftwareФирмыPlatinum Technology Incorporated (Платинум Текнолоджи Инкорпорейтед) - американская корпорация, разработчик программ для управления и усовершенствования информационных корпоративных систем. Кроме того, Platinum Technology занимается программами управления базами данных и информационными системами, построением хранилищ данных, разработкой аналитических средств и инструментария для разработчиков. Штаб-квартира корпорации находится в Экбрук-Террас (Иллинойс). Компания была основана в 1987 году в Чикаго. К концу 1990-х годов компания по объемам продаж занимала седьмое место в мире среди компаний-разработчиков компьютерного обеспечения. Своей основной задачей Platinum Technology считает предоставление полного спектра программного обеспечения для нужд крупного предприятия. Компания активно взаимодействует с крупными разработчиками программного обеспечения — компаниями Oracle, Microsoft, Informix, Sybase, производителями аппаратных средств — IBM, Hewlett-Packard, Sun Microsystems, Digital Equipments. В 1997 году доходы корпорации составили 749 млн. долларов. Офисы Platinum Technology находятся в 40 странах мира, в 1995 году компания начала свою деятельность на территории России. В 1999 году компания была полностью приобретена корпорацией Computer Assotiations.^ Computer Associates. (CA) (Компьютер Ассошиэйтс) - американский софтвер, лидер в области СУБД и т.п. Американская компания, специализирующаяся в области программного обеспечения (выпуск программных продуктов в области системного управления, СУБД, средств экономического и финансового управления). Основана в 1976 году Чарлзом Вонгом и Руссом Артцем. Штаб-квартира находится в г. Айсландия (шт. Нью-Йорк). CA, являясь крупнейшей (второй после Microsoft) компанией в мире по созданию программного обеспечения, осуществляет разработку, лицензирование и поддержку более 500 интегрированных продуктов, включающих системы управления информационными и вычислительными сетями предприятий, инструментальные средства, приложения финансового и производственного назначения. Первым успешным продуктом компании была программа сортировки данных (СA Sort). Тонко уловив конъюнктуру (пользователям приходилось около 25% времени тратить на сортировку), СА приобрела права на эту программу у швейцарской фирмы и осуществила ее выгодные продажи. Благодаря своим первым удачным шагам Computer Associates завоевала репутацию одного из ведущих участников рынка софтверной продукции. После удачных первых шагов фирма во главе с удачливым, но жестким исполнительным директором Вонгом стала интенсивно расширять поле своей деятельности. За более чем двадцатилетнюю историю своего существования CA приобрела свыше 60 компаний, сотрудники которых были безжалостно уволены — такова кадровая стратегия компании. Подбору персонала уделяется огромное внимание. С начала 1990-х годов компания становится лидером в области управления хранением и резервным копированием данных. Последним достижением в этой области является продукт ARCserve. Принадлежащая CA технология ARCserve обеспечивает сквозное управление средствами хранения данных для всех ресурсов информационных технологий, включая рабочие станции, серверы, базы данных, системы групповой работы и web-серверы. Эта технология позволяет осуществлять целостное управление хранилищами на любых платформах — от настольных ПК до мейнфреймов. Играя роль всеобъемлющего интегрированного решения по управлению средствами хранения, ARCserve обеспечивает не только простое резервное копирование, но также архивирование, восстановление после сбоев, сетевую миграцию данных, реплицирование и управление носителями и устройствами. Начиная с 1996 года, продукция ARC-serve неоднократно отмечалась почетными наградами ведущих компьютерных изданий. В 1998 году в штате компании насчитывалось более 13 тыс. сотрудников, совокупный доход компании составил 4,7 млрд. долларов. Продукция CA распространяется в более чем 100 странах мира, в 40 странах функционируют зарубежные представительства СА. К 2002 году планируется, что годовой доход компании составит около $1,5 млрд., что превысит показатели 1997 года более чем в три раза. Computer Associates сегодня является наиболее динамично развивающейся компьютерной компанией в мире.RAD В связи с развитием CASE-технологий в рамках спиральной модели жизненного цикла ПО широкое распространение получила методология быстрой разработки приложений RAD (Rapid Application Development). Процесс разработки при этом содержит три элемента: небольшую команду программистов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес); итерационный подход, при котором разработчики, по мере того как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком. Команда разработчиков представляет собой группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств. Кроме того, разработчики должны уметь преобразовывать в рабочие прототипы предложения конечных пользователей. Жизненный цикл ПО по методологии RAD состоит из четырех фаз: анализа и планирования требований; проектирования; реализации; внедрения. На фазе анализа и планирования происходит определение требований к разрабатываемому ПО силами пользователей под руководством специалистов-разработчиков. Пользователи системы определяют функции, которые она должна выполнять, выделяют те, которые требуют проработки в первую очередь, описывают информационные потребности. Определяется возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т. п. Затем определяются временные рамки самого проекта в каждой из последующих фаз. Результатом данной фазы должны быть состав и приоритеты функций будущей ИС, предварительные функциональные и информационные модели ИС. ^ На фазе проектирования часть пользователей под руководством специалистов-разработчиков принимает участие в техническом проектировании системы. Пользователи, непосредственно взаимодействуя с разработчиками, уточняют и дополняют требования к системе, которые не были выявлены на фазе анализа и планирования требований. Для быстрого получения работающих прототипов приложений используются CASE-средства. Анализируется и при необходимости корректируется функциональная модель. Определяются требования разграничения доступа к данным. Каждый процесс рассматривается детально, и при необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Здесь же выясняется, какой набор документации необходим для эксплуатации будущей системы. По результатам анализа процессов принимается решение о количестве, составляющих ИС подсистем, поддающихся разработке одной командой разработчиков за приемлемое для RAD-проектов время — порядка 2—3 мес. Результатом данной фазы должны быть: общая информационная модель системы; функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков; точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами; построенные прототипы экранов, отчетов, диалогов. Использование CASE-средств позволяет избежать искажения данных при передаче информации с фазы на фазу. Кроме того, в подходе RAD каждый прототип не выбрасывается после выполнения своей задачи, а развивается в часть будущей системы. Поэтому на следующую фазу передается уже более полная и полезная информация. ^ На фазе реализации выполняется непосредственно сама быстрая разработка приложения. Программный код частично формируется с помощью автоматических генераторов CASE-средств. Для контроля за выполнением требований к ПО привлекаются конечные пользователи. Во время разработки осуществляется тестирование каждой подсистемы, что уменьшает стоимость исправления ошибок в коде программ по сравнению с тестированием уже готовой программной системы. Автономно разрабатываемые подсистемы постепенно внедряются в общую систему. При подключении очередной части производится тестирование. Затем осуществляется тестирование всей системы в целом. Завершается физическое проектирование системы. При этом производится анализ использования данных, если необходимо, создаются базы данных и подключаются к системе, определяются требования к аппаратным ресурсам, завершается разработка документации ПО и определяются способы увеличения производительности. Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям. ^ На этапе внедрения проводят обучение пользователей, организационные изменения и постепенный переход на новую систему. При этом параллельно с новой системой продолжается эксплуатация старой системы до полного внедрения новой. Методология RAD не претендует на универсальность. Она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика, и неприменима для построения сложных расчетных программ, операционных систем или систем управления космическими кораблями, т. е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода. ^ Принципы организации RAD Главная идея RAD технологии состоит в том, чтобы как можно быстрее донести до заказчика результаты разработки, пусть и не в полном виде. Например, реализация только пользовательского интерфейса и предъявление его заказчику позволяет уже на ранней стадии разработки получить замечания по экранным и отчетным формам и внести необходимые коррективы. В этом случае значительно возрастает вероятность успеха проекта, то есть возникает уверенность в том, что конечный продукт будет делать именно то, что ожидает заказчик. Кроме того, не следует забывать и тот факт, что разница стоимости ошибки определения требований в начале проекта и в конце равна 1:200.Основные принципы RAD можно сформулировать следующим образом: Обязательное использование инструментальных средств, автоматизирующих процесс разработки, и методик их использования. Тесное взаимодействие между разработчиками и заказчиком. Работа ведется немногочисленными хорошо управляемыми группами профессионалов. Типичный состав группы - руководитель, аналитик, два программиста, технический писатель. Если проект сложный, то для него может быть выделено несколько RAD-групп. Разработка базируется на моделях. Моделирование позволяет оценить проект и выполнить его декомпозицию на составные части, каждая из которых может разрабатываться отдельной RAD-группой. разработка подсистем несколькими; ^ Итерационное прототипирование. Разработка системы и предъявление ее заказчику осуществляется в виде последовательности развиваемых прототипов. Любой из прототипов реализует определенную часть функциональности, требуемой от конечного продукта. При этом каждый последующий прототип включает всю функциональность, реализованную в предыдущем прототипе, с добавлением новой. Число прототипов определяется на основе учета разных параметров – размера проекта, анализа рисков, пожеланий заказчика и т. д. Традиционно для проектов ПО средней сложности разрабатываются три прототипа. Первый содержит весь пользовательский интерфейс с нулевой функциональностью. Он дает возможность собрать замечания заказчика и после их устранения утвердить у него экранные и отчетные формы. Второй прототип содержит реализованную на 70-80% функциональность системы, третий – полностью реализованную функциональность. Основаниями для очередной итерации являются: ^ Замечания заказчика, который привлекается к оценке выходных результатов прототипа. Если замечания носят характер исправлений, они учитываются в следующем прототипе, если же изменяются требования, то выполняется переоценка проекта и корректируются сроки и стоимость проекта. Детализация. Выполняется программирование нереализованной части системы в соответствии с составленным планом. Анализ результатов программирования. Исправляются ошибки, повышается эффективность программного кода и т. д. ^ RAD группа всегда работает только над одним прототипом, что обеспечивает единство целей, лучшую наблюдаемость и управляемость процессом разработки. Соответственно используемые инструментальные средства должны обеспечивать групповую разработку и конфигурационное управление проектом. ^ Большие системы разбиваются на подсистемы. Если проект сложный, то для него может быть выделено несколько RAD групп. Каждая подсистема разрабатывается независимой группой. Ключ успеха – правильное разбиение системы на подсистемы. Команды должны использовать общие стандарты. Обязательно финальное тестирование полной системы. Принципы RAD применяются не только при реализации, но и распространяются на все этапы жизненного цикла, в частности на этап обследования организации, построения требований, анализ и дизайн. ^ Гибкое проектирование и XPЧтобы разрешить проблемы, стоящие перед разработчиками ПО, в феврале 2001 года инициативная группа из 17 методологов объединилась в альянс гибкой разработки программного обеспечения. Эта группа приняла манифест и на его основе сформулировала принципы которые являются критериями процесса гибкой разработки ПО. Гибкое моделирование (Adile Modeling - AM) – это упорядочивающая, основанная на практическом опыте методология эффективного моделирования и документирования программных систем. Четыре базовых положения манифеста. 1. Люди и контакты важнее процессов и средств. 2. Работающие программы важнее идеальной документации. 3. Сотрудничество с заказчиком важнее переговоров по условиям контракта. 4. Готовность к изменениям важнее соблюдения планов. Принципы гибкой разработки ПО: 1. Мы придаем первоочередное значение удовлетворению заказчика, быстро и постоянно предоставляя нужное ему программное обеспечение. 2. Мы приветствуем изменения требований, даже на поздних этапах разработки. Гибкие процессы позволяют поддерживать изменения, обеспечивая заказчику конкурентное преимущество. 3. Новые версии работающего программного обеспечения поставляются часто, с регулярностью от нескольких недель до нескольких месяцев, причем более предпочтительны короткие временные периоды. 4. В ходе проекта бизнесмены и разработчики должны постоянно работать вместе. 5. Проекты строятся мотивированными индивидуалами. Создайте им условия, удовлетворяйте их требования и доверяйте им в том, что касается выполнения работы. 6. Наиболее производительный и эффективный способ передачи информации рабочей группе и внутри нее – это разговор лицом к лицу. 7. Работающее программное обеспечение – это основной показатель прогресса. 8. Гибкие процессы стимулируют устойчивую работу. Спонсоры, разработчики и пользователи должны быть в состоянии неограниченно долго поддерживать постоянный ритм работы. 9. Непрерывное внимание к техническому качеству и хорошему проектированию улучшает гибкость. 10. Простота – искусство минимизировать количество ненужной работы – исключительно важна. 11. Наилучшим образом архитектура, требования и проектирование формируются и выполняются самоорганизующимися командами. 12. Команда должна регулярно обсуждать, как повысить эффективность своей работы, после чего изменять и согласовывать рабочий процесс с результатами этих обсуждений.^ Экстремальное программирование Основополагающие практики: непрерывная интеграция, тестирование и рефакторинг создают новую среду, в которой эволюционное проектирование выглядит вполне убедительно. В ХР очень популярны два лозунга: «Do the Simplest Thing that Could Possibly Work» («Ищите самое простое решение, которое может сработать») и YAGNI («You Aren't Going to Need It» — «Это вам не понадобится»). Оба они олицетворяют собой одну из практик ХР под названием Простой дизайн. По принципу YAGNI вы не должны заниматься написанием кода сегодня, если он понадобится для того свойства программы, которое вы будете реализовывать только завтра. На первый взгляд в этом нет ничего сложного. Сложности начинаются, когда речь заходит о таких вещах, как программные каркасы для создания приложений, компоненты для повторного использования и гибкий дизайн. Надо сказать, что спроектировать их довольно сложно. Вы заранее добавляете к общей стоимости работ стоимость и такого проектирования и рассчитываете впоследствии вернуть эти деньги. При этом наличие заблаговременно встроенной в систему гибкости считается признаком хорошего проектирования. Тем не менее ХР не советует заниматься созданием гибких компонентов и каркасов до того, как понадобится именно эта функциональность. Лучше, если эти структуры будут наращиваться по мере необходимости. Если сегодня мне нужен класс Money, который обрабатывает сложение, а не умножение, то сегодня я буду встраивать в этот класс только сложение. Даже если я абсолютно уверен, что умножение понадобится мне уже