Rozdział. Rozwijanie dużego systemu w warunkach akademickich. Jacek Sroka Instytut Informatyki Uniwersytetu Warszawskiego sroka@mimuw.edu.
|
|
- Krzysztof Sobczak
- 9 lat temu
- Przeglądów:
Transkrypt
1 Rozdział Rozwijanie dużego systemu w warunkach akademickich Jacek Sroka Instytut Informatyki Uniwersytetu Warszawskiego sroka@mimuw.edu.pl Droga prosta jest najkrótsza, ale na ogół wymaga najwięcej czasu, aby dojść nią do celu. Georg Christoph Lichtenberg ( ) Streszczenie Rozwijanie dużego systemu w warunkach akademickich oraz w warunkach komercyjnych różni się pod kilkoma aspektami. Poza głównym celem, jakim jest dostarczenie użytkownikom wysokiej jakości produktu spełniającego ich wymagania, w pracach prowadzonych na wyższej uczelni duży nacisk stawia się na walory edukacyjne i badawcze przedsięwzięcia. Różnice dotyczą również organizacji zespołu. W warunkach komercyjnych dąży się do specjalizacji poszczególnych osób. W warunkach akademickich każdy uczestnik przedsięwzięcia powinien zdobyć jak najszerszy zakres wiedzy, a osiągnięcie specjalizacji nie jest możliwe ze względu na krótki okres uczestnictwa w projekcie, porównywalny z okresem tworzenia pracy magisterskiej. Celem pracy jest ocena przydatności języka UML do zastosowania w pracach nad projektem USOS. USOS to duży system bazodanowy do obsługi spraw studiów, rozwijany w środowisku akademickim. Opisane wyniki zostały zebrane podczas rozwoju obecnie wdrażanego podsystemu Akademiki.
2 1. Wprowadzenie Uniwersytecki System Obsługi Studiów [USOS2003] został przedstawiony na KKIO 2001 [JMD2001] i KKIO 2002 [JMD2002]. Jego rozwojem steruje Uniwersyteckie Centrum ds. Informatyzacji, zrzeszające 15 polskich uniwersytetów. Prace projektowe i programistyczne prowadzone są przez pracowników oraz studentów Wydziału Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego (WMIM UW). Projekt trwa od grudnia Brało w nim dotychczas udział kilkudziesięciu studentów, z których około 15 zrealizowało projekty magisterskie dotyczące USOS. Prace rozwojowe prowadzone są przez studentów, w ramach zajęć dydaktycznych, bądź projektu magisterskiego. Zazwyczaj każdy uczestnik opracowuje od początku do końca nowy podsystem. Nadzór nad jego postępami sprawują nauczyciele akademiccy WMIM posiadający doświadczenia zebrane podczas realizacji dotychczasowej funkcjonalności systemu. Przy projekcie zatrudnionych jest też dwóch programistów, którzy wykonują prace standaryzacyjne, dostrajają bazę danych, poprawiają znalezione błędy oraz dodają niezwłocznie potrzebną funkcjonalność. Początkowo wydawało się, iż USOS będzie systemem średniej wielkości, składającym się z luźno powiązanych podsystemów. Dlatego prace prowadzone były zgodnie z metodą Fast Track [CDM2000] należącą do Custom Development Method opracowanego przez firmę Oracle sposobu wytwarzania oprogramowania. Wykorzystywano przy tym zalecane narzędzia z pakietu Oracle Designer. Główną zaletą takiego podejścia jest możliwość szybkiego reagowania na życzenia użytkowników dzięki często weryfikowanym prototypom. Okazuje się jednak, że w skutek ciągłego rozszerzania funkcjonalności systemu dalsza jego realizacja w ten sposób staje się utrudniona. USOS przekształca się w system duży. Nowe podsystemy zaczynają być silnie powiązane z tymi już wdrożonymi, a nawet innymi rozwijanymi równolegle. Szybkie dostarczanie prototypów przestaje być atutem przy uwzględnianiu ewentualnych błędów, jakie mogą być przy okazji wprowadzone do reszty systemu. Rośnie za to waga dokładnej analizy i dobrego projektu. Co więcej ewolucji systemu nie towarzyszy wzrost doświadczenia zespołu. Pomyślne ukończenie kolejnego podsystemu pociąga za sobą obronienie pracy magisterskiej przez jego autora i odejście z zespołu osoby najlepiej znającej dane zagadnienie. Pozostawiona dokumentacja staje się głównym źródłem wiedzy dla kolejnych ochotników, którzy odbywają przy okazji ważną, praktyczną lekcję inżynierii oprogramowania. Podczas realizacji podsystemu Akademiki zdecydowano się wprowadzić do projektu język Unified Modeling Language (UML), który stał się standardem zaakceptowanym przez środowiska akademickie oraz przemysł i uważany jest za jeden ze skuteczniejszych sposobów zarządzania zmianami w projekcie. Jeden z pionierów metodologii obiektowej Grady Booch uważa, że jeśli aplikacja zawiera kilkadziesiąt klas lub abstrakcji, to zespół nie jest w stanie zapamiętać wszystkich zależności pomiędzy nimi. Wykorzystanie intuicyjnej, graficznej notacji w trakcie prac analitycznych, projektowych i tworzenia dokumentacji sprawia, iż powstałe w ten sposób artefakty oraz zależności między nimi są zrozumiałe nawet dla nowych członków zespołu. Jednocześnie ich znaczenie nie budzi
3 wątpliwości, gdyż wszystkie elementy są dobrze zdefiniowane (por. [UML2001]). Inne istotne cechy UML to możliwość komputerowego wspomagania walidacji opracowywanych modeli, dostępność materiałów edukacyjnych oraz dobre wsparcie narzędziowe. Prowadzone przez półtora roku prace pozwoliły zbadać sposoby wykorzystania języka UML we wszystkich etapach rozwoju nowego podsystemu. Jako punkt wyjścia wybrano dostosowany do warunków komercyjnych proces wytwarzania oprogramowania Rational Unified Proces (RUP). Przy pomocy zakupionego oprogramowania Rational Rose Enterprise Edition opracowano model podsystemu Akademiki. Powstała także praca magisterska [SRO2003], która może posłużyć za szablon dla innych uczestników projektu. W ramach eksperymentu, dla przetestowania jakości rozwiązań, część prac programistycznych została wykonana jedynie na podstawie przygotowanego projektu, przez osobę nieuczestniczącą w pracach analitycznych ani projektowych. Wypracowane rozwiązania oraz ich ocena przedstawione są w kolejnych punktach. 2. Wykorzystanie UML w projekcie Prace nad podsystemem Akademiki prowadzone są od początku roku akademickiego 2001/2002. Rozpoczęto od zapoznania się ze sposobem działania zespołu USOS i wykorzystywanymi narzędziami. Następnie przeanalizowano architekturę USOS i dostępną dotychczas funkcjonalność. Rys. 1. Diagram komponentów - architektura systemu USOS Głównym źródłem wiedzy były prace magisterskie wcześniejszych uczestników projektu oraz dokumentacja elektroniczna stworzona przy pomocy pakietu Oracle Designer. Narzędzie to sprawdza się przy projektowaniu bazy danych oraz formularzy i raportów. Istotne jest przy tym operowanie dobrze zrozumiałymi przez studentów diagramami Entity Relation Diagram (ERD) oraz opracowaną specjalnie do tego celu graficzną
4 notacją umożliwiającą przedstawianie organizacji formularzy i raportów. Istotną zaletą jest również możliwość wygenerowania na podstawie opracowanego projektu skryptów Data Definition Language (DDL) tworzących bazę danych oraz prototypów formularzy i raportów, które spełniają przyjęte w projekcie standardy. Niestety możliwości modelowania architektury, zależności pomiędzy podsystemami oraz funkcjonalności są niedostępne bądź niewystarczające i większość uczestników projektu wykonywało te prace przy pomocy wybranych, a czasami nawet opracowanych przez siebie notacji i narzędzi. Prowadziło to do powstawania niejasności co do znaczenia elementów tworzonych modeli. Zdecydowano się zatem na wykorzystanie języka UML. Do przedstawienia architektury wykorzystano diagramy komponentów (por. rysunek 1). Zależności pomiędzy podsystemami pokazano na diagramach klas, a do analizy funkcjonalności zdecydowano się zastosować przypadki użycia. Efekty pracy były obiecujące, a pomysł zyskał poparcie kierownictwa projektu. Wykorzystanie UML ma duże znaczenie dydaktyczne. Język ten jest obecnie podstawą kursów dotyczących projektowania systemów informacyjnych. Jego wykorzystanie w USOS może zachęcić studentów do podejmowania się projektów badawczych z dziedziny inżynierii oprogramowania mogących znaleźć praktyczne zastosowanie. Daje to większą satysfakcję oraz czyni zajęcia bardziej interesującymi. 3. Kontakty z użytkownikami i analiza wymagań Każde przedsięwzięcie programistyczne rozpoczyna się od analizy wymagań. Błędy popełnione w tej fazie trwania projektu są bardzo kosztowne. Głównym źródłem ich powstawania jest niedostateczne zrozumienie potrzeb przyszłych użytkowników. Powodem mogą być problemy z komunikacją, brak odpowiedzialności za ustalenia, a nawet nie zrozumienie własnych potrzeb przez samych użytkowników. 3.1 Problemy z komunikacją W kontaktach z użytkownikami należy posługiwać się zrozumiałym dla obu stron językiem. Niezależnie od przyjętej metodyki powinien zostać sporządzony słownik niejasnych pojęć zawierający objaśnienia terminów zarówno z zakresu modelowanej dziedziny, jak i tworzonego systemu informatycznego. Umożliwi on zrozumienie powstających dokumentów przez osoby nieuczestniczące w rozmowach i ma szczególne znaczenia dla zespołu programistycznego o systematycznie uzupełnianym, bądź zmienianym składzie. Nowoczesne procesy wytwarzania oprogramowania, jak RUP, zalecają rozpoczęcie projektu od analizy biznesowej. Jej wynikiem powinno być sporządzenie dokumentów obrazujących sposób działania przedsiębiorstwa/organizacji zlecającej wytworzenie oprogramowania. Podczas realizacji podsystemu Akademiki szczególnie przydatne okazały się diagramy przepływu czynności. Na przykład na rysunku 2 przedstawiono
5 nadzorowany przez Biuro Spraw Studenckich (BSS) proces rozdzielania akademików na UW. Poza udostępnieniem informacji dla pozostałych członków zespołu takie diagramy pozwalają w wygodny sposób komunikować się z użytkownikami. Rys. 2. Diagram przepływu czynności - rozdzielanie akademików na UW Ponieważ USOS ma działać na wielu uniwersytetach nie mogąc ograniczać ich autonomii, konieczne jest wypracowanie modelu biznesowego pasującego do rozwiązań
6 stosowanych przez nie wszystkie. Rozproszenie geograficzne ogranicza często komunikację do wymiany dokumentów. Doświadczenie pokazało, że generowane przez studentów diagramy są zrozumiałe dla użytkowników, co nie zawsze miało miejsce z opisami słownymi. 3.2 Odpowiedzialność za ustalenia W komercyjnych przedsięwzięciach część dokumentów sporządza się po to, aby umożliwić nadzór nad postępami projektu. Niezbędna jest też możliwość wykazania, że gotowy produkt spełnia wynegocjowane wymagania. Ze względu na niekomercyjny charakter USOS wydawać by się mogło, że spisywanie wymagań jest zbędne, ponieważ uczestnikami projektu jak i przyszłymi użytkownikami kierują dobre chęci. Tak jednak nie jest, a doświadczenie tego na własnej skórze jest doskonałą szkołą inżynierii oprogramowania. W przeciwieństwie do projektów wykonywanych na zajęciach, dla których wymagania są dobrze określone, podczas realizacji systemu produkcyjnego użytkownicy nie zawsze wiedzą, czego dokładnie im potrzeba. Skoro jednak prace programistyczne prowadzone są do momentu zaakceptowania stworzonego podsystemu cel musi być widoczny od samego początku. Rys. 3. Przypadki użycia dla aktora Sekcja Studencka Należy założyć, że ustalenia ustne nie są wiążące. Zgoda użytkowników może wynikać z ich niechęci do przyznania się, iż nie rozumieją, bądź nie są pewni. Sytuację może utrudniać obecność ich przełożonych na spotkaniach, a czasami skrępowanie wiekiem studentów. Opracowanie i utrzymywanie dokumentów zawierających uzgodnione wymagania jest więc dobrą praktyką. Użytkownicy powinni po każdym spotkaniu dostać
7 czas na zapoznanie się z dokumentami i być zachęcani do zadawania pytań. Istnienie spisanych wymagań stwarza większą presję do zastanowienia się nad nimi zanim podsystem zostanie stworzony, a wprowadzenie jakichkolwiek zmian będzie dużo bardziej pracochłonne. Do określenia granic i zakresu odpowiedzialności systemu w UML wykorzystuje się aktorów i przypadki użycia. Ogólne zależności przedstawiane są na diagramach przypadków użycia (por. rysunek 3). Szczegółowy opis można wykonać zgodnie z jednym z wielu dostępnych szablonów. W pracy [SRO2003] wykorzystano szablon dostarczony z [RUP2002]. Przy określaniu przypadków użycia należy zachować wiele uwagi. Powinny one obejmować wszystkie kluczowe aspekty działania systemu bez wchodzenia w zbędne szczegóły. 3.3 Niezrozumienie swoich potrzeb przez użytkowników Podstawowym celem systemu USOS jest usprawnienie prac administracyjnych związanych z obsługą dydaktyki na wyższej uczelni. Jednak czasami użytkownicy na początku nie postrzegają wprowadzenia systemu jako ułatwienia. Jego siła objawia się po poznaniu możliwości i opanowaniu sposobu obsługi. Bardzo istotne jest zachęcenie użytkowników do współpracy przez ich przełożonych. Prace rozwojowe nad nowym podsystemem powinny należeć do zakresu ich obowiązków, a wykazywanie inicjatywy powinno być motywowane. Należy się spodziewać, iż użytkownicy mogą nie znać technologii komputerowej w stopniu dostatecznym do określenia swoich potrzeb. Cześć ich pomysłów może być niemożliwa do zrealizowania. Z drugiej strony mogą nie być świadomi, iż niektóre wykonywane przez nich czynności da się znacznie uprościć poprzez zastosowanie odpowiednich rozwiązań. Spisywanie wymagań może mieć dodatkowy efekt porządkujący. Skoro trzeba spisać, to trzeba najpierw przemyśleć, uprościć, może nawet zreorganizować. Jest to dobry moment na zastanowienie się czy nie występują jakieś przypadki szczególne. Możliwe, że ich wykrycie spowoduje rewizję procedur organizacyjnych. Trzeba być jednak świadomym, iż mimo dobrych chęci i odpowiedzialnego podejścia formalnie spisane wymagania oraz jasny projekt nie zawsze wystarczą. Konieczne jest częste weryfikowanie postępów poprzez przedstawianie użytkownikom prototypów oraz zastosowanie iteracyjnego sposobu pracy. 4. Projekt bazy Przy podejściu strukturalnym do projektowania relacyjnej bazy danych wykorzystuje się diagramy ERD. Technika ta stanowi podstawę każdego kursu baz danych. Diagramy ERD są skutecznie wykorzystywane podczas prac nad systemem USOS. W UML do modelowania bazy danych wykorzystuje się diagramy odpowiednio stereotypowanych klas. Kluczową różnicą tych podejść jest szczegółowość. Diagramy ERD mają charakter
8 pojęciowy. Przedstawia się na nich encje, a nie tabele. Encje posiadają jedynie atrybuty je opisujące. Natomiast w UML przedstawia się tabele, które fizycznie mogą istnieć w bazie danych. Tabele zawierają dodatkowe kolumny niezbędne do realizacji więzów referencyjnych. Z tabelami mogą być związane wyzwalacze, które w UML modeluje się jako metody. Może się wydawać, iż ze względu na wyższy poziom abstrakcji diagramy ERD powinny być wygodniejsze w użyciu. Jednak przy dużym projekcie, w którym baza danych ulega dynamicznemu rozwojowi istotnym czynnikiem jest możliwość wykorzystania inżynierii wprzód (ang. forward engineering) i inżynierii wstecz (ang. backward engineering). W obu wypadkach inżynieria wprzód jest możliwa, dla encji po sprecyzowaniu kryteriów przekształcenia do tabel, a dla klas po doprecyzowaniu wszystkich szczegółów. Jednak pełna inżynieria wstecz jest możliwa jedynie w przypadku UML. Dlatego dodatkowy nakład pracy potrzebny na stworzenie projektu o wyższym poziomie szczegółowości wydaje się procentować przy uwzględnieniu łatwości utrzymania modelu bazy. Ponadto opłacalne wydaje się podejście iteracyjne, w którym w zależności od wygody zmiany wprowadza się raz w modelu, a raz w schemacie bazy danych i przy pomocy inżynierii wprzód lub inżynierii wstecz uzgadnia się ich stan. 5. Projekt modułów Konstrukcja systemu USOS, ze względu na jego złożoność, nie byłaby możliwa bez wyodrębnienia mniejszych podsystemów. Aby projekt zachował jednorodność, wszystkie prace powinny być prowadzone zgodnie z uprzednio ustalonymi standardami. Dotyczy to zarówno architektury systemu, rozwiązań programistycznych w nim przyjętych, jak i interfejsu użytkownika. Funkcjonalność części administracyjnej systemu opiera się na formularzach i raportach przygotowywanych za pomocą narzędzi z pakietu Oracle Developer. W ramach pracy standaryzacyjnej [GOLD2003] spisano zalecane rozwiązania oraz przedstawiono szablony umożliwiające szybkie generowanie zgodnych ze standardami prototypów. Wykonywane są również czynności mające na celu ujednolicenie wdrożonych już podsystemów. Niestety samo przestrzeganie standardów nie gwarantuje jeszcze jednolitości rozwiązań. Przykładowo niektóre dane wykorzystywane są przez kilka podsystemów. Dla wygody użytkowników dostęp do nich powinien być możliwy z kontekstu różnych formularzy. Należy zadbać o to, aby w miarę możliwości wykorzystano analogiczne rozwiązania. Wymaga to dodatkowych rozwiązań w zakresie organizacji pracy zespołu, ponieważ prace rozwojowe prowadzone są przez osoby nieznające istniejącej funkcjonalności USOS. Nawet wykorzystanie często weryfikowanych prototypów prowadzi w niektórych przypadkach do niepotrzebnego rozwiązywania tych samych problemów na nowo, a czasami nawet do marnowania wykonanej pracy. Jakkolwiek nie da się przecenić wagi prototypów przy współpracy z użytkownikami, to oceny planowanych rozwiązań warto dokonać wcześniej, w obrębie zespołu. Konieczne jest, więc sporządzenie projektu i jego weryfikacja. Ze względu na wymuszone wygodą użytkowników dążenie do tworzenia modułów jak najprostszych,
9 nakład prac konieczny do uzyskania projektu o zadowalającej szczegółowości może być niewielki. Analiza projektu pozwoli nauczycielom akademickim nadzorującym projekt spostrzec analogie z dotychczas wdrożonymi podsystemami i zasugerować ewentualne poprawki przed dokonaniem żmudnej organizacji interfejsu użytkownika w pierwszych prototypach. Rys. 4. Model danych formularza Akademiki UML najlepiej sprawdza się w pracach nad obiektowymi systemami informacyjnymi. Został jednak przewidziany wygodny mechanizm rozszerzania samego języka o specyficzne pojęcia, dotyczące modelowanej dziedziny. W pracy [SRO2003] przedstawiono proponowany sposób modelowania formularzy i raportów Oracle Developer przy pomocy języka UML oraz zdefiniowanych specjalnie do tego celu
10 stereotypów i metek. Na rysunku 4 pokazano model danych formularza Akademiki, a na rysunku 5 elementy składowe, zależności między nimi oraz powiązani z innymi modułami formularza Przyznawania. Rozwiązanie to jest ściśle dopasowane do sposobu konstruowania modułów wykorzystywanych w USOS. Przedstawienie przy jego pomocy konstrukcji odmiennych może być niewygodne. Ten efekt jest zamierzony. Wspomaga się tym samym powstawanie projektów o analogicznej strukturze, i ogranicza bałaganiarskie programowanie. Jednocześnie ogólność UML gwarantuje możliwość wprowadzenia rozszerzeń, gdyby w przyszłości zaistniała taka potrzeba. Rys. 5. Organizacja i powiązania formularza Przyznawania Dodatkową korzyścią z opracowania projektu modułów jest zwiększenie jakości tworzonego kodu. System opracowany na podstawie nawet prostego projektu jest zazwyczaj zdecydowanie solidniej wykonany niż analogiczny powstały metodą programowania ewolucyjnego. 6. Dokumentacja techniczna i dokumentacja użytkownika Działający system nie powinien być jedynym efektem prac zespołu programistycznego. Należy również opracować solidną dokumentację techniczną oraz dokumentację użytkownika. Podstawowe cech języka UML przemawiające za wykorzystaniem go w tych celach to: zastosowanie łatwej do zrozumienia graficznej notacji, możliwość przedstawienia powiązań pomiędzy elementami należącymi do różnych podsystemów, użycie tego samego formalizmu co w poprzednich fazach przedsięwzięcia,
11 duże możliwości wspomagania komputerowego, w tym automatycznej kontroli spójności modeli. Podczas rozwoju podsystemu Akademiki wykazano, że nakład pracy niezbędnej do utrzymywania aktualności artefaktów powstałych w wyniku analizy i projektowania jest niewielki w porównaniu z metodami dotychczas stosowanymi. Dodatkowo powstające diagramy doskonale nadają się do wykorzystania w różnego rodzaju publikacjach, np. pracach magisterskich opracowywanych po wdrożeniu kolejnych podsystemów. Poznanie UML przez uczestników projektu ma również pozytywny wpływ na jakość powstającej dokumentacji użytkownika. Należy pamiętać, iż przejrzysty diagram może przekazywać więcej informacji niż kilkustronicowy opis. 7. Podsumowanie Metody inżynierii oprogramowania ulegają stałej ewolucji. Uczestnictwo w projekcie rozwijanym w warunkach akademickich jest doskonałym sposobem przetestowania ich w praktyce. Dzięki niezależności od czynników komercyjnych istnieje tu duże pole do eksperymentów. Specyfika dużego, ciągle ewoluującego, projektu akademickiego sprawia, że duży nacisk kładzie się na organizację pracy w zespole i wspomaganie wymiany doświadczeń pomiędzy jego członkami. W warunkach systematycznie zmieniającego się zespołu jednolity sposób wymiany informacji jest niezmiernie istotny. Język UML idealnie nadaje się do tego celu. Prace prowadzone nad rozwojem podsystemu Akademiki potwierdziły jego przydatność. Wykazano poprawę kontaktów z użytkownikiem. Wzrosły możliwości kontroli nad prowadzonymi pracami przez osoby nadzorujące projekt. Wymiana informacji pomiędzy członkami zespołu stała się łatwiejsza. Pomyślnie został oceniony sposób rozszerzenia UML o stereotypy umożliwiające projektowanie modułów wytwarzanych przy pomocy narzędzi z pakietu Oracle Developer. Jakość powstałego projektu potwierdziło wykonanie części pracy programistycznej przez osobę nieuczestniczącą w pracach analityczno-projektowych, jedynie na podstawie dostarczonych dokumentów. Zniechęcający może się wydawać dodatkowy nakład pracy konieczny do poznania nowego formalizmu. Jednak ze względu na powszechność wykorzystania UML w przemyśle informatycznym posiadanie praktycznego doświadczenia w jego stosowaniu wydaje się znaczącą zaletą. Warto przypomnieć, że pomysł użycia UML został wysunięty przez samych uczestników projektu, a nie narzucony im przez osoby nadzorujące zespół. Należy zaznaczyć, iż zainteresowanie metodami inżynierii oprogramowania wśród studentów jest duże i przy dobrym umotywowaniu ich przez nauczycieli akademickich projekt USOS może dostarczyć wiele ciekawych wyników z tej dziedziny.
12 Bibliografia [CDM2000] Gylseth S., Using CDM Fast Track, Oracle s DSDM Compliant RAD Approach. Oracle Corporation, [GOLD2003] Goldman B., Uniwersytecki System Obsługi Studiów. Standardy. Instytut Informatyki Uniwersytetu Warszawskiego, Praca magisterska (w przygotowaniu). [JMD2001] Mincer-Daszkiewicz J., Tworzenie produkcyjnego oprogramowania w środowisku akademickim. III Krajowa Konferencja Inżynierii Oprogramowania KKIO 2001, 2001, s [JMD2002] Mincer-Daszkiewicz J., Tworzenie i wdrażanie produkcyjnego oprogramowania w środowisku akademickim. IV Krajowa Konferencja Inżynierii Oprogramowania KKIO 2002, 2002, s [RUP2002] Rational Unified Process. Rational Software Corporation., [SRO2003] Sroka J., Uniwersytecki System Obsługi Studiów. Akademiki. Instytut Informatyki Uniwersytetu Warszawskiego, Praca magisterska (w przygotowaniu). [UML2001] Booch G., Rumbaugh J., Jacobson I., UML przewodnik użytkownika. WNT, [USOS2003]
PRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy
Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne
Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Kierunek: Informatyka Modeling and analysis of computer systems Forma studiów: Stacjonarne Rodzaj przedmiotu: obowiązkowy w ramach specjalności:
PRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.
Spis treúci. 1. Wprowadzenie... 13
Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...
Narzędzia CASE dla.net. Łukasz Popiel
Narzędzia CASE dla.net Autor: Łukasz Popiel 2 Czym jest CASE? - definicja CASE (ang. Computer-Aided Software/Systems Engineering) g) oprogramowanie używane do komputerowego wspomagania projektowania oprogramowania
1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI
KARTA PRZEDMIOTU przedmiotu Stopień studiów i forma Rodzaj przedmiotu Grupa kursów Zaawansowane techniki analizy systemowej oparte na modelowaniu warsztaty Studia podyplomowe Obowiązkowy NIE Wykład Ćwiczenia
Projektowanie systemów informatycznych. wykład 6
Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany
Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 1 Wprowadzenie do narzędzia CASE. Materiały dla nauczyciela
Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 1 Wprowadzenie do narzędzia CASE
Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty
Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy
WPROWADZENIE DO UML-a
WPROWADZENIE DO UML-a Maciej Patan Instytut Sterowania i Systemów Informatycznych Dlaczego modelujemy... tworzenie metodologii rozwiązywania problemów, eksploracja różnorakich rozwiązań na drodze eksperymentalnej,
PRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: Kierunek: Inżynieria Biomedyczna Rodzaj przedmiotu: obowiązkowy moduł specjalności informatyka medyczna Rodzaj zajęć: wykład, laboratorium PROGRAMOWANIE INTERNETOWE Internet Programming
Wprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego
Etapy Ŝycia systemu informacyjnego Wprowadzenie do metodologii modelowania systemów informacyjnych 1. Strategia 2. Analiza 3. Projektowanie 4. Implementowanie, testowanie i dokumentowanie 5. WdroŜenie
Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl
Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki
Narzędzia Informatyki w biznesie
Narzędzia Informatyki w biznesie Przedstawiony program specjalności obejmuje obszary wiedzy informatycznej (wraz z stosowanymi w nich technikami i narzędziami), które wydają się być najistotniejsze w kontekście
Informatyczne fundamenty
Informatyczne fundamenty Informatyka to szeroka dziedzina wiedzy i praktycznych umiejętności. Na naszych studiach zapewniamy solidną podstawę kształcenia dla profesjonalnego inżyniera IT. Bez względu na
Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia. Materiały dla nauczyciela
Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia Materiały dla nauczyciela Projekt
Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)
Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu
KARTA MODUŁU KSZTAŁCENIA
KARTA MODUŁU KSZTAŁCENIA I. Informacje ogólne 1 Nazwa modułu kształcenia Inżynieria 2 Nazwa jednostki prowadzącej moduł Instytut Informatyki, Zakład Informatyki Stosowanej 3 Kod modułu (wypełnia koordynator
Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2
Wyższa Szkoła Menedżerska w Legnicy Systemy informatyczne w przedsiębiorstwach Zarządzanie, ZIP, sem. 6 (JG) Modelowanie wymagań Wykład 2 Grzegorz Bazydło Cel wykładu Celem wykładu jest przekazanie wiedzy
Inżynieria oprogramowania. Jan Magott
Inżynieria oprogramowania Jan Magott Literatura do języka UML G. Booch, J. Rumbaugh, I. Jacobson, UML przewodnik użytkownika, Seria Inżynieria oprogramowania, WNT, 2001, 2002. M. Fowler, UML w kropelce,
KIERUNKOWE EFEKTY KSZTAŁCENIA
WYDZIAŁ INFORMATYKI I ZARZĄDZANIA Kierunek studiów: INFORMATYKA Stopień studiów: STUDIA II STOPNIA Obszar Wiedzy/Kształcenia: OBSZAR NAUK TECHNICZNYCH Obszar nauki: DZIEDZINA NAUK TECHNICZNYCH Dyscyplina
Janina Mincer-Daszkiewicz
Janina Mincer-Daszkiewicz Wydział Matematyki, Informatyki i Mechaniki Uniwersytet Warszawski http://www.mimuw.edu.pl/~jmd jmd@mimuw.edu.pl Możliwości wykorzystania własnej kadry informatycznej (pracownicy,
Analiza i projektowanie obiektowe w UML Kod przedmiotu
Analiza i owanie obiektowe w UML - opis przedmiotu Informacje ogólne Nazwa przedmiotu Analiza i owanie obiektowe w UML Kod przedmiotu 11.3-WK-MATP-UML-W-S14_pNadGen5M44E Wydział Kierunek Wydział Matematyki,
Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym
Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM
Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)
Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Zarządzanie wymaganiami Ad hoc (najczęściej brak zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura
KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA
KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,
Opis metodyki i procesu produkcji oprogramowania
Opis metodyki i procesu produkcji oprogramowania Rational Unified Process Rational Unified Process (RUP) to iteracyjny proces wytwarzania oprogramowania opracowany przez firmę Rational Software, a obecnie
Techniki modelowania programów Kod przedmiotu
Techniki modelowania programów - opis przedmiotu Informacje ogólne Nazwa przedmiotu Techniki modelowania programów Kod przedmiotu 11.3-WI-INFD-TMP Wydział Kierunek Wydział Informatyki, Elektrotechniki
Spis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08
Spis treści Wstęp.............................................................. 7 Część I Podstawy analizy i modelowania systemów 1. Charakterystyka systemów informacyjnych....................... 13 1.1.
Konfiguracja modelowania w procesie wytwarzania oprogramowania
Konfiguracja modelowania w procesie wytwarzania oprogramowania Anna Bobkowska Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura nie zastępuje obecności na
PRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: Kierunek: Informatyka Rodzaj przedmiotu: obowiązkowy w ramach specjalności: Programowanie aplikacji internetowych Rodzaj zajęć: laboratorium PRZEWODNIK PO PRZEDMIOCIE I KARTA PRZEDMIOTU
PRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: Kierunek: Mechatronika Rodzaj przedmiotu: obowiązkowy w ramach treści kierunkowych Rodzaj zajęć: wykład, laboratorium BAZY DANYCH I SYSTEMY EKSPERTOWE Database and expert systems Forma
PRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: Kierunek: Inżynieria Biomedyczna Rodzaj przedmiotu: obowiązkowy moduł specjalności informatyka medyczna Rodzaj zajęć: wykład, laboratorium PROGRAMOWANIE OBIEKTOWE Object-Oriented Programming
Projekt systemu informatycznego
Projekt systemu informatycznego Kod przedmiotu: PSIo Rodzaj przedmiotu: specjalnościowy ; obieralny Wydział: Informatyki Kierunek: Informatyka Specjalność (specjalizacja): Inżynieria Systemów Informatycznych
Egzamin / zaliczenie na ocenę*
WYDZIAŁ PODSTAWOWYCH PROBLEMÓW TECHNIKI Zał. nr 4 do ZW33/01 KARTA PRZEDMIOTU Nazwa w języku polskim : INŻYNIERIA OPROGRAMOWANIA Nazwa w języku angielskim: SOFTWARE ENGINEERING Kierunek studiów (jeśli
Projektowanie baz danych za pomocą narzędzi CASE
Projektowanie baz danych za pomocą narzędzi CASE Metody tworzenia systemów informatycznych w tym, także rozbudowanych baz danych są komputerowo wspomagane przez narzędzia CASE (ang. Computer Aided Software
Inżynieria oprogramowania
Inżynieria oprogramowania Instrukcja do laboratorium rok akad. 2014/2015 Informacje podstawowe: Celem laboratorium jest nabycie przez studentów praktycznej umiejętności wykonywania modeli analitycznych
SVN. 10 października 2011. Instalacja. Wchodzimy na stronę http://tortoisesvn.tigris.org/ i pobieramy aplikację. Rysunek 1: Instalacja - krok 1
SVN 10 października 2011 Instalacja Wchodzimy na stronę http://tortoisesvn.tigris.org/ i pobieramy aplikację uruchamiany ponownie komputer Rysunek 1: Instalacja - krok 1 Rysunek 2: Instalacja - krok 2
Podsumowanie wyników ankiety
SPRAWOZDANIE Kierunkowego Zespołu ds. Programów Kształcenia dla kierunku Informatyka dotyczące ankiet samooceny osiągnięcia przez absolwentów kierunkowych efektów kształcenia po ukończeniu studiów w roku
Etapy życia oprogramowania
Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 w prezentacji wykorzystano również materiały przygotowane przez Michała Kolano
System informacji edukacyjnej regionu kujawsko-pomorskiego
X Konferencja PLOUG Kościelisko Październik 2004 System informacji edukacyjnej regionu kujawsko-pomorskiego Izabela Rojek-Mikołajczak Krzysztof Tyburek Akademia Bydgoska, Instytut Mechaniki Środowiska
Politechnika Krakowska im. Tadeusza Kościuszki. Karta przedmiotu. obowiązuje studentów rozpoczynających studia w roku akademickim 2013/2014
Politechnika Krakowska im. Tadeusza Kościuszki Karta przedmiotu Wydział Mechaniczny obowiązuje studentów rozpoczynających studia w roku akademickim 2013/2014 Kierunek studiów: Informatyka Stosowana Forma
Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla nauczyciela
Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram
Zasady organizacji projektów informatycznych
Zasady organizacji projektów informatycznych Systemy informatyczne w zarządzaniu dr hab. inż. Joanna Józefowska, prof. PP Plan Definicja projektu informatycznego Fazy realizacji projektów informatycznych
PRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: Kierunek: Informatyka Rodzaj przedmiotu: moduł specjalności obowiązkowy: Inżynieria oprogramowania Rodzaj zajęć: laboratorium PROJEKT ZESPOŁOWY DYPLOMOWY IO Team Project SE Forma studiów:
Uniwersytet w Białymstoku Wydział Ekonomiczno-Informatyczny w Wilnie SYLLABUS na rok akademicki 2012/2013
SYLLABUS na rok akademicki 01/013 Tryb studiów Studia stacjonarne Kierunek studiów Informatyka Poziom studiów Pierwszego stopnia Rok studiów/ semestr III/VI Specjalność Bez specjalności Kod katedry/zakładu
Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania
Etapy życia oprogramowania Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 Określenie wymagań Testowanie Pielęgnacja Faza strategiczna
Architektura oprogramowania w praktyce. Wydanie II.
Architektura oprogramowania w praktyce. Wydanie II. Autorzy: Len Bass, Paul Clements, Rick Kazman Twórz doskonałe projekty architektoniczne oprogramowania! Czym charakteryzuje się dobra architektura oprogramowania?
Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017
Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy
UML w Visual Studio. Michał Ciećwierz
UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować
Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla studenta
Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram
Procesowa specyfikacja systemów IT
Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office
ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski
INFORMATYKA W ZARZĄDZANIU Wykład VI dr Jan Kazimirski jankazim@mac.edu.pl http://www.mac.edu.pl/jankazim MODELOWANIE SYSTEMÓW UML Literatura Joseph Schmuller UML dla każdego, Helion 2001 Perdita Stevens
Projektowanie oprogramowania
Wrocław, 24.09.2018 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia) Zajęcia składają się z
Projektowanie oprogramowania
Wrocław, 27.09.2010 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia) Zajęcia składają się z
Analityk i współczesna analiza
Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura
Modelowanie i analiza systemów informatycznych
Katolicki Uniwersytet Lubelski Jana Pawła II Wydział Matematyki, Informatyki i Architektury Krajobrazu Modelowanie i analiza systemów informatycznych ćwiczenia informacja wstępna dr Viktor Melnyk, prof.
PRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: Kierunek: Informatyka Rodzaj przedmiotu: moduł specjalności obowiązkowy: Inżynieria oprogramowania, Programowanie aplikacji internetowych Rodzaj zajęć: wykład, laboratorium I KARTA PRZEDMIOTU
Wymagania edukacyjne z informatyki i technologii informacyjnej
Wymagania edukacyjne z informatyki i technologii informacyjnej TECHNOLOGIA INFORMACYJNA Cele edukacyjne 1. Wykształcenie umiejętności świadomego i sprawnego posługiwania się komputerem oraz narzędziami
Lista przykładowych pytań do egzaminu z przedmiotu Inżynieria Oprogramowania
Lista przykładowych pytań do egzaminu z przedmiotu Inżynieria Oprogramowania Inżynieria oprogramowania przykładowe pytania egzaminacyjne str. 2 Przykładowe pytania 1. Wymień i omów krótko podstawowe kategorie
KARTA PRZEDMIOTU. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI Ogólne umiejętności posługiwania się komputerem
WYDZIAŁ INFORMATYKI I ZARZĄDZANIA Zał. nr 4 do ZW 33/01 KARTA PRZEDMIOTU Nazwa w języku polskim: Nazwa w języku angielskim: Kierunek studiów (jeśli dotyczy): Specjalność (jeśli dotyczy): Stopień studiów
Podstawy programowania III WYKŁAD 4
Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.
Web frameworks do budowy aplikacji zgodnych z J2EE
Web frameworks do budowy aplikacji zgodnych z J2EE Jacek Panachida promotor: dr Dariusz Król Przypomnienie Celem pracy jest porównanie wybranych szkieletów programistycznych o otwartym kodzie źródłowym
Tworzenie i wdrażanie produkcyjnego oprogramowania w środowisku akademickim
Tworzenie i wdrażanie produkcyjnego oprogramowania w środowisku akademickim Janina Mincer-Daszkiewicz Instytut Informatyki, Uniwersytet Warszawski Streszczenie Projekt Tempus NET i system USOS przedstawiono
Zarządzanie firmą Celem specjalności jest
Zarządzanie firmą Celem specjalności jest przygotowanie jej absolwentów do pracy na kierowniczych stanowiskach średniego i wyższego szczebla we wszystkich rodzajach przedsiębiorstw. Słuchacz specjalności
Wykład 1 Inżynieria Oprogramowania
Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI
Organizacja zajęć BAZY DANYCH II WYKŁAD 1. Plan wykładu. SZBD Oracle 2010-10-21
Organizacja zajęć BAZY DANYCH II WYKŁAD 1 Wykładowca dr inż. Agnieszka Bołtuć, pokój 304, e-mail: aboltuc@ii.uwb.edu.pl Liczba godzin i forma zajęć: 15 godzin wykładu oraz 30 godzin laboratorium Konsultacje:
PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK
KLUCZ ODPOWIEDZI Część DODATEK 8.1 9.4 PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB Na podstawie: Syllabus REQB Certified Professional for Requirements Engineering, Advanced Level, Requirements
Dokument Detaliczny Projektu
Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej
Dokument Detaliczny Projektu
Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej
Jarosław Żeliński analityk biznesowy, projektant systemów
Modele wdrażania i zarządzania projektami ERP Jarosław Żeliński analityk biznesowy, projektant systemów (c) Jarosław Żeliński IT-Consulting 1 Cel prezentacji Wskazanie kluczowych ryzyk projektów wdrożenia
SPINACZ.edu.pl platforma współpracy nauki z biznesem w zakresie innowacyjnych rozwiązań informatycznych
SPINACZ.edu.pl platforma współpracy nauki z biznesem w zakresie innowacyjnych rozwiązań informatycznych Poznańska Impreza Wolnego Oprogramowania Poznań, 3 grudnia 2011 Rafał Brzychcy rafal.brzychcy@fwioo.pl
Informatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny) kierunkowy (podstawowy / kierunkowy / inny HES)
KARTA MODUŁU / KARTA PRZEDMIOTU Kod modułu Nazwa modułu Modelowanie i Analiza Systemów Informatycznych Nazwa modułu w języku angielskim Modeling and Analysis of Information Systems Obowiązuje od roku akademickiego
KARTA PRZEDMIOTU. 1. Informacje ogólne. 2. Ogólna charakterystyka przedmiotu. Inżynieria oprogramowania, C12
KARTA PRZEDMIOTU 1. Informacje ogólne Nazwa przedmiotu i kod (wg planu studiów): Nazwa przedmiotu (j. ang.): Kierunek studiów: Specjalność/specjalizacja: Poziom kształcenia: Profil kształcenia: Forma studiów:
Podstawy modelowania programów Kod przedmiotu
Podstawy modelowania programów - opis przedmiotu Informacje ogólne Nazwa przedmiotu Podstawy modelowania programów Kod przedmiotu 11.3-WI-INFP-PMP Wydział Kierunek Wydział Informatyki, Elektrotechniki
Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, Zofia Kruczkiewicz
Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004 Zofia Kruczkiewicz 1. Przedstaw znaczenie oprogramowania we współczesnym świecie. x 3 2. Jaki wpływ na ludzi, komunikację
Interbase. stacjonarne (stacjonarne / niestacjonarne) kierunkowy (podstawowy / kierunkowy / inny HES)
Załącznik nr 7 do Zarządzenia Rektora nr../12 z dnia.... 2012r. KARTA MODUŁU / KARTA PRZEDMIOTU Kod modułu Nazwa modułu Interbase Nazwa modułu w języku angielskim Obowiązuje od roku akademickiego 2012/2013
Podrozdziały te powinny zawierać informacje istotne z punktu widzenia przyjętego celu pracy
Uwaga: 1. Praca powinna być napisana z użyciem formy bezosobowej np. wykonano. Nazwa rozdziału Zawartość Liczba stron 1. Wstęp Rozdział ten powinien zawierać zarys najważniejszych elementów pracy Krótki
Modelowanie obiektowe - Ćw. 3.
1 Modelowanie obiektowe - Ćw. 3. Treść zajęć: Diagramy przypadków użycia. Zasady tworzenia diagramów przypadków użycia w programie Enterprise Architect. Poznane dotychczas diagramy (czyli diagramy klas)
Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON
Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Opis szkoleń z obszaru INFORMATYKA planowanych
Inżynieria oprogramowania (Software Engineering)
Inżynieria oprogramowania (Software Engineering) Wykład 2 Proces produkcji oprogramowania Proces produkcji oprogramowania (Software Process) Podstawowe założenia: Dobre procesy prowadzą do dobrego oprogramowania
1. CEL BADAŃ 2. METODYKA BADAŃ 2.1. ORGANIZACJA BADAŃ
1. CEL BADAŃ Celem głównym ewaluacji jakości kształcenia jest diagnoza i ocena jakości procesu dydaktycznego realizowanego przez nauczycieli akademickich, wspieranego przez pracowników wszystkich komórek
PRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: Bazy danych Database Kierunek: Rodzaj przedmiotu: obieralny Rodzaj zajęć: wykład, laboratorium Matematyka Poziom kwalifikacji: I stopnia Liczba godzin/tydzień: 2W, 2L Semestr: III Liczba
Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji
Analiza i programowanie obiektowe 2016/2017 Wykład 6: Projektowanie obiektowe: diagramy interakcji Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Przejście
Inżynieria oprogramowania - opis przedmiotu
Inżynieria oprogramowania - opis przedmiotu Informacje ogólne Nazwa przedmiotu Inżynieria oprogramowania Kod przedmiotu 11.3-WK-IiED-IO-W-S14_pNadGenRB066 Wydział Kierunek Wydział Matematyki, Informatyki
Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34
Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych
Język UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)
Bazy danych i ich aplikacje
ORAZ ZAPRASZAJĄ DO UDZIAŁU W STUDIACH PODYPLOMOWYCH Celem Studiów jest praktyczne zapoznanie słuchaczy z podstawowymi technikami tworzenia i administrowania bazami oraz systemami informacyjnymi. W trakcie
Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.
Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,
Efekt kształcenia. Ma uporządkowaną, podbudowaną teoretycznie wiedzę ogólną w zakresie algorytmów i ich złożoności obliczeniowej.
Efekty dla studiów pierwszego stopnia profil ogólnoakademicki na kierunku Informatyka w języku polskim i w języku angielskim (Computer Science) na Wydziale Matematyki i Nauk Informacyjnych, gdzie: * Odniesienie-
Przegląd modułów systemu POL-on
Przegląd modułów systemu POL-on dr Piotr Rodzik ekspert systemu Ośrodek Przetwarzania Informacji - Państwowy Instytut Badawczy Al. Niepodległości 188B, 00-608 Warszawa Numer KRS: 0000127372 Sąd Rejonowy
INŻYNIERIA OPROGRAMOWANIA
INSTYTUT INFORMATYKI STOSOWANEJ 2013 INŻYNIERIA OPROGRAMOWANIA Inżynieria Oprogramowania Proces ukierunkowany na wytworzenie oprogramowania Jak? Kto? Kiedy? Co? W jaki sposób? Metodyka Zespół Narzędzia
Zakres wykładu. Podstawy InŜynierii Oprogramowania
Zakres wykładu Pojęcia podstawowe InŜynierii Oprogramowania Proces wytwarzania oprogramowania Artefakty procesu wytwarzania i ich modele Jakość oprogramowania Literatura: [1] Sacha K., InŜynieria oprogramowania,
Uniwersytet Warszawski Wydział Matematyki, Informatyki i Mechaniki. Paweł Parys. Nr albumu: 209216. Aukcjomat
Uniwersytet Warszawski Wydział Matematyki, Informatyki i Mechaniki Paweł Parys Nr albumu: 209216 Aukcjomat Praca licencjacka na kierunku INFORMATYKA w zakresie INFORMATYKA Praca wykonana pod kierunkiem
Uchwała Nr 59/2016/IX Senatu Politechniki Lubelskiej z dnia 15 grudnia 2016 r.
Uchwała Nr 59/2016/IX Senatu Politechniki Lubelskiej z dnia 15 grudnia 2016 r. w sprawie określenia efektów kształcenia dla studiów podyplomowych Grafika komputerowa w technice i reklamie prowadzonych
ZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH
ZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH ZSE - Systemy baz danych 2 rzeczywistość uzyskanie od użytkowników początkowych informacji i wymagań dotyczących przetwarzania danych analiza
Projektowanie interakcji
Projektowanie interakcji K2 User Experience www.k2.pl/ux Tytuł dokumentu: k2-projektowanie_ux-oferta.pdf Data: 21 sierpnia 2009 Przygotowany przez: Maciej Lipiec Maciej Lipiec User Experience Director
Dyrektor szkoły Rodzice (lub prawni opiekunowie) Nauczyciele i specjaliści Sposób prezentacji procedur: Tryb dokonywania zmian w procedurze:
Procedury współpracy ze specjalistami w zakresie udzielania pomocy psychologiczno--pedagogicznej w Zespole Szkół Specjalnych im. Jana Pawła II w Grajewie Cel Procedura została opracowana w celu doprecyzowania
Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?
ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest
KIERUNKOWE EFEKTY KSZTAŁCENIA
KIERUNKOWE EFEKTY KSZTAŁCENIA WYDZIAŁ INFORMATYKI I ZARZĄDZANIA Kierunek studiów: INFORMATYKA Stopień studiów: STUDIA II STOPNIA Obszar Wiedzy/Kształcenia: OBSZAR NAUK TECHNICZNYCH Obszar nauki: DZIEDZINA