Organizacja - students.mimuw.edu.plstudents.mimuw.edu.pl/~db277594/io.pdf · Egzamin - pytania testowe ... Inżynieria oprogramowania ... programiści uaktualniają model szacowania

klucz Moodle IO1902-

witryna.mimuw.edu.pl - projekty tworzone na wydziale-

Laboratoriazespoły mniej więcej 4 osobowe-

projekt i kompilowany szkielet / prototyp-

wizjaa.specyfikacjab.koncepcjac.plan jakościd.plan projektue.

projekt systemu1)

zarządzanie komunikacją2)szkielet / prototyp (kompilowalny, uruchamialny)3)

Egzaminpytania testowe wielokrotnego wyboru z punktami ujemnymi-

uzupełnianie-

projektowanie-

ocena koocowa to (~50%) ocena z laba + ocena egzaminu (~50%)-

Organizacja19 lutego 2010

10:01

Inżynieria oprogramowania Strona 1

Inżynieria oprogramowania

systematycznego○

zdyscyplinowanego○

ilościowego○

zastosowanie-

podejście do rozwoju, eksploatacji, utrzymywania oprogramowania-

wymagania○

projektowanie○

walidacja○

ewolucja○

procesy○

Zarządzanie○

narzędzia○

API○

metody formalne ○

systemy specjalne○

komponenty○

niezawodnośd○

inżynieria oprogramowania:-

Zarządzanie Projektami Informatycznymi (monograf)○

Wytwarzanie Systemów Informatycznych (seminarium)○

dalej:-

Model wodospadowy

zadziała przy produkcji sterownika, nie zadziała przy banku internetowym-

model dobry przy dokładnej specyfikacji-

smoke test - prosty test uruchomieniowy-

Model prototypowany

Wstęp19 lutego 2010

08:36


nadaje się do większych projektów-

Model przyrostowyERP - Enterprise Rosource Planning-

iterujemy tworząc kolejne wersje - duży projekt składa się z wielu małych-

model bezpieczny - coś będzie działad - może nie wszystko, ale jakieś składniki-

Model ewolucyjny

zbieramy wymagania, produkujemy-

za jakiś czas znów zbieramy wymagania i znów produkujemy kolejną wersję w oparciu o wcześniejsze doświadczenia

-

Model spiralny


budżet rośnie z czasem, tworzymy kolejne wersje zgodnie z napływającymi wymaganiami-

de facto Agile-

Model V

analiza i projektowanie, później testowanie i integracja, testy i integracja silnie związane z powstawaniem wymagao

-

Model UP (Unified Process)


Rationalplanowanie wstępne, iteracje analizy, zbierania wymagao i produkcji, wersja ostateczna-

filozofia jest taka, że cały czas zajmujemy się wszystkim, ale z różnym natężeniem-

cały czas utrzymujemy skompilowany system, testy itd.-

nightly build - projekt cały czas się kompiluje-

Model CMMI (Capability Maturity Model Integration)model porównywania dostawców-

na każdym poziomie znajdują się praktyki, które są realizowane przez dostawcę-

Model XP (eXtreme Programming)klient wymienia cechy oprogramowania-

programista ustala zadania i pracochłonnośd-

Przygotowują testy jednostkowe○

Dodają funkcjonalnośd sprawdzając testy jednostkowe○

Naprawiają błędy jeśli testy są spełnione○

programiści programują w parach-

później integracja i produkcja-

klient ustala zadania do zrealizowania w najbliższym wydaniu-

klient prowadzi testy akceptacyjne-

programiści uaktualniają model szacowania pracochłonności na podstawie zebranych


programiści uaktualniają model szacowania pracochłonności na podstawie zebranych doświadczeo

-

Esencja


Model a metodyka

ma za zadanie upraszczad○

diagram bardzo ogólny○

model to nie programowanie wizualne○

model -

zbiór dobrych praktyk○

metodyka-

Podejścieabstrakcja-

dekompozycja-

Analiza i projektowanie

znajdowanie i opisywanie bytów / pojęd z dziedzin problemu○

analiza-

definiowanie elementów oprogramowania i sposób, w jaki b ędą współpracowad w celu spełnienia wymagao

○

projektowanie-

odpowiada na pytanie "co"○

definicja problemu○

umowa pomiędzy dostawcą a zamawiającym○

specyfikacja-

odpowiada na pytanie "jak"○

definicja rozwiązania○

projekt-

optimist of yought: We can do it over the weekend○

Marine Corps mentality: Real programmers don't need sleep○

czego chcemy uniknąd-

zasady dostosowywane w trakcie□

Agile Software Development (metodyka adaptacyjne)

lekkie (small - scale projects, 3 - 6 osób, 3 - 6 miesięcy)○

Unified Process

średnie(medium - scale projects, 20 - 30 osób, 1 - 2 lata)○

projekt jest dostosowywany do metodyki□

Capability Maturity Model Integration

ciężkie (large - scale projects, 100 - 300 osób, 3 - 5 lat)○

metodyki o różnym poziomie formalizmu-

Agile Software Developmentwymaganie będą się zmieniad-

trzeba pracowad ze zamawiającymi softwarem-

miarą postępu w projekcie jest działający software-

jakośd zapewniana poprzez prostotę projektu-

Capability Maturity Moodel Integrationbardzo formalnie-

dokładne opisy procesu decyzyjnego-

Unified Process

Specyfikacje26 lutego 2010

08:45


Unified Process

business modeling - dobre rozpoznanie rzeczywistości-

requirements - rozpoznanie wymagao-

software należy robid iteracyjnie-

konfiguracja - czy pasuje do siebie kompilator, system i kod○

configuration & change managemt-

implementacje <-> interfejsy○

implementacja komunikują się ze sobą tylko za pomocą interfejsów○

oprogramowanie należy dzielid na komponenty-

projektowanie wizualne-

Specyfikacja

pomiędzy producentem a klientem○

pomiędzy zarządzającymi a programistami○

pomiędzy architektami a programistami○

forma kontraktu-

istnieje niebezpieczeostwo niezrozumienie się○

gdy realizujemy potrzeby więcej niż jednej osoby○

gdy więcej niż jedna osoba pracuje nad projektem○

jest potrzebna gdy:-

staramy się unikad założeo niejawnych i ogólników (duży ekran)-

scenariusze-

Przykład dobrej praktykibudujemy drzewo-

powinna byd definiowana czasem, który chcemy przeznaczyd na jej tworzenie - np. spisujemy to, o wymyślimy przez tydzieo

-

wizja1)

czynności poza systemem-

automatyzacja-

procesy biznesowe2)

aktorzy-

scenariusz główny-

scenariusze alternatywne-

modele zależności-

przypadki użycia3)

Modle a metodykamodel -> co?


Modle a metodykamodel -> co?-

metodyka -> jak?-

czy zrobiliśmy wszystko, co trzeba-

czy programiści napiszą to, co trzeba-

problem kompletności oprogramowania-

Budowa wizji - podejście wszerz, a nie wgłąb

funkcjonalne-

pozafunkcjonalne-

słownikowe-

ograniczenia-

wymagania systemowe1)

wymagania zamawiającego2)wizja systemu3)

Wizjaproblem-

możliwe rozwiązania-

budowa systemu IT-

wybranie rozwiązania-

opis działania organizacji za pomocą procesów biznesowych-

wersje językowe-

przyjaznośd użytkownikowi-

zdarzenia losowe - niezawodnośd-

wydajnośd-

przykłady wymagao pozafunkcjonalnych-

wymagania powinny zostad zdefiniowane w sposób weryfikowalny-

Inżynieria wymagao

wydobywanie wymagao w oparciu o model biznesu1)analiza i negocjacja wymagao2)zatwierdzanie wymagao3)zarządzanie zmianami wymagao4)

etapy:-

Specyfikacjaspecyfikacja jest rodzajem kontraktu-

istnieje niebezpieczeostwo niezrozumienia lub zapomnienia o potrzebach klienta-

reprezentowane są potrzeby więcej niż jednej osoby-

więcej niż jedna osoba wytwarza oprogramowanie-

oprogramowanie musi byd wyspecyfikowane gdy:-

wizja1)procesy biznesowe2)przypadki użycia3)

2 i 3 opisują funkcjonalnośd-

poza tym należy jeszcze pomyśled o wymaganiach pozafunkcjonalnych-

kolejnośd działao:-

Proces biznesowyludzki opis procedury-

musi wynikad z wizji-

scenariusz wykonywania systemu z punktu widzenia firmy-

Przypadek użyciapowinien wynikad z procesu biznesowego-

scenariusz wykonania z punktu widzenia systemu-


scenariusz wykonania z punktu widzenia systemu-

scenariusz główny - podstawowy przebieg przypadku użycia

scenariusze alternatywny - inne przebiegi przypadku użycia

scenariusz to jedno z wystąpieo przypadku użycia-

niekiedy zdarzenia prowadząc w różnych kierunkach (w zależności od decyzji użytkownika)-

fraza czasownikowa w nazwie-

nadrzędny cel - czytelnośd

scenariusz główny - najbardziej prawdopodobna ścieżka

alternatywne scenariusze - kiedy coś pójdzie nie tak

aktor, scenariusz, rozszerzenia-

obojętnośd technologiczna-

budowa dobrego przypadku użycia-

Wizja

postawienie problemu1)motto dla systemu2)osoby zainteresowane, kluczowi użytkownicy3)główne cechy oprogramowania4)główne ograniczenia środowiska5)

składniki:-

functionality-

usability-

wymagania funkcjonalne-

reliability-

performance-

security-

wymagania pozafunkcjonalne-

FURPS:-

Functionality - Feature set, Capabilities, Generality, Security-

Usability - Human factors, Aesthetics, Consistency, Documentation-

Reliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure-

Performance - Speed, Efficiency, Resource consumption, Throughput, Response time-

-

Supportability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability

-

Wymagania pozafunkcjonalneprzenośnośd-

efektywnośd-

komunikatywnośd-

ustrukturyzowanie-

wydajnośd-

odpornośd na błędy-

modularnośd-

Dobra specyfikacja

czy tak ma działad system-

czy są to faktyczne wymagania-

poprawnośd-

czy wymagania mają tylko jedną interpretację-

każde stwierdzenie może byd odczytane dokładnie w jeden sposób-

pojęcia mylące definiowane są w słowniku-

jest przejrzysta (zrozumiała dla nie-informatyków)-

jednoznacznośd-

czy zamieszczono wszystkie wymagania funkcjonalne i pozafunkcjonalne-

brak elementów wymagających uzupełnienia (kompletnośd strukturalna)-

określa wszystkie rzeczy, które system ma robid oraz wszystkie rzeczy, których robid nie ma-

kompletnośd-

koniecznośd


http://en.wikipedia.org/wiki/Functional_requirements

http://en.wikipedia.org/wiki/Usability

http://en.wikipedia.org/wiki/Reliability_engineering

http://en.wikipedia.org/wiki/Computer_performance

http://en.wikipedia.org/wiki/Supportability

czy zawiera wszystkie elementy istotne dla zamawiającego-

czy nie zawiera elementów niepotrzebnych-

koniecznośd-

czy wymagania zamawiającego są zgodne z wizją i niesprzeczne ze sobą-

czy nie przeczy sobie-

jednolicie korzysta z pojęd-

spójnośd-

atrybuty umożliwiające określenie wagi i znaczenia-

możliwośd porządkowania (priorytetyzacja)-

czy każde wymaganie ma przyporządkowane kryterium jakości-

istnieje procedura pozwalająca przetestowanie każdego z wymagao-

każde wymaganie jest opisane deklaratywnie-

weryfikowalnośd-

czy można w łatwy sposób wprowadzad zmiany do specyfikacji wymagao-

dobrze zorganizowana-

minimalna redundancja-

możliwośd śledzenia-

coupling factor - współczynnik zależności pomiędzy modułami-

modyfikowalnośd-

zachowywanie zależności z wcześniej otrzymanymi fragmentami dokumentacji - specyfikacja wynika z przypadków użycia

-

utrzymywanie śladu-

Jeden system - różne perspektywy

model logiczny1)kod wynikowy2)warstwa fizyczna3)

strukturaa)

przypadki użycia1)algorytmy działania2)interakcje między obiektami3)maszyny stanowe4)

zachowanieb)

rozłączne tworzenie specyfikacji i projektu pozwala na późniejszą weryfikację całości-

Co jest najważniejsze dla sukcesu projektu?Wiarygodne oszacowanie1)Jasne cele biznesowe2)Doświadczony menedżer3)Wykwalifikowany zespół4)Zaangażowanie użytkowników5)Stałe ograniczenie zakresu6)Formalna metodyka7)Zaangażowanie użytkowników8)Elastyczne podejście do wymagao9)Standardowa architektura10)

model - warstwa składowania○

widok - warstwa prezentacji○

kontroler - logika systemu○

model trójwarstwowy:

Abstrakcja i dekompozycja

analogie-

ukrywanie szczegółów-

upraszcza problem○

nie rozwiązuje problemu○

abstrakcja

podproblemu podobnej wielkości○

podproblemy można rozwiązywad niezależnie

dekompozyjca


podproblemu podobnej wielkościpodproblemy można rozwiązywad niezależnie○

ze składania rozwiązao podproblemów otrzymuje się rozwiązanie problemu○

Zalety Wady

można przypisad podzadania różnym osobom

-

podzadania można rozwiązywad równolegle-

łatwo utrzymywad system w przyszłości-

można ukryd nieistotne szczegóły-

scalanie podrozwiązao może stanowid problem-

problem źle zrozumiany nie da się dobrze zdekomponowad

-

ukrywanie szczegółów nie rozwiązuje problemu-

Perspektywy

UMLdiagram pakietów-

diagram klas i diagram obiektów-

diagram struktur złożonych-

diagram komponentów-

diagram wdrożenia-

diagram przypadków uzycia-

diagram czynności-

diagram maszyny stanowej-

diagramy interakcji (sekwencji, komunikacji, przeglądu interakcji)-

diagram uwarunkowao czasowych-



Przypadki użycia


Przypadki użycia

Model dziedzinowy / klas / interfejsów / danych


UML definiuje 4 poziomy widoczności cech i metod• + publiczny –element jest widoczny z każdego miejscaw systemie• # chroniony – element jest widoczny we własnej klasie ijej podklasach• – prywatny – element jest widoczny tylko we własnejklasie• ~ publiczny wewnątrz pakietu –element jest widocznytylko wewnątrz własnego pakietu

Maszyna stanowa


Maszyna stanowa

Interakcje


Aktywnośd


Komponenty, wdrożenie


Warstwy



MTBF - Mean Time Between Failures-

Edgar Dijkstrahow software is partitioned and structured is important-

not merely simply programming a „correct”solution-

Fred BrooksSystem Architecture-

by the architecture of the system I mean the complete and detailed specification of the user interface…-

the architect of a system, like the architect of a building, is the user’s agent-

David Parnasinformation hiding as the basis of decomposition for ease of maintenance and reuse-

the separation of interface from implementation of components-

observations on the separate character of different program elements-

the “uses” relationship for controlling the connectivity between components-

principles for the detection and handling of errors, i.e. exceptions-

identifying commonalities in “families of systems” to provide coarse-grained, stable common structures-

recognition that structure influences nonfunctional ‘qualities’ of a system-

Przetwarzanie potokowe (pipe - and - filter)kolekcja programów ułożona w łaocuch-

przykład: Latex-

Klient - serwerlogika i większośd obliczeo jest realizowana u klienta-

przykład: gry sieciowe, Outlook-

Peer - to - Peersied zestawiana ad-hoc-

Architektura trójwarstwowa (3 - tier)warstwa danych1)warstwa logiki2)warstwa prezentacji3)

Architektura wielowarstwowa (n - tier)

okienka UIa.HTML, XML, JSP, Javascriptb.

prezentacja1)

workflow, stan sesji, zmiana stron / okiena.obsługuje żądania warstwy prezentacjib.

aplikacja2)

obsługuje zadania warstwy aplikacjia.usługi dziedziny (Kasa, Magazyn)b.może byd wykorzystywana przez kilka aplikacjic.

dziedzina (biznes, usługi biznesowe, model)3)

niskopoziomowe usługi biznesowe wykorzystywane w wielu dziedzinacha.infrastruktura biznesowa (niskopoziomowe usługi biznesowe)4)

bezpieczeostwo, utrwalaniea.wysokopoziomowe usługi techniczneb.

usługi techniczne5)

struktury danych, obsługa wątkówa.niskopoziomowe usługi techniczneb.

podstawy6)

Perspektywa historyczna

Architektury19 marca 2010

09:33


Perspektywa historyczna

Sevice oriented architecturefunctionality ważniejsze od connectivity-

mainframe1)klient serwer2)Web3)SOA4)

ery architektury-

osiągamy przełom technologiczny pomiędzy mocą obliczeniową a możliwością łączności-

SOA - składanie usług zaawansowanych z rozproszonych usług sieciowych-

usługi tworzą rozróżnialne poprzez standaryzację klasy abstrakcji○

katalogi○

dobrze zdefiniowane○

samowystarczalne○

zawsze i łatwo dostępne○

nie jest istotne, kto jest klientem

niezależne od kontekstu konsumenta○

konkurowanie zakresem a nie sposobem implementacji

bardzo konkurencyjne○

można łączyd○

Usługa-

EDI - elektroniczny obieg dokumentów-

BPM - business process managing (procesy biznesowe)-

WS - web services-

Workflow - obieg informacji, obieg zadao-

podobne klocki składa się w nowe narzędzia-

Aktorzy

wyraża zamiar○

konsument-

udostępnia ofertę○

dostawca-

znajduje najlepszą ofertę○

reklamuje oferty na różne sposoby

broker-


znajduje najlepszą ofertę

odpowiadające różnym zamiarom

reklamuje oferty na różne sposoby○

zapewnia usługę katalogową ("yellow pages")○

podejście dawne - wywalamy istniejące systemy i budujemy jeden super system-

aplikacje klienckie odwołują się do rejestru usług, a dopiero później do konkretnych systemów poprzez XML'a

○

podejście współczesne - tworzymy rejestr usług na bazie istniejących systemów-

autentykacja - ustalenie tożsamości-

autoryzacja - ustalenie praw dostępu-

SOAP - simple object acces protocol - protokół zdalnego wywoływania objektów - dawne rozwiązanie-

WS* - web services* - aktualne rozwiązanie służące się do łączenia z web servisami-

MVC

SOA vs Komunikatyusługami sterują komunikaty-

ważna jest treśd komunikatu, a nie warstwy transportowe-

różne struktury komunikatów-

komunikaty idempotentne (kilkukrotne wywołanie nie skutkuje niczym negatywnym)○

komunikacja niezawodna○

pytanie, czy dopuszczamy utratę komunikatów:-

SOA vs Web Servicesotwarty standard oferowanych usług-

różne zestawy informacji○

metadane○

możliwośd wymiany dokumentów strukturalnych-

niewielkie nakłady na konsumpcję usługi○

XML, WSDL

przyjmowanie komunikatów nie w pełni rozumianych○

lokalizacja niezależna od mechanizmu wywołania + katalogi usług

późnie wiązanie○

luźne powiązania-

niewydajny i ograniczający model interakcji

request / response○

zacierają się granice między klientem a serwerem

wzrost poziomu gradualności○

możliwe interakcje peer-to-peer-

SOA vs ESB

działa jak broker komunikatówkręgosłup SOA-


działa jak broker komunikatów○

proste kolejkowanie□

MQ - message queue

potrafi również zarządzad komunikatami□

potrafi zmieniad format komunikatów, tłumaczyd jedne na drugie□

MB- message brocker

zapewnia system kolejkowania komunikatów ○

np. SOA lub JMS

standard przemysłowy wymiany komunikatów○

zapewnia współpracę aplikacji wysokopoziomowych z niskopoziomowymi poprzez standardowe adaptery i interfejsy

-

dawniej architektura spagetti, teraz szyny-

Otwarty standard oferowania usług-

Różny zestaw informacji, metadane (informacje o informacji)○

Możliwośd wymiany dokumentów strukturalnych-

Niewielkie nakłady na konsumpcję usługi○

XML, WSDL

Przyjmowanie komunikatów nie w pełni rozumianych○

Późne wiązanie○

Lokalizacja niezależna od mechanizmu wołania + katalogi usług○

Luźne powiązanie-

Niewydajny i ograniczający model interakcji

Request / response○

Zacierają się granice między klientem a serwerem

Wzrost poziomu granularności○

Możliwe interakcje peer-to-peer-

SOA vs BPMBPM - bussines process modeling-

konstruowanie komponentów oprogramowania○

komponenty mogą byd reużuywane w nieznanym w momencie projketowania kontekście○

kompozycja vs rozszerzanie (OO)○

SOA-

precyzyjnego modelowania

zmiany

kontekstu w którym komponenty (przedsiębiorstwa) są wykorzystywane

zdolnośd do ○

BPM-

Przejście na architekturę zorientowaną usługowo


Przejście na architekturę zorientowaną usługowo

Dotarcie do SOAOsiągnięcie przez organizację kontroli nad zasobami IT-

Zorganizowanie logiki biznesowej w sposób niezależny od kontekstu jej wykorzystania-

Orkiestracja

Choreografia

Wykorzystanie technologii „koordynacji”○

Ponowna implementacja warstwy kontrolera-

Stworzenie nowej warstwy widoku-

Wymagane dobre rozumienie własnego biznesu○

Jest to inwestycja (usług >= procesów)○

Może byd dużym narzutem dla małych przedsiębiorstw○

Problemy-

Kiedy nie warto wdrażad SOA?

SOA może nie byd istotne○

SOA może byd nieefektywne kosztowo○

Stabilne, homogeniczne środowiska IT-

Nie ma potrzeby zapewnienia elastyczności○

Organizacja nie oferuje i nie wykorzystuje usług opartych na IT-

SOA bazuje na luźno powiązanej komunikacji asynchronicznej○

Systemy czasu rzeczywistego-

Podsumowaniezorientowanie na usługi to nowy paradygmat obliczeniowy-

koncepcja konstrukcji oprogramowania-

Większej ilości konsumentów○

Nieznanego kontekstu○

SOA wymusza postrzeganie oprogramowania przez pryzmat:-

SOA jest ciągle przed nami: ewolucja, nie rewolucja-

Podnosi poziom abstrakcji i reużywalnośd systemów IT-

Możemy oczekiwad trendu do posiadania i publikowania-

Już się zaznacza (np. Google)○

Dotknie szczególnie aplikacji Mainframe i Klient/Serwer (ERP, CRM, …)○

usług

Może stad się koszmarem, jeśli uwzględnimy ryzyka bezpieczeostwa○

Potrzeba zapewnienia zbieżności standardów

Nie wszystkie technologie są dojrzałe○

Oprogramowanie będzie bogatsze i sprytniejsze-



zestrzelenie Airbusa 320 - 1988-

śmierd pacjentów chorych na raka, 1985 - 1987-

pentium floating point, 1994-

rakieta Ariane 5, 1996-

Czym jest jakośd?

mierzenie jakości w trakcie produkcji○

związek jakości produktu z jakością procesu wytwórczego○

jak można zmierzyd jakośd-

normy i standardy jakości○

dojrzałośd firm wytwarzających oprogramowanie○

jak można porównywad jakośd poszczególnych dostawców-

w USA najbardziej zainteresowane jakością jest wojsko-

jakośd konstrukcji○

wartośd estetyczna○

zgodnośd z oczekiwaniami○

mierzenie jakości krzesła-

wszystkie miary jakości są względne-

jeśli nawet uda się ustalid, co jest lepsze, to i tak ciężko stwierdzid, o ile lepsze-

oprogramowanie nie powstaje w procesie manufaktury

jakośd konstrukcji○

zdecydowana większośd napisanego oprogramowania jest niewidoczna

wartośd estetyczna ma znaczenie w przypadku interfejsu użytkownika, ale jest to element marginalny z punktu widzenia jakości

wartości estetyczne○

wymagałoby prawdziwego zrozumienia przeznaczenia systemu

zgodnośd z oczekiwaniami○

mierzenie jakości oprogramowania-

Klasyczne podejście

robi to, co trzeba○

da się je rozszerzad○

działa niezawodnie○

działa szybko○

jest bezpieczne○

jest ergonomiczne○

jest w odpowiedniej cenie○

oprogramowanie jest dobrej jakości jeśli jest dopasowane do potrzeb-

Jakośd trzeba mierzydpotrzeba zamienienia nieprecyzyjnych pomysłów w konkretne miary-

pojęcia abstrakcyjne○

koncepcje jakości-

co mierzyd

definicje metryk○

pojęcia mierzalne-

jak mierzyd?realizacja metryk○

pobranie pomiarów-

Jakośd9 kwietnia 2010

08:40


jak mierzyd?

run it and count crashes per hour

mean time to failure?○

reliability-

count procedure calls

information flow between modules?○

complexity-

minutes taken for some user task?

time taken to leran how to use?○

usability-

Cztery najważniejsze elementy?

czy robi wszystko co trzeba?□

czy obsługuje wszystkie dane wejściowe?□

kompletnośd

czy zawsze zachowuje się zgodnie z oczekiwaniami?□

spójnośd

czy dobrze zachowuje się w warunkach niestandardowych?□

odpornośd

projektant musi przewidzied jak się system zachowa-

niezawodnośd-

w większości przypadków jest to mniej istotne niż niezawodnośd

wykorzystanie zasobów takich jak czas procesora, pamięd, przepustowośd sieci-

wydajnośd-

działania doskonalące, adaptujące, naprawcze

jak łatwo można będzie w przyszłości modyfikowad oprogramowanie?-

pielęgnowalnośd-

jak łatwe jest w użyciu-

użytecznośd-

Jakośdjakośd trzeba przewidywad-

może nie da się mierzyd jakości przed ostatecznym uruchomieniem systemu-

jakośd może się różnid zależnie od środowiska-

jakośd jest miarą relacji pomiędzy oprogramowaniem a dziedziną zastosowao-

należy rozumied potrzeby (inżynieria wymagao)-

należy szukad wyznaczników jakości-

podczas projektowania musi byd możliwe przewidywanie jakości-

Generalnie

kontrola jakości-

zapewnianie jakości-

dwa najważniejsze elementy-

mała i duża skala projektu-

dodatkowo-

Kontrola jakości

czy budujemy właściwy system-

subiektywne-

trudno to stwierdzid-

zestaw przypadków testowych (najlepiej jak najwcześniej zdefiniowanych)-

walidacja-

czy budujemy system prawidłowoweryfikacja-


czy budujemy system prawidłowo-

może byd obiektywne-

techniki kontroli jakości-

porównywanie oprogramowania ze specyfikacją - weryfikacja (jeśli specyfikacja jest techniczna, to byd może da się to zrobid automatycznie)

-

porównanie oprogramowania ze światem - walidacja-

Przypadek testowy

prawie jeden do jednego względem scenariuszy w przypadkach testowych-

pochodna przypadku użycia-

scenariusze testowe - pochodne przypadków biznesowych-

trzeba byd w stanie śledzid zależności pomiędzy przypadkami użycia, procesami biznesowymi i przypadkami testowymi

-

konieczne jest opisanie stanu systemu-

Walidacjaczy system realizuje to, co trzeba?-

świat-> analiza -> projekt -> system-

subiektywne-

Weryfikacjaczy oprogramowanie jest zgodne ze specyfikacją-

może byd obiektywne-

zależy od jakości specyfikacji-

wykrycie błędów w systemie

sprawdzanie, czy system się do czegoś nadaje

cele:-

walidacja i weryfikacja muszą byd wykonywane przez cały czas realizacji projektu-

Trzy sposoby kontroli

system jest uruchamiany z danymi testowymi-

testowanie-

analiza statycznej reprezentacji systemu w celu wykrycia problemów-

inspekcje (review)-

metody formalne-

Testowaniekto ma testowad-

jak testowad-

co poddawad testom-

gdy kary za opóźnienie są o wiele większe od kar za błędy-

gdy system ma byd odpalony tylko raz-

nietestowanie może mied sens -

decyzję na temat jakości należy podjąd na samym początku-

losowe testy nie wystarczą-

Podejście systematyczne

podziel zachowania systemu na grupy-

dla każdej grupy wybierz reprezentatywne próbki-

upewnij się, że uwzględniono wszystkie grupy-

systematyczne testowanie opera sie na partycjonowanmiu-

jak zidentyfikowad dobry podział?


czarna skrzynka (black box)

przezroczysta skrzynka (white box)

metody wyboru przypadków testowych-

jak zidentyfikowad dobry podział?-

Przypadek testowydane wejściowe-

stan wstępny-

zaobserwowane wyjście-

migawki maszyny wirtualnej-

zrzuty bazy danych i plików konfiguracyjnych-

skrypty zapełniające / czyszczące dane programu-

istnieją narzędzia półautomatyczne-

Czarna skrzynkagenerowane na podstawie specyfikacji-

nie patrzymy na kod programu-

unikanie przyjmowania tych samych założeo, co programista-

dane testowe są niezależne od implementacji-

wyniki można interpretowad bez wnikania w szczegóły systemy-

zalety:-

pokrywają klauzule "wymaga, modyfikuje, wpływa na"

ścieżki specyfikacji-

Szukaj błędów w aliasach (dwa parametry odnoszące się do tego samego obiektu)

warunki brzegowe-

niepoprawne dane wejściowe

przypadki nienormalne-

sugestie wyboru przypadków-

Przezroczysta skrzynka

czarna skrzynka może nie spowodowad wykonania całego kodu-

badanie kodu i testowanie ścieżek w kodzie-

zestaw testów pokrywa komplet instrukcji jeśli każda instrukcja w kodzie jest wykonywana co najmniej raz w zestawie testów

-

kompletnośd instrukcji-

zestaw testów pokrywa komplet ścieżek, jeśli każda ścieżka w kodzie jest wykonywana co najmniej raz w zestawie testów

-

kompletnośd ścieżek-

Pokryciepokrycie instrukcji (statement coverage)-

instrukcja warunkowa musi byd przynajmniej raz prawdziwa i przynajmniej raz fałszywa-

pokrycie gałęzi-

Atrybuty procesu testowaniapowtarzalne-

trzeba wybierad zestawy testów pokrywające cały zakres działania programu-

należy wybierad testy które są reprezentatywne dla rzeczywistych zastosowao-

systematyczne-

dokumentowane-

Testy jednostkowepisz test, nim napiszesz moduł-

przypadek użycia -> przypadek testowy-

każda jednostka / moduł testowany jest oddzielnie


czy spełnia specyfikację-

nie ma modułu bez testu-

każda jednostka / moduł testowany jest oddzielnie-

extreme programming-

Testy integracjiczy moduły współpracują ze sobą-

bottom up (po odwróconym grafie)-

top down (stubs)-

podejścia:-

chcemy go minimalizowad-

na tym polega architektura komponentowa-

coupling factor - współczynnik powiązao pomiędzy systemami -

często wykrywają błędy specyfikacji a nie błędy integracji-

Testy systemowena poziomie całej aplikacji-

testowanie funkcjonalności-

facility testing –Czy system zapewnia wszystkie wymagane funkcje?-

volume testing –Czy system radzi sobie z dużą ilością danych?-

stress testing –Czy system radzi sobie z dużym obciążeniem?-

endurance testing –Czy system zachowuje parametry w długim okresie?-

usability testing –Czy system jest łatwy w użyciu?-

security testing –Czy system wytrzymuje ataki?-

performance testing – Jak dobry jest czas reakcji systemu?-

storage testing –Czy pojawiają się problemy ze składowaniem danych?-

configuration testing –Czy system działa na wszystkich platformach?-

installability testing –Czy da się skutecznie zainstalowad system?-

reliability testing – Jak zmienia się niezawodnośd systemu w czasie?-

recovery testing – Jak skutecznie system podnosi się po awarii?-

serviceability testing –Czy daje się pielęgnowad system?-

documentation testing –Czy dokumentacja jest dokładna? Adekwatna?-

operations testing –Czy instrukcje operatorów są poprawne?-

Testy pozafunkcjonalne-

Test regresjiponowne wykonanie opracowanych wcześniej testów-

Test uruchomieniowy (smoke test)czy program się uruchamia-

wersja minimalna testowania regresywnego-

JUnit - testy jednostkowe-

Testowanie a debugowanietestowanie - koncentruje się na znajdowaniu błędów-

debugowanie - zajmuje się lokalizacją i usuwaniem błędów-

Inspekcjeznaczenie zmniejszają liczbę błędów-

poprawianie kodu podczas inspekcji jest taosze, niż podczas debugowania lub już po wydaniu-

koszty naprawy danych są bardzo wysokie-

wpływ na morale zespołu, mniejsza rotacja-

lepsze rozpoznanie możliwości zespołu-


Ograniczenia inspekcjidobry zespół - max 6 osób-

min 3, max 7 osób podczas inspekcji-

czas - max 2 godziny (spada koncentracja)-

wszyscy muszą się zgadzad-

podsumowanie (raport - szczegółowa lista zagadnieo)-

wyniki-

skupiamy się na małym fragmencie - 150 LOC / h-

nie za wcześnie - autor świadom błędów-

nie za późni - nic to już nie da-

przegląd po zakooczeniu prac autora-

harmonogram-

Wytyczne inspekcjiprzed spotkaniem należy jasno zdefiniowad cel i oczekiwane efekty-

niezbędny lider-

fakt inspekcji należy zapisad-

uczestnicy powinni móc przygotowad się do inspekcji-


opisuje zależności pomiędzy różnymi komponentami-

bazowa○

przed wydaniem○

dla zadao○

gałęzie przy zarządzaniu wersjami-

można zdad się na integratorów-

kontrola wersji○

zarządzanie zmianą○

budowanie wydao○

zarządzanie konfiguracją-

dodanie zależności od kolejnej biblioteki wymaga uzgodnieo○

zmiany w makefile'u wprowadza tylko jedna osoba - sposób na ograniczenie coupling factoru

-

Specyfikacja (funkcjonalna, pozafunkcjonalna)○

Projekt, model○

Prototyp○

Kod źródłowy○

Testy (jednostkowe, użytkownika)○

Wydania (binaria)○

Instrukcja instalacji○

Lista zmian (w stosunku do wydania poprzedniego)○

Lista znanych błędów○

Podręczniki (użytkownika, administratora)○

Harmonogram○

Notatki robocze zespołu○

co powstaje przy produkcji oprogramowania:-

równoległa praca nad różnymi fragmentami kodu○

identyfikacja i przechowywanie różnych wersji dokumentów○

wersje dokumentów a wersje produktów○

analizowanie histori - kto, kiedy, jaka zmiana○

praca nad nową wersją systemu i poprawianie błędów w starej○

Wyzwania:-

Zarządzanie konfiguracjąkontrola wersji1)zarządzanie zmianą2)budowanie wydao3)

Kontrola wersjikomunikacja z centralnym systemem-

kopia lokalna repozytorium i wprowadzanie zmian w centralnym repozytorium na żądanie-

etykiety-

bazowa○

przed wydaniem○

dla zadao○

gałęzie-

Zarządzanie konfiguracją23 kwietnia 2010

08:56


Pytania do systemu zarządzania konfiguracjąJaka platforma jest wymagana dla danej wersji systemu?-

Które wersje systemu są zależne od zmiany danego komponentu?-

Ile błędów zgłoszono do danej wersji?-

Jakie komponenty zmodyfikowano przy realizacji danej zmiany?-

Budowanie wydao

Przyrostowa zmiana systemu jaka może byd włączona do nowego wydania jest w przybliżeniu stałego rozmiaru

-

Jeśli zbyt wiele nowych cech zostanie włączonych razem z poprawkami błędów, wówczas koszt przygotowania nowego wydania znacząco wzrasta

-

Jeśli do wydania włączono wiele zmian, musi nastąpid po nim wydanie poprawiające błędy wynikające ze zmian wprowadzonych w pierwszym wydaniu

-

dobre praktyki-

Plan zarządzania konfiguracja

artefakty podlegających zarządzaniu konfiguracją-

standardy nazewnictwa-

role odpowiedzialne za tworzenie linii bazowych-

procedury kontroli zmian i wersjonowania-

zasady wglądu klienta w rejestry-

definiuje-

system kontroli wersji

system śledzenia zmian

narzędzia wspierające zarządzanie konfiguracją-

system budowania wydao-

konfigurację narzędzi odpowiadającą przyjętej procedurze-

uprawnienia użytkowników w systemie-

opisuje-

Narzędzia kontroli wersji

System przydziela identyfikatory automatycznie podczas zgłaszania nowej wersji pliku do systemu

-

Identyfikacja wersji i wydao systemu-

Tylko jedna wersja w danej chwili może podlegad zmianie. Można równolegle pracowad nad różnymi wersjami.

-

Kontrolowanie zmian-

Przechowywanie różnid a nie pełnych nowych wersji-

Dla danych tekstowych jak też binarnych-

Zarządzanie przestrzenią dyskową-

Zapamiętuje uzasadnienia wprowadzenia zmian-

Rejestrowanie historii zmian-

Narzędzia budowania systemu - problemyczy uwzględniono wszystkie wymagane komponenty?-

czy wskazano właściwą wersję komponentu?-

czy wszystkie pliki z danymi są dostępne?-

czy odwołania do plików / komponentów są poprawne?-

czy system jest budowany na właściwą platformę?-

czy wykorzystywana jest właściwa wersja kompilatora i narzędzi deweloperskich?-

Narzędzia śledzenia zmianGłównym zadaniem śledzenie statusów zgłoszonych zmian/błędów-

Automatycznie zapewnia że zmiany są przekierowywane do właściwych osób (np. do właścicieli komponentów, których zmiany dotyczą)

-

Organizuje współpracę w ramach zespołu


właścicieli komponentów, których zmiany dotyczą)Organizuje współpracę w ramach zespołu-

Integracja z pocztą elektroniczną zapewnia powiadamiania i eskalację problemów-

Zarządzanie zmianą


Podstawowe pytaniaile potrzeba pracy1)jaki jest całkowity koszt2)ile dni kalendarzowych jest potrzebne3)jaki zespół jest potrzebny4)

Oszacowanie pracochłonności - sposoby

metoda punktów funkcyjnycha.metoda punktów obiektowychb.

metryki1)

struktura podziału pracya.diagram sieciowyb.zrównoważenie zasobówc.

ekspertyzy2)

szacowanie na podstawie wielkości kodu źródłowegoa.inne3)

Metoda punktów funkcyjnychbazujemy na opisie funkcjonalności-

wybór języka

technologiczne○

rodzaj zespołu

środowiskowe○

przypadki użycia

aktorzy

funkcjonalne○

uwzględniamy aspekty-

Aspekt technologiczny

Aspekt środowiskowy

Planowanie30 kwietnia 2010

08:39


Przypadki użycia

Aktorzy


Wynik

Struktura podziału pracy (WBS)Work Breakdown Structure-

definicja zakresu projektu-

co jest częścią czego○

hierarchiczna list czynności - drzewo-

abstrakcja○

dekompozycja○

tworzona w oparciu o podstawowe techniki-

jakośd bazuje na jakości ekspertów-

kto jest odpowiedzialny○

ile czasu potrwa realizacja○

ile będzie kosztowad?○

stopieo szczegółowości (dla każdego liścia)-


Diagram sieciowy (diagram projektu)

jedno źródło, jedno ujście○

co zależy od czego - w jakiej kolejności należy budowad-

ustalenie logiki-

jest to długośd projektu○

najwcześniejsze rozpoczęcia

najpóźniejsze zakooczenie

dla każdej czynności○

ścieżka krytyczna - najdłuższa (z wagami) ścieżka od startu do zakooczenia-

wynikiem jest graf zależności-

jedno źródło i jedno ujście-

ścieżki w grafie, ścieżka krytyczna-

niepewnośd oszacowania-

najpóźniejsze zakooczenie - najwcześniejsze zakooczenie○

czynnośd na ścieżce krytycznej ma zapas zerowy○

wolny zapas○

całkowity zapas○

zapas zadania-

najdłuższa (z wagami) ścieżka od źródła do ujścia○

ścieżka krytyczna-


Wykres Ganttametoda tworzenia harmonogramu-

przydział zasobów do zadao-

zależności-

podział zadao-

kamienie milowe (milestones)-

Skracanie harmonogramu

wzrasta znaczenie komunikacji○

wzrasta ryzyko opóźnieo○

próba zrównoleglenia-

wykorzystanie dodatkowych zasobów○

minimalizacja kosztów dodatkowych zasobów○

skracanie zadao-

Histogram zasobówobciążenie zasobów w jednostkach czasu-

identyfikacja przeciążenia zasobów-

Wyrównywanie zasobówHeurystyki-

W konsekwencji wydłużenie harmonogramu-

Zarządzanie metodą łaocucha krytycznego

oszacowania czasu trwania są zazwyczaj "bezpieczne" - pesymistyczne○

pracownicy nie są nagradzani za wcześniejsze ukooczenie ale karani za opóźnienia○

Założenie 1-

prawo Parkonsona: praca trwa tyle, ile na nią przeznaczymy○

syndrom Studenta: mając świadomośd marginesu bezpieczeostwa rozpoczynamy zadanie jak najpóźniej

○

Założenie 2-

praca w trybie wielozadaniowości wydłuża czas pracy○

Założenie 3-

np. skród prawdopodobny o połowę○

oblicz czas agresywny-

harmonogramuj zadania jak najpóźniej-

wyeliminuj konflikty zasobów-

określ łaocuch krytyczny - zadania nie przesuwalne-

zasobów (dla poszczególnych zasobów)○

projektu (jeden na koocu)○

zasilające (na stykach ze ścieżką krytyczną)○

identyfikacja i rozmieszczenie rezerw-

zarządzanie rezerwami w trakcie trwania projektu-

zamiast tego odbieramy dni przerwy○

celem jest ograniczenie sytuacji polegającej na tym, że zadanie idzie dobrze, więc robimy przerwę, więc na koniec brakuje nam jednego dnia

-

pozwalamy sobie na opóźnienia zadao - po to jest rezerwa-

Zarządzanie rezerwami

nie podejmuj żadnych kroków○

do 1/3 wykorzystanej rezerwy-

do 2/3 wykorzystanej rezerwy


planujemy czynności naprawcze○

do 2/3 wykorzystanej rezerwy-

wdrażamy czynności naprawcze○

ponad 2/3 wykorzystanej rezerwy-

Jak wycenid system informatyczny

projekt kosztuje tyle, ile klient jest w stanie za niego zap łacid-

dostajemy kontrakt-

Prawdopodobieostwo, że klient dostanie system który zamawia jest małe-

Koszty nie odzwierciedlają wymaganej pracy-

wycenid by wygrad-

robiliśmy już coś podobnego○

koszty proporcjonalne do rozmiarów○

analogia-

iterowane konsultacje z ekspertami○

opinia ekspertów-

koszt jest szacowany na podstawie dostępnych zasobów a nie celów○

Work expands to fill in time available"○

Jeśli 5 osób ma wytworzyd system w 12 miesięcy, to koszt odpowiada 60 osobomiesiącom○

Prawo Parkinsona-

pensje inżynierów

koszty ubezpieczeo itd.

oszacowanie pracochłonności○

sprzęt, oprogramowanie, narzędzia○

podróże, szkolenia○

wynajem budynków, oświetlenie itd.○

sied i komunikacja○

elementy współdzielone - biblioteka, kantyna, recepcja○

podejście analityczne-


metodyki adaptacyjne, giętkie, agile-

hurra, działa-

powtarzanie○

kiedy nie będzie działad?-

jakie ma ograniczenia?-

czy to właściwa procedura?-

spróbujmy ją dostosowad-

rozumienie○

wiedza zintegrowana-

pojedyncze techniki nie mają znaczenia-

biegłośd○

etapy nabywania nowych umiejętności-

Poziomy metodykmetodyka - zestaw praktyk, technik, metod, procesów-

bazowanie na procesach○

poziom 1-

identyfikowanie technik praktycznie stosowalnych○

poziom 2-

podejście pragramtyczne○

poziom 3-

należy unikad mieszania poziomów-

zupełna losowośd

poziom 1○

poziom 2○

Capability Maturity Model Integration - sposób oceny dojrzałości firm-

ISO zapewnia przewidywalnośd-

w każdej iteracji musi byd czegoś konkretny przyrost○

Rational Unified Process-

AgileManifestindywidualizm i interakcja ważniejsza niż procesy i narzędzia-

pracujący software a nie szczegółowa dokumentacja-

współpraca z klientem a nie negocjacja kontraktu-

odpowiedzi na zmiany a zamiast ścisłego trzymania się planu-

chodzi o zadowolenie klienta-

software powinien byd wydawany często (chod po kawałku)-

codziennie-

trzeba się często spotykad-

lepiej dyskutowad w cztery oczy a nie za pomocą dokumentów-

im mniej warstw tym większa szansa, że efekt będzie dobry-

zespoły potrafią się same organizowad-

budowanie projektów wokół zmotywowanych indywidualistów-

działający software miar ą sukcesu-

ciągły rozwój-

uwaga skierowana na dobre rozwiązania techniczne i właściwe projektowanie-

prostota - maksymalizacja pracy nie włożonej

Metodyki adaptacyjne14 maja 2010

08:35


prostota - maksymalizacja pracy nie włożonej-

Procesy

rozumienie, co należy zrobid i jak○

powtarzanie dobrych pomysłów○

unikanie błędów○

procesy-

Pracowad efektywnie○

Uniknąd kosztownych błędów○

Określid co jest ważne, a co nie○

Świadomie i z pełnym przekonaniem podejmowad decyzje○

Dobry proces pomaga:-

1 - 3 dni○

cowboy coding / marine corps mentality-

dużo prostych, ale najlepszych zasad○

mały zespół○

extreme programming-

dużo wzroców, rozszerzenie XP○

średni zespół○

scrum-

dużo zasad i ról○

duże projekty○

RUP-

olbrzymie projekty○

CMMI-

mały projekt wcale nie jest taki mały - mały zespół programistów + wiele osób zależnych-

w jednym pomieszczeniu○

może byd za pomocą przedstawiciela○

klient musi pracowad razem z deweloperami-

klient○

deweloper○

najważniejsze role-

pisze skrypty testowe na podstawie rozmów z klientem

tester○

pomaga rozwiązywad napotykane problemy

tunning bazy danych

zarządzanie projektem, metodyką

ktoś znający dziedzinę

coach○

zbiera stytystyki dotyczące zadao / czasu pracy

tworzy podsumowania

tracker○

role pomocnicze-

wzajemne zaufanie klient - zespół-

tworzenie krótkich "opowieści użytkownika"○

każda opowieśd zapisana○

opowieści nie są szczegółowe - krótkie - na jednej kartce○

ma pomóc ustalid zakres, a nie służyd do kodowania○

każda opowieśd powinna byd testowalna○

opowieśd to nie jest kompletne wymaganie - to ustala się w rozmowie w cztery oczy○

przedstawiciel klienta ciągłym źródłem wymagao-

Po co zapisywad opowieści użytkownika?


można uporządkowad rozmowę o wymaganiach○

łatwo przydzielad funkcjonalnośd do poszczególnych wydao○

można śledzid postęp projektu○

Po co zapisywad opowieści użytkownika?-

aby ukryd terminy techniczne○

posługiwanie się metaforami-

najwyżej kilka dni pracy○

szacowanie czasu wykonania○

dynamiczne ustalanie harmonogramu○

klient wybiera to, co chce mied w kolejnym wydaniu○

nastawienie na małe kawałki oprogramowania-

opowieści są dzielone na mniejsze-

jednostki mierzą złożonośd, a nie czas wykonania-

Schemat działao - opowieśdklient pisze opowieśd1)informatycy szacują opowieśd2)klient dzieli opowieśd3)

Schemat działao - gra planistycznaklient pisze opowieśd1)informatycy szacują opowieśd2)klient wybiera zakres3)

Planowanieplanowanie jest kosztem-

plany szybko przeterminowują się-

niektórych rzeczy nie da się zaplanowad-

bez planu jeszcze gorzej-

planowanie powtarzane co tydzieo-

opowieści dzielone są na jednostki-

jednostki mierzą złożonośd a nie czas wykonania-

małe zadania bardziej przewidywalne-

Ludziom lepiej idzie oszacowywanie złożoności niż czasu wykonania-

Klient zna i kontroluje koszty funkcjonalności-

Klient priorytetyzuje pracę na podstawie informacji o złożoności-

Schemat planowaniaKrok 1: Collect1)Krok 2: Prioritize2)Krok 3: Estimate3)Krok 4: Reorder4)Krok 5: Specify (ale nie za bardzo!)5)

Estymacjajednostki względne (niekoniecznie w dniach)-

skala wykładnicza - 1, 2, 4, 8, 16-

rozbijanie dużych zadao na mniejsze-

w estymację są również zaangażowani deweloperzy-

Planowanie

wiem dokładnie, jak to zrobid, zajmie to pół dnia○

1 punkt-

wiem dokałdnie, jak to zrobid, ale wymaga to sporo pracy2 punkty-


wiem dokałdnie, jak to zrobid, ale wymaga to sporo pracy○

nie wiem, jak to dokładnie zrobid○

3 punkty-

zadania za 3 punkty dzielimy na mniejsze-

plany tygodniowe-

plany wydao (np. dwumiesięczne)-

niewielkim wysiłkiem można zaplanowad pracę na dwa - trzy miesiące-

Prace są realizowane w podejściu „top-down”, plany dostosowywane w trakcie prac-

Zmiana planów nie jest kosztowna (bo nie poświęciliśmy na nie dużo czasu)-

najlepiej żółte karteczki○

weryfikowanie oszacowao i szybkości realizacji prac○

stałe minitorowanie postępu-

czy daną pracę nadal trzeba wykonywad○

a może należy zmienid kolejnośd?○

regularne sprawdzanie zasadności oszacowao-

od razu rezygnujemy z tego, czego zrobid się nie da○

wczesne podejmowanie decyzji-

plany musza byd realne, a nie super ambitne-

powinny pokazywad, ile nam jeszcze została (a nie ile już zrobiliśmy)○

wykres wypalania pracy - zależności pomiędzy planem bazowym a postępem prac-

analiza, planowanie, implementacja, testy, zebranie uwag

cyklicznośd○

większośd cech dostarczana etapami, nie ma "wielkiego wybuchu"

przyrostowośd○

praca iteracyjna-

Co 2 tygodnie wydanie pośrednie, po nim testy i wdrożenie, na koniec zebranie uwag uwzględnianych w planach następnej iteracji)

-

przykład:-

Elastyczne podejścieakceptujemy zmiany-

nie spędzamy zbyt wiele czasu na wstępnym planowaniu-

stałe re-planowanie-

oszczędzamy na zbyt szczegółowy wstępnym projektowaniu○

akceptujemy, że fragmenty systemu będą rozszerzane / przepisywane-

stałe przeglądanie kodu-

wspólny standard kodowania-

otwarta przestrzeo pracy dla zespołu - komunikacja-

każdy (posiadający elementarne kompetencje) może zmieniad dowolne fragmenty kodu○

unikanie "silosów wiedzy"○

kod jest własnością całego zespołu-

zarządzanie wersjami-

każdy wykonuje pełen zestaw testów przed przekazaniem kodu-

stała kontrola linii głównej (trunk)-

wczesne wykrywanie problemów-

Przez cały czas aplikacja jest utrzymywana w stanie umożliwiającym jej uruchomienie-

nie ma na początku dokładnego kontraktu określającego pełen zakres działao oraz koszt projektu

klient w dowolnym momencie może zmienid zdanie i zaproponowad zmianę wymagao○

Podejście bazujące na dobrej współpracy z klientem-


koszt projektu

zdaje sobie sprawę z tego, że zmiana elementów już zaimplementowanych będzie go kosztowała dodatkowo

klient płaci na bieżąco za wykonaną pracę� ○

deweloperzy nie muszą się martwid reworkami○

zawsze dostaną wynagrodzenie za swoją pracę○

najlepszy sposób komunikacji to nie mejle, lecz zwykła rozmowa-

niezbędna agenda i moderator○

„Meetings take time - not having them takes more time!”○

częste spotkania-

codziennie○

każdy ma minutę na opowiedzenie, co robił wczoraj i co będzie robił dziś○

dyskusje odkładamy na później○

najlepiej 15 minut○

stand-up meeting-

raz na tydzieo○

45 minut○

"no overcommitment"

każdy zespół może odmówid dodatkowej pracy○

planning meeting-

co 2-4 tygodnie, 90 minut○

co nam przeszkadza

jak usprawnidpracę

co nam nie wyszło

co wyszło nam świetnie?

dyskusja na temat procesów○

Dobre rzeczy po lewej-

Słabe po prawej-

Każdy oddaje głosy (5 głosów max)-

Dyskutujemy 3-4 najważniejsze zagadnienia-

zbieranie wniosków na whiteboardzie○

ustalamy działania, przypisujemy osoby○

retrospective meeting-

Tylko gdy potrzebne○

Tylko z koniecznymi uczestnikami○

Tylko z jasną agendą○

Spotkanie z Alą i Bartkiem czy przejśd z Hibernate 2.0 na 3.0 aby poprawid wydajnośd-

Przykład:○

Inne spotkania-

pochodzą od klienta○

pozwalają oglądad postęp projektu○

klient jest przekonany, że system spełnia jego wymagania○

testując na bieżąco jesteśmy w stanie powiedzied, jak wygląda postęp projektu (ile % funkcjonalności zostało poprawnie zaimplementowane)

○

Obserwując zmianę w czasie, widad że kolejne partie systemu zostały zaimplementowane.○

Słupki stale rosną w czasie, gdyż wraz z przyrostem funkcjonalności, przyrastają przypadki testowe

○

testy akceptacyjne-

dla każdego znalezionego błędu tworzymy kilka nowych testów


dla każdego znalezionego błędu tworzymy kilka nowych testów-

narzędzia, programiści itd. zmieniają się zbyt szybko, żeby planowad coś na rok z góry○

wcześnie otrzymujemy opinie klientów○

deweloperzy cieszą się, widząc działający kod○

krótki cykl kodowanie - debugowanie○

wiele małych wydao-

Problemy z metodykami adaptacyjnymiklient przez cały czas pracuje z zespołem-

brak dokumentacji-

brak fazy projektowania-

brak długoterminowego planowania-

Zapewnianie jakościDbaj o prostotę-

Unikaj (niepotrzebnej) optymalizacji-

Dla każdej jednostki kodu opracuj najpierw zestaw testów, potem napisz kod-

Automatyczne wykonanie testów-

Refaktoryzacja-

optymalizowad kod należy tylko wtedy, gdy jest to konieczne (nie próbujemy przewidywad problemów, stawiamy na proste rozwiązania i refaktoring)

○

przypadki testowe należy przygotowad przed rozpoczęciem kodowania○

testy wykonywane automatycznie, na bieżąco wychwytywane błędy○

stałe poprawianie czytelności kodu (czyli znów refaktoryzacja)○

Różnica względem metodyk tradycyjnych:-

Kod musi przejśd wszystkie testy jednostkowe zanim przekażesz go do eksploatacji-

Dla każdego wykrytego błędu (na przetestowanym kodzie) utwórz dodatkowy zestaw testów-

Często integruj kod, wykonuj testy integracyjne-

Często wykonuj testy akceptacyjne, publikuj ich wyniki-

Metodyki adaptacyjne nie są rozwiązaniem uniwersalnym-

A kto robi to, co robił do tej pory?○

Klient przez cały czas pracuje z zespołem?-

A jeśli po pewnym czasie trzeba wrócid do prac nad starym modułem?○

Brak dokumentacji?-

Czy rzeczywiście potrafimy robid refaktoring?○

Brak fazy projektowania?-

Kto mi powie kiedy system będzie ukooczony?○

Brak długoterminowego planowania?-


"da się, to wszystko napisad w asemblerze"-

poziom języka

implementacyjne○

poziom interakcji pomiędzy klasami

projektowe○

poziom integracji komponentów

architektoniczne○

poziom opisu rzeczywistości

analityczne○

wzorce-

Podstawowe pytania

Creator: zawiera (agreguje) / zapisuje / blisko używa / posiada dane inicjalizujące○

Kto powinien byd odpowiedzialny za tworzenie nowych instancji danej klasy?-

Controller: reprezentuje system / scenariusz przypadku użycia○

Który obiekt (poza interfejsem użytkownika) jako pierwszy odbiera (i koordynuje) operacje systemowe?-

Expert: posiada niezbędne informacje, minimalizuje zależności○

Według jakiej zasady poszczególnym obiektom przypisywane są odpowiedzialności (funkcje)?-

High Cohesion: ograniczaj odpowiedzialności jednego bytu○

Low Coupling: minimalizuj stopnie powiązao pomiędzy bytami○

Jak zmaksymalizowad możliwośd wprowadzania zmian, reużywalnośd, spójnośd?-

Pure Fabrication: klasy nie posiadającej odpowiednika w dziedzinie problemu○

Czy wszystkie klasy w programie muszą byd zainspirowane bytami z dziedziny?-

Polymorphism: automatyczne rozdzielanie odpowiedzialności zgodnie z hierarchią○

Jak obsłużyd alternatywne rodzaje bytów? (instrukcje warunkowe)-

Indirection: powiązania z obiektem pośrednim a nie między sobą○

Gdzie przypisad odpowiedzialnośd aby uniknąd tworzenia bezpośrednich powiązao pomiędzy (dwoma lub więcej) bytami?

-

Protected Variations: wokół niestabilnych miejsc (tam wariacje) stworzyd interfejsy○

Jak należy projektowad obiekty / systemy / podsystemy aby zmiany wewnątrz tych obiektów nie miały wpływu na inne elementy?

-

Kreator

Kto powinien byd odpowiedzialny za tworzenie nowych instancji danej klasy? (nie mówimy o konstruktorach, tylko o logice aplikacji)

○

Problem-

Tworzenie obiektów jest jedną z częściej wykonywanych czynności w systemie obiektowym.-

Wygodnie (dla programisty) jest mied ogólną zasadę przypisywania odpowiedzialności za tworzenie-

obiektów.Dobre zdefiniowanie odpowiedzialności zwiększa przejrzystośd programu, zapewnia kapsułkowanie i-

reużywalnośd.

Wzorce projektowe21 maja 2010

08:39


Kto powinien byd odpowiedzialny za tworzenie instancji SalesLineItem?-

B zawiera (agreguje) A

B zapisuje A

B blisko używa A

B posiada dane inicjalizujące A

Przypisz klasie B odpowiedzialnośd za tworzenie egzemplarzy klasy A jeżeli spełniony jest co najmniej jeden z warunków (im więcej, tym lepiej):

○

Rozwiązanie-

Fabryka

Kto odpowiada za tworzenie obiektów?○

Problem:-

Logika tworzenia obiektu jest skomplikowana○

Chcemy wydzielid logikę tworzenia obiektu (np. chcemy mied możliwośd wpływania na nią poprzez konfigurację systemu)

○

Kto tworzy obiekty będące adapterami?

W jaki sposób określana jest właściwa klasa adaptera (który powinien zostad utworzony)?

Jeśli adaptery są tworzone przez obiekt z dziedziny problemu, wówczas zakres odpowiedzialności takiego obiektu wykracza poza czystą logikę aplikacji.

Stosujemy adaptery (zewnętrzne usługi mają zmieniające się interfejsy)○

Szczególne przypadki:-

Powołujemy Fabrykę, która będzie odpowiadad za tworzenie innych obiektów○

Rozwiązanie-

Dostęp do Fabryk jest często zapewniany z wykorzystaniem wzorca Singleton○

Podobne-

Singleton

W podobny sposób można zarządzad pulą zasobów○

Dlaczego nie wszystkie metody statyczne? w większości języków metod statycznych nie da się przesłonid w podklasie

○

większośd mechanizmów zdalnego dostępu do obiektów, np. RMI, dotyczy jedynie metod egzemplarza○

z czasem możemy zmienid zdanie i zapragnąd puli zamiast pojedynczej instancji○

Czasami instancja nigdy nie powstaje

Logika tworzenia jest skomplikowana

Dlaczego nie wczesna inicjalizacja zamiast leniwej?○

W przypadku aplikacji wielowątkowej –sekcja krytyczna○

dyskusja-


Kontroler

sprowadza się to do grupy akcji○

obsługuje proces biznesowy-

pierwszy obiekt po warstwie UI odpowiedzialny za odebranie i obsłużenie komunikatu biznesowego-

reprezentującej cały system, główny obiekt w systemie, urządzenie w ramach którego system działa lub główny podsystem

reprezentującej scenariusz przypadku użycia, w ramach którego zachodzi dana operacja systemowa <UseCaseName>Handler, <UseCaseName>Coordinator, <UseCaseName>Session

Odpowiedzialnośd przypisz jednej z klas:○

Rozwiązanie:-

Na tej liście nie ma klas: "window," "view," "document" - Takie klasy nie powinny wypełniad zadao związanych z obsługą zdarzeo systemowych. Zazwyczaj jedynie odbierają zdarzenia i delegują je do kontrolera.

-

To jest wzorzec wykorzystujący delegację. Przyjmując założenie, że warstwa UI nie powinna zawierad logiki aplikacji, obiekty z warstwy UI musza delegowad zadania do innej warstwy.

○

Zazwyczaj system odbiera zewnętrzne zdarzenia wejściowe z wykorzystaniem GUI obsługiwanego przez osobę. Należy też uwzględnid obsługę zdarzeo z innych źródeł (wywołania procedur, sygnały, …). We wszystkich przypadkach trzeba wskazad miejsce obsługi tych zdarzeo.

○

Często ta sama klasa będzie kontrolerem dla wszystkich zdarzeo z jednego przypadku użycia, żeby kontroler mógł kontrolowad stan realizacji przypadku użycia. Można wtedy wychwytywad zdarzenia spoza scenariusza (sekwencji zdarzeo, np. dla rozważanego przykładu wykonanie makePayment przed wykonaniem endSale). Dla różnych przypadków użycia –różne kontrolery.

○

Częstym błędem jest projektowanie kontrolerów posiadających przesadnie duży zakres odpowiedzialności.○

dyskusja-

Stanowią główne punkty obsługi zgłoszeo z warstwy UI, przekazują je do niższych warstw.

Fasady są czasami abstrakcjami bytów ze świata rzeczywistego (Kasa, Telefon, Robot, Centrala Telefoniczna, …) lub reprezentują cały system (PoSSystem, ChessGame, …).

Takie podejście sprawdza się głównie w przypadku, gdy nie ma zbyt wielu (oczywiście pojęcie „wiele” jest względne!) zdarzeo systemowych

Pierwszą kategorią kontrolerów są fasady (FACADE) reprezentujące cały system, urządzenie, podsystem. ○

Taki kontroler nie pochodzi z dziedziny problemu –wprowadza sztuczną warstwę / konstrukcję (PURE FABRICATION)

Konieczne do zastosowania jeśli

w systemie jest duża liczba obsługiwanych zdarzeo

kontroler fasadowy otrzymuje zbyt duży zakres odpowiedzialności

istnieje potrzeba śledzenia stanu realizacji scenariusza przypadku użycia

Drugą kategorią kontrolerów są klasy odpowiadające przypadkom użycia. ○

boundary

control

entity

Ograniczenia (boundary) to abstrakcja interfejsów

Encje (entity) są bytami z dziedziny problemu, niezależnymi od aplikacji, zazwyczaj trwałymi (persistent)

Kontrolery (control) są obiektami tutaj opisywanymi

W starszych metodykach występował podział na klasy:○

podsumowanie-

Podobne podejście jest stosowane w przypadku aplikacji webowych (ASP.NET, WebForms, …)○

Plik z kodem („stojący za” renderowaną stroną) zawierający obsługę zdarzeo dla przycisków na stronie webowej powinien posiadad referencję do kontrolera (z warstwy domenowej) i delegowad do niego zadania.

○

Takie podejście kontrastuje z powszechnym stylem programowania ASP.NET w którym deweloperzy wstawiają logikę do takiego pliku (łącząc logikę aplikacji z warstwą UI).

○

Frameworki do obsługi UI webowych (np. Struts) bazują na koncepcji Web-MVC (Model-View-Controller).○

Taki kontroler może się różnid nieco od tutaj omówionego –będzie zapewne częścią warstwy interfejsu użytkownika i będzie kontrolował przepływ stron (logikę stron).

○

W klasycznym przypadku był częścią warstwy dziedzinowej i koordynował pracę, nie był zupełnie świadomy rodzaju wykorzystywanego UI (Web, Swing, …).

○

Drugim wariantem (np. w EJB) jest delegowanie z warstwy Web-UI (np. z klasy Struts Action) do obiektu sesyjnego (EJB Session), który obsługuje scenariusz przypadku użycia (analogicznie do klasycznej wersji) lub całą sesję użytkownika. Ciągle obiekt sesyjny jedynie deleguje pracę (sam jej nie wykonuje).

○

Web GUI & Server-Side Application of Controller-

�

Wzorzec CONTROLLER stosuje się także w przypadku aplikacji desktopowych komunikujących się z serwerem. Warstwa kliencka obsługująca UI przekazuje zgłoszenie do kontrolera po stronie klienckiej, który z kolei

○

Smart Client-


przekazuje żądanie do usługi udostępnionej zdalnie. � Taki projekt obniża stopieo powiązao pomiędzy usługami zdalnymi a elementami UI, umożliwia np. łatwe tworzenie usług działających zarówno lokalnie jak i zdalnie (dzięki warstwie pośredniej w postaci kontrolera w aplikacji desktopowej).

Adapter

Jak ujednolicid niekompatybilne interfejsy?○

Jak zapewnid stabilny interfejs do podobnych komponentów o różnych interfejsów?○

Problem:-

Należy przekształcid (zasłonid) oryginalny interfejs komponentu na inny interfejs za pomocą dodatkowego obiektu –adaptera

○

Rozwiązanie:-

Adapter jest rodzajem Fasady, ale zastosowanej dla kilku systemów○

Podobne:-

Obserwator

Różne obiekty (obserwatorzy) są zainteresowane obserwowaniem zmian stanu obiektów (obserwowanych).○

Chcą po swojemu reagowad na te zdarzenia, jednocześnie zachowując luźne sprzężenie.○

Problem:-

Zdefiniuj interfejs np. Listener lub Subscriber○

Obserwatorzy implementują ten interfejs, a obserwowani mogą dynamicznie rejestrowad obserwatorów i powiadamiad ich o zdarzeniach.

○

separacja modelu i widoku

ale nie tylko –zdarzenia systemowe, zegary, …

Najczęściej stosowane dla kapsułkowania zmienności względem zmieniających się UI○

Sprzężenie jest ograniczone do jednego interfejsu (obserwatorzy nie muszą byd zawsze obecni i można ich dynamicznie dodawad/usuwad)

○

Często stosowane w bibliotekach widżetów np. Swing, SWT, .Net○

Rozwiązanie:-

Strategia

Jak w projekcie uwzględnid różnorodne, ale powiązane algorytmy lub strategie?○

Jak zapewnid łatwą możliwośd ich zmiany?○

Problem:-

Wszystkie algorytmy / strategie zdefiniuj w oddzielnych klasach o wspólnym interfejsie.○

Obiekt Strategia zazwyczaj otrzymuje jako parametr jakiś obiekt wyznaczający kontekst, na którym pracuje○

Rozwiązanie:-

Fabryka może odczytywad wymagane dane z zewnętrznego źródła○

użycie Fabryki pozwala łatwo zmieniad strategię w trakcie działania aplikacji○

Strategie zazwyczaj tworzymy przy pomocy Singletonowej Fabryki-

Kompozyt

Jak traktowad zgrupowanie lub kompozycję obiektów w taki sam sposób jak obiekt atomowy?○

Problem:-

Niech klasy reprezentujące kompozycję obiektów i obiekt atomowy posiadają ten sam interfejs○

Rozwiązanie: -

polityka co zrobid jak klient pasuje do kilku strategii i trzeba wybrad najlepszą dla Klienta

dodajemy gdy tworzona jest sprzedaż

całego sklepu□

dodajemy gdy system zostaje poinformowany o typie klienta

klienta□

gdy produkt jest dodany do sprzedaży

produktu□

taki rabat może dotyczyd:

wiele strategii rabatu○

Przykład:-

Fasada

Potrzebny jest wspólny, jednorodny interfejs do zbioru implementacji lub interfejsów np. jeden interfejs do zbioru klas w ramach podsystemu

○

Chcemy ograniczyd niepożądane sprzężenie ze składnikami podsystemu oraz zabezpieczyd się przed jego zmianami.

○

Problem:-

Zdefiniuj pojedynczy kontrakt dla całego podsystemu Rozwiązanie:-


obiekt fasadę, który opakowuje podsystem

Zdefiniuj pojedynczy kontrakt dla całego podsystemu ○

Podobne do Adaptera○

Kapsułkowanie zmienności względem zmian podsystemu.○

Konkluzja


Esencja procesu twórczegoopisad problem1)opisad rozwiązanie2)

czy rozwiązanie rozwiązuje postawiony problem?-

zweryfikowad3)

czy rozwiązaliśmy właściwy problem-

zwalidowad4)

Projektowanie

uprośd i uogólnija.abstrakcja1)

podziel i zwyciężaja.dekompozycja2)

Praktyki wytwórcze

Przyczyny udanych projektów informatycznych

Podsumowanie28 maja 2010

08:39


Specyfikacja uzupełniająca

poziom zgodności ze standardem korporacyjnym○

stopieo czytelności napisów○

stopieo spełnienia zasad ergonomii○

Wygląd zewnętrzny-

czas potrzebny na naukę systemu○

czas potrzebny na wykonanie typowych czynności○

Łatwośd użycia-

czas trwania operacji○

czas niedostępności systemu w miesiącu○

Wydajnośd-

czas poświęcany na administrowanie systemem○

Bezpieczeostwo○

Łatwośd serwisowania-

system nie pozwoli na nieautoryzowany dostęp do danych przy próbie włamania przez firmę hakerską-

-


Documents

Organizacja - students.mimuw.edu.plstudents.mimuw.edu.pl/~db277594/io.pdf · Egzamin - pytania testowe ... Inżynieria oprogramowania ... programiści uaktualniają model szacowania