Wykład 1 – część pierwsza

Slides:



Advertisements
Podobne prezentacje
Piotr Czekalski, ZMiTAC, Politechnika Śląska 2003
Advertisements

Modelowanie przypadków użycia
Projektowanie w cyklu życia oprogramowania
Część 2 OiZPI Iteracyjny przyrostowy model cyklu życiowego Rational Unified Process™ w materiałach wykorzystano: K.Subieta: Budowa i integracja systemów.
Role w zespole projektowym
1 / 47 WARSZAWA 2005 Przemysław Siekierko Stanisław Andraszek Rational Unified Process.
Referat 3. Planowanie zadań i metody ich obrazowania
Inżynieria Oprogramowania 9. Testowanie oprogramowania
Architektura systemu Gra strategiczna „Strusia Jama”
UML Unified Modeling Language
Węgiel jako wyrób Jacek Węglarczyk.
Co UML może zrobić dla Twojego projektu?
Dokumentowanie wymagań w języku XML
Cykle życia oprogramowania
Grzegorz Jokiel Na podstawie materiałów firmy IDS-Scheer
POWTÓRZENIE Architektura trójwarstwowa ANSI-SPARC (zewnętrzna, konceptualna i wewnętrzna); Schemat bazy danych; Logiczna i fizyczna niezależność danych.
Pomiary w inżynierii oprogramowania
Pomiary w inżynierii oprogramowania
Enteprise Java Beans Emil Wcisło.
Rational Unified Process
Wzorce projektowe w J2EE
Wstęp do programowania obiektowego
Projektowanie i programowanie obiektowe II - Wykład IV
Praca Inżynierska „Analiza i projekt aplikacji informatycznej do wspomagania wybranych zadań ośrodków sportowych” Dyplomant: Marcin Iwanicki Promotor:
Analiza i ocena procesów wdrożeniowych systemów klasy MRP/ERP w firmie
Katedra Podstaw Systemów Technicznych Politechnika Śląska
Projekt zaliczeniowy z przedmiotu "Inżynieria oprogramowania"
Analiza i projektowanie Informacyjnych Systemów Zarządzania
Projektowanie - wprowadzenie
Analiza, projekt i częściowa implementacja systemu obsługi kina
Wykład 4 Analiza i projektowanie obiektowe
Wykład 5 UML - Unified Modeling Language
Wykład 3 Analiza i projektowanie strukturalne
Wykład 2 Cykl życia systemu informacyjnego
C.d. wstępu do tematyki RUP
UML 2.x Robert Pająk.
Model przestrzenny Diagramu Obiegu Dokumentów
Wykład 1 – część pierwsza
Microsoft Solution Framework
Metodyki zarządzania projektami
Zaprojektowanie i wykonanie prototypowego systemu obiegu dokumentów (workflow) dla Dziekanatu Wydziału z wykorzystaniem narzędzi open-source i cloud computing.
Programowanie obiektowe – język C++
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
Modelowanie obiektowe Diagramy UML – diagram przypadków użycia
SPECJALNOŚĆ: Oprogramowanie Systemowe
Unified Modeling Language - Zunifikowany Język Modelowania
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski 1 informatyka +
Komputerowe wspomaganie projektowania
Diagram klas Kluczowymi elementami są: klasy (class)
Zarządzanie zagrożeniami
Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu.
Modelowanie obiektowe - system zarządzania projektami.
Copyright © Jerzy R. Nawrocki Team Software Process Inżynieria oprogramowania II Wykład.
Eksploatacja zasobów informatycznych przedsiębiorstwa.
Projektowanie obiektowe. Przykład: Punktem wyjścia w obiektowym tworzeniu systemu informacyjnego jest zawsze pewien model biznesowy. Przykład: Diagram.
Wzorce Projektowe w JAVA
Architektura Rafał Hryniów. Architektura Wizja projektu systemu, którą dzielą twórcy Struktura komponentów systemu, ich powiązań oraz zasad i reguł określających.
Wykład 2 – Zintegrowane systemy informatyczne Michał Wilbrandt.
MAS Rafał Hryniów. Agenda  Zasady  Referaty  Projekt  Kolosy.
Innowacyjne metody zarządzania jakością oprogramowania, Zarządzanie ryzykiem w metodyce PRINCE2 Jerzy Nawrocki
Z. SroczyńskiInżynieria programowania Modele cyklu życia oprogramowania Zdzisław Sroczyński
Inżynieria systemów informacyjnych
T13. Narzędzia wspomagające reengineering - wymagania.
Zarządzanie projektami informatycznymi
Inżynieria Oprogramowania Laboratorium
Cykl życia oprogramowania
Zapis prezentacji:

Wykład 1 – część pierwsza Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowania-iteracyjno-rozwojowy cykl oprogramowania

System Informacyjny =Techniczny SI zorganizowany zespół środków technicznych (komputerów, oprogramowania, urządzeń teletransmisyjnych itp.) służący do gromadzenia, przetwarzania i przesyłania informacji

I. Obszar inżynierii oprogramowania Charakterystyka kryzysu oprogramowania: 1. Przekraczanie terminów 1.1. brak właściwych technik budowy oprogramowania 1.2. brak właściwych języków programowania umożliwiających specyfikacje oprogramowania i tworzenie kodu źródłowego 1.3. brak doświadczeń w tworzeniu zespołów specjalistów, zajmujących się tworzeniem programów 1.4. nieumiejętne kierowanie przedsięwzięciem programistycznym 2. Przerywanie prac z powodu utraty aktualności przez realizowany projekt 2.1. wydłużony czas tworzenia oprogramowania, 2.2. szybki rozwój sprzętu 3. Tworzenie programów niezgodnych z wymaganiami klienta 3.1. brak właściwego sposobu porozumiewania się klienta z zespołem informatyków 3.2. brak odpowiednich norm jakości oprogramowania 3.3. niska niezawodność sprzętu i oprogramowania

Źródła powstania inżynierii oprogramowania - działu informatyki: metody opanowania kryzysu oprogramowania, trwającego od połowy lat sześćdziesiątych tworzenie oprogramowania na skalę produkcyjną. Inżynieria oprogramowania jest wiedzą techniczną, która zajmuje się: procesem wytwarzania (produkcją) oprogramowania i jakością tego procesu budową oprogramowania i jakością oprogramowania (czyli uzyskanego produktu)

II. Zagadnienia inżynierii oprogramowania 1.   Zarządzanie przedsięwzięciem programistycznym obejmujące: 1.1.  techniki planowania, szacowania kosztów, harmonogramowania i monitorowania 1.2. sposoby przygotowania dokumentacji technicznej i użytkowej 1.3. techniki pracy zespołowej 1.4. określanie poziomu umiejętności specjalistów 1.5. zastosowanie narzędzi CASE (Computer Aided System Engineering) 2.   Metody analizy, projektowania i implementacji (programowania)

3.   Pomiary oprogramowania 3.1. Wyznaczanie i badanie atrybutów wewnętrznych oprogramowania obejmujących właściwości struktury oprogramowania  metryki oprogramowania 3.2. Wyznaczanie i badanie atrybutów zewnętrznych oprogramowania: 3.2.1. jakości oprogramowania, obejmującej: niezawodność (testowalność) konserwowalność zrozumiałość wieloużywalność stopień osiągniętej abstrakcji 3.2.2. funkcjonalności 3.3.3. kosztu

4.   Kształtowanie jakości oprogramowania: 4.1.   sposoby poprawy niezawodności, konserwowalności, wieloużywalności, zrozumiałości, stopnia osiągniętej abstrakcji 4.2.  sposoby testowania i walidacji systemów 4.3.  badanie zależności między atrybutami wewnętrznymi i jakością oprogramowania 5.     Rozwój środowisk i narzędzi programistycznych

Warstwy aplikacji (Java EE)*

Pięciowarstwowy model logicznego rozdzielania zadań (wg. D. Alur, J Pięciowarstwowy model logicznego rozdzielania zadań (wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe.)

III. Modele procesu wytwarzania oprogramowania - czyli modele cyklu życia oprogramowania Tworzenie systemu informacyjnego jest powiązane z: budową oprogramowania: co i jak wykonać? zarządzaniem procesem tworzenia oprogramowania: kiedy wykonać? wdrażaniem oprogramowania Modelowanie struktury i dynamiki systemu ( diagramy UML ) Implementacja struktury ( diagramy, i dynamiki systemu generowanie kodu UML) co należy wykonać? jak należy wykonać? model przedsiębiorstwa wymagania analiza (model konceptualny ) testy modelu projektowanie (model projektowy: architektura sprzętu i oprogramowania; dostęp użytkownika; przechowywanie danych) testy projektu programowanie (specyfikacja programu : deklaracje, definicje; dodatkowe struktury danych: struktury „pojemnikowe”, pliki, bazy danych) testy oprogramowania wdrażanie testy wdrażania

Co i jak wykonać? - perspektywy projektowania obiektowych systemów informacyjnych (wg Alan Shalloway, James R.Trott) koncepcji ( co obiekty powinny powinny robić?) specyfikacji interfejsów ( jak używać obiektow?) implementacji ( w jaki sposób zaimplementować interfejs ?) tworzenia i zarządzania (obiekt A tworzy i zarządza B) zastosowania (obiekt A tylko stosuje obiekt B; zabronione jest, aby obiekt A tworzył i używał B)

Zunifikowany iteracyjno- przyrostowy proces tworzenia oprogramowania – kiedy?

Diagramy UML modelowania strukturalnego UML – język wspierający zunifikowany iteracyjno - przyrostowy proces tworzenia oprogramowania Diagramy UML modelowania strukturalnego Diagramy pakietów Diagramy klas Diagramy obiektów Diagramy mieszane Diagramy komponentów Diagramy wdrożenia Iagramy komn

Diagramy UML modelowania zachowania Diagramy przypadków użycia Diagramy aktywności Diagramy stanów Diagramy komunikacji Diagramy sekwencji Diagramy czasu Diagramy interakcji

Rola diagramów UML 2 praca zespołowa pokonanie złożoności projektu formalne, precyzyjne prezentowanie projektu tworzenie wzorca projektu możliwość testowania oprogramowania we wczesnym stadium jego tworzenia

Działanie 1: Wymagania Czynności Produkty wyjściowe Opis produktu wyjściowego lista kandydujących wymagań lista znamionowa status, szacowany koszt, priorytety, poziom ryzyka implementacji itp. zrozumienie kontekstu systemu Model dziedziny (domain model)-najważniejsze obiekty systemu: „rzeczy” lub zdarzenia podawane przez ekspertów diagram najważniejszych klas dziedziny (domain classes) z niewielką ilością operacji-metod (około 10-50 w notacji UML), reszta przewidywanych klas w glosariuszu (glossary); Model biznesowy (business model) -wewnętrzny model procesu biznesowego organizacji, wyszczególniany przez klientów systemu (customers) „business use case” : a) opis „uses cases” i „actors” odpowiadających procesowi biznesowemu (the business) oraz klientom (customers) procesu biznesowego b) biznesowy model obiektowy (business object model) składający się z wykonawców (workers), encji biznesowych (business entities), jednostek pracy (work units) realizujących „use case”,

funkcjonalne wymagania „Use-case” model (identyfikacja „use cases” z modelu biznesowego) proces reprezentowania wymagań jako „use cases” oraz innych produktów specyfikowany za pośrednictwem języka UML: 1) model „use cases” zawierający „actors” i „use cases” oraz powiązania (np. dziedziczenia) między nimi (klasy zawierające atrybuty i operacje) oraz: dodatkowo diagramy (diagrams): stanów(statecharts), czynności (activity ), sekwencji akcji (sequence) oraz współpracy (collaboration), przepływ zdarzeń (flow events)-opis tekstowy realizujących zachowanie systemu przy działaniu poszczególnych „use case” lub „actors” i „use case” - czyli opis sekwencji akcji odpowiednich do modyfikacji, przeglądu, projektowania i testowania, specjalne wymagania (spevial requirements) zawierające niefunkcjonalne wymagania (nonfunctional requirements) w postaci opisu tekstowego, 2) opis architektury (architecture description) „use cases” , 3) glosariusz (glossary) - definicje ważnych termów wyprowadzanych z modelu dziedziny (domain model) lub modelu biznesowego (business model), 4) prototyp interfejsu użytkownika (user-interface prototype)-interakcje między „actors” - ludźmi i oprogramowaniem niefunkcjonalne wymagania uzupełniające wymagania lub (supplementary requirements)-indywidualne wymagania ograniczenia środowiska i implementacji (np. typ komputera, typ plików, rodzaj systemu operacyjnego, typ oprogramowania Internetu), zależności, konserwacja, zdolność do poszerzania,