Inżynieria oprogramowania (Software Engineering)



Podobne dokumenty
Inżynieria oprogramowania (Software Engineering)

INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE

Wytwórstwo oprogramowania. michał możdżonek

Dobre wdrożenia IT cz. I Business Case.

Inżynieria oprogramowania (Software Engineering) Wykład 1

Projektowanie systemów informatycznych. Roman Simiński programowanie.siminskionline.pl. Cykl życia systemu informatycznego

Zarządzanie projektami IT

ISO 9000/9001. Jarosław Kuchta Jakość Oprogramowania

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

Wstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań

MSF. Microsoft Solution Framework

Narzędzia informatyczne wspierające przedsięwzięcia e-commerce

Projektowanie interakcji

Zarządzanie testowaniem wspierane narzędziem HP Quality Center

AL 1302 ZARZĄDZANIE PROJEKTAMI W OPARCIU O METODYKĘ PRINCE2

Oprogramowanie zgodne z prawem

Zarządzanie ryzykiem w projektach informatycznych. Marcin Krysiński marcin@krysinski.eu

Opis Kompetencji Portfel Interim Menedżerowie i Eksperci

Etapy życia oprogramowania

Usługa: Testowanie wydajności oprogramowania

Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania

HP Service Anywhere Uproszczenie zarządzania usługami IT

Zarządzanie kosztami projektu

Agile Project Management

Testowanie oprogramowania

Koordynacja projektów IT w AGH

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

PLASTINVENT listopad Praktyczne aspekty wdrażania i rozwoju wyrobów z tworzyw sztucznych

Interesujący interesariusze

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK

Analityk i współczesna analiza

Modelowanie i analiza systemów informatycznych

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Zarządzanie jakością w logistyce ćw. Artur Olejniczak

Testowanie oprogramowania. Piotr Ciskowski

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

Ryzyko to nasza działalność.

Maciej Oleksy Zenon Matuszyk

Nie o narzędziach a o rezultatach. czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT. Władysławowo, 6 października 2011 r.

Wstęp do zarządzania projektami

Wstęp do zarządzania projektami

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

Międzynarodowa Rada Inżynierii Wymagań. The International Requirements Engineering Board (IREB e.v.) Szkolenia IREB w CTS.

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Studium wykonalności

Jak opisać wymagania zamawiającego wybrane elementy

AUREA BPM HP Software. TECNA Sp. z o.o. Strona 1 z 7

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Inżyniera wymagań

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

Projektowanie systemów informatycznych

Inżynieria oprogramowania II

UPEDU: Testowanie (ang. Testing discipline)

Organizacyjny aspekt projektu

Wykład 1 Inżynieria Oprogramowania

Walidacja systemu ewms / cwms. Sopot

Wsparcie narzędziowe zarządzania ryzykiem w projektach

Opis metodyki i procesu produkcji oprogramowania

Wstęp do zarządzania projektami

SYSTEMY INFORMATYCZNE ćwiczenia praktyczne

Dwuwymiarowy sposób na podróbki > 34

PODSUMOWANIE POLITYKI KONFLIKTU INTERESÓW

Dokumentacja systemu zarządzania bezpieczeństwem pracy i ochroną zdrowia

INŻYNIERIA OPROGRAMOWANIA Jakość w projekcie informatycznym - normy

Wprowadzenie do Behaviordriven

Liczba godzin Punkty ECTS Sposób zaliczenia

Planowanie i realizacja zadań w zespole Scrum

Koncepcja cyfrowej transformacji sieci organizacji publicznych

Zarządzanie projektami. Wykład 2 dr inż. Agata Klaus-Rosińska

Proces tworzenia wartości w łańcuchu logistycznym. prof. PŁ dr hab. inż. Andrzej Szymonik 2014/2015

Inżynieria Programowania Zarządzanie projektem

Wprowadzenie w tematykę zarządzania przedsięwzięciami/projektami. dr inż. Agata Klaus-Rosińska

Zarządzanie Projektami zgodnie z PRINCE2

Narzędzia CASE dla.net. Łukasz Popiel

Efektywność obsługi prawnej projektów IT

Poniższy program może być skrócony do 1 dnia lub kilkugodzinnej prezentacji.

Sukces vs porażka. Sukces. Porażka

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

Inżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki.

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming

Procesowa specyfikacja systemów IT

Headline Verdana Bold Software Asset Management Rola kapitału ludzkiego w programie SAM 10 października, 2018

UPEDU: Rozpoznanie wymagań (ang. requirements discipline)

Bezpieczeństwo i koszty wdrażania Informatycznych Systemów Zarządzania Hubert Szczepaniuk Wojskowa Akademia Techniczna im. Jarosława Dąbrowskiego

Karta przedmiotu studiów podyplomowych

Optymalizacja Automatycznych Testów Regresywnych

B2BCloud simple way to Scale Sale

Porównanie aplikacji do tworzenia harmonogramów.

Testowanie i walidacja oprogramowania

Koszty związane z tworzeniem aplikacji on demand versus zakup gotowych rozwiązań

PRINCE2 czy PMI? Czyli o wyŝszości Świąt Wielkanocnych, nad Świętami BoŜego Narodzenia 11 maja Autor: Jolanta Łabędzka-Benisz.

Zarządzanie projektami. Wykład 2 Zarządzanie projektem

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach)

Programowanie zespołowe

Usługa: Audyt kodu źródłowego

Główne założenia XP. Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness)

Zarządzanie usługami IT

1 Przygotowanie wniosku do PUP doposażenie stanowiska pracy, bony

Transkrypt:

Inżynieria oprogramowania (Software Engineering) Wykład 3 Studium wykonalności Definicja wymagań

Studium wykonalności (feasibility study) Prowadzone przed rozpoczęciem projektu, krótkie, niekosztowne badanie w celu identyfikacji: Klientów Zakresu Potencjalnych korzyści Niezbędnych zasobów: personel, czas, sprzęt itp. Potencjalnych przeszkód: Gdzie są zagrożenia? Jak mogą być zminimalizowane?

Studium wykonalności Studium wykonalności prowadzi do decyzji w rodzaju: Śmiało! Nie idź tędy! Pomyśl jeszcze raz! W realizacji projektów produkcyjnych studium wykonalności często prowadzi do wniosku budżetowego. W projektach badawczych studium wykonalności jest często w formie propozycji albo wniosków.

Klient Pojęcie wieloznaczne: Obywatel starożytnego Rzymu? Ubogi szlachcic uzależniony od możnowładcy? Osoba zwracająca się o wsparcie materialne i niematerialne do instytucji pomocy i integracji społecznej? Osoba nabywająca towar lub usługę, konsument? W projektach IT ma sens ostatnie znaczenie terminu.

Zakres projektu Co stanowi granice projektu? Statyczne/dynamiczne strony internetowe z otwartym/ograniczonym dostępem w sieci lokalnej/globalnej [Web Profiler] Używane przez publiczność czy tylko przez grono studentów i pracowników [Digital Collections] Zróżnicowane formaty danych [Informacje prawne] Tysiące czujników [Data mining] Wsparcie dla Windows, Mac, Unix [SALSA]

Potencjalne korzyści Dlaczego wykonujemy dany projekt? Tworzenie produktu zbywalnego. Poprawa efektywności organizacji. Kontrola systemu, który jest zbyt skomplikowany, aby sterować ręcznie. Dodanie nowych lub ulepszonych usług. Minimalizacja zagrożenia bezpieczeństwa. Inne powody?

Zasoby Personel: Czas: Ile cpecjalistów? Ile godzin pracy w tygodniu? Jakie umiejętności będą wymagane? Wersja beta, testy akceptacyjne, dokumentacja, prezentacja wersji finalnej. Sprzęt i oprogramowanie: Klient: Jakie specjalne potrzeby? Czy klient jest wystarczająco dostępny i będzie pomocny?

Przeszkody Okres rozruchu: Stworzenie zespołu, planowanie spotkań, nabywanie oprogramowania, uczenia się nowych systemów,... Względy biznesowe: Ambicja: Licencje, tajemnice handlowe,... Nic nie wskazuje na koniec pracy. Zmieniające się okoliczności. Co jeszcze?

Jak zminimalizować ryzyko projektowe? Kilka docelowych poziomów funkcjonalności: Wymagany, Pożądany, Opcjonalny. Widoczny proces wytwarzania oprogramowania: Pośrednie rezultaty. Dobra komunikacja w zespole i asysta. Good processes lead to good software! Good processes reduce risk!

Raport wykonalności Dokument pisemny: W audiencji generalnej: klient, zarządzania finansowe, zarządzanie techniczne, itp. Krótki na tyle, że każdy przeczyta. Długi na tyle, że nie ważne tematy mogą być pomijane.

Requirements Definition Definicja i analiza wymagań System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance

Proces inżynierii wymagań Studium wykonalności Feasibility Report Analiza wymagań Modele systemu Definicja wymagań Definicja wymagań Specyfikacja wymagań Dokument wymagań Specyfikacja wymagań

Definicja wymagań Jest to wysokopoziomowy, abstrakcyjny opis wymagań: Określa zewnętrzne zachowanie systemu. Jest zrozumiały dla klienta, menadżerów i użytkowników. Powinien dokładnie odzwierciedlać to, co klient chce: Usługi, które system zapewni. Ograniczenia w ramach których będzie działać.

Wymaganie funkcjonalne Udokumentowana potrzeba określonego produktu czy usługi, albo sposobu ich działania. Stwierdzenie identyfikujące potrzebne cechy, możliwości, charakterystyki lub jakość oprogramowania, aby było ono wartościowe i pożyteczne dla użytkownika. Stwierdzenie, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach. W niektórych wypadkach wymagania funkcjonalne określają, czego system nie powinien robić.

Wymagania niefunkcjonalne Wynikają pośrednio ze zgłoszonych potrzeb użytkownika lub bezpośrednio z wymagań funkcjonalnych. Realizacja wymagania niefunkcjonalnego może wymagać realizacji kilku zależnych wymagań niefunkcjonalnych. Wymagania niefunkcjonalne powstają w wyniku zaprojektowania i uzgodnienia przez architektów produktu specyficznej realizacji wymagań funkcjonalnych.

Specyfikacja wymagań Dokument opisujący wymagania na oprogramowanie. Dobrze napisana specyfikacja wymagań ułatwia komunikację pomiędzy klientem i dostawcą. IEEE Recommended Practice for Software Requirements Specifications

Analiza wymagań Po wykonaniu identyfikacji wymagań należy przeprowadzić ich analizę celem uszczegółowienia, ewentualnego odrzucenia wymagań sprzecznych lub nieprawidłowych oraz określenia priorytetu i ryzyka. Analiza wymagań funkcjonalnych umożliwia zidentyfikowanie i opisanie pożądanego zachowania systemu oprogramowania.

Ewolucja wymagań Jeżeli definicja wymagań jest błędna, projekt systemu zakończy się porażką. Dla systemów złożonych, zrozumieniu potrzeb klienta zawsze będzie się poprawiać stopniowo. Definicje wymagań muszą ewoluować. Dokumentacja wymagań musi być aktualna (wersjonowanie wymagań).