OPRACOWANIE wyk 12

1. Wprowadzenie do zarządzania projektami. Warstwy zarządzania i role w projekcie. WBS.

Podstawowe cechy projektu:

- tymczasowość – każdy projekt ma określone terminy rozpoczęcia i zakończenia, czyli ograniczony czas trwania

- unikalność – produkt lub usługa różnią się pod pewnymi względami od innych produktów lub usług, mogą posiadać cechy powtarzalne

- zakończenie projektu – osiągnięcie jego celów, wygaśnięcie przyczyny dla której rozpoczęto projekt

- stopniowe doprecyzowywanie – na początku projektu własności wyróżniające produkt określa się w ogólnym zakresie, w miarę postępu badań następuje definiowanie szczegółowych własności

Zarządzanie projektami [Kerzner H.]:

- planowanie,

- organizowanie,

- kierowanie,

- kontrolowanie,

zasobów organizacji przydzielonych do konkretnego projektu dla zapewnienia osiągnięcia jego celów.

Struktura organizacyjna projektu

• Warstwy zarządzania projektem

– zarząd organizacji

– rada projektu

– kierownik projektu

– kierownik zespołu

• Liczba warstw i zespołów zależy od

– wielkości i kosztu przedsięwzięcia

– technicznej złożoności produktu

– znaczenia przedsięwzięcia

– dostępności personelu

Podstawowe role w przedsięwzięciu

informatycznym

• sponsor/klient

• użytkownik

• kierownik przedsięwzięcia/zespołu

• specjalista ds. jakości, ryzyka

• Role techniczne

– analityk

– projektant

– programista

– administrator

– dokumentalista

WBS:

WBS (Work Breakdown Structure)

• Struktura podziału pracy definiuje pracę do wykonania w

celu ukończenia projektu

• Stanowi zestawienie składników projektu ze względu na

jego główne produkty

podejścia:

zstępujące: od uogólnienia do

szczegółów, od celu projektu do

pojedynczych zadań

• wstępujące: od szczegółów do

uogólnienia, od zadań do celu

pojęcia WBS:

składnik pracy – dyskretny wynik pracy (produkt lub

usługa) lub agregacja logicznie zgrupowanych

wyników

• poziom WBS – lokalizacja składnika pracy w

hierarchicznej strukturze, unikalny numeryczny kod

składnika pracy

• pakiet roboczy – wynik pracy na najniższym

poziomie WBS, główny punkt zarządzania WBS

(np. planowanie zasobów, zapewnianie jakości)

konto kosztowe – sumaryczny składnik pracy o

jeden poziom wyżej niż pakiet (jeden lub kilka

pakietów), określany jako punkt kontrolny

• gałąź – wszystkie składniki pracy poniżej poziomu

0, gałęzie mogą mieć różne długości

Podstawy tworzenia WBS

• Zakres projektu: lista głównych produktów i ich

opis

• Przepływ pracy: sekwencja wykonywania

produktów

• Dostępne zasoby

• Oczekiwania klienta (szybkość realizacji,

podwykonawcy)

• Położenie projektu: niezależność albo priorytet w

grupie projektów

2. Modele cyklu życia produktu i projektu. Kluczowe produkty etapów przedsięwzięcia

informatycznego.

Model kaskady

Analiza i definiowanie wymagań --> Projektowanie systemu i oprogramowania --> Programowanie i testowanie jednostek (implementacja) --> Integracja i testowanie systemu --> Instalacja i utrzymanie systemu

Zalety i wady modelu kaskadowego

Zalety i wady modelu V

WADY:

-nie uwzględnia optymalności czasowej

Podejście iteracyjne

Podejście ewolucyjne

Podejście prototypowania

Zalety:

Wady:

Zalety i wady modelu spiralnego

Model przyrostowy

Wielokrotne wykonywanie liniowych procesów

Model komponentowy

Komponent

Składanie z powtarzalnych komponentów

Fazy etapu tworzenia w modelu komponentowym

  1. Identyfikacja odpowiednich komponentów

  2. sprawdzenie dostępności komponentów

  3. Wybór dostępnych komponentów

  4. Wytworzenie niedostępnych komponentów

  5. Dodanie nowych komponentów do biblioteki

  6. Konstrukcja n-tej iteracji systemu

RAD

Fazy RAD

Zastosowanie i wymagania RAD

Techniki czwartej generacji (4GL)

• Narzędzia programistyczne umożliwiające definiowanie różnych cech oprogramowania na wysokim poziomie abstrakcji w celu późniejszego automatycznego wygenerowania

– kodu programu

– struktury bazy danych

– okienkowych systemów interakcji

– dokumentacji

• Pozwalają na skrócenie procesu wytwórczego i zwiększenie wydajności programistów

• Trudne w użyciu

• Niska efektywność automatycznie wygenerowanego kodu

Formalna transformacja

• Wykonanie specyfikacji wymagań systemu w języku formalnym

• Automatyczne przekształcenie formalnej specyfikacji do postaci pseudokodu, a następnie kodu programu w określonym języku programowania

• Poszczególne etapy cyklu życia są realizowane w sposób indywidualny, zależny od złożoności obliczeniowej problemu

Język formalny

• symbol – obiekt abstrakcyjny, np. litera, cyfra, znak graficzny

• alfabet – skończony zbiór symboli (Σ)

• łańcuch (słowo) – skończony ciąg symboli

• język (formalny) - zbiór łańcuchów złożonych z symboli jakiegoś jednego alfabetu (Σ*)

• Przykład

jeżeli Σ = {a}, to Σ* = {e, a, aa, aaa, ...}, gdzie e – słowo puste

Zalety i wady formalnej transformacji

• Wysoka niezawodność pod warunkiem bezbłędnej specyfikacji (brak sprzeczności)

• Przeniesienie trudności programowania na etap specyfikacji wymagań

• Prawdopodobna mała efektywność uzyskanego kodu

• Brak uniwersalnych języków formalnej specyfikacji

Zwinne zarządzanie projektami

• Zwinne zarządzanie projektami (ang. Agile Project Management, APD) - zbiór różnych metodyk, określanych jako zwinne bądź lekkie, oraz narzędzi stosowanych w zarządzaniu złożonymi i innowacyjnymi projektami – głównie informatycznymi

• Należą do nich między innymi: metody adaptacyjne, Crystal, SCRUM, eXtreme programming …

• Dokument „Manifesto for Agile Software Development” (2001) zainicjował głębokie przemiany w środowiskach programistycznych, przyjętych też w innych obszarach zarządzania projektami

• Powstanie APD było reakcją na mało elastyczne metody zarządzania projektami informatycznymi, uważane za zbyt sformalizowane i mało efektywne

Cechy charakterystyczne metodyk zwinnych

Cechy

Nieodpowiednie dla:

Porównanie typów cykli życia projektu

Kluczowe produkty coś tam:

Wybór modelu procesu wytwórczego

• Wybór modelu odpowiedniego do potrzeb

• Kryteria wyboru modelu

• ryzyko projektu

• czas na wykonanie

• niezawodność produktu

• klarowność i zmienność wymagań

• technologia, rozmiar i złożoność

• interfejs użytkownika

• priorytety użytkownika

• spodziewany czas życia systemu

• interfejsy z istniejącymi lub nowymi systemami

• potencjalna równoległość działania systemów

• Dostosowanie modelu do konkretnego zespołu wytwórczego

• Na różnych etapach projektu może być zastosowany inny model

Produkty etapu analizy [CASE*Method]

• Model konceptualny danych

• Diagram hierarchii funkcji

• Tabele powiązań funkcja/encja, funkcja/jednostka, funkcja/cel

• Model przepływu danych, model zależności funkcji, diagram stanów i przejść

• Wymagania wydajnościowe, kontroli i bezpieczeństwa

• Kryteria akceptacji oprogramowania przez użytkownika

• Wstępne parametry sprzętowe

• Wstępna strategia wdrożenia systemu

• Uzgodnione podejście do etapu projektowania i budowy

• Skorygowany plan rozwoju systemu

• Założenia i ograniczenia (koszty, personel, metody i styl pracy, regulacje prawne …)

Produkty etapu projektowania [CASE*Method]

• Architektura systemu

• Projekt modułów

• Schematy logiczne i fizyczne

• Projekt bazy danych i plików danych

• Szczegółowe wymagania sprzętowe

• Specyfikacje programów

• Szkic instrukcji użytkownika

• Uzgodniona strategia przeniesienia systemu: plan dostarczenia i odbioru, szkolenia, transformacja danych, odejście od starego systemu

• Plan testowania systemu

• Szkic dokumentacji systemu

• Skorygowany plan rozwoju systemu

Produkty etapu budowy i testowania [CASE*Method]

• Projekt programów

• Dostrojona baza danych

• Działające, przetestowane programy

• Skorygowana strategia przeniesienia systemu

• Wyniki testów systemu

• Zainstalowany sprzęt i oprogramowania, pierwsze oceny wydajności systemu

Produkty etapu dokumentowania [CASE*Method]

• Dokumentacja użytkownika

• Dokumentacja operatorska

Produkty etapu wdrożenia [CASE*Method]

• Materiały szkoleniowe

• Przeszkoleni użytkownicy i operatorzy

• Zainstalowany i w pełni działający system

• Przeniesione dane

• Raporty o błędach w działaniu systemu

• Przeglądowe sprawozdanie po wdrożeniu

• Urządzenia wsparcia technicznego

• Kompletna dokumentacja systemu

Produkty etapu użytkowania [CASE*Method]

• Zbiory danych zapasowe, archiwalne i do odzyskiwania danych

• Raport kontrolny zmian

• Raport o błędach

• Uzupełnienia do systemu

• Statystyka wydajności systemu

• Nowe wymagania

• Wyniki przeglądów systemu

3. Proces rozpoczęcia projektu: karta projektu, uzasadnienie biznesowe. Zagrożenia i krytyczne

czynniki powodzenia projektu.

Karta projektu

• Oficjalna nazwa projektu

• Sponsor projektu

• Kierownik projektu

• Cel projektu

• Uzasadnienie biznesowe realizacji projektu

• Opis wyników na poziomie ogólnym

• Opis organizacji zespołu

• Ramowy terminarz prac

• Zasoby (budżet, personel, dostawcy)

Cel projektu i cel produktu

• Cel projektu – jasno określony wynik projektu, wymierne kryteria

które powinien spełniać projekt, aby mógł być uznany za udany,

np. wskaźnik kosztowy, jakościowy

• Przykładowe cele projektu:

  1. Wdrożenie i udostępnienie do użytkowania programu do końca Iego kwartału przyszłego roku.

  2. Przeszkolenie 1000 osób.

Uzasadnienie biznesowe projektu

• opis i ocena spodziewanych korzyści

– oszczędności wynikające z zatrudnienia

– poprawa wizerunku firmy

– poprawa jakości pracy

• koszty – zakup sprzętu, obsługa systemu, zakłócenia w pracy

• ryzyko związane z realizacją i zaniechaniem

• skutki finansowe - ocena inwestycji

Zagrożenia (ryzyko) projektu

Klasyfikacja zagrożeń

Klasyfikacja ryzyk wg Boehma

• Funkcjonalność – niepewność spełnienia przez produkt stawianych wymagań

• Koszt – możliwość przekroczenia budżetu projektu

• Pielęgnacja – niepewność związana z możliwością poprawiania, rozszerzania i dostosowania do zmieniających się warunków

• Harmonogram – możliwość niedotrzymania zaplanowanych terminów

Zagrożenia wg R. Charette

• Zmiana

– wymagań klienta

– stosowanych technologii

– docelowego środowiska komputerowego i innych elementów związanych z przedsięwzięciem

Przykłady zagrożeń i rozwiązań

• Brak zrozumienia wymagań – zastosuj prototypowanie

• Nieznany sposób integracji z istniejącym systemem – zastosuj prototypowanie i zatrudnij „eksperta”

• Brak doświadczenia w tworzeniu oprogramowania dla platformy .NET – szkolenia

• Duża zmienność wymagań – możliwie szybka budowa architektury wykonywalnej, model ewolucyjny

• Rotacja personelu – szczegółowe dokumentowanie realizacji prac projektowych, motywowanie pracowników

Postępowanie z zagrożeniami

Ocena zagrożeń

• Ustal średnie prawdopodobieństwo wystąpienia zagrożenia

• Ustal wpływ zagrożenia na każdy składnik ryzyka wg klasyfikacji ryzyk (skutki)

• Sporządź (uzupełnij) tabelę zagrożeń

• Oblicz podatność na zagrożenie [E. Hall]: R = P * C, gdzie:

R – podatność na zagrożenie

C – koszt strat poniesionych w wyniku wystąpienia zagrożenia

P – prawdopodobieństwo wystąpienia zagrożenia

Krytyczne czynniki powodzenia cyklu życia projektu wg etapów metodyki CASE*Method

STRATEGIA

ANALIZA

PROJEKTOWANIE

BUDOWA

DOKUMENTOWANIE

WDROŻENIE

EKSPLOATACJA

4. Planowanie realizacji projektu informatycznego: CPM, CCS. Kontrola realizacji

przedsięwzięcia informatycznego (metoda EVM). Narzędzie Project.

Metoda budowy harmonogramu CPM (Critical Path Method)

CCS:

Metoda łańcucha krytycznego (CCS)

Identyfikacja działań w CCS

• Liczba działań w CCS zależy od ich rozmiaru (2-4 tygodni)

• Ważniejsze zapewnienie pełnej listy działań niż dokładne wyznaczenie czasów trwania

Przydzielanie zasobów i szacowanie czasów trwania

Bufory zasobów CCS

Bufor projektu CCS

Bufory zasilające CCS

Metoda EV- Śledzenie czasu i kosztów wykonania projektu

Kontrola postępu prac

• tradycyjne podejście

– różnica miedzy wartością kosztów rzeczywistych i wartością kosztów planowych

• nowe podejście

– wycena wartości prac zrealizowanych do momentu t

(wartość produktów, usług)

Metoda wartości uzyskanej projektu

Earned Value (EV)

• standard do pomiaru wydajności projektów

• kontrola realizacji projektu przez porównywanie do chwili t

– zrealizowanego zakresu projektu,

– wykorzystanego czasu,

– poniesionych kosztów

z przyjętymi wartościami w harmonogramie i budżecie w planie bazowym

Warunki zastosowania metody

• zakres projektu (działania podzielone na wystarczająco małe jednostki)

• harmonogram

• planowany budżet

• stosowane jednostki miary: godziny, kwoty, liczba pakietów roboczych

• Metoda EV nie odnosi się do zadań zarządzania projektem !!!

Odchylenia

• kosztowe

CV(t) = EV(t) – AC(t)

EV(t) – wartość uzyskana w momencie t

AC(t) – koszt rzeczywisty w t

• harmonogramowe

SV(t) = EV(t) – PV(t)

PV(t) – koszt planowany w t

Wskaźniki efektywności

• wskaźnik wykonania kosztów

CPI = EV(t)/AC(t)

• wskaźnik wykonania harmonogramu

SPI = EV(t)/PV(t)

Wartości estymowane projektu

• estymacja kosztu zakończenia

EAC = BAC/CPI

BAC – planowany koszt zakończenia projektu(wartość skumulowana)

• estymacja czasu trwania

SAC = BAS/SPI

BAS – planowany czas trwania projektu (wartość skumulowana)

Założenia do szacowania metodą EV w

wersji (0:100)

• wartość uzyskana

– zadanie zakończone stanowi wartość 100% kosztu planowanego

– zadanie rozpoczęte i nierozpoczęte stanowi wartość 0

• koszt rzeczywisty AC może stanowić wartość równą, mniejszą lub większą od kosztu planowanego PV, dla uproszczenia przyjęto AC=PV

Założenia do szacowania metodą EV w

wersji 50:50

• wartość uzyskana

– wykonanie zadania oszacowane na połowę lub więcej stanowi wartość

50% kosztu planowanego zadania

– wykonanie zadania oszacowane na mniej niż 50% kosztu planowanego stanowi wartość 0

– zadanie zakończone stanowi wartość 100% planowanego kosztu zadania

• koszt rzeczywisty AC może stanowić wartość równą, mniejszą lub większą od kosztu planowanego PV, dla uproszczenia przyjęto AC=PV

Założenia do szacowania metodą EV

wersja szczegółowa

• wartość uzyskana liczona wg oceny procentowej planowanej wartości zadania (jako % planowanego kosztu)

• koszt rzeczywisty AC może stanowić wartość równą, mniejszą lub większą od kosztu planowanego PV, dla uproszczenia przyjęto AC=PV

Narzędzie Project???????

5. Miary i metryki oprogramowania

Aspekty mierzenia wielkości

oprogramowania

• długość - aspekt fizyczny

• funkcjonalność – aspekt użytkowy, efekty otrzymywane przez użytkownika w wyniku działania programu

• złożoność – aspekt budowy i użytkowy: strukturalny, obliczeniowy, semantyczny, …

Definicja pomiaru i miary atrybutu

• Pomiar jest procesem, w którym liczby lub symbole są przydzielane do atrybutów wybranego elementu świata rzeczywistego w sposób wyraźnie zdefiniowany za pomocą odpowiedniej reguły

• Miara jest empirycznie i obiektywnie wyznaczoną liczbą lub symbolem przypisanym do elementu, charakteryzowanego specyficznym atrybutem

Miary bezpośrednie i pośrednie

• Miara bezpośrednia - mierzenie atrybutu nie zależy od miary innego atrybutu: długość kodu źródłowego - LOC, funkcjonalność – liczba funkcji, czas trwania procesu - liczba godzin

• Miara pośrednia - mierzenia atrybutu wymaga odwołania się do miary jednego lub kilku innych atrybutów, a nawet innego obiektu: wydajność programisty – LOC/dzień, efektywność testowania – liczba odkrytych błędów/liczba testowanych pozycji

Atrybuty wewnętrzne i zewnętrzne

• Atrybuty wewnętrzne – cechy procesu, produktu, zasobów mierzone bezpośrednio względem danego obiektu: wielkość programu, złożoność programu

• Atrybuty zewnętrzne - cechy procesu, produktu, zasobów mierzone pośrednio, względem relacji danego obiektu ze środowiskiem: wydajność programisty, niezawodność programu, użyteczność

Klasy mierzonych obiektów projektu

• Proces: określone działanie lub zbiór powiązanych działań

• Produkt: artefakty; dokumenty, jako wyniki działań procesu; produkty pośrednie; produkt finalny

• Zasoby: każdy element niezbędny do wykonywania działań procesu

Miary długości

• liczba linii kodu programu LOC (lines of code)

LOC = NCLOC + CLOC

CLOC (commented lines of code) – linie komentarza programu

NCLOC (noncommented lines of code) – linie kodu niekomentarzowe

• liczba linii kodu kodu efektywnego, tj. bez linii komentarza

ELOC

ELOC (effective lines of code) – linie efektywne kodu

Miary długości

• liczba instrukcji źródłowych programu

DSI

DSI (delivered source instructions)

– liczona bez linii komentarza, ale z deklaracjami i nagłówkami

• liczba bajtów (znaków)

• liczba stron dokumentacji

• teoretyczna miara Halsteada

Miary funkcjonalności

• miara Bang DeMarco

• liczba punktów funkcyjnych FP (Function Points) – Albrecht i Symons

• liczba UCP (Use Case Points)

• liczba funkcji wykonywanych przez program

• liczba elementów struktury funkcjonalnej

• liczba elementów struktury informacyjnej

• odpowiedniość zbioru funkcji w odniesieniu do celów i zadań użytkownika

• dokładność otrzymywanych wyników

Miary złożoności

• liczba cyklomatyczna McCabe

• obiektywna miara złożoności Hendersona – Sellersa

• zestaw miar Chidambera i Kemerera

• miary modułowe - Henry i Kafura

6. Metody FP i UCP - przykłady zastosowania do szacowania wielkości oprogramowania.

Metoda UCP (Use Case Points) [Karner G. 1993]

Metoda stosowana do obliczania wielkości aplikacji tworzonej metodami obiektowymi i z użyciem pojęć języka UML

1. Obliczanie niedopasowanych punktów UUCP (Unadjusted Use Case Point)

2. Obliczanie czynnika złożoności technicznej TCF

3. Obliczanie czynnika złożoności środowiskowej EF

4. Obliczenie końcowych punktów przypadków użycia UCP

1. Obliczanie niedopasowanych punktów UUCP

• Realizacja etapu w dwóch krokach: A - aktorzy i B - przypadki użycia

• Poziomy złożoności każdego składnika ustalane wg kryteriów podanych w tabelach współczynników wagowych

A. Sumowanie aktorów wg oceny ich złożoności: UUCP(A) = Σ zij * Wi

A. Sumowanie przypadków użycia wg rodzaju transakcji albo klasy oraz oceny ich złożoności

Transakcje: UUCP(UCT) = Σ zij * Wi

Klasy: UUCP(UCC) = Σ zij * Wi

• Obliczanie niedopasowanych punktów przypadków użycia

UUCP = UUCP(A) + UUCP(UCT) albo UUCP = UUCP(A) + UUCP(UCC)

FP metoda

Etapy w metodzie FP

  1. Obliczanie „niedopasowanych” punktów funkcyjnych

  2. Obliczanie wskaźnika poziomu technicznej złożoności

  3. Obliczanie wielkości systemu za pomocą liczby punktów funkcyjnych

1. Obliczanie „niedopasowanych” punktów funkcyjnych

a) Wyznaczenie granicy aplikacji

b) Klasyfikacja składowych systemu wg typów funkcyjnych

c) Ustalenie poziomu złożoności dla każdego składnika danego typu funkcyjnego na podstawie macierzy złożoności

a) Obliczenie UFP według wzoru

z_ij – liczba składników i – tego typu j – tej złożoności

w_ij – waga składnika z_ij; i = 1, ...,5; j = 1, 2, 3

  1. Wagi typów funkcyjnych

    Elementy składowe typów składników systemu

• DET – dana elementarna

• RET – logiczny plik danych

• FTR – logiczny plik referencyjny

2. Obliczanie wskaźnika technicznej złożoności

a) Ustalenie poziomu i liczby stopni wpływu każdej charakterystyki na podstawie tabeli reguł

b) Obliczenie całkowitego stopnia wpływu DI = å c_i; i = 1, ...,14

c) Obliczenie wskaźnika technicznej złożoności: TCF = 0.65 + 0.01DI

3. Obliczanie wielkości systemu w punktach funkcyjnych

FP = UFP * TCF

7. Modele szacowania wymiarów projektu: metoda Albrechta, Halsteada, COCOMO, metody

uproszczone. Rzetelność oszacowania. Standardowa procedura szacowania.

Lista funkcji elementarnych do przykładu

Z111. Przyjmij nowego pracownika

Z113. Awansuj pracownika

Z115. Zwolnij pracownika

Z213. Przydziel pracownika do zadania

Z311. Oceń pracownika za pomocą wskaźnika wydajności

Z411. Sporządź raport o lokalizacji pracowników

Z421. Ustal zadania przydzielone pracownikowi … w dniu …

Etap II i III - obliczenie FP

Etap II

Po ustaleniu poziomu wpływu dla każdej charakterystyki, całkowity stopień wpływu DI (2.b)

DI = 21

Po podstawieniu do wzoru (2.c), wskaźnik technicznej złożoności TCF

Etap III

TCF = 0.65 + 0.21= 0.86

Po podstawieniu obliczonych wielkości UFP i TCF do wzoru na obliczanie FP

(3) otrzymuje się

FP = 65*0.86 = 55.9

Metoda halsteda

Nieliniowy, teoretyczny model nakładów

Halsteada (1)

Zauważono, że istnieje zależność

N = kSs (1)

gdzie

N – długość programu jako całkowita liczba operatorów i operandów

n – słownik programu, jako liczba unikalnych operatorów i

operandów

S – oszacowany rozmiar programu w LOC

k – stała, jako średnia liczba operatorów i operandów przypadająca na linię kodu w danym języku programowania (np..Fortran: 7, PL/S: 5)

Nieliniowy, teoretyczny model nakładów

Halsteada (2)

TW1:

V – wielkość programu

TW2:

V = N*log2(n) (2)

E = D*V (3)

gdzie D – trudność programu

D n1

* N 2

(4)

2 * n2

Nakład E aproksymowany przez

E = N2,28/4 (5)

(3)

TW3:

T - czas na wykonanie projektu

T = E / [s] (6)

gdzie

- liczba elementarnych wyróżnień myślowych na sekundę 5<= <=20

u Halsteada = 18

Metoda COCOMO’81

• COnstructive COst Model

• Narzędzie programowe BYL (Before You Leap)

• Model hybrydowy: łączy metody doświadczalne z elementami wnioskowania statystycznego

• Występuje w postaciach zależnych od

– fazy cyklu życia: wstępna, wczesnego projektowania, zaawansowana faza cyklu

– typu systemu: autonomiczny, częściowo wbudowany, wbudowany

• Nakład pracy (np..osobo-miesiące)

E = a(S)^b*m(X), gdzie: S – prognozowana wielkość systemu (KDSI, KLOC), m(X) – współczynnik wnioskowania, jako sterownik kosztowy, a, b - parametry zależne od typu systemu

Prognoza czasu realizacji przedsięwzięcia

T = a(E)^b, gdzie: E – prognoza całkowitego nakładu pracy potrzebnego na realizację

całego przedsięwzięcia w osobomiesiącach a, b – parametry

Metoda COCOMO II – trzy warianty modelu

1. Model kompozycji/wczesnego prototypowania – najwcześniejsza faza cyklu, model odpowiedni dla projektów, w których stosowane są narzędzia GUI, podejście prototypowania oraz rozległego ponownego użycia (ang. reuse), stosowane są punkty obiektowe i prosta formuła nakładów.

2. Model wczesnego projektowania – faza cyklu po uzgodnieniu wymagań, ale przed zdefiniowaniem całej architektury, najczęściej stosowane są punkty funkcyjne transponowane na SLOC.

3. Model po - architekturowy - po utworzeniu architektury i podczas budowy oprogramowania, posiada nowe sterowniki kosztowe i nowe reguły obliczania linii kodu

(SLOC).

Ocena eksperta w grupach

• Technika grupowej oceny eksperta jest stosowana w początkowej fazie projektu

• Recenzje grupowe – techniki niestrukturalne

• Technika Wideband Delphi – technika strukturalna

Recenzje grupowe

• Każdy członek zespołu samodzielnie szacuje fragmenty projektu

• Spotkanie grupy w celu omówienia i dyskutowania oszacowań

• Obliczenie średniej wielkości oszacowań

• Wielkość średnia oszacowania lub przedziały wielkości muszą być przedyskutowane

• Konieczne jest uzyskanie consensusu – wypracowanie wspólnego oszacowania, akceptowanego przez całą grupę

• Uwaga! Nie należy mechanicznie przyjmować wielkości średniej

Metody uproszczone:

Uproszczone metody szacowania rozmiaru oprogramowania

• orzekająca

• ekstrapolacyjna

• próbkowania

• „przedwczesnego zapłonu”

• uśredniania

Metoda orzekająca NESMA

• Wielkość orzekająca UFP obliczana na podstawie liczby ILF i EIF z metody FP:

oUFP = 35 x ILF + 15 x EIF

Metoda ekstrapolacyjna szacowania FP [model ILF Tichenora Ch.]

• Ekstrapolacja rozmiaru na podstawie wybranego elementu systemu – ILF

• Krok 1: UFP = liczba ILF * a, gdzie a = 11,01 system plikowy; = 14,93 system transakcyjny

• Krok 2: FP = 1,0163*(UFP*TCF)^1,0024

Metoda „przedwczesnego zapłonu”. Szacowanie FP na podstawie relacji między liczbą typów encji a liczbą FP

FP = liczba typów encji * a * b * c

• a – 0.8, ponieważ średnio 20% encji podlega grupowaniu

• b – 33, suma składników typu ILF, EI, EO, EQ wg wagi średniej złożoności:

33 = 1*10(ILF)+3*4(C/U/D)+0.5*4(EI)+1*5(EO)+1*4(EQ)

• c – 1.25, ponieważ średnio tylko 75% wymagań jest znanych na początku

Metoda prognozy „trzech punktów” - wartości oczekiwanej [Putnam i Myers] (1)

– opracowanie prognoz dla trzech scenariuszy: optymistyczny (max), najbardziej prawdopodobny (npd), pesymistyczny (min)

– obliczenie wartości oczekiwanej wg ustalonego rozkładu zmiennej

Prognozowanie FP metodą „trzech punktów” (2)

• Szacowanie aspektów dziedziny informacyjnej

– oszacować przedziały wartości zmiennych prognostycznych - składniki UFP,

– oszacować wartości: optymistyczną, najbardziej prawdopodobną, pesymistyczną

– obliczyć wartości oczekiwane każdej zmiennej, np. dla rozkładu beta

S = (sop+4*sm+sp)/6

– porównać otrzymane wartości oczekiwane z danymi historycznymi mierzonymi za pomocą FP

Uśrednione szacowanie nakładu za pomocą FP (4)

• Szacowanie współczynnika TCF na poziomie średnim TCF = 1

• Szacowanie FP na podstawie np.. metody trzech punktów FP = 318*1,0 = 318

• Zastosowanie wskaźników otrzymanych przy podobnych przedsięwzięciach, np.:

• Oszacowanie wielkości projektowych:

Dokładność metody szacowania

• Średnia wielkość błędu względnego

MMRE = suma x(i)/n

gdzie: x (i)= |e(i)-a(i)|/a(i)

e(i) – wartość oszacowana i-tego projektu a(i) – wartość rzeczywista i-tego projektu

n – liczba projektów

i – konkretny projekt

• MMRE<0.25 - miara rzetelności szacowania

• Ocena rzetelności danej metody:

PRED(V) = N/n

gdzie: N – liczba projektów z x(i)<V

n – liczba wszystkich projektów

V – wymagana miara rzetelności szacowań

• PRED(0.25)>0.75 uważa się za dobry wynik

Czynniki dokładności oszacowania nakładów na

projekt informatyczny

• dokładność oszacowania wielkości produktu końcowego

• zmienność wymagań wobec produktu

• znajomość metod obliczania kosztów, terminów i nakładów pracy

• uwzględnienie kwalifikacji wykonawców projektu

• stabilność środowiska projektu

Standardowa procedura szacowania projektów oprogramowania

• Wyraźnie określony proces tworzenia oszacowań, obowiązujący na poziomie organizacji

• Standardowa procedura nie pozwala

– na zgadywanie i szacowanie bez przygotowania

– wprowadzanie zmiany oszacowań bez uzasadnienia

• Standardowa procedura sprzyja

– zachowywaniu spójności procesu szacowania

– pozwala na śledzenie wykonanych działań, szczególnie istotne w przypadku błędnych oszacowań

– poprawianiu i doskonaleniu procesu szacowania (procedury)

Typowe elementy standardowej procedury szacowania projektów oprogramowania

• Stosowanie obliczeń zamiast subiektywnej oceny

• Stosowanie kilku metod szacowania i porównywanie ich wyników

• Planowane powtórki szacowania w predefiniowanych miejscach projektu

• Określenie potrzeb zmiany wymaganej metody szacowania w trakcie realizacji projektu

• Opis dokładności szacowania

• Określenie warunków dla zastosowania wyników szacowania do ustalenia budżetu projektu

• Wymagania archiwizacji danych procesu szacowania i weryfikowania skuteczności procedury

• Szczegóły standardowych procedur są zróżnicowane ze względu na rodzaj projektu

Przykład standardowej procedury szacowania dla sekwencyjnych projektów oprogramowania – krok I

Oszacowanie rozpoznawcze – zatwierdzona definicja produktu

– Wykonanie co najmniej jednego oszacowania przy użyciu każdej z następujących metod:

• Metoda wstępująca przy użyciu WBS

• Metoda zstępująca, przy zastosowaniu podobieństwa do analogicznych projektów

• Metoda przy użyciu składników standardowych: strony WWW, tabele baz danych, reguły biznesowe, ekrany, okna dialogowe, raporty …

– Uzyskanie jednopunktowego oszacowania wielkości nominalnej metodą Wideband Delphi, np.. nakład o wielkości N

– Oszacowanie powinno być przedstawione w postaci przedziału od minus 50% do plus 100% (0.5N do 2N)

• Jednopunktowe oszacowanie nominalne nie powinno być ujawniane

• Oszacowanie to nie powinno być wykorzystywane do ustalania budżetu ani podejmowania zewnętrznych zobowiązań

Standardowa procedura szacowania dla sekwencyjnych projektów oprogramowania – krok II

Oszacowanie budżetu – zakończone projektowanie produktu

– Wykonanie nowego oszacowania przy użyciu dwóch metod:

• Metoda wstępująca przy użyciu WBS

• Metoda przy użyciu składników standardowych

– Wykonanie oszacowania punktów funkcyjnych

• Obliczyć punkty funkcyjne na podstawie specyfikacji wymagań

• Skalibrować otrzymane obliczenia na podstawie danych historycznych

• Oszacować nominalny nakład pracy i harmonogram przy użyciu oprogramowania do szacowania

– Powtarzanie oszacowania do uzyskania zbieżności wszystkich wyników w granicach 5%. Użycie wielkości średniej z tych oszacowań jako oszacowanej wielkości nominalnej N

– Obliczenie nowego przedziału oszacowań jako 0.8N do 1.25N

• Podstawą budżetu powinna być wielkość 1N

• Rezerwa budżetowa 0.25N

• Ujawnić tylko górną granicę 1.25N

• Nie używać tego oszacowania do zewnętrznych zobowiązań

Standardowa procedura szacowania dla sekwencyjnych projektów oprogramowania – krok III

Wstępne oszacowanie zobowiązań – po drugim wydaniu tymczasowym

– Wykonanie nowego oszacowania przy użyciu metody wstępującej

• Utworzenie szczegółowej listy zadań

• Oszacowanie potrzebnego nakładu pracy przez programistów i testerów i innych przy użyciu rozkładu beta (metoda trzech punktów)

• Obliczenie sumy nominalnych oszacowań

– Porównanie otrzymanego wyniku z wynikiem z poprzedniego wydania (krok II).

• Obliczenie nominalnego oszacowania za pomocą wzoru:

(2xgórne oszacowanie +dolne oszacowanie)/3

– Obliczenie nowego przedziału oszacowania jako 1.0N do 1.1N

• Górna granica przedziału może być ujawniona na zewnątrz i użyta do zobowiązań zewnętrznych

• Przedział 1.0N do 1.1N można ujawniać wewnątrz firmy

Standardowa procedura szacowania dla sekwencyjnych projektów oprogramowania – krok IV

Końcowe oszacowanie zobowiązań – po trzecim wydaniu tymczasowym

– Porównanie szacowanego wyniku z faktycznym wynikiem z poprzedniego wydania (krok III).

• Obliczenie poprawionego oszacowania nominalnego za pomocą wzoru: pozostały nakład pracy = planowany pozostały nakład pracy/(faktyczny dotychczasowy nakład pracy/planowany dotychczasowy nakład pracy)

• Dodanie wszystkich zadań pominiętych w kroku III

– Użycie sumy powyższych dwóch składników jako nowego nominalnego nakładu pracy N

• Wartość nominalna 1.0N może być ujawniona na zewnątrz

• Zewnętrzne zobowiązania mogą być ustalone na 1.0N

• Przedział od 0.9N do 1.1N może być podany do użytku wewnętrznego (plus/minus 10%)

Standardowa procedura szacowania dla sekwencyjnych projektów oprogramowania – krok V i VI

• Ponowne oszacowanie projektu – w trakcie realizacji w odpowiedzi na duże zmiany w jego założeniach

• Zakończenie projektu

– Zebranie i archiwizacja danych o faktycznych rezultatach projektu

– Sprawdzenie dokładności każdego oszacowania

• Analiza głównych przyczyn wszystkich poważnych błędów

• Ocena możliwości uzyskania takiej samej dokładności oszacowań mniejszym wysiłkiem

• Propozycje zmian w standardowej procedurze szacowania

8. Metodyki adaptacyjne/zwinne: metoda Scrum.

Metoda Scrum

Podstawowe założenia:

• iteracje – najczęściej 30-dniowe przedziały czasowe - sprint

• przyrostowe tworzenie oprogramowania

• empiryczna kontrola procesu: przejrzystość, kontrola, adaptacja

• samorganizujący się zespół projektowy

Narzędzia: SpiraPlan® - Scrum Project Management

Role w Scrum

Właściciel produktu

• Jest właścicielem definicji sukcesu.

• Kieruje produktem od sprintu do sprintu, aby zapewnić największy zwrot z inwestycji i dostarczyć pewną wartość dla organizacji.

• Zarządza wskaźnikiem ROI (return on investment) poprzez określenie priorytetów oraz publikację planów. Jest jedynym właścicielem zaległości produktu. Określa plan rozwoju projektu poprzez wyznaczanie priorytetów zaległości.

• Eliminuje błędy wielu szefów, różnych opinii i zakłóceń.

Mistrz

• Jedna osoba z zespołu wciela się w rolę mistrza ułatwiającego codzienną pracę zespołu. Mistrz nie robi nic innego, całe jego obciążenie to pełnienie roli Mistrza w pełnym wymiarze czasu pracy.

• Mistrz jest odpowiedzialny za zapewnienie, że zespół żyje wartościami i pracuje zgodnie z regułami metody Scrum.

• Jest tarczą zespołu projektowego dla agresywnych klientów, upewniając się, że zespół nie wychodzi ponad zobowiązania aktualnego sprintu.

• Mistrz staje się odpowiedzialny za usuwanie wszelkich przeszkód, które są zgłaszane przez zespół podczas spotkań.

• Rola mistrza jest zwykle pełniona przez kierownika projektu lub kierownika zespołu technicznego, ale może to być każda osoba z zespołu zarządzania projektem.

Członek zespołu projektowego – tzw. „świnki”

• Właściciel produktu

• Mistrz

• Wykonawcy: architekt, programista, analityk, tester, ekspert …

Pozostali interesariusze projektu – tzw. „kurczaki”,

• nie posiadają formalnej odpowiedzialności

• są zainteresowani projektem,

• biorą udział w spotkaniach przeglądu sprintu,

• podczas spotkań nie mogą mówić, co zespół powinien zrobić

Artefakty Scrum

BACKLOG (lista zaległości) produktu – rejestr produktowy

• Lista wymagań funkcjonalnych i niefunkcjonalnych projektu, ułożonych według priorytetów z przewidywanym czasem na ich zakończenie i wdrożenie.

• Szacunki są podawane w dniach i są bardziej precyzyjne dla wyższych pozycji w kolejce zaległości produktu.

• Priorytety pozycji powinny być ustalone na podstawie największej wartości dla firmy, obliczone za pomocą metody ROI.

• Ta lista w trakcie realizacji rozwija się i zmienia.

BACKLOG sprintu – rejestr zaległości sprintu

• Rejestr zadań, które zespół Scrum zobowiązuje się wykonać całkowicie w bieżącym sprincie.

• Pozycje zaległości sprintu pochodzą z rejestru zaległości produktu.

• Zespół kieruje się priorytetami ustalonymi przez właściciela produktu i swoimi oszacowaniami dotyczącymi czasu ich wykonania.

• Krytyczne jest to, że to sam zespół wybiera pozycje z listy zaległości, ponieważ to zespół zobowiązuje się do zakończenia tych zadań.

Iteracja w Scrum - sprint

Sprint

• Sprint jest to czas przeznaczony na opracowanie jednego przyrostu produktu. Jest to metoda „time boxing: czas, koszt i zakres, ważniejszy jest zakres niż poślizg w dacie zakończenia.

• Sprint obejmuje projektowanie, programowanie, testowanie i dokumentowanie.

• Tylko po rozpoczęciu sprintu zespół może dodawać lub usuwać elementy z rejestru zaległości sprintu.

• Jeżeli osiągnięcie celu sprintu nie ma sensu, to następuje tzw. Nadzwyczajne zakończenie sprintu.

Sprint wydania

• Wydanie oprogramowania do działania (produkcji) wymaga specjalnego sprintu, nazywanego „sprintem wydania”.

• Do tego sprintu jest dedykowany zespół sprintu wydania

Spotkanie planowania sprintu

• Celem jest ustalenie rejestru zaległości sprintu

• Właściciel produktu opisuje właściwości o najwyższym priorytecie, a zespół decyduje, do czego może się zobowiązać i co może dostarczyć w danym sprincie. Odbywa się to w ciągu dwóch kolejnych spotkań (4 godziny),

• Zespół planuje zadania do wykonania, których zbiór tworzy rejestr zaległości sprintu

Codzienny Scrum

• Codzienne spotkanie trwające 15 minut, ważne jest aby odbywało się codziennie w tym samym miejscu i czasie.

• Podczas spotkania zespół siedzi w kręgu naprzeciwko siebie i każdego członka zespołu dotyczą następujące trzy pytania:

1. Co zrobiłeś od ostatniego spotkania?

2. Co będziesz robił od teraz do następnego spotkania?

3. Jakie problemy przeszkadzają Ci w wykonywaniu pracy?

Przegląd sprintu

• Na koniec każdego sprintu odbywa się spotkanie przeglądowe sprintu. Podczas tego spotkania zespół Scrum demonstruje, co zostało zakończone w fazie tego sprintu. Zwykle jest to forma prezentacji nowych funkcji.

• Zaleca się, aby spotkania przeglądowe sprintu było nieformalne, z zasady zakazuje się slajdów programu PowerPoint i pozwala na poświęcenie nie więcej niż dwie godziny czasu na przygotowanie

się do tego spotkania. Spotkania nie mogą stać się uciążliwe dla zespołu, powinny być naturalnym wynikiem sprintu.

• Uczestnicy spotkania przeglądowego sprint: właściciel produktu, zespół Scrum, mistrz, zarząd, klienci i inżynierowie z innych projektów.

• Podczas tego spotkania projekt jest porównywany z celem sprintu ustalonym podczas spotkania planowanie sprintu. Najlepiej jest, gdy zespół zakończy każdą pozycję z rejestru produktów dla tego

sprintu, ale ważniejsze jest osiągnięcie celu sprintu.

Retrospektywa sprintu

• To spotkanie jest wykorzystywane przez mistrza do omówienia zakończonego Sprintu i ma na celu określenie, co można zmienić w następnym Sprincie, by praca była przyjemniejsza i bardziej

produktywna.

• Dyskusja może dotyczyć wszystkiego, co wpływa na pracę zespołu: procesy, praktyki, komunikację, środowisko, narzędzia.

• Retrospektywa Sprint jest ważnym narzędziem, które pozwala zespołowi na ciągłą poprawę w całym cyklu życia projektu.

• Scrum powinien być postrzegany jako ramy, które powinny być odpowiednio dostosowane do danego projektu, zespołu i konkretnej sytuacji.

Korzyści z zastosowania metody Scrum

• Zapewnia najwyższe wartości firmy na wczesnym etapie projektu, unikając jednocześnie nierealistycznych wymagań i niepotrzebnej pracy

• Poprawia satysfakcję klienta

• Dostarcza podejścia kierowanego przez klienta

• Skupia się na szybkości dostawy

• Zapewnia otwartość i przejrzystość dla klientów

• Usuwa przeszkody w sposób priorytetowy i systematyczny

• Poprawia utrzymanie pracowników przez umożliwienie oraz promowanie samorządności, komunikacji w zespole, naukę i rozwój

• Efekty firmy Microsoft ze Scrum: czterokrotny wzrost średniej wydajności i dwanaście razy lepsza jakość

Podstawowe różnice w podejściu tradycyjnym i Scrum

• Kaskadowy model zarządzania projektem bazuje na dokładnie zdefiniowanej metodyce, najpierw z góry określone wymagania, logiczny podział pracy, estymacja, planowanie, a następnie rozpoczęcie realizacji, w której ogranicza się zmiany, jako zagrożenie dla planu

• W Scrum oczekuje się zmian, co oznacza, że końcowy wynik będzie produktem, który w większym stopniu spełni potrzeby klientów na zakończenie projektu.

• W Scrum zakłada się, że nastąpią znaczące zmiany linii bazowej w trakcie realizacji projektu.

• Jest to nieprzewidywalne środowisko zarządzania projektami, do którego zaleca się wykorzystywanie metod empirycznych, a nie deterministycznych.

9. Jakość i modele jakości produktu informatycznego

Jakość produktu informatycznego [IEEE]

• Stopień zrozumienia i odkrycia potrzeb w trakcie definicji wymagań

• Stopień przekształcenia definicji wymagań w produkt informatyczny

• Stopień wspierania produktu

• Stopień, w jakim produkt odpowiada wymaganiom sprecyzowanym i domniemanym

Jakość produktu informatycznego [ISO/IEC 14598-1:1999]

Zbiór charakterystyk pozwalających na stwierdzenie zadowolenia w odniesieniu do wywnioskowanych potrzeb.

Model jakości oprogramowania

Zbiór charakterystyk i relacji między nimi, które stanowią podstawę dla specyfikacji wymagań jakości

i oceny jakości.

Przykłady modeli jakości oprogramowania

Podejście hierarchiczne

• McCalla

• Boehma

• FURPS

• ISO 9126

• Dromeya

Podejście wielowymiarowe

• Ortega, Perez, Rojas

Zasada budowy modeli jakości oprogramowania

FURPS [Grady i Caswell HP 1987]

• Funkcjonalność

• Łatwość użytkowania

• Niezawodność

• Wydajność

• Łatwość wspierania

Model Dromeya

Trzy modele wyróżnione ze względu na etapy cyklu życia:

• model wymagań

• model projektu

• model implementacji

Wprowadza dodatkową charakterystykę:

• dojrzałość procesu

Model i norma ISO/IEC 9126

Jako konsensus między różnymi modelami na podstawie modelu McCalla

Trzy poziomy

• charakterystyki

• podcharakterystyki

• metryki

Koncepcja modelu jakości

Składniki normy jakości PI [ISO/IEC 9126]

9126 – 1: model jakości

9126 – 2: metryki zewnętrzne

9126 – 3: metryki wewnętrzne

9126 – 4: metryki jakości użytkowej

Definicja jakości wewnętrznej [ISO/IEC 9126-1]

• Jakość wewnętrzna to ogół cech oprogramowania z wewnętrznego punktu widzenia.

• Jest mierzona i oceniana podczas projektowania i kodowania w stosunku do wymagań określonych w specyfikacji wymagań (modele statyczne i dynamiczne) i kodzie źródłowym programu, przy użyciu metryk wewnętrznych.

Metryki wewnętrzne

• Miara ilościowa, stosowana do mierzenia atrybutu lub charakterystyki produktu informatycznego, wyprowadzonej pośrednio lub bezpośrednio z produktu

• Stosowana do produktu w postaci źródłowej, podczas projektowania i kodowania na wczesnym etapie rozwoju

Definicja jakości zewnętrznej [ISO/IEC 9126-1]

• Jakość zewnętrzna to ogół cech oprogramowania z zewnętrznego punktu widzenia.

• Mierzona i oceniana względem uruchamianego programu podczas testowania w środowisku symulowanym i na danych testowych, przy użyciu metryk zewnętrznych.

• Podczas testowania większość usterek powinna być wykryta i usunięta, jednak niektóre błędy, po zakończeniu testowania, nadal mogą zostać.

Metryki zewnętrzne

• Miara ilościowa, stosowana do mierzenia atrybutu lub charakterystyki produktu informatycznego, wyprowadzonej z zachowania całego systemu lub jego części

• Stosowana do produktu w postaci wykonywalnej, podczas testowania lub działania, w późniejszym etapie rozwoju lub po wprowadzeniu do procesu eksploatacji

Definicja jakości użytkowej [ISO/IEC 9126-1]

Zdolność produktu do umożliwienia określonym użytkownikom osiągnięcia wyspecyfikowanych celów w zakresie

• efektywności,

• produktywności,

• bezpieczeństwa,

• satysfakcji

w specyficznym kontekście użycia.

10. Wybrane aspekty projektowania: projekt formularza ekranowego i papierowego, projekt

raportu, reguły projektowania relacyjnej bazy danych. Zasady projektowania interfejsu

użytkownika.

Zasady projektowania ekranu

• Podział okna na sekcje funkcjonalne

• Zależność tematyczna między wywołującymi się oknami

• Zasady prezentacji tekstu

• grupowanie informacji wg zadanego kryterium (tytuły)

• wyodrębnianie tekstu (wybór czcionki: rodzaj, rozmiar, kolor)

• Elementy graficzne: obramowania, różne kolory tła (unikać deseni), ikony

• Dźwięk do ostrzegania i potwierdzania

• Unikanie złożonych elementów graficznych (np. ruchomych)

• Przestrzeganie standardowych konwencji kolorowania

Projektowanie formularzy papierowych

• Kolory - podkreślenie ważności niektórych danych i poprawa czytelności

• Dostateczna ilość miejsca w polu

• Pola wyboru

• Instrukcje wypełniania pól

• Ustalenie kolejności i grupowanie pól

• Formularze samokopiujące

• Unikanie zbędnych pytań

PROJEKT RAPORTU

Projekt funkcji wydawniczych

• Funkcje wyszukujące i przekształcające informacje z bazy danych w celu dostarczenia wiedzy użytkownikowi

• Postać raportu zależy od:

– rodzaju użytkownika

– przeznaczenia danych

– sposobu korzystania z danych

• Specyfikacja funkcji wydawniczej:

– kryteria wyboru danych

– lista przeszukiwanych tabel i relacji

– sposób sortowania wyszukanych danych

– algorytm otrzymywania danych pochodnych

Podstawowe składniki raportu

• dane identyfikacyjne: nazwa, krótki opis, data sporządzenia, numer wersji

• prezentowane dane, np. układ tabelaryczny, wykresy, komentarze …

• stronicowanie, kontynuacja strony

• zakończenie raportu

Reguły projektowania relacyjnej bazy danych(Z INTERNETU)

Proces projektowania relacyjnej bazy danych składa się z wielu elementów. Do najważniejszych należą:

Zasady projektowania tabel bazy danych:

Ogólne zasady projektowania interfejsu użytkownika

• Minimalizacja interakcji

• Zachowanie stylu interakcji systemów używanych i akceptowanych przez użytkownika

• Możliwość wyboru kolejności wykonania operacji lub anulowania

• Pomoc: wartości domyślne, znana użytkownikowi terminologia, tytuły ekranów, znaki zachęty, podpowiedzi (najlepiej kontekstowe)

• Obsługa błędów:

- zachowanie reguł integralności przedsiębiorstwa (transakcja, wyłączność, równoległe systemy),

- pomoc użytkownikowi w naprawie błędu lub kontynuacja działania (komunikat o błędzie i podpowiedź dalszego działania)


Wyszukiwarka

Podobne podstrony:
OPRACO WYK 13
Geofizyka opracowanie z wyk, geofizyka
TPL WYK 12 12 26 Ekstrakcja surowców roślinnych podsumowanie
Mikro wyk.12, EKONOMIA, MIKROEKONOMIA, mikroekonomia
moje opracowane wyk ady
RF.wyk.12.wynik.finansowy
wyk 12(2)
socwsi Wyk 12, Socjologia wsi
opracowanie ćw 12, Onedrive całość, Rok I, II sem, Psychologia emocji i motywacji, Streszczenia
Wyk. 12 Profilaktyka chorób cywilizacyjnych w wieku rozwojowym, Lekarski, Propedeutyka pediatrii, Wy
Bud wyk 12
TPL WYK 12 12 26 Napary, Odwary, Maceracje
TPL WYK 12 09 22 Rozpuszczanie
Prawo cywilne wyk.12 2012-03-20, Prawo Cywilne
fs wyk 3 12

więcej podobnych podstron