io, IIS PWSZ, inżynieria oprogramowania, io


1. Dwa podstawowe rodzaje produktów software'owych.

System operacyjny - pozwala na interakcję pomiędzy komputerem a użytkownikiem. Stanowi warstwę pośredniczącą między fizycznymi elementami komputera a człowiekiem.

Aplikacja - program uruchamiany w systemie operacyjnym, nie działa bez niego. Pozwala na wykonywanie różnych działań na komputerze np. wykonywanie obliczeń czy tez odtwarzanie filmów.

2. Ewolucyjny model cyklu życia oprogramowania

Celem modelu ewolucyjnego jest poprawienie modelu kaskadowego poprzez rezygnację ze ścisłego, liniowego następstwa faz. Pozostawia się te same czynności, ale pozwala na powroty, z pewnych faz do innych faz poprzedzających. Tym samym umożliwia się adaptowanie do zmian w wymaganiach i korygowanie popełnionych błędów (oba zjawiska występują w niemal wszystkich praktycznie wykonywanych projektach - stąd model ewolucyjny jest bardziej realistyczny od kaskadowego). Model ewolucyjny wymaga dodatkowych strategii dla uporządkowania procesu wytwarzania oprogramowania.

3. Narzędzia CASE

Narzędzia CASE (czyli Computer Aided Software Engineering lub Computer Aided System Engineering) to systemy komputerowe, przeznaczone do wspomagania rutynowych czynności procesu tworzenia oprogramowania. Dzięki nim projekty tworzy się dokładniej, a praca nad diagramami, sprawdzanie ich poprawności oraz śledzenie wykonanych testów jest prostsze i szybsze.

Kiedyś takie systemy wykorzystywały modele strukturalne procesów. Dzięki rozwojowi metod obiektowych, twórcy tych systemów wprowadzali także takie modele, lecz używali różnych metodologii. Dopiero gdy wymyślono UML - stał się on dobrym standardem, a jego obsługa implementowana jest we wszystkich liczących się CASEach.

Kiedyś systemy były wykonywane w technologii z góry wybranej - wybrać trzeba było środowisko systemowe, język programowania czy też bazę danych. Teraz można wybrać kilka technologii (J2EE, .NET) i oprzeć się na kilku silnikach bazodanowych (lub też zuniwersalizować kwestię wyboru bazy danych).

Systemy CASE można podzielić według faz cyklu życia systemu na: Upper-CASE i Lower-CASE, a także według zakresu zastosowań na pakiety narzędziowe oraz pakiety zintegrowane.

Upper-CASE wspomaga pierwsze fazy budowy systemu - analizę organizacyjną i funkcjonalną i procesową, modelowanie funkcji, procesów, obiektów, modelowanie struktur i potrafi tworzyć wszelkie diagramy. Te narzędzia zajmują się bardziej opisem i modelowaniem rzeczywistości, modelowaniem struktury systemu, bez wszelkich faz implementacji.

Lower-CASE natomiast wspomaga rzeczywiste budowanie oprogramowania - modelowanie bazy danych, generowanie kodu i testy.

Czasami wyróżnia się także systemy Middle-CASE, które pozwalają określić samą strukturę systemu informatycznego, oraz Integrated-CASE, czyli systemy łączące Upper- i Lower-CASE.

Od systemów CASE wymagamy bardzo wiele. Wspomaganie w każdej fazie cyklu projektu jest inne i wymaga różnych funkcjonalności. Można jednak wyróżnić kilka standardowych modułów, których istnienie świadczy o zaawansowaniu danego systemu i spełnieniu wymagań użytkownika.

Słowniki danych (repozytoria) - bazy wszelkich danych o tworzonym systemie wraz z narzędziami edytującymi, zarządzającymi i wyszukującymi te dane.

Edytor Notacji Graficznych - program graficzny, umożliwiający tworzenie i edycję diagramów dla faz określania wymagań systemu, analizy i projektowania. Powinien też umożliwiać powiązania między symbolami w modelu a innymi, zdekomponowanymi modelami, oraz wydruk tych diagramów.

Moduł Kontroli Poprawności - narzędzie do wykrywania i poprawiania błędów w diagramach i repozytoriach. Bardzo często działa w czasie rzeczywistym, co znacząco wpływa na komfort pracy.

Moduł Kontroli Jakości - narzędzie do oceny pewnych ustalonych miar jakości projektu - np. stopnia złożoności lub powiązań składowych modelu.

Generator Raportów - narzędzie tworzące dowolny raport na podstawie danych z repozytorium.

Generator Kodu - narzędzie transformujące projekt na szkielet kodu w wybranym języku programowania. Usprawnia pracę programistów, pozwala na zautomatyzowanie pewnych fragmentów kodu, a także na uzupełnienie kodu o dodatkowe informacje ze słownika danych.

Generator Dokumentacji Technicznej - generator ustandaryzowanych dokumentów, zawierających specyfikację, opisy faz projektu, diagramy oraz wybrane raporty.

Moduł Projektowania Interfejsu Użytkownika - narzędzie do projektowania menu, okien dialogowych oraz innych elementów interfejsu użytkownika.

Moduł Inżynierii Odwrotnej - narzędzie pozwalające odtworzyć słownika danych oraz diagramów, na podstawie kodu źródłowego lub struktury bazy danych.

Moduł Importu/Eksportu Danych - narzędzie służące do wymiany danych z innymi CASE'ami czy też innymi programami.

Moduł Zarządzania Pracą Grupową - narzędzie umożliwiające współpracę grupy osób podczas pracy nad projektem.

Gdy chcemy zacząć pracę nad projektem, możemy to zrobić tworząc dowolny model od podstaw, ale możemy też za pomocą inżynierii odwrotnej stworzyć model, opierając się o istniejące struktury bazy danych, kod źródłowy z klasami, czy też struktury w XMLu. Gdy już będziemy mieli modele i będziemy równolegle pracować nad kilkoma etapami, może się okazać, że potrzebujemy wprowadzić zmiany w kilku modelach. Dobry system CASE potrafi powiązać zmiany w tych modelach z koniecznymi zmianami w innych modelach oraz dokonać automatycznie odpowiednich korekt.

4. Prototypowanie

Prototypowanie jest techniką w ramach wytwarzania ewolucyjnego, w której pojawia się nowa faza tworzenia oprogramowania, poza wymienionymi dotychczas - faza tworzenia prototypu. Prototyp jest niepełnym systemem, spełniającym cześć wymagań, przeznaczonym do przetestowania rozwiązań wykorzystanych do jego wytworzenia. Z założenia prototyp nie wchodzi w skład ostatecznego systemu (ostateczny system budowany jest od podstaw po zaakceptowaniu rozwiązań zastosowanych w prototypie). Prototypowanie, będące w powszechnym użyciu w innych dziedzinach produkcji, w informatyce posiada swoją specyfikę:

a) najczęściej wykorzystywane jest w fazie uzgadniania wymagań - prototypy służą do wykrystalizowania i ostatecznego ustalenia wymagań klienta

b) w trakcie tworzenia oprogramowania wiele wysiłku wkłada się w ponowne wykorzystanie raz utworzonego kodu - stąd typowe dla prototypowania podejście z porzucaniem prototypów nie jest zalecane

c) do stworzenia prototypu także trzeba wykorzystać jakiś model rozwoju oprogramowania.

5. Schemat sieci aktywności

6. Główne zasady przy układaniu harmonogramu

Harmonogram to określony w czasie porządek realizacji zadań w projekcie. Głównymi składowymi harmonogramu są zadania, zależności między nimi, czas trwania oraz alokacja zasobów do poszczególnych zadań.

Jednym z trzech parametrów, który definiuje i ogranicza projekt jest czas, któremu w planowaniu projektu i jego monitorowaniu poświęca się szczególną uwagę. Najczęściej mamy do czynienia z sytuacją dysponowania określonymi (przeważnie ograniczonymi) zasobami ludzkimi lub mamy narzucony czas wykonania projektu. Charakter projektu i technologia jego realizacji wpływa na związki oraz kolejność realizacji zadań.

Czas trwania realizacji zadania obliczamy według wzoru:

(czas trwania zadania*wymagana praca )/nakład pracy zasobu

gdzie:

czas trwania zadania jest rzeczywista wielkością czasu, który jest planowany na wykonanie zadania (np. 5 dni),

wymagana praca jest wielkością mierzoną w jednostkach czasochłonności niezbędnej do wykonania zadania (np. 4 osobogodziny),

nakład pracy zasobu jest wielkością wyrażoną w jednostkach pracochłonności z uwzględnieniem tylko tego czasu, w którym zasób pracuje na rzecz danego zadania - jest alokowany.

Prace nad harmonogramem związane są z wykonaniem następujących kroków:

Stosuje się najczęściej dwa podejścia co do przyjmowanego czasu trwania zadania:

Technologia realizacji i charakter projektu bezpośrednio wpływa na zależności pomiędzy zadaniami, które wyspecyfikowano aby zrealizować projekt.

Powiązania między zadaniami:

Standardowo przyjmuje się, że zadania rozpoczynają się, gdy tylko jest to możliwe.

7. Identyfikacja ryzyka

8. Automat (maszyna) o skończonej liczbie stanów

Obiekt, w świetle swoich własności (unikalna tożsamość, stan i zachowanie) może być traktowany jako automat o skończonej liczbie stanów, czyli pewną maszynę, która może znajdować się w danym momencie w jednym z wyróżnionych stanów, a także może oddziaływać na otoczenie i vice-versa.

Maszyna stanu jest grafem skierowanym, reprezentowanym za pomocą notacji diagramów stanu, którego wierzchołki stanowią stany obiektu, a łuki opisują przejścia między stanami. Przejście między stanami jest odpowiedzią na zdarzenie. Zwykle, maszyna stanu jest przypisana do klasy i specyfikuje reakcje wystąpień danej klasy na zdarzenia, które do nich przychodzą, stanowiąc w ten sposób model historii życia (opis wszystkich możliwych stanów i przejść) dla obiektu danej klasy.



Wyszukiwarka

Podobne podstrony:
diagramy, IIS PWSZ, inżynieria oprogramowania, io
pytania na egz Inż opr, IIS PWSZ, inżynieria oprogramowania, io
projekt dokumentacji Borzęcki Andruszkiewicz Jasiński, IIS PWSZ, inżynieria oprogramowania, io
K testy PWSZ, Inżynieria Oprogramowania I
Inżynieria oprogramowania syllabus IV niestac 07 08, Prywatne, WAT, SEMESTR IV, IO, io, Materiały od
inzynieria oprogramowania pytania na egzamin dypolmowy, studia, IO
sciaga io świder, Studia, Semestr 4, Inżynieria Oprogramowaia
Egzamin z IO 2014 Załącznik biznes BOO, Studia, Politechnika Opolska, Semestr IV, [Wyk] Inżynieria o
ofi sciaga, Studia WIT - Informatyka, IO - Inżynieria Oprogramowania
IO odp, WAT, semestr IV, Inżynieria oprogramowania
Nabór IO, WAT, semestr IV, Inżynieria oprogramowania
Ł IO sciaga powt, Inżynieria Oprogramowania I
Dz- przyklad-eg, Studia WIT - Informatyka, IO - Inżynieria Oprogramowania
Inzynieria oprogramowania w ujeciu obiektowym UML wzorce projektowe i Java iowuje
ZadanieNaZaliczenie, WAT, semestr IV, Inżynieria oprogramowania
Rafał Polak 12k2 lab8, Inżynieria Oprogramowania - Informatyka, Semestr III, Systemy Operacyjne, Spr

więcej podobnych podstron