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

Реферат

Основы методологии проектирования ИС

Банк рефератов / Программирование

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

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

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

Основы методологии проектирования ИС 1.1. Жизненный цикл по ИС Одни м из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее про граммного обеспечения (ЖЦ ПО ). ЖЦ ПО - это непрерывный процесс , который начинается с м омента принятия решения о необходимости его создания и заканчивается в момент е го полного изъятия из эксплуатации . Основным нормативным документом , регламентиру ющим ЖЦ ПО , является международный стандарт ISO/IEC 12207 [5] (ISO - International Organization of Standardization - Международная организация по ст андартизации , IEC - Intern ational Electrotechnical Commission - Международная комиссия по электротехнике ). Он определяет структуру ЖЦ , содержащую процессы , действия и задачи , которые должны быть выполнены во время создания ПО . Структура ЖЦ ПО по стандарту ISO/IEC 12207 бази руется на трех группах процессов : · основные процессы ЖЦ ПО (приобретени е , поставка , разработка , эксплуатация , сопровождени е ); · вспомогательные процессы , обеспечивающие выполнение основных процессов (документирование , управление конфигурацией , обеспеч ение каче ства , верификация , аттестация , оце нка , аудит , решение проблем ); · организационные процессы (управление проектами , создание инфраструктуры проекта , определение , оценка и улучшение сам ого ЖЦ , обучение ). Разработка включае т в себя все работы по созданию ПО и его компонент в соответствии с заданными требованиями , включая оформление проект ной и эксплуатационной документации , подготовку материалов , необходимых для проверки работоспос обности и соответствующего качества программных продуктов , материалов , необход и мых для организации обучения персонала и т.д . Разработка ПО включает в себя , как прав ило , анализ , проектирование и реализацию (прогр аммирование ). Эксплуатация включает в себя работы п о внедрению компонентов ПО в эксплуатацию , в том числе конфигурирование базы да нных и рабочих мест пользователей , обеспечени е эксплуатационной документацией , проведение обуч ения персонала и т.д ., и непосредственно эк сплуатацию , в том числе локализацию проблем и устранение причин их возникновения , модиф икацию ПО в рамках устан о вленного регламента , подготовку предложений по соверш енствованию , развитию и модернизации системы . Управление проектом связано с вопросами планирования и организации работ , создания коллективов разработчиков и контроля за ср оками и качеством выполняемых р абот . Т ехническое и организационное обеспечение проекта включает выбор методов и инструментальных средств для реализации проекта , определение методов описания промежуточных состояний разра ботки , разработку методов и средств испытаний ПО , обучение персонал а и т.п . Обеспечение качества проекта связано с про блемами верификации , проверки и тестирования ПО . Верификация - это процесс определения того , отвечает ли текущее состояние разработки , достигнутое на данном этапе , требованиям эт ого этапа . Проверка позволя е т оцен ить соответствие параметров разработки с исхо дными требованиями . Проверка частично совпадает с тестированием , которое связано с идентифи кацией различий между действительными и ожида емыми результатами и оценкой соответствия хар актеристик ПО исходным т ребованиям . В процессе реализации проекта важное место занимают вопросы идентификации , описания и контроля конфигурации отдельных компонентов и всей системы в целом . Управление конфигурацией является одним и з вспомогательных процессов , поддерживающих осно вные процессы жизненного цикла ПО , пре жде всего процессы разработки и сопровождения ПО . При создании проектов сложных ИС , состоящих из многих компонентов , каждый из которых может иметь разновидности или верс ии , возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы . Упра вление конфигурацией позволяет организовать , сист ематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ . Общие принципы и рекомендации конфигурационного учета , планирования и управления конфигурациями ПО отражены в проекте стандарт а ISO 12207-2 [5]. Каждый процесс характеризуется определенными задачами и методами их решения , исходными данными , полученными на предыдущем этапе , и результатами . Результатами анализа , в частности , являются функциональные модели , информа ционные модели и соответствующие им диаграммы . ЖЦ ПО носит итерационный характер : резул ьтаты очередного этапа часто вызывают изменен ия в проектных решениях , выработанных на б олее ранних этапах . Модели жизненного цикла ПО Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура , определяющая последовательность выполне ния и взаимосвязи процессов , действий и за дач , выполняемых на протяжени и ЖЦ . Мод ель ЖЦ зависит от специфики ИС и спец ифики условий , в которых последняя создается и функционирует ). Его регламенты являются общими для любых моделей ЖЦ , методологий и технологий разработки . Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ П О , но не конкретизирует в деталях , как реализовать или выполнить действия и задачи , включенн ые в эти процессы . К настоящему времени наибольшее распростр анение получили следующие две основные модели ЖЦ : · каскадная модель (70-85 г.г .); · спиральная модел ь (86-90 г.г .). В изначально с уществовавших однородных ИС каждое приложение представляло собой единое целое . Для разраб отки такого типа приложений применялся каскад ный способ . Его основной характеристикой явля ется разбиение всей разработки на этапы , п риче м переход с одного этапа на с ледующий происходит только после того , как будет полностью завершена работа на текуще м (рис . 1.1). Каждый этап завершается выпуском полного комплекта документации , достаточной для того , чтобы разработка могла быть продолжен а д р угой командой разработчиков . Положительные стороны применения каскадного подхода заключаются в следующем [2]: · на каждом этапе формируется законче нный набор проектной документации , отвечающий критериям полноты и согласованности ; · выполняемые в логичн о й последовательности этапы работ позволя ют планировать сроки завершения всех работ и соответствующие затраты . Рис. 1.1. Каскадная схема разр аботки ПО Каскадный подход хорошо зарекомендовал себя при пост роении ИС , для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования , с тем чтобы предоставить разработчикам свободу реализова ть их как можно лучше с техническ ой точки зрения . В эту категорию попадают сложные расчетные системы , системы реального времени и другие подобные задачи . Однако , в процессе использования этого подхода о бнаружился ряд его недостатков , вызванных пре жде всег о тем , что реальный проц есс создания ПО никогда полностью не укла дывался в такую жесткую схему . В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уто чнении или пересмотре ранее принятых решений . В результате реальный п р оцесс создания ПО принимал следующий вид (рис . 1.2): Рис . 1.2. Реальный процесс разработк и ПО по каскадной схеме О сн овным недостатком каскадного подхода является существенное запаздывание с получением результ атов . Согласование результатов с пользователями производится только в точках , планируемых п осле завершения каждого этапа работ , требован ия к ИС "заморожены " в ви д е технического задания на все время ее с оздания . Таким образом , пользователи могут вне сти свои замечания только после того , как работа над системой будет полностью заве ршена . В случае неточного изложения требовани й или их изменения в течение длительного п е риода создания ПО , пользователи получают систему , не удовлетворяющую их п отребностям . Модели (как функциональные , так и информационные ) автоматизируемого объекта могут устареть одновременно с их утверждением . Для преодоления перечисленных проблем был а пре дложена спиральная модель ЖЦ [10] (р ис . 1.3), делающая упор на начальные этапы ЖЦ : анализ и проектирование . На этих этапах реализуемость технических решений проверяется путем создания прототипов . Каждый виток спи рали соответствует созданию фрагмента или в е рсии ПО , на нем уточняются це ли и характеристики проекта , определяется его качество и планируются работы следующего витка спирали . Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный в ариант , к оторый доводится до реализа ции . Разработка итерациями отражает объективно существующий спиральный цикл создания системы . Неполное завершение работ на каждом этап е позволяет переходить на следующий этап , не дожидаясь полного завершения работы на текущем . П ри итеративном способе разраб отки недостающую работу можно будет выполнить на следующей итерации . Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт , тем самым активизируя процесс уточнения и дополнения тр ебований. Основная проблема спирального цикла - опре деление момента перехода на следующий этап . Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненно го цикла . Переход осуществляется в соответств ии с планом , даже если не вся запланир ов анная работа закончена . План составляет ся на основе статистических данных , полученны х в предыдущих проектах , и личного опыта разработчиков . Рис 1.3. Спиральная модель ЖЦ Методологии и технологии проектирования ИС 1.3.1. Общие требования к методоло гии и технологии Методологии , техно логии и инструментальные средства проектирования (CASE-средства ) составляют о снову проекта любой ИС . Методология реализуется через кон кретные технологии и поддерживающие их станда рты , методики и инструментальные средства , кот орые обеспечивают выполнение процессов ЖЦ . Технология проектирования определяется как совокупность трех сос тавляющих : · пошаговой процедуры , определяющей послед овательность технологических операций проектирования (рис . 1.4); · критериев и правил , используемых для оценки результатов выполнения технологических операций ; · нотаций (графических и текстовых средс тв ), используемых для описания проектируемой системы . Рис . 1.4. Представление технологической операции проектирова ния Технологиче ские инструкции , составляющие основное содержание технологии , должны состоять из описания п оследовательности технологических операций , условий , в зависимости от которых выполняется та или иная операция , и описаний самих опе раций . Технологи я проектирования , разработки и сопровождения ИС должна удовлетворять след ующим общим требованям : · технология должна поддерживать полный ЖЦ ПО ; · технология должна об еспечивать гарантированное достижение целей разр аботки ИС с заданным качеством и в ус тан овленное время ; · технология должна об еспечивать возможность выполнения крупных проект ов в виде подсистем (т.е . возможность деком позиции проекта на составные части , разрабаты ваемые группами исполнителей ограниченной числен ности с последующей интеграцией с оставных частей ). Опыт разработки крупных ИС показ ывает , что для повышения эффективности работ необходимо разбить проект на отдельные с лабо связанные по данным и функциям подси стемы . Реализация подсистем должна выполняться отдельными группами специалистов. При это м необходимо обеспечить координацию ведения о бщего проекта и исключить дублирование резуль татов работ каждой проектной группы , которое может возникнуть в силу наличия общих данных и функций ; · технология должна об еспечивать возможность ведения раб от по проектированию отдельных подсистем небольшими группами (3-7 человек ). Это обусловлено принципами управляемости коллектива и повышения произво дительности за счет минимизации числа внешних связей ; · технология должна об еспечивать минимальное время пол учения ра ботоспособной ИС . Речь идет не о сроках готовности всей ИС , а о сроках реализац ии отдельных подсистем . Реализация ИС в це лом в короткие сроки может потребовать пр ивлечения большого числа разработчиков , при э том эффект может оказаться ниже , чем пр и реализации в более короткие с роки отдельных подсистем меньшим числом разра ботчиков . Практика показывает , что даже при наличии полностью завершенного проекта , внедрен ие идет последовательно по отдельным подсисте мам ; · технология должна пр едусматривать воз можность управления конфигу рацией проекта , ведения версий проекта и е го составляющих , возможность автоматического выпу ска проектной документации и синхронизацию ее версий с версиями проекта ; · технология должна об еспечивать независимость выполняемых проек тн ых решений от средств реализации ИС (систе м управления базами данных (СУБД ), операционных систем , языков и систем программирования ); · технология должна бы ть поддержана комплексом согласованных CASE-средств , обеспечивающих автоматизацию процессов , выпол няемых на всех стадиях ЖЦ . Общий п одход к оценке и выбору CASE-средств описан в разделе 4, примеры комплексов CASE-средств - в подразделе 5.7. Реальное применени е любой технологии проектирования , разработки и сопровождения ИС в конкретной организации и ко нкретном проекте невозможно без выработки ряда стандартов (правил , соглашений ), которые должны соблюдаться всеми участникам и проекта . К таким стандартам относятся сл едующие : · стандарт проектирования ; · стандарт оформления проектной документации ; · стан дарт пользов ательского интерфейса . Стандарт проектиро вания должен устанавливать : · набор необходимых моделей (диаграмм ) на каждой стадии проектирования и степень их детализации ; · правила фиксации про ектных решений на диаграммах , в том числе : правила им енования объектов (включая соглашения по терминологии ), набор атрибутов д ля всех объектов и правила их заполнения на каждой стадии , правила оформления диаг рамм , включая требования к форме и размера м объектов , и т . д .; · требования к конфигу рации рабочих м ест разработчиков , включая настройки операционной системы , настройки CASE-с редств , общие настройки проекта и т . д .; · механизм обеспечения совместной работы над проектом , в том ч исле : правила интеграции подсистем проекта , пр авила поддержания проекта в оди наковом для всех разработчиков состоянии (регламент обмена проектной информацией , механизм фиксации общих объектов и т.д .), правила проверки проектных решений на непротиворечивость и т . д . Стандарт оформлени я проектной документации должен устанавливать : · комплектность , состав и структуру до кументации на каждой стадии проектирования ; · требования к ее оформлению (включая требования к содержанию р азделов , подразделов , пунктов , таблиц и т.д .), · правила подготовки , р ассмотрения , согласования и утверждения доку ментации с указанием предельных сроков для каждой стадии ; · требования к настрой ке издательской системы , используемой в качес тве встроенного средства подготовки документации ; · требования к настрой ке CASE-средств для обеспечения подготовки докум ента ции в соответствии с установленными требованиями . Стандарт интерфейс а пользователя должен устанавливать : · правила оформления экранов (шрифты и цветовая палитра ), состав и расположение окон и элементов управления ; · правила использования клавиатуры и мы ши ; · правила оформления т екстов помощи ; · перечень стандартных сообщений ; · правила обработки ре акции пользователя . Методология RAD Одним из возмо жных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО , содержащий 3 элемента : · небольшую команду программистов (от 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-средств , обеспечивающих целостность проекта ; · применение средств у правления конфигурацией , облегчающих внесение изм енений в проект и сопровождение готовой с истемы ; · необходимое использовани е генераторов кода ; · использование прототипир ования , позволяющее полнее выяснить и удовлет ворить потребности конечного пользователя ; · тестирование и разви тие проекта , осуществляемые одновременно с ра зработкой ; · ведение разработки н емногочисленной хорошо управляемой команд ой профессионалов ; · грамотное руководство разработкой системы , четкое планирование и контроль выполнения работ . Литература 1. Вендров А.М . Один из подходов к выбору средств проектирования баз данных и приложений . "СУБД ", 1995, № 3. 2. Зиндер Е.З . Бизнес - реинжиниринг и технологии системного проектирова ния . Учебное пособие . М ., Центр Информационных Технологий , 1996 3. Калянов Г.Н . CASE. Структурный системный анализ (автоматизация и применение ). М ., "Лори ", 1996. 4. Марка Д.А ., МакГоуэн К . Методология стр уктурного анализа и п роектирования . М ., "МетаТехнология ", 1993. 5. Международные стандарты , поддерживающие жизненный цикл программных средст в . М ., МП "Экономика ", 1996 6. Создание информационной системы предприятия . "Computer Direct", 1996, N2 7. Шлеер С ., Меллор С . Объектно-ориентированный анализ : моделирование мира в состояниях . Киев , "Диалектика ", 1993. 8. Barker R. CASE*Method. Entity-Relationship Modelling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990. 1. Barker R. CASE*Method. Function and Process Modelling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990. 2. Boehm B.W. A Spiral Model of Software Development and Enhancement. ACM SIGSOFT Software Engineering Notes, Aug. 1986 3. Chris Ga ne, Trish Sarson. Structured System Analysis. Prentice-Hall, 1979. 4. Edward Yourdon. Modern Structured Analysis. Prentice-Hall, 1989. 5. Tom DeMarco. Structured Analysis and System Specification. Yourdon Press, New York, 1978. 6. Westmount I-CASE User Manual. Westmount Technology B.V., Netherlands, 1994. 7. Uniface V6.1 Designers' Guide. Uniface B.V., Netherlands, 1994. 8. IEEE Std 1348-1995. IEEE Recommended Practice for the Adoption of CASE Tools. 9. IEEE Std 1209-1992. IEEE Recommended Practice fo r the Evaluation and Selection of CASE Tools. 10. PVCS Version Manager. User's Guide. 11. PVCS Tracker. User's Guide.
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

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

Обратите внимание, реферат по программированию "Основы методологии проектирования ИС", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

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


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