Dyscyplina i zwinność w projektach informatycznych (cz. 2)

Dyscyplina i zwinność w projektach

informatycznych(cz. 2)

Analiza systemów informatycznychWykład 6

Jerzy.Nawrocki@put.poznan.plwww.cs.put.poznan.pl/jnawrocki/wsb-asi

Książę Jozef PoniatowskiBitwa pod Lipskiem, 1813

J.Nawrocki, Dyscyplina i zwinność (cz. 2)

Zwinne wytwarzanie oprogramowania

Ludzie i komunikacja

Współpracujący klient Reagowanie na zmiany

Tommorow or never!

O KO K

Działające oprogr.

Cenne praktyki XPCenne praktyki XP: : • Silna orientacja na klientaSilna orientacja na klienta• Przyrosty i krótkie wydaniaPrzyrosty i krótkie wydania• Testy przed kodowaniemTesty przed kodowaniem• Refaktoryzacja Refaktoryzacja • Gra planistyczna etc.Gra planistyczna etc.

Słabości

Dyscyplina (Celebra ) Zwinność (XP)

• Nadmiar papierów

• Powolny proces decyz.

• Mała elastyczność

• Opór przed zmianą

• Założenie „on-site customer”

• Brak spisanej dokumentacji

• Zbyt krótka perspektywa planu

XPrince

eXtreme Programmingin controlled environments

Źródła XPrince

PRINCE 2 Rational Unified Process

Prince2

Kierownik ZespołuKierownik Zespołu

Zespół XPrince

Komitet sterującyGłówny

użytkownikPrzewodn. Główny

dostawca

Kierownik = Coach

Nadzór projektu

Programiści

ArchitektAnalityk=Klient

Plan prezentacji

• Wstęp• Cykl życia projektu• Inżynieria wymagań i UC Workbench• Czynnik ludzki

Plan prezentacji

• Wstęp• Cykl życia projektu• Inżynieria wymagań i UC Workbench• Czynnik ludzki

Cykl życia wg PRINCE2

16.10 27.11 23.01 8.04 27.05 17.06 1.07

Przyg. założ. proj.

Inicjowanie projektu

Etap 1 Etap 2 Etap 3 Etap 4 Zamk. Projektu

Wydanie 2Wydanie 1

Cykl życia wg XP

Przyrost 1 Przyrost 2 Przyrost 1 Przyrost 2

Fazy wg RUP

Rozpoczęcie RozpracowanieRozpracowanie Konstrukcja Wdrożenie

Cykl życia zgodny z XPrince

Przygotowanie założeń

Opis środowiska operacyjnego

Zbieranie wymagań

Dopracowanie architektury

Wydanie

Zamknięcie

Badania

Produkcja

Przygotowanie założeń projektu

Project Mandate

Project Mandate – Bardzo krótka postać

Nazwa klienta: ……………………………………Reprezentant klienta: …………………………. e-mail: ……….…………………………………. telefon: ........…………………………………….Tytuł projektu: ……………………………………..

Project Exec and Project Manager

Project Mandate

Klient Dostawca

PRINCE2

Zespół XPrince

Komitet SterującyPrzewod.

Kierownik

SUDesign of a Project Management Team SU2

Designation of the Project Manag. Team

Cust + PM

Project Brief

Cust + PMProject Approach

Plan for Project Initiat.

PRINCE2

Zespół XPrince

Komitet SterującyGłówny użytkownik

Przewod. Główny dostawca

Kierownik

Nadzór projektu

ArchitektAnalityk

Moderator

Management Team

Cust + PM

Project Brief

Project Approach

PRINCE2

Zespół XPrince

Komitet SterującyGłówny

użytkownikPrzewod. Główny

dostawca

Kierownik

Nadzór projektu

ArchitektAnalityk

Moderator

Zespół XPrince

Przewodniczący: Jerzy Nawrocki nawrocki@put.poznan.pl (61) 665 29 80Główny dostawca: Bartosz Walter bartosz.walter@cs.put.poznan.pl (61) 665 29 80Główny użytkownik: ExecutiveKierownik: . . .Analityk: . . .Architekt: . . . Moderator: . . .

Cust + PM

Project Brief

FAST / JAD

Przew.+G

ł.uż.

Przew.+G

ł.uż.

FAST = Facilitated Application Specification TechniqueJAD Joint Application

DevelopmentModera

Moderator Analityk

Analityk

Kierownik+Arch.

Agenda spotkania dot. „Project Brief”

PrologSpotkanieEpilog

0 Sprawdzenie obecności i zatw. agendy 5’1 Krótka charakterystyka klienta 5’2 Na czym polega problem? 15’3 Kogo ten problem dotyczy? 5’4 Implikacje problemu 10’5 Koncepcja rozwiązania problemu 10’6 Główne ograniczenia 10’7 Sprawy organizacyjne 10’

Info dla klienta: Cel spotkania (zakres) + prop. agendyPytania: Kto przyjdzie? Ile czasu? (<90’) Termin i miejsce?

Raport: Tytuł projektu. Kiedy i gdzie było spotkanie. Lista obecności. Ustalenia dot. terminu ew. zatw. zakresu. Zakres.Prośba: Decyzja dot. zatw. zakresu + opinia o realizowalności

Cust + PM

Project Brief

Project Approach: Burza mózgów

Przew.+G

ł.uż.

Przew.+G

ł.uż.

Pomysły jak rozwiązać problem

Ocena zaproponowanych rozwiązań

Główna decyzja: Off-the-shelf, DIY, outsorcing, …

ModeratorModerator Sekretarz

Sekretarz

Kierownik+Arch.

Analyst

Agenda spotkania dot. Project Approach

PrologSpotkanieEpilog

0 Sprawdzenie obecności i zatw. agendy 5’1 Przypomnienie Project Brief 10’2 Burza mózgów (rozwiązania) 35’3 Ocena rozwiązań 25’4 Konkluzja 10’5 Sprawy organizacyjne 5’

Info dla klienta: Cel spotkania (zakres) + prop. agendyPytania: Kto przyjdzie? Ile czasu? (<90’) Termin i miejsce?

Raport: Tytuł projektu. Kiedy i gdzie było spotkanie. Lista obecności. Ustalenia dot. terminu ew. zatw. zakresu. Zakres.Prośba: Decyzja dot. zatw. zakresu + opinia o realizowalności

Cust + PM

Project Brief

Cykl życia zgodny z XPrince

Przygotowanie założeń

Opis środowiska operacyjnego

Zbieranie wymagań

Dopracowanie architektury

Wydanie

Zamknięcie

Badania

Produkcja

Wstępny plan projektu

05.11.02 – 05.11.29 Opis środ. operacyjnego

05.11.30 – 05.12.20 Zbieranie wymagań

06.01.03 – 06.01.28 Dopracowanie architektury

06.02.28 – 06.04.15 Wydanie 1

06.04.16 – 06.06.01 Wydanie 2

06.06.02 – 06.06.15 Zamknięcie

PRINCE2

Zespół XPrince – Liczba programistów zależy od budżetu

Komitet SterującyGłówny użytkownik

Przewod. Główny dostawca

Kierownik

Nadzór projektu

ArchitektAnalityk

Kierownik ZespołuKierownik ZespołuProgramiści

Team Growth

16.10 27.11 23.01 8.04 27.05 17.06 8.07Starting

Up a Project

Aim and Scope

Architec-ture

Release 1

Release 2

Release 3

Closing a

Project

ManagerAnalyst

Architect + 1 Dev.All the developers

Cust + PM

Project Brief

Plan prezentacji

• Wstęp• Struktura zespołu• Cykl życia projektu• Inżynieria wymagań i UC Workbench• Czynnik ludzki

Tekst czy diagramy?

Wstępna rejestracja artykułuScenariusz główny1. System presents a registration

form.2. Author fills the form in.3. System validates the data and

returns a login and password.Rozszerzenia3a. The data are in wrong

format. 3a1. System displays a message and returns to step 2.

Tekst czy diagramy?

Przypuszczenie:

Przypadki użycia są łatwiejsze do zrozumienia niż diagramy BPMN.

UC Workbench

• Edycja przypadków użycia

Ekran prototypu wygenerowanego przez UC Workbench

UC Workbench evaluation

Plan prezentacji

• Wstęp• Struktura zespołu• Cykl życia projektu• Inżynieria wymagań i UC

Workbench• Czynnik ludzki

Style zarządzania

•Demokratyczny (people-oriented)

•Autorytarny (result-oriented)

Efektywne zarządzanie

•Stawianie zadań

•Chwalenie

•Upominanie

Stawianie celów

Specific

Measurable

Attractive

Realistic

Stawianie celów – inne rozwinięcie SMART

Specific and measurable

Motivating

Attainable

Relevant

Tracktable

Chwalenie

• Przyłapuj ludzi na właściwym wykonywaniu zadań.

• Chwal ich.

• Rób to często.

Upominanie

Krytykuj zachowanie, nie osobę.

Mów o faktach. Plotki i wrażenia muszą być sprawdzone.

Skup się na najważniejszych aspektach problemu.

1. Przedstaw problem.

2. Powiedz co czujesz.

3. Przerwij na chwilę.

4. Wyraź swoje pozytywne nastawienie do osoby.

Dynamika motywacji

Motywacja

Umiejętności i wiedza

Umiejętności

Dynamika zarządzania

Dyrektywnie Motywująco Partnersko

Motywacja

Umiejętności

Podsumowanie

KombinacjaKombinacja zwinnejzwinnej metodykimetodyki (XP) (XP) zeze zdyscyplinowanązdyscyplinowaną (PRINCE2 (PRINCE2 ii RUP) RUP) jest możliwa jest możliwa

Wsparcie narzędziowe (UC Wsparcie narzędziowe (UC Workbench) jest ważneWorkbench) jest ważne

Cele, pochwały i reprymendyCele, pochwały i reprymendy Przywództwo sytuacyjnePrzywództwo sytuacyjne

Pytania?

Plan prezentacji

• Wstęp• Cykl życia projektu• Inżynieria wymagań i UC

Workbench• Czynnik ludzki

Dyscyplina i zwinność w projektach informatycznych (cz. 2)

Documents

Transcript of Dyscyplina i zwinność w projektach informatycznych (cz. 2)

Komputer w projektach edukacyjnych

warsztat-kulinarny.plwarsztat-kulinarny.pl/Documents/teaser.pdfSWOT Analiza rynky oraz zdobyte w wielu projektach informatycznych doÉwiadczenie pozwala nam na zaplanowanie moŽliwie

Wykorzystanie metodyki AgilePM w projektach informatycznych · AgilePM jest oparty na DSDM ... Kluczową technikę: Warsztaty Facylitowane (facilitated workshops) Podstawy – Pryncypium

Elektrotechnologie w projektach studentów Wydziału ...

Programy chemiczne użyteczne w projektach eTwinning

II. Analiza ryzyka w projektach ppp

Dr inż. Andrzej Czerepicki WSM, 2015 · Architektura komputerów Teoria programowania Modelowanie systemów informatycznych itp. Informatyka jako dyscyplina stosowana Programowanie

Rozliczanie personelu w projektach - lodzkie.pl

Obiektowe modelowanie systemów informatycznych

Płatności w projektach RPO WP

SYLABUSY DO PRZEDMIOTÓW - Uniwersytet … studiów: Studia III stopnia Stacjonarne i niestacjonarne Dziedzina nauki/ dziedzina sztuki: Nauki ekonomiczne Dyscyplina naukowa/ dyscyplina

Finansowe skutki upadłości wykonawców w projektach

Zarządzanie ryzykiem w projektach informatycznych€¦ · Narzędzia ilościowej analizy czynników ryzyka. Analiza drzewa decyzyjnego •Opcja A: W = 0,4 * 0,7 * 100 = 28 •Opcja

Projektowanie Systemów Informatycznych - staff.uz.zgora.plstaff.uz.zgora.pl/jjablons/wyk/ProcesUML.pdf · Projektowanie Systemów Informatycznych Funkcjonalno ść - Zaprogramowane

Instytucie Mechatroniki i Systemów Informatycznych · 2/15 Instytut Mechatroniki i Systemów Informatycznych Politechnika Łódzka Instytut Mechatroniki i Systemów Informatycznych

Testowanie bezpieczeństwa systemów informatycznych

Dyscyplina sportowa - siatkówka

Zarządzanie ryzykiem w projektach informatycznych. Teoria ... · † Uzasadnienie biznesowe i analiza ekonomiczna wartoœci projektu † Wybrane techniki analizy ryzyka † B³êdy

Architektura Systemów Informatycznych Zarządzania

Efektywne wdrożenia narzędzi informatycznych