Поиск

Полнотекстовый поиск:
Где искать:
везде
только в названии
только в тексте
Выводить:
описание
слова в тексте
только заголовок

Рекомендуем ознакомиться

'Конкурс'
Сегодня молодежь является основным ресурсом развития нашей страны. В связи с этим выдвигаются и новые требования к государственной молодёжной политик...полностью>>
'Учебно-методическое пособие'
Полный веры в русский народ, И.С.Тургенев в своем творчестве показал одаренность, его душевную красоту. Мы ценим Тургенева как писателя, воспевшего я...полностью>>
'Автореферат'
Защита диссертации состоится «14» ноября 2007 года в 1500 часов на заседании совета по защите докторских и кандидатских диссертаций Д 520.020.01 при ...полностью>>
'Документ'
Стратегический и тактический контроль коммуникаций. Ярмарки и выставки в системе маркетинговых коммуникаций. Характеристика радио- и теле рекламы....полностью>>

Основи програмної інженерії

Главная > Документ
Сохрани ссылку в одной из сетей:

Навчальне електронне видання

Основи програмної інженерії.

посібник

для студентів напряму «Програмна інженерія»

ЗМІСТ

Вступ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1. Основи програмної інженерії . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.1. Програмна інженерія в історичному аспекті . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.2. Програмна інженерія як дисципліна . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.3. SWEBOK: Керівництво до зводу знань з програмної інженерії. . . . . . . . . . . .

9

1.4. Структура і зміст SWEBOK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2. Характеристика життєвого циклу стандарта ISO/IEC 12207 . . . . . . . . . . . . . . . . . .

38

3. Формування прикладних моделей життєвого циклу . . . . . . . . . . . . . . . . . . . . . . . . .

43

4. Вимоги до програмних систем . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5. Методи програмування . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

6. Оптимізація програм . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

99

7. Навчально-методичні рекомендації до вивчення дисцілини «Основи програмної інженерії.». . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

116

Лiтература. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

131

Додаток 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

137

додаток 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

143

Вступ

Програмна Інженерія (Software Engineer ing) - наука побудови комп'ютерних програмних систем, що містить у собі теоретичні концепції, методи і засоби програмування, технологію програмування, системи та інструменти їхньої підтримки, сучасні стандарти, зокрема, процеси життєвого циклу, вимірювання, оцінювання якості розробки ПС. Головне призначення програмної інженерії - побудова ПС, починаючи з аналізу предметної області і закінчуючи виготовленням вихідного коду для виконання на комп'ютері. Фундаментальну основу побудови ПС становлять: теорія алгоритмів, математична логіка, теорія обчислень, теорія керування й ін.

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

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

1. Основи програмної інженерії.

1.1. Програмна інженерія в історичному аспекті.

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

У 1958 р. всесвітньо відомий статистик Джон Тьюкей (John Tukey)уперше ввів термін software - програмне забезпечення. У 1972 р. IEEE (Computer Society of the Institute for Electrical and Electronic Engineers, IEEE Computer Society – IEEE--CS (Комп'ютерне Суспільство) чи просто IEEE. ) випустив перший номер Transactions on Software Engineering – Праці з програмної інженерії. Перший цілісний погляд на цю область професійної діяльності з'явився 1979 р., коли Комп'ютерне Суспільство IEEE підготувало стандарт IEEE Std 730 щодо якості програмного забезпечення. Після 7 років напружених робіт, у 1986 р. IEEE випустило IEEE Std 1002 ”Taxonomy of Software Engineering Standards”.

У 1990 р. почалося планування всеосяжних міжнародних стандартів, в основу яких лягли концепції і погляди стандарту IEEE Std 1074 і результатів роботи утвореної в 1987 р. спільної комісії ISO/IEC JTC 1(International Organization for Standardization; IEC – International Electrotechnical Commission; JTC 1 – Joint Technical Committee 1, Information technology).

У 1995 р. група цієї комісії SC7 “Software Engineering ” випустила першу версію міжнародного стандарту ISO//IEC 12207 “Software Lifecycle Processes ”. Цей стандарт став першим досвідом створення єдиного загального погляду на програмну інженерію. Відповідний національний стандарт Росії – ГОСТ Р ИСО/МЭК 12207-99 [ГОСТ 12207,1999 ] містить повний автентичний переклад тексту міжнародного стандарту ISO/IEC 12207-95 (1995 р.).

У свою чергу, IEEE і ACM (Association of Computer Machinery).,почавши спільні роботи ще в 1993 р. з кодексу етики і професійної практики в даній галузі (ACM/IEEE-CS Code of Ethics and Professional Practice), до 2004 р. сформулювали два ключових описи того, що сьогодні ми і називаємо основами програмної інженерії –Software Engineering:

  1. Guide to the Software Engineering Body of Knowledge (SWEBOK),IEEE 2004 Version - Керівництво до Зводу Знань з Програмної Інженерії, надалі просто “SWEBOK ” [SWEBOK,2004 ];

  2. Software Engineering 2004.Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering - Навчальний План для Викладання Програмної Інженерії у Вузах (дана назва представлено у вільному перекладі) [SE,2004 ] .

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

1.2. Програмна інженерія як дисципліна.

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

Програмна інженерія (ПІ) містить у собі методи і засоби керування програмними проектами (планування робіт і регулювання ресурсів), експертне оцінювання проміжних результатів розроблення під час процесів ЖЦ, оцінювання ризику побудови програмної системи і досягнутої для неї якості. Ця дисципліна використовує стандарти (наприклад, ISO/IEC 12207, ДСТУ 9126), що регламентують процеси ЖЦ, інженерію вимог, тестування і забезпечення якості шляхом перевірки показників на процесах ЖЦ і кінцевого продукту для їхнього оцінювання. Інакше кажучи, в програмної інженерії подані питання теоретичної і практичної побудови різних програмних систем для виконання задач з оброблення інформації на комп'ютерах з метою отримання корисних даних.

Проектування у ПІ - це конструювання комп'ютерних систем методами та засобами програмування за такими загальними кроками:

- опис вимог;

- опис специфікацій системи;

- розроблення системи;

- тестування, оцінка надійності і якості системи.

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

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

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

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

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

Значну роль у становленні програмної інженерії відіграла систематизація накопичених знань у програмуванні, виконана комітетом спеціалістів у галузі інформатики під комітетом відомих комп'ютерних організацій IEEE Computer Society і ACM (Association for Computer Machinery). Цей комітет створив (1999 p.- перший варіант, 2001 p. - другий) ядро знань SWEBOK, де наведено визначення предмету програмної інженерії і її тематичних областей (knovvledge areas). Одночасно були розроблені стандарти з програмної інженерії, головні серед яких ISO/IEC 12207-життєвий цикл ПЗ і ДСТУ 9126 - якість програмного продукту тощо.

Ядро знань SWEBOK і регламентовані процеси стандарту ISO/IEC 12207 узгоджені між собою. Вони утворюють практичний базис інженерії виробництва програмного продукту. Питання керування програмним проектом розглянуті в іншому ядрі знань - РМВОК та відповідному стандарті IEEE Std.1490 «IEEE А Guide to the Project Management Body of Knowledge». Стандарти визначають порядок діяльності в сфері технології розробки, а знання, те що необхідно фахівцям для виконання всіх видів діяльності з проектування і реалізації задач проекту, визначені в ядрі знань SWEBOK.

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

Таким чином, між ядрами знань SWEBOK, РМВОК і основними стандартами існує зв'язок і взаємовплив один на одного, тим більш, що в їхній розробці одночасно беруть участь висококваліфіковані фахівці в галузі програмування й інформатики. Загальні ідеї, методи та інструменти програмування, що склалися в 90-х роках минулого сторіччя, проникли в усі напрями і вплинули на стандартизацію процесів і їхній склад. У ядрі знань SWEBOK викладено концептуальні знання й інженерні підходи до керування проектування програмного продукту, а в стандартах — загальні правила і регламентовані процеси послідовного його розроблення. Але індустріальне виробництво різних видів програмних систем і сімейств систем потребує структуризації програмної інженерії, пов'язаної не тільки з процесами ЖЦ і відповідними змістовними методами проектування з SWEBOK, а й з теоретичними і прикладними методами забезпечення виробництва.

Сутність кожної з дисциплін, які єскладовими програмної інженерії, наступні:

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

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

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

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

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

1.3. SWEBOK: Керівництво до зводу знань з програмної інженерії.

З 1993 р. IEEE і ACM координують свої роботи в рамках спеціального спільного комітету -Software Engineering Coordinating Committee (SWECC -).Проект SWEBOK був ініційований цим комітетом у 1998 р. Оцінений можливий обсяг змісту SWEBOK і інші фактори привели до того, що було рекомендовано проводити роботи з реалізації проекту не тільки силами добровольців з рядів експертів індустрії і представників найбільших споживачів і виробників програмного забезпечення, але і на основі принципу “повної зайнятості”. Базовий комплекс робіт, у відповідності зі спеціальним контрактом, був переданий у Software Engineering Management Research Laboratory Університету Квебек у Монреалі (Universite du Quebec a Montreal).

Серед компаній, що підтримали цей унікальний проект були Boeing, MITRE, Raytheon, SAP. У результаті проекту, здійсненого за фінансової підтримки цих і інших компаній і організацій, а також з урахуванням його значимості для індустрії, SWEBOK Advisory Committee (SWAC) прийняв рішення зробити SWEBOK загальнодоступним – перспективі, якщо удасться забезпечити відповідний рівень фінансування, SWAC вважає за необхідне закінчену версію SWEBOK 2008 зробити також вільно доступною на Web-сайті проекту. Сьогоднішня “публічність” (загальнодоступність) результатів проекту стала можлива, у першу чергу, саме завдяки підтримці SWEBOK Industrial Advisory Board (IAB) – структури, що поєднує представників компаній, що підтримали проект.

Проект SWEBOK планувався у вигляді трьох фаз: Strawman (“солом'яна людина”), Stoneman (“кам'яна людина”) і Ironman (“залізна людина”). До 2004 р. була випущена версія Посібника зі Зводу Знань 3-їй фази -Ironman, тобто максимально наближена до остаточного варіанту і схвалена IEEE у лютому 2005 р. до публікації в якості Trial-версії. Основна мета поточної “пробної ” версії SWEBOK – поліпшити представлення, цілісність і корисність матеріалу керівництва на основі збору й аналізу відгуків на дану версію для того, щоб випустити фінальну редакцію документа в 2008 р.З ряду обгрунтованих причин, “SWEBOK є досить консервативним” [SWEBOK,2004, с.B-2 ].

Після 6 років безпосередніх робіт над документом, SWEBOK включає “лише” 10 галузей знань (knowledge areas, KA ). При цьому, що справедливо і для PMBOK, додавання нових галузей знань у SWEBOK досить прозоре. Усе, що для цього потрібне, зрілість (чи, принаймні, явний і швидкий процес досягнення зрілості) і загальноприйнятності відповідної галузі знань, якщо це не призведе до серйозного
ускладнення SWEBOK (*концепція “загальноприйнятності” - generally accepted – визначена в IEEE Std 1490--1998,Adoption of
PMI Standard — A Guide to the Project Management Body of Knowledge).

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

Керівництво до зводу знань, а таким є SWEBOK, включає базове визначення й опис галузей знань (наприклад, конфігураційне управління – configuration management) і, безумовно, є недостатнім для охоплення всіх питань, що відносяться до питань створення програмного забезпечення, але, у той же час потрібним для їхнього розуміння.

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

1.4. Структура і зміст SWEBOK.

Опис галузей знань у SWEBOK побудовано за ієрархічним принципом, як результат структурної декомпозиції. Така ієрархічна побудова звичайно нараховує два-три рівня деталізації, прийнятих для ідентифікації тих чи інших загальновизнаних аспектів програмної інженерії. При цьому, структура декомпозиції галузей знань деталізована тільки до того рівня, що потрібен для розуміння природи відповідних тем і можливості пошуку джерел компетенції й інших довідкових даних і матеріалів. У принципі, вважається, що як такий “звід знань ” з програмної інженерії представлений не в обговорюваному керівництві (SWEBOK),а в першоджерелах (як зазначених у ньому, так і представлених за його рамками) [SWEBOK,2004, с.1-2 ].

SWEBOK описує 10 галузей знань:

  1. Software requirements – програмні вимоги

  2. Software design – дизайн (архітектура)

  3. Software construction – конструювання програмного забезпечення

  4. Software testing - тестування

  5. Software maintenance – експлуатація (підтримка)програмного забезпечення

  6. Software configuration management – конфігураційне управління

  7. Software engineering management – управління в програмній інженерії

  8. Software engineering process – процеси програмної інженерії

  9. Software engineering tools and methods – інструменти і методи

  10. Software quality – якість програмного забезпечення.

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

  1. Computer engineering

  2. Computer science

  3. Management

  4. Mathematics

  5. Project management

  6. Quality management

  7. Software ergonimics

  8. Systems engineering

Варто відзначити, що прийняті розмежування між галузями знань, їх компонентами (subareas) і іншими елементами досить довільні. При цьому, на відміну від PMBOK, галузі знань SWEBOK не включають “входи ” і “виходи ”. Деякою мірою така декомпозиція пов'язані з тим, що SWEBOK не асоційовано з тією чи іншою моделлю (наприклад, життєвого циклу) чи методом. Хоча на перший погляд перші п'ять галузей знань у SWEBOK представлені в традиційній послідовній (каскадній -waterfall) моделі, це не більш ніж слідування прийнятій послідовності висвітлення відповідних тем. Інші галузі і структура декомпозиції галузей представлені за абеткою.

На рис. 1 представлені перші п'ять галузей знань.

Рис. 1. Перші п'ять галузей знань [SWEBOK,2004,с.1-8, рис.2 ]

1.4.1. Інженерія вимог

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

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

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

Область знань «Вимоги до ПЗ (Software Requirements))) складається у таких розділів:

- інженерія вимог (Requirement Engineering),

- виявлення вимог (Requirement Elicitation),

- аналіз вимог (Requirement Analysis), специфікація вимог (Requirement Specification).

- валідація вимог (Requirement validation),

- керування вимогами (Requirement Management).

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

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

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

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

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

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

Специфікація вимог до ПЗ - процес формалізованого опису функціональ­них і не функціональних вимог, вимог до характеристик якості відповідно до стан­дарту якості ISO/IEC 9126, які будуть відпрацьовуватися на етапах ЖЦ ПЗ. У спе­цифікації вимог відбивається структура ПЗ, вимоги до функцій, якості і документа-функцій, якості і документації, а також задається архітектура системи і ПЗ, алгоритми, логіка керування і структура даних. Специфікуються також системні вимоги, не функціональні вимоги і вимоги до взаємодії з іншими компонентами і платформами (БД, СКБД, маршаллінг даних, мережа й ін.).

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

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

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



Скачать документ

Похожие документы:

  1. Містять теоретичні відомості про організацію начального процесу бакалаврів з напряму «Програмна інженерія»

    Документ
    Бакалавр з програмної інженерії: Рекламно – методичнее видання. Укладачі: М.О. Сидоров, І.І.Вітковська – К.: Видавництво Національного авіаційного університету «НАУ-друк», 2011.
  2. Інформація про програми Напрям підготовки 050103 «Програмна інженерія» Кваліфікація, що присвоюється

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

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

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

    Документ
    ПЕРЕЛІК ДИСЦИПЛІН, ЗА ЯКИМИ БУДУТЬ АТЕСТУВАТИСЬ СТУДЕНТИ: вища математика, основи дискретної математики, чисельні методи в інформатиці, теорія ймовірностей, імовірнісні процеси і математична статистика, моделювання систем, архітектура

Другие похожие документы..