View
228
Download
0
Category
Preview:
Citation preview
© KIO
Inżynieria Oprogramowania
Inżynieria Oprogramowania
Anna BobkowskaMaciej Piechówka
Katedra Inżynierii Oprogramowania
1. Wprowadzenie2. Motywacje i zakres inżynierii
oprogramowania3. Klasyczny cykl życia
Materiały pomocnicze do wykładu z Inży
Oprogramowania na Wydziale ETI PG.
Ich lektura nie zastępuje obecności na wykładzie.
Wykorzystanie materiałów w innym celu oraz ich
rozpowszechnianie jest zabronione.
nierii
© KIO
Inżynieria Oprogramowania
Wprowadzenie do przedmiotuCel: przegląd wiedzy dotyczącej metodycznego wytwarzania
oprogramowania o wysokiej jakości.
Wykład „Przegląd tematyki IO”• Przedmiot inżynierii oprogramowania;
cykl życia systemu; • Model kaskadowy • Faza przedprojektowa• Inżynieria wymagań i wybrane techniki
modelowania systemów• UML• Analiza wymagań; analiza obiektowa• Projektowanie systemu; projektowanie
obiektowe • Implementacja; • Testowanie i walidacja systemu; inspekcje• Wdrażanie i utrzymanie systemu• Narzędzia CASE• Inne podejścia i metodyki
Laboratorium „UML”• Przygotowanie wizji systemu• Modelowanie za pomocą
przypadków użycia • Modelowanie obiektowe • Modelowanie zachowania• Elementy projektowania
Zaliczenie:50% laboratorium50% egzamin
© KIO
Inżynieria Oprogramowania
Literatura
UML• Booch G., Rumbaugh J., Jacobson I.: UML przewodnik
użytkownika, WNT, 2001
Inżynieria Oprogramowania• Górski J. (red.) Inżynieria oprogramowania w projekcie
informatycznym, MIKOM, 2000• Pressman R., Ince D., Software Engineering: a Practitioner’s
Approach. McGraw-Hill, 2000• Sommerville I., Inżynieria Oprogramowania, 2003• Szejko S.(red.), Metody wytwarzania oprogramowania,
MIKOM, 2002
© KIO
Inżynieria Oprogramowania
Motywacje: Ważność i złożoność zagadnienia (1)
• System - zbiór wzajemnie powiązanych elementów, wyodrębnionych z otoczenia,współdziałających dla realizacji wspólnego celu
• Materia (tworzywo)
• Środowisko
– rozproszenie elementów systemu
SprzętOprogramowanieLudzieReguły użycia
Środowisko
© KIO
Inżynieria Oprogramowania
Motywacje: Ważność i złożoność zagadnienia (2)
• Rewolucja informacyjna - zastosowania informatyki:
– transport, produkcja, obsługa pieniądza, ochrona zdrowia, administracja, rozrywka, telekomunikacja, ...
• Oczekiwania (głównie jakościowe):– wysoce niezawodne– użyteczne– łatwe w użyciu– trudne do użycia w sposób niewłaściwy– bezpieczne– tanie– dostępne . . .
© KIO
Inżynieria Oprogramowania
Specyfika oprogramowania (1)
• zdominowane przez proces projektowania– pomijalne nakłady na produkcję, większość wysiłku skierowana
na projektowanie; niedojrzała technologia, kompetencje ?• trudności w wizualizacji
– oprogramowanie to “niematerialny wytwór intelektu”; trudności w obserwacji wcześniejszych form (specyfikacji wymagań, projektu,...); dążenie do jak najwcześniejszej implementacji obniżające szansę na sukces
• nie zużywa się– nie zużywa się; wadliwe działanie wynika z niedopasowania do środowiska, z błędów konstrukcji, często ujawniających się bardzo późno
• duża złożoność– trudno znaleźć standardy projektowe, trudno prześledzić wszystkie
sytuacje, wypuścić produkt pozbawiony błędów
© KIO
Inżynieria Oprogramowania
Specyfika oprogramowania (2)• dowolność struktury
– zwykle niewielkie ograniczenia i duże pole do popisu projektantów -złożoność, nieregularność, niezrozumiałość struktury - trudności modyfikacji i pielęgnacji
• zależność elementów– niejawne zależności pomiędzy elementami prowadzą do trudności
konstrukcyjnych, błędnych ocen poprawności oprogramowania, stwarzają problemy modyfikacji i pielęgnacji
• brak ograniczeń (np. prawami fizyki)– nieznaczna zmiana może spowodować duże odchylenie; „mała
modyfikacja”? „przybliżona analiza”?• łatwość zmian
– łatwość dokonywania zmian prowadzi do chaosu, błędów i bylejakości
• trudność testowania– niematerialność software’u, równoległość działań, skomplikowanie,
zakres możliwych danych istotnie utrudniają eliminacjędefektów
© KIO
Inżynieria Oprogramowania
Specyfika oprogramowania (3)
Zdecydowana większość użytecznego oprogramowania powstaje w układzie klient-wykonawca
KLIENTKLIENT WYKONAWCAWYKONAWCA
oczekiwaniaoczekiwania technologiatechnologia
DZIEDZINA DZIEDZINA PROBLEMOWAPROBLEMOWA
DZIEDZINA DZIEDZINA INFORMATYCZNAINFORMATYCZNA
opro
gram
owan
ieop
rogr
amow
anie
© KIO
Inżynieria Oprogramowania
Krzywe ilości uszkodzeń ujawniających się w czasie
a) w przypadku sprzętu b) w przypadku oprogramowania
© KIO
Inżynieria Oprogramowania
Procentowy rozkład błędów popełnianych przy konstrukcji systemów
Ko ns trukc ja
26%
Ko do wanie
7%
S fo rmułowa-nie
wymag ań56%
Inne błędy11%
© KIO
Inżynieria Oprogramowania
Rozkład kosztów wytworzeniai utrzymania oprogramowania
0%
20%
40%
60%
80%
100%
1975 1980 1985 1990 1995
utrzymanie
wytworzenie
© KIO
Inżynieria Oprogramowania
Zauważalne problemy i tendencje
• wzrost wymagań użytkowników: użytkowość, poprawność, wiarygodność czy efektywność;
• skomplikowanie systemów, nietrywialne zastosowania, wysoko specjalizowane zadania
• niska produktywność procesu wytwarzania
• brak ‘rzemiosła’ i jednostkowość procesu wytwarzania powoduje wysokie narzuty i koszty procesu produkcji
• błędy
• wzrost znaczenia fazy analizy i udziału użytkownika
• koszt utrzymania i wzrost znaczenia właściwej dokumentacji systemu
© KIO
Inżynieria Oprogramowania
Inżynieria Oprogramowania
• Oprogramowanie (software) - zbiór programów, procedur postępowania i związanej z nimi dokumentacji, w ramach danego systemu (komputerowego).
• Inżynieria (engineering) - polega na takim zastosowaniu nauk ścisłych, przyrodniczych i humanistycznych, poprzez które materiai źródła energii naturalnej stają się użyteczne dla człowieka.
Inżynieria oprogramowania polega na takim zastosowaniu nauk (ścisłych, przyrodniczych, humanistycznych), poprzez które własności i możliwości sprzętu komputerowego stająsię, za pośrednictwem oprogramowania, użyteczne dla człowieka.
© KIO
Inżynieria Oprogramowania
Podobieństwa inżynierii oprogramowania
do tradycyjnej inżynierii
techniki rozwiązywania problemów
• identyfikacja potrzeb• planowanie działań• zarządzanie projektem• systematyczna analiza• kontrola jakości procesu• ocena jakości produktu• bieżąca eksploatacja
notacjemetodykinarzędzia
© KIO
Inżynieria Oprogramowania
Podstawowe różnice pomiędzy inżynierią oprogramowania a inżynierią tradycyjną
Brak praw fizyki
Program to “czysta” informacja
Statyczny obraz programu
Obserwacja pośrednia
Nie zużywa się
© KIO
Inżynieria Oprogramowania
Drogi rozwiązania
Systematyczne wytwarzanie, zgodnie z przyjętym cyklem
Rozwój notacji modelujących i wspomaganie uznanych cykli rozwojuoprogramowania, głównie klasycznego
Definiowanie nowych cykli wytwórczych, często posiłkujących się nowymi metodologiami
Rozwijanie nowych metodologii systematycznej konstrukcji oprogramowania, bazujących na istniejących bądź nowych notacjach; najwięcej prac dotyczy metodologii obiektowych
Środowiska i narzędzia wspomagające
Wspomaganie zarządzania projektem informatycznym, planowania, zarządzania ludźmi, minimalizacji ryzyka, zapewniania jakości
© KIO
Inżynieria Oprogramowania
Podejścia i metodyki
Czym jest metodyka konstrukcji systemu ?
- Jest zbiorem procedur, metod, narzędzi i środkówwspomagających dokumentowanie
- Składa się z faz, które same składają się z kolejnych faz- Stanowi 'przewodnik' dla konstruktorów systemu- Stanowi metodę systematycznej budowy systemów- Bazuje na pewnym widzeniu świata, nazywanym podejściem
(ang.: approach)
© KIO
Inżynieria Oprogramowania
Podejścia
• Modularyzacja
• Podejście strukturalne
• Wykorzystanie metod formalnej specyfikacji
• Podejście obiektowe
¨
¨
© KIO
Inżynieria Oprogramowania
Popularne metody modelowania systemów
Modelowanie danych model relacyjny, diagramy związków encjimodel obiektowysłowniki danychabstrakcyjne typy danych (ADT)
Modelowanie diagramy przepływu danychprzetwarzania języki opisu, jak Structured English czy Program
Description Languagetablice decyzyjne, drzewa decyzjidiagramy akcji, diagramy przepływudiagramy przepływu pracy
Modelowanie funkcji hierarchie funkcji i macierze powiązańprzypadki użycia (use cases)abstrakcyjne typy danych
Modelowanie modele grafowe, sieci Petriegozachowania FSMs, automaty, diagramy przejść stanu
diagramy interakcji, diagramy komunikacji (MSC)drzewa zdarzeń, drzewa błędówVDM, Z
Modelowanie struktury diagramy strukturystatycznej i modele obiektowedynamicznej modele komunikujących się procesów, CCS , CSP ,
języki formalnej specyfikacji
© KIO
Inżynieria Oprogramowania
Środowiska wspomagajacespecyfikację wymagań, najcześciej za pomocą notacji graficznych,walidację dokonanej specyfikacji (modelu logicznego), ocenę jej spójności i kompletności,przekształcenie utworzonego modelu w projekt,weryfikację zgodności projektu z wymaganiami i jego logiczną walidację, często poprzez prototypowanie lub symulację działania przyjętej konstrukcji,szkieletową lub pełniejsza generację kodu,testowanie, animację i pomiary utworzonej aplikacji,tworzenie dokumentacji, na różnych poziomach i w różnych przekrojach, zarządzanie projektem, od planowania i harmonogramowania po kontrolę realizacji,analizę zamierzonych zmian i wspomaganie ich dokonania, prace zapewniające re-development, zarządzanie konfiguracją lub przeniesienie aplikacji do nowego środowiskareverse - engineering, czyli pozyskiwanie specyfikacji projektowej oraz analitycznej na podstawie istniejącego kodu i wiedzy konstruktora,powtórne wykorzystanie wcześniejszych rozwiązań w konstrukcji nowych projektów wersjonowanie projektu oraz zespołową pracę nad nim
© KIO
Inżynieria Oprogramowania
Cykl życia systemu
Struktura obrazująca podstawoweetapy rozwoju i eksploatacji systemuwraz z ich produktami, wzajemnymi relacjami pomiędzy tymi etapamioraz ich zależnościami w czasie
© KIO
Inżynieria Oprogramowania
Cykl życia i cykl wytwarzania systemu
Cykl życia oprogramowania reprezentuje powtarzającą się w czasie całość działań prowadzonych od ujawnienia potrzeby budowy systemu po zakończenia jego wykorzystania. Obrazowane są kolejne etapy rozwoju i eksploatacji systemu, wraz z ich kontekstem, produktami, wzajemnymi relacjami i zależnościami w czasie.
Cykl wytwarzania oprogramowania - ta część cyklu życia, która obejmuje etapy wytwórcze.
© KIO
Inżynieria Oprogramowania
Cykl życia systemu“Klasyczny cykl życia systemu” to całość działań prowadzonych
od ujawnienia potrzeby jego budowy,
poprzez analizę stawianych wymagań,
projektowanie
i implementację oprogramowania,
jego konserwację,
do zakończenia wykorzystania oprogramowania
Studium potrzeb i możliwości
?
Analiza wymagań
Projektowanie
Specyfikacja
Implementacja
Nie
Utrzymanie
© KIO
Inżynieria Oprogramowania
Model klasyczny (kaskadowy)
Faza przedprojektowa(Planowanie)
Faza przedprojektowa(Planowanie)
AnalizaAnaliza
ProjektowanieProjektowanie
ImplementacjaImplementacja
TestowanieTestowanie
Wdrożeniei pielęgnacjaWdrożenie
i pielęgnacja
© KIO
Inżynieria Oprogramowania
Klasyczny cykl życia - produkty (wg ESA) FAZY ELEMENTY
UR DEFINIOWANIE WYMAGAŃ UŻYTKOWNIKA
UR/R SR DEFINIOWANIE WYMAGAŃ SOFT- WARE'OWYCH
SR/R
AD PROJEKT KONSTRUKCYJ- NY
AD/R DD PROJEKT SZCZEGÓŁOWY I WYTWARZANIE
DD/R TR PRZEKAZANIE
OM UŻYTKOWANIE I UTRZYMANIE
GŁÓWNE DZIAŁANIA
• ustalenie środowiska użytkwania • identyfikacja wymagań użytkownika
• konstrukcja modelu logicznego • identyfikacja wymagań software'owych
• konstrukcja modelu fizycznego • zdefiniowanie podstawowych komponentów
• projektowanie modułów • kodowanie • testy
segmentów • testy integra- cyjne • testy
systemowe
• instalacja • testy wstępnego odbioru
• testy ostatecznego odbioru • użytkowanie • utrzymanie kodu i dokumentacji
PRODUKTY Dokument Wymagań Użytkownika URD
→
Dokument Wymagań Software'owych SRD
→
Dokument Projektu Konstrukcyjnego ADD
→
Dokument Szczegółowego Projektu DDD Kod SUM Podręcznik Użytkownika Oprogramowania
→
→ →
Dokument Przekazania Software'u STD
Dokument Historii Projektu → PHD
PRZEGLĄ-DY
przeglądy techniczne
przeglądy kontrole
przeglądy techniczne
przeglądy kontrole
przeglady techniczne
przeglądy kontrole
przeglądy techniczne
GŁÓWNE ETAPY
Zatwierdzenie URD
Zatwierdzenie SRD
Zatwierdzenie ADD
Zatwierdzenie Kodu/ADD/ SUM
Powstanie STD Wstępny odbiór
Powstanie PHD Ostateczny odb.
AD;ADD;AD/R Architectural Design/Document/Review Projekt Konstrukcyjny/Dokument /Przegląd DD;DDD;DD/R Detailed Design and production/Document/Review Szczegółowy Projekt i Wytwarzanie/Dokument /Przegląd PHD Project History Document Dokument Historii Projektu SR;SRD;SR/R Software Requirements/Document/Review Wymagania Software'owe/Dokument /Przegląd STD Software Transfer Document Dokument Przekazania Oprogramowania SUM Software User Manual Podręcznik Użytkownika Oprogramowania UR/D/R User Requirements/Document/Review Wymagania Użytkownika/Dokument/Przegląd
© KIO
Inżynieria Oprogramowania
Faza przedprojektowa
• Identyfikacja problemu• Studium wykonalności• Decyzja o realizacji projektu• Inicjalizacja projektu + ustalenia • Plan projektu
© KIO
Inżynieria Oprogramowania
Zdefiniowanie problemu • Opis nieformalny
• Opis ustrukturalizowany:
Założenia wstępne
√ zadania systemu√ cele biznesowe√ wizja systemu: zakres i zadania, użytkownicy, perspektywiczność,
podstawowe założenia, parametry jakościowe i techniczne, zgodność ze standardami, organizacja działania systemu
√ uwarunkowania: ograniczenia zasobowe, powiązane projekty, wymagania i ograniczenia prawne, inne uwarunkowania
• Soft Systems Methodology (SSM)
© KIO
Inżynieria Oprogramowania
Wizja systemu1. Cele systemu
2. Kontekst systemuUżytkownicy i ich specyfikaInne systemy i ich interfejsy
3. Zakres funkcjonalnościOpis, jakie usługi system ma udostępniać.
4. OgraniczeniaOgraniczenia, które mają wpływ na kształt systemu:- dotyczące zasobów projektowych: czasowe, ludzkie, sprzętowe,
oprogramowanie;- dotyczące produktu: interfejsów, dotyczące działania w
specyficznych warunkach, dokumentacji, specyficzne wymaganiaużytkownika.
5. Wymagania jakościoweWymagania dotyczące ochrony, bezpieczeństwa, przenośności,elastyczności, konfigurowalności, niezawodności, wydajności itp.
© KIO
Inżynieria Oprogramowania
Analiza wykonalności
• Studium wykonalności rozwiązania problemów i opcji wskazanych w założeniach projektu
• Dyskusja wariantów rozwiązania
• Podstawy podjęcia decyzji o kontynuacji (lub nie) projektu
• wykonalność techniczna• wykonalność ekonomiczna• wykonalność organizacyjna• aspekty prawne
© KIO
Inżynieria Oprogramowania
Raport studium wykonalności
• Cel, zakres i uwarunkowania
• Istniejący system
• Wymagania użytkownika
• Opis proponowanego systemu
• Strategia i harmonogram prowadzenia prac
• Rozwiązania alternatywne
• Koszty i korzyści
• Analiza ryzyka
• Ramy prawne
© KIO
Inżynieria Oprogramowania
Plan projektu
• Cel projektu• Zakres projektu• Strategia, priorytety, infrastruktura,
role ...• Wybór sposobu wytwarzania• Opis poszczególnych etapów• Harmonogram
© KIO
Inżynieria Oprogramowania
Analiza wymagań (co?)
• identyfikacja i specyfikacja wymagań użytkowych
• specyfikacja wymagań dotyczących oprogramowania - konstrukcja modelu logicznego
-Inżynieria Wymagań-Modelowanie, np. UML
© KIO
Inżynieria Oprogramowania
Poziomy specyfikacji wymagań
Wymagania systemowe (użytkowe)
Modele koceptualne
Wymagania względem oprogramowania
© KIO
Inżynieria Oprogramowania
Diagram przypadków użyciaBiblioteczka domowa
[J. Uścinowicz]
Użytkownik
Ewidencjaksiążek
Dodawaniedanych o książce
Usuwaniedanych o książce
Modyfikowaniedanych o książce
Przeglądaniedanych o książce
extendsextends
uses
extends
© KIO
Inżynieria Oprogramowania
Diagram interakcjiBiblioteczka domowa [J. Uścinowicz]
• Modyfikacja danych dotyczących książki
DescriptionWlasciciel
«user»Ksiazka
«business»
Zmiana informacji dotyczacychdanej ksiazki Wprowadzenie danych
Sprawdzenie poprawnosciwprowadzonych danych Sprawdzenie poprawnosci danych
If dane bledneKomunikatu o blednych danych
Zapisanie rekordu zezmodyfikowanymi danymido bazy danych.
Zapisanie zmodyfikowanego rekordu
© KIO
Inżynieria Oprogramowania
Projektowanie (jak?)
• projekt wysokiego poziomu
• projekt szczegółowy
© KIO
Inżynieria Oprogramowania
Usytuowanie Projektowaniaw cyklu wytwarzania
Modeldanych
Modelfunkcji
Modelzachowania
Innewymagania
Ograni-czenia
Projektowanie
Projektarchitektury
Projektdanych
Projektprocedur
Implemen-tacja
Testowanie
Kodprogramu
Zintegrowane, po walidacji,
oprogramowanie
© KIO
Inżynieria Oprogramowania
Testowanie i walidacja
• integracja i testy integracyjne
• walidacja i testy systemowe
• testowanie akceptacyjne
© KIO
Inżynieria Oprogramowania
Testowanie i walidacja
user requirements acceptance tests validation tests
logical design system testing
system integrationarchitecture testing
detail unit design testing
coding
© KIO
Inżynieria Oprogramowania
Model V
WYMAGANIAPLANOWANIE
TESTUSYSTEMU
TESTSYSTEMU INSTALACJA
KODOWANIE
PLANOWANIETESTÓW
MODUŁÓW
PLANOWANIETESTU
INTEGRACYJNEGO
PIELĘGNACJATESTMODUŁÓW
TESTINTEGRACYJNY
PROJEKTSZCZEGÓŁOWY
PROJEKTSYSTEMU
© KIO
Inżynieria Oprogramowania
Sterowanie jakością - model VProjectplanning
Userrequirements Documen tation
Finalising
Requirementsanalysis
Softwarerequirements(software models) Design proposal Acceptance Acceptance test testing specification Test reports
Testing
Design
Systen architecture specification Module (object) Integration specification tests Integration Test reports and module Module tests test plans Test reports
Implemen-tation
Documentation
Code, forms, prototypes,...Implemen-tation
Q
Q
Q Q
Q
Q
© KIO
Inżynieria Oprogramowania
Wdrożenie systemu
• Złożoność problemu• Kulminacja błędów i odpowiedzialności
© KIO
Inżynieria Oprogramowania
Fazy wdrożenia
Planowanie wdrożeniaPrzygotowanieInstalacja SzkolenieReorganizacja przedsiębiorstwaZmiana systemuOcena / audytDostosowanieEksploatacja
© KIO
Inżynieria Oprogramowania
Utrzymanie (pielęgnacja, konserwacja)
pielęgnacja naprawcza (ang. corrective maintenance)obejmuje diagnostykę i usuwanie błędów,
adaptacja (ang. adaptive maintenance),dostosowuje oprogramowanie do zmian środowiska jego pracy,
ulepszanie (ang. perfective maintenance)ma na celu poprawę funkcjonalności i jakości oprogramowania, np.dostosowanie oprogramowania do nowych wymagań użytkowników,zwiększenie wydajności wybranych funkcji systemu,zmianę interfejsu użytkownika
utrzymanie zapobiegawcze (ang. preventive maintenance)przygotowuje istniejące oprogramowanie do zwiększenia jegopielęgnowalności, w tym głównie do wykrycia i poprawienia defektówzanim one wystąpią.
© KIO
Inżynieria Oprogramowania
Zalety modelu kaskadowego
• obejmuje cały cykl życia• wprowadza systematykę• sprawdzony, zweryfikowany praktycznie• dobra strukturalizacja (etapy, czynności)• uwypukla analizę i projektowanie, ze szczególnym
uwzględnieniem aspektów technicznych rozwiązania• pozwala na dobrą dekompozycję pracy
© KIO
Inżynieria Oprogramowania
Problemy
• założenie: a priori wiadomo ‘co’• proces silnie zależy od stabilności wymagań, która
w praktyce jest bardzo trudna do uzyskania• oderwanie od użytkownika• walidacja produktu następuje dopiero w końcowych
krokach• poprawa bądź konieczność dopasowania produktu do
rzeczywistych potrzeb użytkownika prowadzi do wzrostu kosztów (reguła 1:10)
• niska produktywność• błędy powodujące znaczne koszty utrzymania
© KIO
Inżynieria Oprogramowania
Inne cykle rozwoju systemów informatycznych
Klasyczny (kaskadowy)
PrototypowanieRozwój ewolucyjny i przyrostowo-ewolucyjnyPrzekształcenia formalneWielokrotne użycie oprogramowania (reuse)Ponowna inżynieria (re-engineering)
Recommended