Контрольная: Подход RAD - текст контрольной. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Контрольная

Подход RAD

Банк рефератов / Информатика, информационные технологии

Рубрики  Рубрики реферат банка

закрыть
Категория: Контрольная работа
Язык контрольной: Русский
Дата добавления:   
 
Скачать
Архив Zip, 107 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникальной работы

Узнайте стоимость написания уникальной работы

Контрольная работа Тема: Подход RAD Содержание Введение 1. Подход RAD 1. Программное обеспечение по методо логии RAD 1.2. Методология RAD 2. Применение подхода RAD . Его отличие 2.1 Отличие подхода RAD от традиционного 2.2. Опыт применения методологий RAD в конкретных проектах (на примере Национального Банка) 2.3. Применение подхода RAD в других областях Заключение Список литературы Введение Для успешной реализации про екта объект проектирования информационных систем должен быть прежде в сего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели информационных систем. Накопленный к настоящему времени оп ыт проектирования информационных систем показывает, что это логически сложная, трудоёмкая и длительная по времени работа, требующая высокой кв алификации участвующих в ней специалистов. Однако до недавнего времени проектирование информационных систем выполнялось в основном на интуит ивном уровне с применение неформализованных методов, основанных на иск усстве, практическом опыте, экспертных оценках и дорогостоящих экспери ментальных проверках качества функционирования информационных систе м. Кроме того, в процессе создания и функционирования информационных сис тем информационные потребности пользователей изменяться или уточнять ся, что ещё более усложняет разработку таких систем. Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели ЖЦ явл яется получившая в последнее время широкое распространение методологи я быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно пон имается процесс разработки программного обеспечения, содержащий 3 элем ента: · небольшую команду программис тов (от 2 до 10 человек); · короткий, но тщательно прорабо танный производственный график (от 2 до 6 мес.); · повторяющийся цикл, при которо м разработчики, по мере того, как приложение начинает обретать форму, зап рашивают и реализуют в продукте требования, полученные через взаимодей ствие с заказчиком. · Команда разработчиков должна п редставлять из себя группу профессионалов, имеющих опыт в анализе, проек тировании, генерации кода и тестировании программного обеспечения с ис пользованием CASE-средств. Члены коллектива должны также уметь трансформи ровать в рабочие прототипы предложения конечных пользователей. 1. Подход RAD 1. Программное обеспечение по методологии RAD Жизненный цикл программного обеспечения по методологии RAD состоит из четырех фаз: · фаза анализа и планирования тр ебований; · фаза проектирования; · фаза построения; · фаза внедрения. На фазе анализа и планирования требований пользователи системы определяют функции, которые она должн а выполнять, выделяют наиболее приоритетные из них, требующие проработк и в первую очередь, описывают информационные потребности. Определение т ребований выполняется в основном силами пользователей под руководство м специалистов-разработчиков. Ограничивается масштаб проекта, определ яются временные рамки для каждой из последующих фаз. Кроме того, определ яется сама возможность реализации данного проекта в установленных рам ках финансирования, на данных аппаратных средствах и т.п. Результатом да нной фазы должны быть список и приоритетность функций будущей информац ионной системы, предварительные функциональные и информационные модел и информационных систем. На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специал истов-разработчиков. CASE-средства используются для быстрого получения ра ботающих прототипов приложений. Пользователи, непосредственно взаимод ействуя с ними, уточняют и дополняют требования к системе, которые не был и выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функционал ьная модель. Каждый процесс рассматривается детально. При необходимост и для каждого элементарного процесса создается частичный прототип: экр ан, диалог, отчет, устраняющий неясности или неоднозначности. Определяют ся требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценива ется количество функциональных элементов разрабатываемой системы и пр инимается решение о разделении информационных систем на подсистемы, по ддающиеся реализации одной командой разработчиков за приемлемое для RAD- проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распр еделяется между различными командами (делится функциональная модель). Р езультатом данной фазы должны быть: · общая информационная модель с истемы; · функциональные модели систем ы в целом и подсистем, реализуемых отдельными командами разработчиков; · точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами; · построенные прототипы экрано в, отчетов, диалогов. Все модели и прототипы должн ы быть получены с применением тех CASE-средств, которые будут использоватьс я в дальнейшем при построении системы. Данное требование выз вано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение д анных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности. 1.2. Методология RAD Один из подходов к разработке ПО в рамках спиральной мо дели ЖЦ - получившая широкое распространение методология быстрой разра ботки приложений RAD (Rapid Application Development), она включает в себя три составляющие: · небольшую команду программис тов (от 2 до 10 человек); · короткий, но тщательно прорабо танный производственный график (от 2 до 6 мес.); · повторяющийся цикл, при которо м разработчики по мере того, как приложение начинает обретать форму, зап рашивают и реализуют в продукте требования, полученные через взаимодей ствие с заказчиком. Команда разработчиков должн а представлять собой группу профессионалов, имеющих опыт в анализе, прое ктировании, генерации кода и тестировании ПО с использованием CASE-средств , способных хорошо взаимодействовать с конечными пользователями и тран сформировать их предложения в рабочие прототипы. Жизненный цикл ПО по методологии RAD с остоит из четырех фаз: анализа и планирования требований; проектировани я; построения; внедрения. На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиб олее приоритетные из них, требующие проработки в первую очередь, описыва ют информационные потребности. Формулирование требований к системе ос уществляется в основном силами пользователей под руководством специал истов-разработчиков. Ограничивается масштаб проекта, устанавливаются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации проекта в заданных размерах финансировани я, на имеющихся аппаратных средствах и т.п. Результатом фазы должны быть с писок расставленных по приоритету функций будущей ИС, предварительные функциональные и информационные модели ИС. На фазе проектирования часть пользователей принимает у частие в техническом проектировании системы под руководством специали стов-разработчиков. CASE-средства используются для быстрого получения раб отающих прототипов приложений. Пользователи, непосредственно взаимоде йствуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы с истемы. Анализируется и при необходимости корректируется функциональн ая модель. Каждый процесс рассматривается детально. Если требуется, для каждого элементарного процесса создается частичный прототип: экран, ди алог, отчет, устраняющий неясности или неоднозначности. Устанавливаютс я требования разграничения доступа к данным. На этой же фазе происходит определение необходимой документации. После детального определения состава процессов оценива ется количество функциональных элементов разрабатываемой системы и пр инимается решение о разделении ИС на подсистемы, поддающиеся реализаци и одной командой разработчиков за приемлемое для RAD-проектов время (60 - 90 дне й). С использованием CASE-средств проект распределяется между различными ко мандами (делится функциональная модель). Результатом данной фазы должны быть: · общая информационная модель с истемы; · функциональные модели систем ы в целом и подсистем, реализуемых отдельными командами разработчиков; · точно определенные с помощью CASE-средств интерфейсы между автономно разрабатываемыми подсистемами; · построенные прототипы экрано в, отчетов, диалогов. Все модели и прототипы должн ы быть получены с применением тех CASE-средств, которые будут использоватьс я в дальнейшем при построении системы. Данное требование вызвано тем, чт о в традиционном подходе при передаче информации о проекте с этапа на эт ап может произойти фактически неконтролируемое искажение данных. Прим енение единой среды хранения информации о проекте позволяет этого избе жать. В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, н е предназначенные для построения реальных приложений, а прототипы выбр асывались после того, как выполняли задачу устранения неясностей в прое кте, в подходе RAD каждый прототип развивается в часть будущей системы. Так им образом, на следующую фазу передается более полная и полезная информа ция. На фазе построения выполняется непосредственно сама бы страя разработка приложения. На данной фазе разработчики производят ит еративное построение реальной системы на основе полученных в предыдущ ей фазе моделей, а также требований нефункционального характера. Програ ммный код частично формируется при помощи автоматических генераторов, получающих информацию из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ран ее требованиям. Тестирование системы осуществляется в процессе разраб отки. После окончания работ каждой отдельной команды разрабо тчиков производится постепенная интеграция данной части системы с ост альными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения, а затем тестирование систем ы в целом. Завершается физическое проектирование системы: · определяется необходимость р аспределения данных; · осуществляется анализ исполь зования данных; · производится физическое прое ктирование базы данных; · определяются требования к апп аратным ресурсам; · определяются способы увеличе ния производительности; · завершается разработка докум ентации проекта. Результатом фазы является г отовая система, удовлетворяющая всем согласованным требованиям. На фазе внедрения производятся обуч ение пользователей, организационные изменения и параллельно с внедрен ием новой системы осуществляется работа с существующей системой (до пол ного внедрения новой). Так как фаза построения достаточно непродолжител ьна, планирование и подготовка к внедрению должны начинаться заранее, ка к правило, на этапе проектирования системы. Приведенная схема разработк и ИС не является абсолютной. Возможны различные варианты, зависящие, нап ример, от начальных условий, в которых ведется разработка: разрабатывает ся совершенно новая система; уже было проведено обследование предприят ия и существует модель его деятельности; на предприятии уже существует н екоторая ИС, которая может быть использована в качестве начального прот отипа или должна быть интегрирована с разрабатываемой. Следует, однако, отметить, что методология RAD, как и любая др угая, не может претендовать на универсальность, она хороша в первую очер едь для относительно небольших проектов, разрабатываемых для конкретн ого заказчика. Если же разрабатывается типовая система, которая не являе тся законченным продуктом, а представляет собой комплекс типовых компо нентов, централизованно сопровождаемых, адаптируемых к программно-тех ническим платформам, СУБД, средствам телекоммуникации, организационно- экономическим особенностям объектов внедрения и интегрируемых с сущес твующими разработками, на первый план выступают такие показатели проек та, как управляемость и качество, которые могут войти в противоречие с пр остотой и скоростью разработки. Для таких проектов необходимы высокий у ровень планирования и жесткая дисциплина проектирования, строгое след ование заранее разработанным протоколам и интерфейсам, что снижает ско рость разработки. Методология RAD неприменима для построения сложных расчет ных программ, операционных систем или программ управления космическим и кораблями, т.е. программ, содержащих большой объем (сотни тысяч строк) ун икального кода. Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно опре деляющая логику работы системы (например, приложения реального времени ), и приложения, от которых зависит безопасность людей (например, управлен ие самолетом или атомной электростанцией), так как итеративный подход пр едполагает, что первые несколько версий наверняка не будут полностью ра ботоспособны, что в данном случае исключается. Оценка размера приложений производится на основе так на зываемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п .). Подобная метрика не зависит от языка программирования, на котором веде тся разработка. Размер приложения, которое может быть выполнено по метод ологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повто рным использованием программных компонентов определяется следующим о бразом: · менее 1000 функциональных элемен тов - один человек; · 1000 - 4000 функциональных элементов - одна команда разработчиков; · более 4000 функциональных элемен тов - 4000 функциональных элементов на одну команду разработчиков. · Итак, перечислим основные прин ципы методологии RAD: · разработка приложений итерац иями; · необязательность полного зав ершения работ на каждом из этапов жизненного цикла; · обязательность вовлечения по льзователей в процесс разработки ИС; · необходимость применения CASE-ср едств, обеспечивающих целостность проекта; · применение средств управления к онфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы; · необходимость использования генераторов кода; · использование прототипирован ия, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя; · тестирование и развитие проек та, осуществляемые одновременно с разработкой; · ведение разработки немногочи сленной хорошо управляемой командой профессионалов; · грамотное руководство разраб откой системы, четкое планирование и контроль выполнения работ. 2. Применение п одхода RAD . Его отличие 2.1 Отличие подхода RAD от традиционного В отличие от традиционного п одхода, при котором использовались специфические средства прототипиро вания, не предназначенные для построения реальных приложений, а прототи пы выбрасывались после того, как выполняли задачу устранения неясносте й в проекте, в подходе RAD каждый прототип развивается в часть будущей сист емы. Таким образом, на следующую фазу передается более полная и полезная информация. На фазе построения выполняется непо средственно сама быстрая разработка приложения. На данной фазе разрабо тчики производят итеративное построение реальной системы на основе по лученных в предыдущей фазе моделей, а также требований нефункционально го характера. Программный код частично формируется при помощи автомати ческих генераторов, получающих информацию непосредственно из репозито рия CASE-средств. Конечные пользователи на этой фазе оценивают получаемые р езультаты и вносят коррективы, если в процессе разработки система перес тает удовлетворять определенным ранее требованиям. Тестирование систе мы осуществляется непосредственно в процессе разработки. После окончания работ каждой отдельной команды разрабо тчиков производится постепенная интеграция данной части системы с ост альными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестиро вание системы в целом. Завершается физическое проектирование системы: · определяется необходимость р аспределения данных; · производится анализ использо вания данных; · производится физическое прое ктирование базы данных; · определяются требования к апп аратным ресурсам; · определяются способы увеличе ния производительности; · завершается разработка докум ентации проекта. Результатом фазы является г отовая система, удовлетворяющая всем согласованным требованиям. На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы ос уществляется работа с существующей системой (до полного внедрения ново й). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки информационных с истем не является абсолютной. Возможны различные варианты, зависящие, на пример, от начальных условий, в которых ведется разработка: разрабатывае тся совершенно новая система; уже было проведено обследование предприя тия и существует модель его деятельности; на предприятии уже существует некоторая информационная система, которая может быть использована в ка честве начального прототипа или должна быть интегрирована с разрабаты ваемой. 2.2. Опыт применения методологий RAD в конкретных проектах (на примере Национального Банка) При использовании методологии проектирования от данных при разр аботке системы надзора для Национального Банка были получены схемы вза имодействия отдела надзора, деятельность которого автоматизировалась , с внешними организациями, модели деятельности отдела в виде диаграмм б изнес-процессов, временные диаграммы выполнения процессов, концептуал ьная модель данных автоматизируемой задачи. Результатами обследования деятельности отдела явились состав и содержание ролевых функций отдел а, состав и содержание форм документов, выпускаемой отделом, описание пр ограммных средств, используемых в отделе. Анализ результатов обследова ния выявил направления совершенствования информатизации отдела и позв олил сформулировать требования к доработке существующих систем и к инт еграции приложений. Использование современных технологий разработки и сопр овождения программного обеспечения (в частности подход RAD ) дало новые возможности: · Г ибкость ориентации на "ролевые" функции · Переносимость ПО на другие пла тформы без перепрограммирования · Более высокая производительн ость в разработке и сопровождении · Упрощение реализации новых фу нкциональных задач без перепрограммирования На этапе проектирования системы концептуальная модель данных бы ла преобразована в реляционную модель данных (структуру базы данных), со здана архитектура информационной системы: схемы навигации экранов при ложений, модели данных приложений, модели интерфейса (данных, спецификац ии, представления). Рис. 1. Архитектура информ ационной системы При создании системы была реализована спиральная моде ль жизненного цикла, было получено четыре прототипа системы, разработка каждого прототипа заняла четыре недели. В конце четвертого цикла протот ипирования была получена полностью функциональная система, которая ба ла передана заказчику для опытной эксплуатации. При создании первого прото типа были зафиксированы внешние представления системы, собраны замеча ния и предложения заказчика по реализованному составу ролевых функций, внешнему виду и функциональности системных модулей, замечания и предло жения по проекту документации сопровождения. В состав первого прототип а вошли работающая версия системы, уточненная диаграмма автоматизируе мых ролевых функций, список реализованных ролевых функций, реляционная модель данных системы и пояснительная записка к ней, архитектура систем ы в виде схемы навигации модулей, модели данных автоматизируемых функци й и интерфейсных элементов, внешний вид интерфейсных элементов (на бумаж ном носителе), исходные тексты прикладного программного обеспечения (на магнитном носителе). В результате предъявления первого прототипа заказч ику были получены протокол рассмотрения итогов создания прототипа, спи сок замечаний по составу ролевых функций, список замечаний по составу ре ализованных в базе данных системы сущностей предметной области, соглаш ение по внешнему виду системы с приложением к протоколу в виде бумажных копий экранов с замечаниями на них. При реализации второго прототипа были зафиксирован ы перечень и состав ролевых функций системы и способы их реализации, стр уктура базы данных системы, проверены выполнения требований к первому п рототипу и сбор замечаний по функциональности экранов и логикам формир ования отчетов. Результатами второго прототипа явились протокол ра ссмотрения итогов создания 2-го прототипа, список замечаний по функциона льности экранов и логикам формирования отчетов, приложение к протоколу в виде бумажных копий экранов с замечаниями на них. Результаты третьего пр ототипа были аналогичны. Перед вводом системы в опытную эксплуатацию были с озданы рабочая база данных системы, рабочие места пользователей, систем ы автоматизированного версионного управления версиями ПО и автоматизи рованного сбора замечаний, проведено обучение пользователей. Таблица 1. Таблица характеристик проекта Объекты проекта Общее количе ство Файлы экранов 217 Файлы отчетов 74 Файлы меню 33 Файлы моделей архитекту ры 41 Файлы моделей данных 18 Характеристики проекта при тра диционном подходе: Сложность проекта ~ 1850 ф.т. Типичная норма выработки - 18 ф. т. на человеко-месяц Проект потребует - 103 человеко-месяца 5 человек - более 20 месяцев при спиральной модели жизненного цикла: Сложность проекта ~ 1850 ф.т. Проект потребовал - 38 человеко-месяцев Норма выработки - 48,5 ф.т. на человеко-м есяц. Рис. 2. Структура рабочих м ест группы RAD Высокая производительность проекта достигалась за сч ет использования средств автоматизации анализа и проектирования (CASE SilverRun), языка четвертого поколения (JAM), за счет автоматизации всей технологическ ой цепочки (мост SR-(JAM), использования средств конфигурационного управлени я (PVCS), средства автоматизации тестирования QualityWorks. 2.3. Применение подхода RAD в других областях Методология RAD непримени ма для построения сложных расчетных программ, операционных систем или п рограмм управления космическими кораблями, т.е. программ, требующих напи сания большого объема (сотни тысяч строк) уникального кода. Не подходят для разработки по м етодологии RAD приложения, в которых отсутствует ярко выраженная интерфе йсная часть, наглядно определяющая логику работы системы (например, прил ожения реального времени) и приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий навер няка не будут полностью работоспособны, что в данном случае исключается . Оценка размера приложени й производится на основе так называемых функциональных элементов (экра ны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка про граммирования, на котором ведется разработка. Размер приложения, которо е может быть выполнено по методологии RAD, для хорошо отлаженной среды разр аботки информационных систем с максимальным повторным использованием программных компонентов, определяется следующим образом: Таблица 2. Определение размера приложения по методол огии RAD < 1000 фун кциональных элементов один челов ек 1000-4000 функциональных элементов одна команда разработч иков > 4000 функциональных элементов 4000 функциональных элеме нтов на одну команду разработчиков Заключение Недостатки традиционного (каскадного) подхода к построению жи зненного цикла программного обеспечения хорошо известны. Жестко зафик сированные требования к разрабатываемой системе в самом начале жизнен ного цикла, отсутствие в процессе реализации участия конечного пользов ателя приводят к тому, что проект растягивается на годы, выходит за рамки установленного бюджета, полученная в результате система не удовлетвор яет требованиям пользователей. Развитие информационных т ехнологий, появление средств автоматизации практически всех этапов жи зненного цикла привели к возникновению разнообразных моделей жизненны х циклов современных информационных систем. Современные методологии р азработки программных продуктов позволяют создавать в сжатые сроки си стемы высокого качества, удовлетворяющие требованиям пользователей. М ногие из современных методологий поддерживаются современными инструм ентальными средствами. Наиболее широкое распространение получила методол огия быстрой разработки приложений RAD (rapid application development), которая охватывает все э тапы жизненного цикла современных информационных систем. Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь дл я относительно небольших проектов, разрабатываемых для конкретного за казчика. Если же разрабатывается типовая система, которая не является за конченным продуктом, а представляет собой комплекс типовых компонент, ц ентрализованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД и т.д., на первый план выступают такие показатели проекта , как управляемость и качество, которые могут войти в противоречие с прос тотой и скоростью разработки. Для таких проектов необходимы высокий уро вень планирования и жесткая дисциплина проектирования, строгое следов ание заранее разработанным протоколам и интерфейсам, что снижает скоро сть разработки. В качестве итога перечислим осн овные принципы методологии RAD: · разработка прилож ений итерациями; · необязательность полного завершения работ на каждом из этапов жизненного цикла; · обязательное вовле чение пользователей в процесс разработки информационных систем; · необходимое приме нение CASE-средств, обеспечивающих целостность проекта; · применение средст в управления конфигурацией, облегчающих внесение изменений в проект и с опровождение готовой системы; · необходимое испол ьзование генераторов кода; · использование про тотипирования, позволяющее полнее выяснить и удовлетворить потребност и конечного пользователя; · тестирование и ра звитие проекта, осуществляемые одновременно с разработкой; · ведение разработк и немногочисленной хорошо управляемой командой профессионалов; · грамотное руковод ство разработкой системы, четкое планирование и контроль выполнения ра бот. Сп исок литературы 2. Автоматизированн ые информационные технологии в экономике/Под ред. И.Т. Трубилина. – М.: Фин ансы и статистика, 2000. 3. Автоматизированн ые информационные технологии в экономике: Учебник/Под ред. Г.А. Титоренко. – М.: Компьютер: ЮНИТИ, 1998. 4. Благодатских В.А. Э кономика, разработка и использование программного обеспечения ЭВМ. – М : Финансы и статистика, 1995. 5. Благодатских В.А., В олнин В.А., Поскакалов К.Ф. Стандартизация разработки программных средст в. – М: Финансы и статистика, 2003. 6. Вендров А.М. Пректи рование программного обеспечения экономических информационных систе м – М: Финансы и статистика, 2002. 7. Вендрова А.М. Практ икуме по проектированию программного обеспечения экономических инфор мационных систем – М: Финансы и статистика, 2002. 8. Информатика. Базо вый курс // Под ред. С.В. Симоновича, СПб., 2000. 9. Компьютерные техн ологии обработки информации./Под. ред. С.В. Назарова. – М.: Финансы и статист ика, 1995. 10. Котов С.Л. Нормиров ание жизненного цикла программной продукции. – М.: ЮНИТИ-ДАНА, 2002. 11. Липаев В.В. Надежно сть программных средств – М: СИНТЕГ, 1998. 12. Орлов С.А. Технолог ии разработки программного обеспечения: Разработка сложных программны х систем: Учебное пособие для студентов вузов, обуч. по напр. Подготовки ак алавров и магистров «Информатика и выч.техника». – СПб.: Питер, 2002. 13. Черемных С.В., Семен ов И.О., Ручкин В.С. Моделирование и анализ систем: IDEF-технологии: практикум – М: Финансы и статистика, 2002. 14. Черемных С.В., Семен ов И.О., Ручкин В.С. Структурный анализ систем: IDEF-технологии – М: Финансы и с татистика, 2001.
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
А между тем Бурановские дедушки уже начали вспоминать, как играть в футбол, и учить футбольные правила.
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

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

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru