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

Реферат

Понятие программного продукта

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

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

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Microsoft Word, 199 kb, скачать бесплатно
Обойти Антиплагиат
Повысьте уникальность файла до 80-100% здесь.
Промокод referatbank - cкидка 20%!
Заказать
Узнать стоимость написания уникального реферата

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

10 Понятие программного продукта ВВЕДЕНИЕ. Существенной особенностью пос тиндустриальной эпохи стало появление рынка а вторских прав на программные продукты . Стоит сразу же отметить разницу понятий " прог раммный продукт " (ПП ) и "программа для ЭВМ ", которая полностью определена. Нужен ли программный продукту некий о тличительный знак , подтверждающий его качество ? Казалось бы , рыночная экономика дает отрицательный ответ на этот вопрос - высокий спрос подтвердит качество товара . Своеобразным знаком качества часто служит громкое имя поставщика , всем известный brand. И т е м не менее , серьезные компани и стремятся не только обеспечить качество , но и подтвердить его официально , получив сертификат , демонстрирующий , что все внутренние процессы компании направлены на создание качественного продукта . Иначе говоря , работает систем а управления и обеспечения качеством . Наличие такого сертификата - гарантия доверия его обладателю со стороны клиент ов и партнеров . В данной работе мы определи м понятие «программного продукта» , его сертиф икацию , а также вопросы авторских прав. 1. Поняти е программ ного продукта и его стандартизация. Система качества представляет собой орган изационный стержень для компании , которая вын уждена тщательно продумывать и документально оформлять , а затем контролировать каждый этап проектирования программного продукта и его результаты . Для этого нужен специальн о обученный персонал и особые методы упра вления качеством . Эти методы варьируются от компании к компании , но основные их пол ожения едины для всех и определяются стан дартом . В конечном итоге система к ачества позволяет создать оптимальные усл овия для продуктивного труда специалистов , по скольку берет на себя все формальные и рутинные , но абсолютно необходимые операции . Она позволяет перейти от кустарного уровня сотворения замечательных программ "на коле н ке " к научно организованному масс овому производству программного продукта . ISO 9000-3 - система качества для ПО Стандарт ISO 9000-3 включает в себя все положения общего стандарта ISO 9001, а также необходимые дополнения к ним , относящиеся к разработк е , пос тавке и обслуживанию ПО . ISO 9001 устанавливает треб ования к системе качества поставщика и по зволяет оценивать его возможности по проектир ованию и поставке продукции , соответствующей этим требованиям . Требования стандарта направлены в первую очередь на то , чтобы удовлетворить запросы пользователя , предупредив появление каких- либо несоответствий продукции на всех стадиях ее жизненного цикла – от проектирования до обслуживания . Стандарт определяет ряд важных понятий , которые затем используются в п о ложениях стандарта , в том ч исле : продукт - результат действий или процессов ; программный продукт - набор компьютерных пр ограмм , процедур и , возможно , связанных с н ими документов и данных ; элемент программного обеспечения (software item) – любая и дентифицируемая часть программного продукта ; основание (baseline) - формально утвержденная версия элемента конфигурации , зафиксированная в определенный момент времени в процессе жизненного цик ла элемента конфигурации ; разработка (development) - про цесс жизненного цикла программного проду кта , охватывающий анализ требований , проектирован ие , кодирование, интеграцию , тестирование , установку и подд ержку ; модель жизненного цикла (life cycle model) - базовая м одель , включающая процессы , действия и зада чи , вовлеченные в разработку , функциониров ание и сопровождение программного продукта и хватывающие весь жизненный цикл системы от определения требований до завершения использования ; этап (phase) - определенный сегмент работы ; регрессионное тестиров ание (regression testing) - те стирование , позволяющее убедиться в том , что изменения , внесенные с целью исправления об наруженных ошибок , не породили новых ; репликац ия (replication) - копирование программного продукта с одного носителя на другой . В а жно отметить , что в большинстве пунктов станд арта поставщик обязывается не только определя ть соответствующие действия , но и оформлять их документально , регистрировать результаты и периодически анализировать , для того чтобы внести необходимые усовершенство в ания или полностью заменить . Управление проектированием Это самый обширный раздел стандарта , п оскольку он затрагивает базовую составляющую общего процесса создания продукта , программного продукта в частности , решающим образом в лияющую на его кач ество . Поставщик уст анавливает и документирует методики управления и верификации проекта с целью обеспечения выполнения установленных требований . Этот ра здел стандарта ISO 9000-3 дает руководящие указания п о основным действиям в процессе разработки , таким как анализ требований к п роекту , проектирование архитектуры системы , деталь ное проектирование и кодирование , а также планирование разработки . Проект разработки программного продукта организуется в соответствии с определенной моделью жизненного цик ла . ISO 9000-3 не определ яет , какой должна быть модель жизненного ц икла , это зависит от специфики решаемой за дачи . Стандарт дает лишь общее определение модели жизненного цикла как множества проц ессов . Модель показывает , когда и как эти процессы подключают с я к реализац ии проекта . Разработка системы - это процесс преобразо вания исходных требований в конечный програм мный продукт . Стандарт оговаривает , что этот процесс должен проводиться в строго опре деленном порядке . Это позволит предотвратить появлен ие ошибок и снизит зависимость от процессов проверки и утверждения как единственных методов определения проблемных си туаций . Требование строгой дисциплины процесса разработки подразумевает наличие и поддержку в рабочем состоянии документированных процедур, которые послужат гарантией того , что программный продукт создается в соответствии с заданными тр ебованиями и планами разработки и обеспечения качества. Управление проектом должно учитывать таки е аспекты , как используемый метод проектирова ния и ег о соответствие конкретной зад аче , опыт предыдущих проектов , требования посл едующих процессов : тестирования , установки , сопрово ждения и использования , наконец , соображения з ащиты и безопасности . В тех случаях , когда сбои системы могут нанести ущерб людям , с обственности или окружающей среде , при проектировании должно быть сформулированы специальные требования , гарантирующие устойчивос ть системы или ее ответные действия на потенциальные аварийные ситуации . Для процессов кодирования должны задаваться правила и с пользования языков программирования , принципы кодирования и правила составления а декватных комментариев . Инструментальные средства и методы , испол ьзуемые в разработке программного продукта , такие , например , как системы анализа и про ектирования и ком пиляторы , должны заранее утверждаться и контролироваться системой кон фигурационного управления . Область применения инс трументария должна быть задокументирована , а его использование периодически анализироваться , д абы выявить необходимость усовершенствовани я инструментальных систем или замены на новые продукты . Проектирование и разработка должны тщател ьно планироваться . План разработки программного продукта формулирует строго документированные действия по анализу требований к системе , проектированию, кодированию , интеграции , тес тированию , установке и поддержке системы . План разработки должен быть проанализирован и утвержден. План разработки включает также связанные с основным процессом планы обеспечения к ачества , управления рисками и конфигурацией , п л аны интеграции , тестирования , установки , о бучения сотрудников и др . Должны быть определены и задокументирован ы принципы организационно-технического взаимодействия между различными группами , участвующими в разработке . Здесь четко определяются границы ответ ственности каждого участника разработ ки и то , каким образом техническая информация будет передаваться между участниками . Здесь же оговаривается о тветственность заказчика проекта , если он при нимает участие в разработке : необходимость уч аствовать в проекте , обязательства по св оевременному предоставлению нужной информации . В случае обоюдной договоренности между поставщ иком и заказчиком может быть запланирован совместный анализ ведения проект а , регуляр но или на определенных его этапах . Этот анализ затрагивает таки е факторы , как ход разработки состороны по ставщика , участие в разработке со стороны заказчика , соответствие системы требованиям заказ чика , результаты проверок , результаты тестирования. Входные проектные требования к продукции . Требования формулирует за казч ик , а поставщик анализирует , насколько они адекватны . Неполные , двусмысленные или противоречи вые требования являются предметом урегулирования с лицами , ответственными за их предъявлен ие . В определенных ситуациях , по обоюдному согласию , спецификацию тр е бований мож ет проводить поставщик . Выходные проектные данные та кже оформляются документально , причем таким о бразом , чтобы их можно было проверить и подтвердить относительно входных проектных тре бований . Выходные данные проекта программной системы могут в ключать : спецификацию архи тектуры проекта , детальную спецификацию проекта , исходные коды , руководство пользователя . Постав щик программного продукта должен планировать и проводить официальный , документально оформлен ный анализ результатов проектиров а ния . Степень формальности и строгости процессо в анализа соответствуют сложности разрабатываемо й системы и степени риска , связанного с ее использованием . Анализ проектирования затраг ивает такие аспекты , как выполнимость проекта , удовлетворение требованиям защиты и бе зопасности системы , выполнение правил программиро вания и возможность тестирования . На определе нных стадиях проектирования проводится проверка соответствия выходных данных входным требова ниям . Такая верификация проекта может включать анализ выход ных данных , д емонстрации , в том числе с помощью прототи пов и моделирования , или тестирование . Только проверенные выходные проектные данные утверж даются для окончательного приема и последующе го использования . Все обнаруженные в процессе проверки проблемные ситуации должны адекватно разрешаться. Прежде чем система будет передана зак азчику , поставщик должен утвердить систему на соответствие заданному назначению . Заказчику может быть передан только утвержденный прогр аммный продукт . Все изменения и модиф икации проек та должны быть идентифицированы , документально оформлены , проанализированы и утверждены до их реализации . Поставщик устанавливает и по ддерживает в рабочем состоянии процедуры упра вления изменениями в проекте , которые могут возникнуть на любой с тадии жизнен ного цикла системы . Управление документацией и данными Обслуживание Поддержка заказчиков обсуждается в станда рте ISO 9000-2. Сопровождение системы , как правило , вкл ючает в себя обнаружение и анализ несоотв етствий в программной системе , вызываю щих сбои в ее работе ; коррекцию программных ошибок ; модификацию интерфейсов , что необходи мо в случае внесения добавлений или измен ений в аппаратуру ; функциональное расширение или улучшение производительности Все действия по сопровождению должны проводитьс я и контролироваться в соответствии с планом сопровождения , который заранее определяе тся и согласовывается поставщиком и заказчико м . В заключение нам остается лишь добавить , что технология разработки программного обес печения - это целая наука , которой в Ро с сии , увы , почти не учат . Отсюд а явный дефицит хороших менеджеров и спец иалистов по комплексным проектам . Общие полож ения стандарта по обеспечению качества - лишь верхушка айсберга . За пределами нашей ста тьи остались детали тех процессов , которые реально о б еспечивают качество коне чного продукта . Но это , как правило , "ноу хау " компании. 2. АВТОРСКОЕ ПРАВО НА ПРОГРАММНЫЙ ПРОДУКТ КАК ОБЪЕКТ СТОИМОСТНОЙ ОЦЕНКИ Существенной особенностью постиндустриальной эпохи стало появление рынка авторских прав на программны е продукты . Стоит сразу же отметить разницу понятий " программный продукт " (ПП ) и "программа для ЭВМ ", которая полностью определена. В рыночной экономике авторские права на ПП выступают в виде принципиально ново го информационного ресурса и проду кта , вовлечение которого в хозяйственный оборот происходит в процессе коммерциализации (купли-п родажи , переуступки прав собственности ) и капи тализации (постановки на баланс , инвестирования в уставный капитал ). Наиболее сложной , но интересной в теор етическо м и практическом плане является такая обязательная процедура введения в хозяйственный оборот как стоимостная оценка и мущественных прав на ПП . Еще далеко не разрешены все проблемы , связанные со стоимо стной оценкой объектов промышленной собственност и , а оце н ка стоимости авторских прав на ПП тем более затруднена , т.к . ПП является сложным синтетическим и часто составным объектом интеллектуальной собственнос ти (ОИС ) . Необходимость оценить в денежном выражени и программный продукт (ПП ) возникает на ра зличных стад иях его жизненного цикла . Фирма , создавшая ПП , может быть заинтересована в его стоимостной оценке в качестве новой продукции , подлежащей реализации , а такж е в качестве своего имущества при включен ии ПП в баланс предприятия путем постанов ки на учет в соста в е нематери альных активов (НМА ). Стоимостная оценка ПП с целью включен ия в НМА (капитализации ) называется балансовой стоимостью и носит явно выраженный затра тный характер. После включения в НМА ПП вводятся в состав основного капитала фирмы , погашают свою ст оимость путем амортизации , но и как всякое другое имущество , ПП под вергаются налогообложению. Необходимость в стоимостной оценке ПП и их капитализации явно выражена в сле дующих ситуациях , требующих различного подхода : - приватизация или превращение фирмы в акционерное общество ; - оценка имущества фирмы в случае ее разделения ; - организация на основе фирмы обособленн ого нового производства ; - оценка имущества фирмы в случае ее продажи ; - оценка имущества фирмы при страховании ; - оценка имущества фирмы при ба н кротстве. Типичным случаем корпоративных трансакций также является внесение вкладов в уставной фонд вновь создающихся фирм , тогда имущес твенные права на ПП являются инвестициями в развитие другого производства. Выход на рынок ПП также может рас сматриватьс я как выход продукции (продажа копий ), а также как выход на рынок имущественных прав на ПП , который предусмат ривает различные случаи стоимостной оценки : - оценка исключительных имущественных прав на ПП ; - оценка неисключительных имущественных прав на ПП ; - оценка имущественных прав на "ноу-хау ", заключенных в прикладной компьютерной програм ме. Уступка вышеуказанных имущественных прав на ПП оформляется в виде авторских или иных договоров , а также беспатентной лиценз ии , в которых в подавляющем большинстве сл у чаев указывается стоимость прав в де нежном выражении. В процессе создания программы для ЭВМ алгоритм может быть защищён как "ноу-хау " в качестве информации научного или техни ческого характера , составляющей коммерческую тайн у фирмы-разработчика. Имущественн ые же права на объекты интеллектуальной собственности , к которым от носятся ПП , предполагают действие триады прав омочий (владение , распоряжение , пользование ). Такими правомочиями могут обладать авторы ПП ил и коллектив авторов , фирма-разработчик , а также фи з ические или юридические лица , купившие эти имущественные права на ПП . Только при наличии имущественных прав во зможна их уступка , обмен правами , копирование и продажа копий , а также возбуждение судебных исков при незаконном пользовании ПП. Стоимостная оценк а прав на интелл ектуальную собственность имеет много общего с о стоимостной оценкой материального имущества , предприятий , бизнеса. Федеральный закон об акционерных общества х (ст . 77) дает следующее определение рыночной стоимости : "Рыночная стоимость имущест ва , включ ая стоимость акций или других ценных бума г , является ценой , по которой продавец , име ющий полную информацию о стоимости имущества и не обязанный его продавать , согласен был бы продать , а покупатель , имеющий по лную информацию о стоимости имущества и не обязанный его приобрести , согласен был бы приобрести ". Акты "покупки-продажи " имущественных прав н а ПП как исключительных , так и неисключите льных , выступают на рынке в виде лицензион ных , авторских или иных предусмотренных закон одательством договоров . Э тот рынок так же , как и рынок копий программ является преимущественно рынком монопольной конкуренции . Его существенное отличие от рынка копий ПП заключается в сравнительно небольшом количестве покупателей и продавцов , а значит и в небольшом количестве акт о в "покупки-продажи ". Исходя из теоретических положений макроэкономики это означает , что при рыночном ценообразовании не срабатывает закон больших чисел и устанавливается не чистая рыночная цена имущественных прав , а , скорее , рыночная договорная . А это , со б ственно , и есть цена , по котор ой продавец согласен продать , а покупатель - купить товар на рынке. Затратный метод определения балансовой и рыночной цены ПП предполагает установление цены на уровне средних затрат на раз работку ОИС плюс нормальная прибыль , а также дополнительная (экономическая ) прибыль за высокий научно-технический уровень разработки или уменьшение сроков ее выполнения . Таким образом устанавливается цена по научно-техни ческим подрядам - договорам па создание научно- технической продукции , в ч а стности на разработку ПП. В условиях рынка , когда договора заклю чаются на конкурсной основе , такой принцип ценообразования называется "Const plus Fee", т.е . затраты плю с вознаграждение . На переговорах по заключени ю договора стороны согласуют смету затрат н а разработку (подряд , заказ ), а такж е вознаграждение в процентах или доле от суммы договорной сметы (не ниже ставки банковского процента ). На этот принцип накла дывается его модификация "Target price" (целевая цена ) и "Taget time" (целевой срок ), предполаг а ющая дополнительное вознаграждение за превышение пока зателей технического задания или желательное для заказчика сокращение срока заказа. Обычная смета затрат на разработку на учно-технической продукции включает в себя сл едующие статьи затрат : - заработная п лата разработчиков ; - отчисления на соцстрах ; - эксплуатационные расходы , включающие расхо ды на персональный компьютер (ПК ) и аморти зацию лицензионного программного обеспечения (ПО ); - накладные расходы ; - прибыль ; - налог на прибыль ; - НДС. Сумма вышеуказ анных статей затрат представляет собой стоимость разработки с налогами , но без дополнительного вознаграждения за качество и сроки . Таким образом , дого ворная цена на разработку ОИС носит "затра тный характер " в отличие от "антизатратных цен " на рынке лиценз и й (договоров на передачу имущественных нрав на ОИС ). К основным проблемам выявления затрат отно сятся трудности с определением трудоемкости р азработок , так как при ценообразовании должны учитываться только усредненные , обоснованные затраты . Такими , наприме р , могут быть среднеотраслевые нормы трудовых затрат при разработке объектов промышленной собственности . Особенно острой является эта проблема пр и разработке ПП . В принятых в 1988 году ук рупненных нормах времени на разработку ПП к числу основных факторов , в лияющ их на трудоемкость разработки , отнесены : - объем ПП в тысячах условных машинн ых команд ; - сложность ПП ; - степень новизны ; - степень использования при разработке с тандартных модулей , типовых программ и ПС. Однако с переходом на ПК вышеуказанны е укрупн енные нормы времени устарели , и трудоемкость определяется на основе методов аналогий и экспертных оценок , а чаще всего "уторговывается " при заключении договоров. Основными факторами , определяющими стоимость объектов интеллектуальной собственности , являютс я : - затраты владельца исключительных прав на создание , разработку объекта правовой охра ны (по смете затрат по договору-подряду на НИОКР ); - затраты владельца исключительных прав на патентование (регистрацию ) объектов интеллектуа льной собственности , включая пошлины и д ругие расходы на поддержание охранных докумен тов в силе ; - затраты на организацию использования О ИС , включая и затраты на его маркетинг ; - затраты на страхование ОИС ; - срок действия охранного документа (пате нта , свидетельства ) на момент оценки его стоимости ; - издержки владельца исключительных прав на разрешение патентно-правовых конфликтов , в том числе в судебном порядке , по оценив аемому ОИС ; - ожидаемые поступления лицензионных платеже й по данному объекту интеллектуальной собстве нности при ус ловии фиксации объемов п латежей лицензионными договорами , зарегистрированными в установленном действующим законодательством порядке ; - ожидаемые денежные поступления от прод ажи копий ПП ; - ожидаемая экономия текущих затрат при использовании ОИС в производс тве. Проблемы возникают в том случае , когда одна организация является разработчиком алго ритмов , а другая - исходного текста ПП . Если эти организации независимы друг от друга , то в балансе каждой из них отражаютс я только затраты , произведенные в каждой к онк ретной организации. При расчёте рыночной цены прав на ПП затратным методом должны учитываться вс е совокупные затраты на синтетический ОИС , в том числе и затраты дилера , создающег о для конечного пользователя исполняемый моду ль , а также вознаграждение , распр еделение которого между авторами ПП должно найти отражение в договоре о передаче прав на ПП. При определении рыночной , а также инве стиционной стоимости авторского права на ПП может быть применён метод сравнения с рыночными продажами аналогов. Вышеуказанный метод основан на изве стном в теории оценивания принципе замещения . Он равно применим при расчете рыночной стоимости по практике продаж аналогичных объектов и по практике продаж аналогичных имущественных прав . Например , метод сравнения рыночных продаж мож е т быть п рименим как при установлении цены на копи ю ПП , так и при установлении цены пере уступки имущественных прав на ПП. Сущность метода заключается в сравнении по цене и потребительных свойствах сопос тавимых объектов оценки (аналогов ), и на эт ой основе ус тановления стоимостной оценки нового ОИС. При применении метода сравнения рыночных продаж выявляется цена покупателя , которого не интересуют затраты разработчика и нас тоящего владельца ОИС , а только потребительны е свойства (качество , конкурентоспособность ) покупаемого ими товара . Как правило , эта цена выше рассчитанной затратным методом и может быть принята как верхняя граница оценки. Трудность установления цены по вышеуказан ному методу прежде всего заключается в вы явлении конкретного набора потребительных с войств (технико-экономических характеристик , параметро в , функций ) оцениваемого объекта и их влия ния на цену ОИС. При расчете цены сервисной программы для ЭВМ может приниматься следующий набор потребительских характеристик (функций ): - набор возможностей ; - удобство использования ; - общая оценка скорости ; - качество документации. Каждому конкретному случаю оценки отвечае т определенный набор характеристик , параметров , функций (в дальнейшем тексте функций ). Алгоритм стоимостной оценки по методу аналогичных пр одаж состоит из следующе й последовательности процедур : 1. Выявление основных функций ОИС ; 2. Оценка в баллах качества выполнения отдельных функций для аналогов и оцениваем ого ОИС ; 3. Выявление экспертного мнения о коэффиц иентах веса (важности , полезности ) функций ; 4. Определение интегрального показателя каче ства выполнения функций для оцениваемого ОИС и его аналогов ; 5. Определение "стоимости " балла качества ; 6. Определение диапазона рыночной стоимостно й оценки ОИС ; 7. Формирование экспертного мнения о наиб олее обоснованной рыночной стоимости оцен иваемого ОИС. Формализовано можно представить , что оцен иваемый объект сравнивается с аналогами на множестве Ni , где i - число аналогов ( i = 1, n). Оцениваемый объект и аналоги характеризую тся множеством показател ей Nija , ( j = 1, n), где Nija явл яется балльной оценкой качества выполнения j-о й функции i-го аналога. В случае невозможности определения натура льных значений параметров - функций необходимо провести экспертную оценку . Работа экспертов строится но следу ющему алгоритму : - формулирование задачи ; - выявление мнения каждого эксперта ; - выявление крайних суждений ; - исследование причин расхождения во мне ниях ; - доведение до всех экспертов , участвующи х в оценке , указанных выше результатов обр аботки мнений ; - а нализ каждым экспертом указанных выше результатов и переоценка своего пер воначального мнения или сохранение его в силе ; - выявление преобладающего , наиболее обоснов анного мнения. ЗАКЛЮЧЕНИЕ. Таким образом можно сделать вывод : Существенной особенностью п остиндустриал ьной эпохи стало появление рынка авторских прав на программные продукты . Стоит сразу же отметить разницу понятий " программный продукт " (ПП ) и "программа для ЭВМ ", которая полностью определена. В рыночной экономике авторские права н а ПП выступают в виде принципиально нового информационного ресурса и продукта , вовлечение которого в хозяйственный оборот происходит в процессе коммерциализации (купли-п родажи , переуступки прав собственности ) и капи тализации (постановки на баланс , инвести р ования в уставный капитал ). Наиболее сложной , но интересной в теор етическом и практическом плане является такая обязательная процедура введения в хозяйствен ный оборот как стоимостная оценка имущественн ых прав на ПП . Еще далеко не разрешены все проблемы , св язанные со стоимостно й оценкой объектов промышленной собственности , а оценка стоимости авторских прав на П П тем более затруднена , т.к . ПП является сложным синтетическим и часто составным об ъектом интеллектуальной собственности (ОИС ) . ЛИТЕРАТУРА : 1. Ефимо в А.Н . Программа для ЭВМ как объект гражданского оборота . Московский оценщик ° 1,1999 2. Федотова М.А . Сколько стоит бизнес ? методы оценки , М . Перспектива 1996 3. Валдайцев С.В . Оценка бизнеса и инн оваций , М - 1997.
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Экономическая теория

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

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

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

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


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