1.5.3. Зручність

Цей критерій найбільш суб'єктивний. Можна запропонувати, наприклад, такий підхід: система або її частина зручна, якщо вона дозволяє легко і просто вирішувати ті завдання, які зустрічаються найбільш часто, але в той же час містить засоби для вирішення широкого кола менш стандартних завдань (нехай навіть ці кошти не настільки прості). Приклад: таке часте дію, як копіювання файлу, повинно виконуватися за допомогою однієї простої команди або легкого руху миші; в той же час для переформатування диску не гріх почитати керівництво, оскільки це може знадобитися навіть не щороку.

Розробники кожної ОС мають власні уявлення про зручність, і кожна ОС має своїх прихильників, які вважають саме її ідеалом зручності.

1.5.4. Масштабованість

Досить дивний термін «масштабованість» (scalability) означає можливість налаштування системи для використання в різних варіантах, в залежності від потужності обчислювальної системи, від набору конкретних периферійних пристроїв, від ролі, яку відіграє конкретний комп'ютер (сервер, робоча станція або ізольований комп'ютер) від призначення комп'ютера (домашній, офісний, дослідний і т.п.).

Гарантією масштабованості служить продумана модульна структура системи, що дозволяє в ході установки системи збирати та налаштовувати потрібну конфігурацію. Можливий і інший підхід, коли під загальною назвою об'єднуються, по суті, різні системи, що забезпечують в розумних межах програмну сумісність. Прикладом можуть служити версії Windows NT/2000/XP, Windows 95/98 і Windows CE.

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

користувач купує ліцензію на дорожчу версію. Але це вже питання, пов'язане не з технічною стороною справи, а з маркетинговою політикою.

1.5.5. Здатність до розвитку

Щоб складна програма мала шанси проіснувати довго, в неї спочатку мають бути закладені можливості для майбутнього розвитку.

Однією з головних умов здатності системи до розвитку є добре продумана модульна структура, в якій чітко визначені функції кожного модуля і його взаємозв'язку з іншими модулями. При цьому створюється можливість вдосконалення окремих модулів з мінімальним ризиком викликати небажані наслідки для інших частин системи.

Важливою вимогою до розвитку ОС є сумісність версій знизу вгору, що означає можливість безболісного переходу від старої версії до нової, без втрати раніше напрацьованих прикладних програм і без необхідності різкої зміни всіх навичок користувача. Зворотна сумісність - зверху вниз - як правило, не гарантується, оскільки в ході розвитку система здобуває нові можливості, не реалізовані в старих версіях. Програма з Windows 3.1 буде нормально працювати і в Windows XP; навпаки - навряд чи.

Фірми-виробники ОС докладають максимум зусиль для забезпечення сумісності знизу вгору, щоб не відлякати користувачів. Але при цьому фірми намагаються в кожну нову версію закласти якусь нову цукерку, яка спонукала б користувачів якнайскоріше купити її.

Сумісність версій - благо для користувача, однак на практиці вона часто призводить до консервації давно віджили свій вік особливостей або ж просто невдалих рішень, прийнятих в ранній версії системи. У документації подібні архаїзми позначаються як «застарілі» (obsolete), але повної відмови від них, як правило, не відбувається (а раптом десь ще працює прикладна програма, написана двадцять років тому з використанням саме цих коштів?).

Як правило, найбільш консервативної стороною будь-якої ОС є не алгоритми, а структури системних даних, тому далекоглядні розробники заздалегідь будують структури «на виріст»: закладають в них резервні поля, використовують змінні замість деяких констант, встановлюють кількісні обмеження з великим запасом і т.п .

1.5.6. Мобільність

Під мобільністю (portability) розуміється можливість перенесення програми (в даному випадку ОС) на іншу апаратну платформу, тобто на інший тип процесора і іншу архітектуру комп'ютера. Тут мається на увазі перенесення з помірними трудовитратами, що не вимагає повної переробки системи.

Властивість мобільності не настільки однозначно позитивно, як може здатися. Щоб програма була мобільна, при її розробці слід відмовитися від глибокого використання особливостей конкретної архітектури (таких, як кількість і функціональні можливості регістрів процесора, нестандартні команди і т.п.). Мобільна програма повинна бути написана на мові досить високого рівня (часто використовується мова C), який можна реалізувати на комп'ютерах будь архітектури. Платою за мобільність завжди є деяка втрата ефективності, тому немобільні системи поширені досить широко.

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

У той же час мобільна система UNIX продовжує процвітати четвертий десяток років, набагато переживши ті комп'ютери, для яких вона спочатку створювалася. Приблизно 5-10% вихідних текстів UNIX написані на мови асемблера і повинні листуватися заново при перенесенні на нову архітектуру. Інша частина системи написана на C і практично не вимагає змін при перенесенні.

Деяким компромісом є багатоплатформні ОС (наприклад, Windows NT), спочатку спроектовані для використання на декількох апаратних платформах, але не гарантують можливість перенесення на нові, не передбачені заздалегідь архітектури.