Навіщо нам потрібна розробка програмного забезпечення?

Автор: | 24 апреля, 2017

Щоб зрозуміти необхідність розробки програмного забезпечення, ми повинні коротко зупинитися, щоб озирнутися на новітню історію обчислень. Ця історія допоможе нам зрозуміти проблеми, які стали очевидними наприкінці 60-х — початку 70-х років, і рішення, які призвели до створення області розробки програмного забезпечення. Деякі назвали ці проблеми «Криза програмного забезпечення», названий так для симптомів проблеми. Ситуацію можна було б також назвати «бар'єром складності», названої так для основної причини проблем. Дехто ставиться до програмного кризи в минулому часі. Криза ще далека від завершення, але завдяки розробці багатьох нових методів, які тепер включені в заголовок програмного забезпечення, ми домоглися і продовжуємо домагатися прогресу.

В перші дні обчислень Першочерговим завданням було створення або придбання обладнання. Майже очікувалося, що програмне забезпечення подбає про себе. На загальну думку, «апаратне забезпечення» «складно» змінити, в той час як «програмне забезпечення» є «м'яким» або легко мінливим. Відповідно до цього більшість людей в галузі ретельно планував розробку апаратного забезпечення, але значно менше передбачено програмне забезпечення. Якби програмне забезпечення не працювало, на їхню думку, було б легко змінити його, поки воно не спрацює. В такому випадку навіщо прикладати зусилля для планування?

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

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

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

Розгляньте цю аналогію: тесля може працювати один, щоб побудувати простий будинок для себе, не більше ніж із загальною концепцією плану. Він або вона могли б щось змінити або внести корективи в ході роботи. Саме так були написані ранні програми. Але якщо будинок складніший, або якщо він побудований для кого-то другого, тесля повинен більш ретельно планувати, як будинок повинен бути побудований. Плани повинні бути переглянуті з майбутнім власником до початку будівництва. І якщо будинок повинен бути побудований багатьма теслями, весь проект обов'язково повинен бути спланований до початку роботи, так що, коли один тесля будує одну частину будинку, інший не будує іншу сторону іншого будинку. Планування стає ключовим елементом, тому цементні підрядники виливають стіни підвалу до того, як теслі почнуть обрамлення. Оскільки будинок стає більш складним, і необхідно скоординувати роботу більшого числа людей, потрібні креслення і плани управління.

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

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

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

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

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

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

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

На жаль, до декількох років тому не існувало хорошого методу уявлення, щоб описувати задовільно складні системи, як ті, які розробляються Вчора. Єдине гарне уявлення про те, як буде виглядати продукт, — це сам готовий продукт. Розробники не могли показати клієнтам, що вони планують. І клієнти не могли зрозуміти, чи було програмне забезпечення тим, чого вони хотіли, поки воно не було остаточно побудовано. Тоді це було дуже дорого, щоб змінитися.

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

Крім того, важливо, щоб ця мова була простим, щоб його можна було швидко вивчити.


1web hosting