Inżynieria Oprogramowania - Wykład 2 PDF

Inżynieria Oprogramowania 11.10.2024 Czym jest Inżynieria Oprogramowania? Proces projektowania, rozwijania, testowania i utrzymywania oprogramowania przy użyciu dobrze zdefiniowanych zasad, metod i procedur. Inżyniera Oprogramowania vs Zarządzenie Proje...

Inżynieria Oprogramowania 11.10.2024 Czym jest Inżynieria Oprogramowania? Proces projektowania, rozwijania, testowania i utrzymywania oprogramowania przy użyciu dobrze zdefiniowanych zasad, metod i procedur. Inżyniera Oprogramowania vs Zarządzenie Projektem Dwie odrębne dyscypliny, które są ściśle ze sobą powiązane, ale mają różne cele, zadania i obowiązki. Inżynieria oprogramowania zajmuje się Zarządzanie projektami nie zajmuje się technicznymi aspektami związanymi z tworzeniem technicznymi aspektami tworzenia oprogramowania. Po zebraniu wymagań IO jest oprogramowania, ale koncentruje się na budowaniu przeznaczona do: i zarządzaniu całym procesem wykorzystywanym Projektowanie architektury do tworzenia oprogramowania. PM jest do: oprogramowania Zrozumienia wymagań Projektowanie oprogramowania Przygotowania planów wykonania prac Konwersja złożonej logiki/algorytmu na Szacowania kosztów, nakładu pracy, kod czasu trwania i zasobów wymaganych do Testowanie i debugowanie realizacji projektu oprogramowania Zarządzania wszystkimi powyższymi aspektami, aby doprowadzić projekt do końca Cykl życia zespołu High Forming Storming Norming Adjourning performance Formowanie Docieranie Normowanie Zakończenie Działanie Stworzenie zespołu i Konflikty pojawiają się, Negatywne aspekty Szczyt wydajności, w Zespół zaczyna się ustalenie podstawowych gdy członkowie zespołu zaczynają być którym zespół działa w rozpadać. Członkowie zasad. Początkowy dowiadują się więcej o odkładane na bok i synergii. zaczynają przenosić sobie nawzajem i o tym, entuzjazm, zapoznanie rozpoczyna się się do innych co należy zrobić. się z oczekiwaniami. współpraca w celu projektów. Ustanawiają się osiągnięcia rezultatu. Przeprowadzane są nieformalne Członkowie zaczynają oceny i tworzone są hierarchie/władza. czuć się jak zespół i plany przejść do Członkowie postrzegają zdają sobie sprawę, że nowych zadań. siebie bardziej jako mogą osiągnąć więcej jednostki niż zespół. pracy, jeśli mają Wyniki mogą być wspólny punkt bezproduktywne. widzenia. Po co rozmawiać z klientem? Kim jest “klient”? Użytkownik końcowy dla Analityka Biznesowego Analityk Biznesowy dla Architekta Architekt dla Programisty …. Komunikacja w zespole zależy od jego struktury. Musimy wiedzieć czego się od nas oczekuje oraz jak sprawdzić, że kryteria akceptacji zostały spełnione. Słaba komunikacja (lub błędna komunikacja) często powoduje niepotrzebne koszty i może prowadzić do niepowodzenia projektu. Dlaczego potrzebujemy efektywnej komunikacji? Inżynier oprogramowania zajmuje się nie tylko pisaniem kodu Funkcje oprogramowania nie są odizolowane – musimy zrozumieć interakcje i komunikować się z twórcami innych komponentów Funkcje oprogramowania należą do klienta lub użytkowników końcowych - musimy rozwiązać czyjś problem w najlepszy możliwy sposób Co oznacza efektywna komunikacja? Jasna i zwięzła komunikacja ma fundamentalne znaczenie dla sukcesu zespołów inżynierów oprogramowania. Zwięzłość – jakość ponad ilość Słuchaj uważnie – przeformułuj wypowiedź, aby potwierdzić zrozumienie, zanim zadasz pytanie Zadawaj pytania Zrozum wymagania – przeczytaj przed, w trakcie i po implementacji Omawiaj problem, a nie osobę Wybierz odpowiedni kanał komunikacji Wymagania dla oprogramowania - nie łatwe do ogarnięcia Jak zbierane są wymagania? Czy brane są pod uwagę potrzeby i priorytety interesariuszy? Czy to naprawdę jest poprawne wymaganie wobec oprogramowania? Czy rozważane są możliwe ograniczenia techniczne? Skąd wiadomo, kiedy wymaganie zostało zrealizowane? Czy realizacja wymagania spełnia ustalone kryteria? I tak dalej… Wymagania są „wspólne” i obsługiwane przez różne role w projekcie. Co musimy wiedzieć? Ustalanie wymagań Identyfikacja interesariuszy projektu jest ważna ze względu na ich wkład w wymagania projektu PM powinien zrównoważyć interesy interesariuszy, technologię i projekt (warunki rynkowe, wymagania, konkurencję itp.) Niedoprecyzowane projekty to strata czasu, talentu i pieniędzy -> projekt naprawdę zaczyna się, gdy wiadomo dokładnie, co będzie rezultatem Należy upewnić się, że projekt ma określony i możliwy do uzyskania efekt końcowy Gromadzenie wymagań Wymaganie (requirement) – skwantyfikowane i udokumentowane potrzeby i oczekiwania interesariuszy Wymagania wyznaczają zakres każdego projektu Nie zaleca się uwzględnienia w zakresie produktu większej liczby wymagań niż podane, dostarczenie czegokolwiek mniejszego niż wymagania określone przez użytkownika nie spełni jego oczekiwań Cecha (feature) to grupa wymagań funkcjonalnych, które razem spełniają konkretną potrzebę klienta Narzędzia wykorzystywane do zbierania wymagań: Burza mózgów, mapowanie myśli Technika Delphi Wywiady, grupy fokusowe, warsztaty fakultatywne i technika grupowania nominalnego Analiza dokumentów Analiza interfejsów, inżynieria odwrotna Obserwacja Prototypowanie Gdzie może być zaangażowany Inżynier Oprogramowania? Identyfikacja - zbieranie wymagań dotyczących oprogramowania Klasyfikacja - kategoryzacja wymagania Walidacja – potwierdzenie wymagania z interesariuszami Implementacja - budowanie oprogramowania pod kątem wymagań Negocjacje – radzenie sobie z możliwymi konfliktami interesów Weryfikacja - ocena, czy funkcja oprogramowania spełnia wymagania Skąd się biorą wymagania na oprogramowanie? przeprowadzanie wywiadów z interesariuszami przygotowywanie scenariuszy budowanie prototypów obserwacje w obszarze zainteresowań historie użytkownika (user stories) … Poziomy wymagań Wymagania wysokiego poziomu (high-level requirements) – są to stwierdzenia ogólne dotyczące wizji lub biznesu, zazwyczaj o charakterze ogólnym Wymagania na poziomie użytkownika (user-level requirements) - są to wymagania, które według użytkowników są absolutnie niezbędne, aby móc pomyślnie współdziałać z systemem Wymagania na poziomie systemu (system-level requirements) – często najbardziej szczegółowe; uwzględniane są czynniki tak szczegółowe, jak np. liczba i typ znaków w polu danych Klasyfikacja wymagań Business requirements – why the project is undertaken? e.g. high-level goals of the organisation or market needs Stakeholder requirements – needs of stakeholders, a bridge between business and solution requirements; not stating how they want these requirements to be implemented, they are simply stating what is required Solution requirements – features and functions of the product that meet business and stakeholder requirements; describe how the stakeholder wants to implement their stakeholder requirements ○ Functional - how the solution must behave, related to functionalities ○ Non-functional - characteristics that the solution should have e.g. scalability, security, performance, accessibility Transition requirements – related to transitioning from current state to desired future state e.g. deployment related Project requirements – related to actions and processes that the project must meet Quality requirements - criteria to validate the successful completion of a deliverable or fulfillment of requirements e.g. acceptance tests. Przykłady Business requirement: We would like to automate our customer relationship management system so that we can offer better customer services so that the customer response time improves by 70% in the next 6 months. Stakeholders requirement: We would like to have a mechanism to monitor the response time for each and every customer support request on a daily basis in order to improve the response time. The report should be generated daily, monthly or on on-demand basis. Functional Requirements: ○ Payment processing functionality ○ Tools and resources (PDF, infographics, courseware, spreadsheets) available for users, accessible via the resources landing page ○ The software system should be integrated with banking API Non-Functional Requirements: ○ SSL certificate ○ System is required to have 99% availability ○ Monthly scheduled maintenance should be less than 3h Common categories of transition requirements include: ○ Rollout activities ○ Data conversions ○ Training needs ○ Realignment of responsibilities in the user groups ○ etc. ○ The users must be trained to be able to use the system effectively ○ Previous years data must be migrated to the new system to generate comparative report  SMART For each goal, requirement, objective determine if they follow smart spell. Specific - what the specific requirements and deliverables are for your project Measurable - avoid vague terms like fast, good, and happy; measurable metrics for the project requirements are needed. Achievable - goals of the project should be achievable considering the resources, cost, and time required versus what’s available in the organization Relevant - goals of the project should support the primary business need of the organization, provide an opportunity for the company, or solve a problem (increase revenue or cut costs) Time-bound - requirements that are open-ended are not good to accurately plan and create Do czego potrzebne są wymagania? Planowanie implementacji -> zaprojektowanie funkcjonalności Weryfikacja i walidacja Planowanie testowania Podstawa do testów akceptacyjnych i odbiorów Wymagania służą jako referencyjne źródło wiedzy na temat tego, co ma zostać dostarczone. Wymagania wyrażają „umowę” między interesariuszami dotyczącą tego, co należy zrobić. Mapowanie wymagań Wymagania wysokiego poziomu dotyczące rozwiązania -> Zatwierdzone wymagania dotyczące oprogramowania -> Komponenty oprogramowania -> Testowanie akceptacyjne, czy dana funkcjonalność została zapewniona Requirements traceability matrix - dokument demonstrujący związek między wymaganiami a innymi artefaktami Jak opisać funkcjonalności systemu? Scenariusz Załóżmy, że mamy opisać funkcjonalności systemu USOS, m.in. związane z tworzeniem grafiku dla grup. Musimy odpowiedzieć na następujące pytania: Kto (osoba) lub co (inne oprogramowanie) będzie używać / wchodzić w interakcję z naszym systemem? Jakie są możliwości naszego systemu wystawione na działanie świata zewnętrznego? UML Use Case Diagram (Diagram Przypadków Użycia) Unified Modeling Language (UML) diagram przypadków użycia podsumowuje szczegóły dotyczące użytkowników systemu (zwanych aktorami) i ich interakcje z systemem. Pomaga reprezentować: Zakres systemu i wysoko-poziomowy przegląd systemu Scenariusze, w których system wchodzi w interakcję z ludźmi/systemami zewnętrznymi Cele, które system pomaga aktorom osiągnąć Wymagania funkcjonalne dla systemu Powinien skupiać się na „co”, a nie na „jak” Jednak: nie wchodzi w wiele szczegółów (tutaj przydatne są inne diagramy UML) diagramy UML = symbole i konektory UML Use Case Diagram notacja (1) Use case - horizontally shaped ovals that represent the different uses Actors - stick figures that represent the people/systems actually employing the use cases Associations - a line between actors and use cases System boundary box - a box that sets a system/module scope to use cases UML Use Case Diagram notacja (2) Relacje - modelowanie zależności pomiędzy dwoma przypadkami użycia: Extends - indicates that "Use Case 2" may include (subject to specified in the extension) the behavior specified by base "Use Case 1" Includes - indicates that an instance of the base “Use Case 1” will include the behavior as specified in the child use case “Use Case 2” Generalization - a parent-child relationship between use cases; the child “Use Case 2” is an enhancement of the parent “Use Case 1” Includes vs Extends Źródło: https://www.educative.io/answers/what-are-include-and-extend-relationships-in-a-use-case-diagram Przykład Jak zidentyfikować aktora? Kto korzysta z systemu? Kto instaluje system? Kto uruchamia system? Kto utrzymuje system? Kto zamyka system? Jakie inne systemy korzystają z tego systemu? Kto otrzymuje informacje z tego systemu? Kto dostarcza informacje do systemu? Czy coś dzieje się automatycznie w chwili obecnej? Source: https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-use-case-diagram/ Jak zidentyfikować przypadek użycia? Jakich funkcji aktor będzie oczekiwał od systemu? Czy system przechowuje informacje? Którzy aktorzy będą tworzyć, czytać, aktualizować lub usuwać te informacje? Czy system musi powiadamiać aktora o zmianach stanu wewnętrznego? Czy są jakieś zdarzenia zewnętrzne, o których system musi wiedzieć? Jaki aktor informuje system o tych zdarzeniach? Source: https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-use-case-diagram/ Opis Przypadku Użycia Nazwa (Name): Przypisanie profesora do grupy na zajęcia Opis (Description): Uprawniony podmiot przydziela profesora do wybranych zajęć Warunek wstępny (Precondition): Podmiot posiada token bezpieczeństwa i odpowiedni poziom uprawnień Warunek końcowy (Postcondition): Profesor jest przypisany do zajęć Sytuacja błędna (Error situation): Profesor jest niedostępny Ścieżka podstawowa: (1) podmiot wybiera zajęcia, (2) podmiot wybiera profesora z listy, (3) potwierdza się dostępność, (4) przypisuje profesora do zajęć … np. Ścieżki alternatywne Historyjki użytkowników (User stories) Historyjka użytkownika to naturalna reprezentacja interakcji określonego typu użytkownika z oprogramowaniem i funkcjonalnością, jaką powinno mu ono zapewniać. Zwykle ma format: As a , I want , so that Jako chcę , aby Przykłady: As a dean I want to create subjects so that students can learn something. As a schedule coordinator I want to create groups so that I can assign students and professors to it. As a schedule coordinator, I want to see the number of people enrolled in a course, so that I can see the current course capacity. Historyjki użytkownika Wykorzystywane w podejściu zwinnym Nieformalne, ogólne objaśnienie funkcji oprogramowania z perspektywy użytkownika Podkreślenie w jaki sposób praca przełoży się na korzyść dla klienta Korzyści: ○ Nacisk na użytkownika – skupienie się na rozwiązaniu problemu ○ Lepsza współpraca ○ Zachęcają do poszukiwania twórczych rozwiązań ○ Zwiększają poczucie satysfakcji z realizacji Jak napisać dobrą historyjkę? Co oznacza, że historyjka jest gotowa? Podział na zadania główne i podrzędne Persony użytkowników – dla kogo? Uporządkowane kroki Wysłuchanie opinii Szacowanie czasu User Story - odwrócone spojrzenie As a schedule coordinator I want to create groups so that I can assign students and professor to it. Jako koordynator zajęć chcę tworzyć grupy, aby móc przypisywać do nich studentów i profesora. Czy mogę zobaczyć dostępne przedziały czasowe? Czy mogę wybrać zajęcia? Czy mogę zobaczyć listę profesorów? Czy mogę potwierdzić przypisanie? Czy można uniemożliwić przydzielanie niedostępnych profesorów? Przypadki użycia vs historyjki użytkownika PU zapewniają ustrukturyzowany i ustandaryzowany sposób modelowania i rozumienia wymagań PU – szeroki zakres, szczegółowe informacje w opisie, bardziej techniczne, wielu aktorów, złożone scenariusze PU są przydatne do: projekt systemu, komunikacja i interesariuszami, gromadzenie, planowanie testów, zarządzanie projektem, dokumentacja HU – rejestr, wykorzystywane do planowania, zwinny rozwój, świadomość kontekstu klienta HU – wąski zakres (jedna funkcja/funkcjonalność), zorientowane na użytkownika, mniej techniczne, samodzielne, jeden aktor (interakcja jednego użytkownika) FURPS+ Schemat postępowania dotyczący klasyfikacji atrybutów jakości oprogramowania zaproponowany przez firmę Hewlett-Packard. What? ○ Functionality - What the system should do? Why? capability, audit, printing, reporting, reusability, security, scheduling How? ○ Usability (UX) - How the interface should look like? Why? accessibility, aesthetics, consistency, documentation, responsiveness ○ Reliability - How fast we should be able to bring the system online after failure? Why? availability, accuracy, recoverability ○ Performance - How fast should the system operate and on what hardware? Why? speed, efficiency, resource consumption, throughput, capacity, scalability ○ Supportability - Which parameters should be configurable? Why? adaptability, auditability, configurability, serviceability, maintainability, sustainability, testability, flexibility, installability, localizability MoSCoW - priorytety Mo - Must have – definiuje wszelkie wymagania, które MUSI zawierać wydanie produktu lub systemu. S – Should have – to kategoria wymagań o wysokim priorytecie, która POWINNA, jeśli to możliwe, zostać uwzględniona w wydaniu. Co – Could have – to wymagania, które są pożądane lub „miłe do posiadania”, jeśli MOGĄ zostać uwzględnione bez zbytnich rozbieżności lub kosztów. W - Won't have – to te wymagania, które są pożądane, ale NIE BĘDĄ uwzględnione w bieżącej wersji. FRUPS + MoSCoW Source: https://www.linkedin.com/puls e/conjoining-furps-moscow- analyse-prioritise-jonathan- dyson/ Gdzie można zapisać wymagania? issue tracking software Narzędzia do zarządzania projektem Systemy kontroli wersji …. Co sprawdzić przed rozpoczęciem implementacji? Czy istnieją odpowiednie kryteria akceptacji (spisane lub uzgodnione) z interesariuszami - określa to, w jaki sposób można osiągnąć cele user stories. Używane do: ○ podstawa do testów akceptacyjnych powiązanych funkcjonalności, ○ może stanowić część definicji „ukończenia” przyjętej przez zespół (definition of done). Wszelkie założenia leżące u podstaw wymagania. Należy szukać: ○ luk w wiedzy, potencjalnych problemów lub innych scenariuszy/przypadków skrajnych, które nie były brane pod uwagę, a które wymagają dalszych wyjaśnień. Jeżeli dotyczy: wykonalność prototypu – czy mieści się on w aktualnej architekturze, pasuje do umiejętności inżynierskich i technologii zastosowanej w projekcie.