Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Ryabokon.doc
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
525.82 Кб
Скачать
  1. Еволюція відкритого версійного программного забезпечення.

Розробка F / OSS (вільне (безкоштовне) ПЗ/ПЗ з відкритим кодом) з'явилася і поширилась в усьому світі технології програмного забезпечення в основному в останні десять років. Це збігається з поширенням, прийняття і регулярним використанням Інтернету та Всесвітньої павутини в якості глобальної технічної системи. Ця інфраструктура підтримує широкий доступ до раніше вилученої інформації та програмного забезпечення, а також можливість для децентралізованих громад однодумців, щоб знайти і спілкуватися один з одним. Це світ, який багато в чому відрізняється від традиційної розробки програмного забезпечення. Таким чином, щоб краще зрозуміти, чи є моделі еволюції програмного забезпечення в технічному і соціальному режимі F / OSS, відповідають або відрізняються від попередніх досліджень або моделей еволюції програмного забезпечення, доцільно почати з визначення типів об'єктів для F / OSS еволюції, а потім прямувати з розгляду емпіричних досліджень, збір даних і аналіз F / OSS лінії розвитку.

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

  1. Індекс супроводжуваності.

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

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

  1. Модель зрілості супроводження програмного забезпечення (sммм).

Мета моделі: SMmm була розроблена як орієнтована на клієнта еталонна модель, тобто орієнтир для:

• Аудит супроводу програмного забезпечення служби постачальника програмного забезпечення технічного обслуговування або аутсорсера; або

• Підвищення внутрішньої організації з технічного обслуговування програмного забезпечення.

Ця модель була розроблена з точки зору споживача, як досвід в конкурентоспроможному, комерційному середовищі. Кінцевою метою поліпшення програм, ініційованих в результаті SM – збільшення оцінки задоволення клієнтів, а не жорстка відповідність стандартам

SMmm була побудована виконанням послідовності операцій, виконуваних при проектуванні моделі Trillium [Tri91]. Це робиться за рахунок інтеграції практики з ключових документів, що відносяться до технічного обслуговування програмного забезпечення передового досвіду у відповідності з 9 крокі:

Крок 1 - Практика взята з відображення в додатках A & B та архітектурі високого рівня

Крок 2 - Відображення проводиться з версією 1.1 CMMi [Sei02]. CMMi практики можуть бути злегка змінені для забезпечення цього відображення;

Крок 3 - Положення ISO 9001:2000 [Iso00] з використанням ISO9003: 2004 [Iso04]. Подібні практики потім розглядаються поодинці, додаються та інтегруються з моделлю;

Крок 4 - Інші практики моделі зрілості відображаються в конкретних областях, в залежності від їх охоплення області програмного забезпечення.

Крок 5 - посилання на IT Infrastructure Library керівних принципів найкращої практики в галузі надання послуг та сервісної підтримки [Iti01a, Iti01b];

Крок 6 - Легше відображення процесу здійснюється з відповідними частинами Малькольма Болдріджа критерії експертизи [Mal04];

Крок 7 - Обрана практика CobIT [Cob00] відображається де доречний супровід програмного забезпечення;

Крок 8 - посилання, що мають відношення до ISO / IEC і IEEE стандартів додаються (ISO/IEC12207, ISO/IEC14764 і IEEE 1219);

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]