Samodzielny Zakład Sieci Komputerowych dr inż. Marcin Kwapisz Lecture 7 – Gazing into the Crystal Ball and Reading Tea Leaves.

Slides:



Advertisements
Podobne prezentacje
I część 1.
Advertisements

Project management w procesie budowy grona
Jarosław Kuchta Jakość Oprogramowania
Projektowanie w cyklu życia oprogramowania
Inżynieria Oprogramowania 10. Szacowanie kosztu oprogramowania cz. 2
Część 2 OiZPI Iteracyjny przyrostowy model cyklu życiowego Rational Unified Process™ w materiałach wykorzystano: K.Subieta: Budowa i integracja systemów.
1 / 47 WARSZAWA 2005 Przemysław Siekierko Stanisław Andraszek Rational Unified Process.
Rational Unified Process www-306.ibm.com/software/rational/
Zarządzanie zakresem i czasem
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 1 Szacowanie kosztu oprogramowania l Szacowanie kosztu i pracy niezbędnej do wyprodukowania.
Projektowanie Aplikacji Komputerowych
EXtreme Programming » Magdalena Tchorzewska.
Tematyka prac magisterskich w Zakładzie Informatyki Stosowanej
Dokumentowanie wymagań w języku XML
Inżynieria oprogramowania II Wykład 4 Normy serii ISO 9000
Inżynieria oprogramowania Copyright, 2000 © Jerzy R. Nawrocki Wprowadzenie do informatyki.
Szacowanie rozmiaru i pracochłonności
Model dojrzałości CMMI
Szacowanie rozmiaru i pracochłonności
Personal Software Process
Analiza i walidacja wymagań
Copyright © Jerzy R. Nawrocki Zbieranie wymagań Analiza systemów informatycznych Wykład.
Copyright © Jerzy R. Nawrocki Wprowadzenie Analiza systemów informatycznych Wykład.
Szacowanie pracochłonności
Dyscyplina i zwinność w projektach informatycznych (cz. 2)
Copyright © Jerzy R. Nawrocki Szacowanie rozmiaru i pracochłonności Inżynieria oprogramowania.
Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego LOGISTICS PACKAGING Imię i nazwisko: Alicja Małek Grupa.
Szacowanie rozmiaru oprogramowania
Inżynieria Oprogramowania dla Fizyków
Życiorys mgr inż. Katarzyna Łukasiewicz Katedra Inżynierii Oprogramowania WETI PG Urodzona: r. Wykształcenie: 2010 – obecnie studia doktoranckie.
Pomiary w inżynierii oprogramowania
Pomiary w inżynierii oprogramowania
Eksploatacja zasobów informatycznych przedsiębiorstwa
Metody Funkcyjne FPA Maciej Bukowski PJWSTK grudzień 2006.
Rational Unified Process
Wykład 2 Cykl życia systemu informacyjnego
Szacowanie złożoności oprogramowania
C.d. wstępu do tematyki RUP
Agile Estimating and Planning
Inżynieria oprogramowania Copyright, 1999 © Jerzy R. Nawrocki Wprowadzenie do informatyki.
Zarządzanie projektami IT
Model przestrzenny Diagramu Obiegu Dokumentów
Wykład 1 – część pierwsza
Microsoft Solution Framework
Norma IEEE 1058 – SPMP IEEE - The Institute for Electrical and Electronics Engineering Instytut inynierii elektrycznej i elektronicznej SPMP - Software.
Inżynieria Oprogramowania Copyright, 2001 © Jerzy R. Nawrocki Wprowadzenie do informatyki.
Rational Unified Process Implementacja Aleksandra Reiman, gr. I-52.
Inżynieria Oprogramowania
Pomiary procesów programistycznych Copyright, 2002 © Jerzy R. Nawrocki Zarządzanie jakością.
© 2007 AMX AMX ® Resource Management Suite ®. © 2007 AMX Confidential Rozwiązania sieciowe Video Konferencje Centra zarządzania Kino domowe Sale wykładowe.
Zarządzanie projektami informatycznymi
Studium osiągalności. Rozmiar projektu (np. w punktach funkcyjny projektu w porównaniu do rozmiaru zakładanego zespołu projektowego i czasu Dostępność.
Studium osiągalności. Rozmiar projektu (np. w punktach funkcyjny projektu w porównaniu do rozmiaru zakładanego zespołu projektowego i czasu Dostępność.
Polsko-Norweski Fundusz Badań Naukowych / Polish-Norwegian Research Fund Testowanie metriksów czyli do czego jesteśmy zobowiązani zapisami aplikacji Warsztaty.
SINTEF Byggforsk/Building and Infrastructure
Business Consulting Services © 2005 IBM Corporation Confidential.
Studium osiągalności.
Copyright © Jerzy R. Nawrocki Team Software Process Inżynieria oprogramowania II Wykład.
Eksploatacja zasobów informatycznych przedsiębiorstwa.
Komponentowe i rozproszone Interludium czyli krótki wykład o rozpraszaniu.
Metody analizy wydajności i precyzji oprogramowania Wojciech Matuszewski.
7 Międzynarodowa Konferencja INŻYNIERIA PRODUKCJI – r. Wrocław Piotr Garbacz INTEGRATED VISION SYSTEMS VERSUS CUSTOM SOLUTIONS FOR.
(c) InMoST 2006 Plan szkolenia ▪ Wprowadzenie (9:00-10:30): Czym jest szacowanie? (MO) Systematyczne podejście do planowania (ŁO) Planowanie, a kalendarz.
Zarządzanie projektami informatycznymi
A prototype of distributed modelling environment
Wykład 1 – część pierwsza
IEEE SPMP Autor : Tomasz Czwarno
Zapis prezentacji:

Samodzielny Zakład Sieci Komputerowych dr inż. Marcin Kwapisz Lecture 7 – Gazing into the Crystal Ball and Reading Tea Leaves

Lecture 7.1 – Szacowanie nakładu pracy i harmonogramu  Modele algorytmiczne  COCOMO II  Punkty funkcyjne  Punkt przypadków-użycia  Punkty obiektowe  QIF-based estimates (Quantitative Influencing Factors) - IBM Rational SUMMIT Ascendant  Szacowanie przez ekspertów  Wideband Delphi  Szacowanie na podstawie analogicznych projektów Najczęściej używane techniki szacowania

Lecture 7.2 – Dystrybucja wartości szacowanej  Z góry na dół, czyli od ogółu do szczegółu (Top-down)  Oszacowanie całego projektu (COCOMO II, Punkty funkcyjne)  Dystrybucja wartości szacowanej na wszystkie elementy WBS Dystrybucja w WBS Faza opracowania Zadanie 1 Podzadanie 1.1 Podzadanie 1.2 Zadanie 2 Podzadanie 2.1

Lecture 7.3 – Dystrybucja wartości szacowanych  Z dołu do góry, czyli od szczegółu do ogółu  Szacowanie niskopoziomowych elementów WBS (QIF, Szacowanie ekspertów)  Suma w rezultacie da końcowy szacunek dla całego projektu Faza opracowania Zadanie 1 Podzadanie 1.1 Podzadanie 1.2 Zadanie 2 Podzadanie 2.1 Dystrybucja w WBS

Lecture 7.3 – Iteracyjne szacowania Oceń Zaktualizuj plan Wykonaj Przegląd oszacowania Porównaj

Lecture 7.4 – Dokładność szacunku 0 4X X/4 Variance in Cost to Complete Estimate Na koniec każdej fazy powinno się zweryfikować i udoskonalić miary projektowe, kiedy wiedza o aktualnych nakładach pracy jest już dostępna Iteration I1Iteration E1Iteration E2Iteration C1Iteration C2Iteration C3Iteration T1 Elaboration Construction Transition Inception Over-estimated Under-estimated

Lecture 7.5 – COCOMO II   Etap koncepcji  Etap wczesnego projektowania (Early Design)  Badanie różnych rozwiązań architektonicznych oprogramowania/systemów i pomysłów na ich wykonanie,  Zgrubna ocena kosztów  Zbiór 7 multiplikatywnych czynników kosztowych  Etap po-projektowy (Post-Architecture)  Rozwój i utrzymanie oprogramowania  Dokładna ocena kosztów  Zbiór 17 multiplikatywnych czynników kosztowych COnstructive COst MOdel II

Lecture 7.6 – COCOMO II – Ocena nakładu pracy Osobo-miesiące BRAKProcent kodu porzuconego, z uwagi na zmienność wymagań ASLOCRozmiar zaadoptowanego kodu komponentów wyrażony w tysiącach linii kodu ATLiczba komponentów automatycznie przekonwertowanych ATPRODPoziom zautomatyzowania konwersji wyrażony w SLOC/osobomiesiąc Czynniki kosztowe Kod porzucony B Czynniki skalujące Re-engineering and Conversion PM nom

Lecture 7.7 – COCOMO II – Ocena nakładu pracy Nowe KSLOC Zaadaptowane KSLOC KNSLOCRozmiar wyrażony w tysiącach linii nowego kodu KASLOCRozmiar wyrażony w tysiącach linii zaadaptowanego kodu ATProcent komponentów automatycznie przystosowanych AAProcent nakładu pracy koniecznego do oceny i przyswojenia istniejącego komponentu SUProcent nakładu pracy koniecznego do zrozumienia jego działania DM/CMProcent nakładu pracy na projektowanie i modyfikacje kodu IMProcent nakładu pracy na integrację i testowanie

Lecture 7.8 – Rozmiar w liniach kodu (LOC) Design Modified Code Modified Integration/Test Modified Assessment & Assimilation Automatically translated Software Understanding

Lecture 7.9 – Czynniki skalujące Czynniki kosztowe Kod porzucony Re-engineering and Conversion PM nom PRECPrecedens (Precedentedness) FLEXElastyczność budowy oprogramowania (Development Flexibility) RESLArchitektura i przeciwdziałanie ryzyku (Architecture and Risk Resolution) TEAMSpójność zespołu (Team Cohesion) PMATDojrzałość procesu (Process Maturity)

Lecture 7.10 – Czynniki skalujące – SF 1  Organizacyjne zrozumienie celów produktu  Ogólne \ Znaczne \ Całkowite  Doświadczenie w pracy nad podobnymi systemami  Umiarkowane \ Znaczne \ Extensive  Równoległy rozwój budowy platformy sprzętowej i procedur operacyjnych  Rozległe \ Umiarkowane \ Nieznaczne  Need for innovative data processing architectures, algorithms  Znaczne \ Nieznaczne \ Minimalne PREC – Precedentedness (Very Low, Low = 5 \ Nominal, High \ Very High, Extra High = 0)

Lecture 7.11 – Czynniki skalujące – SF 2  Konieczność zgodności oprogramowania z wcześniej ustalonymi wymaganiami  Pełna \ Znaczna \ Podstawowa  Konieczność zgodności oprogramowania ze specyfikacją zewnętrznych interfejsów  Pełna \ Znaczna \ Podstawowa  Premia za wcześniejsze ukończenie projektu  Wysoka \ Średnia \ Niska FLEX – Development Flexibility (Very Low = 5 \ Low \ Nominal \ High \ Very High \ Extra High = 0)

Lecture 7.12 – Czynniki skalujące – SF 3  Risk Management Plan – identyfikuje wszystkie krytyczne elementy ryzyka, ustala kamienie milowe dla ich rozwiązania poprzez PDR (Product Design Review).  Wcale \ Mało \ Trochę \ Ogólnie \ W większości \ W pełni  Harmonogram, budżet i wewnętrzne kamienie milowe z PDR zgodne z Risk Management Plan  Wcale \ Mało \ Trochę \ Ogólnie \ W większości \ W pełni  Procent czasu poświęconego na ustalenie architektury na podstawie głównych celów produktu  5 \ 10 \ 17 \ 25 \ 33 \ 40  Procent najlepszych architektów dostępnych dla projektu  20 \ 40 \ 60 \ 80 \ 100 \ 120  Wsparcie narzędzi do rozwiązywania elementów ryzyka, tworzenia i weryfikacji specyfikacji architektonicznych  Żadne \ Niewielkie \ Ograniczone \ Dobre \ Silne \ Pełne  Poziom niepewności kluczowych czynników architektonicznych: cel, interfejs użytkownika, sprzęt, technologia, wydajność, COTS (commercial-off-the-shelf)  Ogromny \ Znaczący \ Duży \ Niewielki \ Mały \ Bardzo mały  Liczba i wielkość elementów ryzyka  > 10 krytycznych \ 5-10 krytycznych \ 2-4 krytycznych \ 1 krytycznych \ > 5 niekrytycznych \ < 5 niekrytycznych RESL – Architecture and Risk Resolution (Very Low = 5 \ Low \ Nominal \ High \ Very High \ Extra High = 0)

Lecture 7.13 – Czynniki skalujące – SF 4  Spójność celów udziałowców i kultury  Mała \ Niewielka \ Podstawowa \ Znaczna \ Silna \ Pełna  Możliwości i chęci dostosowywania się do celów innych udziałowców  Małe \ Niewielke \ Podstawowe \ Znaczne \ Silne \ Pełne  Doświadczenie udziałowców w pracy zespołowej  Żadne \ Małe \ Małe \ Podstawowe \ Znaczne \ Rozległe  Budowa zespołu udziałowców celem osiągnięcia wspólnej wizji i zaangażowania  Żadna \ Mała \ Mała \ Podstawowe \ Znaczna \ Rozległa TEAM – Team Cohesion (Very Low = 5 \ Low \ Nominal \ High \ Very High \ Extra High = 0)

Lecture 7.14 – Scale Factors – SF 5  CMMI – Capability Maturity Model (Integration)  Capability Maturity Model ® Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes. It can be used to guide process improvement across a project, a division, or an entire organization. CMMI helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.  PMAT – Process Maturity (Very Low = 5 \ Low \ Nominal \ High \ Very High \ Extra High = 0)

Lecture 7.15 – Nakład pracy a czynniki skalujące

Lecture 7.16 – Czynniki kosztowe Czynniki kosztowe Kod porzucony B Czynniki skalujące Re-engineering and Conversion PM nom RCPXNiezawodność i złożoność produktu (Product Reliability and Complexity) RUSEWymagania ponownego wykorzystania komponentów (Required Reuse) PDIFOgraniczenia platformy (Platform Difficulty) PERSMożliwości kadrowe (Personnel Capability) PREXDoświadczenie kadry (Personnel Experience) FCILInfrastruktura (Facilities) SCEDHarmonogram (Schedule)

Lecture 7.17 – Czynniki kosztowe (1) Model wczesnego projektowania (7) Model po-projektowy (17) RCPXRELY, DATA, CPLX, DOCU RUSE PDIFTIME, STOR, PVOL PERSACAP, PCAP, PCON PREXAEXP, PEXP, LTEX FCILTOOL, SITE SCED Early Design and Post-Architecture Effort Multipliers

Lecture 7.18 – Czynniki kosztowe (2)  Stopniowanie:  Liczba stopni – 7  XLO \ VLO \ LO \ NO \ HI \ VHI \ XHI  NO = 1 (poziom nominalny)  EM 1 – RCPX– Product Reliability and Complexity  EM 2 – RUSE – Required Reuse  EM 3 – PDIF – Platform Difficulty  EM 4 – PERS – Personnel Capability  EM 5 – PREX – Personnel Experience  EM 6 – FCIL – Facilities  EM 7 – SCED – Schedule Model wczesnego projektowania

Lecture 7.19 – Effort Multipliers (3)  Stopniowanie:  Liczba stopni – 6  VLO \ LO \ NO \ HI \ VHI \ XHI  NO = 1 (poziom nominalny) Model po-projektowy

Lecture 7.20 – Effort Multipliers (4)  Product Reliability and Complexity (RCPX) – Product Factors  EM 1 – RELY – Required Software Reliability (VLO – VHI)  EM 2 – DATA – Database Size (LO – VHI)  EM 3 – CPLX – Product Complexity (VLO – XHI) Control Op., Computational Op., Device-Dependant Op., Data Management Op., User Interface Management Op.  EM 4 – DOCU – Documentation match to life-cycle needs (VLO – VHI)  EM 5 – RUSE – Required Reuse (LO – XHI) – Product Factor  Platform Difficulty (PDIF) – Platform Factors  EM 6 – TIME – Execution Time Constraint (NO – XHI)  EM 7 – STOR – Storage Constraint (NO – XHI)  EM 8 – PVOL – Platform Volatility (LO – VHI) Model po-projektowy (Post–Architecture Model)

Lecture 7.21 – Effort Multipliers (5)  Personnel Capability (PERS) – Personnel Factors  EM 9 – ACAP – Analyst Capability (VLO – VHI)  EM 10 – PCAP – Programmer Capability (VLO – VHI)  EM 11 – PCON – Personnel Continuity (VLO – VHI)  Personnel Experience (PREX) – Personnel Factors  EM 12 – AEXP – Application Experience (VLO – VHI)  EM 13 – PEXP – Platform Experience (VLO – VHI)  EM 14 – LTEX – Language and Tool Experience (VLO – VHI)  Facilities (FCIL) – Project Factors  EM 15 – TOOL – Use of Software Tools (VLO – XHI)  EM 16 – SITE – Multi-site Development (VLO – XHI) Model po-projektowy (Post–Architecture Model)

Lecture 7.22 – Effort Multipliers (6)  EM 17 – SCED – Required Development Schedule – Project Factor Model po-projektowy (Post–Architecture Model) VLOLONOHIVHI SCED75%85%100%130%160%

Lecture 7.23 – COCOMO II – Schedule Estimation Czas budowy oprogramowania TDEVcalendar time in months from the determination of a product’s requirements baseline to the completion of an acceptance activity certifying that the product satisfies its requirements PMestimated person-months excluding the SCED effort multiplier SCED%the compression / expansion percentage in the SCED effort multiplier