Розробка програмного забезпечення: відмінності між версіями

[неперевірена версія][неперевірена версія]
Вилучено вміст Додано вміст
Створена сторінка: Розробка програмного забезпечення (англ. software engineering, software development) - це рід діяльності (пр...
Мітка: перше редагування
 
Немає опису редагування
Рядок 1:
[[Файл:H96566k.jpg|thumb|260px|Коли [[Грейс Хоппер]] працювала з комп'ютером [[Гарвард Марк II]] в [[Гарвардський університет|Гарвардському університеті]], її колеги виявили цю [[Міль|моль]], застряглу в [[реле]] та таким чином зашкодила роботі пристроя, після чого вона зазначила, що вони «налагоджували» (debug) систему. Таким чином почав набувати популярності термін [[Баґ|Баг]] — помилка програмного забезпечення.]]
Розробка програмного забезпечення (англ. software engineering, software development) - це рід діяльності (професія) і процес, спрямований на створення і підтримку працездатності, якості та надійності програмного забезпечення, використовуючи технології, методологію та практики з інформатики, управління проектами, математики, інженерії та інших областей знання.
{{не плутати|Програмна інженерія}}
 
'''Розробка програмного забезпечення''' (англ. {{lang-en|software engineering}}, ''software development'') - — це рід діяльності ([[професія]]) іта процес, спрямований на створення іта підтримку працездатності, якості та надійності [[програмне забезпечення|програмного забезпечення]], використовуючи технології, методологію та практики з [[інформатика|інформатики]], управління[[керування проектами]], [[математика|математики]], [[інженерія|інженерії]] та інших областей знання.
 
== Складність розробки ПЗ ==
Як ій інші традиційні інженерні дисципліни, розробка програмного забезпечення має справу з проблемами якості, вартості та надійності. Деякі програми містять мільйони [[кількість рядків коду|рядків]] [[сирцевий код|вихідного коду]], які, як очікується, повинні правильно виконуватися в умовах, що змінюються. Складність ПЗ порівнянна з складністю найбільш складних з сучасних машин, таких як літаки[[літак]]и.
 
== Розділи дисципліни ==
Розробка програмного забезпечення може бути розділена на кілька розділів. Це:
# [[Вимоги до програмного забезпечення|Вимоги до програмного забезпечення:]]: вилученнявитяг, аналіз, специфікація та ратифікація вимог для програмного забезпечення.
# [[Проектування програмного забезпечення|Проектування програмного забезпечення:]]: проектування програмного забезпечення засобами [[Автоматизованої Розробки Ррограмного ЗабеспеченняCASE|Автоматизованої Розробки Програмного Забезпечення (CASE)]] і стандарти формату описів, такі як Уніфікований Мова Моделювання ([[Unified Modeling Language|UML]]), використовуючи різні підходи: [[проблемно-орієнтоване проектування]] і  т. д..
# [[Програмна інженерія|Інженерія програмного забезпечення]]: створення програмного забезпечення за допомогою мов програмування.
# [[Тестування програмного забезпечення]]: пошук іта виправлення помилок у програмі.
# [[Обслуговування програмного забезпечення]]: програмні системи часто мають проблеми сумісності іта переносимості, а також потребують подальших модифікаціяхмодифікацій протягом довгого часу після того, як закінченастворена їх перша версія. Підобласть має справу з цими проблемами.
# Управління[[Конфігураційне керування|Керування конфігурацією програмного забезпечення]]: так якоскільки системи програмного забезпечення дуже складні іта модифікуються в процесі експлуатації, їх конфігурації повинні управлятися стандартизованим іта структурованим методом.
# Управління[[Керування розробкою програмного забезпечення]]: управліннякерування системами програмного забезпечення має запозичення з управління[[керування проектами]], але є нюанси, що не зустрічаютьсятрапляються в інших дисциплінах управліннякерування.
# [[Процес розробки програмного забезпечення]]: процес побудови програмного забезпечення гаряче обговорюється серед практиків, основними парадигмами вважаються [[Гнучка розробка програмного забезпечення|agile]] або [[Водоспадна модель|waterfall]].
# Інструменти розробки програмного забезпечення, див. [[CASE]]: методика оцінки складності системи, вибору засобів розробки іта застосування програмної системи.
# [[Якість програмного забезпечення]]: методика оцінки критеріїв якості програмного продукту іта вимог до надійності.
# [[Локалізація програмного продукту|Локалізація програмного забезпечення]], гілка мовної промисловості.
 
== Процес і методологія ==
 
Протягом кількох десятиліть стоїть завдання пошуку повторюваного, передбачуваного процесу або методології, яка б поліпшила продуктивність, якість і надійність розробки. Одні намагалися систематизувати та формалізувати цей, мабуть, малопередбачуванихмалопередбачуваний процес. Інші застосовували до нього методи управління проектами та методи [[Програмна інженерія|програмної інженерії]]. Треті вважали, що без постійного контролю з боку замовника розробка ПЗ виходить з-під контролю, з'їдаючи зайвий час і кошти.
Досвід управління розробкою програм відбивається у відповідних посібниках, звичаях і стандартах. Якщо при розробці використовується декілька стандартів і нормативних документів, то має сенс скласти [[Профіль|профіль]].
[[Інформатика]] як наукова дисципліна пропонує і використовує на базі методів структурного програмування технологію надійної розробки програмного забезпечення, використовуючи тестування програм та їх верифікацію на основі методів доказового програмування для систематичного аналізу правильності [[Алгоритм|алгоритмів]] і розробки програм без алгоритмічних помилок.
Рядок 29 ⟶ 32:
== Учасники процесу розробки ПЗ ==
 
* [[Користувач]]
* [[Замовник]]
* [[Дизайнер]]
* [[Керівник проектів|Керівник проекту]]
* [[Аналітик]]
* Тестувальник
* [[Постачальник послуг Інтернету|Постачальник]]
 
== Проблеми розробки ПЗ ==
 
Найбільш поширеними проблемами, що виникають в процесі розробки ПЗ, вважають:
* Недолік прозорості. У будь-який момент часу складно сказати, в якому стані знаходиться проект і який відсоток його завершення.  Дана проблема виникає при недостатньому плануванні структури (чи [[Архітектура|архітектури]]) майбутнього програмного продукту, що найчастіше є наслідком відсутності достатнього фінансування проекту: програма потрібна, скільки часу займе розробка, якими є етапи, чи можна якісь етапи виключити або заощадити - — наслідком цього процесу є те, що етап [[Проектування|проектування]] скорочується.
* Недолік контролю. Без точної оцінки процесу розробки зриваються графіки виконання робіт і перевищуються встановлені бюджети. Складно оцінити обсяг виконаної і залишилася роботи.
Дана проблема виникає на етапі, коли проект, завершений більш ніж наполовину, продовжує розроблятися після додаткового фінансування без оцінки ступеня завершеності проекту.
* Недолік [[Трасування (програмування)|трасування]].
* Недолік [[Моніторинг|моніторингу]]. Неможливість спостерігати хід розвитку проекту не дозволяє контролювати хід розробки в реальному часі. За допомогою інструментальних засобів менеджери проектів приймають рішення на основі даних, що надходять в реальному часі.
Дана проблема виникає в умовах, коли вартість навчання менеджменту володінню інструментальними засобами порівнянна з вартістю розробки самої програми.
* Неконтрольовані зміни. У споживачів постійно виникають нові ідеї щодо розроблюваного програмного забезпечення. Вплив змін може бути суттєвим для успіху проекту, тому важливо оцінювати пропоновані зміни та реалізовувати тільки схвалені, контролюючи цей процес за допомогою програмних засобів.
Дана проблема виникає внаслідок небажання кінцевого споживача використовувати ті чи інші програмні середовища. Наприклад, коли при створенні клієнт-серверної системи [[Споживач|споживач]] висуває вимоги не тільки до [[Операційна система|операційної системи]] на комп'ютерах-клієнтах, а й на комп'ютері-сервері.
* Недостатня [[Надійність|надійність]]. Найскладніший [[Процес|процес]] - — пошук і виправлення помилок у програмах на ЕОМ. Оскільки число помилок у програмах заздалегідь невідомо, то заздалегідь невідома і тривалість налагодження програм і відсутність гарантій відсутності помилок в програмах. Слід зазначити, що залучення доказового підходу до проектування ПЗ дозволяє виявити помилки в програмі до її виконання. У цьому напрямку багато працювали [[Кнут Лундмарк|Кнут]], [[Дейкстра Едсгер|Дейкстра]] і [[Вірт Юрій Миколайович|Вірт]]. Професор Вірт при розробці [[Паскаль Блез|Паскаля]] і [[Оберон|Оберона]]а за рахунок строгості їх синтаксису домігся математичної доказовоюдоказовості завершаемостівиконання і правильності програм, написаної на цих мовах.
Дана проблема виникає при неправильному виборі засобів розробки. Наприклад, при спробі створити програму, що вимагає коштів високого рівня, за допомогою засобів низького рівня. Наприклад, при спробі створити засоби автоматизації з СУБД на асемблері. У результаті вихідний код програми виходить занадто складним і погано піддається структуруванню.
* Неправильний вибір методології розробки програмного забезпечення. Процес вибору необхідної методології може проблемно відбитися на всіх показниках програмного забезпечення - — це його гнучкість, вартість і функціональність. Так звані гнучкі методології розробки допомагають вирішити основні проблеми, однак, варто відзначити, що і каскадна модель (waterfall) так само має свої переваги. У деяких випадках найбільш доцільним буде застосування гібридних методологій у зв'язці Agile + каскадна модель + MSF + RUP і  т. д.
* Відсутність гарантій якості і надійності програм через відсутність гарантій відсутності помилок в програмах аж до формальної здачі програм замовникам.
Дана проблема не є проблемою, що відноситься виключно до розробки ПЗ. Гарантія якості - — це проблема вибору постачальника товару (продукту).
 
== Посилання ==
* [http://www.example.org IEEE Standards Association:Software Engineering  — Descriptions]
* [http://www.example.org Інститут програмної інженерії Університету Карнегі-Меллон]
* [http://www.example.org Розробка програмного забезпечення на практиці / застосування змішаних методологій]
 
== Література ==
 
* Іан Соммервіллем Інженерія програмного забезпечення = Software Engineering.  — 6-е вид.  — М.: «Вильямс», 2002.  — С. 642.  — ISBN 5-8459-0330-0
* Джек Грінфілд, Кіт Шорт, Стів Кук, Стюарт Кент, Джон Крупи Фабрики розробки програм (Software Factories): потокова збірка типових додатків, моделювання, структури та інструменти = Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. - — М.: «Діалектика», 2006. - — С. 592. - — ISBN 978-5-8459-1181-0
 
{{Перекладена стаття|ru|Разработка программного обеспечения|Перекладено з російської Вікіпедії станом на 9 червня 2013 року.}}
 
[[Категорія:Програмна інженерія]]