Базовi поняття програмної інженерії

Термін “ програмна інженерія ” (Software Engineering) вперше вжито в 1968 р., коли створення програмного забезпечення досягло такого ступеня розвитку, що можна застосовувати інженерні технології. Зараз розроблення програмного забезпечення стало справді масовим явищем.

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

Методи ПІ - це способи розроблення ПЗ, що містять рекомендації щодо послідовності обробки інформації, нотації, правила опису ІС тощо.

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

Основні проблеми, що постають перед ПІ, пов’язані з інтеграцією створеного раніше ПЗ у нові розробки (legacy challenge), роботою в розподіленому гетерогенному середовищі (heterogeneity challenge) та обмеженнями часу, що відводиться на розроблення інформаційних продуктів (delivery challenge).

Основні роздiли програмної інженерії:

· аналiз вимог до ІС, яку треба створити;

· детальний проект ІС;

· кодування;

· тестування системи;

· процес супроводження програмного продукту;

· керування конфiгурацiєю;

· забезпечення якостi розроблення;

· забезпечення вiдповiдностi розроблення вимогам її замовникiв та забезпечення вiдповiдностi кодiв проекту;

· процес удосконалення отриманого програмного продукту.

Життєвий цикл ПЗ

Поняття життєвого циклу програмного забезпечення (ЖЦ ПЗ) є одним з базових у програмній інженерії.

Життєвий цикл ПЗ- певна послiдовнiсть фаз або стадiй вiд моменту прийняття рішення про необхідність створення ПЗ до повного вилучення ПЗ з експлуатації

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

Головні ресурси програмної iнженерiї, що визначають ефективнiсть розроблень, - це час та вартiсть.

Усі процеси ЖЦ ПЗ поділяються на три групи: основні процеси (придбання, доставка, розроблення, експлуатація, супровід); організаційні процеси (управління, удосконалення, навчання); допоміжні процеси (документування, забезпечення якості, верифікація, атестація, аудит, загальна оцінка тощо).

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

Характерні роботи процесу розроблення:

· Визначення вимог. Збiр та аналiз вимог замовника виконавцем та подання їх у нотацiї, яка є зрозумiлою як замовнику, так i виконавцю.

· Проектування. Перетворення вимог до розроблення у послiдовнiсть проектних рiшень щодо способiв реалiзацiї вимог: формування загальної архiтектури програмної системи та принципiв її прив'язки до конкретного середовища функцiонування; визначення детального складу модулiв кожної з архiтектурних компонент.

· Реалiзацiя. Перетворення проектних рiшень у програмну систему, що реалiзує означенi рiшення.

· Тестування. Перевірка кожного з модулiв та способiв їх iнтеграцiї; тестування програмного продукту в цiлому (так звана верифiкацiя); тестування вiдповiдностi функцiй працюючої програмної системи вимогам, що були до неї поставленi замовником (так звана валiдацiя).

· Експлуатацiя та супроводження готової системи.

Інженерiя вимог

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

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

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

· побудову моделей діяльності організації, що передбачає обробку матеріалів обстеження;

· побудову двох видів моделей:

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

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

Перехід від моделі "як є" до моделі "як має бути" можна виконувати двома способами:

1) удосконалюванням існуючих технологій на основі оцінки їхньої ефективності;

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

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

Є кiлька класiв нефункцiональних вимог, суттєвих для бiльшостi ІС, якi виражають обмеження, актуальнi для багатьох проблемних галузей:

· вимоги конфiденцiйностi;

· вiдмовостiйкiсть;

· кiлькiсть клiєнтiв, що одночасно мають доступ до системи;

· вимоги безпеки;

· час очікування вiдповiдi на звернення до системи;

· виконавськi якостi системи (обмеження щодо ресурсiв пам'ятi, швидкiсть реакцiї на звернення до системи тощо).

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

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

Не нашли, что искали? Воспользуйтесь поиском: