Первая страница
Наша команда
Контакты
О нас

    Головна сторінка



Поняття програмних систем. Характеристика процесу розробки систем

Скачати 148.27 Kb.

Поняття програмних систем. Характеристика процесу розробки систем




Скачати 148.27 Kb.
Дата конвертації03.04.2017
Розмір148.27 Kb.
ТипПрограма

  1. Поняття програмних систем.

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

    Характеристика процесу розробки систем.

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

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

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

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




  1. Системи, що використовуються на різних рівнях управління.

Виділяють три основні рівні управління:оперативний,тактичний,стратегічний.

Для прийняття рішень на кожному рівні потрібні певні знання чи інформація:

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

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

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

- системи обробки транзакцій.

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



- системи аналітичної обробки даних

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

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

Обро́бка да́них - систематична цілеспрямована послідовність дій над даними. Обробка даних містить в собі множину різних операцій.

Аналітична обробка пов'язана з аналізом архівних даних при виборі правильних рішень. Чим більше архівних даних має компанія, тим надійніше буде прийняте рішення.

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

- системи обробки знань

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

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

Управлі́ння знання́ми (англ. knowledge management), також використовується термін «Менеджмент знань» - це систематичні процеси, завдяки яким знання, необхідні для успіху організації, створюються, зберігаються, розподіляються і застосовуються.

Основні цілі інтелектуального аналізу:

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

Класифікація. Перевірка, чи потрапляють певні факти в заздалегідь визначену категорію.

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


  1. Учасники процесу розробки ПЗ та їх функції.

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

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



Користувач - особа або організація, яка використовує діючу систему для виконання конкретної функції.

Замовник - особа (фізична або юридична), яка зацікавлена у виконанні виконавцем якого-небудь обсягу робіт або придбання у продавця будь-якого продукту, і яка оформляє у зв'язку з цим замовлення.

Розробник – особа, що займається програмуванням, виконує розробку програмного забезпечення

Поділ на ролі у проекті може бути наступним:

Бізнес-аналітик.

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

Основне завдання бізнес - аналітика – розібратися у можливостях системи, що відносяться до задачі і розкрити їх команді.

Менеджер проекту. Основне завдання менеджера проекту - домагатися виконання поставлених перед командою завдань у відповідності з графіком та в рамках бюджету.

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

Розробник. Його основне завдання - реалізувати програму відповідно до специфікацій і у встановлені терміни.

Тестувальник. Тестувальник виконує завдання тестування продукту.

Реліз-менеджер. Реліз-менеджер відповідає за операції з випуску продукту

Розробник баз даних. Основне завдання розроблювача баз даних - виконання комплексу завдань з розробці бази даних у встановлені терміни.



  1. Життєвий цикл програмного забезпечення.


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

Основні процеси ЖЦ ПЗ:

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

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

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

4) Процесс експлуатації охоплює дії і завдання оператора - організації, що експлуатує систему.

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



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

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

Програ́мний проду́кт (англ. programming product) - це: програмний засіб, програмне забезпечення, які призначені для постачання користувачеві (покупцеві, замовникові). програма, яку може запускати, тестувати, виправляти та змінювати будь-яка людина.



Організаційні процеси ЖЦ ПЗ: Процесс управління, процесс створення інфраструктури, процесс удосконалення, процесс навчання.


  1. Методи і моделі розробки програмного забезпечення.

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

Ітеративний підхід ( англ. iteration - Повторення) - виконання робіт паралельно з безперервним аналізом отриманих результатів і коректуванням попередніх етапів роботи. Проект при цьому підході в кожній фазі розвитку проходить повторюваний цикл: Планування - Реалізація - Перевірка

Переваги ітеративного підходу:

зниження впливу серьезних ризиків на ранніх стадіях проекту

організація ефективного зворотного зв'язку проектної команди зі споживачем

акцент зусиль на найбільш важливі та критичні напрямки проекту;

безперервне Ітеративний тестування, що дозволяє оцінити успішність всього проекту в цілому;

більш рівномірне завантаження учасників проекту;

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

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

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


  1. Основні розділи технічного завдання та їх зміст.


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

Техні́чне завдання́ (ТЗ) (англ. scope statements та англ. statement of work; SOW) - документ, що встановлює основне призначення, показники якості, техніко- економічні та спеціальні вимоги до виробу, обсягу, стадії розроблення та складу конструкторської документації.

Застосунок, застосовна програма, прикладна програма (англ. application, application software; пол. aplikacja; рос. приложение, прикладная программа) - користувацька комп'ютерна програма, що дає змогу вирішувати конкретні прикладні задачі користувача.

Технічне завдання повинно містити наступні розділи:



  • вступ;

  • найменування і область застосування;

  • підстава для розробки;

  • призначення розробки;

  • технічні вимоги до програми або програмного виробу;

  • техніко-економічні показники;

  • стадії і етапи розробки;

  • порядок контролю та приймання;

  • додатки.

Вступ повинен включати коротку характеристику області застосування програми або програмного продукту, а також об'єкта

«Найменування та область застосування

«Підстава для розробки» повинні бути вказані:


  • документ (документи), на підставі яких ведеться розробка. Таким документом може служити план, наказ, договір і т. п.

  • організація, що затвердила цей документ,

  • найменування і (або) умовне позначення теми розробки.

«Призначення розробки»

«Технічні вимоги до програми або програмного забезпечення» повинен містити такі підрозділи:



  • вимоги до функціональних характеристик;

  • вимоги до надійності;

  • умови експлуатації,

  • вимоги до складу і параметрів технічних засобів;

  • вимоги до інформаційної та програмної сумісності мости;

  • вимоги до маркування та пакування;

  • вимоги до транспортування і зберігання;

  • спеціальні вимоги.

«Стадії та етапи розробки»

«Порядок контролю і приймання» повинні бути вказані види випробувань і загальні вимоги до приймання роботи.



додатки



  1. Історія розвитку та основні поняття UML.

До 1995 року серед методів аналізу і проектування спостерігалось різноманіття підходів та жорстка конкуренція.

Проте, у відповідь на пропозицію звести всі методи до єдиного стандарту, компанія OMG отримала відкритий лист із протестом від всіх авторів основних методологій. Джим Рамбо приєднався до Буча. На конференції OOPSLA'95 Буч та Рамбо представили перший опис об'єднаного. В цей самий час до розробників уніфікованого методу приєднався Джекобсон. Розробка нового методу - вже під назвою UML - тривала до 1997 року, причому з відкритим несхваленням зі сторони голови OMG.

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

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

Серед тих пропозицій була і документація на мову UML 1.0. Після внесення декількох істотних доповнень версія 1.1. мови UML була обрана в якості офіційного стандарту OMG.

На протязі декількох років спеціальна робоча група OMG (OMG Revision Task Force) підтримувала просування проекту UML. Були створені версії 1.3, 1.4, і 1.5. За 2000-2003 була розроблена версія UML 2.0.у листопаді 2007 випущена поточна версія UML2.1.2.

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

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

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



  1. діаграм UML.

Діаграми UML

1)Структурні діаграми: діаграма класів, діаграма компонентів, діаграма об’єктів, діаграма композитних структур, діаграма розгортання, діаграма пакетів.

Діаграма розгортання (англ. deployment diagram) - діаграма в UML, на якій відображаються обчислювальні вузли під час роботи програми, компоненти, та об'єкти, що виконуються на цих вузлах. Компоненти відповідають представленню робочих екземплярів одиниць коду.

Діаграма компонент - в UML, діаграма, на якій відображаються компоненти, залежності та зв'язки між ними.

Діагра́ма кла́сів - статичне представлення структури моделі. Відображає статичні (декларативні) елементи, такі як: класи, типи даних, їх зміст та відношення. Діаграма класів, також, може містити позначення для пакетів та може містити позначення для вкладених пакетів.



2)Діаграми поведінки: діаграма активності, діаграма варіантів використання, діаграма стану, діаграма взаємодії (діаграма комунікації, діаграма схеми взаємодії, діаграма послідовності, часова діаграма)

структурні діаграми:

діаграма класів– призначена для моделювання структури об’єктно-орієнтованих програм: класів, їх атрибутів і назв методів, наслідування, а також зв’язків класів один з одним.

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

Діаграма послідовності - в UML, діаграма послідовності відображає взаємодії об'єктів впорядкованих за часом. Зокрема, такі діаграми відображають задіяні об'єкти та послідовність відправлених повідомлень.



діаграма компонент – використовується для моделювання компонентної структури програм, всередині кожна компонента може бути реалізована як множина класів.

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

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

діаграма розгортання – призначена для моделювання апаратної частини системи, з якою безпосередньо пов'язана (розміщена або взаємодіє).

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

діаграми поведінки:

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

діаграма варіантів використання– використовується для «витягування» інформації з користувачів та експертів про вимоги до системи; показує роботу системи з точки зору користувача.

Аспект (лат. aspectus - вигляд, погляд) - поняття філософії (онтології, теорії пізнання). У філософії аспект розглядається



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

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



діаграми взаємодії:

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

діаграма схеми взаємодії – використовуються для організації ієрархії діаграм послідовностей.

діаграма комунікації– аналог діаграм послідовності, але у формі графів.

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

  1. Діаграми варіантів використання в UML.


Usecasediagram– часткова модель поведінки системи, яка: є базою для побудови усіх інших моделей; показує різні дії, які користувачі можуть виконувати в системі; моделює динамічні аспекти системи; моделює взаємодію користувача з системою; дозволяє задокументувати проект.

Елементи usecasediagram: 1) Актор (actor) – ролі користувачів, які взаємодіють з системою; 2) Варіант використання (usecase) – описує дію, яку виконує актор по відношенню до системи або її модулів; 3) Відношення (relationship) – зв'язки між елементами моделі варіантів використання; 4) Межі (границі) системи (boundary) – відділена частина функціональності системи.

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

Варіант використання: цілісний набір функцій, що мають цінність для Актора; дія, яку може виконувати актор у системі; можна ділити на групи за функціями (boundary).

Відношення: 1) Generalizationузагальнення, коли один елемент є узагальненням іншого ( ); 2) CommunicationAssociation– зв’язок між актором та варіантом використання ( ); 3) Include– відношення залежності, коли один варіант використання включається в інший ( ); 4) Extend – відношення залежності, коли один варіант використання розширює можливості іншого за певних умов ( ).


  1. Інтерв’ювання як один із основних методів аналізу вимог до ПЗ.

Слід пам’ятати, що клієнт – це людина, котра отримує від продукту пряму або опосередковану вигоду. При цьому необхідно чітко розмежовувати:

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

б) вимоги кінцевих користувачів (опис функціональних властивостей продукту).

У процесі проведення інтерв’ю виділяють три основних складових:

1. Підготовка

• виберіть потрібного співрозмовника;

• домовтесь про зустріч;

• встановіть попередню програму зустрічі;

• вивчіть супутню інформацію;

• узгодьте свої дії з групою проектування



2. Проведення опитування

Контекст інтерв’ю

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

Узагальнений зразок інтерв’ю

Частина І. Визначення профіля замовника або користувача

Частина ІІ. Оцінка проблеми

Частина ІІІ. Розуміння середовища користувача

Частина ІV. Резюме (перечислення основних пунктів

Частина V. Припущення аналітика

Частина VІ. Оцінка можливості (хто потребує даного рішення)

Частина VІІ. Оцінка необхідного рівня надійності та продуктивності, а також потреби у супроводі

Частина IX. Інші вимоги

Частина X. Загальний підсумок



3. Завершення


Скачати 148.27 Kb.