МЕТОДИЧНІ ВКАЗІВКИ

до виконання практичних робіт

з дисципліни:

«ПРОЕКТНИЙ ПРАКТИКУМ»

«Розробка програмного забезпечення»

Вимоги до оформлення:

1. Практична робота має один варіант для усіх студентів, виконується на аркушах формату А4 в друкованому варіанті згідно ДСТУ 30008-95. Також допускається виконання роботи у письмовому вигляді в окремому зошиті.

2. Практична робота складається з одного завдання, а саме – розробити специфікацію програмного забезпечення для обраної теми згідно варіанту.

3. Практична робота повинна бути здана не пізніше ніж через два тижні від дати видачі завдання.

4. Практична робота повинна містити в собі наступні розділи: Титульний лист, на якому позначається назва дисципліни, ПІБ розробника, ПІБ

викладача; Тема; Мета; Завдання; Хід виконання завдання; Перелік використаної літератури та інформаційних джерел;

Практична робота № 1

Тема: Проектування проекту з використанням шаблону Façade.Мета: Ознайомитись із шаблоном проектування, здобути навички проектування.Завдання: Оберіть предметну область, розробіть програмне забезпечення з використанням шаблону Façade. Опишіть розроблене ПЗ згідно шаблону, розробіть необхідні функціональні блоки.

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

У моїй практиці був випадок, коли я працював за контрактом для великої інженерно-виробничої компанії. У день мого першого появи на новому робочому місці безпосередній керівник проекту був відсутній. Компанія відмовлялася оплатити цей робочий день просто так, але ніхто не знав, яке завдання мені слід доручити. Вони хотіли, щоб я робив хоч чтонибудь, навіть якщо це не принесло б ніякої користі! Думаю, вам теж доводилося стикатися з чимось подібним. Зрештою, одна зі співробітниць знайшла для мене заняття. Вона сказала: "Вважаю, що рано чи пізно, але вам обов'язково потрібно вивчити ту САПР, яка використовується у нас в даний час, - так що ви можете приступити до цього прямо зараз ". Після цих слів дівчина вказала мені на стос документації, що займала на книжковій полиці майже 3 метри. Книги були надруковані дрібним шрифтом на аркушах формату А4, і вся ця гора паперу представляла собою технічний опис однієї єдиної, але дуже складною системи.

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

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

КОНТРОЛЬНІ ПИТАННЯ:1. Що таке шаблон проектування?2. Опишіть основні характеристики шаблону FAÇADE.3. Які переваги та недоліки, на Вашу думку, має шаблон проектування FACADE?

ЛІТЕРАТУРА:1. ISO 10014. Управление качеством — Указания по получению финансовых и экономических выгод.2. ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» (информационные технологии – жизненный цикл программного обеспечения), ГОСТ Р ИСО/МЭК 12207-99.3. Буч Г. Коналлен Д. Максимчук Р.А. Хьюстон К. Энгл М. Янг Б. Объектно-ориентированный анализ и проектирование с примерами приложений. – 3-е изд. М.: Вильямс, 2008. – 720 с.4. Гонтарев И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами. М.: Диброком, 2009. – 384 с.5. ГОСТ Р ИСО/МЭК 15288-2005. Системная инженерия. Процессы жизненного цикла систем6. ГОСТ Р ИСО/МЭК ТО 16326-2002. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом

Практична робота № 2Тема: Проектування проекту з використанням шаблону Adapter.Мета: Ознайомитись із шаблоном проектування, здобути навички проектування.Завдання: Оберіть предметну область, розробіть програмне забезпечення з використанням шаблону Adapter. Опишіть розроблене ПЗ згідно шаблону, розробіть необхідні функціональні блоки.

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

• Створити класи для представлення в системі точок, ліній і квадратів, кожен з яких матиме метод display (відобразити).

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

• Необхідно використовувати підпрограму або метод, написаний кимось іншим, оскільки в ньому реалізовані саме ті функції, які нам потрібні.

• При цьому включити готову підпрограму безпосередньо в створювану програму неможливо.

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

абстрактні фігури. • Це дозволить об'єктам-клієнтам працювати з будь-якими типами об'єктів-даних

одним і тим же чином, не беручи до уваги існуючі між ними відмінності (рис. 7.1). • Крім того, з'являється можливість згодом додавати в систему нові види фігур, не

вносячи жодних змін в ті об'єкти, які будуть їх використовувати.

Тут використовується принцип поліморфізму; тобто в системі присутні об'єкти-дані різних типів, але використовують їх об'єкти-клієнти повинні взаємодіяти з ними одним і тим же чином. У результаті об'єкт-клієнт може просто вказати об'єкту-даному (незалежно від того, представляє він точку, лінію або квадрат), що необхідно виконати ту чи іншу дію - наприклад, відобразити себе на екрані або, навпаки, видалити з екрану своє зображення. У цьому випадку кожен об'єкт, що представляє точку, лінію або квадрат, повинен буде нести повну відповідальність за коректне виконання необхідних операцій в повній відповідності зі своїм типом. Для вирішення поставленого завдання створимо клас Shape (фігура), а потім визначимо похідні від нього класи, що представляють точки (Point), лінії (Line) і квадрати (Square) - як показано на рис. 7.2.

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

• Отримати дані про становище об'єкта Shape (метод setLocation). • Повідомити дані про становище об'єкта Shape (метод getLocation). • Показати представлену об'єктом фігуру на екрані (метод display). • Зафарбувати зображення фігури вказаним кольором (метод fill). • Встановити колір зафарбовування фігури (метод setColor). • Видалити зображення фігури з екрана (метод undisplay). Припустимо, що в систему необхідно включити новий тип об'єктів класу Shape,

призначений для представлення кіл (не забувайте, що вимоги постійно змінюються!). Для цієї мети створимо новий клас, Circle (Коло), який представлятиме в системі окружності. Реалізуємо клас Circle як похідний від класу Shape, що дозволить скористатися перевагами його полиморфного поведінки.

Тепер необхідно написати методи display, fill і Undisplay для класу Circle. Це завдання може виявитися досить складною. На щастя, після недовгих пошуків альтернативних рішень (що завжди повинен робити кожен хороший програміст), з'ясувалося, що один з моїх колег вже описав в системі клас XXCircle, призначений для роботи з колами (рис. 7.4). На жаль, він попередньо не порадився зі мною, як краще назвати методи цього класу, тому вони отримали такі імена:

• displayIt • fillIt • undisplayIt

В результаті, безпосередньо використовувати клас XXCircle не можна, оскільки бажано зберегти поліморфну поведінку, реалізоване в класі Shape, але цьому перешкоджають наступні моменти.

• Клас Shape і клас XXCircle включають методи з різними іменами і різними списками параметрів.

• Клас XXCircle повинен не тільки мати співпадаючі імена методів, а й обов'язково бути похідним від класу Shape.

КОНТРОЛЬНІ ПИТАННЯ:1. Що таке шаблон проектування?2. Опишіть основні характеристики шаблону Adapter.3. Які переваги та недоліки, на Вашу думку, має шаблон проектування Adapter?

ЛІТЕРАТУРА:1. ISO 10014. Управление качеством — Указания по получению финансовых и экономических выгод.2. ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» (информационные технологии – жизненный цикл программного обеспечения), ГОСТ Р ИСО/МЭК 12207-99.3. Буч Г. Коналлен Д. Максимчук Р.А. Хьюстон К. Энгл М. Янг Б. Объектно-ориентированный анализ и проектирование с примерами приложений. – 3-е изд. М.: Вильямс, 2008. – 720 с.4. Гонтарев И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами. М.: Диброком, 2009. – 384 с.5. ГОСТ Р ИСО/МЭК 15288-2005. Системная инженерия. Процессы жизненного цикла систем

Практична робота № 3Тема: Проектування проекту з використанням шаблону Bridge.Мета: Ознайомитись із шаблоном проектування, здобути навички проектування.Завдання: Оберіть предметну область, розробіть програмне забезпечення з використанням шаблону Bridge. Опишіть розроблене ПЗ згідно шаблону, розробіть необхідні функціональні блоки.

Щоб краще зрозуміти ідею побудови шаблону Bridge і принципи його роботи, розглянемо конкретний приклад поетапно. Спочатку обговоримо встановлені вимоги, а потім проаналізуємо висновок основної ідеї шаблону і способи його застосування. Можливо, цей приклад може здатися занадто простим. Однак придивіться до обговорюваних в ньому концепціям, іям, а потім спробуйте згадати аналогічні ситуації, з якими нам доводилося стикатися раніше. Зверніть особливу увагу на наступне.

• Наявність варіацій в абстрактному представленні концепцій. • Наявність варіацій в тому, як ці концепції реалізуються. Гадаю, у вас не з'явиться сумнівів, що наведений нижче приклад має багато спільного

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

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

І чому. Такий підхід перегукується з філософією шаблонів Александера: "Кожен шаблон описує проблему, яка виникає в даному середовищі знову і знову, а потім пропонує принцип її вирішення таким способом.

Спробуємо застосувати даний підхід до нашого випадку і сформулюємо задачу, для вирішення якої призначений шаблон Bridge. Шаблон Bridge корисний тоді, коли є деяка абстракція і існує не ¬ скільки різних варіантів її реалізації. Шаблон дозволяє абстракції та реалі ¬ зації змінюватися незалежно один від одного. Зазначені характеристики якнайкраще відповідають нашій ситуації. Тому можна зробити висновок, що шаблон Bridge слід використовувати, навіть ще не знаючи до пуття, як він реалізується на практиці. Те, що абстракцію можна буде міняти незалежно від її реалізації, означає, що нові елементи абстракції можна буде додавати, не вносячи яких змін на рівні реалізації і навпаки. Існуюче у нас рішення не забезпечує подібної незалежності змін. Не викликає сумніву, що проект був би набагато краще, якби вдалося знайти рішення, що надає таку можливість. Зауваження. Зверніть особливу увагу на те, що, навіть не знаючи конкретних способів реалізації шаблону Bridge, ми змогли прийти до висновку про можливість і корисності його застосування в нашому проекті. Пізніше ви зрозумієте, що це зауваження справедливо щодо практично всіх шаблонів проектування. Іншими словами, завжди можна встановити, що застосування того чи іншого шаблону в даній предметній області буде можливо і полезн про, навіть не маючи точного уявлення про те, як саме він може бути реалізований.

Тепер, коли досягнуто ясне розуміння стоїть перед нами проблеми, прийшов час спільними зусиллями вивести шаблон Bridge. Самостійний висновок цього шаблону допоможе нам усвідомити його складність і, одночасно, міць. Використовуємо на практиці

деякі з основних положень якісного об'єктно-орієнтованого проектування - вони допоможуть нам знайти рішення, дуже близьке до шаблону Bridge.

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

• Знайдіть те, що змінюється, і інкапсулює це. • Віддавайте перевагу композиції, а не спадкоємства.

КОНТРОЛЬНІ ПИТАННЯ:1. Що таке шаблон проектування?2. Опишіть основні характеристики шаблону Bridge.3. Які переваги та недоліки, на Вашу думку, має шаблон проектування Bridge?

ЛІТЕРАТУРА:1. ISO 10014. Управление качеством — Указания по получению финансовых и экономических выгод.2. ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» (информационные технологии – жизненный цикл программного обеспечения), ГОСТ Р ИСО/МЭК 12207-99.3. Буч Г. Коналлен Д. Максимчук Р.А. Хьюстон К. Энгл М. Янг Б. Объектно-ориентированный анализ и проектирование с примерами приложений. – 3-е изд. М.: Вильямс, 2008. – 720 с.4. Гонтарев И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами. М.: Диброком, 2009. – 384 с.5. ГОСТ Р ИСО/МЭК 15288-2005. Системная инженерия. Процессы жизненного цикла систем

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

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

У ході аналізу предметної області було розглянуто кілька програмних продуктів, один з яких називається «Кафе-8». «Кафе-8» - багатофункціональне ПЗ для ведення бухгалтерського та виробничого обліку в ресторанах, барах, кафе та інших підприємствах громадського харчування. Особливістю всієї лінійки програм «Кафе» є їх сумісність з програмою 1С, т.к. вони побудовані на базі її конфігурацій.

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

Вашим співробітникам, вже працювали з 1С, не доведеться переучуватися, відповідно в роботі не буде збоїв і простоїв.

Інтерфейс програми розроблений за принципом «Все - під рукою», програмою зручно користуватися, а її освоєння займає у користувача не більше 5-10 хвилин. Програма «Кафе8» надає наступні можливості:

автоматичне заповнення калькуляційних карт страв; випуск продукції на підставі заданих калькуляцій; автоматичне списання матеріалів по випущеної продукції; автоматичне заповнення документів на реалізацію готової продукції; автоматичний облік уваркі компонентів. У програмі реалізована друк реєстрів випуску продукції, витрати матеріалів, друк

меню і забірного листа. Що стосується бухгалтерського супроводу, то програма дозволяє: вести роздільний виробничий і бухгалтерський облік витрат матеріалів; проводити групову обробку калькуляцій; програма гарантовано оновлюється до нових релізів 1С; сумісна з квартальною звітністю, що випускається фірмою 1С. Всі меню, документи і звіти типової конфігурації збережені без зміни, в програмі

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

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

Другим програмним продуктом, гідним розгляду є система автоматизації підприємств громадського харчування R-Keeper. Програма R-Keeper була розроблена в 1992 році компанією UCS - першої російської приватною фірмою, що вийшла на ринок громадського харчування з системою власної розробки для автоматизації ресторанів, яка склала гідну конкуренцію зарубіжним аналогам. За 20 років впроваджень назва системи R-Keeper ("еркіпер") стало в середовищі рестораторів ім'ям прозивним.

Станом на січень 2013 року на R-Keeper працюють більше 27000 ресторанів в 34 країнах світу. Наші клієнти - провідні оператори індустрії гостинності.

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

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

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

Постановка задачі:Дипломна робота "Контролер для розподілених інформаційно-управляючих систем"

була виконана в рамках реалізованого на практиці проекту з модернізації експлуатується розподіленої інформаційно-керуючої системи потоці-С для філії ПТС (Петербурзькі Телефонні Мережі) ВАТ "Північно-Західний Телеком".

Фактично, виконана робота стосувалася всіх рівнів системи, так якпроект передбачав:- Модернізацію апаратної частини контролера нижнього рівня;- Оновленняіснуючого ПЗ нижнього рівня;- Оновлення існуючого ПЗ верхнього рівня;- Проведення необхідних експериментів з апробації пропонованих рішень;- Виконання монтажно і пуско-налагоджувальних робіт.Для кращого розуміння суті проекту і завдань, що вирішуються в рамках дипломної

роботи, нижче наведено опис проблематики (система потоці-С і контролер ASK-Lab).2.1 Опис сучасного стану системи потоці-СУ 2005 р. в OAO ПТС [3], [4] запущено в дослідно-промислову експлуатацію

розподілена інформаційно-керуюча система (РІУС) Поток-С, призначена для моніторингу режимів теплопостачання, комерційного обліку споживання тепла спорудами цієї організації, а також забезпечення ряду функцій з дистанційного управління режимами теплопостачання об'єктів. Структура системи представлена на малюнку 2.1.

Верхній рівень системи представлений ДПС, в якому організовано декілька робочих місць: АРМи диспетчера, адміністратора, комерційного обліку та інженера. АРМи об'єднані в ЛОМ.

Нижній рівень системи утворюють більше 100 будинків АТС, розміщених в різних районах міста СПб. Ці будівлі опалюються з використанням міських ТЕЦ і обладнані засобами обліку та регулювання подачі гарячої води в опалювальну систему АТС.

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

В даний час об'єкти ПТС можна розділити на дві групи за ознакою наявності автономного контуру регулювання тепловим режимом станції: ПТС-1 і ПТС-2 (рисунок 2.2).

Вузли обліку ПТС-1 обладнані тільки теплолічильниками (малюнок 2.3), що дозволяють дистанційно зчитувати параметри системи теплопостачання, то:

- Температура і тиск води;- Об'ємний або масова витрата води;- Перенесена теплова енергія в подавальному та зворотному трубопроводі (на вході і

виході системи опалення АТС).Дані з теплолічильників знімаються в ручному або автоматичному режимі (за

розкладом) і використовуються для виявлення нештатних ситуацій, наприклад порушення температурного режиму АТС, порушення договірних показників опалення, прорив трубопроводу і т.д.

Вузли обліку ПТС-2 крім теплолічильника обладнані контролером ECL Comfort 300 (малюнок 2.4), який відповідно до заданими параметрами здійснює автономне регулювання тепловим режимом станції.

Функції управління в підсистемі ПТС-2 реалізовані на базі спеціалізованого контролера ASK-Lab, розробленого в СКБ Державного Університету Аерокосмічного Приладобудування. Зовнішній вигляд контролера в підвалі ПТС представлений на рис. 2.5.

 

Рисунок 2.5 - Контролер ASK-Lab в підвалі ПТСВузли теплопостачання, що входять в підсистему ПТС-2 забезпечені

автоматизованими засувками (малюнок 2.6), управління якими може здійснюватися як теплорегулятор ECL COMFORT-300 в автономному режимі, так і в режимі ручного керування з АРМ інженера.

Однією з головних функцій контролера ASK-Lab є забезпечення можливості прийняття екстрених заходів у разі виникнення аварійних ситуацій в опалювальній системі АТС. Виконавчими пристроями, підключеними до контролера, є два електроприводу і клапан зливу води. Так, у разі аварії в режимі ручного управління з АРМ інженера підсистеми ПТС-2 можна дистанційно перекрити воду в трубах, відкрити клапан для зливу води і таким чином запобігти псуванню дорогого устаткування.

  2.2 Модернізація підсистеми ПТС-2У такому вигляді (підрозділ 2.1) система експлуатувалася до вересня 2007 року. На

підставі накопиченого досвіду у Замовника з'явилися вимоги до вдосконалення РІУС Поток-С.

У рамках дипломного проекту вирішувалися поставлені Замовником завдання з модернізації підсистеми ПТС-2, а саме:

1) Примусове вимикання електромоторів після закінчення тайм-ауту;2) Забезпечення контролю положення засувок;3) Підвищення надійності каналообразующей апаратури.Модернізація ПТС-2 зажадала змін на декількох рівнях системи:1) Апаратне забезпечення контролера ASK-Lab;2) Програмне забезпечення контролера ASK-Lab;3) Програмне забезпечення АРМ інженера.Роботи з модернізації підсистеми ПТС-2 велися в міжопалювальний сезон 2007 року і

становлять суть дипломного проекту.

Примітка: До цієї практичної роботи не передбачені контрольні питання. Вони формуються на основі виконання завдання.

ЛІТЕРАТУРА:1. ISO 10014. Управление качеством — Указания по получению финансовых и экономических выгод.2. ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» (информационные технологии – жизненный цикл программного обеспечения), ГОСТ Р ИСО/МЭК 12207-99.3. Буч Г. Коналлен Д. Максимчук Р.А. Хьюстон К. Энгл М. Янг Б. Объектно-ориентированный анализ и проектирование с примерами приложений. – 3-е изд. М.: Вильямс, 2008. – 720 с.4. Гонтарев И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами. М.: Диброком, 2009. – 384 с.5. ГОСТ Р ИСО/МЭК 15288-2005. Системная инженерия. Процессы жизненного цикла систем

Практична робота № 5Тема: Розробка специфікацій при тестуванні програмного забезпеченняМета: Навчитись розробляти специфікації при тестуванні програмного забезпечення. Завдання: На основі виконаної практичної роботи № 4 розробіть розділ, який назвіть умовно «Тестування програмного забезпечення». Протестуйте програму, опишіть всі її функціональні можливості, опишіть критичні точки проекту, надайте пояснення всім недолікам, які знайшлись, а також опишіть можливості розширення проекту.

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

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

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

З точки зору ISO 9126, якість програмного забезпечення можна визначити яксукупну характеристику досліджуваного ПЗ з урахуванням таких складових:НадійністьСопровождаемостьПрактичністьЕфективністьМобільністьФункціональністьІснує кілька ознак, за якими прийнято виробляти класифікацію видів тестування.

Зазвичай виділяють наступні:По об'єкту тестування:Функціональне тестування (functional testing)Тестування продуктивності (performance testing)Тестування навантаження (load testing)Стрес-тестування(Stress testing)Тестування стабільності (stability / endurance / soak testing)Юзабіліті-тестування (usability testing)Тестування інтерфейсу користувача (UI testing)Тестування безпеки (security testing)Тестування локалізації (localization testing)Тестування сумісності (compatibility testing)По знанню системи:Тестування чорного ящика (black box)Тестування білого ящика (white box)Тестування сірого ящика (grey box)За ступенем автоматизації:Ручне тестування (manual testing)Автоматизоване тестування (automated testing)Напівавтоматизований тестування (semiautomated testing)За ступенем ізольованості компонентів:Компонентне (модульне) тестування (component / unit testing)Інтеграційне тестування (integration testing)Системне тестування (system / end-to-end testing)За часом проведення тестування:

Альфа-тестування (alpha testing)Димове тестування (smoke testing)Тестування новоїфункціональності (new feature testing)Підтверджує тестування (confirmation testing)Регресійне тестування (regression testing)Приймальне тестування (acceptance testing)Бета-тестування (beta testing)За ознакою позитивності сценаріїв:Позитивне тестування (positive testing)Негативний тестування (negative testing)За ступенем підготовленості до тестування:Тестування з документації (formal testing)Тестування ad hoc або інтуїтивне тестування(Ad hoc testing)Модульне тестування (юніт-тестування) - тестується мінімально можливий для

тестування компонент, наприклад, окремий клас або функція. Часто модульне тестування здійснюється розробниками ПЗ.

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

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

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

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

Часто для вільного / відкритого ПЗ стадія альфа-тестування характеризує функціональне наповнення коду, а бета-тестування - стадію виправлення помилок. При цьому як правило на кожному етапі розробки проміжні результати роботи доступні кінцевим користувачам.

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

При статичному тестуванні програмний код не виконується - аналіз програми відбувається на основі початкового коду, який вичитується вручну, або аналізується спеціальними інструментами. У деяких випадках, аналізується не вихідний, а проміжний код (такий як байт-код або код на MSIL).

При тестуванні білого ящика (англ. white-box testing, також говорять - прозорого ящика), розробник тесту має доступ до вихідного коду програм і може писати код, який пов'язаний з бібліотеками тестованого ПЗ. Це типово для юніт-тестування (англ. unit testing), при якому тестуються тільки окремі частини системи. Воно забезпечує те, що компоненти конструкції - працездатні і стійкі, до певної міри. При тестуванні білого ящика використовуються метрики покриття коду або мутаційні тестування.

Примітка: До цієї практичної роботи не передбачені контрольні питання. Вони формуються на основі виконання завдання.

ЛІТЕРАТУРА:1. ISO 10014. Управление качеством — Указания по получению финансовых и экономических выгод.2. ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» (информационные технологии – жизненный цикл программного обеспечения), ГОСТ Р ИСО/МЭК 12207-99.3. Буч Г. Коналлен Д. Максимчук Р.А. Хьюстон К. Энгл М. Янг Б. Объектно-ориентированный анализ и проектирование с примерами приложений. – 3-е изд. М.: Вильямс, 2008. – 720 с.4. Гонтарев И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами. М.: Диброком, 2009. – 384 с.5. ГОСТ Р ИСО/МЭК 15288-2005. Системная инженерия. Процессы жизненного цикла систем

Практичні роботи № 6, 7, 8Тема: Вступ до технології SCRUM, RAD, RUPМета: Ознайомитись із існуючими технологіями проектування програмного забезпечення.Завдання: Зробити презентацію та реферат про кожну із означених технологій проектування програмного забезпечення. Знайти проекти, які розроблені згідно означених технологій. Розробіть власний проект за допомогою технології RAD.

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

Візьмемо такий критерій, як легкість впровадження методики в процес розробки. XP містить в собі достатньо жорсткі правила ведення проекту, які не всі розробники можуть прийняти, або просто може знадобитися тривалий час, щоб отримати від них гарну віддачу. А це ризиковано, якщо проекти не дуже великі і не розраховані хоча б на рік. Але в компанії-замовнику справи йдуть саме таким чином. Якщо впровадження методології йде важко, то велика ймовірність не вкластися в терміни і втратити великий прибуток. Природно, це неприпустимо.

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

Якщо розглядати RUP в його важкому варіанті, то він абсолютно не підходить для компанії-замовника, тому як створення занадто великого обсягу артефактів при коротких проектах - абсолютно не вигідно. Полегшений ж RUP - більш відповідний, однак для його впровадження необхідно, щоб весь керуючий персонал, включаючи менеджерів, досконально його знали, щоб процес розробки пішов у потрібному напрямку. У цьому випадку теж потрібні досить великі зусилля і деяка перебудова того процесу, який природним чином склався в компанії. Scrum ж дуже близький до існуючого на даний момент процесу замовника, тому його впровадження займе мінімум зусиль і витрат.

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

Scrum Для того щоб мати повне уявлення про обраній для компанії-замовника методології

розробки, наведемо найбільш докладний її опис. Методологія Scrum встановлює правила управління процесом розробки і дозволяє

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

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

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

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

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

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

1. Програмне забезпечення за методологією RAD Життєвий цикл програмного забезпечення за методологією RAD складається з

чотирьох фаз: • фаза аналізу і планування вимог; • фаза проектування; • фаза побудови; • фаза впровадження. На фазі аналізу і планування вимог користувачі системи визначають функції, які вона

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

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

Після детального визначення складу процесів оцінюється кількість функціональних елементів системи і приймається рішення про розділення інформаційних систем на підсистеми, піддаються реалізації однією командою розробників за прийнятний для RAD-проектів час - близько 60 - 90 днів. З використанням CASE-засобів проект розподіляється між різними командами (ділиться функціональна модель). Результатом даної фази повинні бути:

• загальна інформаційна модель системи; • функціональні моделі системи в цілому і підсистем, що реалізуються окремими

командами; • точно визначені за допомогою CASE-засоби інтерфейси між автономно

розробляються підсистемами; • побудовані прототипи екранів, звітів, діалогів. Всі моделі і прототипи повинні бути отримані із застосуванням тих CASE-засобів, які

будуть використовуватися надалі при побудові системи. Дана вимога викликано тим, що в традиційному підході при передачі інформації про

проект з етапу на етап може відбутися фактично неконтрольоване спотворення даних. Застосування єдиної середовища зберігання інформації про проект дозволяє уникнути цієї небезпеки.

1.2. Методологія RAD Один з підходів до розробки ПЗ в рамках спіральної моделі ЖЦ - одержала широке

поширення методологія швидкої розробки додатків RAD (Rapid Application Development), вона включає в себе три складові:

• невелику команду програмістів (від 2 до 10 осіб); • короткий, але ретельно пророблений виробничий графік (від 2 до 6 міс.); • повторюваний цикл, при якому розробники по мірі того, як додаток починає

набувати форму, запитують і реалізують у продукті вимоги, отримані через взаємодію з замовником.

Команда розробників повинна являти собою групу професіоналів, які мають досвід в аналізі, проектуванні, генерації коду і тестуванні ПЗ з використанням CASE-засобів, здатних добре взаємодіяти з кінцевими користувачами і трансформувати їх пропозиції в робочі прототипи.

Життєвий цикл ПЗ за методологією RAD складається з чотирьох фаз: аналізу і планування вимог; проектування; побудови; впровадження.

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

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

Після детального визначення складу процесів оцінюється кількість функціональних елементів системи і приймається рішення про поділ ІС на підсистеми, піддаються реалізації однією командою розробників за прийнятний для RAD-проектів час (60 - 90 днів). З використанням CASE-засобів проект розподіляється між різними командами (ділиться функціональна модель). Результатом даної фази повинні бути:

• загальна інформаційна модель системи; • функціональні моделі системи в цілому і підсистем, що реалізуються окремими

командами; • точно визначені за допомогою CASE-засобів інтерфейси між автономно

розробляються підсистемами; • побудовані прототипи екранів, звітів, діалогів. Всі моделі і прототипи повинні бути отримані із застосуванням тих CASE-засобів, які

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

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

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

Динамічна структура - тимчасова зміна процесу, що показує як процес, виражений у формі фаз, циклів, віх, ітерацій, розгортається в ході життєвого циклу проекту.

Фази життєвого циклу, цілі, віхи.Повний життєвий цикл розробки продукту складається з чотирьох фаз, кожна з яких

включає в себе одну або декілька ітерацій:

Початок:Цілі:1. Зрозуміти межі проекту.2. Розробити економічне обгрунтування.3. Домогтися угоди між зацікавленими сторонами для подальшого просування

проекту.Віха: LCO (LifeCycle Objective) віха життєвого циклу.Проектування:Цілі:1. Звести до мінімуму головні технічні ризики.2. Створити базову архітектуру.

3. Зрозуміти у скільки обійдеться побудова системи.Віха: LCA (LifeCycle Architecture) віха архітектури життєвого циклу.Побудова:Мета - Побудова першої версії продукту.Віха: IOC (Initial Operational Capacity) віха початкової функціональноїготовності.Впровадження:Мета - Створення остаточної версії продукту і відправлення замовнику.Віха: PR (Production Release) віха готового продукту.Кожна фаза містить одну або більше ітерацій, спрямованих на створення проміжних

компонентів системи, необхідних для досягнення бізнес-цілей даної фази. Ітерацій стільки скільки потрібно для досягнення цілей фази.

4. Статична структура RUP. Роді. Завдання. Артефакти. Процеси, Робочі процеси.

Статична структура - опис логічного групування елементів процесу (завдання, роль, артефакти) у головні дисципліни процесу.

Роль - область функціональних обов'язків компетенції та відповідальності, які повинна мати людина або група людей.

Завдання - одиниця роботи в RUP, яка може бути запропонована ролі для виконання. Час виконання коливається від кількох годин до декількох днів.

Категорії кроків завдання:1. Кроки для роздумів (визначення суті завдання, формулювання результату).2. Виконувані кроки (створення та модифікація деяких артефактів).3. Перевірочні кроки (оцінка результату за певним критерієм).Артефакт - обсяг інформації, створений, змінений або використаний процесом, що

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

роллю в процесі рішення задачі або бути результатом цього рішення.Процес - набір частково впорядкованих кроків для досягнення мети. В програмному

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

Чотири ключові частини процесу:1. Опис ролі ( «хто робить?")2. Опис артефакту ( «що робить?)3. Опис робочого процесу ( «коли робить?")4. Опис завдання ( «як робить?")Робочий процес - опис послідовності задач і їх взаємодії між ролями, що створюють

видимий результат.5. Дисципліни RUP. Додаткові елементи процесу.Дисципліна - логічна група, що складається з ролей, завдань, артефактів та інших

засобів управління процесом (концепцій, інструкцій, шаблонів).Дисципліна - Високорівневий робочий процес. Дисципліна розділяється на деталі

робочого процесу - робочі процеси всередині дисципліни.Дисципліни:1. Бізнес-моделювання - призначена для:• Розуміння структури й поводження організації замовника, її поточних проблем,

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

та розробниками;• Для визначення деяких системних вимог.2. Управління вимогами - призначена для:• Визначення функцій системи між усіма зацікавленими особами

(користувачами, розробниками, замовниками);

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

вартості розробки системи;в Визначення користувацького інтерфейсу системи.3. Аналіз і проектування - призначена для:• Побудови дизайну системи на підставі вимог до системи;• Розробки архітектури системи;• Підготовки дизайну впровадження системи.4. Реалізація - призначена для:• Визначення структури та організації вихідних кодів системи, розбитих на окремі

рівні реалізації;• Для реалізації класів і об'єктів в термінах компонентів (вихідні двійкові і виконавчі

файли);• Для модульного тестування розроблених компонентів;• Для інтеграції результатів розробки окремих компонентів у працездатну

систему.5. Впровадження - призначена для:• Для опису всіх дій, пов'язаних з доступністю кінцевого продукту для користувачів.6. Тестування - призначена для:• Перевірки якості розроблюваного продукту за допомогою спеціальних процесів;• Пошук і реєстрація дефектів;• Демонстрація достовірності зроблених на етапі проектування та збору вимог

припущень (архітектурних рішень).7. Управління проектом - призначена для:• Забезпечення розробки інструкцій з планування, підбору персоналу, виконання, і

контролю проектів (моніторингу прогресу ітеративного проекту та метрик);• Забезпечення управління ризиками.8. Управління змінами - призначена для:• Контролю змін;• Підтримання цілісності продукту і складових його артефактів.Додаткові елементи процесу:1. Інструкції - правила, рекомендації для виконання завдань, кроків і поводження з

артефактами.2. Шаблони - для різних артефактів.3. Інструкції з використання інструментальних засобів розробки.4. Основні концепції, визначення та принципи (Concepts).5. Roadmaps - графічні діаграми.

КОНТРОЛЬНІ ПИТАННЯ:Надайте стислу характеристику технологіям RAD, RUP, SCRUM. Опишіть основні недоліки та переваги технологій. Які ще технології ви знаєте? Опишіть їх. Яке програмне забезпечення відповідає технологіям RAD, RUP, SCRUM?

1. ISO 10014. Управление качеством — Указания по получению финансовых и экономических выгод.2. ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» (информационные технологии – жизненный цикл программного обеспечения), ГОСТ Р ИСО/МЭК 12207-99.3. Буч Г. Коналлен Д. Максимчук Р.А. Хьюстон К. Энгл М. Янг Б. Объектно-ориентированный анализ и проектирование с примерами приложений. – 3-е изд. М.: Вильямс, 2008. – 720 с.4. Гонтарев И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами. М.: Диброком, 2009. – 384 с.

Практична робота № 9Тема: Сучасні концепції керування якістю: проектування ПЗ з використанням концепційМета: Ознайомитись з поняттям «концепція керування», здобути навички проектування засобів для оцінки якості програмного забезпечення.Завдання: Ознайомтесь із сучасними концепціями керування якістю програмного забезпечення, на їх основі спробуйте створити власну концепцію, а сам: вигадайте назву, опишіть методи, якими будете контролювати якість. Також надайте перелік нормативної бази документів, за допомогою яких розробник зможе спроектувати ПЗ, щоб воно максимально відповідало вашій концепції. Дозволяється використовувати наробки існуючих концепцій.

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

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

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

Оцінці якості ПС присвячені державні та міжнародні стандарти, наприклад, [1, 2]. Згідно ГОСТ 28195-89, оцінка якості ПС являє собою сукупність операцій, що включає вибір номенклатури показників якості, визначення значень цих показників і порівняння їх з базовими значеннями.

Аналізуючи роботи, присвячені оцінці якості ПС, можна класифікувати існуючі підходи по природі показників якості як оцінку за внутрішніми показниками якості, оцінку за зовнішніми показниками якості і змішаний підхід.

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

Розглянемо деякі підходи, пов'язані до першого класу. Так в [3] запропонована методика, що базується на теорії динамічних систем. ПС розглядається як динамічна система, при цьому правомочним стає використання методів спектрального аналізу. Як показники якості виступають фрактальна розмірність та інформаційна ентропія, що характеризують складність програми. Істотним недоліком цієї методики оцінки якості ПС є те, що отримувана за наведеними показниками оцінка дозволяє порівнювати за якістю тільки ПС, що виконують однакові функції, наприклад, програми, написані на різних мовах високого рівня відповідно з одного специфікацією.

В [4] запропоновано визначення «хорошою» програми. На погляд його автора, хорошою програмою можна назвати тільки добротну програму. Під добротністю програми розуміється її розумна і раціональна реалізація з продуманою організацією потоків управління та інформаційних потоків. У роботі проведена класифікація критеріїв добротності програм. Наприклад, до кількісних критеріям віднесена складність програми, складність керуючого графа програми, раціональність процедурного розбиття програми, раціональність модульного розбиття програми. До генетичним критеріям добротності віднесені такі критерії як добротність технології розробки, добротність апаратури. До прагматичним критеріям віднесені цільова спрямованість, структурна доцільність, виправдана вибудуваність обчислень, обчислювальна ненадмірність, розумна організованість потоку даних.

В [5] дано розвиток метричної теорії програм Холстеда. Як показники якості ПС використовуються метрики Холстеда, для розрахунку довжини програми запропоновано використовувати модифіковану формулу Холстеда. Цю роботу можна розглядати в контексті удосконалення одного з показників якості програми. Її недоліком є те, що прогнозувати вплив довжини програми на значення спостережуваних показників якості дуже важко, а часом взагалі неможливо.

Обговоримо цей клас підходів. Загальним недоліком оцінки якості за внутрішнім показниками ПС є те, що хоча ці показники, безсумнівно, впливають на зовнішні спостережувані показники програми, але точні залежності між ними, як правило, не відомі або надзвичайно складні. Користувачів більшою мірою цікавлять саме зовнішні показники. Наприклад, якщо ПС дозволяє швидко і точно виконати необхідну функцію, то користувачеві байдуже, за допомогою якого алгоритму вона реалізована, і наскільки віртуозно написаний фрагмент тексту програми. Тому оцінку якості на основі цих підходів доцільно проводити тільки на ранніх етапах розробки ПС. Якість же готового продукту слід оцінювати з точки зору користувача, тобто на підставі зовнішніх показників. І, нарешті, оцінка на основі внутрішніх показників може бути проведена тільки при наявності лістингу програми, що значною мірою звужує можливість використання цих підходів на етапі впровадження ПС в експлуатацію.

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

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

x ij=¿ {0,если i-ая функция реализована в j-ом ПС, ¿ ¿¿¿До матриці {xij} додається стовпець у відповідності з уявленнями особи, що приймає

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

процедура повторюється до тих пір, поки не будуть відсіяні всі альтернативні ПС крім одного - результату вибору.

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

В [3] запропонована методика, рекомендована авторами для використання розробниками ПС на етапах його проектування, створення та налагодження. Методика дозволяє оцінити значення наступних факторів якості: практичність, цілісність, ефективність, коректність, безпека, надійність, зручність обслуговування, оценіваемость, гнучкість, можливість використання в інших умовах, мобільність, можливість взаємодії.

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

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

f i=∑j=1

Si

V j k j

де kj - значення j-ого показника якості, яке визначається експертно, причому kj [0;1].

Значення узагальненого показника якості ПС визначається як середнє арифметичне отриманих значень факторів якості.

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

Для того, що б підвести підсумок, наведемо основні етапи процедури оцінки якості, характерні, практично, для всіх методик і підходів.

1. Складання системи характеристик якості ПС. Як правило, ця система має вигляд ієрархічної структури. Для різних методик характерно різну кількість рівнів ієрархії, а так само різне число критеріїв кожного рівня ієрархії. Система критеріїв якості може включати як внутрішні, так і зовнішні характеристики ПС. Однак перевага слід віддавати зовнішніми характеристиками. Крім того, критерії можуть носити як кількісний, так і якісний характер. Перевагу варто віддавати кількісним характеристикам. Авторами цієї статті в [11] була запропонована методика складання ієрархічних систем характеристик якості ПС.

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

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

оцінка критеріїв цим методом неможлива, або надмірно трудомістка, то залучається експертна інформація.

4. Нормування значень одиничних показників якості. У різних методиках використовуються різні функції приведення.

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

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

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

ЛІТЕРАТУРА:1. ГОСТ 28195 - 89. Оцінка якості програмних засобів. Загальні положення. 2. ISO / IEC 9126:1991. Information technology - Software product evaluation - Quality characteristics and guidelines for their use. 3. Методи і моделі оцінювання якості програмного забезпечення. Воробйов В. І., Копильців А. В., Пальчун Б. П., Юсупов Р. М. С-Пб.: СПІІРАН.1992.-33с. 4. Поттосін І. В. «Хороша програма»: спроба точного визначення поняття / Програмування, 1997, № 2, с. 3-17. 5. Про программометріческом підході до оцінок програмного забезпечення. Апостолова Н. А., Гольдштейн Б. С., Зайдман Р. А. / Изв. Вузів. Програмування, 1995, № 4, с. 38-44. 6. Хубаев Г. Н. Економічна оцінка споживчої якості програмних засобів: Текст лекцій / РГЕА. - Ростов н / Д., 1997 - 104с. 7. Чікішева Н. М., Проскурякова Л. А. Розробка методики вибору програмного забезпечення бухгалтерського обліку для будівельних організацій. - С-Пб.: Вид-во СПбГУЕФ, 1999. -88с. 8. Елтаренко Є., Сергієвський М. Оцінка апаратних і програмних засобів за багаторівневою системою критеріїв. / Комп'ютер-прес, № 8, 1998, с. 268-272. 9. Загальна методика оцінки якості програмних засобів. Москва. 1988 10. Петров Б. Г., Шеремет В. П. Надійність і якість прогрммного забезпечення суднових СУТС (за публікаціями і досвіду розробки) / ЦНДІ «Аврора», 1992, 120с.

Практична робота № 10, 11Тема: Вступ до моделі CMMI, вступ до стандарту SPICE.Мета: Ознайомитись із основними положеннями моделі та стандарту, навчитись використовувати при проектуванні положення моделі та стандарту.Завдання: На основі існуючої моделі CMMI розробіть прототип власної моделі оцінки зрілості проекту. Дозволяється використовувати існуючи проектні рішення.

Модель Технологічної Зрілості (Capability Maturity Model Integrated, CMMI) описує шкалу з п'яти рівнів зрілості, заснованих на тому, наскільки послідовна компанія або організація в проходженні загальним повторюваним процесам при виконаємо своєї роботи. Нижній рівень шкали описує компанії без повторюваних процесів, де більша частина роботи хаотична і сумбурна. Верхній рівень описує компанії, які використовують певні і повторювані процеси, збирають метрики для безперервного поліпшення своїх процесів, а також на регулярній основі шукають творчі методи, що дозволяють працювати краще.

Перша версія моделі CMM розроблялася з 1984 по 1987 рік Уотс Хамфрі (Watts Humphrey) та Інститутом Програмної Інженерії (Software Engineering Institute, SEI). SEI є підрозділом Університету Карнегі-Меллона (Піттсбург, США). Робота спонсорувалася і продовжує спонсоруватиметься Міністерством Оборони США, яке шукало можливості порівнювати і оцінювати численних підрядників, які виконували роботи (в першу чергу, розробку програмного забезпечення) за гроші оборонного бюджету.

У наступні роки було розроблено кілька різних моделей CMM, які в 200 році були об'єднані в одну інтегровану модель CMMI ("I" якраз і означає "Integrated"). Хоча SEI продовжує покращувати і розширювати зміст, а також спектр додатків різних моделей технологічної зрілості, основним орієнтиром для більшості компаній як і раніше залишається CMMI.

Існують деякі незначні відмінності в інтерпретації СММI. Деякі компанії також розробили свої власні, приватні версії CMM. Проте, в загальному вигляді, скрізь присутні п'ять певних рівнів.

Безлад / кризу. У організації дуже мало загальних процесів. Успіх проектів повністю залежить від зусиль і досвіду Ваших співробітників. Організація мало робить для створення умов, що допомагають всі проекти робити успішними. Більшість компаній перебувають на цьому рівні, хоча деякі з них напівжартома стверджують, що вони знаходяться на нульовому або навіть на -1 рівні.

Стандартне управління проектами. Організація впровадила стандартні процеси управління проектами і використовує з у всіх проектах. Ви намагаєтеся створити базовий

фундамент, на якому збираєтеся в майбутньому будувати подальші поліпшення. Більшість компаній, що почали рух по шляху CMMI, намагаються досягти цього рівня.

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

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

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

Наскільки Ваша компанія готова вступити на шлях CMMI? Як і в багатьох інших випадках повторного використання, існують реальні вигоди від повторного використання процесів. Навіщо кожному керівнику проекту Вашої компанії ламати голову, щоб зрозуміти, як визначити проект і наскільки докладним повинен бути робочий план? Навіщо керівникам проекту "набивати шишки", щоб зрозуміти, як ефективно управляти об'ємом проекту, ризиками та якістю? Адже ці завдання абсолютно не нові, навіть всередині Вашої компанії. Тому, раціонально було б одного разу визначити відповідні процеси на рівні всієї організації, а потім багаторазово використовувати усіма керівниками проектів.

Ви можете використовувати модель CMMI в якості керівництва при впровадженні загальних процесів. При цьому не розраховуйте почати з рівня 1 і протягом року "сплигнути" на рівень 5. Шкала CMMI - це подорож. Більшість компаній тільки збираються почати рух до рівня 2. Проте, навіть такий короткий стрибок не є безболісним. У багатьох відносинах, впровадження загальних процесів управління проектами - найбільш складна частина шляху. Багато організації саме на цьому етапі сходять з дистанції через небажання частини персоналу слідувати загальним процесам. Якщо ж Ви змогли досягти рівня 2, то свідомість організації змінюється настільки, що перехід до рівня 3 дається значно легше.

Узагальнюючи, можна підсумувати, що багато компаній бачать реальну цінність для бізнесу, одержувану від якісних багаторазово використовуваних по всій організації процесів. Модель Технологічної Зрілості надає підхід, в рамках якого компанії можуть виміряти себе за стандартною шкалою від 1 до 5. Більшість компаній сьогодні знаходяться на рівні 1 і хотіли б досягти рівня 2. Більшість керівників і більшість організацій усвідомлюють, що їм слід було б мати загальні повторювані процеси. Однак, на шляху перетворень завжди стоїть хворобливість. Вона пов'язана з будь-якою спробою зміни культури в організації, коли людей просять змінити порядок, в якому вони виконують свою роботу. Тим не менш, ця болючість коштує тих значних вигод, яких Ваша компанія досягає, якщо їй вистачає сил залишатися зосередженою на перервах до тих пір, поки культурні зміни не набудуть чинності.

«Модель зрілості ОУП» встановлює вісім рівнів досконалості застосування процесів управління проектами, встановленими РМI в керівництві РМВОК *. При використанні даної моделі ОУП повинен відібрати десять найважливіших стратегічних проектів, завершених організацією протягом останніх 12 місяців. У їх число не повинні включатися перервані проекроекти. Кожен проект має бути проаналізований на відповідність вимогам, пред'явленим до нього з усіх аспектів управління, наведеними в додатку А, з метою оцінки якості його виконання.

Темпи виконання проектів також оцінюються, на основі трьох рівневого підходу до швидкості виконання - високий, середній і низький. Якщо проект реалізований за час, на 5 і більше відсотків менша встановленого графікою, то швидкість виконання такого проекту вважають високою. Якщо ж тривалість проекту виявилася більш, ніж на 5% вище планової, то швидкість його виконання вважають низькою. Коли відхилення тривалості виконання проекту від планового знаходиться в межах ± 5%, то темпи виконання такого проекту вважають середніми.

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

Аналіз процесів виконання проектів завершується виставленням оцінок рівня зрілості організації по кожному з дев'яти аспектів управління стосовно до кожного з відібраних проектів. Ці оцінки також мають три рівні - високий, середній і низький. Узагальнену оцінку рівня зрілості організації з певному аспекту управління проектами отримують шляхом усереднення оцінок за всіма проектами. Наприклад, якщо рівень зрілості управління змістом проектів визнаний середнім для 7 з 10 проектів, то узагальнений рівень зрілості підприємства з цього аспекту управління проектами вважають також середнім. Аналогічним чином оцінюють рівні зрілості по решті восьми аспектам управління проектами. Таким чином, уникають використання складного математичного апарату, такого улюбленого багатьма фахівцями. Автори вважають, що прості оцінки завжди краще.

Якщо оцінки рівня зрілості по п'яти і більше аспектам управління всіма проектами виявляються нижче «середнього», то це означає, що рівень зрілості ОУП, що знаходиться на рівні II моделі, також повинен бути визнаний нижче середнього. Для ОУП, що досяг рівня VI і вище, рівні зрілості з усіх аспектів управління повинні бути не нижче «високого». В іншому випадку, рівень зрілості такого ОУП не може бути визнаний високим. Точно також, для ОУП, що досягли рівня IV і V, оцінки рівнів зрілості за всіма дев'яти аспектам управління проектами повинні бути не нижче «середнього».

Порівнянність оцінок рівнів зрілості ОУП, що проводяться щорічно, залежить від стійкості застосовуваних критеріїв для оцінки окремих аспектів управління проектами, встановлених РМВОК *, які, як очікується, не повинні часто змінюватися.

запропонованого підхід до оцінки зрілості ОУП є простим і легким для застосування. Такі оцінки повинні проводитися регулярно, з періодичністю від 12 до 18 місяців, бажано, із залученням зовнішніх аудиторів. Доцільно, щоб ОУП доводив інформацію про результати оцінки до всіх керівників і виконавців проектів з тим, щоб вони краще розуміли необхідні і достатні умови для виконання вимог до вихідних результатами проектів.

ЛІТЕРАТУРА:1. ГОСТ 28195 - 89. Оцінка якості програмних засобів. Загальні положення. 2. ISO / IEC 9126:1991. Information technology - Software product evaluation - Quality characteristics and guidelines for their use. 3. Методи і моделі оцінювання якості програмного забезпечення. Воробйов В. І., Копильців А. В., Пальчун Б. П., Юсупов Р. М. С-Пб.: СПІІРАН.1992.-33с. 4. Поттосін І. В. «Хороша програма»: спроба точного визначення поняття / Програмування, 1997, № 2, с. 3-17. 5. Про программометріческом підході до оцінок програмного забезпечення. Апостолова Н. А., Гольдштейн Б. С., Зайдман Р. А. / Изв. Вузів. Програмування, 1995, № 4, с. 38-44. 6. Хубаев Г. Н. Економічна оцінка споживчої якості програмних засобів: Текст лекцій / РГЕА. - Ростов н / Д., 1997 - 104с. 7. Чікішева Н. М., Проскурякова Л. А. Розробка методики вибору програмного забезпечення бухгалтерського обліку для будівельних організацій. - С-Пб.: Вид-во СПбГУЕФ, 1999. -88с. 8. Елтаренко Є., Сергієвський М. Оцінка апаратних і програмних засобів за багаторівневою системою критеріїв. / Комп'ютер-прес, № 8, 1998, с. 268-272. 9. Загальна методика оцінки якості програмних засобів. Москва. 1988 10. Петров Б. Г., Шеремет В. П. Надійність і якість прогрммного забезпечення суднових СУТС (за публікаціями і досвіду розробки) / ЦНДІ «Аврора», 1992, 120с.

КРИТЕРІЇ ОЦІНЮВАННЯ ВИКОНАННЯ ТА ЗАХИСТУЛАБОРАТОРНО-ПРАКТИЧНИХ РОБІТ

Оцінка «5» (відмінно) ставиться:- коли лабораторна робота виконана згідно завдання у повному обсязі; - наведені усі необхідні програмні коди, обґрунтування, скріншоти тощо;оформлена згідно до вимог ЄГР;- при захисті студент впевнено обґрунтовано відповідає на поставлені питання і захищає виконаний звіт;- впевнено та правильно розв’язує проблемно-ситуаційні питання, обґрунтовує їх, вільно володіє термінологією з даної дисципліни.Оцінка «4» (добре) ставиться:якщо студент показує знання і ті ж вимоги, що й оцінка «5», але припускає окремі помилки, які сам же може виправити після зауважень викладача.Оцінка «3» (задовільно) ставиться:якщо студент показує знання і розуміння основних положень з даної теми, але:- припускає неточності у розрахунках, помилки при написанні програми, у формуванні визначення, рішень поставлених задач та завдань;- не досить точно може обґрунтувати відповідь;- плутається у термінології з даної дисципліни, даної теми;- захищає роботу не своєчасно.Оцінка «2» (незадовільно) ставиться:якщо студент при захисті лабораторної роботи показує незнання більшої частини теми роботи, припускає в формулюваннях та визначеннях помилки, які викривляють зміст, безладно та невпевнено викладає матеріал. Робота повертається на повторне доопрацювання з послідовним захистом.