Języki i metodyka oprogramowania
|
|
- Tadeusz Murawski
- 8 lat temu
- Przeglądów:
Transkrypt
1 Języki i metodyka oprogramowania Automatyka i Robotyka sem.2 (część I) Rok akademicki 2010/2011 Dr inż. Wojciech Koziński Literatura A. Januszkiewicz. Inżynieria oprogramowania. Helion W. Dąbrowski, A. Stasiak, M. Wolski. Modelowanie systemów informatycznych w języku UML2.1. PWN S.A G. Booch, J.Rumbaugh, I.Jacobson. UML przewodnik użytkownika. WNT 2001, (Seria: inżynieria oprogramowania). F. P. Brooks: The Mythical Man-Month. Addison Wesley Publishing Company (Anniversary Addition) (jest polskie tłumaczenie). J. Hunt. The Unified Process for Practitioners. Object Oriented Design, UML and Java. Springer, JIMO 2010/ Kariera zawodowa Kariera zawodowa w informatyce: Programista (tester), Projektant (projektant testów), Analityk. Kierownik (osoba zarządzająca): Zadaniem, Projektem (coraz większym). JIMO 2010/
2 Inżynieria oprogramowania a dobre oprogramowanie Inżynieria oprogramowania jako nauka praktyczna mówiąca o sposobie (metodyce) tworzenia dobrego oprogramowania. Cechy dobrego oprogramowania: Zgodne z wymaganiami użytkownika, Niezawodne, Efektywne, Łatwe w konserwacji, Ergonomiczne. JIMO 2010/ Dobre oprogramowanie Dlaczego jest trudno zrobić dobre oprogramowanie? Duża złożoność systemów informatycznych. Niepowtarzalność poszczególnych przedsięwzięć. Nieprzejrzystość procesu budowy oprogramowania (trudność w ocenie stopnia zaawansowania prac). Co to znaczy, że prace są zaawansowane w 90%? Jak mierzyć postęp w realizacji przedsięwzięcia? Pozorna łatwość wytwarzania produktu i dokonywania poprawek (1 dzień 100 linii, 10 dni 1000 linii, 100 dni linii, 10 osób razy 100 dni linii). JIMO 2010/ Inżynieria oprogramowania Inżynieria oprogramowania opisuje między innymi: Sposoby prowadzenia przedsięwzięć informatycznych, Techniki planowania, szacowania kosztów, harmonogramowania i monitorowania przedsięwzięć informatycznych, Metody analizy i projektowania systemów, Techniki zwiększania niezawodności oprogramowania, Sposoby testowania systemów i szacowania niezawodności, Sposoby przygotowania dokumentacji technicznej i użytkowej, Procedury kontroli jakości, Metody redukcji kosztów konserwacji (usuwania błędów, modyfikacji i rozszerzeń), Techniki pracy zespołowej i czynniki psychologiczne wpływające na efektywność pracy. JIMO 2010/
3 Modele cyklu życia oprogramowania Model kaskadowy, Realizacja sterowana dokumentami (ang. document driven). Prototypowanie, Programowanie odkrywcze, Realizacja przyrostowa, Montaż z gotowych elementów, Model spiralny. JIMO 2010/ Strategia, Cykl życia oprogramowania (fazy) Model wodospadowy Określenie wymagań. Analiza (modelowanie). Projektowanie. Implementacja. Dokumentacja (produkcyjna, użytkownika). Testowanie. Instalacja, szkolenie. Konserwacja oprogramowania. JIMO 2010/ Narzędzia wspomagające Narzędzia wspomagające tworzenie oprogramowania (narzędzia CASE): Do zarządzania całym cyklem życia (OracleCASE, RUP - IBM). Do analizy i projektowania z wykorzystaniem UML, (Posejdon, wtyczki do NetBeans, Eclipse). Do kodowania, uruchamiania, testowania (Eclipse, NetBeans, JBuilder). Rozwój graficznych metod tworzenia oprogramowania, aż do pełnej generacji kodu. JIMO 2010/
4 Podstawowe wiadomości o UML (Unified Modelling Language) Diagramy (rysunki) tworzące model systemu. Do diagramów konieczne są definicje, opisy, słowniki. Zespół diagramów daje całkowity opis systemu (miejmy nadzieję). UML jest językiem przeznaczonym do: Wizualizacji, Specyfikacji, Opisu, Dokumentacji oprogramowania. JIMO 2010/ UML podstawowe diagramy Diagram przypadków użycia (ang. use case diagram), Diagram klas (ang. class diagram), Diagram obiektów (ang. object diagram), Diagram działania (ang. activity diagram), Diagram sekwencji (ang. sequence diagram), Diagram współpracy (ang. collaboration diagram), Diagram przejść stanów (ang. state charts), Diagram składowych (ang. component diagram) Diagram rozmieszczenia (ang. deployment diagram). JIMO 2010/ Tradycyjny sposób tworzenia oprogramowania Projekt przebiega według modelu wodospadowego, w kolejności wykonując wymagania, analizę, projekt, implementację, a następnie utrzymując system. Projekt ma tylko jeden cykl. Projekt ma tylko jedną iterację w jednym kroku (przykładowo w analizie). JIMO 2010/
5 Wada tradycyjnego sposobu wytwarzania oprogramowania Podstawowym problemem (wadą) modelu kaskadowego (wodospadowego) jest to, że wymagania są analizowane raz, powinny być więc dobrze zdefiniowane na początku. W takim procesie nie ma miejsca na zmiany w wymaganiach, czyli odbiorca może otrzymać produkt niedostosowany do zmienionych (w czasie budowy systemu) warunków. JIMO 2010/ Podstawowe wiadomości o Rational Unified Process (RUP). Hierarchiczna struktura RUP Cykle (ang. Cycles) Fazy (ang. Phases) Iteracje (ang. Iterations) Prace (ang. Workflows) Czynności (ang. Activities) Cztery fazy RUP Inception -> Elaboration -> Construction -> Transition JIMO 2010/ Rational Unified Process (RUP) Inception - Definiuje zakres projektu i cel tego przedsięwzięcia w terminach biznesowych. Określa możliwość wykonania projektu (ang. feasibility). Elaboration - Opisuje i analizuje wymagania funkcjonalne, specyfikuje wymagania niefunkcjonalne, ustala podstawową architekturę systemu. Construction - Wytworzenie produktu (systemu). Transition - Przeniesienie produktu do środowiska produkcyjnego. JIMO 2010/
6 Rational Unified Process (RUP) JIMO 2010/ Rational Unified Process (RUP) JIMO 2010/ Rational Unified Process (RUP) Inception (olśnienie, pomysł). Faza ta koncentruje się na wygenerowaniu opisu z punktu widzenia potrzeb użytkownika (business case), oceny czy jest to wykonalne i opłacalne. Zdefiniowane są tu przypadki użycia, zakres działania systemu, a także nowe, ryzykowne bądź trudne elementy systemy, mogące mieć wpływ na końcowy sukces. W fazie tej powstaje koncepcja architektury (na najwyższym poziomie), dla oceny stopnia komplikacji. Należy też ocenić wykonalność projektu oraz oszacować nakłady czasu, siły roboczej, finansowe. Podstawową pracą są tu prace nad wymaganiami, jednakże by rzetelnie ocenić architekturę konieczne są pewne prace analityczne, projektowe, a nawet implementacyjne. Podstawowym pytaniem jest jednak wykonalność przedsięwzięcia. JIMO 2010/
7 Rational Unified Process (RUP) Elaboration (podstawowa architektura zarys systemu) Podstawowym zadaniem tej fazy jest zrozumienie (i formalne zapisanie) jak wymagania przekładają się na podstawową architekturę systemu i jak mogą przebiegać dalsze prace. Wszystkie przypadki użycia powinny być dokładnie opisane. Zidentyfikowane powinny być elementy obarczone ryzykiem (nieznane). Powinny one być opracowane jako pierwsze w następnej fazie (construction). Rozważeniu powinny podlegać też zagadnienia związane z niezawodnością oraz szybkością działania. Odpowiednio wysokie wymagania mogą mieć istotny wpływ na architekturę systemu. W fazie tej powinna być zaprojektowana, zaimplementowana i przetestowana przewidywana architektura systemu. Jak w każdej fazie powinny być określone elementy o najwyższym ryzyku (najwyższej trudności). JIMO 2010/ Rational Unified Process (RUP) Construction (w pełni funkcjonalna wersja beta) Produktem końcowym tej fazy jest w pełni funkcjonalna wersja beta systemu. Może ona zawierać pewne błędy, wymagać pewnych niedużych poprawek. Poprawki te nie powinny zmieniać podstawowej funkcjonalności. Powodzenie tej fazy zależy głównie od rozwiązania problemów wykrytych we wcześniejszych fazach. Faza ta zawiera prace głownie projektowe i implementacyjne, chociaż prace nad wymaganiami i analityką są dopuszczalne. JIMO 2010/ Rational Unified Process (RUP) Transition (produkt końcowy - wersja produkcyjna) Faza ta zaczyna się instalacji beta wersji systemu, uzyskaniu opinii użytkownika i wprowadzeniu żądanych zmian i usprawnień. Mogą być tu prowadzone prace projektowe i implementacyjne. Faza ta kończy się oddaniem wersji produkcyjnej systemu. JIMO 2010/
8 Rational Unified Process (RUP) Faza (ang. Phase) Czas trwania Zużycie zasobów Inception 10-20% 5-10% Elaboration 30-40% 20-25% Construction 40-50% 60-65% Transition 5-10% 5-10% JIMO 2010/ Rational Unified Process (RUP) Liczby iteracji dla projektu o średnim stopniu złożoności: Inception. Jedna iteracja, składająca się głównie z prac nad wymaganiami. Elaboration. Dwie iteracje, pierwsza identyfikująca przypadki użycia i zarys architektury, druga uszczegółowiająca przyjętą architekturę. Construction. Trzy, cztery lub pięć iteracji w zależności od wykrytych zagrożeń i złożoności systemu. Każda z iteracji zawiera prace projektowe, implementacyjne i testowanie. Mogą też wchodzić prace analityczne (wprowadzanie zmian). Transition. Jedna lub dwie iteracje w zależności od sukcesu wersji beta. JIMO 2010/ Metodyka SCRUM SCRUM to iteracyjny, przyrostowy sposób budowy/rozwoju produktu. Po każdej iteracji powinien powstać produkt o nowej funkcjonalności, gotowy do przekazania zamawiającemu. Cechy charakterystyczne metodyki SCRUM: SCRUM jest zwinną metodyką zarządzania produkcją oprogramowania, SCRUM obejmuje (zawiera) istniejące (stosowane) metodyki, SCRUM jest metodyką dla zespołu wytwarzającego produkt, którego wymagania zmieniają się gwałtownie, SCRUM jest procesem, który uwzględnia i rozwiązuje konfliktowe sytuacje, SCRUM jest sposobem na poprawę komunikacji w zespole i osiągnięcie dobrej współpracy. SCRUM jest sposobem na eliminację przeciwności w procesie tworzenia produktu. SCRUM jest sposobem zwiększenia produktywności zespołu, SCRUM jest skalowany, od pojedynczych produktów do całych organizacji, SCRUM powoduje, że każdy członek zespołu czuje się przydatny. JIMO 2010/
9 Metodyka SCRUM JIMO 2010/ Zarządzanie metodyką SCRUM JIMO 2010/ Metodyka SCRUM i extreme programmning JIMO 2010/
10 Obiektowy sposób myślenia Języki programowania, rys historyczny kod maszynowy, języki asemblera, języki wysokiego poziomu, języki generacyjne. Programowanie strukturalne i obiektowe. Obiektowy sposób myślenia ang. object - oriented analysis, design, programming (OOA - OOD OOP) JIMO 2010/ Wymagania przypadki użycia (ang. use cases) Wyniki zastosowania przypadków użycia to: Opis wszystkich interakcji z systemem, Aktorzy, którzy współdziałają z systemem, Inne artefakty (takie jak GUI i wymagania niefunkcjonalne). Podstawowe czynności analizy przypadków użycia: Znaleźć i opisać aktorów występujących w systemie, Znaleźć wszystkie przypadki użycia, Właściwie opisać przypadki użycia, Opisać cały model przypadków użycia, Przygotować słownik terminów. JIMO 2010/ Przypadki użycia (przykład) JIMO 2010/
11 Przypadki użycia (przykład) JIMO 2010/ Przypadki użycia - aktor Aktor to cokolwiek, co współdziała (ma interakcję) z naszym systemem. Aktor nie reprezentuje konkretnego użytkownika, reprezentuje jedynie rolę użytkownika. Aktor może mieć dodatkowe cechy jak identyfikatory, dozwolone operacje, znaczniki (ang. tagged values), ograniczenia. JIMO 2010/ Przypadki użycia - aktor Aktor - jak go znaleźć trzeba poszukać odpowiedzi na pytania: Kto jest zainteresowany systemem? Kto potencjalnie będzie używał systemu? Kto będzie czerpał korzyści z działania systemu? Kto dostarcza informację do systemu? Kto otrzymuje informację z systemu? Kto pielęgnuje informację w systemie? Gdzie jest miejsce systemu w organizacji? JIMO 2010/
12 Przypadki użycia Reguły, które muszą być spełnione przy poszukiwaniu aktorów: Zawsze powinien być przynajmniej jeden użytkownik dla każdego aktora. Role poszczególnych aktorów powinny być rozłączne. Przypadki użycia specyfikują sekwencję akcji z wariantami, które system może wykonać i które w rezultacie dają wymierny (obserwowalny) rezultat dla aktora. JIMO 2010/ Przypadki użycia Przypadki użycia zawierają (opisują): Sekwencję wykonywanych akcji, Opcjonalny zbiór jednej lub wielu alternatywnych sekwencji akcji, Krótką definicję przyczyny przypadku użycia, Sposób komunikacji z jednym lub wieloma aktorami, Ograniczenia w użyciu. JIMO 2010/ Przypadki użycia Przypadki użycia i sposób ich zidentyfikowania. Zbiór wszystkich przypadków użycia definiuje funkcjonalność systemu i stanowi postawę do ustalenia testów końcowych (!). Identyfikacja przypadków użycia bazuje na identyfikacji aktorów. Każdy aktor musi posiadać przynajmniej jeden przypadek użycia. JIMO 2010/
13 Przypadki użycia W identyfikacji przypadków użycia pomocne mogą być odpowiedzi na pytania: Jakie są główne zadania każdego aktora? Czy aktor zapisuje, odczytuje lub zmienia informację w systemie? Czy rozpatrywany przypadek użycia powoduje utworzenie, zapamiętanie, zmianę, usunięcie, odczytanie informacji? Dla każdego aktora: Czy aktor ma informować system o zmianach na zewnątrz? Czy aktor chce być informowany o zmianach na zewnątrz? Czy przypadki użycia zawierają utrzymanie systemu? Czy wszystkie wymagania funkcjonalne dla systemu są zawarte w aktualnych przypadkach użycia? JIMO 2010/ Przypadki użycia Nazwy przypadków użycia muszą mieć znaczące nazwy. Do poprawnego zidentyfikowania przypadków użycia pomocne są techniki: Wywiadów z aktualnymi lub przyszłymi użytkownikami systemu, Tablice poglądowe (rysunki w dużej skali), Seminaria połączone z burzą mózgów nad możliwymi scenariuszami zdarzeń w systemie. JIMO 2010/ Przypadki użycia Zdarzenia w przypadkach użycia: Warunki wstępne do użycia przypadku (logowanie). Kiedy i jak przypadek zaczyna się i kończy się? Jakie interakcje przypadku użycia występują z aktorami? Jakie dane są potrzebne do przypadku użycia? Jaki jest normalny ciąg (sekwencja zdarzeń)? Jakie są sekwencje alternatywne bądź związane z obsługą wyjątków? Jakie są warunki po zakończeniu przypadku użycia? JIMO 2010/
14 Przypadki użycia Doskonalenie modeli przypadków użycia. Model nie powinien być zbyt mały bądź zbyt obszerny. Celem jest zrozumiałość modelu. Model powinien być kompletny i zwarty. Nie powinien odwoływać się do dodatkowego materiału, by móc określić jego funkcjonalność. Przypadki użycia powinny dostarczać wartość dodatkową dla użytkowników systemu (aktorów). Każdy przypadek użycia musi być skojarzony z przynajmniej jednym aktorem. Przypadek użycia bez aktora nigdy nie będzie użyty. JIMO 2010/ Przypadki użycia Słowniki (konieczne definicje). Opisy (konieczne objaśnienia), Projekty interfejsów : Interfejsy graficzne z użytkownikiem (GUI), dla języka Java pakiet Swing, Interfejsy z innymi systemami (budowane na zamówienie specyfikacja). Interfejsy oparte na standardach wymiany informacji (np. XML, webmethods). JIMO 2010/
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
Bardziej szczegółowoBłę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
Bardziej szczegółowoOpis 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
Bardziej szczegółowoPRZEWODNIK 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
Bardziej szczegółowoRational Unified Process. Dokładny opis metodyki i procesu produkcji oprogramowania
Rational Unified Process Dokładny opis metodyki i procesu produkcji oprogramowania Rational Unified Process (RUP). RUP jest iteracyjnym procesem rozwoju oprogramowania. Definiuje szkielet postępowania,
Bardziej szczegółowoEtapy ż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
Bardziej szczegółowoNazwa 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:
Bardziej szczegółowoEtapy ż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
Bardziej szczegółowoZasady 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
Bardziej szczegółowoCo 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
Bardziej szczegółowoSVN. 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
Bardziej szczegółowoZakres 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,
Bardziej szczegółowoPRZEWODNIK 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.
Bardziej szczegółowoKARTA 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
Bardziej szczegółowoRUP. Rational Unified Process
RUP Rational Unified Process Agenda RUP wprowadzenie Struktura RUP Przepływy prac w RUP Fazy RUP RUP wprowadzenie RUP (Rational Unified Process) jest : Iteracyjną i przyrostową metodyka W pełni konfigurowalną
Bardziej szczegółowoModelowanie 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.
Bardziej szczegółowoCel 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
Bardziej szczegółowoUML 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ć
Bardziej szczegółowoWytwarzanie oprogramowania
AiPA 6 Wytwarzanie oprogramowania Proces tworzenia oprogramowania jest procesem przekształcenia wymagań w oprogramowanie zgodnie z metodyką, która określa KTO CO robi JAK i KIEDY. - Wymagania Proces tworzenia
Bardziej szczegółowoProgramowanie zespołowe
Programowanie zespołowe Laboratorium 4 - modele tworzenia oprogramowania, manifest Agile i wstęp do Scruma mgr inż. Krzysztof Szwarc krzysztof@szwarc.net.pl Sosnowiec, 14 marca 2017 1 / 21 mgr inż. Krzysztof
Bardziej szczegółowoAnaliza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32
Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:
Bardziej szczegółowoNarzę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
Bardziej szczegółowoOgólne określenie wymagań. Ogólny projekt. Budowa systemu. Ocena systemu. Nie. Tak. System poprawny. Wdrożenie. Określenie.
Inżynieria I Andrzej Jaszkiewicz Kontakt Andrzej Jaszkiewicz p. 8, CW Berdychowo tel. 66 52 933 ajaszkiewicz@cs.put.poznan.pl Rynek 2008 Świat 304 miliardy $ (451 miliardów 2013F) Bez wytwarzanego na własne
Bardziej szczegółowoWykł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
Bardziej szczegółowoFeature Driven Development
Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami
Bardziej szczegółowoMODELE CYKLU ŻYCIA OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś
OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś (często stosowany w praktyce do projektów o niewielkiej złożoności) wymagania specyfikowanie kodowanie
Bardziej szczegółowoUniwersytet 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
Bardziej szczegółowoIteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1
Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1 Zofia Kruczkiewicz 1 Zunifikowany iteracyjno- przyrostowy proces tworzenia oprogramowania kiedy? Przepływ działań Modelowanie przedsiębiorstwa
Bardziej szczegółowoTestowanie oprogramowania
Testowanie oprogramowania 1/17 Testowanie oprogramowania Wykład 01 dr inż. Grzegorz Michalski 13 października 2015 Testowanie oprogramowania 2/17 Dane kontaktowe: Kontakt dr inż. Grzegorz Michalski pokój
Bardziej szczegółowoZagadnienia (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
Bardziej szczegółowoInżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu
Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use
Bardziej szczegółowoIn ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania
In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania prowadzący: dr inż. Krzysztof Bartecki www.k.bartecki.po.opole.pl Proces tworzenia oprogramowania jest zbiorem czynności i
Bardziej szczegółowoInż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
Bardziej szczegółowoAnaliza 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,
Bardziej szczegółowoPodstawy 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.
Bardziej szczegółowoZofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2
Modelowanie i analiza systemów informatycznych 1. Warstwowa budowa systemów informatycznych 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wstęp do modelowania systemów
Bardziej szczegółowoWPROWADZENIE 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,
Bardziej szczegółowoPrzedsięwzięcia Informatyczne w Zarządzaniu
Przedsięwzięcia Informatyczne w Zarządzaniu 2005/06 dr inż. Grażyna Hołodnik-Janczura GHJ 1 LITERATURA 1. Praca zbiorowa p.r. Górski J., Inżynieria oprogramowania, MIKOM, W-wa, 2000 2. Jaszkiewicz A.,
Bardziej szczegółowoSpis 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...
Bardziej szczegółowoCykle życia systemu informatycznego
Cykle życia systemu informatycznego Cykl życia systemu informatycznego - obejmuję on okres od zgłoszenia przez użytkownika potrzeby istnienia systemu aż do wycofania go z eksploatacji. Składa się z etapów
Bardziej szczegółowoTestowanie i walidacja oprogramowania
i walidacja oprogramowania Inżynieria oprogramowania, sem.5 cz. 3 Rok akademicki 2010/2011 Dr inż. Wojciech Koziński Zarządzanie testami Cykl życia testów (proces) Planowanie Wykonanie Ocena Dokumentacja
Bardziej szczegółowoJarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming
Jarosław Kuchta Wymagania jakości w Agile Programming Wady klasycznych metod zapewnienia jakości Duży narzut na dokumentowanie Późne uzyskiwanie konkretnych rezultatów Trudność w odpowiednio wczesnym definiowaniu
Bardziej szczegółowoGrupa treści kształcenia, w ramach której przedmiot jest realizowany Przedmiot kierunkowy
SYLLABUS na rok akademicki 0113/014 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
Bardziej szczegółowoRozpoczęcie, inicjacja (ang. inception
Wydział Informatyki PB Analogia do budowanego domu Inżynieria oprogramowania II Wykład 2: Proces tworzenia oprogramowania (na podstawie Unified Process) Marek Krętowski pokój 206 e-mail: mkret@ii.pb.bialystok.pl
Bardziej szczegółowoEgzamin / 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
Bardziej szczegółowoNarzędzia informatyczne wspierające przedsięwzięcia e-commerce
Narzędzia informatyczne wspierające przedsięwzięcia e-commerce Zarządzanie projektami e-commerce, Meblini.pl, UE we Wrocławiu Wrocław, 11-03-2018 1. Cykl życia projektu 2. Pomysł / Planowanie 3. Analiza
Bardziej szczegółowoInżynieria oprogramowania II
Wymagania funkcjonalne, przypadki użycia Inżynieria oprogramowania II Problem i cel Tworzenie projektów bez konkretnego celu nie jest dobre Praktycznie każdy projekt informatyczny powstaje z uwagi na jakiś
Bardziej szczegółowoINŻ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
Bardziej szczegółowoDr Katarzyna Grzesiak-Koped
Dr Katarzyna Grzesiak-Koped 2 Tworzenie oprogramowania Najlepsze praktyki IO Inżynieria wymagao Technologia obiektowa i język UML Techniki IO Metodyki zwinne Refaktoryzacja Mierzenie oprogramowania Jakośd
Bardziej szczegółowoLaboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny
Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny mgr inż. Kajetan Kurus 15 kwietnia 2014 1 Dostępne techniki programowania Tworząc program należy
Bardziej szczegółowoWprowadzenie 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
Bardziej szczegółowoTematy 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ę
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 1: Wprowadzenie oraz cykl życia oprogramowania i faza określenia wymagań
Analiza i projektowanie obiektowe 2016/2017 Wykład 1: Wprowadzenie oraz cykl życia oprogramowania i faza określenia wymagań Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza
Bardziej szczegółowoAnaliza biznesowa a metody agile owe
Analiza biznesowa a metody agile owe P6S_WG01 ma wiedzę w zakresie metodyk zwinnych P6S_WG02 ma wiedzę w zakresie zwinnego gromadzenia i zarządzania wymaganiami P6S_WG03 zna i rozumie proces wytwarzania
Bardziej szczegółowoTematy 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 1 2. Jaki wpływ na ludzi, komunikację
Bardziej szczegółowoProjekt: 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
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas
Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy
Bardziej szczegółowoInżynieria oprogramowania I
Kontakt Inżynieria I Andrzej Jaszkiewicz Andrzej Jaszkiewicz p. 424y, Piotrowo 3a tel. 66 52 371 jaszkiewicz@cs.put.poznan.pl www-idss.cs.put.poznan.pl/~jaszkiewicz Literatura A. Jaszkiewicz, Inżynieria,
Bardziej szczegółowoDIAGRAM PRZYPADKÓW UŻYCIA USE CASE MODEL
Projektowanie Systemów Komputerowych Laboratoria/Projekty Krzysztof Regulski AGH, WIMiIP DIAGRAM PRZYPADKÓW UŻYCIA USE CASE MODEL 1) Zastosowanie Jedną ze stosowanych metodologii prowadzenia projektów
Bardziej szczegółowoAnalityk 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
Bardziej szczegółowoPRZEWODNIK 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
Bardziej szczegółowoInż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,
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej
Analiza i projektowanie obiektowe 2017/2018 Wykład 3: Model wiedzy dziedzinowej Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Model wiedzy dziedzinowej
Bardziej szczegółowoKATEDRA 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,
Bardziej szczegółowoProcesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania
Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania dr inż. Marcin Szlenk Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Wprowadzenie O mnie dr inż. Marcin
Bardziej szczegółowoKomputerowe 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
Bardziej szczegółowoINŻYNIERIA OPROGRAMOWANIA
INŻYNIERIA OPROGRAMOWANIA dr inż. Jerzy Sas e-mail: jerzy.sas@pwr.wroc.pl Wykład 1 (1) to zastosowanie systematycznego, zdyscypliniowanego ilościowego podejścia do prowadzenia projektu informatycznego
Bardziej szczegółowoMSF. Microsoft Solution Framework
MSF Microsoft Solution Framework MSF a PMI PMI - metodyka podobna dla każdego rodzaju projektów MSF metodyka przeznaczona dla projektów informatycznych mająca cechy PMI MSF metodyka utworzona na podstawie
Bardziej szczegółowoPytania z przedmiotów kierunkowych
Pytania na egzamin dyplomowy z przedmiotów realizowanych przez pracowników IIwZ studia stacjonarne I stopnia Zarządzanie i Inżynieria Produkcji Pytania z przedmiotów kierunkowych 1. Co to jest algorytm?
Bardziej szczegółowoMichał Adamczyk. Język UML
Michał Adamczyk Język UML UML I. Czym jest UML Po co UML II.Narzędzia obsługujące UML, edytory UML III.Rodzaje diagramów UML wraz z przykładami Zastosowanie diagramu Podstawowe elementy diagramu Przykładowy
Bardziej szczegółowoOceny z prezentacji INKU011S. Zofia Kruczkiewicz
Oceny z prezentacji INKU011S Zofia Kruczkiewicz Data Student Oceny Uwagi 22.10.2017 231085 3.0 Przedstaw idealne środowisko do stosowania inżynierii oprogramowania- opisz elementy tego środowiska (sprzęt
Bardziej szczegółowoKurs 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
Bardziej szczegółowoWykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych
Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław
Bardziej szczegółowoSpis 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.
Bardziej szczegółowoAnaliza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz
Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz Promotor dr inż. Szymon Supernak Warszawa, 22.05.2014 Plan prezentacji 1. Cel i
Bardziej szczegółowo1. 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
Bardziej szczegółowoInż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
Bardziej szczegółowoSTUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe
STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe Technologie informacyjne prof. dr hab. Zdzisław Szyjewski 1. Rola i zadania systemu operacyjnego 2. Zarządzanie pamięcią komputera 3. Zarządzanie danymi
Bardziej szczegółowoDiagram przypadków użycia
Diagram przypadków użycia Diagram przypadków użycia opisuje system z punktu widzenia użytkownika, pokazuje, co robi system, a nie jak to robi. Diagram ten sam w sobie zazwyczaj nie daje nam zbyt wielu
Bardziej szczegółowoAnaliza 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
Bardziej szczegółowoInż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
Bardziej szczegółowoRok akademicki: 2012/2013 Kod: IET-2-211-SW-s Punkty ECTS: 3. Kierunek: Elektronika i Telekomunikacja Specjalność: Systemy wbudowane
Nazwa modułu: Metodyki projektowania i modelowania systemów I Rok akademicki: 2012/2013 Kod: IET-2-211-SW-s Punkty ECTS: 3 Wydział: Informatyki, Elektroniki i Telekomunikacji Kierunek: Elektronika i Telekomunikacja
Bardziej szczegółowoREFERAT PRACY DYPLOMOWEJ
REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i implementacja środowiska do automatyzacji przeprowadzania testów aplikacji internetowych w oparciu o metodykę Behavior Driven Development. Autor: Stepowany
Bardziej szczegółowoKarta 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
Bardziej szczegółowoPodstawy 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
Bardziej szczegółowoKonfiguracja 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
Bardziej szczegółowoWykład 2. MIS-1-505-n Inżynieria oprogramowania Marzec 2014. Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie
Wykład 2 MIS-1-505-n Inżynieria Marzec 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 2.1 Agenda 1 2 3 4 5 6 2.2 Czynności w czasie produkcji. Inżynieria stara się zidentyfikować
Bardziej szczegółowoMetodyki programowania. Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl
Metodyki programowania Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl Wybrane metodyki zwinne TRADYCYJNE: RUP (Rational Unified Process) spiralny, rozbudowany PRINCE2 (Projects In Controlled Environments)
Bardziej szczegółowoProjektowanie 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
Bardziej szczegółowoWprowadzenie, podstawowe pojęcia, projekt a produkt Wykład1
Wprowadzenie, podstawowe pojęcia, projekt a produkt Wykład1 Zofia Kruczkiewicz 1 Literatura 1. Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004 2. Stephen H. Kan, Metryki i modele w
Bardziej szczegółowoPRZEWODNIK 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:
Bardziej szczegółowoRok akademicki: 2014/2015 Kod: IEL s Punkty ECTS: 5. Poziom studiów: Studia I stopnia Forma i tryb studiów: -
Nazwa modułu: Programowanie obiektowe Rok akademicki: 2014/2015 Kod: IEL-1-408-s Punkty ECTS: 5 Wydział: Informatyki, Elektroniki i Telekomunikacji Kierunek: Elektronika Specjalność: - Poziom studiów:
Bardziej szczegółowo<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0>
Wersja [Uwaga: Niniejszy wzór dostarczony jest w celu użytkowania z Unified Process for EDUcation. Tekst zawarty w nawiasach kwadratowych i napisany błękitną kursywą
Bardziej szczegółowoFaza Określania Wymagań
Faza Określania Wymagań Celem tej fazy jest dokładne określenie wymagań klienta wobec tworzonego systemu. W tej fazie dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia
Analiza i projektowanie obiektowe 2015/2016 Wykład 2: Przypadki użycia Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Czym są przypadki użycia. 2.
Bardziej szczegółowoInformatyczne 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
Bardziej szczegółowoKARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20
Z1-PU7 WYDANIE N2 Strona: 1 z 5 (pieczęć wydziału) KARTA PRZEDMIOTU 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA 3) Karta przedmiotu ważna od roku akademickiego: 2014/2015 2) Kod przedmiotu:
Bardziej szczegółowoProjektowanie 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
Bardziej szczegółowoModelowanie 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)
Bardziej szczegółowo