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

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

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

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

14.3. Планування і складання розкладів по розробці ПС.

Загальне уявлення про цю діяльність можна скласти по її опису на псевдокоді (див. лекцію 8), приведеному на мал. 14.2 (див. також [14.1]). Цей опис показує, що планування і складання розкладів по розробці ПС є ітеративним процесом, який закінчується тільки після припинення робіт за самим програмним проектом.

Определить ограничения, с которыми проект должен быть доведен до конца.

Сделать начальную оценку параметров проекта.

Установить вехи развития проекта и их сроки.

ПОКА проект не является завершенным или прекращенным (аннулированным)

ДЕЛАТЬ

Составить расписание проекта.

Инициировать процессы, соответствующие расписанию.

ПОДОЖДАТЬ.

Просмотреть развитие проекта.

Скорректировать параметры проекта.

Оценить влияние изменения параметров проекта на расписание проекта.

Уточнить ограничения и сроки.

ЕСЛИ возникли проблемы ТО

Инициировать технический пересмотр и возможную ревизию проекта.

ВСЕ ЕСЛИ

ВСЕ ПОКА

---

Мал. 14.2. Опис на псевдокоді процесу планування і складання розкладів по розробці ПС.

На початку цього опису оцінюються загальний термін розробки ПС, використовувані штати виконавців, граничний бюджет і інші обмеження (умови) розробки. З урахуванням цього фіксуються початкові параметри проекту (його структура і розподіл функцій). Повинні бути також визначені «віхи розвитку проекту» і їх терміни. Віха розвитку проекту (project progress milestone) – це кінцева точка деякого етапу або процесу, з якою зв'язується видача деякого проміжного продукту, що є деяким чітко певним документом. Віхи розвитку проекту забезпечують можливість контролю розвитку проекту і можливість модифікації розкладів проекту.

Далі починається ітераційний процес, основу якого складає складання розкладів, що повторюються. Складання розкладу полягає

• у розділенні всієї роботи, необхідної для виконання проекту, на окремі самостійно виконувані завдання;

• у складанні мережевого графіка виконання завдань;

• у складанні гістограми виконання завдань;

• у розстановці виконавців завдань.

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

Через деякий час (звичайно 2-3 тижні) після активізації процесів, вказаних в розкладі, проводиться огляд (перегляд) ходу розвитку проекту і наголошуються виниклі суперечності. З урахуванням цього проводиться перегляд (уточнення) параметрів проекту і оцінюється вплив змінених параметрів на розклад проекту. Якщо опиниться, що ці зміни збільшують час розробки ПС, необхідно обговорити із замовником можливість зміни обмежень проекту і терміну його завершення. У тому випадку, коли замовник не може піти на відповідні зміни, проводиться технічний перегляд проекту з метою пошуку альтернативних підходів до розробки ПС.

---

14.4 Атестації програмного засобу.

Завершуючим етапом розробки ПС є атестація ПС, що підводить підсумок всій розробці. Атестація (certification) ПС  це авторитетне підтвердження якості ПС [14.5, 14.6]. Зазвичай для атестації ПС створюється атестаційна комісія з експертів, представників замовника і представників розробника. Ця комісія проводить приймально-здавальні випробування ПС з метою отримання необхідної інформації для оцінки його якості. Під випробуванням ПС тут розуміють [14.6, 14.7] процес проведення комплексу заходів, що досліджують придатність ПС для успішної його експлуатації (застосування і супроводи) відповідно до вимог замовника. У цьому процесі перевіряється повнота і досліджується якість представленої програмної документації, проводиться необхідне тестування програм, що входять до складу ПС, а також досліджуються і інші властивості ПС, що декларують в його специфікації якості. На основі отриманої інформації комісія повинна встановити, в якому ступені ПС виконує функції, що декларують, і в якому ступені ПС володіє примітивами, що декларують, і критеріями якості. Вирішення атестаційної комісії про проведену оцінку якості ПС фіксується у відповідному документі (сертифікаті), який підписується членами комісії.

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

• безпосереднє вимірювання показників примітиву якості;

• тестування програм ПС;

• експертна оцінка на підставі вивчення програм і документації ПС.

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

Для оцінки деяких примітивів якості ПС використовується тестування [14.5-14.8]. До таких примітивів відносяться, перш за все, завершеність ПС, а також його точність, стійкість, захищеність і інші примітиви якості. Це питання вже обговорювалося в лекції 10. Проте, під час приймально-здавальних випробувань немає необхідності проведення тестування ПС в повному об'ємі (це може дуже дорого коштувати). Атестаційна комісія винна, перш за все, вивчити пред'явлену документацію по проведеному розробниками тестуванню ПС і лише вибірково пропустити пред'явлені тести. Додаткові тести складаються, якщо у комісії виникають певні сумніви в облиште тестування, проведеного розробниками. Крім того, зазвичай працездатність і деякі показники якості ПС демонструються на вирішенні контрольних завдань, що пред'являються замовником.

---

В деяких випадках для оцінки якості ПС проводяться додаткові польові або промислові випробування [14.8, 14.9]. Польові випробування ПС – це демонстрація ПС разом з технічною системою, якою управляє ця ПС, із забезпеченням ретельного спостереження за поведінкою ПС. Замовникам повинна бути надана можливість завдання власних контрольних прикладів, зокрема, з виходом в критичні режими роботи технічної системи, а також з викликом в ній аварійних ситуацій. Промислові випробування ПС – це процес передачі ПС в постійну експлуатацію користувачам, що є дослідною експлуатацією ПС (див. лекцію 10) користувачами із збором інформації про особливості поведінки ПС і її експлуатаційних характеристиках.

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

Атестація ПС схожа на огляд різних компонент ПС в процесі управління якістю ПС, проте, є і істотні відмінності [14.1]. По-перше, огляд проводиться менш представницькою групою фахівців. По-друге, в процесі огляду не проводиться повної оцінки якості ПС, а виявляються лише окремі прорахунки і порушення вимог щодо якості ПС, пов'язані з компонентой (документом), що оглядає, при цьому не вимагається негайного усунення виявлених недоліків, якщо вони не заважають проведення подальших робіт. Метою ж атестації є перевірка і фіксація реальних показників якості пред'явленого ПС [14.7]. Якщо атестаційна комісія підтверджує, що пред'явлене ПС відповідає всім вимогам щодо його якості, сформульованим в зовнішньому описі цього ПС, то вважається, що його розробка завершена успішно і замовник зобов'язаний прийняти це ПС. Якщо ж будуть виявлені відступи від цих вимог, то повинні ухвалюватися певні рішення про продовження або припинення розробки пред'явленого ПС, але це вже питання взаємин між замовником і розробниками. Таким чином, атестаційна комісія, підписуючи документ про проведену оцінку якості ПС, приймає на себе певну відповідальність за гарантію якості цього ПС. Але тут є певні правові проблеми, обговорення яких виходить за рамки теми цієї лекції.

---

Вправи до лекції 14.

14.1. Що таке управління розробкою ПС?

14.2. Що таке менеджер програмного проекту?

14.3. Що таке неформальна демократична бригада розробників ПС?

14.4. Що таке бригада провідного програміста?

14.5. Що таке огляд програмної компоненти (програмного документа)?

14.6. Що таке атестація ПС?

Литература к лекции 14.

14.1. Ian Sommerville. Software Engineering. – Addison-Wesley Publishing Company, 1992. – P. 479-493.

14.2. В.В. Липаев. Управление разработкой программных средств. Методы, стандарты, технология. – М.: Финансы и статистика, 1993.

14.3. Б. Шнейдерман. Психология программирования. – М.: Радио и связь, 1984. – С. 128-146.

14.4. Ф.П. Брукс, мл. Как проектируются и создаются программные комплексы. – М.: Наука, 1979.

14.5. Г. Майерс. Надежность программного обеспечения. – М.: Мир,1980. - С. 174-175.

14.6. Е.А. Жоголев. Введение в технологию программирования (конспект лекций). – М.: "ДИАЛОГ-МГУ", 1994.

14.7. В.В. Липаев, Е.Н. Филинов. Мобильность программ и данных в открытых информационных системах. – М.: Научная книга, 1997. – С. 252-268.

14.8. В.В. Липаев. Тестирование программ. – М.: Радио и связь, 1986. – С. 231-245.

14.9. Д. Ван Тассел. Стиль, разработка, эффективность, отладка и

испытание программ. – М.: Мир, 1985. – С. 281-283.

---

Смотрите также файлы

• Лекція 11.doc

• Практическая стилистика руссского языка.pdf

• Т. В. Корнилова Экспериментальная психология.doc

• Гуревич ПС Психология.pdf

• Комуникационные технологии. О.М. Холод.doc