Zarządzanie inicjatywami i wymaganiami w projektach IT Spotkanie 1 Katarzyna Misiak katarzyna.misiak@gmail.com
Czym się będziemy zajmować? Co będzie: 1. Zarządzanie wymaganiami 2. Przegląd oprogramowania 3. Zarządzanie inicjatywami UW PSM ZPI
Co już Państwo znają? 1. Ideę wychodzenia od strategii organizacji i jej potrzeb 2. Priorytety dla wymagań w oparciu o MoSCoW 3. Zarządzanie wymaganiami w Scrum (product backlog) 4. Podstawowe zasady specyfikacji w oparciu o modele 5. Procedurę zarządzania zmianą UW PSM ZPI
ITIL Źródło: ITIL Service Transition UW PSM ZPI
Czemu projekty się nie udają? Główne ryzyka dla projektów IT: 1) Problemy z harmonogramem 2) Inflacja wymagań 3) Utrata pracowników 4) Niepełne i niespójne specyfikacje 5) Niska produktywność Źródło: Tom DeMarco, Timothy Lister Waltzing with Bears: Managing Risk on Software Projects
Po co nam zarządzanie wymaganiami?
Po co nam zarządzanie wymaganiami? Aby mieć pewność, że potrzeby i oczekiwania klientów oraz interesariuszy są właściwie udokumentowane, co pozwala je spełnić. A skoro wymagania się zmieniają trzeba również zarządzać ich cyklem życia i móc śledzić zależności
Dlaczego to robimy? Bo pominięcie ważnej potrzeby Klienta prędzej, czy później będzie wymagało od nas pilnej akcji a poprawki wprowadzane w ostatniej chwili wymagają testów, aby nie wprowadzić błędów, trwają i zużywają zasoby (reguła 1-10-100)
Odrobina teorii Wymaganie: Coś pożądanego Daje się opisać i zaobserwować Cechy wymagań [za: Ian Sommerville]: Weryfikowalność Zrozumiałość Pochodzenie Elastyczność
Odrobina teorii Rodzaje wymagań [za: Systems Engineering Fundamentals. Defense Acquisition University Press, 2001]: Klienta gdzie będzie zastosowany jaki będzie scenariusz wykorzystania jakie są krytyczne parametry niezbędne do osiągnięcia celu jak będą wykorzystywane komponenty systemu jakiej efektywności wymagamy jak długo system będzie wykorzystywany w jakim środowisku ma działać system Funkcjonalne (zadania do wykonania) Nie funkcjonalne (cechy systemu zależne od innych) Wydajnościowe Projektowe Pochodne Przyporządkowane
I spostrzeżenie praktyczne Problemy z wymaganiami [za: Just Enough Requirements Management Alan M. Davis]: 1) Brak świadomości istnienia wymagania 2) Ignorowanie dostępnych zasobów (czas, środki) 3) Niejasna specyfikacja
Jak wygląda zarządzanie wymaganiami? Fazy zarządzania wymaganiami: 1) Gromadzenie wymagań 2) Analiza wymagań 3) Dokumentowanie wymagań + oczywiście wykorzystywanie i doprecyzowywanie wymagań w ramach pracy projektowej na etapach projektowania, konstruowania i testów oraz wydania
Jak można gromadzić wymagania? 1) Wywiady 2) Warsztaty 3) Analiza dokumentacji 4)
Po co nam analiza biznesowa? 1) Wychwytywanie błędów i niespójności (w tym np. sprzecznych wymagań) 2) Tłumacz 3) Ustalanie priorytetów 4) Zarządzanie zmianą 5)
Jak dokumentować wymagania? 1) Dokumentacja wyników warsztatu/burzy mózgów np. w formie mindmapy 2) Lista kontraktowa 3) Lista mierzalnych celów (vide Agile) 4) Prototypy i symulacje (uwaga na syndrom jutra ; nie zawsze wystarczają) 5) Przypadki użycia (lub bardziej pełny opis za pomocą modeli :) 6) Software Requirements Specifications (SRS) IEEE 830 7)
Struktura SRS (1/2) 1 INTRODUCTION 1.1 Product Overview 1.2 Purpose 1.3 Scope 1.4 Reference 1.5 Definition And Abbreviation 2 OVERALL DESCRIPTION 2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics 2.4 General Constraints 2.5 Assumptions and Dependencies
Struktura SRS (2/2) 3 SPECIFIC REQUIREMENTS 3.1 External Interface Requirements 3.1.1 User Interfaces 3.1.2 Hardware Interfaces 3.1.3 Software Interfaces 3.1.4 Communications Protocols 3.1.5 Memory Constraints 3.1.6 Operation 3.1.7 Product function 3.1.8 Assumption and Dependency 3.2 Software Product Features 3.3 Software System Attributes 3.3.1 Reliability 3.3.2 Availability 3.3.3 Security 3.3.4 Maintainability 3.3.5 Portability 3.3.6 Performance 3.4 Database Requirements 4 ADDITIONAL MATERIALS
Kryteria jakości specyfikacji wymagań (IEEE 830) 1) poprawność, 2) jednoznaczność, 3) kompletność, 4) spójność, 5) uporządkowanie wg ważności i stabilności, 6) weryfikowalność, 7) modyfikowalność 8) możliwość śledzenia + uwaga OGC [www.ogc.gov.uk/delivery_lifecycle_requirements_management.asp] 9) bez projektowania
Dokumentacja im więcej, tym lepiej? Secrets of Just Enough Elicitation (Alan M. Davis): 1) Never lose sight of your goal: understanding enough of the problem so you can proceed with minimal risk 2) Never think you understand the problem better than the customer. 3) Never assume that one stakeholder can speak for all stakeholders. 4) Maintain a glossary of terms. 5) Avoiding elicitation altogether will significantly lengthen the overall development time, not reduce it. 6) Prepare for change. The more the stakeholders discuss, the more they will want. Don t solve this problem by cutting off the stakeholder. An involved stakeholder is a happy stakeholder. 7) Stakeholders have the right to change their minds. 8) Prepare for active, explicit, and overt triage.
Dobre praktyki PMBOK Project Scope Management: 1) Collect Requirements 2) Define Scope 3) Create WBS 4) Verify Scope 5) Control Scope Wejście: karta projektu rejestr interesariuszy Narzędzia i techniki: techniki kreatywności grupowej, techniki grupowego podejmowania decyzji Wyjście: dokumentacja wymagań, macierz śledzenia wymagań (Requirements Traceability Matrix) przypisująca wymagania do funkcjonalności plan zarządzania wymaganiami
Dobre praktyki inne źródła BABOK http://www.theiiba.org/ SWEBOK http://www.computer.org/portal/web/swebok
Oprogramowanie - przegląd Freemind ADONIS:CE już był, więc dla równowagi Enterprise Architect Axure OSRMT + rozwiązania autorskie Rozwiązania sieciowe: Gatherspace.com Tracecloud.com
Podsumowanie Dziękuję