Opracowanie na Inżynierie Oprogramowania
czyli dodaj coś od siebie

na czerwono - do opracowania
na pomarańczowo - w trakcie
szare tło - Polecenia

Proszę o podawanie źródeł.
Nie wal w Janka dopisz się.


1. Procesy wytwórcze informatyczne (fazy, przepływy prac, jak wygląda) (wiki)

Proces wytwórczy oprogramowania (ang. software process) – proces mający na celu wytworzenie oprogramowania.
a. Proszę nazwać procesy wytwórcze, które znamy    

• Rational Unified Process (ang. Rational Unified Process) – proces wytwarzania oprogramowania opracowany przez firmę Rational Software (która jest również twórcą języka UML), proces dostosowany jest do prowadzenia większych projektów

• Open Unified Process, metodyka wytwarzania oparta na metodyce RUP. Szablon do tworzenia procesu zaimplementowany jest w produkcje Eclipse Process Framework rozwijanym przez Eclipse Foundation.

• OpenUP/basic, metodyka Open Unified Process przystosowana do małych projektów. Zawiera zarówno elementy RUP, jak również elementy z metodyk zwinnych Agile.

 Metodyki nurtu zwinnego

• XP (ang. Extreme Programming) – proces lżejszy od metodyki RUP, obarczony jednak większym ryzykiem – jest znacznie mniej sformalizowany (i przez to lubiany przez programistów)

• Scrum - jest bardziej sformalizowany od XP, ale wciąż przyjemny i przyjazny dla programistów. Oprogramowanie jest tworzone w wyszczególnionych odstępach czasowych, tzw. sprintach, timebox'ach, w czasie których drużyna ma za zadanie wykonać z góry określone wymogami zadania. Nad drużyną czuwa Scrum Master, który jest raczej pomocnikiem niż liderem zespołu.

b. Proszę scharakteryzować jeden z wybranych procesów (tych wyżej)

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.

Rational Unified Process (RUP) to także nazwa oprogramowania, opracowanego przez Rational Software (obecnie dostępnego w IBM). Produkt ten zawiera hipertekstową bazę wiedzy z przykładowymi artefaktami oraz szczegółowymi opisami wielu typów czynności. Process RUP definiowany jest także w produkcie Rational Method Composer (RMC), który pozwala na tworzenie spersonalizowanych wersji RUP

Budowa

Autorzy procesu skupili się na diagnozowaniu charakterystyk projektów, które zakończyły się fiaskiem. Postępując w ten sposób próbowali poznać przyczyny owych niepowodzeń. Przyglądali się również ówcześnie istniejącym procesom inżynierii oprogramowania i sposobom, w jaki rozwiązywały one problemy.

Lista najczęstszych błędów zawierała następujące rzeczy:

• Zarządzanie wymaganiami Ad hoc (najczęściej brak zarządzania nimi)

• Niejednoznaczna, nieprecyzyjna komunikacja

• Architektura oprogramowania nieodporna na obciążenia (ang. Brittle architecture)

• Zbytnia, niepotrzebna złożoność oprogramowania

• Niewykryte niespójności w wymaganiach, projekcie, oraz implementacji

• Brak, lub niewystarczające testowanie

• Subiektywna ocena postępu projektu

• Brak zarządzania ryzykiem

• Brak automatyzacji prowadzenia projektu

Niepowodzenie projektu było spowodowane kombinacją wielu czynników, w każdym projekcie w specyficzny sposób. Rezultatem badań firmy Rational było opracowanie zbioru dobrych praktyk, które nazwane zostały właśnie Rational Unified Process.

Proces RUP został opracowany z użyciem tych samych technik, których zespół Rational używał do modelowania systemów - języka UML. Język UML powstawał równolegle z RUP (również jako połączenie doświadczenia w modelowaniu firm Objectory i Rational).

RUP bazuje na zbiorze zasad inżynierii programowania oraz najlepszych praktykach, na przykład:

1. Iteracyjnym wytwarzaniu oprogramowania (Iterative Development)

2. Zarządzaniu wymaganiami (Requirement Management)

3. Używaniu architektury bazującej na komponentach (Component-based architecture)

4. Graficznym projektowaniu oprogramowania

5. Kontroli jakości oprogramowania (Quality Assurance)

6. Procesu kontroli zmian w oprogramowaniu (Change Management)

Zarządzanie wymaganiami

Zarządzanie wymaganiami w RUP jest skupione na zaspokojeniu oczekiwań użytkowników końcowych systemu poprzez identyfikację i specyfikację ich potrzeb oraz wykrywanie zmiany tych wymagań. Zalety zarządzania wymaganiami:

• Poprawnie zidentyfikowane wymagania tworzą prawidłowy produkt, potrzeby użytkownika są zaspokojone.

• Tworzymy istotną dla użytkowników funkcjonalność, redukując późniejsze koszty dobudowywania zapomnianej (niezidentyfikowanej podczas tworzenia) funkcjonalności.

RUP sugeruje, że zarządzanie wymaganiami składa się z następujących czynności:

Analiza problemu - uzgodnienie problemu i stworzenie miar, które dowiodą jego istotności dla klienta.

Zrozumienie potrzeb udziałowców (stakeholders) (brak odpowiedniego słowa w języku polskim, są to odbiorcy i użytkownicy oprogramowania na różnych szczeblach w organizacji, w innych metodykach zarządzania projektami nazywa się ich Interesariuszami) - konsultacja problemu i jego wartości z głównymi udziałowcami (stakeholders) i rozpoznanie w jaki sposób koncepcja rozwiązania zaspokaja ich potrzeby.

Definicja systemu - tworzenie projektu funkcjonalności na podstawie potrzeb użytkowników, identyfikacja przypadków użycia - które prezentują ogólne wymagania (high-level requirements) i użyteczność modelu systemu.

Zarządzanie zakresem systemu (Scope Management) - modyfikowanie zakresu prac nad systemem bazując na analizie wymagań, wybór kolejności realizacji (atakowania) przypadków użycia.

Zawężanie definicji systemu - uszczegóławianie scenariuszy przypadków użycia razem z użytkownikami systemu w celu stworzenia dokładnej Specyfikacji wymagań (ang. Software Requirements Specification - SRS), która może służyć (i na ogół służy) jako umowa pomiędzy wykonawcą systemu a klientem. Na podstawie dokumentu SRS tworzony jest projekt systemu oraz scenariusze testów.

Zarządzanie zmianami wymagań - zarządzanie zmianami wymagań lub nowozidentyfikowanymi wymaganiami w czasie trwania projektu.

c. Proszę wytłumaczyć różnicę między poszczególnymi procesami wytwórczymi
d. Po co potrzebny proces wytwórczy i gdzie go możemy zobaczyć w dokumentacji

2. Zarządzanie ryzykiem (http://wazniak.mimuw.edu.pl/index.php?title=Zio-10-wyk-toc)

a. Proszę odpowiedzieć ogólny algorytm zarządzania ryzykiem (z jakich kroków, jak wypełnić tabelkę)

Etapy:
    Ocena

Identyfikacja, - wykazanie czynników mogących zagrozić przedsięwzięciu

• Listy kontrolne

• Analiza czynników decyzyjnych

• Analiza założeń

• Dekompozycja

    Kontrola

Planowanie,

• Zakup informacji - np. dokumentacji

• Unikanie ryzyka - np. wybór alternatywnej technologii

• Przeniesienie ryzyka - np. ubezpieczenie

• Minimalizacja ryzyka - np. dodatkowa analiza

• Planowanie elementów ryzyka

• Integracja z planem ryzyka

Analiza ryzyka

• Modele kosztowe

• Modele wydajnościowe - wpływ czynników ryzyka na postępy

• Analizy sieciowe - umożliwiające identyfikację ograniczeń kolejnościowych dla zadań  projektowych wynikające z wpływu ryzyka na sukces końcowego efektu

• Analizy decyzyjne - prawdopodobieństwo osiągnięcia rezultatu podejmując różne decyzje

• Analizy czynników jakościowych

• Analizy wagi (podatności na)

• Analizy wzmocnienia ryzyka

Zarządzanie Reakcją na Ryzyko,

• Prototypy - demonstrują wybrane lub uproszczone elementy

• Symulacje

• Rankingi

• Analizy

• Rekrutacje/Personel

Monitorowanie i Kontrola

• Śledzenie kamieni milowych - okresowe przeglądy czynników ryzyka

• Ranking Top 10 - koncentracja na najważniejszych czynnikach

• Regresywna ocena ryzyka - cykliczna weryfikacja wag (podatności na)

• Działania korygujące naprawcze

3. Szacowanie nakładów pracy, kosztów przedsięwzięcia

a. Proszę nazwać metody szacowania kosztów przedsięwzięcia (jakie rodzaje)

• Algorytmiczne modelowanie kosztów - Tworzenie obliczalnej formuły, która jest oparta na danych historycznych i generalnie ocenia koszt oprogramowania na podstawie jego rozmiaru

• Ocena ekspertów

• Szacowanie przez analogię - porównanie przedsięwzięcia z podobnymi przedsięwzięciami

• Prawo Parkinsona - Przedsięwzięcie zużyje wszystkie dostępne zasoby
  Zalety: Nie przekroczymy budżetu
  Wady: Zazwyczaj nie ukończymy systemu

• Ustalanie ceny pod zwycięstwo - Cena przedsięwzięcia to tyle ile klient może wydać

• Szacowanie wstępujące - Realizację przedsięwzięcia dzieli się na mniejsze częsci, których koszt jest łatwy do obliczenia

b. Scharakteryzować czym jest COCOMO 2 (podstawowa część)

COCOMO (COst COntruction MOdel) - algorytmiczny model szacowania kosztów bazujący na rozmiarze oprogramowania. Powstał w oparciu o informacje dotyczące wielu rzeczywistych przedsięwzięć. Stosowanie modelu wymaga oszacowania liczby instrukcji, z których będzie składał się system.

Jednostką, w której mierzy się pracochłonność w metodzie COCOMO jest osobomiesiąc . Jeden osobomiesiąc oznacza miesięczny czas pracy jednej osoby nad danym projektem, przy czym:

• nie wliczono dni świątecznych i innych dni wolnych od pracy,

• wliczono natomiast weekendy.

Podstawowy wzór określający pracochłonność (PM nominal ) wyznaczono jako:

A * Size ^ E

W COCOMO uwzględniono  estymację  w  poszczególnych  etapach realizacji  projektów  zgodnie  z  modelami  spiralnym  i iteracyjnym poprzez wprowadzenie trzech faz estymacji.(poniżej)

c. Jaka jest podstawowa różnica pomiędzy 1. 2. I 3. Poziomem COCOMO 2

http://www.student-life.pl/materialy/io/Inzynieria_Oprogramowania_WSZiB_19.pdf

CostEstimation.pdf, strona 69 (wykłady Fedorova)

• 1. Poziom wczesnego prototypowania - Szacowanie  w  fazie  Application  Composition  polega  na określeniu  nakładu  pracy  (PM)  z  wykorzystaniem  metody Object Points

Korzystamy z następujacej formuły:

PM=(NOP * (1-%reuse/100))/PROD

PM - wynik w osobomiesiącach

NOP - ilość object points

PROD - produktywność

//gdyby ktoś mógł wytłumaczyć tutaj, o co konkretnie kaman, byłoby fajnie :-)

2. Poziom wczesnego projektowania - (Early Design) ma na celu umożliwienie estymacji we wczesnych fazach  realizacji  projektu,  kiedy  wstępne  wymagania  zostały już  określone  a  realizacja  projektu  jest  na  etapie  tworzenia architektury systemu. Podstawę  oszacowania  rozmiaru  produktu  stanowi  metoda punktów funkcyjnych

•  Wprowadzono  zależność  współczynnika  ekspotencjalnego  (w granicach 1.01 - 1.26) od:

• Stopnia  znajomości  danego zagadnienia/domeny/technologii

• Elastyczności procesu produkcji i wymagań

• Spójności  i  łatwości  komunikacji  członków  zespołu projektowego

• Dojrzałości  procesu  produkcji

• 3. Poziom post-architektoniczny - (Post-Architecture) - Szczegółowe szacowanie nakładów wymaganych na realizację systemu i jego późniejsze utrzymanie

 

• Rozszerza szacowanie fazy Early Design

• Wprowadzenie ekwiwalentu linii kodu dla oprogramowania wykorzystywanego w produkcji nowego systemu (ESLOC)

• Wprowadzenie  modyfikatora  odpowiedzialnego  za zarządzanie zmianami wymagań

• 17 modyfikatorów nakładu w miejsce 7 z fazy Early Design

 

• Zależność czynnika ekspotencjalnego od 5 współczynników związanych  z  produktem,  projektem  i  grupą  projektową, którym przypisywane są odpowiednie wagi

 

 

 d. Proszę podać ogólną charakterystykę metody punktów funkcyjnych

 

http://wazniak.mimuw.edu.pl/index.php?title=Zio-12-wyk-Slajd49

Metoda punktów funkcyjnych pozwala na szacowanie rozmiaru projektu na podstawie wymagań i niezależnie od technologii.

Jest to technika podziału systemów na mniejsze, łatwiejsze do zrozumienia i przeanalizowania, komponenty. W metodzie tej występuje pięć głównych klas, charakteryzujących systemy:

 

• "zewnętrzne wejścia" - dane wchodzą z zewnątrz do systemu

• "zewnętrzne wyjścia" - dane wychodzą na zewnątrz systemu

• "zewnętrzne zapytania" połączenie powyższych. Nie może modyfikować plików wewnętrznych

• "pliki wewnętrzne" - grupa danych rozmieszczona w granicach systemu

• "pliki zewnętrzne" - = || = poza granicami systemu

 

Klasy te charakteryzują funkcjonalność systemu.

 

e. Charakterystyka z innych (po jednym zdaniu)

 

 

4. Wymagania

 

a. Jak wygląda zarządzanie wymaganiami, co to jest, jakie podstawowe kroki, przepływ pracy (dyscyplina pracy)

Kroki:

 

• Doprowadzić do jednolitego rozumienia wymagań pochodzących z różnych źródeł

• Uzyskać akceptacje wymagań od wszystkich uczestników przedsięwzięcia

• Zarządzanie zmianami wymagań w trakcie przedsięwzięcia

• Utrzymywanie 2-kierunkowej możliwości śledzenia zależności między wymaganiami a planami i produktami

• Wykrywanie niespójności między wymaganiami a planami i produktami.

Przepływ pracy

komputerowe wspomaganie pracy zespołów ludzkich poprzez porządkowanie, organizowanie, automatyzowanie, przekazywanie i śledzenie prac, które one wykonują.

 

 

b. Czym jest przypadek użycia i określić podstawowe związkiPrzypadek użycia przedstawia interakcję pomiędzy aktorem (użytkownikiem systemu), który inicjuje zdarzenie oraz samym systemem jako sekwencję prostych kroków.Związki  

• uszczegółowienie - wyspecjalizowana wersja przypadku użycia  

• rozszerzenia - dodatkowa funkcjonalność przypadku użycia  

• zawierania - wykonanie jednego przypadku użycia przez drugi

c. Jak realizować przypadki użycia i jak to się robi

 

5. Proces biznesowy a. Zadania i celb. Na czym polega (z wykładu Fedorova)    Proces biznesowy jest zbiorem czynnosci wykonywanych, aby uzyskać konkretny rezultat dla klienta lub rynku. Jest uruchamiany przez konkretne zdarzenie. Wyjściem procesu jest rezultat. Każdy z procesów biznesowych musi realizowac okreslony cel, który ten proces uzasadnia.    Proces biznesowy wymaga pewnej porcji informacji oraz zasobów. Informacje wykorzystuje siew trakcie procesu biznesowego. Zasób z kolei sie konsumuje. Przykład procesu biznesowego:

 

c. Podstawowe diagramy UML w procesie biznesowym (analizy)
a)Diagram przypadków użycia
Składa się z:
-przypadków uzycia dotyczących działalności - odwołuja sie do celów działania i reguł działalnosci. Oznaczamy je jak kazdy inny przypadek uzycia dodając stereotyp <<business>>
-aktorów działalności - zarówno klienci, jak i udziałowcy i pracownicy danej firmy.
-pracowników działalnosci.

d. Wytłumaczyć jak zorganizować w projekcie przejścia z modelu biznesowego na model wymagań funkcjonalnych (na UML)

  e. Jakie są korzystne diagramyf. Diagramy dynamiczne UML, cele i korzyści płynące z wykorzystaniag. Wyjaśnić diagramy klas co to jest, podstawowe oznaczenia UML na diagramach klas i wytłumaczyć jak przekształcić diagramy klas w kod (znaleźć odpowiednik) 

 

6. Architektura systemu

 

a. Co oznacza architektura systemu i czym są wzorce architektoniczne, nazwać rodzaje wzorców architektonicznychczyli opisuje, jak funkcjonalność programu użytkowego rozproszono na kilku logicznych komponentach oraz jak te komponenty rozproszono na procesorach.Rodzaje

 

• Architektura monolityczna

• Oparta na serwerze plików

• Klient - Serwer

  • Dwuwarstwowa

    • Klient cienki

    • Klient gruby 

  • Trójwarstwowa 

b. Jak sprawdza się poprawność wybranej architektury przy projektowaniu systemów informatycznych

 

7. Wzorce projektowe  a. Czym są wzorce, dlaczego są potrzebne, wymienić rodzaje Wzorzec projektowy wywodzi się z architektury. Jest gotowym schematem postępowania, który można zastosować w wielu sytuacjach, łącząc go także z innymi wzorcami. Rodzaje http://wazniak.mimuw.edu.pl/index.php?title=Io-8-wyk-Slajd8  

• architektoniczne - poziom integracji komponentów

• projektowe - poziom integracji między klasami

• wzorce analityczne - poziom opisu rzeczywistości

• wzorce implementacyjne - poziom języka programowania

LUB (które lepsze??) Rodzaje http://wazniak.mimuw.edu.pl/index.php?title=Io-8-wyk-Slajd9  

• kreacyjne - modelujące działanie systemu

• behawioralne - skupiających się na opisie algorytmów, podziale odpowiedzialności pomiędzy obiekty oraz charakterystyce interakcji pomiędzy nimi.

• strukturalne - opisujących sposób konstrukcji struktur obiektowych, łączenia ze sobą obiektów i zarządzania nimi

 b. Wymienić wzorce projektowe kreacyjne (modelujące działanie systemu), behawioralne, strukturalne (wybrać nie więcej niż 2 wzorce z każdej grupy)

• kreacyjne  

  • Metoda Wytwórcza (Factory Method),  

  • Budowniczy (Builder),  

  • Fabryka Abstrakcyjna (Abstract Factory),  

  • Prototyp (Prototype),  

  • Singleton

• behawioralne

  • Interpreter,  

  • Metoda Szablonowa (Template Method),  

  • Iterator,  

  • Łańcuch Zobowiązań (Chain of Responsibility),  

  • Mediator,  

  • Obserwator (Observer),  

  • Odwiedziający (Visitor),  

  • Pamiątka (Memento),  

  • Polecenie (Command),

  • Stan (State),  

  • Strategia (Strategy)

• strukturalne

  • Adapter (klasy),  

  • Adapter (obiekty),  

  • Dekorator (Decorator),  

  • Fasada (Facade),  

  • Kompozyt (Composite),  

  • Most (Bridge),  

  • Pełnomocnik (Proxy),  

  • Pyłek (Flyweight)

 

c. Wybrać nie więcej niż 2 wzorce z każdej grupy, napisać strukturę np. w pseudokodzie jak to wygląda          

 

        class Singleton {        private:            static Singleton *instance;        public:             static Singleton *getInstance() {                if(!Singleton::instance)                       Singleton::createInstance();                return Singleton::instance;            }                         static void createInstance() {                Singleton::instance = new Singleton();            }     }

 

            Metoda wytwórcza   

 

class Pizza {

public:

virtual void get_price() const = 0;

virtual ~Pizza() {};

};

class HamAndMushroomPizza: public Pizza {

public:

virtual void get_price() const {

std::cout << "Ham and Mushroom: $8.5" << std::endl;

}

};

class DeluxePizza : public Pizza {

public:

virtual void get_price() const {

std::cout << "Deluxe: $10.5" << std::endl;

}

};

class HawaiianPizza : public Pizza {

public:

virtual void get_price() const {

std::cout << "Hawaiian: $11.5" << std::endl;

}

};

class PizzaFactory {

public:

static Pizza* create_pizza(const std::string& type) {

if (type == "Ham and Mushroom") return new HamAndMushroomPizza();

else if (type == "Hawaiian")

return new HawaiianPizza();

else

return new DeluxePizza();

}

};

//usage

int main() {

PizzaFactory factory;

  std::auto_ptr<const Pizza> pizza(factory.create_pizza("Default"));

pizza->get_price();

  pizza.reset(factory.create_pizza("Ham and Mushroom"));

pizza->get_price();

  pizza.reset(factory.create_pizza("Hawaiian")); pizza->get_price();

}