Usability:
Użyteczność (ang. usability) – własność produktów decydująca o ich jakości użytkowej. Pojęcie to odnoszone jest najczęściej do interaktywnych urządzeń, aplikacji oraz stron internetowych (jako web usability).
Norma ISO 9241 z 1998 definiuje użyteczność jako miarę wydajności, efektywności i satysfakcji użytkownika z jaką dany produkt może być używany dla osiągnięcia danych celów przez danych użytkowników w danym kontekście[1].
Jakob Nielsen zdefiniował usability jako zbiór 5 elementów[2]:
nauczalność (learnability) - jak łatwo jest wykonać proste zadania przy pierwszym kontakcie z produktem
efektywność (efficiency) - jak szybko korzystają z produktu użytkownicy, którzy już go znają
zapamiętywalność (memorability) - łatwość przypomnienia sobie korzystania z produktu po dłuższej przerwie
błędy - jak często są popełniane i jak łatwo użytkownicy mogą się z nich wydobyć
satysfakcja - jak bardzo produkt przyjemny jest w korzystaniu.
Sama użyteczność bywa używana wymiennie z user experience (UX), jednak w odróżnieniu od UX obejmuje ona tylko tę część kontaktu z produktem, dotyczącą bezpośredniego korzystania z niego[3].
RUP:
Rational Unified Process (RUP) to proces iteracyjnego wytwarzania oprogramowania opracowany przez firmę Rational Software Corporation (firma została przejęta przez IBM).
Proces RUP nie jest pojedynczym, ściśle określonym procesem, ale raczej szablonem procesu. Został on zaprojektowany w celu przystosowania do charakteru konkretnej organizacji (przedsiębiorstwa), konkretnego zespołu projektowego lub nawet charakteru konkretnego projektu. Z szablonu RUP można wybrać elementy w zależności od konkretnych potrzeb.
RUP bazuje na zbiorze zasad inżynierii programowania oraz najlepszych praktykach, na przykład:
Iteracyjnym wytwarzaniu oprogramowania (Iterative Development)
Zarządzaniu wymaganiami (Requirement Management)
Używaniu architektury bazującej na komponentach (Component-based architecture)
Graficznym projektowaniu oprogramowania
Kontroli jakości oprogramowania (Quality Assurance)
Procesu kontroli zmian w oprogramowaniu (Change Management)
Cykl życia projektu[edytuj]
Cykl życia w RUP bazuje na modelu spiralnym. RUP jest dostępny jako struktura prowadzenia projektu, która może być personalizowana w celu przystosowania do specyficznych potrzeb projektowych. Cykl życia w RUP układa zadania w fazy i iteracje.
Projekt został podzielony na cztery fazy:
Faza rozpoczęcia (Inception phase)
Faza opracowywania (Elaboration phase)
Faza konstrukcji (Construction phase)
Faza przekazania systemu (Transition phase)
Faza rozpoczęcia (Inception phase)[edytuj]
W fazie tej formułowany jest problem – zagadnienie biznesowe (business case). Przy opracowaniu tego zagadnienia określa się jego kontekst (business context); czynniki wpływające na jego powodzenie (success factors) – na przykład spodziewany zwrot z inwestycji, zwiększenie udziału w rynku; oraz prognozę finansową. Dodatkowo uzupełnia się go o prosty modelprzypadków użycia, plan projektu, wstępną analizę ryzyka oraz opis projektu (główne wymagania, ograniczenia, główna funkcjonalność). Po stworzeniu powyższych dokumentów projekt sprawdza się według następujących kryteriów:
Zgoda użytkowników na oszacowany koszt/czas wykonania.
Zrozumienie wymagań poprzez ocenę jakości głównych przypadków użycia.
Wiarygodność szacowanych kosztów, priorytetów, ryzyka i planu procesu wytwarzania.
Rozmiar stworzonego prototypu architektury.
Wydatki rzeczywiste względem wydatków planowanych.
Jeżeli wstępny projekt nie osiągnie kamienia milowego (ang. milestone), nazywanego Lifecycle Objective Milestone, może być albo zakończony, albo faza ta może zostać jeszcze raz powtórzona (w celu ulepszenia projektu wstępnego).
Faza opracowania (Elaboration phase)[edytuj]
W tej fazie projekt systemu nabiera kształtów. Przeprowadzona jest analiza dziedziny zagadnienia (ang. Domain Analysis – nazywana też w literaturze polskiej Analizą/Modelem Domeny) i budowana podstawowa architektura systemu.
Zakończenie tej fazy wiąże się z osiągnięciem kamienia milowego Lifecycle Architecture Milestone poprzez spełnienie kryteriów:
Stworzony został model przypadków użycia – zidentyfikowani zostali aktorzy i większość przypadków. Model jest kompletny w 80%.
Została opracowana architektura systemu.
Architektura ta pozwala realizować główne przypadki użycia.
Sprawdzona została zgodność zagadnienia biznesowego oraz listy ryzyk.
Stworzony został plan prac dla całego projektu.
Jeżeli projekt nie może przejść tej fazy, ciągle mamy czas na jego zaniechanie, lub ponowne opracowanie. Przechodząc do następnej fazy przechodzimy w obszar większego ryzyka, w którym zmiana (np. wymagań) jest dużo trudniejsza i znacząca.
Faza konstrukcji (Construction phase)[edytuj]
W fazie tej główny nacisk położony jest na budowę komponentów i innych funkcjonalności opracowywanego systemu. W tej fazie odbywa się większość prac programistycznych. W większych projektach może być wiele iteracji konstrukcji, w celu podzielenia dziedziny przypadków użycia na mniejsze, zarządzalne poddziedziny. Pozwala to także na szybsze przekazywanie części prac (lub prototypów).
W tej fazie tworzona jest pierwsza wersja oprogramowania do wglądu użytkowników zewnętrznych. Zakończenie fazy wiąże się z osiągnięciem Initial Operational Capability Milestone.
Faza przekazania systemu (Transition phase)[edytuj]
W tej fazie produkt przekazywany jest od zespołu programistycznego do użytkowników końcowych (potocznie mówiąc: do produkcji). W tej fazie znajdują się takie czynności jak: trening użytkowników końcowych i administratorów, testy akceptacyjne (testy beta). Sprawdzana jest zgodność produktu z miarami jakości określonymi w pierwszej fazie.
Spełnienie celów jest tożsame z osiągnięciem Product Release Milestone i zakończeniem cyklu wytwarzania oprogramowania.
Dyscypliny (Disciplines and workflows)[edytuj]
RUP bazuje na zbiorze klocków (building blocks, content elements). Opisują one, co ma zostać stworzone, jakie umiejętności są do tego wymagane oraz, krok po kroku, jak powinien wyglądać proces wytwarzania.
Główne klocki:
Rola (Roles) – Kto? – Rola definiuje zbiór wymaganych umiejętności, kompetencji i odpowiedzialności.
Produkt (Work Products) – Co? – Produkt reprezentuje wynik zadania oraz wszystkie dokumenty i modele utworzone w czasie procesu.
Zadanie (Tasks) – Jak? – Zadanie opisuje jednostkę pracy przypisaną do roli.
W ramach każdej iteracji zadania podzielone są na dziewięć dyscyplin (disciplines):
Dyscypliny inżynierskie (Engineering Disciplines):
Modelowanie biznesowe (Business modeling)
Wymagania (Requirements)
Analiza i projekt (Analysis and design)
Implementacja (Implementation)
Testowanie (Test)
Wdrożenie (Deployment)
Dyscypliny pomocnicze (Supporting Disciplines):
Zarządzanie zmianami oraz konfiguracją (Configuration and change management)
Zarządzanie projektem (Project management)
Środowisko (Environment)
Modelowanie biznesowe (dyscyplina)[edytuj]
Z biegiem czasu przedsiębiorstwa i inne organizacje stają się coraz bardziej zależne od systemów informatycznych. Wymusza to w sposób oczywisty na inżynierach tworzących oprogramowanie wiedzę, w jaki sposób ich systemy wpasowują się w procesy zachodzące w administracji i jakie jej wymogi adresują. Z kolei firmy inwestują na ogół w systemy informatyczne na podstawie racjonalnych przesłanek – wtedy, kiedy widzą wartość dodaną wynikającą ze stworzenia takiego systemu.
Celem modelowania biznesowego jest przede wszystkim zapewnienie komunikacji i lepsze zrozumienie pomiędzy biznesem (inżynieria biznesowa) a IT (inżynieria oprogramowania). Zrozumienie biznesu oznacza, że inżynierowie oprogramowania muszą zrozumieć strukturę i dynamikę organizacji swojego klienta, jego bieżące problemy i możliwe usprawnienia. Muszą także zapewnić wspólne zrozumienie celów pomiędzy klientami, użytkownikami końcowymi a programistami.
Modelowanie biznesowe tłumaczy w jaki sposób opisać wizję organizacji, w której będzie wdrożony system i jak później użyć jej do opisania procesów, ról i odpowiedzialności w organizacji.
Wymagania (dyscyplina)[edytuj]
Celem Wymagań jest opisanie tego, co system powinien robić. Wymagania zbierane są przez analityków, którzy odkrywają je, klasyfikują i dokumentują. Proces zbierania wymagań polega na dyskusji i uzgodnieniach pomiędzy tworzącymi system a klientem.
Analiza i projekt (dyscyplina)[edytuj]
Celem Analizy i projektu jest zobrazowanie sposobu w jaki będzie tworzony system w fazie implementacji. Ma to być system, który:
Zapewnia w specyficznym środowisku realizację zadań i funkcji opisanych w przypadkach użycia.
Spełnia wszystkie swoje wymagania.
Jest łatwy do zmiany, gdy zmienią się wymagania funkcjonalne.
Analiza i projekt tworzy model projektowy i opcjonalnie model analityczny systemu. Model analityczny zapewnia abstrakcję od kodu źródłowego – to znaczy, służy on jako wytyczne do stworzenia tego kodu. Model projektowy składa się z klas zorganizowanych w pakiety i podsystemy z dobrze określonymi interfejsami. Służy to wyodrębnieniu komponentów w fazie implementacji. Zawiera także opis, które obiekty klas współpracują w celu realizacji przypadków użycia.
Implementacja (dyscyplina)[edytuj]
Celami implementacji są:
Zdefiniowanie organizacji kodu systemu, w sensie podsystemów zorganizowanych w warstwy.
Stworzenie klas i obiektów w sensie komponentów (pliki źródłowe, binaria, pliki wykonywalne i inne)
Testowanie tworzonych komponentów jako jednostki (testami jednostkowymi).
Integracja wyników tworzonych przez poszczególne osoby lub zespoły do pełnego systemu.
Systemy realizowane są poprzez implementację swoich komponentów. Proces opisuje w jaki sposób zapewnić reużywalność istniejących komponentów albo implementować nowe komponenty ze zdefiniowaną odpowiedzialnością tworząc system łatwiejszy do utrzymania i zwiększając reużywalność.
Testowanie (dyscyplina)[edytuj]
Celami dyscypliny testowania są:
Weryfikacja interakcji pomiędzy obiektami.
Weryfikacja poprawnej integracji komponentów.
Sprawdzenie, czy wszystkie wymagania zostały zaimplementowane w sposób poprawny.
Identyfikacja i sprawdzenie, że defekty zostały usunięte przed wdrożeniem oprogramowania.
Proces RUP proponuje podejście iteracyjne, które oznacza testowanie od początkowych faz projektu. Pozwala to na szybsze wykrywanie defektów i ograniczenie kosztów ich usunięcia. Testy są prowadzone w ramach wymiarów jakości: wiarygodności, funkcjonalności, osiągów pojedynczych aplikacji oraz systemu (performance). RUP opisuje w jaki sposób testować w każdym z tych wymiarów w czasie trwania projektu.
Wdrożenie (dyscyplina)[edytuj]
Celem wdrożenia (deployment) jest udane wytwarzanie dystrybucji produktu i dostarczanie oprogramowania końcowym użytkownikom. Pokrywa ono szeroki zbiór czynności włączając:
Produkcja zewnętrznych dystrybucji oprogramowania
Pakowanie oprogramowania
Dystrybucja oprogramowania
Instalacja oprogramowania
Zapewnienie pomocy i wsparcia użytkownikom
Jakkolwiek czynności wdrożenia są skoncentrowane głównie na fazie przekazania (transition), wiele z nich musi być włączone we wcześniejsze fazy w celu przygotowania do wdrożenia na końcu fazy budowy(construction). Procesy (workflows) Deployment and Environment w procesie RUP zawierają mniej szczegółów niż inne procesy.
Zarządzanie zmianą i konfiguracją (dyscyplina)[edytuj]
Dyscyplina zarządzania zmianą (change management) w RUP dotyka trzech obszarów:
Zarządzania konfiguracją (configuration management) – jest odpowiedzialne za systematyczne strukturalizowanie produktów. Artefakty takie jak dokumenty i modele muszą być wersjonowane (version control) a zmiany muszą być widoczne. W skład zarządzania konfiguracją wchodzi także utrzymywanie rejestru zależności pomiędzy artefaktami, tak, aby wszystkie powiązane części były uaktualniane wraz ze zmianami.
Zarządzanie zleceniami zmian(Change request management) – w czasie opracowywania oprogramowania istnieje wiele artefaktów z różnymi wersjami. Zarządzanie polega na trzymaniu rejestru propozycji lub zleceń zmian.
Zarządzanie stanem i miarami (Status and measurement management) – zlecenia zmian (change requests) mają stany takie jak nowy, zalogowany, zatwierdzony, przypisany i zakończony. Zlecenia zmian mają także atrybuty takie jak przyczyna (root cause) oraz natura (jak defekt lub rozszerzenie), priorytet itp. Te stany i atrybuty powinny być przechowywane w bazie danych, tak aby umożliwić tworzenie użytecznych raportów na temat postępów prac. Firma Rational posiada produkt, który umożliwia utrzymywanie takiego rejestru ClearQuest. Czynność ta wiąże się z procedurami, które trzeba wykonywać.
Zarządzanie projektem (dyscyplina)[edytuj]
Planowanie projektu w RUP występuje na dwóch poziomach – zgrubnym (coarse-grained) zwanym planem faz, który opisuje cały projekt oraz serii szczegółowych planów iteracji, które opisują iteracje.
Ta dyscyplina skupia się głównie na ważnych aspektach iteracyjnego procesu wytwarzania oprogramowania. Nie próbuje objąć natomiast wszystkich aspektów zarządzania projektami, na przykład:
Zarządzania zespołem: zatrudniania, szkoleń, opieki (coaching)
Zarządzania budżetem: definiowania, alokowania itp.
Zarządzania umowami ze sprzedawcami i klientami
Główne obszary dyscypliny:
Zarządzanie ryzykiem
Planowanie projektu iteracyjnego, w ramach całego cyklu i pojedynczych iteracji
Monitorowanie postępu projektu iteracyjnego, miary
Dyscyplina zarządzania projektem zawiera również inne Plany i Artefakty, które są używane do kontrolowania projektu i monitorowania jego postępu. Do planów należą:
Plan faz (The Software Development Plan)
Plan iteracji
Plan faz[edytuj]
Każda faza traktowana jest jako projekt, kontrolowany i mierzony poprzez Software Development Plan pogrupowany w podzbiór planów kontrolnych:
Plan miar (Measurement Plan) – definiuje cele pomiarów, skojarzone miary, i proste miary, które będą gromadzone w projekcie w celu monitorowania jego postępu.
Plan zarządzania ryzykiem (Risk Management Plan) – uszczegóławia w jaki sposób zarządzać ryzykami związanymi z projektem. Wymaga uszczegółowienia zadań zarządzania ryzykami, które będą wykonywane, przypisania do nich odpowiedzialności oraz dodatkowych wymaganych zasobów. W projektach mniejszej skali plan może być powiązany z Software Development Plan.
Lista ryzyk (Risk list) – posortowana lista znanych i otwartych ryzyk posortowanych według ważności i skojarzonych z akcjami minimalizacji oraz planami awaryjnymi (mitigation and contingency actions).
Test jednostkowy (ang. unit test) to w programowaniu metoda testowania tworzonego oprogramowania poprzez wykonywanie testów weryfikujących poprawność działania pojedynczych elementów (jednostek) programu - np. metod lub obiektów w programowaniu obiektowym lub procedur w programowaniu proceduralnym. Testowany fragment programu poddawany jest testowi, który wykonuje go i porównuje wynik (np. zwrócone wartości, stan obiektu, wyrzucone wyjątki) z oczekiwanymi wynikami - tak pozytywnymi, jak i negatywnymi (niepowodzenie działania kodu w określonych sytuacjach również może podlegać testowaniu).
Zaletą testów jednostkowych jest możliwość wykonywania na bieżąco w pełni zautomatyzowanych testów na modyfikowanych elementach programu, co umożliwia często wychwycenie błędu natychmiast po jego pojawieniu się i szybką jego lokalizację zanim dojdzie do wprowadzenia błędnego fragmentu do programu. Testy jednostkowe są również formą specyfikacji. Z powyższych powodów są szczególnie popularne w programowaniu ekstremalnym.
Kryzys oprogramowania
Inżynieria oprogramowania jest dziedziną informatyki, która pojawiła się w połowie lat 60-tych. Rozwój inżynierii oprogramowania poprzedziło zwrócenie uwagi na tzw. kryzys oprogramowania. W latach 50 i na początku lat 60-tych tworzono tylko małe programy. Rozwój sprzętu komputerowego oraz języków programowania umożliwił tworzenie znacznie bardziej złożonych systemów. Stało się jasne, że rozwój technik oprogramowania nie nadąża za rozwojem sprzętu i to zjawisko nazwano "kryzysem oprogramowania", który trwa do dziś. W latach 90-tych 90% poważnych firm programistycznych w USA uważa, że często zdarzają się im opóźnienia w realizacji przedsięwzieć programistycznych. Oprogramowanie jest też chyba jedynym produktem technicznym, w którym błędy są powszechnie akceptowane. Przykładem może być wykrycie błędu w pierwszych egzemplarzach PENTIUM. Producenci programów sprzedawanych w milionach egzemplarzy nie dają praktycznie żadnej gwarancji na to, że ich produkt działa zgodnie z opisem.
Przyczyny kryzysu oprogramowania:
Duża złożoność systemów informatycznych.
Niepowtarzalność poszczególnych przedsięwzięć.
Nieprzejrzystość procesu budowy oprogramowania, tj. fakt trudności w ocenie stopnia zaawansowania prac. Najgorszym sposobem oceny postępów jest pytanie się programistów o ocenę stopnia zaawansowania. Jeżeli po miesiącu uzyskamy odpowiedź, że prace są zaawansowane w 90%, można się spodziewać, że przedsięwzięcie potrwa jeszcze cały rok.
Pozorna łatwość wytwarzania i dokonywania poprawek w oprogramowaniu, Narzędzia pozwalające tworzyc nawet całkiem duże programy są stosunkowo tanie. Każdy, kto korzystając z nich napisał w ciągu jednego dnia program liczący 100 linii, może sądzić, że w ciągu 10 dni napisze program zawierający 1000 linii, a 10 osób w ciągu 100 dni opracuje program liczący 100000 linii, co nie jest słuszne.
Efektywne tworzenie formularzy:
Oznaczaj pola obowiązkowe
Podawaj przykłady formatu informacji jakiego oczekujesz, lub przyjmuj każdy używany format
Wyraźnie podawaj ograniczenia liczby znaków
Jeśli to nie jest niekonieczne, nie twórz ograniczeń liczby znaków
Nie pokazuj opcji, których klient nie może wybrać
Wprowadzone dane sprawdzaj jak najszybciej
Bezwzględnie zrezygnuj z przycisku Wyczyść
Na czym polega analiza i projektowanie:
Analiza to badanie problemu i wymagań, a nie szukanie rozwiązania. Jeśli np. klient życzy sobie systemu sprzedaży internetowej, należy poszukać odpowiedzi na pytanie w jaki sposób będzie z niego korzystał i jakie funkcje ma spełniać system.
Celem projektowania jest przetłumaczenie wymagań na specyfikację, opisującą jak zaimplementować system. Projektowanie jest związane z szukaniem pomysłu na rozwiązania, które spełnią wymagania, ale nie łączy się bezpośrednio z implementacją.
Diagram klas – w ujednoliconym języku modelowania (UML, ang. Unified Modeling Language), to statyczny diagram strukturalny, przedstawiający strukturę systemu w modelachobiektowych przez ilustrację struktury klas i zależności między nimi.
Diagram klas przedstawia klasy (typy) obiektów w programie, w odróżnieniu od diagramu obiektów, który pokazuje jedynie egzemplarze (instancje) obiektów i ich zależności istniejące w konkretnym momencie.
Diagram klas pokazuje określony fragment struktury systemu. Diagramów klas używa się do modelowania statycznych aspektów perspektywy projektowej. Wiąże się z tym silnie modelowanie słownictwa systemu, kooperacji lub schematów. Diagramy klas pozwalają na sformalizowanie specyfikacji danych i metod. Mogą także pełnić rolę graficznego środka pokazującego szczegóły implementacji klas.
Zależności klas
Zależność – związek znaczeniowy między klasami, gdy jedna z nich używa innych klas.
Kompozycja
Kompozycja, zwana również złożeniem, jest związkiem typu całość-część. W relacji kompozycji, części należą tylko do jednej całości, a ich okres życia jest wspólny — razem z całością niszczone są również części. Na diagramie, kompozycję oznacza się za pomocą linii zakończonej wypełnionym rombem.
Agregacja
Agregacja również reprezentuje związek typu całość-część. Jednak, w odróżnieniu od kompozycji, występuje tutaj relacja posiadania — co oznacza, że elementy częściowe mogą należeć do większej całości, jednak również mogą istnieć bez niej. Na diagramie, agregację oznacza się za pomocą linii zakończonej pustym rombem.
Generalizacja
Generalizacja – związek opisujący dziedziczenie po klasach.
Asocjacje
czyli powiązania pomiędzy obiektami klas
Diagramy aktywności(czynności) – przedstawiają kolejne oraz równoległe czynności składające się na proces.
Diagram aktywności oferuje bogatą notację, pozwalającą na przedstawienie sekwencji czynności, również czynności równoległych; technika ta sprawdza się w przypadku złożonych procesów; może być stosowany w dowolnej perspektywie i dowolnym celu; diagram często stosowany jest do modelowania: procesów biznesowych, scenariuszy przypadków użycia, przetwarzania współbieżnego, algorytmów.
Notacje:
Aktywność, czynność lub akcja; przepływ sterowania: oznacza zakończenie jednej aktywności/akcji i przejście do drugiej; blok decyzyjny: może rozdzielać jedno przejście na kilka alternatywnych lub łączyć kilka alternatywnych przejść w jedno przejście; sztabka synchronizująca: może być typu rozwidlenia lub typu scalenie; aktywność początkowa; aktywność końcowa; zakończenie przepływu
Diagramy pakietów to graficzne przedstawienie struktury systemu w postaci pakietów połączonych zależnościami i zagnieżdżeniami.
Diagramy pakietów wykorzystywane są do porządkowania, grupowania różnorodnych klasyfikatorów języka UML, takich jak: przypadków użycia, kompletnych diagramów, klas, podsystemów.
Notacja: pakiet; zależność; zagnieżdżenie pakietów
Diagramy sekwencji to graficzne przedstawienie interakcji pomiędzy obiektami systemu.
Diagram sekwencji łączy w sobie aktorów, obiekty i komunikaty. Jest więc zgodny z koncepcją obiektowego modelowania systemów. Umożliwia bezpośrednie przejście do generowania kodu w językach obiektowych.
Notacja: Klasyfikator to dokładniej: aktor, klasa, pakiet. Może wysyłać i odbierać komunikaty; linia życia to czas życia instancji; komunikat to specyficzna wymiana informacji zawiera zlecenie wykonania określonej operacji; ośrodek sterowania to stan aktywności danej instancji.
Wzorzec projektowy (ang. design pattern) – w inżynierii oprogramowania, uniwersalne, sprawdzone w praktyce rozwiązanie często pojawiających się, powtarzalnych problemów projektowych. Pokazuje powiązania i zależności pomiędzy klasami oraz obiektami i ułatwia tworzenie, modyfikację oraz pielęgnację kodu źródłowego. Jest opisem rozwiązania, a nie jego implementacją. Wzorce projektowe stosowane są w projektach wykorzystujących programowanie obiektowe.
Elementy wzorca[edytuj]
Wzorzec projektowy składa się z czterech podstawowych elementów:
nazwy wzorca;
problemu – opisuje sposoby rozpoznawania sytuacji, w których możemy zastosować dany wzorzec oraz warunki jakie muszą zostać spełnione, by jego zastosowanie miało sens;
rozwiązania – opisuje elementy rozwiązania: ich relacje, powiązania oraz obowiązki, zawiera także wskazówki implementacyjne dla różnych technologii;
konsekwencji – zestawienie wad i zalet stosowania wzorca, uwzględniające informacje o jego brakach oraz kosztach rozwoju i utrzymania systemu wykorzystującego dany wzorzec.
Zalety zastosowania wzorców: zapobiegają ponownemu wymyślaniu kodu zaprojektowanego już przez innych programistów; zmniejszają liczbę popełnionych błędów; zapewniają kod łatwo rozszerzalny; ułatwiają zrozumienie kodu; ułatwiają komunikacje zespole.
Podział wzorców:
konstrukcyjne: wykorzystuje się je do pozyskania obiektów zamiast bezpośredniego tworzenia instancji klasy; programy zyskują na elastyczności, gdyż można decydować, jaki typ obiektu ma zostać utworzony w danym przypadku
strukturalne: pomagają łączyć obiekty w większe struktury
behawioralne: charakteryzują sposób, w jaki klasy lub obiekty oddziałują i dzielą odpowiedzialności; pomagają definiować przepływ danych w złożonym programie
Wzorzec Strategia definiuje rodzinę algorytmów, pakuje je jako osobne klasy i powoduje, że są one w pełni wymienne. Zastosowanie tego wzorca pozwala na to, aby zmiany w implementacji algorytmów przetwarzania były całkowicie niezależne od strony klienta, który z nich korzysta.
Wzorzec Singleton zapewnia, że dana klasa będzie miała tylko i wyłącznie jedną instancje obiektu i zapewnia globalny punkt dostępu do tej instancji.
Wzorzec Dekorator pozwala na dynamiczne przydzielanie danemu obiektowi nowych zachowań. Dekoratory dają elastyczność podobną do tej, jaką daje dziedziczenie, oferując jednak w zamian znacznie rozszerzoną funkcjonalność.
Wzorzec Polecenie hermetyzuje żądania w postaci obiektów, co umożliwia parametryzowanie różnych obiektów zróżnicowanymi żądaniami oraz obsługiwanie operacji, które można wycofać
Refaktoryzacja (czasem też refaktoring, ang. refactoring) to pojęcie związane z wytwarzaniem systemów informatycznych, w szczególności z programowaniem. Jest to proces wprowadzania zmian w projekcie/programie, w wyniku którego zasadniczo nie zmienia się funkcjonalność. Celem refaktoryzacji jest więc nie wytwarzanie nowej funkcjonalności, ale utrzymywanie odpowiedniej, wysokiej jakości organizacji systemu. W ramach refaktoryzacji podejmowane są następujące działania:
modyfikowanie elementów systemu w celu wpasowania ich w przyjęte standardy i wzorce
poszukiwanie nowych standardów i wzorców, które pojawiły się w systemie w trakcie jego rozwoju i ich precyzyjne definiowanie (łącznie z wpasowywaniem istniejących elementów w te definicje).
Dzięki refaktoryzacji w systemie ogranicza się redundancję (nadmiarowość, np. istnienie wielu obiektów i procedur o takiej samej lub bardzo zbliżonej funkcjonalności, a mających niezależne implementacje, czyli stosując regułę DRY) i wprowadza standardy. W przypadku systemów o architekturach wielowarstwowych, refaktoryzacja jest jednym z istotnych czynników gwarantujących zachowanie silnej separacji warstw systemu i ich przejrzystej struktury.
Testowanie oprogramowania – proces związany z wytwarzaniem oprogramowania. Jest to jeden z procesów zapewnienia jakości oprogramowania. Testowanie ma na celuweryfikację oprogramowania oraz walidację oprogramowania. Weryfikacja oprogramowania ma na celu sprawdzenie, czy wytwarzane oprogramowanie jest zgodne ze specyfikacją. Walidacja sprawdza, czy oprogramowanie jest zgodne z oczekiwaniami użytkownika.
Rodzaje testów:
jednostkowe: wykonuje programista w środowisku laboratoryjnym. Celem tych testów jest sprawdzenie pojedynczej jednostki oprogramowania jaką jest klasa, metoda, czy też zbiór współpracujących ze sobą klas
integracyjne: przetestowane jednostki kodu są następnie łączone w większą całość. Podczas integracji przeprowadzane są testy integracyjne. ich zadaniem jest sprawdzenie łącznych fragmentów kodu. Weryfikowana jest współpraca integrowanych jednostek między sobą. Celem jest określenie czy po zintegrowaniu otrzymany podsystem nadaje się do dalszego testowania i przekazania klientowi. Proces łączenia i testowania jest powtarzany aż do powstania całego systemu.
Systemowe: wykonywane są po pomyślnej integracji jednostek wchodzących w skład systemu będącego przedmiotem testowania. Wykonywane są przez programistów lub niezależny zespół w kontrolowanym środowisku laboratoryjnym. Sprawdzają one czy system jako całość spełnia wymagania funkcjonalne i jakościowe postawione przez klienta.
akceptacyjne
Model spiralny (tworzenie spiralne) – jeden z modeli procesów tworzenia oprogramowania.
Proces tworzenia ma postać spirali, której każda pętla reprezentuje jedną fazę procesu. Najbardziej wewnętrzna pętla przedstawia początkowe etapy projektowania, np. studium wykonalności, kolejna definicji wymagań systemowych, itd.
Każda pętla spirali podzielona jest na cztery sektory:
Ustalanie celów - Definiowanie konkretnych celów wymaganych w tej fazie przedsięwzięcia. Identyfikacja ograniczeń i zagrożeń. Ustalanie planów realizacji.
Rozpoznanie i redukcja zagrożeń - Przeprowadzenie szczegółowej analizy rozpoznanych zagrożeń, ich źródeł i sposobów zapobiegania. Podejmuje się odpowiednie kroki zapobiegawcze.
Tworzenie i zatwierdzanie - Tworzenia oprogramowania w oparciu o najbardziej odpowiedni model, wybrany na podstawie oceny zagrożeń.
Ocena i planowanie - Recenzja postępu prac i planowanie kolejnej fazy przedsięwzięcia bądź zakończenie projektu.
Widoczną cechą modelu spiralnego jest szczegółowe potraktowanie zagrożeń realizacji projektu. Dobrze rozpoznane zagrożenia i przedsięwzięte kroki im zapobiegania lub redukcji skutkują m.in. wysoką niezawodnością (dependability) powstającego oprogramowania, bądź pewnością, że projekt ma szanse dalszej realizacji.
W modelu spiralnym nie ma takich faz jak specyfikowanie albo projektowanie. Jeden cykl spirali może przebiegać w oparciu o model kaskadowy procesu tworzenia oprogramowania, w innym można użyć prototypowania lub przekształceń formalnych, w zależności od aktualnego etapu przedsięwzięcia / realizowanej części systemu (np. inny dla tworzenia interfejsu użytkownika, inny dla krytycznych funkcji bezpieczeństwa)
Każdy cykl wymaga formalnej decyzji o kontynuacji projektu.
Model przyrostowy (realizacja przyrostowa, ang. incremental development) – jedna z technik pisania oprogramowania, stosowany w przypadkach, w których dopuszczalna jest okrojona funkcjonalność systemu.
Fazy[edytuj]
określenie całości wymagań (w ramach naszych możliwości, na tyle na ile uda nam się ją sprecyzować), wykonanie wstępnego, ogólnego projektu całości systemu
wybór pewnego podzbioru funkcji systemu
szczegółowy projekt (wg modelu kaskadowego) oraz implementacja części systemu realizującej wybrane funkcje
testowanie zrealizowanego fragmentu i dostarczenie go klientowi
powtarzanie kolejnych etapów, aż do zakończenia implementacji całego systemu
Model kaskadowy (ang. waterfall model) – jeden z kilku rodzajów procesów tworzenia oprogramowania zdefiniowany winżynierii oprogramowania. Jego nazwa wprowadzona została przez Winstona W. Royce w roku 1970, w artykule "Managing the Development of Large Software Systems" (zarządzanie tworzeniem dużych systemów informatycznych).
Polega on na wykonywaniu podstawowych czynności jako odrębnych faz projektowych, w porządku jeden po drugim. Każda czynność to kolejny schodek (kaskada):
Planowanie systemu (w tym Specyfikacja wymagań)
Analiza systemu (w tym Analiza wymagań i studium wykonalności)
Projekt systemu (poszczególnych struktur itp.)
Implementacja (wytworzenie kodu)
Testowanie (poszczególnych elementów systemu oraz elementów połączonych w całość)
Wdrożenie i pielęgnacja powstałego systemu.
Jeśli któraś z faz zwróci niesatysfakcjonujący produkt cofamy się wykonując kolejne iteracje aż do momentu kiedy otrzymamy satysfakcjonujący produkt na końcu schodków.
Model kaskadowy jest rzadko używany z następujących powodów:
Nie można przejść do następnej fazy przed zakończeniem poprzedniej
Model ten posiada bardzo nieelastyczny podział na kolejne fazy
Iteracje są bardzo kosztowne - powtarzamy wiele czynności
Tego typu modelu należy używać wyłącznie w przypadku gdy wymagania są zrozumiałe i przejrzyste, ponieważ każda iteracja jest czasochłonna i wymaga dużych wydatków na ulepszanie.
Model prototypowy tworzenia oprogramowania polega na stworzeniu podczas projektowania prototypu w celu przedyskutowania oraz akceptacji z klientem. Po akceptacji prototypu przechodzi się do kolejnych etapów tworzenia oprogramowania. Prototypowanie zapobiega błędnym zrozumieniem wymagań systemu, które może powodować wzrost kosztów, zwłaszcza w modelu kaskadowym.
Metoda szacowani kosztów COCOMO
jest oparte na kilku formułach pozwalających oszacować całkowity koszt przedsięwzięcia na podstawie oszacowanej liczby linii kodu. Jest to główna słabość tej metody, gdyż:
liczba ta staje się przewidywalna dopiero wtedy, gdy kończy się faza projektowania architektury systemu; jest to za późno;
pojęcie “linii kodu” zależy od języka programowania i przyjętych konwencji;
pojęcie “linii kodu” nie ma zastosowania do nowoczesnych technik programistycznych, np. programowania wizyjnego.
COCOMO oferuje kilka metod określanych jako podstawowa, pośrednia i detaliczna.
Metoda podstawowa: prosta formuła dla oceny osobo-miesięcy oraz czasu potrzebnego na całość projektu.
Metoda pośrednia: modyfikuje wyniki osiągnięte przez metodę podstawową poprzez odpowiednie czynniki, które zależą od aspektów złożoności.
Metoda detaliczna: bardziej skomplikowana, ale jak się okazało, nie dostarcza lepszych wyników niż metoda pośrednia.