Структура житлово-комунальних господарств

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

 

 

 

 

 

 

 

 

 

РОЗДІЛ ІІ. РОЗРОБКА СПЕЦИФІКАЦІЇ ПЗ

 

Специфікація вимог до програмного забезпечення (англ. Software Requirements Specification (SRS)) - специфікація вимог для програмної системи - це повний опис поведінки системи що розробляється. Вона включає множину прецедентів які описують всі взаємодії, які користувачі мають з програмним забезпеченням. Прецеденти також відомі як функціональні вимоги. На додачу до прецедентів SRS також включає нефункціональні (чи додаткові) вимоги. Нефункціональні вимоги є вимогами які накладають обмеження на проект, чи реалізацію (такі як вимоги інженерії продуктивності, стандарти якості, чи обмеження проектування).

Рекомендовані підходи для  специфікації вимог програмного  забезпечення описані стандартом IEEE 830-1998. Цей стандарт описує можливі  структури, бажаний вміст, і якості специфікації вимог програмного  забезпечення.

Стандарт IEEE-830-1998 описує рекомендовані принципи складання специфікації вимог до програмного забезпечення. Вона заснована на моделі, в якій результат процесу специфікації програмного забезпечення є однозначним і повним документом специфікації. Вона повинна допомогти

а) Замовникам програмного забезпечення точно описати, що вони хочуть отримати;

б) Постачальникам програмного забезпечення точно зрозуміти, що хоче замовник;

в) Окремим особам виконати наступні завдання:

1. Розробити схему стандартної специфікації програмного забезпечення (SRS) для їх власних організацій;
2. Визначити формат і зміст конкретних специфікацій вимог до програмного забезпечення;
3. Розробити додаткові допоміжні документи, такі як контрольний лист для перевірки якості SRS або довідник укладача SRS.

 

2.1 Типи вимог  SRS

Вимоги клієнтів.

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

• Вимоги експлуатації або розгортання: Де система буде використовуватися?
• Профіль місії або сценарій: Як система досягне цілей місії?
• Вимоги продуктивності: Які параметри системи є критичними для досягнення місії?
• Сценарії використання: Як різні компоненти системи повинні використовуватися?
• Вимоги ефективності: Наскільки ефективною має бути система для виконання місії?
• Експлуатаційний життєвий цикл: Як довго система буде використовуватися?
• Навколишнє середовище: Яким оточенням система повинна буде ефективно управляти?

Функціональні вимоги.

Функціональні вимоги пояснюють, що повинно  бути зроблено. Вони ідентифікують  завдання або дії, які повинні  бути виконані. Функціональні вимоги визначають дії, які система повинна бути здатною виконати, зв'язок входу / виходу в поведінці системи.

Нефункціональні вимоги.

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

Вимоги продуктивності.

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

Похідні вимоги.

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

Відомі моделі класифікації вимог  включають FURPS і FURPS+, розроблені в Hewlett-Packard.

2.2 Проблеми аналізу вимог

Проблеми  зацікавлених осіб.

Стів Макконнелл, в його книзі «Швидкий розвиток», докладно описує як користувачі можуть перешкоджати збору вимог:

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

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

Проблеми  інженерів / розробників.

Можливі проблеми, викликані інженерами та розробниками під час аналізу  вимог:

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

Вирішення проблем.

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

Методики, введені в 1990-х - прототипування, уніфікована мова моделювання (UML), сценарії використання та гнучка методологія розробки, - також призначені для вирішення описаних вище проблем.

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

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

2.3 Методи моделювання  SRS

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

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

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

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

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

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

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

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

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

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

 

 

 

 

 

 

 

 

РОЗДІЛ ІІІ. РОЗРОБКА ОБ’ЄКТНО – ОРІЄНТОВНОЇ МОДЕЛІ ПЗ НА МОВІ UML

 

3.1  Основні  відомості про мову UML

      При створенні складних інженерних систем прийнято використовувати прийоми моделювання. Складність більшості створюваних сьогодні програмних систем не поступається складності багатьом інженерним спорудженням, тому моделювання програмних систем є досить актуальним завданням. Більш того, у таких концепціях, як MDA (Model Driven Architecture - архітектура на основі моделей) і MDD (Model Driven Development - розробка на базі моделей), моделям приділяється центральна роль у процесі створення програмного продукту. Основною ідеєю цих концепцій є представлення процесу створення програмного продукту у вигляді ланцюжка трансформацій його вихідної моделі в готову програмну систему.

Майже у всіх інструментальних засобах, що втілює ідеї MDD, як мова моделювання  використовується мова UML (Unified Modeling Language - уніфікована мова моделювання), цілком або які-небудь його частини.

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

Мова UML призначена для рішення  наступних завдань:

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

2. передбачити внутрішні  механізми розширюваності й спеціалізації  базових концепцій мови;