Для поиска темы - пользуйтесь СИСТЕМОЙ ПОИСКА


Стоимость дипломной работы


Home Для студента... Методология и технология разработки информационных систем

Методология и технология разработки информационных систем
загрузка...
Рейтинг пользователей: / 0
ХудшийЛучший 

Лекция 5

Тема: Методология и технология разработки информационных систем

1. Общая характеристика методологии, технологии и инструментальных средств.
Методология создания информационных систем заключается в организации про¬цесса построения информационной системы и обеспечении управления этим про¬цессом для того, чтобы гарантировать выполнение требований как к самой систе¬ме, так и к характеристикам процесса разработки.
Основными задачами, решение которых должна обеспечивать методология созда¬ния корпоративных информационных систем (с помощью соответствующего на¬бора инструментальных средств), являются следующие:
 обеспечение создания информационных систем, отвечающих целям и задачам предприятия и соответствующих предъявляемым к ним требованиям по авто¬матизации деловых процессов;
 гарантия создания системы с заданными параметрами в течение заданного вре¬мени в рамках оговоренного заранее бюджета;
 простота сопровождения, модификации и расширения системы с целью обес¬печения ее соответствия изменяющимся условиям работы предприятия;
 обеспечение создания корпоративных информационных систем, отвечающих требованиям открытости, переносимости и масштабируемости;
 возможность использования в создаваемой системе разработанных ранее и при¬меняемых на предприятии средств информационных технологий (программ¬ного обеспечения, баз данных, средств вычислительной техники, телекомму¬никаций).
Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой информационной системы. Методология реализуется через конкретные технологии и поддерживающие их стандар¬ты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла информационных систем.
Основное содержание технологии проектирования составляют технологические инструкции, состоящие из описания последовательности технологических опера¬ций, условий, в зависимости от которых выполняется та или иная операция, и опи¬саний самих операций.
Технология проектирования может быть представлена как совокупность трех со¬ставляющих:
 заданной последовательности выполнения технологических операций проек¬тирования;
 критериев и правил, используемых для оценки результатов выполнения техно¬логических операций;
 графических и текстовых средств (нотаций), используемых для описания про¬ектируемой системы.
Каждая технологическая операция должна обеспечиваться следующими матери¬альными и информационными ресурсами:
 данными, полученными на предыдущей операции (или исходными данными), представленными в стандартном виде;
 методическими материалами, инструкциями, нормативами и стандартами;
 программными и техническими средствами;
 исполнителями.
Результаты выполнения операции должны представляться в некотором стандарт¬ном виде, обеспечивающем их адекватное восприятие при выполнении следую¬щей технологической операции (на которой они будут использоваться в качестве исходных данных).
Можно сформулировать следующий ряд общих требований, которым должна удов¬летворять технология проектирования, разработки и сопровождения информаци¬онных систем:
 поддерживать полный жизненный цикл информационной системы;
 обеспечивать гарантированное достижение целей разработки системы с задан¬ным качеством и в установленное время;
- обеспечивать возможность разделения крупных проектов на ряд подсистем - де¬композицию проекта на составные части, разрабатываемые группами исполните¬лей ограниченной численности, с последующей интеграцией составных частей.
Декомпозиция проекта позволяет повысить эффективность работ. Подсистемы, на которые разбивается проект, должны быть слабо связанны по данным и функциям. Каждая подсистема разрабатывается отдельной группой разработчиков. При этом необходимо обеспечить координацию работ и исключить дублирование результатов, получаемых каждой проектной группой.
 технология должна обеспечивать возможность ведения работ по проектирова¬нию отдельных подсистем небольшими группами (3-7 человек). Это обуслов¬лено принципами управляемости коллектива и повышения производительно¬сти за счет минимизации числа внешних связей;
 обеспечивать минимальное время получения работоспособной системы. Здесь имеется в виду не реализация информационной системы в целом, а разработ¬ка ее отдельных подсистем. Как правило, даже при наличии полностью завершенного проекта внедрение разработанной системы проводится последовательно, по отдель¬ным подсистемам. Реализация же всей системы в сжатые сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации отдельных подсистем в более короткие сроки меньшим числом разработчиков.
 предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
 обеспечивать независимость выполняемых проектных решений от средств реа¬лизации системы — системы управления базами данных, операционной систе¬мы, языка и системы программирования.

2. Методология RAD — Rapid Application Development
На начальном этапе существования компьютерных информационных систем их разработка велась на традиционных языках программирования. Однако по мере возрастания сложности разрабатываемых систем и увеличения запросов пользо¬вателей (чему в значительной степени способствовал прогресс в области вычис¬лительной техники, а также появление удобного графического интерфейса пользо¬вателя в системном программном обеспечении) потребовались новые средства, обеспечивающие значительное сокращение сроков разработки. Это послужило предпосылкой к созданию целого направления в области программного обеспече¬ния — инструментальных средств для быстрой разработки приложений. Развитие этого направления привело к появлению на рынке программного обеспечения средств автоматизации практически всех этапов жизненного цикла информаци¬онных систем.
Основные особенности методологии RAD
Методология разработки информационных систем, основанная на использовании средств быстрой разработки приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки прило¬жений — RAD (Rapid Application Development). Данная методология охватывает все этапы жизненного цикла современных информационных систем.
RAD — это комплекс специальных инструментальных средств быстрой разработ¬ки прикладных информационных систем, которые позволяют оперировать с определен¬ным набором графических объектов и  функционально отображают отдельные информационные компоненты приложений.
Под методологией быстрой разработки приложений обычно понимается процесс разработки информационных систем, основанный на трех основных элементах:
 небольшой команде программистов (обычно от 2 до 10 человек);
 тщательно проработанный производственный график работ, рассчитанный на сравнительно короткий срок разработки (от 2 до 6 мес);
 итерационная модель разработки, основанная на тесном взаимодействии с за¬казчиком — по мере выполнения проекта разработчики уточняют и реализуют в продукте требования, выдвигаемые заказчиком.
При использовании методологии RAD большое значение имеют опыт и профессио¬нализм разработчиков. Группа разработчиков должна состоять из профессиона¬лов, имеющих опыт в анализе, проектировании, программировании и тестирова¬нии программного обеспечения.
Основные принципы методологии RAD можно свести к следующему:
 используется итерационная (спиральная) модель разработки;
 полное завершение работ на каждом из этапов жизненного цикла не обяза¬тельно;
 в процессе разработки информационной системы необходимо тесное взаимо¬действие с заказчиком и будущими пользователями;
 необходимо применение CASE-средств и средств быстрой разработки прило¬жений; 
 необходимо применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
 необходимо использование прототипов, позволяющее полнее выяснить и реа¬лизовать потребности конечного пользователя;
 тестирование и развитие проекта осуществляются одновременно с разработкой;
 разработка ведется немногочисленной и хорошо управляемой командой про¬фессионалов;
 необходимы грамотное руководство разработкой системы, четкое планирова¬ние и контроль выполнения работ.

3. Объектно-ориентированный подход
Средства RAD дали возможность реализовывать совершенно иную по сравнению с традиционной технологию создания приложений.  Информационные объекты формируются как некие действующие модели (прототипы), чье функционирова¬ние согласовывается с пользователем, а затем разработчик может переходить не¬посредственно к формированию законченных приложений, не теряя из виду об¬щей картины проектируемой системы.
Возможность использования подобного подхода в значительной степени является результатом применения принципов объектно-ориентированного проектирования. Применение объектно-ориентированных методов позволяет преодолеть одну из главных трудностей, возникающих при разработке сложных систем — колоссаль¬ный разрыв между реальным миром (предметной областью описываемой пробле¬мы) и имитирующей средой.
Использование объектно-ориентированных методов позволяет создать описание (модель) предметной области в виде совокупности объектов — сущностей, объ¬единяющих данные и методы обработки этих данных (процедуры). Каждый объект обладает своим собственным поведением и моделирует некоторый объект реаль¬ного мира. С этой точки зрения объект является вполне осязаемой вещью, которая демонстрирует определенное поведение.
В объектном подходе акцент переносится на конкретные характеристики физи¬ческой или абстрактной системы, являющейся предметом программного моделирования. Объекты обладают целостностью, которая не может быть нарушена. Та¬ким образом, свойства, характеризующие объект и его поведение, остаются неиз¬менными. Объект может только менять состояние, управляться или становиться в определенное отношение к другим объектам.
Широкую известность объектно-ориентированное программирование получило с появлением визуальных средств проектирования, когда было обеспечено слия¬ние (инкапсуляция) данных с процедурами, описывающими поведение реаль¬ных объектов, в объекты программ, которые могут быть отображены определен¬ным образом в графической пользовательской среде.
Это позволило приступить к созданию программных систем, максимально похожих на реальные, и добивать¬ся наивысшего уровня абстракции. В свою очередь, объектно-ориентированное про¬граммирование позволяет создавать более надежные коды, так как у объектов про¬грамм существует точно определенный и жестко контролируемый интерфейс.
При разработке приложений с помощью инструментов RAD используется множе¬ство готовых объектов, сохраняемых в общедоступном хранилище. Однако обес¬печивается и возможность разработки новых объектов. При этом новые объекты могут разрабатываться как на основе существующих, так и «с нуля».
Инструментальные средства RAD обладают удобным графическим интерфейсом пользователя и позволяют на основе стандартных объектов формировать простые приложения без написания кода программы. Это является большим преимуще¬ством RAD, так как в значительной степени сокращает рутинную работу по разра¬ботке интерфейсов пользователя (при использовании обычных средств разработ¬ка интерфейсов представляет собой достаточно трудоемкую задачу, отнимающую много времени). Высокая скорость разработки интерфейсной части приложений позволяет быстро создавать прототипы и упрощает взаимодействие с конечными пользователями.
Таким образом, инструменты RAD позволяют разработчикам сконцентрировать усилия на сущности реальных деловых процессов предприятия, для которого со¬здается информационная система. В итоге это приводит к повышению качества разрабатываемой системы.

4. Визуальное программирование
Применение принципов объектно-ориентированного программирования позволи¬ло создать принципиально новые средства проектирования приложений, называе¬мые средствами визуального программирования. Визуальные инструменты RAD позволяют создавать сложные графические интерфейсы пользователя вообще без написания кода программы. При этом разработчик может на любом этапе наблю¬дать то, что закладывается в основу принимаемых решений.
Визуальные средства разработки оперируют в первую очередь со стандартными интерфейсными объектами — окнами, списками, текстами, которые легко можно связать с данными из базы данных и отобразить на экране монитора. Другая груп¬па объектов представляет собой стандартные элементы управления — кнопки, пе¬реключатели, флажки, меню и т. п., с помощью которых осуществляется управле¬ние отображаемыми данными. Все эти объекты могут быть стандартным образом описаны средствами языка, а сами описания сохранены для дальнейшего повтор¬ного использования.
В настоящее время существует довольно много различных визуальных средств разработки приложений. Но все они могут быть разделены на две группы — уни¬версальные и специализированные.
Среди универсальных систем визуального программирования сейчас наиболее распространены такие, как Borland Delphi и Visual Basic. Универсальными мы их называем потому, что они не ориентированы на разработку только приложений баз данных — с их помощью могут быть разработаны приложения почти любого типа, в том числе и информационные приложения. Причем программы, разраба¬тываемые с помощью универсальных систем, могут взаимодействовать практически с любыми системами управления базами данных. Это обеспечивается как исполь¬зованием драйверов ODBC или OLE DB, так и применением специализирован¬ных средств (компонентов).
Специализированные средства разработки ориентированы только на создание при¬ложений баз данных. Причем, как правило, они привязаны к вполне определен¬ным системам управления базами данных. В качестве примера таких систем мож¬но привести Power Builder фирмы Sybase (естественно, предназначенный для работы с СУБД Sybase Anywhere Server) и Visual FoxPro фирмы Microsoft.
Поскольку задачи создания прототипов и разработки пользовательского интерфейса, по существу, слились, программист получил непрерывную обратную связь с конеч¬ными пользователями, которые могут не только наблюдать за созданием приложе¬ния, но и активно участвовать в нем, корректировать результаты и свои требования. Это также способствует сокращению сроков разработки и является важным психоло¬гическим аспектом, который привлекает к RAD все большее число пользователей.
Визуальные инструменты RAD позволяют максимально сблизить этапы создания информационных систем: анализ исходных условий, проектирование системы, раз¬работка прототипов и окончательное формирование приложений становятся сход¬ными, так как на каждом этапе разработчики оперируют визуальными объектами.

5. Событийное программирование
Логика приложения, построенного с помощью RAD, является событийно-ориен¬тированной. Это означает следующее: каждый объект, входящий в состав прило¬жения, может генерировать события и реагировать на события, генерируемые дру¬гими объектами.
Примерами событий могут быть: открытие и закрытие окон, нажатие кнопки, нажатие клавиши клавиатуры, движение мыши, изменение дан¬ных в базе данных и т. п.
Разработчик реализует логику приложения путем определения обработчика каж¬дого события — процедуры, выполняемой объектом при наступлении соответству¬ющего события. Например, обработчик события «нажатие кнопки» может открыть диалоговое окно. Таким образом, управление объектами осуществляется с помо¬щью событий.
Обработчики событий, связанных с управлением базой данных (DELETE, INSERT, UPDATE), могут реализовываться в виде триггеров на клиентском или серверном узле. Такие обработчики позволяют обеспечить ссылочную целостность базы дан¬ных при операциях удаления, вставки и обновления, а также автоматическую ге¬нерацию первичных ключей.

6. Фазы жизненного цикла в рамках методологии RAD
При использовании методологии быстрой разработки приложений жизненный цикл информационной системы состоит из четырех фаз:
 фаза анализа и планирования требований;
 фаза проектирования;
 фаза построения;
 фаза внедрения.

6.1 Фаза анализа и планирования требований
На данной фазе выполняются следующие работы:
 определяются функции, которые должна выполнять разрабатываемая инфор¬мационная система;
 определяются наиболее приоритетные функции, требующие разработки в пер¬вую очередь;
 проводится описание информационных потребностей;
 ограничивается масштаб проекта;
 определяются временные рамки для каждой из последующих фаз;
 в заключение, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на имеющихся аппаратных и про¬граммных средствах. 
Если реализация проекта принципиально возможна, то результатом фазы анализа и планирования требований будет список функций разрабатываемой информаци¬онной системы с указанием их приоритетов и предварительные функциональные и информационные модели системы.

6.1 Фаза проектирования
На фазе проектирования необходимым инструментом являются CASE-средства, используемые для быстрого получения работающих прототипов приложений.
Термин CASE (Computer Aided Software/System Engineering) используется в настоя¬щее время в весьма широком смысле. Первоначальное значение термина CASE огра¬ничивалось лишь вопросами автоматизации разработки программного обеспечения. Однако в дальнейшем значение этого термина расширилось и приобрело новый смысл, охватывающий процесс разработки сложных информационных систем в целом.
Те¬перь под термином «CASE-средства» понимаются программные средства, поддер¬живающие процессы создания и сопровождения информационных систем, включая анализ и формулировку требований, проектирование прикладного программного обеспечения и баз данных, генерацию кода, тестирование, документирование, обес¬печение качества, конфигурационное управление и управление проектом, а также другие процессы.
Прототипы, созданные с помощью CASE-средств, анализируются пользователя¬ми, которые уточняют и дополняют те требования к системе, которые не были вы¬явлены на предыдущей фазе. Таким образом, на данной фазе также необходимо участие будущих пользователей в техническом проектировании системы.
Для построения всех моделей и прототипов должны быть использованы именно те CASE-средства, которые будут затем применяться при построении системы. Данное требование связано с тем, что при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение еди¬ной среды хранения информации о проекте позволяет избежать этой опасности.
Далее на этой фазе проводится анализ и при необходимости корректировка функ¬циональной модели системы. Детально рассматривается каждый процесс системы.
При необходимости для каждого элементарного процесса создается частичный про¬тотип: экран, диалог или отчет (это позволяет устранить неясности или неоднознач¬ности). Затем определяются требования разграничения доступа к данным.
После детального рассмотрения процессов определяется количество функциональ¬ных элементов разрабатываемой системы.
Это позволяет разделить информаци¬онную систему на ряд подсистем, каждая из которых реализуется одной командой разработчиков за приемлемое для RAD-проектов время (порядка полутора меся¬цев). С использованием CASE-средств проект распределяется между различными командами — делится функциональная модель.
На этой же фазе происходит определение набора необходимой документации.
Результатами данной фазы являются:
 общая информационная модель системы;
 функциональные модели системы в целом и подсистем, реализуемых отдель¬ными командами разработчиков;
 точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;
 построенные прототипы экранов, диалогов и отчетов.
Одной из особенностей применения методологии RAD на данной фазе является то, что каждый созданный прототип развивается в часть будущей системы. Таким обра¬зом, на следующую фазу передается более полная и полезная информация. (При тра¬диционном подходе использовались средства прототипирования, не предназначен¬ные для построения реальных приложений, поэтому разработанные прототипы не могли быть использованы на последующих фазах и просто «выбрасывались» после того, как выполняли задачу устранения неясностей в проекте.)

6.3 Фаза построения
На фазе построения выполняется собственно быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных ранее моделей, а также требований нефункционального ха¬рактера. Разработка приложения ведется с использованием визуальных средств программирования. Формирование программного кода частично выполняется с помощью автоматических генераторов кода, входящих в состав CASE-средств. Код генерируется на основе разработанных моделей.
На фазе построения также требуется участие пользователей системы, которые оце¬нивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирова¬ние системы осуществляется непосредственно в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется пол¬ный программный код, выполняется тестирование совместной работы данной ча¬сти приложения с остальными, а затем тестирование системы в целом.
Завершается физическое проектирование системы, а именно:
 определяется необходимость распределения данных;
 производится анализ использования данных;
 производится физическое проектирование базы данных;
 определяются требования к аппаратным ресурсам;
 определяются способы увеличения производительности;
 завершается разработка документации проекта.
Результатом данной фазы является готовая информационная система, удовлетво¬ряющая всем требованиям пользователей.

6.4 Фаза внедрения
Фаза внедрения в основном сводится к обучению пользователей разработанной информационной системы. Так как фаза построения достаточно непродолжительна, планирование и подготов¬ка к внедрению должны начинаться заранее, еще на этапе проектирования системы.
Приведенная схема разработки информационной системы не является универсаль¬ной. Вполне возможны различные отклонения от нее. Это связано с зависимостью схемы выполнения проекта от начальных условий, при которых начинается разработ¬ка (например, разрабатывается совершенно новая система или на предприятии уже существует некоторая информационная система). Во втором случае существующая система может либо использоваться в качестве прототипа новой системы, либо ин¬тегрироваться в новую разработку в качестве одной из подсистем.

7. Ограничения методологии RAD
Несмотря на все свои достоинства, методология RAD тем не менее (как, впрочем, и любая другая методология) не может претендовать на универсальность. Ее при¬менение наиболее эффективно при выполнении сравнительно небольших систем, разрабатываемых для вполне определенного предприятия.
При разработке же типовых систем, не являющихся законченным продуктом, а пред¬ставляющих собой совокупность типовых элементов информационной системы, большое значение имеют такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Это свя¬зано с тем, что типовые системы обычно централизованно сопровождаются и мо¬гут быть адаптированы к различным программно-аппаратным платформам, системам управления базами данных, коммуникационным средствам, а также интегрировать¬ся с существующими разработками. Поэтому для такого рода проектов необходим высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает ско¬рость разработки.
Методология RAD неприменима не только для создания типовых информацион¬ных систем, но и для построения сложных расчетных программ, операционных систем или программ управления сложными инженерно-техническими объекта¬ми — программ, требующих написания большого объема уникального кода.
Методология RAD не может быть использована для разработки приложений, в ко¬торых интерфейс пользователя является вторичным, то есть отсутствует нагляд¬ное определение логики работы системы. Примерами таких приложений могут служить приложения реального времени, драйверы или службы.
Совершенно неприемлема методология RAD для разработки систем, от которых зависит безопасность людей, — например, систем управления транспортом или атомных электростанций. Это обусловлено тем, что итеративный подход, являю¬щийся одной из основ RAD, предполагает, что первые версии системы не будут полностью работоспособны, что в данном случае может привести к серьезнейшим катастрофам.


 
загрузка...

Добавить комментарий


Защитный код
Обновить