Технологія розробки програмного забезпечення

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

 

 

 

5. Управління проектами зі створення і впровадження ПЗ

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

«Хороше управління не гарантує успішного завершення проекту, але погане управління обов'язково приведе до його провалу.»

Відмінності процесу розробки ПЗ від процесів реалізації технічних проектів:

• Програмний продукт нематеріальний.
• Не існує стандартних процесів розробки ПЗ.
• Великі програмні проекти - це часто "одноразові" проекти.

Процеси управління:

• Написання пропозицій по створенню ПЗ. Пропозиції повинні містити опис цілей проектів і способів їх досягнення. Вони також зазвичай включають оцінки фінансових і часових витрат на виконання проекту. При потребі тут можуть приводитися обґрунтування для передачі проекту на виконання сторонньою організацією або команді розробників.
• Планування і складання графіка робіт із створення ПЗ. На етапі планування проекту визначаються процеси, етапи і отримані на кожному з них результати, які повинні привести до виконання проекту. Реалізація цього плану приведе до досягнення цілей проекту. Визначення вартості проекту безпосередньо пов'язано з його плануванням, оскільки тут оцінюються ресурси, потрібні для виконання плану.
• Оцінювання вартості проекту.
• Контроль за ходом виконання робіт. Менеджер повинен постійно відстежувати хід реалізації проекту і порівнювати фактичні і планові показники виконання робіт з їх вартістю.
• Підбір персоналу. Керівники - менеджери проектів зазвичай зобов'язані самі підбирати виконавців для своїх проектів. В ідеальному випадку професійний рівень виконавців повинен відповідати тій роботі, яку вони будуть виконувати в ході реалізації проекту. Проте у багатьох випадках менеджери повинні покладатися на команду розробників, яка далека від ідеальної.
• Написання звітів і представлень. Менеджер проекту зазвичай зобов'язаний посилати звіти про хід його виконання як замовникові, так і підрядним організаціям. Це повинні бути короткі документи, які базуються на інформації, добутій із докладних звітів про проект. У цих звітах повинна бути та інформація, яка дозволяє чітко оцінити ступінь готовності створюваного програмного продукту.

 

 

6. Управління персоналом при реалізації проектів

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

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

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

Організація людської пам'яті

1. Короткочасна пам'ять з швидким доступом, але обмеженими можливостями. Доступна для обробки інформації, яка надходить.
2. Проміжна пам'ять з високими можливостями. Зберігання «короткострокової» інформації.
3. Довготривала пам'ять. Це пам'ять з найширшими можливостями, відносно важким доступом і вкрай ненадійними механізмами зберігання.

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

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

 

7. Оцінка вартості програмного продукту

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

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

 

Показник розміру

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

 

Функціональний показник

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

• Інтенсивності використання введення і виведення зовнішніх даних.
• Взаємодії системи з користувачем.
• Зовнішніх інтерфейсів.
• Файлів, які використовуються системою.

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

UFC = 2 (кількість елементів даного  типу) × (вагова величина).

Для визначення можна скористатися методом об'єктних точок.

Число об'єктних точок у програмі можна отримати шляхом попереднього підрахунку низки елементів:

• Кількість зображень на дисплеї. Прості зображення беруться за 1 об'єктну точку, зображення помірної складнощі беруться за 2 точки, а дуже складні зображення прийнято рахувати за 3 точки.
• Кількість представлених звітів. Для простих звітів призначаються 2 точки, помірно складним звітам призначається 5 точок. Написання складних звітів оцінюється в 8 точок.
• Кожен модуль на мові третього покоління рахується за 10 об'єктних точок.

Продуктивність програміста

Найважливішим чинником є індивідуальні здібності.

 

 

8. Управління якістю створених програмних систем

Якість  програмного продукту повинна відповідати деяким технічним вимогам. Тут виникає низка проблем:

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

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

1. Забезпечення якості. Визначення множини організаційних процедур і стандартів.
2. Планування якості. Виділення підмножини стандартів і процедур і їх адаптація до даного проекту.
3. Контроль якості. Проведення заходів щодо виконання нормативних процедур і стандартів якості всіма членами групи розробників.

Особливості процесу управління якістю:

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

 

 

9. Створення проекту програмної системи з використанням елементів об’єктного проектування

Основна ідея об'єктно-орієнтованого  аналізу і проектування (object-oriented analysis and design) полягає в розгляді предметної області і логічного рішення задачі з погляду об'єктів (понять і сутностей). У процесі об'єктно-орієнтованого аналізу основна увага приділяється визначенню і опису об'єктів (або понять) у термінах предметної області. У процесі об'єктно-орієнтованого проектування визначаються логічні програмні об'єкти, які будуть реалізовані засобами об'єктно-орієнтованої мови програмування. Ці програмні об'єкти включають атрибути і методи. І, нарешті, в процесі конструювання (construction) або об'єктно-орієнтованого програмування (object-oriented programming) забезпечується реалізація розроблених компонентів і класів.

 

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

• З початку проводиться так званий аналіз вимог (requirements analysis) під час якого виділяються основні процеси, які відбуваються в модельованій системі і їх формулювання у вигляді прецедентів. Прецедент (precedent) - це текстовий опис процесів, які відбуваються в предметній області.
• Крок другий. Об'єктно-орієнтований аналіз предметної області (object-oriented domain analysis). Завдання цього кроку у визначенні видів діяльності учасників процесу і складанні концептуальної моделі (conceptual model), яка відображає різні категорії елементів предметної області. Причому не тільки види діяльності учасників, але і всі поняття, які відносяться до справи.
• Крок третій. Розбираємося, хто, чим займається. Ця діяльність і називається об'єктно-орієнтованим проектуванням (object-oriented design), при якому основна увага зосереджена на розподілі обов'язків. Розподіл обов'язків (responsibility assignment) означає виділення завдань і обов'язків різних програмних об'єктів у застосуванні.

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

 

 

 

 

10. CASE-засоби автоматизації процесів створення ПЗ

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

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

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

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

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