Словарик философствующего информатика: различия между версиями

Содержимое удалено Содержимое добавлено
Нет описания правки
Строка 294:
Характеристки программного средства делятся на группы.
Характеристики, важные пользователю:
* '''функциональность''' (functionality)
* '''надежность''' (reliability)
* '''легкость и удобность применения''' (usability)
* '''эффективность''' (efficiency)
* '''мобильность''' (portability)
 
 
Строка 320:
Эта характеристика касается не качества работы ПС, а качества архитектуры и качество исходного кода ПС:
* концептуальная продуменность архитектуры, которая делает систему простой, легко понимаемой и расширяемой
* [[#Самодокументированность (code self-documentation)|самодокументированность кода]]
* [[#самопроверяемость (code self-verification)/самопроверяемость кода]]
Эта характеристика, часто непринимаемая во внимание пользователем (пользователь часто просто не имеет доступа к исходным кодам ПС), играет ключевую роль в жизнеспособности и используемости ПС на практике.
 
Строка 513:
[[/Злые волшебники]]
 
=== Self-documentation ===
 
=== Правильность и надежность ===
=== Self-verification ===
 
Безусловно, программные средства должны работать правильно и надёжно.
Но оба упомянутых термина допускают большую свободу интрепретации.
Работать правильно — это
* так, как представляет себе это заказчик;
* так как записал в техзадании постановщих задания;
* так как понял это задание программист;
Ясно, что данные три пункта могут отличаться. Вариантов, в действительности гораздо больше,
так как между заказчиком и постановщиком задания может быть еще несколько менеджеров проекта.
Это отдельная тема, но мы не будем её развивать,
а обратимся к связанную критерию качества ПС — надёжности.
 
Под надежностью можно понимать правильность работы для всех входных данных.
И в таком случае, правильность работы ПС подразумевает его надежность.
Но более правильно следующее представление о надежности:
 
'''Надёжность ПС''' — это правильность работы ПС при экстремальных условиях,
достижимое засчет учета возможных сбоев в различных подсистемах, от корых зависит
работа ПС.
 
Здесь словосочетание «правильность работы» имеет смысл заменить на
 
[[#Самодокументированность (code self-documentation)|Самодокументированность]] и
[[#Cамопроверяемость (code self-verification)|самопроверямость]] являются важными общепринятыми методологиями
достижения нажёжности кода.
 
Кроме того, надежность ПС гарантируется с помощью массового и многопланового [[#Тестирование|тестирования]] ПС.
 
Также существуют специализированные инструменты,
осуществляющие анализ кода и проверяющие выполнение необходимых условий.
Эти условия указываются непосредственно в коде, и непосредственно
связаны с требованиями, предъявляемыми к ПС в спецификации логики работы.
Например, это могут быть post- и prerequisites conditions —
условие, которым должны удовлетворять данные в момент вызова некоторой функции,
и в момент завершения выполнения функции.
Задача ''доказательства правильности работы программ'' довольно сложна,
но уже есть прецеденты создания программ, для которых с использованием специальным программ
доказано, что они ''всегда'' работают правильно.
 
Выделенное слово ''всегда'' и есть такое слово, степень приближения к которому
измеряется надёжностью.
 
Неправильно думать, что надежность достигается на этапах кодирования и
тестирования. Думать о надёжности ПС следует начинать на этапе проектирования.
В частности уменьшение числа зависимостей между компонентами за счёт
тащательно продуманной архитектуры и исключения лишних зависимостей позволяет
уменьшить количество источников проблем, и тем самым облегчить задачу
достижения надёжности на этапах кодирования и тестирования.
 
Часто излишнее стремление к надежности приводит к слишком жесткой архитектуре,
слишком медленному коду. Например, в коде в самых различных
местах можно вставлять кусочки, проверяющие корректность данных,
с которыми будет связано следующее действие.
Здесь, как и везде и информационных технологиях, важно чувствовать баланс
и не доводить стремление к надежности до параной.
Важно распределить задачу достижения надежности по различным этапам разработки ПС,
на каждом этапе делая то, что может быть сделано на этом этапе меньшими усилиями, чем на других,
не усложняя при этом сильно разработку.
 
 
=== Самодокументированность (code self-documentation) ===
 
 
 
=== Cамопроверяемость (code self-verification) ===