Білоруський державний університет інформатики і радіоелектроніки
КАФЕДРА МЕНЕДЖМЕНТУ
РЕФЕРАТ
на тему:
"ПРОБЛЕМИ ВДОСКОНАЛЕННЯ ЯКОСТІ випускає програмне забезпечення"
МІНСЬК, 2009
Програмне забезпечення розробляють вже більше п'ятдесяти років, але до цих пір програми, що рясніють помилками, залишаються нормою, а якісні рішення - рідкісним винятком. Різноманітність дефектів разюче: від проблеми 2000 року "Все програмне забезпечення містить помилки, і кожен повинен з цим змиритися" до вад захисту, не кажучи вже про безліч катастрофічних програмних помилок. Нам слід звернутися до минулого і зрозуміти, чому до цих пір не існує загальних технологій, які дозволили би всім розробникам писати надійне програмне забезпечення з прийнятними витратами і в розумний час.
Можна виділити наступні існуючі проблеми в розробці програмного забезпечення:
Невідповідність процесів розробки ПЗ міжнародним стандартам.
Наявність помилок в інструментах, що використовуються для розробки програмних продуктів.
Стислі терміни виконання проекту.
Недостатньо досвідчені розробники ПЗ.
Різні середовища розробки ПЗ на боці розробників і замовника.
Погано організовані процеси розробки ПЗ.
Непорозуміння функціональності програми, яку бажає бачити замовник (спілкування відбувається на іноземній мові, т.к більшість замовлень надходить з-за кордону, це часто призводить до двозначного розуміння речей).
Розробка та / або тестування відбувається і на стороні аутсорсингової компанії, і на стороні замовника. Може призвести до утрудненого розумію або втрати коду як з боку розробників, так і з боку замовника.
Неможливо розібратися в проблемі не знаючи її витоків. Тому досліджуємо період зародження і розвитку програмного забезпечення, що допоможе зрозуміти існуючі проблеми в галузі вдосконалення процесу написання програм. На початку XXI століття є сенс проаналізувати минулі 50 років. Перші експерименти, які можна віднести до сучасного програмування, проводилися ще під час Другої світової війни. Але саме 50-ті роки стали першим десятиріччям розвитку програмування як галузі. За цей період, включаючи початок нового тисячоліття, буквально на наших очах кардинально змінилося коло завдань, які здатне вирішувати програмне забезпечення, та форми подання таких рішень.
У не меншому ступені змінилися методи роботи і ставлення до програмування самих розробників. Технологічні досягнення в апаратному забезпеченні, операційних системах і мовах програмування допомогли сформувати середовище розробки. Однак соціальні та економічні фактори зіграли, мабуть, більш важливу роль, оскільки саме вони визначали, яким чином галузь адаптувала ці досягнення, хто, в кінцевому підсумку, став їх використовувати, і як вони впливають (якщо впливають) на можливість створювати якісне програмне забезпечення.
Хоча повно описати останні 50 років розвитку програмного забезпечення складно, можна спробувати коротко викласти суть кожного десятиліття, аналізуючи теорію і практику розробки програмного забезпечення, зосереджуючись на принципах і тенденціях, які сформували сучасні методи створення програм. Можливо, вивчаючи рішення з минулого, як успішні, так і невдалі, ми виявимо дороговказну нитку, яка дозволить знайти спосіб поліпшити програмні системи в майбутньому.
Але у військових умовах швидкість і точність однаково важливі, а комп'ютер ENIAC Дж. Преспера Еккерта і Джона Мочлі гарантував і те, й інше. Крім того, війна відкриває фінансові можливості, яких в інших умовах може і не бути. ENIAC був більшою мірою електричної, ніж механічною машиною, використовуючи електрику не тільки для керування механічними компонентами, але і для самих обчислень. Ця машина могла не тільки породжувати результати, але й автоматично використовувати ці результати для інших обчислень. Однак ENIAC спізнився, не встигнувши вирішити ні одного завдання для військових цілей (Scott McCartney, ENIAC: The Triumphs and Tragedies of the World's First Computer, Walker and Company, New York, 1999).
Після війни комп'ютери стали застосовуватися в першу чергу саме для оборонних завдань. Вони створювалися для вирішення серйозних математичних проблем, і першими програмістами в більшості своїй були люди, які складали і виводили рівняння. Фізики та математики ретельно розробляли алгоритми. Вони готували докладну і точну документацію, аналізували вирішення своїх колег і шукали математичні докази. Ніколи більше в історії розробки програмного забезпечення до вирішення завдання програмування не підходили настільки методично.
Однак за сучасними мірками, проблеми, які вирішували ці талановиті першопрохідці, були відносно простими. З іншого боку, не можна сказати, що алгоритми та математичні обчислення були тривіальними. Але в ту епоху застосовувалися тільки самі базові команди та операції. Сучасних операційних систем з тисячами вбудованих функцій і служб тоді не існувало.
Таким чином, у 50-ті роки сверхталантлівие люди вирішували проблеми, які вони добре собі уявляли, в нескладних програмних середовищах. Іншими словами, це було десятиліття найрозумніших людей, що вирішували добре поняті завдання: запорука успіху і прекрасний шлях для формування дисципліни програмування.
У той же час, комп'ютери стали значно ефективніше і функціональніша. Коло проблем, які вони могли вирішувати, серйозно змінився як за рівнем, так і за складністю. Мови програмування також ставали могутніше і простіше в іспользованіі.60-і роки були періодом феноменального зростання комп'ютерних технологій і задали тон решти століття.
Між тим, в ці роки розвиток галузі могло піти безперспективним шляхом. Менш талановиті люди бралися за вирішення більш складних завдань. Ситуація спонукала до катастрофи, але катастрофи не сталося. Програмне забезпечення, написане в 60-х роках, відрізняється настільки ж високою якістю, що і програми, створені десятиліттям раніше.
Цей який парадокс має просте, хоча і неочевидне, пояснення. Програмісти в 60-і роки були сумлінними, а якість програм найвищим завдяки відсутності персональних засобів компіляції.
Компіляція в 60-ті роки була справою не з легких. Здебільшого компанія або університет мали тільки один величезний комп'ютер. Компілятор на цьому комп'ютері, по-перше, знаходився досить далеко від робочого місця програміста, по-друге, був настільки завантажений, що час роботи на ньому припадало резервувати заздалегідь, а, по-третє, він був украй сприйнятливий до помилок в синтаксисі і конструкціях мови програмування.
Іншими словами, компіляція недостатньо досконалої програми вимагала величезних непродуктивних витрат часу і сил, і, в результаті, могла вимагати значних переробок. Уявіть, що вам потрібно пройти декілька сотень метрів, несучи в руках стос перфокарт висотою 20 см тільки для того, щоб машина видала назад цю пачку з повідомленням про "неузгодження типів" на 30-й перфокарті. І могло виявитися так, що до компілятора в наступний раз вас допустять тільки через кілька днів, а то й тижнів.
Болісний процес компіляції змушував програмістів годинами просиджувати за робочими столами з олівцем у руках, ретельно перевіряючи свої програми, звертатися за допомогою до колег і знову читати, читати і читати свої перфокарти до тих пір, поки не будуть вичерпані всі можливі засоби їх перевірки. Ніякі заходи не здавалися зайвими, оскільки ціна недбалості була занадто висока.
Настільні обчислення перетворили комп'ютер в інструментарій, дійсно доступний для всіх, а не тільки для математиків, університетських вчених і військових. Нікому більше не доводилося годинами, днями і тижнями чекати, поки трапиться нагода скористатися компілятором, оскільки вбудований компілятор мав кожен ПК. Компілятор можна було запустити в будь-який час, коли програміст хотів швидко перевірити синтаксис. Навіщо, сидячи за столом, ретельно аналізувати кожен рядок, коли можна запустити компілятор?
Можливо подібну "лінь" програмістів стимулював той факт, що змінився і вигляд завдань, для яких створювалося програмне забезпечення. Програмісти більше не займалися кодуванням математичних алгоритмів. Вони створювали системи, які дозволяли працювати швидше і ефективніше. Вони писали програми, про які раніше не доводилося навіть мріяти.
Це була епоха, коли програмісти стали видавати помилки за особливості програм. Наївні користувачі 70-х охоче погоджувалися на складні хитрощі для того, щоб обійти помилку, якщо вірили в те, що це була "єдина можливість реалізувати необхідну функцію". Програмісти дійшли до того, що стали видавати помилки за проблеми конфігурації та операційного середовища, спровоковані самими користувачі. Користувачі ж занадто мало розуміли, що ж насправді відбувається.
Тестування стало ще однією втратою цього десятиліття хаосу. У 60-х роках компетентні розробники самі виконували весь аналіз і тестування. Але в 70-ті, коли почався бум у створенні автоматизованих рішень для нових задач (і в додаванні нових можливостей до існуючих систем), з'явився великий попит на програмістів. Тому кожен, хто хоч щось знав про програми, став займатися програмуванням, і в цьому ажіотажі про тестування просто забули.
Звичайно, організації, що займаються розробкою програмного забезпечення не намеривались зовсім відмовлятися від тестування, але багато з них віддали його на відкуп неспеціалістам, по суті перетворивши на тестувальників підсобний персонал.
Код, написаний у 70-х роках, - найгірше, що є в сучасному програмуванні. Для нього навіть існує спеціальна назва: "успадкований код". Він лякає, він заплутаний, і з ним дуже складно працювати. Більшість фахівців прагнуть всіма можливими засобами уникнути необхідності його підтримувати. Зрештою, чужий код іноді зрозуміти дуже складно, і одна помилка, зроблена в модифікованому коді, може породити непередбачувані побічні ефекти, незалежно від того, наскільки ретельно цей код протестований.
Нарешті, ще одним важливим нововведенням 70-х років стали метрики - показники, які, як передбачалося, повинні характеризувати "якісність" коду, але найчастіше їх інтерпретували занадто суб'єктивно. Десятиліття хаосу виявилося не найкращим часом для введення метрик. Ця теорія будується на кількісних аспектах вихідних текстів - числі циклів, розгалужень, умовних виразів і т.д. Замість того, щоб намагатися визначити, чи є дане програмне забезпечення функціонально коректним, розробники могли просто підрахувати кількість елементів у коді, щоб встановити його складність.
У 70-х роках це було захоплююче заняття, і, можливо, давало багатьом розробникам почуття задоволеності своїм кодом. Проте до цих пір використання метрик залишається винятком з правил. Більшість розробників ігнорують параметри, розуміючи, що хороші програмісти можуть створити дуже хороший код, у якого окремі метрики виявляться далеко не найкращими, а погані програмісти можуть написати поганий код, який за своїми метриках буде просто блискучим. Так що, на жаль, "репутація" метрик була зіпсована, оскільки спочатку вони не відображали дійсність. Гарні, сучасні метрики функціональної коректності і зараз не користуються довірою через асоціації з метриками складності коду, які були запропоновані у 70-х роках.
У цілому про це хаотичному десятилітті розвитку програмного забезпечення можна сказати, що воно було орієнтоване на код, а не на якість. До кінця 70-х стало очевидно, що зміни в галузі просто необхідні. І перша книга з тестування програмного забезпечення (Glenford Myers, The Art of Software Testing, Wiley, 1979) з'явилася в кінці саме цього десятиліття. Це був вірний ознака насуваються.
Перша така спроба набула форми засобів автоматизації розробки програм, які отримали назву CASE (computer aided software engineering). Ідея CASE полягала в тому, що програмісти могли б створювати більш якісне програмне забезпечення, якщо б у них були допоміжні програмні засоби. Кожному майстрові потрібні певні інструменти. Теслі, приміром, молотки. Спробуйте забити цвях у дошку за допомогою черевика.
Як і теслі, розробники програмного забезпечення мали свій набір основних, надійних інструментів: редактор, компілятор і відладчик. Підхід CASE дав їм можливість отримати більш досконалі інструменти, наприклад, мови четвертого покоління (для них є навіть своя абревіатура, 4GL). На жаль, 4GL і більшість інших високоякісних інструментальних засобів не виправдали покладені на них надії. Візьмемо, наприклад, Visual Basic. Усі згодні, що це корисний, потужний і популярний 4GL-інструментарій, який дозволяє збільшити продуктивність програмістів і скоротити число потенційних помилок. Проте до цих пір саму високооплачувану роботу пропонують програмістам на Сі, а переважна більшість великих прикладних систем, як і раніше пишуть на Сі (Брайан Керніган, Денніс Рітчі, "Мова програмування Сі" - Brian W. Kernighan, Dennis M. Ritchie, The C Programming Language, Prentice-Hall, 1978). За загальним визнанням, створення інструментарію 4GL і CASE було цілком виправдано, але інструментальні засоби загального призначення, такі як редактори, компілятори і відладчики, залишаються головними в побуті сучасних розробників програмного забезпечення, незважаючи на величезний інтерес до CASE, що виник на початку 80-х.
Ще одна причина того, що цей інструментарій так і не завоював широкої популярності, полягає в тому, що їх призначення як засобів, що поліпшують якість програм, грає проти них. Якщо інструментарій обіцяє значне збільшення якості продукту, чи повинен він сам бути високоякісним? Чи використовували його самі розробники інструментарію? Інструментальні засоби, що рясніють помилками, і при цьому призначені для поліпшення якості створюваних програм, навряд чи сподобаються розробникам. Не менш важливі й особисті якості людини, яка використовує такий інструментарій. Затвердження "дурень з інструментом усе одно дурень" залишається вірним і понині.
Друге важливе рішення, запропоноване в 80-х роках для створення більш якісного коду, пов'язане з використанням формальних методів. Як і у випадку з CASE, багато хто розглядав формальні методи як панацею (Richard Linger, "Cleanroom Process Model", IEEE Software, vol.11, no.2, Mar. 1994). І, як і у випадку з CASE, це рішення теоретично могло дозволити вирішити проблему, але на практиці все виявилося далеко не так.
КАФЕДРА МЕНЕДЖМЕНТУ
РЕФЕРАТ
на тему:
"ПРОБЛЕМИ ВДОСКОНАЛЕННЯ ЯКОСТІ випускає програмне забезпечення"
МІНСЬК, 2009
Програмне забезпечення розробляють вже більше п'ятдесяти років, але до цих пір програми, що рясніють помилками, залишаються нормою, а якісні рішення - рідкісним винятком. Різноманітність дефектів разюче: від проблеми 2000 року "Все програмне забезпечення містить помилки, і кожен повинен з цим змиритися" до вад захисту, не кажучи вже про безліч катастрофічних програмних помилок. Нам слід звернутися до минулого і зрозуміти, чому до цих пір не існує загальних технологій, які дозволили би всім розробникам писати надійне програмне забезпечення з прийнятними витратами і в розумний час.
Можна виділити наступні існуючі проблеми в розробці програмного забезпечення:
Невідповідність процесів розробки ПЗ міжнародним стандартам.
Наявність помилок в інструментах, що використовуються для розробки програмних продуктів.
Стислі терміни виконання проекту.
Недостатньо досвідчені розробники ПЗ.
Різні середовища розробки ПЗ на боці розробників і замовника.
Погано організовані процеси розробки ПЗ.
Непорозуміння функціональності програми, яку бажає бачити замовник (спілкування відбувається на іноземній мові, т.к більшість замовлень надходить з-за кордону, це часто призводить до двозначного розуміння речей).
Розробка та / або тестування відбувається і на стороні аутсорсингової компанії, і на стороні замовника. Може призвести до утрудненого розумію або втрати коду як з боку розробників, так і з боку замовника.
Неможливо розібратися в проблемі не знаючи її витоків. Тому досліджуємо період зародження і розвитку програмного забезпечення, що допоможе зрозуміти існуючі проблеми в галузі вдосконалення процесу написання програм. На початку XXI століття є сенс проаналізувати минулі 50 років. Перші експерименти, які можна віднести до сучасного програмування, проводилися ще під час Другої світової війни. Але саме 50-ті роки стали першим десятиріччям розвитку програмування як галузі. За цей період, включаючи початок нового тисячоліття, буквально на наших очах кардинально змінилося коло завдань, які здатне вирішувати програмне забезпечення, та форми подання таких рішень.
У не меншому ступені змінилися методи роботи і ставлення до програмування самих розробників. Технологічні досягнення в апаратному забезпеченні, операційних системах і мовах програмування допомогли сформувати середовище розробки. Однак соціальні та економічні фактори зіграли, мабуть, більш важливу роль, оскільки саме вони визначали, яким чином галузь адаптувала ці досягнення, хто, в кінцевому підсумку, став їх використовувати, і як вони впливають (якщо впливають) на можливість створювати якісне програмне забезпечення.
Хоча повно описати останні 50 років розвитку програмного забезпечення складно, можна спробувати коротко викласти суть кожного десятиліття, аналізуючи теорію і практику розробки програмного забезпечення, зосереджуючись на принципах і тенденціях, які сформували сучасні методи створення програм. Можливо, вивчаючи рішення з минулого, як успішні, так і невдалі, ми виявимо дороговказну нитку, яка дозволить знайти спосіб поліпшити програмні системи в майбутньому.
1950-1959 рр..
Програмовані комп'ютери вперше почали використовувати для вирішення військових завдань, що стояли перед США у Другій світовій війні. Такі пристрої були потрібні для самих різних цілей, від обчислення траєкторій бомб до дешифрування ворожих радіопередач. Саме війна стимулювала створення більш якісних і швидких способів обчислень. До вирішення цієї проблеми були залучені самі блискучі фахівці. Першими "комп'ютерами" були люди, головним чином жінки, яких у 40-х роках не брали в армію США. Вони складали довгі "конвеєри" з механічних рахункових машин. Уявіть собі "роботу" програми таким чином: кожна з тих, що сидять у ряд жінок, працює на своїй станції, виконуючи певну частину обчислень траєкторії бомби, і передає відповідь своїй сусідці для виконання наступного кроку.Але у військових умовах швидкість і точність однаково важливі, а комп'ютер ENIAC Дж. Преспера Еккерта і Джона Мочлі гарантував і те, й інше. Крім того, війна відкриває фінансові можливості, яких в інших умовах може і не бути. ENIAC був більшою мірою електричної, ніж механічною машиною, використовуючи електрику не тільки для керування механічними компонентами, але і для самих обчислень. Ця машина могла не тільки породжувати результати, але й автоматично використовувати ці результати для інших обчислень. Однак ENIAC спізнився, не встигнувши вирішити ні одного завдання для військових цілей (Scott McCartney, ENIAC: The Triumphs and Tragedies of the World's First Computer, Walker and Company, New York, 1999).
Після війни комп'ютери стали застосовуватися в першу чергу саме для оборонних завдань. Вони створювалися для вирішення серйозних математичних проблем, і першими програмістами в більшості своїй були люди, які складали і виводили рівняння. Фізики та математики ретельно розробляли алгоритми. Вони готували докладну і точну документацію, аналізували вирішення своїх колег і шукали математичні докази. Ніколи більше в історії розробки програмного забезпечення до вирішення завдання програмування не підходили настільки методично.
Однак за сучасними мірками, проблеми, які вирішували ці талановиті першопрохідці, були відносно простими. З іншого боку, не можна сказати, що алгоритми та математичні обчислення були тривіальними. Але в ту епоху застосовувалися тільки самі базові команди та операції. Сучасних операційних систем з тисячами вбудованих функцій і служб тоді не існувало.
Таким чином, у 50-ті роки сверхталантлівие люди вирішували проблеми, які вони добре собі уявляли, в нескладних програмних середовищах. Іншими словами, це було десятиліття найрозумніших людей, що вирішували добре поняті завдання: запорука успіху і прекрасний шлях для формування дисципліни програмування.
1960-1969 рр..
До кінця 50-х років комп'ютерів було досить мало, а в 60-і програмування стає загальнодоступним. Університети почали пропонувати навчальні програми за новою технологією, і число виробників апаратного забезпечення швидко зростало. Раптово комп'ютери, і присвячені їм навчальні курси, стали доступні всім, або, принаймні, тим, хто відвідував коледж.У той же час, комп'ютери стали значно ефективніше і функціональніша. Коло проблем, які вони могли вирішувати, серйозно змінився як за рівнем, так і за складністю. Мови програмування також ставали могутніше і простіше в іспользованіі.60-і роки були періодом феноменального зростання комп'ютерних технологій і задали тон решти століття.
Між тим, в ці роки розвиток галузі могло піти безперспективним шляхом. Менш талановиті люди бралися за вирішення більш складних завдань. Ситуація спонукала до катастрофи, але катастрофи не сталося. Програмне забезпечення, написане в 60-х роках, відрізняється настільки ж високою якістю, що і програми, створені десятиліттям раніше.
Цей який парадокс має просте, хоча і неочевидне, пояснення. Програмісти в 60-і роки були сумлінними, а якість програм найвищим завдяки відсутності персональних засобів компіляції.
Компіляція в 60-ті роки була справою не з легких. Здебільшого компанія або університет мали тільки один величезний комп'ютер. Компілятор на цьому комп'ютері, по-перше, знаходився досить далеко від робочого місця програміста, по-друге, був настільки завантажений, що час роботи на ньому припадало резервувати заздалегідь, а, по-третє, він був украй сприйнятливий до помилок в синтаксисі і конструкціях мови програмування.
Іншими словами, компіляція недостатньо досконалої програми вимагала величезних непродуктивних витрат часу і сил, і, в результаті, могла вимагати значних переробок. Уявіть, що вам потрібно пройти декілька сотень метрів, несучи в руках стос перфокарт висотою 20 см тільки для того, щоб машина видала назад цю пачку з повідомленням про "неузгодження типів" на 30-й перфокарті. І могло виявитися так, що до компілятора в наступний раз вас допустять тільки через кілька днів, а то й тижнів.
Болісний процес компіляції змушував програмістів годинами просиджувати за робочими столами з олівцем у руках, ретельно перевіряючи свої програми, звертатися за допомогою до колег і знову читати, читати і читати свої перфокарти до тих пір, поки не будуть вичерпані всі можливі засоби їх перевірки. Ніякі заходи не здавалися зайвими, оскільки ціна недбалості була занадто висока.
1970-1979 рр..
70-ті роки виявилися далеко не найкращими для поборників якості програмного забезпечення. Проблеми 60-х років - більш складні завдання і менш кваліфіковані програмісти - в 70-х роках тільки посилилися. З іншого боку, недоступна і трудомістка компіляція пішла в минуле. Поява ПК змінило правила гри, знявши обмеження, які змушували досягати високої якості програм у 60-і роки.Настільні обчислення перетворили комп'ютер в інструментарій, дійсно доступний для всіх, а не тільки для математиків, університетських вчених і військових. Нікому більше не доводилося годинами, днями і тижнями чекати, поки трапиться нагода скористатися компілятором, оскільки вбудований компілятор мав кожен ПК. Компілятор можна було запустити в будь-який час, коли програміст хотів швидко перевірити синтаксис. Навіщо, сидячи за столом, ретельно аналізувати кожен рядок, коли можна запустити компілятор?
Можливо подібну "лінь" програмістів стимулював той факт, що змінився і вигляд завдань, для яких створювалося програмне забезпечення. Програмісти більше не займалися кодуванням математичних алгоритмів. Вони створювали системи, які дозволяли працювати швидше і ефективніше. Вони писали програми, про які раніше не доводилося навіть мріяти.
Це була епоха, коли програмісти стали видавати помилки за особливості програм. Наївні користувачі 70-х охоче погоджувалися на складні хитрощі для того, щоб обійти помилку, якщо вірили в те, що це була "єдина можливість реалізувати необхідну функцію". Програмісти дійшли до того, що стали видавати помилки за проблеми конфігурації та операційного середовища, спровоковані самими користувачі. Користувачі ж занадто мало розуміли, що ж насправді відбувається.
Тестування стало ще однією втратою цього десятиліття хаосу. У 60-х роках компетентні розробники самі виконували весь аналіз і тестування. Але в 70-ті, коли почався бум у створенні автоматизованих рішень для нових задач (і в додаванні нових можливостей до існуючих систем), з'явився великий попит на програмістів. Тому кожен, хто хоч щось знав про програми, став займатися програмуванням, і в цьому ажіотажі про тестування просто забули.
Звичайно, організації, що займаються розробкою програмного забезпечення не намеривались зовсім відмовлятися від тестування, але багато з них віддали його на відкуп неспеціалістам, по суті перетворивши на тестувальників підсобний персонал.
Код, написаний у 70-х роках, - найгірше, що є в сучасному програмуванні. Для нього навіть існує спеціальна назва: "успадкований код". Він лякає, він заплутаний, і з ним дуже складно працювати. Більшість фахівців прагнуть всіма можливими засобами уникнути необхідності його підтримувати. Зрештою, чужий код іноді зрозуміти дуже складно, і одна помилка, зроблена в модифікованому коді, може породити непередбачувані побічні ефекти, незалежно від того, наскільки ретельно цей код протестований.
Нарешті, ще одним важливим нововведенням 70-х років стали метрики - показники, які, як передбачалося, повинні характеризувати "якісність" коду, але найчастіше їх інтерпретували занадто суб'єктивно. Десятиліття хаосу виявилося не найкращим часом для введення метрик. Ця теорія будується на кількісних аспектах вихідних текстів - числі циклів, розгалужень, умовних виразів і т.д. Замість того, щоб намагатися визначити, чи є дане програмне забезпечення функціонально коректним, розробники могли просто підрахувати кількість елементів у коді, щоб встановити його складність.
У 70-х роках це було захоплююче заняття, і, можливо, давало багатьом розробникам почуття задоволеності своїм кодом. Проте до цих пір використання метрик залишається винятком з правил. Більшість розробників ігнорують параметри, розуміючи, що хороші програмісти можуть створити дуже хороший код, у якого окремі метрики виявляться далеко не найкращими, а погані програмісти можуть написати поганий код, який за своїми метриках буде просто блискучим. Так що, на жаль, "репутація" метрик була зіпсована, оскільки спочатку вони не відображали дійсність. Гарні, сучасні метрики функціональної коректності і зараз не користуються довірою через асоціації з метриками складності коду, які були запропоновані у 70-х роках.
У цілому про це хаотичному десятилітті розвитку програмного забезпечення можна сказати, що воно було орієнтоване на код, а не на якість. До кінця 70-х стало очевидно, що зміни в галузі просто необхідні. І перша книга з тестування програмного забезпечення (Glenford Myers, The Art of Software Testing, Wiley, 1979) з'явилася в кінці саме цього десятиліття. Це був вірний ознака насуваються.
1980-1989 рр..
У 80-і роки були зроблені перші спроби повернути здоровий глузд розробці програмного забезпечення. Дві з них заслуговують особливої уваги.Перша така спроба набула форми засобів автоматизації розробки програм, які отримали назву CASE (computer aided software engineering). Ідея CASE полягала в тому, що програмісти могли б створювати більш якісне програмне забезпечення, якщо б у них були допоміжні програмні засоби. Кожному майстрові потрібні певні інструменти. Теслі, приміром, молотки. Спробуйте забити цвях у дошку за допомогою черевика.
Як і теслі, розробники програмного забезпечення мали свій набір основних, надійних інструментів: редактор, компілятор і відладчик. Підхід CASE дав їм можливість отримати більш досконалі інструменти, наприклад, мови четвертого покоління (для них є навіть своя абревіатура, 4GL). На жаль, 4GL і більшість інших високоякісних інструментальних засобів не виправдали покладені на них надії. Візьмемо, наприклад, Visual Basic. Усі згодні, що це корисний, потужний і популярний 4GL-інструментарій, який дозволяє збільшити продуктивність програмістів і скоротити число потенційних помилок. Проте до цих пір саму високооплачувану роботу пропонують програмістам на Сі, а переважна більшість великих прикладних систем, як і раніше пишуть на Сі (Брайан Керніган, Денніс Рітчі, "Мова програмування Сі" - Brian W. Kernighan, Dennis M. Ritchie, The C Programming Language, Prentice-Hall, 1978). За загальним визнанням, створення інструментарію 4GL і CASE було цілком виправдано, але інструментальні засоби загального призначення, такі як редактори, компілятори і відладчики, залишаються головними в побуті сучасних розробників програмного забезпечення, незважаючи на величезний інтерес до CASE, що виник на початку 80-х.
Ще одна причина того, що цей інструментарій так і не завоював широкої популярності, полягає в тому, що їх призначення як засобів, що поліпшують якість програм, грає проти них. Якщо інструментарій обіцяє значне збільшення якості продукту, чи повинен він сам бути високоякісним? Чи використовували його самі розробники інструментарію? Інструментальні засоби, що рясніють помилками, і при цьому призначені для поліпшення якості створюваних програм, навряд чи сподобаються розробникам. Не менш важливі й особисті якості людини, яка використовує такий інструментарій. Затвердження "дурень з інструментом усе одно дурень" залишається вірним і понині.
Друге важливе рішення, запропоноване в 80-х роках для створення більш якісного коду, пов'язане з використанням формальних методів. Як і у випадку з CASE, багато хто розглядав формальні методи як панацею (Richard Linger, "Cleanroom Process Model", IEEE Software, vol.11, no.2, Mar. 1994). І, як і у випадку з CASE, це рішення теоретично могло дозволити вирішити проблему, але на практиці все виявилося далеко не так.
Формальні методи представляли собою такі методики, як приховування інформації, структурне програмування і поетапне поліпшення. Ці методики, що з'явилися й стали популярними в 80-х роках, як і раніше широко застосовуються сучасними програмістами, що зайвий раз підтверджує їх успіх. Структурний програмування та орієнтація на об'єкти безсумнівно корисні для створення якісного коду. Вони зараз настільки широко застосовуються, що є скоріше правилом, ніж винятком.
Однак суворі формальні методи ніколи не будуть прийняті в провідних компаніях, що спеціалізуються на розробці програмного забезпечення. Деякі планують впровадити той чи інший варіант формальних методів (див. David P. Kelly, Robert S. Oshana, "Integrating Cleanroom Software Engineering Methods into an SEI Level 4-5 Program", Crosstalk, Nov. 1996), але переважна більшість сучасних розробників вважають їх вузькоспеціалізованими. Причини - невідповідність витрат і повернення від інвестицій. Формальні методи складно використовувати, вони дуже ресурсомісткі і часто припускають, що програміст, застосовує їх, повинен був мати мало не кандидатську ступінь. І що найголовніше, як і в 80-х роках, як і раніше не вистачає інструментальних засобів, які могли б допомогти розробникам в реалізації формальних методів.
Тим не менш, десятиріччя відродження принесло цінні ідеї, що стосуються збільшення продуктивності розробника. Крім того, вчені, невтомно створюють формальні методи, дали науковому співтовариству методики, які дозволяють систематизувати керівництво розробкою. До кінця 80-х всі усвідомили важливість практичних методів програмування, і в цілому змінилося ставлення до вимог, що гарантує більш високу якість.
Іншими словами, оскільки розробники не могли належним чином управляти своїми проектами (що історично підтверджується досить низьким рівнем якості програмного забезпечення), менеджери повинні ввести організаційний контроль. Втім, навіть найкращі в світі процеси можна неправильно реалізувати.
Незважаючи на гадану легкість тону, мова йде про дуже серйозні речі. При всій незаперечності того факту, що гарні процеси розробки програмного забезпечення, як правило, необхідні, ідея вдосконалення таких процесів передбачає формування антагоністичних відносин між керівництвом і технічними фахівцями. Ситуацію погіршує і той факт, що багато менеджерів, які нічого не знають про програмне забезпечення, раптово з'ясовують, що їхній досвід нібито досить затребуваний у програмних компаніях, де завдання вдосконалення процесів розробки ставиться на перше місце.
Процес розробки програм та їх тестування складається з наступних етапів (рис.1).
Досліджуючи наведені нижче фази розробки та впровадження програмних продуктів, а також порядок виконання активностей на описаних етапах, можна побачити такі проблеми, що виникають при неправильній організації процесу розробки програмного забезпечення:
При спілкуванні з замовником вимоги до програмного продукту були обумовлені неточно, що призводить до неправильного розуміння свого завдання програмістом.
Проведени недоскональною аналіз програмної специфікації, що в подальшому веде до величезного числа важко виправних помилок.
Стадія дизайну відсутній, що позначається на написанні коду.
Відсутні або існують неясні процеси з розробки програмного забезпечення.
Рис.1. Етапи розробки програм та їх тестування
Примітки:
Фази розробки програмного забезпечення:
Inception - Початковий етап;
Elaboration - Розробка програм, уточнення вимог до продукту;
Construction - Написання коду;
Transition - Доопрацювання програм, здача і підтримка продукту.
Дисципліни, які застосовуються на етапах розробки:
Business Modeling - Бізнес-моделювання;
Requirements - Написання та аналіз вимог;
Analysis & Design - Аналіз і дизайн коду;
Implementation - Написання коду;
Test - Тестування програм;
Deployment - Введення в дію програмного продукту;
Configuration & Change Mgmt - Аналіз конфігурації;
Project Management - Управління проектом;
Environment - Дослідження та аналіз середовища впровадження.
Тестування починається на пізніх стадіях розробки програм. У більшості випадків такі програмні продукти мають велике число дефектів та ін
Як правило, всі ці проблеми виникають через побудованих неналежним чином процесів розробки програмних додатків в аутсорсингових компаніях.
Проте розробка програмного забезпечення в основі своїй - це технічне завдання. Хороші розробники можуть створити хороше програмне забезпечення, незважаючи на погане керівництво або навіть його повна відсутність. Проте зворотне невірно: некваліфіковані технічні фахівці навряд чи розроблять гарне програмне забезпечення навіть при блискучому керівництві. Опис іншого дослідження, але з аналогічними висновками, головним чином щодо ролі керівництва у вирішенні проблеми 2000 року, можна знайти у статті Роберта Гласса (Robert Glass, "Y2K and Other Software Noncrises," IEEE Software, vol.17, no.2, Mar . 2002). Враховуючи вище викладене, CMM впроваджується повільно. У багатьох програмних компаніях розробники як і раніше не знають про її існування.
Модель CMM - це не тільки ідея вдосконалення процесів розробки, що виникла в 90-х роках. В останні роки цього десятиліття організації, що спеціалізуються на розробці програмного забезпечення, почали застосовувати ту чи іншу популярну теорію до своїх процесам. Приклад тому - Six Sigma, метод спочатку призначений для скорочення помилок при проектуванні і виробництві апаратних систем.
"Шість сигма" (Six Sigma) - це дисциплінарний, визначається даними підхід і методологія ліквідації дефектів у будь-якому процесі - від виробництва до транзакцій, від продукту до служби. Щоб досягти рівня "шести сигма", процес не повинен породжувати більше 3,4 дефектів на мільйон випадків (http://www. Isixsigma. Com / sixsigma / six_sigma. Asp).
Головний недолік методики Six Sigma, полягає в тому, що до цих пір не ясно, що означає мільйон потенційних випадків появи помилок у програмному продукті. Більш того, як це взагалі їх можна коректно підрахувати?
Ще більшого збільшення прірви, що розділяє керівництво і технічних фахівців у процесі розробки програмного забезпечення, сприяло те, що в 90-і роки досягнуто значний прогрес у розвитку обчислювальної інфраструктури. Нові операційні платформи перевершили старіші операційні системи по функціональності. Знання, які раніше були корисними, стали непотрібними. З'явилися нові мови програмування, миттєво завоювали популярність. Програмування доводилося вчитися знову і знову. Нові API для комунікацій, захисту, розподілених обчислень і, звичайно, Web, повністю перевернули життя розробників. Оскільки розробники постійно перебували в стресових умовах, тому що були змушені без кінця вивчати все нові і нові технології, у них не було часу на те, щоб слідувати конкретним стандартам на процес розробки програмного забезпечення.
На захист ідеї процесів розробки програм можна сказати, що це було абсолютно нове явище. Як і багато інші нововведення, воно не було до кінця зрозумілим, і часто його використовували невірно. Нам здається, що одна з особливостей 90-х років полягає у тому, що практика процесу розробки програм не дозволяла з легкістю підтримувати нові технології. Те, що працювало на мейнфреймах або настільних додатках, не обов'язково працює на продуктах, які швидко створюються і щогодини розгортаються в сучасному світі, де існує Internet.
Проте як це було і у випадку з його вдалими попередниками, особливу увагу до процесу розробки програм дало свій позитивний ефект. Той факт, що значно більше розробників дізналися про такі прості речі, як управління конфігуруванням, контроль помилок і аналіз за допомогою колег, безумовно, виявилося полезним.90-і роки починалися як революція процесів, а закінчилися усвідомленням того, що процес розробки не можна нав'язати людям , і навряд чи такий підхід стане популярним в найближчі роки. Більш того, безглуздо реалізовувати процес заради самого процесу. Поліпшення процесів розробки програм можливо за рахунок їх спрощення, збільшення конструктивності та використання більш якісних технічних рішень.
Нарешті, 1990-і роки ознаменували першу реальну спробу перетворити розробку програмного забезпечення в інженерну дисципліну з допомогою концепцій CBSE (component-based software engineering - "компонентна розробка програмного забезпечення") і COTS (commercial off-the-shelf - готові комерційно доступні компоненти) . Ідея полягає у створенні невеликих, високоякісних модулів і наступного їх об'єднання. Проблема, безумовно, полягає в тому, що об'єднані разом високоякісні модулі не обов'язково перетворяться на високоякісну систему. Комбінована система може виявитися нікуди непридатною через некоректну способу об'єднання, або із-за помилкових уявлень про поведінку компонентів або про середовище, в яку вони поміщаються. Більш того, COTS-компоненти, які зазвичай ліцензуються у вигляді виконуваних модулів, можуть породити неприємні побічні ефекти, невідомі одержувачу ліцензії. Подібні побічні ефекти іноді виявляються тільки при об'єднанні одних компонентів з іншими, і їх практично неможливо виявити при тестуванні кожного модуля окремо. Парадигма "розділяй і володарюй", яка виправдовує себе у випадку апаратних і фізичних систем, може виявитися згубною для систем логічних. Лише час покаже, як CBSE вплине на якість програмного забезпечення в майбутньому.
За словами Ліси Хеттон (Les Hatton, "Does OO Sync With How We Think?" IEEE Software, vol.15, no.3, May 1998), "галузевий стандарт на хороше комерційне програмне забезпечення передбачає близько 6 помилок на тисячу рядків коду при середньому показнику в 30 помилок ". Таким чином, рівень помилок останні двадцять років практично не змінюється, незважаючи на об'єктно-орієнтовану технологію, автоматичні відладчики, більш якісні засоби тестування і більш суворий контроль типів в таких мовах, як Java і Ada. Чи є підстава вважати, що в цьому десятилітті ситуація зміниться? Хоча технічні труднощі зростають, але серйозний стимул дає той факт, що витрати з-за неякісного програмного забезпечення також збільшуються. Згідно з даними звіту, опублікованого в 2002 році Національним інститутом з стандартів та технології, "обсяг економічних втрат через помилковий програмного забезпечення в США досягає мільярдів доларів на рік і становить, за деякими оцінками, близько 1% національного валового внутрішнього продукту" (Research Triangle Institute, "The Economic Impacts of Inadequate Infrastructure for Software Testing," NIST Planning Report 02-3, May 2002).
Деякі програмісти вже відмовляються від традиційних методів розробки програмного забезпечення (як одномоментних, так і поетапних) на користь методів швидкого і екстремального програмування. У своєму крайньому прояві швидка розробка - це абсолютно неструктурований, хаотичний процес, який використовує спеціалізовані методи і в якому пропускаються багато етапи планування та проектування. Хоча швидка розробка може скоротити час випуску продукції і збільшити швидкість, з якою програміст створює код, чи дозволить такий підхід збільшити якість, абсолютно не відомо.
Питання про те, що це десятиліття запропонує, поділяє "кризових спеціалістів" і тих, хто вірить, що людська винахідливість та інженерні "ноу-хау" дозволять вирішити проблему якості програмного забезпечення. Зрештою, бухгалтери розібралися з питаннями якості, літакобудівні компанії вирішили цю проблему, виробники електроприладів впоралися з таким завданням, водопровідники знайшли вихід і електрики домоглися успіху.
Розробники програмного забезпечення, як мінімум, настільки ж талановиті, як і ті, хто працює в цих галузях, тому ми впевнені, що в майбутньому з'явиться більш якісне програмне забезпечення. Ми, як спільнота, зможемо вирішити це завдання. Фактично, навіть Білл Гейтс, мабуть, усвідомив необхідність "розколоти цей міцний горішок", як він назвав проблему якості програмного забезпечення в своєму листі, розісланому, за деякими відомостями, всім співробітникам корпорації 15 січня 2002:
"Кожні кілька років я розсилаю листи, в яких розповідаю про найвищий пріоритет для Microsoft. Два роки тому це була реалізація стратегіі.net. До того було декілька листів про те, наскільки важливим є Internet для нашого майбутнього, і яким чином ми можемо зробити Internet дійсно корисним для людей. За останній рік стало ясно, що завдання превращенія.net у платформу надійних обчислень (Trustworthy Computing) - важливіше, ніж будь-яка інша частина нашої роботи. Якщо ми цього не доб'ємося, люди просто не захочуть (або не зможуть) використовувати всі інші наші досягнення. Надійні обчислення - це найвищий пріоритет для всього, що ми робимо. Ми повинні вивести галузь на абсолютно новий рівень надійності в обчисленнях ".
Так воно і є, хоча і не зрозуміло, коли вдасться цього домогтися. Коли ми отримаємо можливість створювати дійсно високоякісне програмне забезпечення? Відповідь істотно залежить від того, чи зможемо ми (і наскільки швидко) втілити в життя деякі ідеї, що виникли в минулих десятиліттях, ідеї, описані в цій статті. Кожне десятиліття формує важливі уявлення, і, хоча поки панацея так і не була знайдена, кожне з десятиліть дає відповідь на частину великого питання про якість програмного забезпечення.
Головна проблема нашої спільноти полягає в тому, що воно, без довгих роздумів, відмовляється від багатьох корисних ідей тільки тому, що жодна з них не є панацеєю. Протягом кількох десятиліть вважалося, що навіть якщо технологія збільшує ймовірність створення більш якісного забезпечення, але при цьому не гарантує створення бездоганних програм, вона ні на що не годиться. Безумовно, це не так. До тих пір, поки як спільнота професіоналів ми не станемо всерйоз займатися інтеграцією випробуваних методик минулого в нові методології збільшення якості, використовуючи їх для рішення тих же завдань, що й створюване зараз програмне забезпечення, нам доведеться ще довго чекати появи такої панацеї.
2. Бухгалтерський баланс СП ЗАТ "Научсофт" за 2007-2008 рр..
3. Посадові інструкції спеціалістів СП ЗАТ "Научсофт".
4. Донцов, Д. Як зберегти зір при роботі на комп'ютері / Д. Донцов. - СПб.: Пітер, 2007.
5. Кляузи, В.П. Безпека і комп'ютер. Норми і рекомендації щодо безпечної експлуатації обчислювальної техніки / В.П. Кляузи. - Мінськ: Видавець В.П. Кляузи, 2001.
6. Котлер, Ф. Маркетинг менеджмент: експрес-курс / Ф. Котлер, К.Л. Келлер. - 3-е вид. - СПб.: Пітер, 2007.
7. 15. Уорден, К. Нові інтелектуальні матеріали і конструкції. Властивості та застосування / К. Уорден; пер. з англ. С.Л. Баженова. - М.: Техносфера, 2006.
8. Статут СП ЗАТ "Научсофт".
9. Экономика и организация производства: Руководство по преддипломной практике и дипломному проектированию для студ. всіх форм навч. / Э.А. Афитов и др.; Под ред. В.П. Пашуто. - Мінськ: БДУІР, 2007.
Однак суворі формальні методи ніколи не будуть прийняті в провідних компаніях, що спеціалізуються на розробці програмного забезпечення. Деякі планують впровадити той чи інший варіант формальних методів (див. David P. Kelly, Robert S. Oshana, "Integrating Cleanroom Software Engineering Methods into an SEI Level 4-5 Program", Crosstalk, Nov. 1996), але переважна більшість сучасних розробників вважають їх вузькоспеціалізованими. Причини - невідповідність витрат і повернення від інвестицій. Формальні методи складно використовувати, вони дуже ресурсомісткі і часто припускають, що програміст, застосовує їх, повинен був мати мало не кандидатську ступінь. І що найголовніше, як і в 80-х роках, як і раніше не вистачає інструментальних засобів, які могли б допомогти розробникам в реалізації формальних методів.
Тим не менш, десятиріччя відродження принесло цінні ідеї, що стосуються збільшення продуктивності розробника. Крім того, вчені, невтомно створюють формальні методи, дали науковому співтовариству методики, які дозволяють систематизувати керівництво розробкою. До кінця 80-х всі усвідомили важливість практичних методів програмування, і в цілому змінилося ставлення до вимог, що гарантує більш високу якість.
1990-1999 рр..
Наступне "рішення" проблеми якості програмного забезпечення з'явилося в 90-х роках під назвою "вдосконалення процесу розробки програм". Основою цього руху була тепер популярна і часто критикована модель Capability Maturity Model. Для стислості спростимо формулювання основного принципу вдосконалення процесу розробки програм: створення програмного забезпечення - це завдання управління, до якої можна застосовувати відповідні процедури управління даними, процесами й практикою, з метою створення максимально оптимального рішення. Управління розробкою програмного забезпечення гарантує одержання більш якісного продукту.Іншими словами, оскільки розробники не могли належним чином управляти своїми проектами (що історично підтверджується досить низьким рівнем якості програмного забезпечення), менеджери повинні ввести організаційний контроль. Втім, навіть найкращі в світі процеси можна неправильно реалізувати.
Незважаючи на гадану легкість тону, мова йде про дуже серйозні речі. При всій незаперечності того факту, що гарні процеси розробки програмного забезпечення, як правило, необхідні, ідея вдосконалення таких процесів передбачає формування антагоністичних відносин між керівництвом і технічними фахівцями. Ситуацію погіршує і той факт, що багато менеджерів, які нічого не знають про програмне забезпечення, раптово з'ясовують, що їхній досвід нібито досить затребуваний у програмних компаніях, де завдання вдосконалення процесів розробки ставиться на перше місце.
Процес розробки програм та їх тестування складається з наступних етапів (рис.1).
Досліджуючи наведені нижче фази розробки та впровадження програмних продуктів, а також порядок виконання активностей на описаних етапах, можна побачити такі проблеми, що виникають при неправильній організації процесу розробки програмного забезпечення:
При спілкуванні з замовником вимоги до програмного продукту були обумовлені неточно, що призводить до неправильного розуміння свого завдання програмістом.
Проведени недоскональною аналіз програмної специфікації, що в подальшому веде до величезного числа важко виправних помилок.
Стадія дизайну відсутній, що позначається на написанні коду.
Відсутні або існують неясні процеси з розробки програмного забезпечення.
Рис.1. Етапи розробки програм та їх тестування
Примітки:
Фази розробки програмного забезпечення:
Inception - Початковий етап;
Elaboration - Розробка програм, уточнення вимог до продукту;
Construction - Написання коду;
Transition - Доопрацювання програм, здача і підтримка продукту.
Дисципліни, які застосовуються на етапах розробки:
Business Modeling - Бізнес-моделювання;
Requirements - Написання та аналіз вимог;
Analysis & Design - Аналіз і дизайн коду;
Implementation - Написання коду;
Test - Тестування програм;
Deployment - Введення в дію програмного продукту;
Configuration & Change Mgmt - Аналіз конфігурації;
Project Management - Управління проектом;
Environment - Дослідження та аналіз середовища впровадження.
Тестування починається на пізніх стадіях розробки програм. У більшості випадків такі програмні продукти мають велике число дефектів та ін
Як правило, всі ці проблеми виникають через побудованих неналежним чином процесів розробки програмних додатків в аутсорсингових компаніях.
Проте розробка програмного забезпечення в основі своїй - це технічне завдання. Хороші розробники можуть створити хороше програмне забезпечення, незважаючи на погане керівництво або навіть його повна відсутність. Проте зворотне невірно: некваліфіковані технічні фахівці навряд чи розроблять гарне програмне забезпечення навіть при блискучому керівництві. Опис іншого дослідження, але з аналогічними висновками, головним чином щодо ролі керівництва у вирішенні проблеми 2000 року, можна знайти у статті Роберта Гласса (Robert Glass, "Y2K and Other Software Noncrises," IEEE Software, vol.17, no.2, Mar . 2002). Враховуючи вище викладене, CMM впроваджується повільно. У багатьох програмних компаніях розробники як і раніше не знають про її існування.
Модель CMM - це не тільки ідея вдосконалення процесів розробки, що виникла в 90-х роках. В останні роки цього десятиліття організації, що спеціалізуються на розробці програмного забезпечення, почали застосовувати ту чи іншу популярну теорію до своїх процесам. Приклад тому - Six Sigma, метод спочатку призначений для скорочення помилок при проектуванні і виробництві апаратних систем.
"Шість сигма" (Six Sigma) - це дисциплінарний, визначається даними підхід і методологія ліквідації дефектів у будь-якому процесі - від виробництва до транзакцій, від продукту до служби. Щоб досягти рівня "шести сигма", процес не повинен породжувати більше 3,4 дефектів на мільйон випадків (http://www. Isixsigma. Com / sixsigma / six_sigma. Asp).
Головний недолік методики Six Sigma, полягає в тому, що до цих пір не ясно, що означає мільйон потенційних випадків появи помилок у програмному продукті. Більш того, як це взагалі їх можна коректно підрахувати?
Ще більшого збільшення прірви, що розділяє керівництво і технічних фахівців у процесі розробки програмного забезпечення, сприяло те, що в 90-і роки досягнуто значний прогрес у розвитку обчислювальної інфраструктури. Нові операційні платформи перевершили старіші операційні системи по функціональності. Знання, які раніше були корисними, стали непотрібними. З'явилися нові мови програмування, миттєво завоювали популярність. Програмування доводилося вчитися знову і знову. Нові API для комунікацій, захисту, розподілених обчислень і, звичайно, Web, повністю перевернули життя розробників. Оскільки розробники постійно перебували в стресових умовах, тому що були змушені без кінця вивчати все нові і нові технології, у них не було часу на те, щоб слідувати конкретним стандартам на процес розробки програмного забезпечення.
На захист ідеї процесів розробки програм можна сказати, що це було абсолютно нове явище. Як і багато інші нововведення, воно не було до кінця зрозумілим, і часто його використовували невірно. Нам здається, що одна з особливостей 90-х років полягає у тому, що практика процесу розробки програм не дозволяла з легкістю підтримувати нові технології. Те, що працювало на мейнфреймах або настільних додатках, не обов'язково працює на продуктах, які швидко створюються і щогодини розгортаються в сучасному світі, де існує Internet.
Проте як це було і у випадку з його вдалими попередниками, особливу увагу до процесу розробки програм дало свій позитивний ефект. Той факт, що значно більше розробників дізналися про такі прості речі, як управління конфігуруванням, контроль помилок і аналіз за допомогою колег, безумовно, виявилося полезним.90-і роки починалися як революція процесів, а закінчилися усвідомленням того, що процес розробки не можна нав'язати людям , і навряд чи такий підхід стане популярним в найближчі роки. Більш того, безглуздо реалізовувати процес заради самого процесу. Поліпшення процесів розробки програм можливо за рахунок їх спрощення, збільшення конструктивності та використання більш якісних технічних рішень.
Нарешті, 1990-і роки ознаменували першу реальну спробу перетворити розробку програмного забезпечення в інженерну дисципліну з допомогою концепцій CBSE (component-based software engineering - "компонентна розробка програмного забезпечення") і COTS (commercial off-the-shelf - готові комерційно доступні компоненти) . Ідея полягає у створенні невеликих, високоякісних модулів і наступного їх об'єднання. Проблема, безумовно, полягає в тому, що об'єднані разом високоякісні модулі не обов'язково перетворяться на високоякісну систему. Комбінована система може виявитися нікуди непридатною через некоректну способу об'єднання, або із-за помилкових уявлень про поведінку компонентів або про середовище, в яку вони поміщаються. Більш того, COTS-компоненти, які зазвичай ліцензуються у вигляді виконуваних модулів, можуть породити неприємні побічні ефекти, невідомі одержувачу ліцензії. Подібні побічні ефекти іноді виявляються тільки при об'єднанні одних компонентів з іншими, і їх практично неможливо виявити при тестуванні кожного модуля окремо. Парадигма "розділяй і володарюй", яка виправдовує себе у випадку апаратних і фізичних систем, може виявитися згубною для систем логічних. Лише час покаже, як CBSE вплине на якість програмного забезпечення в майбутньому.
2000-2009 рр..
У перші роки нового десятиліття ми гадаємо, що нас чекає в майбутньому. Чи зможемо ми саме в цьому десятилітті вирішити проблему якості програмного забезпечення? Чи буде це десятиліттям, коли розробники і користувачі почнуть сприймати помилку в програмному забезпеченні як щось виняткове? Або в кінці цього десятиліття ми знову станемо покладати на майбутнє ті ж надії, що і в 2000 році: "Все програмне забезпечення містить помилки, і кожен повинен з цим змиритися" (Charles C. Mann, "Why Software Is So Bad, and What Is Being Done to Fix It? "MIT Technology Rev., 17 June 2002)?За словами Ліси Хеттон (Les Hatton, "Does OO Sync With How We Think?" IEEE Software, vol.15, no.3, May 1998), "галузевий стандарт на хороше комерційне програмне забезпечення передбачає близько 6 помилок на тисячу рядків коду при середньому показнику в 30 помилок ". Таким чином, рівень помилок останні двадцять років практично не змінюється, незважаючи на об'єктно-орієнтовану технологію, автоматичні відладчики, більш якісні засоби тестування і більш суворий контроль типів в таких мовах, як Java і Ada. Чи є підстава вважати, що в цьому десятилітті ситуація зміниться? Хоча технічні труднощі зростають, але серйозний стимул дає той факт, що витрати з-за неякісного програмного забезпечення також збільшуються. Згідно з даними звіту, опублікованого в 2002 році Національним інститутом з стандартів та технології, "обсяг економічних втрат через помилковий програмного забезпечення в США досягає мільярдів доларів на рік і становить, за деякими оцінками, близько 1% національного валового внутрішнього продукту" (Research Triangle Institute, "The Economic Impacts of Inadequate Infrastructure for Software Testing," NIST Planning Report 02-3, May 2002).
Деякі програмісти вже відмовляються від традиційних методів розробки програмного забезпечення (як одномоментних, так і поетапних) на користь методів швидкого і екстремального програмування. У своєму крайньому прояві швидка розробка - це абсолютно неструктурований, хаотичний процес, який використовує спеціалізовані методи і в якому пропускаються багато етапи планування та проектування. Хоча швидка розробка може скоротити час випуску продукції і збільшити швидкість, з якою програміст створює код, чи дозволить такий підхід збільшити якість, абсолютно не відомо.
Питання про те, що це десятиліття запропонує, поділяє "кризових спеціалістів" і тих, хто вірить, що людська винахідливість та інженерні "ноу-хау" дозволять вирішити проблему якості програмного забезпечення. Зрештою, бухгалтери розібралися з питаннями якості, літакобудівні компанії вирішили цю проблему, виробники електроприладів впоралися з таким завданням, водопровідники знайшли вихід і електрики домоглися успіху.
Розробники програмного забезпечення, як мінімум, настільки ж талановиті, як і ті, хто працює в цих галузях, тому ми впевнені, що в майбутньому з'явиться більш якісне програмне забезпечення. Ми, як спільнота, зможемо вирішити це завдання. Фактично, навіть Білл Гейтс, мабуть, усвідомив необхідність "розколоти цей міцний горішок", як він назвав проблему якості програмного забезпечення в своєму листі, розісланому, за деякими відомостями, всім співробітникам корпорації 15 січня 2002:
"Кожні кілька років я розсилаю листи, в яких розповідаю про найвищий пріоритет для Microsoft. Два роки тому це була реалізація стратегіі.net. До того було декілька листів про те, наскільки важливим є Internet для нашого майбутнього, і яким чином ми можемо зробити Internet дійсно корисним для людей. За останній рік стало ясно, що завдання превращенія.net у платформу надійних обчислень (Trustworthy Computing) - важливіше, ніж будь-яка інша частина нашої роботи. Якщо ми цього не доб'ємося, люди просто не захочуть (або не зможуть) використовувати всі інші наші досягнення. Надійні обчислення - це найвищий пріоритет для всього, що ми робимо. Ми повинні вивести галузь на абсолютно новий рівень надійності в обчисленнях ".
Так воно і є, хоча і не зрозуміло, коли вдасться цього домогтися. Коли ми отримаємо можливість створювати дійсно високоякісне програмне забезпечення? Відповідь істотно залежить від того, чи зможемо ми (і наскільки швидко) втілити в життя деякі ідеї, що виникли в минулих десятиліттях, ідеї, описані в цій статті. Кожне десятиліття формує важливі уявлення, і, хоча поки панацея так і не була знайдена, кожне з десятиліть дає відповідь на частину великого питання про якість програмного забезпечення.
Головна проблема нашої спільноти полягає в тому, що воно, без довгих роздумів, відмовляється від багатьох корисних ідей тільки тому, що жодна з них не є панацеєю. Протягом кількох десятиліть вважалося, що навіть якщо технологія збільшує ймовірність створення більш якісного забезпечення, але при цьому не гарантує створення бездоганних програм, вона ні на що не годиться. Безумовно, це не так. До тих пір, поки як спільнота професіоналів ми не станемо всерйоз займатися інтеграцією випробуваних методик минулого в нові методології збільшення якості, використовуючи їх для рішення тих же завдань, що й створюване зараз програмне забезпечення, нам доведеться ще довго чекати появи такої панацеї.
Література
1. Бабук, І.М. Економіка підприємства: Учеб. посібник для студ. техн. спец. / І.М. Бабук. - Мінськ: ІОЦ Мінфіну, 2006.2. Бухгалтерський баланс СП ЗАТ "Научсофт" за 2007-2008 рр..
3. Посадові інструкції спеціалістів СП ЗАТ "Научсофт".
4. Донцов, Д. Як зберегти зір при роботі на комп'ютері / Д. Донцов. - СПб.: Пітер, 2007.
5. Кляузи, В.П. Безпека і комп'ютер. Норми і рекомендації щодо безпечної експлуатації обчислювальної техніки / В.П. Кляузи. - Мінськ: Видавець В.П. Кляузи, 2001.
6. Котлер, Ф. Маркетинг менеджмент: експрес-курс / Ф. Котлер, К.Л. Келлер. - 3-е вид. - СПб.: Пітер, 2007.
7. 15. Уорден, К. Нові інтелектуальні матеріали і конструкції. Властивості та застосування / К. Уорден; пер. з англ. С.Л. Баженова. - М.: Техносфера, 2006.
8. Статут СП ЗАТ "Научсофт".
9. Экономика и организация производства: Руководство по преддипломной практике и дипломному проектированию для студ. всіх форм навч. / Э.А. Афитов и др.; Под ред. В.П. Пашуто. - Мінськ: БДУІР, 2007.