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

Реферат

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

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

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

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

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

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Экономическая теория

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

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

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

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


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