- При возникновении изменений спецификаций в проекте заказчик будет в курсе, и, в случае необходимости, изменит тех. задание и спецификацию.
Замечание. Заказчик должен быть заинтересован. Заказчик – это не только эксперт хода проведения работы, на него можно переложить часть функций архитектора системы: проектирование пользовательского интерфейса и лингвистическое обеспечение проекта (среда пользователя с интуитивно понятными ему методами работы и структурой его деятельности, вплоть до использования терминологии).
Завершающий этап: при таком подходе работы с заказчиком облегчается процесс сдачи работы.
23. Качество программных продуктов. Оценка качества программ.
Прежде чем оценивать качество, ПП должен быть
Понятие «качество» - относительное понятие
1. Нельзя оценить ПП в абсолютном выражении
2. ПП оцениваются относительно друг друга
3. Оценка качества может быть произведена по каким-либо выделенным и заранее определённым критериям оценивания. Если критерии не определены, качество не оценивается.
Критерий определяется для каждой из характеристик программ. При этом критерии должны быть определены в категориях:
- Метрика
- Мера (ед. измерения)
- Шкала диапазона изменения характеристики
Шкалы:
- Абсолютные (любой диапазон от -∞ до +∞)
- Шкала отношений (Свойство А1 лучше, чем А2 и т.д.) А1>А2; А1>А3; А2?А3. Надо А1>А2>А3
- Шкала порядка. Может быть представлена чётко упорядоченным отношением некоторых характеристик, свойств программы: отличная, хорошая, удовлетворительная, плохая, очень плохая.
4. Шкала наименований. Каждому понятию соответствует какое-либо наименование.
Для оценки программы необходимо сформировать критерий оценки с указанием шкалы, метрики и единицы измерения. На основе этих 3 понятий формируется критерий оценки программы
Программа |
Оценки программы |
Сумма |
||
1 |
||||
2 |
||||
Сумма |
Сумму сложно рассчитывать, если шкалы разные. Одним из выходов является использование бальной шкалы. Субъективная оценка экспертов, которые оценивают ПП.
24. Инсталляция и деинсталляция пакетов программ.
Setup.exe
*.pab
*.html
*.chl
25. Авторское право и виды пакетов прикладных программ.
Конвенция «о защите авторских прав в области ПО, БД и интегральных микросхем». По конвенции ПП нельзя использовать без разрешения. То есть необходимо получить право на использование, либо все права на продукт. Права могут переходить как за деньги, так и без какого-либо материального вознаграждения, все зависит от вида ППП:
Достоинства для пользователей:
a. В роли тестировщика обычно выступают фирмы, создающие или собственное ПО, или фирмы, которые выпускают hardware, для которого надо писать драйвера.
26. Защита программ от копирования.
В защите от копирования нет смысла, если программа создается для 1 пользователя. Защита нужна, когда вы собираетесь получать доход от продажи интеллектуальной собственности. Методов защиты от копирования много, они постоянно развиваются (и постоянно взламываются):
1. Привязка ПП к конкретному компьютеру. Применялась еще во времена DOS. ПП генерируется для конкретного компьютера
2. Ключевая дискета. ПП не работает до тех пор, пока в дисковод не вставлена ключевая дискета, на которой записан какой-либо ключ.
3. Использование конфигурации компьютера. Параметры компьютера записываются в некоторое место на диске и наличие такого файла является разрешением на работу программы.
4. Электронный ключ. В порт принтера или USB вставляется устройство, наличие которого программа проверяет при загрузке. В электронный ключ помещается некоторый код, который может использоваться для кодирования данных, используемых ПП. (1С, Компас).
При защите программ от копирования 2 стороны решают одну и ту же задачу. Разработчик оптимизирует стоимость средств защиты относительно прибыли, которую он получит. Нелегальные продавцы решают ту же задачу: оптимизируют прибыль относительно затрат на вскрытие + стоимость защиты + юридический компонент.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.