Inżynieria Oprogramowania Lecture 1 PDF

Inżynieria Oprogramowania 04.10.2024 Wstęp Dr inż. Katarzyna Wasielewska-Michniewska Kontakt: [email protected] MS Teams -> zostanie utworzony zespół (slajdy z wykładów będą wygrywane) Możliwo...

Inżynieria Oprogramowania 04.10.2024 Wstęp Dr inż. Katarzyna Wasielewska-Michniewska Kontakt: [email protected] MS Teams -> zostanie utworzony zespół (slajdy z wykładów będą wygrywane) Możliwość konsultacji na MiNI: piątki 10:00-18:00 Zasady zaliczenia Wykład 40 pkt - końcowy test wielokrotnego wyboru Projekt 60 pkt - zasady zaliczenia zostaną przedstawione na zajęciach projektowych Do zaliczenia wymagane jest min 50% z wykładu i projektu Skala ocen: ○ 91 i więcej - 5 ○ 81-90 - 4.5 ○ 71-80 - 4 ○ 61-70 - 3.5 ○ 51-60 - 3 ○ 50 i mniej - 2 Czym jest inżynieria oprogramowania? Proces projektowania, rozwijania, testowania i utrzymywania oprogramowania przy użyciu dobrze zdefiniowanych zasad, metod i procedur. Definicja IEEE: 1. Stosowanie systematycznego, zdyscyplinowanego i wymiernego podejścia do tworzenia, obsługi i utrzymania oprogramowania; co oznacza zastosowanie inżynierii do oprogramowania. 2. Badanie podejść w odniesieniu do powyższego stwierdzenia. Jaka jest różnica pomiędzy inżynierią oprogramowania a rozwojem oprogramowania (ang. software development)? Software paradigm Software development Vestibulum congue Software design Vestibulum congue Programming Dlaczego potrzebujemy IO? Coraz bardziej skomplikowane systemy: integracje, interakcje, modularność, procesy,... Większe zespoły ze skomplikowaną strukturą Unikanie chaotycznych plac deweloperskich Coraz trudniejsze śledzenie postępu, zakresu, oceny ryzyka dla projektów Rotacja deweloperów - praca na “cudzym” kodzie Projekty żyją dłużej niż zespoły Potrzebujemy: Ustandaryzowanej komunikacji Procedur, praktyk do powielania Skalowanych i adaptowalnych podejść do realizacji Czym jest dobre oprogramowanie? Operacyjność Przejściowość ○ Reliability - niezawodność ○ Interoperability - ○ Integrity - integralność interoperacyjność ○ Correctness - poprawność ○ Usability - użyteczność ○ Reusability - reużywalność ○ Efficiency - wydajność ○ Portability - przenaszalność ○ Functionality - funkcjonalność ○ Adaptability - zdolność adaptacji ○ Security - bezpieczeństwo ○ Safety - bezpieczeństwo Utrzymanie ○ Scalability - skalowalność Depending on the project different ○ Flexibility - elastyczność features may have different importance. ○ Testability - testowalność ○ Extensibility - rozszerzalność ○ Modularity - modularność Kto może zyskać na stosowaniu Inżynierii Oprogramowania? Plan wykładów 1. Wprowadzenie, zasady 2. Cykl życia projektu IT, powiązane procesy i role funkcyjne 3. Zbieranie i analiza wymagań 4. Narzędzia i techniki do wsparcia analizy systemu: UML, User stories, FURPS, BPMN 5. Software Development Frameworks 6. Narzędzia i techniki do zarządzania kodem 7. Zasady tworzenia dobrego oprogramowania 8. Architektury oprogramowania 9. Wzorce projektowe 10. Zarządzanie jakością oprogramowania 11. Testowanie 12. Skrzynka z narzędziami: git, gitflow, continuous integration, bugtracking, profiling,... 13. Utrzymanie oprogramowania Literatura dodatkowa Unified Modelling Language 2.5.1 Software Requirements. Karl Wiegers and Joy https://www.omg.org/spec/UML/2.5.1 Beatty. Business Process Management and Notation Team roles at work. Meredith Belbin. https://www.omg.org/spec/BPMN/2.0/ Inżynieria wymagań w praktyce. Bartosz Chrabski SOLID Design Principles by Uncle Bob i Karolina Zmitrowicz Clean Code. Robert Martin Zrozumieć BPMN modelowanie procesów Clean Architecture. Robert Martin biznesowych. Szymon Drejewicz Manifesto for Agile Software Development Analiza biznesowa. Praktyczne modelowanie organizacji. Jarosław Żeliński The Scrum Guide UML Distilled. A brief guide to standard object IBM Rational Unified Process modelling language. Martin Fowler Cele Poznać metody i wiedzieć do czego są wykorzystywane Poznać narzędzia i techniki Zrozumieć proces tworzenia oprogramowania Nauka najlepszych praktyk Wiedza czego szukać w razie problemów w przyszłości Cykl życia projektu Initiating Groundwork necessary to create Closing and define the project, usually 03 05 Releasing resources, documenting on the organizational level: lessons learnt. feasibility study, funding, initial scope statement, identification of stakeholders 01 04 Monitoring and controlling Ensuring that project Planning PMI deliverables are on time, on Project Management Plan budget and of acceptable covering all aspects of project quality. execution is defined and accepted. 01 02 02 03 Executing Deliverables are produced.  Software development lifecycles (SDLC) Requirements gathering Proposed architecture (modules, In fact this is done in all stages Risks identification communication, data flows,...) Defects identification, reporting, tracking Meetings with stakeholders Design Document Specification Monitoring quality standards Resource allocation Development according to guidelines Software Requirements Specification - Development according to guidelines Maintenance? preparation and acceptance Different variations: Waterfall, Iterative, Spiral, V-Model, Big Bang SDLC - Waterfall Proces tworzenia oprogramowania jest podzielone na etapy Wyjście z jednego etapu stanowi wejście do kolejnego sekwencyjnie Source: https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm SDLC - Iterative Tworzenie oprogramowania w powtarzalnych cyklach w krótszych odstępach czasu (przyrostowo) Implementacja podzbioru wymagań i iteracyjne ulepszanie ewoluujących wersji dopóki pełna funkcjonalność nie zostanie zaimplementowana Source: https://www.tutorialspoint.com/sdlc/sdlc_iterative_model.htm SDLC - Spiral Model spiralny ma 4 fazy: identyfikacja, projekt, budowanie, ewaluacja i ocena ryzyka. Oprogramowanie powtarzalnie przechodzi przez te fazy w iteracjach zwanych spiralami. Source: https://www.tutorialspoint.com/sdlc/sdlc_spiral_model.htm SDLC - V-Model Verification and Validation model Realizacja procesów odbywa się sekwencyjnie w kształcie litery V Dla każdej fazy cyklu rozwojowego istnieje bezpośrednio powiązana faza testowania Source: https://www.tutorialspoint.com/sdlc/sdlc_v_model.htm SDLC - Big Bang Nie jest przestrzegany żaden konkretny proces Wymagane bardzo niewielkie planowanie Wszystkie zasoby skupione na rozwoju oprogramowania Benefity SDLC Większa widoczność procesu rozwoju dla wszystkich interesariuszy Efektywne szacowanie, planowanie i harmonogramowanie Lepsze zarządzanie ryzykiem i szacowanie kosztów Systematyczne dostarczanie oprogramowania i większa satysfakcja klientów Kto jest potrzebny? Role funkcyjne: Z każdą rolą powiązana Analityk Biznesowy jest inna wiedza, priorytety i oczekiwania Architekt Deweloper Tester Zespół wdrożeniowy Administrator Sponsor projektu Menadżer projektu Właściciel Produktu Zespół sprzedaży i marketingu Gdzie możemy zastosować inżynierię oprogramowania? Dlaczego potrzebujemy inżynierii oprogramowania? Metafora huśtawki Metafora huśtawki 9 Belbin team roles - https://www.belbin.com/about/belbin-team-roles 1. The Monitor Evaluator (thought-oriented) 2. The Specialist (thought-oriented) 3. The Plant (thought-oriented) 4. The Shaper (action-oriented) 5. The Implementer (action-oriented) 6. The Completer/Finisher (action-oriented) 7. The Coordinator (people-oriented) 8. The Team Worker (people-oriented) 9. The Resource Investigator (people-oriented) Jak używać teorii Balbin? Zespół składający się z członków o podobnych stylach zachowań i tendencjach w miejscu pracy może utracić równowagę Mieszanka osobowości i umiejętności do pełnienia różnych ról funkcjonalnych Maksymalizacja wydajności zespołów poprzez rozważenie mocnych i słabych stron każdej osoby Rozwój i coaching istniejących zespołów