Розробка програмного забезпечення: відмінності між версіями
[перевірена версія] | [перевірена версія] |
Вилучено вміст Додано вміст
Pavlo1 (обговорення | внесок) м →Проблеми розробки ПЗ: вікіфікація |
м робот косметичні зміни |
||
Рядок 25:
Протягом кількох десятиліть стоїть завдання пошуку повторюваного, передбачуваного процесу або методології, яка б поліпшила продуктивність, якість і надійність розробки. Одні намагалися систематизувати та формалізувати цей, мабуть, малопередбачуваний процес. Інші застосовували до нього методи управління проектами та методи [[Програмна інженерія|програмної інженерії]]. Треті вважали, що без постійного контролю з боку замовника розробка ПЗ виходить з-під контролю, з'їдаючи зайвий час і кошти.
Досвід управління розробкою програм відбивається у відповідних посібниках, звичаях і стандартах. Якщо при розробці використовується декілька стандартів і нормативних документів, то має сенс скласти [[
[[Інформатика]] як наукова дисципліна пропонує і використовує на базі методів структурного програмування технологію надійної розробки програмного забезпечення, використовуючи тестування програм та їх верифікацію на основі методів доказового програмування для систематичного аналізу правильності [[Алгоритм|алгоритмів]] і розробки програм без алгоритмічних помилок.
Дана [[Методологія науки|методологія]] спрямована на вирішення завдань на ЕОМ, аналогічної технології розробки алгоритмів і програм, використовуваної на олімпіадах з програмування вітчизняними студентами та програмістами з використанням тестування і структурного псевдокоду для документування програм в корпорації IBM з 70-х років.
Методологія структурного проектування програмного забезпечення може використовуватися з застосуванням самих різних мов і засобів програмування для розробки надійних програм самого різного призначення. Одним з таких проектів була розробка бортового програмного забезпечення для космічного корабля [[Буран (орбітальний корабель)|«Буран»]], в якому вперше використовувався [[
При виборі методології розробки програмного забезпечення слід керуватися тим, що складність методології порівнянна з складністю структури програмного продукту, і невиправдана для продукту даної складності складність методології тільки невиправдано збільшить вартість розробки. Прикладом сучасної методології проектування може бути проблемно-орієнтоване проектування.
Рядок 44:
Найбільш поширеними проблемами, що виникають в процесі розробки ПЗ, вважають:
* Недолік прозорості. У будь-який момент часу складно сказати, в якому стані знаходиться проект і який відсоток його завершення. Дана проблема виникає при недостатньому плануванні структури (чи [[Архітектура|архітектури]]) майбутнього програмного продукту, що найчастіше є наслідком відсутності достатнього фінансування проекту: програма потрібна, скільки часу займе розробка, якими є етапи, чи можна якісь етапи виключити або заощадити — наслідком цього процесу є те, що етап [[
* Недолік контролю. Без точної оцінки процесу розробки зриваються графіки виконання робіт і перевищуються встановлені бюджети. Складно оцінити обсяг виконаної і залишилася роботи.
Дана проблема виникає на етапі, коли проект, завершений більш ніж наполовину, продовжує розроблятися після додаткового фінансування без оцінки ступеня завершеності проекту.
Рядок 51:
Дана проблема виникає в умовах, коли вартість навчання менеджменту володінню інструментальними засобами порівнянна з вартістю розробки самої програми.
* Неконтрольовані зміни. У споживачів постійно виникають нові ідеї щодо розроблюваного програмного забезпечення. Вплив змін може бути суттєвим для успіху проекту, тому важливо оцінювати пропоновані зміни та реалізовувати тільки схвалені, контролюючи цей процес за допомогою програмних засобів.
Дана проблема виникає внаслідок небажання кінцевого споживача використовувати ті чи інші програмні середовища. Наприклад, коли при створенні клієнт-серверної системи [[
* Недостатня [[
Дана проблема виникає при неправильному виборі засобів розробки. Наприклад, при спробі створити програму, що вимагає коштів високого рівня, за допомогою засобів низького рівня. Наприклад, при спробі створити засоби автоматизації з СУБД на асемблері. У результаті вихідний код програми виходить занадто складним і погано піддається структуруванню.
* Неправильний вибір методології розробки програмного забезпечення. Процес вибору необхідної методології може проблемно відбитися на всіх показниках програмного забезпечення — це його гнучкість, вартість і функціональність. Так звані гнучкі методології розробки допомагають вирішити основні проблеми, однак, варто відзначити, що і [[Водоспадна модель|каскадна модель]] (waterfall) так само має свої переваги. У деяких випадках найбільш доцільним буде застосування гібридних методологій у зв'язці Agile + каскадна модель + MSF + RUP і т. д.
|