Projekt modułu Nazwa całego projektu Nazwa modułu Imię i Nazwisko Inżynieria Oprogramowania II dzień, godzina rok akademicki W szablonie na niebiesko zamieszczone.

Slides:



Advertisements
Podobne prezentacje
Piotr Czekalski, ZMiTAC, Politechnika Śląska 2003
Advertisements

slajd 1 PREZENTACJA na sprawdzian INSTRUKCJA (czas 25 minut):
Związki w UML.
Projektowanie aplikacji równoległych Jarosław Kuchta.
Modelowanie przypadków użycia
Jarosław Kuchta Dokumentacja i Jakość Oprogramowania
ALGORYTM Co to jest algorytm?
Inżynieria oprogramowania
Projekt modułu Gra strategiczna „Strusia jama” Wyrzutnie
Inżynieria Oprogramowania II
Co UML może zrobić dla Twojego projektu?
Podstawy informatyki Rekurencja i rekurencja Grupa: 1A
Diagram czynności (Activity Diagrams)
Projektowanie i programowanie obiektowe II - Wykład IV
Dr Anna Kwiatkowska Instytut Informatyki
Projekt zaliczeniowy z przedmiotu "Inżynieria oprogramowania"
Projektowanie - wprowadzenie
Projekt zespołowy aplikacji sieciowej
Zarządzanie projektami
Unified Modeling Language graficzny język wizualizacji, specyfikowania, tworzenia i dokumentowania systemów informatycznych.
Inżynieria Oprogramowania
Przykładowa prezentacja w PowerPoint
Wprowadzanie opisu przedmiotu po stronie USOSweb (według sylabusa zgodnego z załącznikiem 1 do Zarządzenia nr 11 Rektora UW z dnia 19 lutego 2010) DAK.
Model przestrzenny Diagramu Obiegu Dokumentów
Zbiory biblioteczne W bibliotekach gromadzone są różnorodne zbiory, między innymi: książki, filmy na kasetach VHS oraz DVD, różne programy multimedialne,
Konspekt, a scenariusz (teza 13).
KURS Z INFORMATYKI prowadzący: mgr Przemysław Głowacki.
WebQuest wykonane w ramach projektu BelferOnLine
Instrukcja USOS Rejestracja na zajęcia obieralne wersja by Marek Opacki.
Wprowadzenie do obsługi programu PowerPoint
ZMIANY W KSZTAŁCENIU Przeczytaj, a dowiesz się o najważniejszych zmianach w kształceniu kadry w ZHP – ważnych dla Ciebie.
Prezentacja danych w postaci wykresu
Związki w UML Do zrobienia jest: -Przerysować jak ktoś ma Visio te dwa diagramy tak żeby podmienić tylko nazwy a reszta Taka sama, -I dodać po jednym zdaniu.
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
Modelowanie obiektowe Diagramy UML – diagram przypadków użycia
Spis treści W świecie algortmów -Budowa algorytmu
INSTRUKCJA WARUNKOWA (TJ. JEŻELI)
Wzorce slajdów programu microsoft powerpoint
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Konspekt (plan metodyczny) a scenariusz
Model obiektowy bazy danych
Diagram klas Kluczowymi elementami są: klasy (class)
Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu.
Modelowanie obiektowe - system zarządzania projektami.
Projektowanie relacyjnych baz danych – diagramy związków encji
Dokumentacja programu komputerowego i etapy tworzenia programów.
MAS Rafał Hryniów. Agenda  Zasady  Referaty  Projekt  Kolosy.
Algorytmy. Co to jest algorytm? Przepis prowadzący do rozwiązania zadania.
Zgłoszenie do konkursu Złota Słuchawka 2016 zlotasluchawka.pl Prezentację oraz formularz zgłoszeniowy należy wysłać na adres
Program Rozwoju Obszarów Wiejskich Wsparcie przygotowawcze dla LGD Lublin Urząd Marszałkowski Województwa Lubelskiego w Lublinie Departament.
Temat: Tworzenie bazy danych
Temat pracy Promotor: Imię i nazwisko dyplomanta Rodzaj pracy (dyplomowa inżynierska/magisterska)
Prezentacja agencji – nazwa agencji
Inżynieria systemów informacyjnych
Redakcja tekstów naukowych dla orientalistów
Autor: Łukasz Budrewicz
PROJEKTOWANIE APLIKACJI INTERNETOWYCH
Inżynieria Oprogramowania Laboratorium
Wprowadzenie do programu PowerPoint 2007
Projekt modułu BANK INTERNETOWY Moduł funkcji banku
Zgłoszenie do konkursu
Nazwa zajęć, numer Osoba prowadząca Imiona i nazwiska członków grupy
Jak napisać dobry konspekt?
Zgłoszenie w ramach kategorii Wewnętrzne doskonalenie organizacji cc
Zgłoszenia w ramach kategorii Najlepszy Zespół wspierający
Zgłoszenie w ramach kategorii Razem
MATEMATYKA Egzamin ósmoklaisty
Zgłoszenia w ramach kategorii Najlepszy Zespół konsultantów
Haskell Składnia funkcji.
Zapis prezentacji:

Projekt modułu Nazwa całego projektu Nazwa modułu Imię i Nazwisko Inżynieria Oprogramowania II dzień, godzina rok akademicki W szablonie na niebiesko zamieszczone są uwagi odnośnie zawartości kolejnych slajdów. Należy się do nich zastosować, a potem je usunąć. Tu należy umieścić nazwę projektu, nazwę modułu, imiona i nazwiska członków zespołu projektantów, dzień i godzina zajęć, rok akademicki. Należy trzymać się konwencji odnośnie graficznego ułożenia tego szablonu. Czas prezentacji powinien zawierać się w zakresie od 10 do 15 minut.

Cel i założenia Należy tu umieścić opis wszystkich założeń i celów danego modułu. Należy je opracować na podstawie założeń przedstawionych przez prowadzącego na zajęciach oraz prezentacji architektów. Powinny być tu uwzględnione jak najdokładniej założenia, które na koniec będą musiały być spełnione. Zgodność końcowego programu z tymi założeniami jest oczywiście brana pod uwagę przy końcowej ocenie. W razie potrzeby (gdyby się nie mieściło) dodać kolejny slajd według tego szablonu. ● Cel ● Pierwsze założenie ● Drugie założenie

Zmiany założeń Należy tu umieścić wszystkie zmiany, które ewentualnie nastąpiły względem założeń podanych przez prowadzącego i architektów. Gdy takich zmian nie ma można ten slajd pominąć. W razie potrzeby (gdyby się nie mieściło) dodać kolejny slajd według tego szablonu. ● Pierwsza zmiana ● Druga zmiana

Wymagania Należy tu umieścić opis wszystkich wymagań stawianych danemu modułowi. Należy je opracować na podstawie wymagań przedstawionych przez prowadzącego na zajęciach i prezentacji architektów. Powinny być tu uwzględnione jak najdokładniej wymagania, które na koniec będą musiały być spełnione. Zgodność końcowego programu z tymi wymaganiami jest oczywiście brana pod uwagę przy końcowej ocenie. ● Pierwsze wymaganie ● Drugie wymaganie

Zmiany wymagań Należy tu umieścić wszystkie zmiany, które ewentualnie nastąpiły względem wymagań podanych przez prowadzącego i architektów. Gdy takich zmian nie ma można ten slajd pominąć. W razie potrzeby (gdyby się nie mieściło) dodać kolejny slajd według tego szablonu. ● Pierwsza zmiana ● Druga zmiana

Diagram przypadków użycia Należy tu umieścić diagram przypadków użycia dla całego modułu, zawierający funkcje realizowane przez aplikację (z odpowiednimi powiązaniami elementów). Do każdego przepadku użycia i aktora należy dołączyć notatkę UML-ową z opisem odpowiedniego elementu. Gdyby się nie mieścił można go rozbić na kilka slajdów wg. tego schematu.

Diagram komponentów Należy tu umieścić diagram komponentów dla danego modułu, lecz tylko wtedy kiedy jest on konieczny (kiedy autorzy danego modułu decydują się na dekompozycję na mniejsze kawałki). W przeciwnym wypadku, slajd można usunąć.

Powiązania z innymi modułami Należy tu zamieścić dokładny opis zależności między projektowanym modułem, a innymi modułami systemu. Należy go opracować na podstawie założeń przedstawionych przez prowadzącego i prezentacji architektów. W razie potrzeby (gdyby się nie mieściło) dodać kolejny slajd według tego szablonu. ● Pierwsze powiązanie ● Drugie powiązanie

Diagram klas Należy tu umieścić diagram klas, zawierający klasy, interfejsy wykorzystywane przez daną aplikację (z odpowiednimi powiązaniami elementów). Do każdego elementu (zarówno klasy jak i powiązania) należy dołączyć notatkę UML-ową z opisem odpowiedniego elementu, bądź tak je nazwać, by z nazw wynikało ich znaczenie w aplikacji (pamiętać należy jednak, że to co jest oczywiste dla autorów projektu nie musi być oczywiste dla innych osób!). Gdyby się nie mieścił można go rozbić na kilka slajdów wg. tego schematu.

Diagram interakcji (sekwencji lub kooperacji) Należy tu umieścić diagramy interakcji (diagram sekwencji lub diagram kooperacji) dla co najmniej dwóch przypadków użycia (z diagramu przypadków użycia) – atrybuty i metody wykorzystywane na diagramach interakcji powinny odpowiadać tym, które występują w odpowiednich klasach na przedstawionym wcześniej diagramie klas. Innymi słowy należy tu pokazać jak zapomocą zaprojektowanych klas realizowane są scenariusze odpowiadające przypadkom użycia. Do każdego elementu należy dołączyć notatkę UML-ową z opisem odpowiedniego elementu, bądź tak je nazwać, by z nazw wynikało ich znaczenie w aplikacji (pamiętać należy jednak, że to co jest oczywiste dla autorów projektu nie musi być oczywiste dla innych osób!). Gdyby się nie mieścił można go rozbić na kilka slajdów wg. tego schematu.

Dodatkowe diagramy (czynności, stanów, obiektów) Można tu umieścić dodatkowe diagramy (diagramy czynności, stanów, obiektów), których użycie pozwoli lepiej zobrazować działanie konkretnego modułu. Do każdego elementu należy dołączyć notatkę UML-ową z opisem odpowiedniego elementu, bądź tak je nazwać, by z nazw wynikało ich znaczenie w aplikacji (pamiętać należy jednak, że to co jest oczywiste dla autorów projektu nie musi być oczywiste dla innych osób!). Gdyby nie był potrzebny (i tylko wtedy) można ten slajd usunąć.

Realizacja założeń i wymagań Należy tu zamieścić szczegółowe uzasadnienie tego, iż proponowany projekt przedstawiony na diagramach UML faktycznie spełnia postawione na początku założenia i wymagania. W razie potrzeby (gdyby się nie mieściło) dodać kolejny slajd według tego szablonu. ● Pierwsze uzasadnienie ● Drugie uzasadnienie

Realizacja powiązań z innymi modułami Należy tu zamieścić szczegółowe uzasadnienie tego, iż proponowany projekt przedstawiony na diagramach UML realizuje wszystkie założenia narzucone przez prowadzącego i architektów odnośnie zależności między modułami (tj. czy realizuje wszystko to czego oczekuja od niego inne moduły). W razie potrzeby (gdyby się nie mieściło) dodać kolejny slajd według tego szablonu. ● Pierwsze uzasadnienie ● Drugie uzasadnienie