Відповіді Булаченко
Інженерія програмного забезпечення(англ. Software Engineering) - додаток систематичного, дисциплінного, вимірного підходу до розвитку, оперування та обслуговування програмного забезпечення, а також дослідження цих підходів; тобто додаток дисципліни інженерії до програмного забезпечення.
Програмна інженерія- це інтегрування принципів математики, інформатики та комп'ютерних наук з інженерними підходами, розробленими для виробництва відчутних матеріальних артефактів. Також програмна інженерія визначається як системний підхід до аналізу, проектування, оцінки, реалізації, тестування, обслуговування та модернізації програмного забезпечення, тобто застосування інженерії до розробки програмного забезпечення.
Дисципліна програмної інженерії включаєтьсяу коло питань комп'ютингу (англ. computing) і може розглядатися як інженерна область, яка має тісніші зв'язки зі своєю базовою дисципліною — комп'ютерними науками, — ніж інші інженерні галузі. Серед інших інженерних дисциплін вона якісно вирізняється нематеріальністю програмного забезпечення та дискретною природою його функціонування. Ґрунтуючись на математиці та комп'ютингу, програмна інженерія займається розробкою систематичних моделей та надійних методів виробництва високоякісного програмного забезпечення, і цей підхід поширюється на всі рівні — від теорії та принципів до реальної практики створення програмного забезпечення, яка найкраще помітна стороннім спостерігачам.
Термін "розробка програмного забезпечення" є більш загальним і часто використовується, порівняно з терміном "програмна інженерія" і не обов'язково включає парадигми інженерії. Однак навряд чи можна сказати, що використанняцього методу зробило скільки-небудь відчутний внесок у розвиток реальної розробки програмного забезпечення протягом вже більш ніж 40 років.
Коли перші сучасні цифрові комп'ютери з'явилися на початку 1940-х років, набори команд, що виконуються, вже були вбудовані в машину. Фахівці швидко зрозуміли, що цей підхід не надто зручний. Так з'явилася «архітектура програм, що зберігаються» або архітектура фон Неймана. Таким чином, поділ на «залізо» та «програмне забезпечення» розпочався з абстракції, яка використовується для вирішення проблеми складності обчислень.
Перші мови програмування почали з'являтися у 1950-х роках, і це був ще один важливий крок у абстракції. Основні мови, такі як Фортран, Алгол та Кобол були випущені в кінці 1950-х для вирішення наукових, алгоритмічних та бізнес-завдань відповідно. Дейкстра написав свою відому статтю, "Go To Statement Considered Harmful" у 1968 році, а Девід Парнас ввів ключове поняття модульності та приховання інформації в 1972 році, щоб допомогти програмістам справлятися з більш складними програмними системами. Системне програмне забезпечення для керування апаратним, назване «операційна система» було представлене компанією Unix у 1969 році. У 1967 році мова Сімула запровадила поняття об'єктно-орієнтованої парадигми програмування.
Ці досягнення в галузі програмного забезпечення були зустрінуті великим проривом комп'ютерної техніки. У 1970-х років було представлено мікрокомп'ютер, що дозволило любителям отримати власний комп'ютер і писати свої програми йому. Це, у свою чергу, призвело до появи персональних комп'ютерів (ПК) і Microsoft Windows. Також у середині 1980-х з'являються такі поняття як життєвий цикл програмного забезпечення як деякий консенсус для централізованоїрозроблення програмного забезпечення. Кінець 1970-х і початок 1980-х років ознаменувалися появою кількох нових симула-подібних об'єктно-орієнтованих мов програмування, у тому числі Smalltalk, Objective-C та C++.
Відкрите програмне забезпечення, що з'явилося на початку 1990-х, затвердило децентралізований стиль розробки програмного забезпечення. Потім світове павутиння та стрімка популяризація інтернету в середині 1990-х змінили програмну інженерію ще раз. Розподілені системи набули широкого поширення, як спосіб улаштування систем, а також мова Java з його власною віртуальною машиною, зробили ще один крок в абстракції. Співпраця програмістів дозволила з'явитися на світ документу, названому Agile Manifesto, який підтримував полегшення процесів, що сприяло написанню більш дешевих та регулярно оновлюваних програм.
CASE(англ.Computer-Aided Software Engineering) — набір інструментів та методів програмної інженерії для проектування програмного забезпечення, який допомагає забезпечити високу якість програм, відсутність помилок та простоту в обслуговуванні програмних продуктів.
Також підCASEрозуміють сукупність методів та засобів проектування інформаційних систем з використанням CASE-інструментів.
Зазвичай доCASE-засобіввідносять будь-який програмний засіб, що автоматизує ту чи іншу сукупність процесів життєвого циклу ПЗ і володіє наступними основнимихарактернимиособливостями:
потужні графічні засоби для опису та документування ІВ, що забезпечують зручний інтерфейс з розробником та розвивають його творчі можливості;
інтеграція окремих компонентів CASE-засобів, що забезпечує керованість процесом розробки ІВ;
використання спеціальним чином організованого сховища проектних метаданих (репозиторія).
ІнтегрованийCASE-засіб(або комплекс засобів, що підтримують повний ЖЦ ПЗ)містить наступні компоненти;
репозиторій, що є основою CASE-кошти. Він повинен забезпечувати зберігання версій проекту та його окремих компонентів, синхронізацію надходження інформації від різних розробників при груповій розробці, контроль метаданих на повноту та несуперечність;
графічні засоби аналізу та проектування, що забезпечують створення та редагування ієрархічно пов'язаних діаграм (DFD, ERD та ін), що утворюють моделі ІВ;
засоби розробки додатків, включаючи мови 4GL та генератори кодів;
засоби конфігураційного управління;
засоби управління проектом;
У однорідних ІС, що спочатку існували, кожен додаток являв собою єдине ціле. Для розробки такого типу програм застосовувався каскадний спосіб. Його основною характеристикою є розбиття всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершено роботу на поточному (рис. 2). Кожен етап завершується випуском повного комплекту документації, достатньої для того, щоб технологія могла бути продовжена командою фахівців на наступному етапі.
Мал. 2. Каскадна схема розробки ПО
Позитивні сторони застосування каскадного підходу полягають у наступному:
на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти та узгодженості;
етапи робіт, що виконуються в логічній послідовності, дозволяють планувати терміни завершення всіх робіт і відповідні витрати.
Мал. 3. Реальний процес розробки ПЗ за каскадною схемою
Основним недоліком каскадного підходу є суттєве запізнення з одержанням результатів. Узгодження результатів з користувачами здійснюється тільки в точках, що плануються після завершення кожного етапу робіт, вимоги до ІС “заморожені” у вигляді технічного завдання на весь час її створення. Таким чином, користувачі можуть зробити свої зауваження тільки після того, як робота над системою буде повністю завершена. У разі неточного викладу вимог або їх зміни протягом тривалого періоду створення ПЗ, користувачі отримують систему, яка не задовольняє їх потребам. Моделі (як функціональні, так і інформаційні) об'єкта, що автоматизується, можуть застаріти одночасно з їх затвердженням.
Еволюційна модель розробки
Прототипування. Тут метою процесу еволюційної розробки ПЗ є поетапне уточнення вимог замовника і, отже, отримання закінченої специфікації, що визначає систему, що розробляється. Прототип зазвичай будується для експериментування з частиною вимог замовника, які сформовані нечітко чи з внутрішніми протиріччями.
Еволюційний підхід часто ефективніший, ніж підхід, побудований на основі каскадної моделі, особливо якщо вимоги замовника можуть змінюватися в процесі розробки системи. Перевагою процесу створення ПЗ, побудованого на основі еволюційного підходу, є те, що тут специфікація може розроблятися поступово, у міру того, як замовник (або користувачі) усвідомлює та сформулює транспортні засоби, які має вирішувати програмне забезпечення. Водночас цей підхід має і деякі недоліки.
Багато етапів процесу створення ПЗне документовані. Менеджерам проекту створення програмного забезпечення необхідно регулярно документально відстежувати виконання робіт. Але якщо система розробляється швидко, економічно не вигідно документувати кожну версію системи.
Система часто виходить погано структурованою. Постійні зміни у вимогах призводять до помилок та упущень у структурі ПЗ. Згодом внесення змін до системи стає дедалі складнішим і витратнішим.
Часто потрібні спеціальні засоби та технології розробки ПЗ. Це викликано необхідністю швидкої розробки версій програмного продукту. Але, з іншого боку, це може призвести до несумісності деяких засобів і технологій, що, у свою чергу, вимагає наявності в команді розробників фахівців високого рівня.
Еволюційний підхід найбільш прийнятний для розробки невеликих програмних систем(до 100 000 рядків коду) та систем середнього розміру (до 500 000 рядків коду) з відносно коротким терміном життя. На великих довгоживучих системах дуже помітно виявляються недоліки цього підходу. Для таких систем я рекомендую змішаний підхід до створення ПЗ, який увібрав би в себе найкращі риси каскадної та еволюційної моделей розробки.
За такого змішаного підходу для прояснення "темних місць" у системній специфікації можна використовувати прототипування. Частина системних компонентів, котрим повністю визначені вимоги, може створюватися з урахуванням каскадної моделі. Інші системні компоненти, які важко піддаються специфікації, наприклад інтерфейс користувача, можуть розроблятися з використанням прототипування.
Ітераційні моделі розробки ПЗ
У цьому розділі я представлю дві гібридні ітераційні моделі, що поєднують декількарізних підходів до розробки ПЗ та розроблені спеціально для підтримки ітераційного способу створення ПЗ.
1.Модель покрокової розробки, де процеси специфікування вимог, проектування та написання коду розбиваються на послідовність невеликих кроків, що ведуть до створення ПЗ.
2.Спіральна модель розробкив якій весь процес створення програмного забезпечення, від початкового ескізу системи до її кінцевої реалізації, розгортається по спіралі.
Істотною відмінністю ітераційних моделей є те, що тут процес розробки специфікації протікає паралельно із розробкою самої програмної системи. Більш того, в моделі покрокової розробки повну системну специфікацію можна отримати тільки після завершення останнього кроку процесу створення ПЗ. Очевидно, що такий підхід входить у суперечність із моделлю придбання ПЗ, коли повна системна специфікація є складовою контракту на розробку системи. Тому, щоб застосовувати ітераційні моделі для розробки великих систем, які замовляються "серйозними" організаціями, наприклад державними агентствами, необхідно змінювати форму контракту, на що такі організації йдуть насилу.
Модель покрокової розробки
У каскадної моделі створення ПЗ визначення вимог здійснюється разом із замовником до початку проектування системи, так само системна архітектура має бути створена до початку безпосередньої реалізації (кодування) системи. Зміни у вимогах, зроблені на етапі написання коду, ведуть до необхідності виконання повторних робіт із проектування та кодування системи. Разом з тим до переваг каскадної моделі можна віднести простоту управління процесом створення ПЗ (у рамках даної моделі), атакож наявність окремих етапів проектування та реалізації, що призводить до створення цілком працездатних систем, в яких враховано всі зміни у специфікації, зроблені вже під час процесу розробки ПЗ. На відміну від каскадної, в еволюційній моделі можна відкласти ухвалення остаточних рішень про специфікацію та структуру системи, однак це може призвести до створення погано структурованої системи, яка буде також складною у супроводі.
Модель покрокової розробки знаходиться десь між цими моделями та поєднує їх переваги. Ця модель була запропонована Міллсом (Mills) як спроба зменшити кількість робіт, що повторно виконуються в процесі створення ПЗ і збільшити для замовника тимчасовий період остаточного прийняття рішення про всі деталі системних вимог.
У процесі покрокової розробки замовник спочатку загалом визначає ті послуги (функціональні можливості), які мають бути у створюваної системи. У цьому встановлюються пріоритети, тобто. визначається, які послуги важливіші, а які менш. Також визначається кількість кроків розробки, причому на кожному кроці має бути отриманий системний компонент, що реалізує певне підмножина системних функцій. Розподіл реалізації системних сервісів за кроками розробки залежить від своїх пріоритетів. Сервіси з вищими пріоритетами реалізуються першими.
Послідовність кроків розробки визначається заздалегідь на початок їх виконання. На перших кроках деталізуються вимоги для сервісів, потім реалізації (на наступних кроках) використовується одне із потрібних методів розробки ПО. У ході їх реалізації аналізуються та деталізуються вимоги для компонентів, які розроблятимуться на більш пізніх кроках, причомуЗміна вимог для тих компонентів, які вже перебувають у процесі розробки, не допускається.