Знаймо

Додати знання

приховати рекламу

Цей текст може містити помилки.

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



План:


Введення

Коли Грейс Хоппер працювала з комп'ютером Гарвард Марк II в Гарвардському університеті, її колеги виявили цю моль, застряглу в реле і таким чином перешкодити роботі пристрою, після чого вона зазначила, що вони "налагоджували" (debug) систему. Таким чином почав набувати популярності термін Баг - помилка програмного забезпечення.

Розробка програмного забезпечення ( англ. software engineering , Software development) - це рід діяльності ( професія) і процес, спрямований на створення і підтримку працездатності, якості та надійності програмного забезпечення, використовуючи технології, методологію та практики з інформатики, управління проектами, математики, інженерії та інших областей знання.


1. Складність розробки ПЗ

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


2. Розділи дисципліни

Розробка програмного забезпечення може бути розділена на кілька розділів. Це:

  1. Вимоги до програмного забезпечення : витяг, аналіз, специфікація і ратифікація вимог для програмного забезпечення.
  2. Проектування програмного забезпечення : проектування програмного забезпечення коштами Автоматизованої Розробки Програмного Забезпечення (CASE) і стандарти формату описів, такі як уніфікована мова моделювання ( UML), використовую різні підходи: проблемно-орієнтоване проектування і т.д..
  3. Інженерія програмного забезпечення : створення програмного забезпечення за допомогою мов програмування.
  4. Тестування програмного забезпечення : пошук і виправлення помилок в програмі.
  5. Обслуговування програмного забезпечення: програмні системи часто мають проблеми сумісності і переносимості, а також потребують подальших модифікаціях протягом довгого часу після того, як закінчена їх перша версія. Підобласть має справу з цими проблемами.
  6. Управління конфігурацією програмного забезпечення: так як системи програмного забезпечення дуже складні і модифікуються в процесі експлуатації, їх конфігурації повинні управлятися стандартизованим і структурованим методом.
  7. Управління розробкою програмного забезпечення : управління системами програмного забезпечення має запозичення з управління проектами, але є нюанси, що не зустрічаються в інших дисциплінах управління.
  8. Процес розробки програмного забезпечення : процес побудови програмного забезпечення гаряче обговорюється серед практиків, основними парадигмами вважаються agile або waterfall.
  9. Інструменти розробки програмного забезпечення, см. CASE : методика оцінки складності системи, вибору засобів розробки і застосування програмної системи.
  10. Якість програмного забезпечення : методика оцінки критеріїв якості програмного продукту і вимог до надійності.
  11. Локалізація програмного забезпечення, гілка мовної промисловості.

3. Процес і методологія

Основна стаття: Процес розробки програмного забезпечення

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

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

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

Дана методологія спрямована на рішення задач на ЕОМ, аналогічній технології розробки алгоритмів і програм, використовуваної на олімпіадах з програмування вітчизняними студентами та програмістами з використанням тестування та структурного псевдокоду для документування програм в корпорації IBM з 70-х років.

Методологія структурного проектування програмного забезпечення може використовуватися з застосуванням самих різних мов і засобів програмування для розробки надійних програм самого різного призначення. Одним з таких проектів була розробка бортового програмного забезпечення для космічного корабля "Буран", в якому вперше використовувався бортовий комп'ютер для автоматичного управління апарату, яка вчинила успішний старт і посадку космічного корабля.

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


4. Учасники процесу розробки ПЗ

5. Проблеми розробки ПЗ

Найбільш поширеними проблемами, що виникають в процесі розробки ПЗ, вважають:

  • Брак прозорості. У будь-який момент часу складно сказати, в якому стані знаходиться проект і який відсоток його завершення.
    Дана проблема виникає при недостатньому плануванні структури (або архітектури) майбутнього програмного продукту, що найчастіше є наслідком відсутності достатнього фінансування проекту: програма потрібна, скільки часу займе розробка, якими є етапи, чи можна якісь етапи виключити або заощадити - наслідком цього процесу є те, що етап проектування скорочується.
  • Недолік контролю. Без точної оцінки процесу розробки зриваються графіки виконання робіт і перевищуються встановлені бюджети. Складно оцінити обсяг виконаної і залишилася роботи.
    Дана проблема виникає на етапі, коли проект, завершений більш ніж наполовину, продовжує розроблятися після додаткового фінансування без оцінки ступеня завершеності проекту.
  • Недолік трасування.
  • Недолік моніторингу. Неможливість спостерігати хід розвитку проекту не дозволяє контролювати хід розробки в реальному часі. За допомогою інструментальних засобів менеджери проектів приймають рішення на основі даних, що надходять у реальному часі.
    Дана проблема виникає в умовах, коли вартість навчання менеджменту володінню інструментальними засобами порівнянна з вартістю розробки самої програми.
  • Неконтрольовані зміни. У споживачів постійно виникають нові ідеї щодо розроблюваного програмного забезпечення. Вплив змін може бути суттєвим для успіху проекту, тому важливо оцінювати пропоновані зміни та реалізовувати тільки схвалені, контролюючи цей процес за допомогою програмних засобів.
    Дана проблема виникає внаслідок небажання кінцевого споживача використовувати ті чи інші програмні середовища. Наприклад, коли при створенні клієнт-серверної системи споживач пред'являє вимоги не тільки до операційній системі на комп'ютерах-клієнтах, але і на комп'ютері-сервері.
  • Недостатня надійність. Найскладніший процес - пошук і виправлення помилок в програмах на ЕОМ. Оскільки число помилок в програмах заздалегідь невідомо, то заздалегідь невідома і тривалість налагодження програм та відсутність гарантій відсутності помилок в програмах. Слід зазначити, що залучення доказового підходу до проектування ПЗ дозволяє виявити помилки в програмі до її виконання. У цьому напрямку багато працювали Кнут, Дейкстра і Вірт. Професор Вірт при розробці Паскаля і Оберона за рахунок строгості їх синтаксису домігся математичної доказовою завершаемості і правильності програм, написаної на цих мовах.
    Дана проблема виникає при неправильному виборі засобів розробки. Наприклад, при спробі створити програму, що вимагає коштів високого рівня, за допомогою засобів низького рівня. Наприклад, при спробі створити засоби автоматизації з СУБД на асемблері. В результаті вихідний код програми виходить занадто складним і погано піддається структуруванню.
  • Відсутність гарантій якості і надійності програм через відсутність гарантій відсутності помилок в програмах аж до формальної здачі програм замовникам.
    Дана проблема не є проблемою, яка відноситься виключно до розробки ПЗ. Гарантія якості - це проблема вибору постачальника товару (не продукту).

Цей текст може містити помилки.

Схожі роботи | скачати

Схожі роботи:
Бережлива розробка програмного забезпечення
Якість програмного забезпечення
Архітектура програмного забезпечення
Супровід програмного забезпечення
Впровадження програмного забезпечення
Проектування програмного забезпечення
Портування програмного забезпечення
Тестування програмного забезпечення
Локалізація програмного забезпечення
© Усі права захищені
написати до нас