Види програмного забезпечення Загальні вимоги до програмних систем

Курсова робота

Види програмного забезпечення. Загальні вимоги до програмних систем

Київ 2009

Зміст

1. Цілі і завдання програмної інженерії. Поняття програмного забезпечення

2. Шість принципів ефективного використання програмного забезпечення

3. Види програмного забезпечення: загальносистемне, мережеве та прикладне

4. Типи програмного забезпечення

5. Загальні вимоги до програмних систем

6. Принципи побудови програмного забезпечення

1. Цілі і завдання програмної інженерії. Поняття програмного забезпечення

Останнє десятиліття в області програмування характеризується становленням нової дисципліни - програмної інженерії (Software E ngineering), що викликано зрослими потребами:

у створенні різного виду комп'ютерних систем;

необхідністю скорочення термінів розробки;

забезпечення якості ПЗ;

оптимізації використовуваних ресурсів (фінансових і трудових).

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

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

Програмна інженерія - суворе використання інженерних, наукових і математичних принципів, методів та інструментарію для економічного створення якісного програмного забезпечення.

Програмне забезпечення (ПЗ) - це сукупність машинних програм, відповідної якісної документації, баз даних, а також технологічних процедур по експлуатації ПЗ.

Основа програмної інженерії - стандарти, методи, методології проектування і управління процесом розробки ПЗ, а також інструментально-технологічні засоби підтримки цього процесу (CASE - технології), до яких відносяться системи програмування та автоматизації різних етапів проектування та розробки ПЗ.

Верифікація - це встановлення відповідності ПЗ його специфікації.

Підтвердження - встановлення придатності або відповідності ПЗ його призначенням.

Структура цілей програмної інженерії

2. Шість принципів ефективного використання програмного забезпечення

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

Однак існує ряд компаній, які змогли по-справжньому опанувати інформаційними технологіями і отримують від них реальну користь, так як управляють своїми програмними системами приблизно так само, як і іншими важливими функціями і процесами в компанії:

забезпечуючи адміністративну підтримку на найвищому рівні,

прищеплюючи фахівцям з інформаційних технологій знання бізнес-термінології

орієнтуючи зусилля співробітників технічного відділу на досягнення конкретних бізнес-цілей.

В основі успіху впровадження ПО лежать шість перерахованих нижче принципів:

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

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

Програмна система має просту і гнучку структуру.

Будь-які розробки починають приносити користь бізнесу практично з моменту впровадження.

Проводяться планомірні і постійні покращення продуктивності програмної системи.

Відділ інформаційних технологій добре розбирається в бізнесі, а бізнес-підрозділи - у програмних системах та інформаційних технологіях.

Дуже важливо застосовувати всі ці принципи одночасно: жоден з них не принесе успіху без п'яти інших.

Таблиця 1. Контрольний список для реалізації шести принципів

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Програмна система має просту і гнучку структуру.

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

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

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

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

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

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

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

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

Будь-які розробки починають приносити користь бізнесу практично з моменту впровадження.

Майже всі компанії при розробці додатків стикаються з проблемами управління проектом.

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

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

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

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

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

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

Проводяться планомірні і постійні покращення продуктивності програмної системи

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

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

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

У багатьох відносинах управління ІТ діяльністю вимагає більше адміністративних, ніж технічних навичок.

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

Відділ інформаційних технологій добре розбирається в бізнесі, а бізнес-підрозділи - у програмних системах та інформаційних технологіях

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

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

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

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

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

3. Види програмного забезпечення: загальносистемне, мережеве та прикладне

3.1 Загальносистемне програмне забезпечення

Загальносистемне ПЗ забезпечує управління обчислювальним процесом; введенням, висновком і обробкою даних і команд користувача. До його складу входять:

операційні системи

інструментально-технологічні засоби розробки та мовні процесори

СУБД

CASE-системи та ін

3.2 Мережеве програмне забезпечення

Мережі забезпечує взаємодію локально або глобально розподілених компонентів комп'ютерної системи.

3.3 Прикладне програмне забезпечення

Прикладне ПЗ забезпечує вирішення конкретних задач користувачів і включає:

3.3.1 Незалежні програми

3.3.2 Бібліотеки підпрограм

3.3.3 Мовні процесори для вирішення спільних прикладних завдань

3.3.4 Багатофункціональні програми для вирішення обмеженого класу задач, різними алгоритмами

3.3.5 Пакети прикладних програм

Забезпечують:

рішення класу задач

вхідна мова

інформаційна модель предметної області

прикладні програми - модулі

управління обчислювальним процесом

системна і функціональна компоненти

ППП можуть бути:

методо-орієнтовані ППП

проблемно-орієнтовані ППП

модельно-орієнтовані ППП

об'єктно-орієнтовані ППП

3.3.6. Програмні системи (комплекси)

4. Типи програмного забезпечення

Тип ПЗ може бути наступним:

Розроблятися знов;

Наявне в готовому вигляді;

Програмно-апаратний (вбудоване);

Автономне.

Знову розроблювальне. Таке ПЗ вступає в процес Розробки Із самого початку І для нього повінні буті розглянуті Усі Вимоги задовольняють процесу.

Наявний в готовому вігляді.

Готове ПЗ Може вікорістовуватіся одним з Наступний способів.

Використання ПЗ точно в тому віді як воно є. Таке ПЗ Вже спроектоване, закодоване І тестоване. Додаткова Тестування Може знадобітіся з урахуванням таких чінніків Як крітічність І історія використання. Це ПЗ входити у процес Розробки НЕ пізніше кваліфікаційного Тестування. Повна процес Розробки Може віявітіся зайвих. Повінні буті оцінені працездатність, документація, Право власності І подальшої підтрімкі ПЗ.

Використання готового ПЗ без модіфікації, но Зі зміною параметрів конфігурації додатка (наприклад, формату дати, валюти або розміру сторінки). Таке ПЗ входити у процес Розробки, коли компоненти ПЗ тестуються й інтегруються після відповідної Перелік нормативних параметрів. Повна процес Розробки Може віявітіся зайвих. Повінні буті оцінені працездатність, документація, Право власності І подальшої підтрімкі ПЗ.

Модіфікація готового ПЗ (наприклад, Зміна формату звітів або доробки документації). У процес Розробки входити на етапі кодування І Тестування ПЗ. Повінні буті оцінені працездатність, документація, Право власності І подальшої підтрімкі ПЗ.

Вмонтоване ПЗ.

ПЗ або програмно-апаратні засоби вбудовуються в систему. Оскількі таке ПЗ є частина Великої системи, Усі дії рівня системи в процесі Розробки повінні буті враховані. ЯКЩО ПЗ або програмно-апаратні засоби НЕ вімагають подальшої модіфікації, то треба намагався досліджуваті питання про обсягах необхідної документації.

Автономне ПЗ. Оскількі таке ПЗ не є частина системи, Усі дії рівня системи з процесу Розробки мо-жуть буті віключені. Необхідно розглянуті потреби в документації, особливо для супроводу системи.

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

Чім більше система поклади від того чи правильно працює ПЗ І чи закінчена Його розробка Вчасно, тім більше гласності І контролю Необхідно. З іншої стороні надмірній контроль у тих випадка коли В ньому Ні необхідності, є неєфективний.

Розробка ПЗ Може буті сполучена з технічнім ризико. ЯКЩО вікорістовується незріла технологія розробка, ЯКЩО розроблювальне ПЗ НЕ МАЄ прецедентів або Дуже складне, ЯКЩО до ПЗ подаються спеціфічні Вимоги по БЕЗПЕЦІ, захіщеності, тоді Потрібні Дуже ретельні спеціфікації, проектування, Тестування й Оцінка. У цьому випадка мо-жуть буті Важливі незалежна веріфікація І валідація.

5. Загальні вимоги до програмних систем

5.1. Максимум зручностей користувача

спілкування мовою, близькому до природного

наочне представлення даних, можливість редагування

швидкість ознайомлення з роботою, легкість освоєння

відсутність жорстких обмежень на структуру та обсяг вихідних даних

доступність спілкування

можливість адаптації до вимог користувача

повнота і доступність програмної документації

5.2. Адаптованість ПЗ - пристосованість до функціонування в різних умовах

5.3. Гнучкість - можливість легко вводити зміни, доповнення та виправлення до ПЗ

5.4. Мобільність - переносимість на різні обчислювальні платформи та операційні середовища

5.5. Масштабованість, розширюваність і модифікованості

5.6. Ефективність роботи

6. Принципи побудови програмного забезпечення

6.1. Модульність ПЗ - проведення декомпозиції алгоритмів і програм на модулі з метою виділення загальних типових функцій і компонентів.

6.2. Інтелектуальність ПЗ - наявність знань про предметну область і вміння використовувати їх при вирішенні завдань.

6.3. Чорний ящик - ПЗ повинно приховувати від користувачів складний механізм організації та взаємодії програм.

6.4. Умовчання - замовчування одного разу заданих параметрів, якщо вони мають сенс в інших аналогічних задачах.

7. Критичні питання процесу розробки програмного забезпечення

Якість

Людям властиво помилятися. Кожна помилка, коли вона знайдена, є сюрпризом, виправлення якого або дорого коштує, або вибиває з ритму розробки.

Якщо контроль якості в організації ослаблений, потрібно запланувати в самому процесі розробки ряд інспекцій проектної документації та інспекцій кодів, розробляючи плани якості, систему вимірювань, програму тестування, тобто більш інтенсивну роботу з підтвердження якості програмного забезпечення (Software Quality Assurance).

Продуктивність технології.

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

Нестабільність (мінливість) вимог.

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

Існують три основні типи змін вимог.

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

Нестабільні вимоги. У той час як загальні вимоги відомі, зокрема продовжують "плавати". У бортових системах, для яких hardware і software часто проектується одночасно, зміни в hardware призводять до зміни вимог до програмного забезпечення. Зміна hardware, що диктуються програмними змінами, є нонсенсом, аналогічним вимогам поміняти фундамент при спорудженні будівлі. Тим не менш, з даним явищем можна боротися шляхом передбачення нестабільностей та ізоляції їх.

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

Складність.

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

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

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