Modele cyklu życia projektu:

● Model kaskadowy: zakończenie etapu powoduje całkowite jego zamknięcie; dobry dla projektów krótkoterminowych, wbrew wszystkiemu istnieje możliwość weryfikacji etapu, aczkolwiek faktycznie nie ma elastyczności; modyfikujemy wtedy oś czasu i ustalamy kto, gdzie i “za ile” ma wrócić do wcześniejszego etapu i go poprawić, ale jest to bardzo kosztowne;

● Model sterowany dokumentami: na każdym etapie projekt można przerwać i przekazać go w celu skorygowania obecnie gotowych modułów i akceptacji dalszych założeń; koszt projektu rośnie od 30% do 50%, a efektywność realizacji rośnie zdecydowanie bardziej - większość tak realizowanych projektów dochodzi do skutku, podczas gdy te realizowane innymi metodami są często porzucane i niedokończone; taki projekt można w każdej chwili odebrać jednemu realizatorowi i przekazać zupełnie innemu bez większych problemów; ze względu na wysokie koszty jest stosowany głównie przez takie organizacje jak armia USA;

● Model V: fazy otwierające i zamykające, linie poziome mówią, że możemy jednocześnie pisać dwa moduły, mimo że nie do końca wiemy, jak to będzie wyglądać, (np. pisanie kodu wraz z testami); żaden etap po lewej stronie nie może się zakończyć bez stworzonych dla niego testów (znajdujących się po prawej stronie) potrzebnych do jego weryfikacji;

● Model spiralny: duże ryzyko i niepewność musi być uwzględniana co jakiś czas; mając określone cele i alternatywy, określamy dla nich ryzyko - wtedy wybieramy taką alternatywę, by w “naszej” ocenie było dobre, gdyż “to zależy” i nie ma konkretnej odpowiedzi, ale trzeba podjąć decyzję - zwykle wtedy pomaga doświadczenie, każdy kolejny etap projektu jest planowany po zakończeniu poprzedniego.

● Model prototypowanie: dokumentacja pobieżna, ogólna, bez szczegółów; wymaga prototypowania i budowania namiastki produktu, by następnie - zgodnie z wybranym modelem - wytworzyć finalny projekt. Trzeba uważać na to, żeby klient nie doszedł do błędnego wniosku, że prototyp jest działającym produktem, gdyż może mieć pretensje “że on widział to samo pół roku temu, dlaczego więc po pół roku prac firma nie pokazuje mu niczego nowego”, dlatego należy wyraźnie zaznaczać, że prezentuje się prototyp który nie

działa;

● Model “programowanie odkrywcze”: tzw. “jazda bez trzymanki”, brak precyzyjnych (często żadnych) wymagań od klienta; jest to podstawa dla lekkich metodyk typu Agile;

● Model “realizacja przyrostowa”: w miarę kompletne wymagania, przygotowanie modułu, ewentualna weryfikacja klienta i wtedy następuje jego zamknięcie i dostarczenie w formie podzbioru funkcji; realizacja pozostałych modułów następuje w czasie;

Bezpieczeństwo systemów

● Bezpieczeństwo systemu nie jest tożsame z niezawodnością. System zawodny może być bezpieczny, jeśli skutki tych błędów nie są groźne (skutki zdrowotne, finansowe lub prawne).

● Analiza drzewa błędów – bardzo prosta technika zwiększania bezpieczeństwa. Korzeniem tego drzewa jest sytuacja niebezpieczna i ta sytuacja ma swoje przyczyny, które także mogą mieć przyczyny, które w sumie/koniunkcji/alternatywie mogą prowadzić do błędu zagrażającemu bezpieczeństwu. Schodzimy w sam dół, aż do pierwotnej przyczyny. Starajmy się, aby te fragmenty kodu, które odpowiadają za te przyczyny, były napisane bez błędów – oddajmy je w ręce solidnych, doświadczonych testerów. I podobnie, niech ten kawałek kodu napiszą osoby z doświadczeniem, których sposób działania pozwoli na uniknięcie bardzo

pospolitych i trywialnych błędów.

○ Można też stosować techniki programowania N-wersyjnego, np. budujmy jakiś kawałek kodu za pomocą kilku algorytmów, które rozwiązują te same problemy. Jeśli każdy jest napisany przez inny zespół i trzy dają dobrą odpowiedź, to jesteśmy zadowoleni. Jeśli wszystkie trzy (bądź wybrana przez nas kombinacja) dają złą odpowiedź, to coś trzeba zrobić. Możemy wystawić komunikat, że coś jest nie tak.

Systemy jakości

Systemy jakości wprowadzone zostały w celu poprawienia jakości towarów przemysłowych, ale wykorzystuje się je także przy produkcji software’u. Charakteryzują się one opisywaniem procedur powtarzalnych, za którymi powinniśmy podążać, zapewnieniem minimalnej ilości defektów oraz tworzeniem coraz lepszych produktów (jap. kaizen – jeśli możesz zrobić coś lepiej, możesz coś poprawić, to zrób to). Na wykładzie było mówione, że historycznie systemy jakości były wprowadzone w jakiś fabrykach, gdzie producenci kantowali kupców sprzedając towar o niższej jakości - polityka jakości to był opis procesu tworzenia produktu, którego producent zawsze się trzymał.

● Jak przełożyć te charakterystyki na IO?

● Jak zdefiniować dane o defektach?

● Jakich norm cząstkowych (standardów) się trzymać?

● Jakość oprogramowania wynika z kosztów, jakie ma ponieść klient. W przypadku usterek, płaci za nie klient.

CMM - Capability Maturity Model

Opis jego systemu jakości znajduje się w PDFie dra. Unolda i jest naprawdę dobrze opisany.

Model propagacji błędów - model Pressmana (IBM)

Model propagacji błędów wg Pressmana (IBM) - koszt błędów zależy od fazy w której ten błąd został znaleziony i rośnie znacznie wraz z kolejnymi fazami (koszt dla fazy projektowania to tylko 1, a dla fazy po uruchomieniu systemu to już 67 (80)). Ilość błędów wychodzących z systemu to suma (liczby błędów przepuszczanych + liczba błędów wzmacnianych (razy wzmocnienie, zależne od fazy) + liczba nowych błędów każdej fazy - efektywność wykrycia błędów na każdym etapie). Wzmocnienie zależy od fazy projektu i dla fazy projektowania szczegółowego wynosi 1,5, a dla implementacji 3. Z tego modelu wynika, że na każdym etapie efektywność wykrywania błędów powinna być wysoka.

Konserwacja oprogramowania

Konserwacja oprogramowania to z punktu widzenia klienta jego dalsza eksploatacja, z punktu widzenia twórców

systemu jest to modyfikacja, pielęgnacja. Definiujemy trzy klasy konserwacji:

● modyfikacje poprawiające: gdy pojawią się błędy, względnie do podpisanej umowy serwisowej, twórcy reagują w miarę szybko i wprowadzają poprawki, by pozbawić system kolejnej partii błędów, nie wyłapanych podczas testów;

● modyfikacje ulepszające: wynikają zwykle z zachcianek klienta i zmiany jego wymagań; zdarza się jednak, że to firma wychodzi z inicjatywą ulepszenia oprogramowania, ot np. żeby obsługiwało dodatkowe wzory druków bądź dodatkowe urządzenie fiskalne; (najczęściej po to żeby wyprzedzić konkurencję).

● modyfikacje dostosowujące: wynikają ze zmiany środowiska, w którym pracuje system, np. ze zmiany przepisów prawa, regulaminów, druków, zasad i polityki obowiązującej w firmie klienta; bardzo często do tej klasy wlicza się także to, że zespół tworzący oprogramowanie sam modyfikuje je, dostosowując go i ponownie poziomując go wśród konkurencji;

Koszty konserwacji wynikają ze stabilności środowiska, w którym pracuje system, platformy sprzętowej i oprogramowania systemowego oraz od czasu pracy użytkownika. Aby zredukować takie koszty, najważniejszą chyba kwestią jest znajomość środowiska, dla którego zostało napisane oprogramowanie. Jeśli tworzymy program dla biura prawniczego, dobrze znać prawo, bądź kogoś, kto się na tym prawie zna. Choćby po to, żeby nasze oprogramowanie było na bieżąco ze zmianami przepisów oraz żeby czas i budżet potrzebny na wprowadzanie modyfikacji z tego zakresu były jak najmniejsze.

Ważna jest też jakość dokumentacji technicznej tworzonej w czasie budowy systemu, bo to właśnie w czasie budowy musi być podjęta większa część decyzji, które w przyszłości wpłyną na redukcję kosztów konserwacji.