Чем отличается программа от программного продукта той же функциональности

Существенной особенностью постиндустриальной эпохи стало появление рынка авторских прав на программные продукты. Стоит сразу же отметить разницу понятий » программный продукт » (ПП) и «программа для ЭВМ», которая полностью определена.

Нужен ли программный продукту некий отличительный знак, подтверждающий его качество? Казалось бы, рыночная экономика дает отрицательный ответ на этот вопрос — высокий спрос подтвердит качество товара. Своеобразным знаком качества часто служит громкое имя поставщика, всем известный brand.

И тем не менее, серьезные компании стремятся не только обеспечить качество, но и подтвердить его официально, получив сертификат, демонстрирующий, что все внутренние процессы компании направлены на создание качественного продукта. Иначе говоря, работает система управления и обеспечения качеством. Наличие такого сертификата — гарантия доверия его обладателю со стороны клиентов и партнеров.

В данной работе мы определим понятие «программного продукта», его сертификацию, а также вопросы авторских прав.

Интерфейс программного продукта (дата 2021-09-22)

1. Понятие программного продукта и его стандартизация.

Система качества представляет собой организационный стержень для компании, которая вынуждена тщательно продумывать и документально оформлять, а затем контролировать каждый этап проектирования программного продукта и его результаты. Для этого нужен специально обученный персонал и особые методы управления качеством. Эти методы варьируются от компании к компании, но основные их положения едины для всех и определяются стандартом. В конечном итоге система качества позволяет создать оптимальные условия для продуктивного труда специалистов, поскольку берет на себя все формальные и рутинные, но абсолютно необходимые операции. Она позволяет перейти от кустарного уровня сотворения замечательных программ «на коленке» к научно организованному массовому производству программного продукта .

ISO 9000-3 — система качества для ПО Стандарт ISO 9000-3 включает в себя все положения общего стандарта ISO 9001, а также необходимые дополнения к ним, относящиеся к разработке, поставке и обслуживанию ПО. ISO 9001 устанавливает требования к системе качества поставщика и позволяет оценивать его возможности по проектированию и поставке продукции, соответствующей этим требованиям.

Требования стандарта направлены в первую очередь на то, чтобы удовлетворить запросы пользователя, предупредив появление каких-либо несоответствий продукции на всех стадиях ее жизненного цикла – от проектирования до обслуживания. Стандарт определяет ряд важных понятий , которые затем используются в положениях стандарта, в том числе:

продукт — результат действий или процессов; программный продукт — набор компьютерных программ, процедур и, возможно, связанных с ними документов и данных;

элемент программного обеспечения (software item) – любая идентифицируемая часть программного продукта ; основание (baseline) — формально утвержденная версия элемента

Что делает тестировщик, мой рабочий день | тестирование ПО | Тестировщик | QA Engineer

конфигурации, зафиксированная в определенный момент времени в процессе жизненного цикла элемента конфигурации; разработка (development) — процесс жизненного цикла программного продукта , охватывающий анализ требований, проектирование, кодирование,

интеграцию, тестирование, установку и поддержку; модель жизненного цикла (life cycle model) — базовая модель, включающая процессы, действия и задачи, вовлеченные в разработку, функционирование и сопровождение программного продукта и хватывающие весь жизненный цикл системы от определения требований до завершения

использования; этап (phase) — определенный сегмент работы; регрессионное тестирование (regression testing) — тестирование, позволяющее убедиться в том, что изменения, внесенные с целью исправления обнаруженных ошибок, не породили новых; репликация (replication) — копирование программного продукта с одного носителя на другой. Важно отметить, что в большинстве пунктов стандарта поставщик обязывается не только определять соответствующие действия, но и оформлять их документально, регистрировать результаты и периодически анализировать, для того чтобы внести необходимые усовершенствования или полностью заменить.

Это самый обширный раздел стандарта, поскольку он затрагивает базовую составляющую общего процесса создания продукта , программного продукта в частности, решающим образом влияющую на его качество. Поставщик устанавливает и документирует методики управления и верификации проекта с целью обеспечения выполнения установленных требований. Этот раздел стандарта ISO 9000-3 дает руководящие указания по основным действиям в процессе разработки, таким как анализ требований к проекту, проектирование архитектуры системы, детальное проектирование и кодирование, а также планирование разработки.

Проект разработки программного продукта организуется в соответствии с определенной моделью жизненного цикла. ISO 9000-3 не определяет, какой должна быть модель жизненного цикла, это зависит от специфики решаемой задачи. Стандарт дает лишь общее определение модели жизненного цикла как множества процессов. Модель показывает, когда и как эти процессы подключаются к реализации проекта.

Разработка системы — это процесс преобразования исходных требований в конечный программный продукт . Стандарт оговаривает, что этот процесс должен проводиться в строго определенном порядке. Это позволит предотвратить появление ошибок и снизит зависимость от процессов проверки и утверждения как единственных методов определения проблемных ситуаций. Требование строгой дисциплины процесса разработки подразумевает наличие и поддержку в рабочем состоянии документированных процедур, которые послужат

гарантией того, что программный продукт создается в соответствии с заданными требованиями и планами разработки и обеспечения качества.

Управление проектом должно учитывать такие аспекты, как используемый метод проектирования и его соответствие конкретной задаче, опыт предыдущих проектов, требования последующих процессов: тестирования, установки, сопровождения и использования, наконец, соображения защиты и безопасности. В тех случаях, когда сбои системы могут нанести ущерб людям, собственности или окружающей среде, при проектировании должно быть сформулированы специальные требования, гарантирующие устойчивость системы или ее ответные действия на потенциальные аварийные ситуации. Для процессов кодирования должны задаваться правила использования языков программирования, принципы кодирования и правила составления адекватных комментариев.

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

Читайте также:
Как закрыть полностью программу с компьютера

Проектирование и разработка должны тщательно планироваться. План разработки программного продукта формулирует строго документированные действия по анализу требований к системе, проектированию, кодированию, интеграции, тестированию, установке и поддержке системы. План разработки должен быть проанализирован и утвержден.

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

Должны быть определены и задокументированы принципы организационно-технического взаимодействия между различными группами, участвующими в разработке. Здесь четко определяются границы ответственности каждого участника разработки и то, каким образом

техническая информация будет передаваться между участниками. Здесь же оговаривается ответственность заказчика проекта, если он принимает участие в разработке: необходимость участвовать в проекте, обязательства по своевременному предоставлению нужной информации. В случае обоюдной договоренности между поставщиком и заказчиком может быть запланирован совместный анализ ведения проект а, регулярно или на определенных его

этапах. Этот анализ затрагивает такие факторы, как ход разработки состороны поставщика, участие в разработке со стороны заказчика, соответствие системы требованиям заказчика, результаты проверок, результаты тестирования.

Входные проектные требования к продукции. Требования формулирует заказчик, а поставщик анализирует, насколько они адекватны. Неполные, двусмысленные или противоречивые требования являются предметом урегулирования с лицами, ответственными за их предъявление. В определенных ситуациях, по обоюдному согласию, спецификацию требований может проводить поставщик.

Выходные проектные данные также оформляются документально, причем таким образом, чтобы их можно было проверить и подтвердить относительно входных проектных требований. Выходные данные проекта программной системы могут включать: спецификацию архитектуры проекта, детальную спецификацию проекта, исходные коды, руководство пользователя. Поставщик программного продукта должен планировать и проводить официальный, документально оформленный анализ результатов проектирования.

Степень формальности и строгости процессов анализа соответствуют сложности разрабатываемой системы и степени риска, связанного с ее использованием. Анализ проектирования затрагивает такие аспекты, как выполнимость проекта, удовлетворение требованиям защиты и безопасности системы, выполнение правил программирования и возможность тестирования. На определенных стадиях проектирования проводится проверка соответствия выходных данных входным требованиям. Такая верификация проекта может

включать анализ выходных данных, демонстрации, в том числе с помощью прототипов и моделирования, или тестирование. Только проверенные выходные проектные данные утверждаются для окончательного приема и последующего использования. Все обнаруженные в процессе проверки проблемные ситуации должны адекватно разрешаться.

Источник: smekni.com

Вопросы по курсу «Проектирование информационных систем» + ответы неизвестной версии

vedro-compota's picture

в данной версии вопросов-ответов судя по всему перемешаны вопросы типа «выберете правильный вариант ответа» и вопросы , где требуется самому что-то написать/сказать — так как мне досталась именно такая версия текста — где после каждого вопроса что-нибудь — да написано (причём, не обязательно только правильные ответы) — то вопросы , «ответы» к которым (приведённые после вопроса) сомнительны или же не присутствует не самое лучшее оформление — рассматриваются отдельно по ссылке «[ответ]»

ВОПРОСЫ ПО КУРСУ «ПРОЕКТИРОВАНИЕ ИС»:

1. Общие характеристики процесса проектирования: [ответ]

  • 1. Этапность, плановость, коллективность, управляемость, документирование, связь с заказчиком; (правильный ответ)
  • 2. Творческий подход, инициативность;
  • 3. Демократичность принятия решений;
  • 4. Спонтанное развитие.

2. Определяющий фактор структуры информации и логики ИС:

  • 1. Общефилософский подход;
  • 2. Входные и выходные формы; (правильный ответ)
  • 3. Скорость разработки проекта;
  • 4. Опыт разработчиков.

3. Исходные данные для проектирования: [ответ]

  • 1. Заработная плата разработчиков проекта;
  • 2. Квалификация разработчиков проекта;
  • 3. Входные и выходные формы, эффективность работы, надёжность, защита данных, техническая оснащённость и т.п.; (правильный ответ)
  • 4. Аналогичный продукт/проект другой фирмы.

4. Чем отличается программа от программного продукта той же функциональности?

  • 1. Отлаженностью, качественным интерфейсом;
  • 2. Скоростью работы;
  • 3. Стоимостью;
  • 4. Качеством, оттестированностью, документацией, процедурой приёмки, сопровождением (правильный ответ)

5. Чем определяется качество программного продукта?

  • 1. Ориентация на стандарты, хорошо организованное сопровождение, проектная документация, и пр.; (правильный ответ)
  • 2. Гениальная идея;
  • 3. Самоотверженный труд;
  • 4. Скорость подготовки проекта.

6. Что занимает большую часть работы над проектом?

  • 1. Написание программ;
  • 2. Анализ и планирование; (правильный ответ)
  • 3. Тестирование;
  • 4. Системное тестирование.

7. Функции проектной документации –

  • 1. Повышение авторитета фирмы;
  • 2. Формальное соответствие стандартам;
  • 3. Повышение общности и абстрактности программного продукта;
  • 4. Связь с отделом тестирования, планирование, основания для принятия решений, основа развития продукта. (правильный ответ)

8. Сопровождение программного продукта это

  • 1. Сервисное обслуживание пользователей, купивших программу (консультации по использованию, обучение, рассылки нововведений и релизов, пропаганда знаний использования и т.п.); (правильный ответ)
  • 2. Исправление ошибок;
  • 3. Доработка функциональности;
  • 4. Гарантийное обязательство.

9. Внедрение системы – это = [ответ]

  • 1. Инсталляция на ЭВМ пользователя;
  • 2. Квалифицированная помощь пользователю в запуске и освоении системы, устранение неучтённых особенностей («мелочей»), повышение уровня доверия к системе; (правильный ответ)
  • 3. Определение особенностей автоматизации объекта;
  • 4. Бюрократическая рутинная процедура завершения проекта.

10. Какие компоненты информационного комплекса подлежат защите? (далее , видимо , список правильных ответов)

  • 1) оборудование
  • 2) средства хранения данных
  • 3) каналы связи

11. Какие существуют категории защиты информации? (далее , видимо , список правильных ответов)

  • 1) физическая защита от разрушения
  • 2) логическая защита (ссылочная целостность и пр.)
  • 3) защита от перехвата
  • 4) защита от несанкционированного доступа
  • 5) защита от неправильных действий оператора (от «дурака»)

12. Методы обеспечения физической защиты

  • 1) защита от сбоев питания
  • 2) защита от выхода из строя оборудования (дублирование и резервирование)
  • 3) архивация и резервное копирование данных
  • 4) применение RAID-массивов
  • 5) журнализация
  • 6) административные и дисциплинарные меры (график работы, ограничение доступа к оборудованию, штрафы и т.п.)
Читайте также:
Программа для того чтобы сделать видео из презентации

13. Методы защиты от перехвата и несанкционированного доступа

  1. криптозащита (шифрование)
  2. электронно-цифровая подпись
  3. использование защищенных протоколов передачи данных (SSL)
  4. формирование защищенных каналов передачи (туннелирование)
  5. персональная идентификация пользователей, желательно единая в рамках всей системы
  6. использование дополнительных средств идентификации (штрих-код, магнитные и proximity-карты)
  7. категоризация пользователей
  8. протоколирование действий пользователей
  9. ограничение и протоколирование условий доступа (HID, MAC, IP, время получения доступа)
  10. хранение истории изменений свойств объектов
  11. настройка интерфейса в зависимости от прав пользователя или группы

14. Что служит основой для формирования требований к ТЗ (техническому заданию)? [ответ]

  • 1) входные и выходные формы
  • 2) вид деятельности оператора
  • 3) способ и интенсивность работы со средствами ввода
  • 4) способ получения и восприятия информации
  • 5) ограничения безопасности
  • 6) защита от «дурака»
  • 7) понятие эффективности
  • 8) понятие оптимальности
  • 9) сведения о квалификации операторов

15. Какие существуют концептуальные подходы к проектированию? [ответ]

  • 1) Нисходящее проектирование
  • 2) Восходящее проектирование
  • 3) Низ-восходящее проектирование
  • 4) Экстремальное проектирование (программирование)

16. Преимущества нисходящего проектирования

  • 1) очень удобное документирование
  • 2) высокая надёжность
  • 3) управляемость процессом проектирования
  • 4) лёгкость создания тестов

17. Недостатки нисходящего проектирования

  • 1) многие из реальных проблем не иерархические
  • 2) слишком строгая формализация может замедлить процесс разработки
  • 3) обилие тестов

18. Когда следует использовать нисходящее проектирование?

  • 1. Всегда
  • 2. Когда задачи имеют ясно выраженный иерархический характер (правильный ответ)
  • 3. Когда требует заказчик
  • 4. Когда задача плохо формализована

19. В чем заключается суть метода восходящего проектирования? [ответ]

Суть метода – построение системы путем обобщения из готовых понятий

20. Когда может быть использовано восходящее проектирование?

Восходящее проектирование может быть использовано, когда слабо определена конечная цель или по природе задачи результат должен получиться как итог реализации некоторых заранее известных и определенных задач

21. Принципы экстремального программирования [ответ]

  • 1) планирование
  • 2) деление на простые составляющие
  • 3) постоянное совершенствование кода
  • 4) тестирование
  • 5) постоянное взаимодействие с заказчиком
  • 6) программирование в парах
  • 7) единый стандарт кодирования

22. Какова последовательность разработки?

  • 1) ТЗ->проект->программа
  • 2) программа-> ТЗ->проект->
  • 3) Quick-проект->ТЗ (техническое задание)->проект->кодирование->документация пользователя (правильный ответ)
  • 4) документация-> Quick-проект->ТЗ->проект->кодирование->документация пользователя

23. Перечислить исходные данные для проектирования. [ответ]

  • 1) входные и выходные данные;
  • 2) эксплуатационные требования; (сюда же вхоят требования к надёжности)
  • 3) стоимостные характеристики;
  • 4) технические средства;
  • 5) переносимость;
  • 6) распределённость;
  • 7) потоки данных;
  • 8) открытость;
  • 9) архитектура;
  • 10) перспективы.

24. Перечислить эксплуатационные требования

  • 1) эффективность;
  • 2) надежность;
  • 3) скорость;
  • 4) защита данных.

25. Что включает понятие «встраиваемость»? [ответ]

  • 1) нетребовательность к настройке; ( — этот ответ правильный — см. почему)
  • 2) незаметность для приложений;
  • 3) минимизация потребления ресурсов;
  • 4) контроль занимаемой памяти.

26. Дать определение среды проектирования.

Среда проектирования представляет собой совокупность различных внешних и внутренних по отношению к коллективу разработчиков факторов, непосредственно определяющих стиль, технологию, качество и сроки выполнения проекта

27. Внутренние факторы среды проектирования

  • 1) оборудование;
  • 2) программное обеспечение;
  • 3) квалификация персонала;
  • 4) объем «наработок»;
  • 5) правила и традиции;
  • 6) стратегия руководства.

28. Внешние факторы среды проектирования.

  • 1) социально-экономическая ситуация;
  • 2) целевая установка заказчика;
  • 3) ясность понимания задачи заказчиком;
  • 4) четкость формулировки задачи заказчиком;
  • 5) правила, традиции заказчика.

29. Этапы проекта и проектная документация.

  • 1) Quick-проект;
  • 2) план работ по ТЗ;
  • 3) ТЗ;
  • 4) договор на выполнение работ;
  • 5) план работ по проекту;
  • 6) программа-методика испытаний;
  • 7) собственно проект;
  • 8) работы по проекту;
  • 9) контрольное тестирование;
  • 10) акт приемки;
  • 11) внедрение;
  • 12) сопровождение.

30. Объекты, участвующие в процессе управления.

  • 1) управляющая система;
  • 2) управляемая система;
  • 3) внешняя среда.

31. Идея управления.

  • 1) задача управления: обеспечить соответствие поведения системы заранее установленной целевой функции;
  • 2) в частном случае целевая функция может быть задана как набор критериев;
  • 3) с целью обеспечения выполнения целевой функции на управляемый объект оказываются определенные воздействия.

32. Общие принципы управления.

  • 1) управление всегда имеет цель;
  • 2) управление возможно только тогда, когда есть неопределенность.

33. Виды ресурсов, учитываемые при планировании.

  • 1) структура;
  • 2) кадровый потенциал;
  • 3) средства производства;
  • 4) финансы.

34. Виды планов.

  • 1) стратегический;
  • 2) тактический;
  • 3) оперативный.
_____________________________________________
Источники(читать подробнее)=
http://masters.donntu.edu.ua/2007/fvti/m.
http://ru.wikipedia.org/wiki/%D0%9F%D1%8.
Ключевые слова и фразы(для поиска)=

Key Words for FKN + antitotal forum (CS VSU):

  • программирование
  • ошибки
  • неофициальный форум фкн
  • фкн
  • вгу воронеж
  • фкн + вгу + antitoal

Источник: fkn.ktu10.com

ХАРАКТЕРИСТИКА ПРОГРАММНОГО ПРОДУКТА

Все программы по характеру использования и категориям пользователей можно разделить на два класса (рис.8.4) – утилитарные программы и программные продукты (изделия).

Рис. 8.4.Классификация программ по категориям пользователей

Утилитарные программы («программы для себя») предназначены для удовлетворения нужд их разработчиков. Чаще всего утилитарные программы выполняют роль сервиса в технологии обработки данных либо являются программами решения функциональных задач, не предназначенных для широкого распространения.

Программные продукты (изделия) предназначены для удовлетворения потребностей пользователей, широкого распространения и продажи.

В настоящее время существуют и другие варианты легального распространения программных продуктов, которые появились с использованием глобальных или региональных телекоммуникаций:

§ freeware – бесплатные программы, свободно распространяемые, поддерживаются самим пользователем, который правомочен вносить в них необходимые изменения;

§ shareware – некоммерческие (условно-бесплатные) программы, которые могут использоваться, как правило, бесплатно. При условии регулярного использования подобных продуктов осуществляется взнос определенной суммы.

Ряд производителей использует ОЕМ-программы (Original Equipment Manufacturer), т.е. встроенные программы, устанавливаемые на компьютеры или поставляемые вместе с вычислительной техникой.

Программный продукт должен быть соответствующим образом подготовлен к эксплуатации, иметь необходимую техническую документацию, предоставлять сервис и гарантию надежной работы программы, иметь товарный знак изготовителя, а также желательно наличие кода государственной регистрации. Только при таких условиях созданный программный комплекс может быть назван программным продуктом.

Читайте также:
Сколько человек смотрит программу время

Программный продукт – комплекс взаимосвязанных программ для решения определенной проблемы (задачи) массового спроса, подготовленный к реализации как любой вид промышленной продукции.

Путь от «программ для себя» до программных продуктов достаточно долгий, он связан с изменениями технической и программной среды разработки и эксплуатации программ, с появлением и развитием самостоятельной отрасли – информационного бизнеса, для которой характерны разделение труда фирм – разработчиков программ, их дальнейшая специализация, формирование рынка программных средств и информационных услуг.

Программные продукты могут создаваться как:

§ индивидуальная разработка под заказ;

§ разработка для массового распространения среди пользователей.

При индивидуальной разработке фирма-разработчик создает оригинальный программный продукт, учитывающий специфику обработки данных для конкретного заказчика.

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

Программный продукт разрабатывается на основе промышленной технологии выполнения проектных работ с применением современных инструментальных средств программирования. Специфика заключается в уникальности процесса разработки алгоритмов и программ, зависящего от характера обработки информации и используемых инструментальных средств. На создание программных продуктов затрачиваются значительные ресурсы – трудовые, материальные, финансовые; требуется высокая квалификация разработчиков.

Как правило, программные продукты требуют сопровождения, которое осуществляется специализированными фирмами – распространителями программ (дистрибьютерами), реже – фирмами-разработчиками. Сопровождение программ массового применения сопряжено с большими трудозатратами – исправление обнаруженных ошибок, создание новых версий программ и т.п.

Сопровождение программного продукта – поддержка работоспособности программного продукта, переход на его новые версии, внесение изменений, исправление обнаруженных ошибок и т.п.

Программные продукты в отличие от традиционных программных изделий не имеют строго регламентированного набора качественных характеристик, задаваемых при создании программ, либо эти характеристики невозможно заранее точно указать или оценить, так как одни и те же функции обработки, обеспечиваемые программным средством, могут иметь различную глубину проработки. Даже время и затраты на разработку программных продуктов не могут быть определены с большой степенью точности заранее.

Основными характеристиками программ являются:

§ алгоритмическая сложность (логика алгоритмов обработки информации);

§ состав и глубина проработки реализованных функций обработки;

§ полнота и системность функций обработки;

§ объем файлов программ;

§ требования к операционной системе и техническим средствам обработки со стороны программного средства;

§ объем дисковой памяти;

§ размер оперативной памяти для запуска программ;

§ версия операционной системы;

§ наличие вычислительной сети и др.

Программные продукты имеют многообразие показателей качества, которые отражают следующие аспекты:

§ насколько хорошо (просто, надежно, эффективно) можно использовать программный продукт;

§ насколько легко эксплуатировать программный продукт;

§ можно ли использовать программный продукт при изменении условия его применения и др.

Дерево характеристик качества программных продуктов представлено на рис. 8.5.

Рис. 8.5. Дерево характеристик качества программного продукта

Мобильность программных продуктов означает их независимость от технического комплекса системы обработки данных, операционной среды, сетевой технологии обработки данных, специфики предметной области и т.п. Мобильный (многоплатформный) программный продукт может быть установлен на различных моделях компьютеров и операционных систем, без ограничений на его эксплуатацию в условиях вычислительной сети. Функции обработки такого программного продукта пригодны для массового использования без каких-либо изменений.

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

Эффективность программного продукта оценивается как с позиций прямого его назначения – требований пользователя, так и с точки зрения расхода вычислительных ресурсов, необходимых для его эксплуатации.

Расход вычислительных ресурсов оценивается через объем внешней памяти для размещения программ и объем оперативной памяти для запуска программ.

Учет человеческого фактора означает обеспечение дружественного интерфейса для работы конечного пользователя, наличие контекстно-зависимой подсказки или обучающей системы в составе программного средства, хорошей документации для освоения и использования заложенных в программном средстве функциональных возможностей, анализ и диагностику возникших ошибок и др.

Модифицируемость программных продуктов означает способность к внесению изменений, например расширение функций обработки, переход на другую техническую базу обработки и т.п.

Коммуникативность программных продуктов основана на максимально возможной их интеграции с другими программами, обеспечении обмена данными в общих форматах представления (экспорт/импорт баз данных, внедрение или связывание объектов обработки и др.).

В условиях существования рынка программных продуктов важными характеристиками являются:

§ время нахождения на рынке (длительность продаж);

§ известность фирмы-разработчика и программы;

§ наличие программных продуктов аналогичного назначения.

Программные продукты массового распространения продаются по ценам, которые учитывают спрос и конъюнктуру рынка (наличие и цены программ-конкурентов). Большое значение имеет проводимый фирмой маркетинг, который включает:

§ формирование политики цен для завоевания рынка;

§ широкую рекламную кампанию программного продукта;

§ создание торговой сети для реализации программного продукта (так называемые дилерские и дистрибьютерные центры);

§ обеспечение сопровождения и гарантийного обслуживания пользователей программного продукта, создание горячей линии (оперативный ответ на возникающие в процессе эксплуатации программных продуктов вопросы);

§ обучение пользователей программного продукта.

Спецификой программных продуктов (в отличие от большинства промышленных изделий) является также и то, что их эксплуатация должна выполняться на правовой основе – лицензионные соглашения между разработчиком и пользователями с соблюдением авторских прав разработчиков программных продуктов.

Источник: allrefrs.ru

Рейтинг
( Пока оценок нет )
Загрузка ...
EFT-Soft.ru