X36SSP Správa softwarových produktů 5. přednáška Ing. Martin Molhanec ČVUT – FEL K13113.

Prezentace na téma: "X36SSP Správa softwarových produktů 5. přednáška Ing. Martin Molhanec ČVUT – FEL K13113."— Transkript prezentace:

1 X36SSP Správa softwarových produktů 5. přednáška Ing. Martin Molhanec ČVUT – FEL K13113

2 OBJECT ORIENTED SOFTWARE PROCESS

3 Dnešní témata Historie SPHistorie SP Co je to OOSPCo je to OOSP Z jakých částí se skládáZ jakých částí se skládá Inicializační fáze OOSPInicializační fáze OOSP

4 Software proces Způsob vytváření softwarových produktů –Programů –Informačních systémů –Webových sídel –…

5 Co je? Proces –Série akcí, která má svůj vstup a svůj výstup Pattern (vzor) –Popis obecného způsobu dobrého řešení Antipattern –Popis obecného způsobu špatného řešení OOSP –Object-Oriented Software Process

6 Historie SP Sériový vývoj (vodopád) –Nevýhodou je malá pružnost Inkrementální (spirálový) –U velkých projektů je náročný na zdroje Iterativní –Vývoj se děje po kouskách Paralelní –Vývoj se děje současně Dobrá cesta Agilní metodiky

7 Velké projekty je potřeba kvalifikovaně plánovat a řídit tak, aby se přednosti OO paradigmatu projevily a ne aby se staly ohrožením projektu. Není možné se pouze spoléhat na „zázračné“ vlastnosti nových programovacích jazyků a nástrojů. pro oblast řízení a podpory softwarových projektů máme různé metodiky: Rational Software Corporation.: RUP - Rational Unified Process S. W. Ambler: Object-Oriented Process Pattern objektově orientované paradigma a velké projekty  jednodušší, procesně orientovaný, zahrnuje CMM, SCM, metriky,...  fáze údržby a provozu je aktivní součástí celého procesu  důraz na využití refactoringu, znovupoužitelnosti a vlastností čistých nástrojů  použitelný i pro XP, BORM  rozsáhlá sada různých nástrojů a technik, je třeba si umět vybrat  nepokrývá fázi údržby a provozu  je šitý na míru smíšeným vývojovým nástrojům  předpokládá klasický vývoj s UML

8 maintenance & support in-house development using packages in-house development using packages project initiation SOFTWARE DEVELOPMENT PROCESS INITIATION CONSTRUCTION DELIVER MAINTAIN & SUPORT well define user requirements well define user requirements select optimal solution select optimal solution prepare all required for project start success... prepare all required for project start success... well define user requirements well define user requirements select optimal solution select optimal solution prepare all required for project start success... prepare all required for project start success... key performance issues Each phase has associate its key performance issues, corresponding roles, activities etc. well end efficient performed analysis well end efficient performed analysis best system assembling and testing best system assembling and testing to have good documentation... to have good documentation... well end efficient performed analysis well end efficient performed analysis best system assembling and testing best system assembling and testing to have good documentation... to have good documentation... start system use seamless and efectively start system use seamless and efectively well prepare users of the system... well prepare users of the system... start system use seamless and efectively start system use seamless and efectively well prepare users of the system... well prepare users of the system... to have satisfied users to have satisfied users repair defects repair defects to have good knowledge base for possible new version start... to have good knowledge base for possible new version start... to have satisfied users to have satisfied users repair defects repair defects to have good knowledge base for possible new version start... to have good knowledge base for possible new version start... GO NEXT

9 Advanced SW Development Model (ASDM) INICIACE KONSTRUKCE DODÁNÍ PROVOZ Vychází z praktických zkušeností na IT projektech. Inspirace metodikou „object-oriented process pattern“ (Scott W. Amblera). Inspirace některými prvky metody RUP. správně definovat požadavky na systémsprávně definovat požadavky na systém vybrat optimální variantu řešenívybrat optimální variantu řešení naplánovat a připravit vše potřebné k zahájení projektu...naplánovat a připravit vše potřebné k zahájení projektu... správně definovat požadavky na systémsprávně definovat požadavky na systém vybrat optimální variantu řešenívybrat optimální variantu řešení naplánovat a připravit vše potřebné k zahájení projektu...naplánovat a připravit vše potřebné k zahájení projektu... oblasti klíčových výkonnostních požadavků Pro každou fázi jsou identifikovány charakteristické činnosti a k nim jsou definovány pracovní role a odpovědnosti. provést dobře a efektivně analýzuprovést dobře a efektivně analýzu co nejlépe sestavit a otestovat systémco nejlépe sestavit a otestovat systém mít řádnou dokumentaci...mít řádnou dokumentaci... provést dobře a efektivně analýzuprovést dobře a efektivně analýzu co nejlépe sestavit a otestovat systémco nejlépe sestavit a otestovat systém mít řádnou dokumentaci...mít řádnou dokumentaci... efektivně zahájit provoz systémuefektivně zahájit provoz systému dobře zaškolit uživatele...dobře zaškolit uživatele... efektivně zahájit provoz systémuefektivně zahájit provoz systému dobře zaškolit uživatele...dobře zaškolit uživatele... spokojenost uživatelů s podporouspokojenost uživatelů s podporou rychlá oprava chybrychlá oprava chyb mít dostatečnou znalostní bázi požadavků a návrhů pro novou verzi...mít dostatečnou znalostní bázi požadavků a návrhů pro novou verzi... spokojenost uživatelů s podporouspokojenost uživatelů s podporou rychlá oprava chybrychlá oprava chyb mít dostatečnou znalostní bázi požadavků a návrhů pro novou verzi...mít dostatečnou znalostní bázi požadavků a návrhů pro novou verzi...

10 maintenance & support in-house development using packages in-house development using packages project initiation INITIATE CONSTRUCT DELIVER MAINTAIN & SUPORT JUSTIFY define and validate REQUIRE- MENTS define initial management DOCUMENTS define INFRA- STRUCTURE MODEL TEST in the small GENERALIZE PROGRAM PROCESS TEST in the large RELEASE REWORK ASSESS SUPPORT identify defects and enhance- ments SOFTWARE DEVELOPMENT PROCESS project office team development team support team user experts end-users quality assurance, manage project, trainig&education, manage people, manage risk, manage reuse, manage metrics, manage deliverables, manage infrastructure GO NEXT

11 činnosti provozované na provozní platformě činnosti provozované na vývojové a testovací platformě INITIATEINITIATECONSTRUCTCONSTRUCTDELIVERDELIVER MAINTAIN & SUPPORT PODPŮRNÉ PROCESY zajištění kvality, people management, risc management, reuse management, právní zabezpečení, bezpečnost, řízení infrastruktury,... JUSTIFYJUSTIFY DEFINE REQUIRE- MENTS DEFINE MGMT DOCUMENTS DEFINE INFRA- STRUCTURE MODELMODEL TESTS IN THE SMALL GENERALIZEGENERALIZEPROGRAMPROGRAM TESTS IN THE LARGE RELEASERELEASE REWORKREWORKASSESSASSESS SUPPORTSUPPORT IDENTIFY DEFECTS podpora týmem „help desk“ podpora týmem projektové kanceláře spolupráce všech budoucích uživatelů spolupráce zástupců budoucích uživatelů provozní tým pracovní tým zahajovací tým Scott W. Ambler: Object-Oriented Process Pattern

12 SUPPORT PROCESSES FOR THE ADVANCE SOFTWARE DEVELOPMENT MODEL RISK MANAGEMENT IDENTIFY A RISK ASSESS THE RISK DEVELOP MITIGATION STRATEGIES MITIGATE THE RISK REPORT RISK QUALITY ASSURANCE FOLLOW ISO STANDARDS TRAINING & EDUCATION DEVELOP A TRAINING PLAN REUSE MANAGEMENT COLLECT REUSABLE ITEMS METRICS MANAGEMENT DEVELOP METRICS PLAN DELIVERABLES MANAGEMENT INFRA- STRUCTURE MANAGEMENT MANAGE SOFTWARE CONFI- GURATION MANAGE SOFTWARE CONFI- GURATION APPLY CMM, … TECHNIQUES DEVELOP A RISK MANAGEMENT PLAN PERFORM INTRO TRAININGS PERFORM INTRO TRAININGS PERFORM DETAILED TRAININGS PERFORM DETAILED TRAININGS PERFORM AND DISCUSS

13 Nasazení rolí v jednotlivých fázích je odlišné modelprogramgeneralize test in the small … development engineer modeler project manager subject matter expert / user technical writer Složení týmu a nasazení jeho členů se v různých fázích ASDM mění.

14 INITIATEINITIATECONSTRUCTCONSTRUCTDELIVERDELIVER MAINTAIN & SUPPORT Alokace lidských zdrojů !!! při zahájení projektu se nemá plýtvat pracovní silou !!! poměr programátorských profesí k analytickým klesá se mění v závislosti na fázi projektu.

15 Struktura ASDM Co do dané fáze vstupuje! Co se v dané fázi dělá! Co je výstupem dané fáze! Jaké role se v dané fázi uplatňují!

16 Struktura ASDM

17 INITIATE PHASE The main goal of the Initiate phase is to lay the foundation for a successful project.

18 JUSTIFY define and validate REQUIRE- MENTS define initial management DOCUMENTS define INFRA- STRUCTURE allocated maintenance changes management documents initial requirement project infrastructure project funding project charter potential roles during this phase: project manager analyst subject matter expert quality assurance engineer estimator / planner process specialist standards specialist tools specialist project sponsor JAD / meeting facilitator technical writer infrastructure engineer from maintain & support phase INITIATE PHASE The main goal is to lay the foundation for a successful project. This is hard due to pressures by senior management and developers to start “real work” as soon as possible. to construct phase

19 DEFINE AND VALIDATE INITIAL REQUIREMENTS DEFINE SYSTEM FUNCTIONS vision commitment reasibility study existing applications maintenance changes DEFINE SYSTEM SCENARIOS CREATE MODELING CARDS HOLD SESSIONS INTERVIEW USERS PRIORITIZE REQUIRE- MENTS WALK THROUGH PROTOTYPES WALK THROUGH PROTOTYPES SIMULATE SCENARIOS DRAW PROCES MAPS requirement documentation (forms, tables, diagrams,...) project scope This is determining what needs to be built. Initial requirements are a foundation from which modeling can begin. Analýza požadavků

20 DEFINE INITIAL MANAGEMENT DOCUMENTS DEFINE TASKS reasibility study project infrastructure initial requirements project objectives CREATE INITIAL SCHEDULE CREATE INITIAL RISK ASSESMENT CREATE INITIAL ESTIMATE CREATE INITIAL QUALITY ASSUR. PLAN DEFINE PROJECT SCOPE project plan risk assessment master test quality assurance plan Purpose of this process is to initiate documents such as the project plan and project risk assessment. They must be started at the beginning of the project and then maintained throughout its life. Definice dokumentů pro management

21 JUSTIFY IDENTIFY IMPLEMEN- TATION ALTERNATIVES vision estimate requirements documentation schedule risk assessment DETERMINE OPERATIONAL FEASIBILITY DETERMINE TECHNICAL FEASIBILITY DETERMINE ECONOMIC FEASIBILITY CHOOSE ALTERNATIVE IDENTIFY RISKS feasibility study recommendations project funding risk assessment The purpose is to determine whether or not an application should be built. It is a reality check to determine whether or not a project makes a sense. Studie proveditelnosti Feasibility Study

22 DEFINE INFRASTRUCTURE SELECT TOOLS project plan initial requirements feasibility study existing infrastructure DEFINE TEAM SELECT STANDARDS AND GUIDELINES SELECT METHODO- LOGY NEGOTIATE DELIVE- RABLES GREATE GROUP KNOWLEDGE BASE team definition (profile, skill database,...) tools selection tailored software process group knowledges The project infrastructure is made up of the project team, the tools that they will use, and a tailored version of the software development process that the team will follow. Definice infrastruktury (Architektury projektu)

23 INITIATE PHASE Checklists

24 INITIATE entrance conditions checklist  senior management support exists to initiate a new project  maintenance changes pertaining to previous version (if any) are identified  infrastructure is available

25 INITIATE to be performed checklist  the initial requirements have been defined and validated  the initial management documents have been defined  the project has been technically, economically and operationally justified  required project infrastructure has been defined  potential reusable artifacts have been identified  project team has been identified and trained where appropriate

26 INITIATE exit conditions checklist  project plan has been accepted by senior management  project schedule has been accepted by senior mgmt  initial risk assessment has been performed  initial requirements have been accepted by senior management  appropriate standards and guidelines have been identified  software development process has been tailored to meet specific needs for the project  appropriate tools are prepared/installed  project funding has been obtained  project charter has been defined and accepted  project team has been assembled  lessons learned have been identified - team should take the time to consider the processes that could be improved

27 INITIATE PHASE Define and validate initial requirements Stage Checklists

28 Define and validate initial req. to be performed checklist  business process models have been developed and validated  user interface prototype has been developed and validated (if appropriate)  technical requirements have been documented and validated  operation and support requirements have been documented and validated  requirements have been prioritized  requests of appropriate stakeholders have been considered  reusable artifacts have been identified  risk assessment document has been updated  decisions (both made and forgone) were documented into group memory  metrics have been collected

29 Define and validate initial req. exit conditions checklist  requirement documents have been validated and accepted by the user community  requirement documents have been validated and accepted by the senior management  the scope of the project has been defined and accepted - definition of the functionality that will, and will not, be implemented

30 INITIATE PHASE Define the initial management documents Stage Checklists

31 Define the initial mgmt documents entrance conditions checklist  the project infrastructure has been selected  the feasibility study has been at least started  the project objectives have been identified and agreed to  initial requirements have been defined

32 Define the initial mgmt documents to be performed checklist  build-versus-buy decisions have been made  application release schedule has been defined or updated  project estimate has been developed and accepted  metric plan has been developed and accepted  project plan has been developed and accepted  assumptions and constraints have been documented  risk assessment has been started  test plan has been developed and accepted  reusable artifacts have been identified  risk assessment document has been updated  decisions (both made and forgone) were documented into group memory  metrics have been collected

33 Define the initial mgmt documents exit conditions checklist  initial version of the project plan has been accepted by senior management  initial version of the project plan has been accepted by the development team  initial version of the risk assessment has been accepted by senior management

34 INITIATE PHASE Justify Stage Checklists

35 Justify entrance conditions checklist  development of the requirements documents has begun  development of the project plan has begun  development of the risk assessment has begun  definition of the project infrastructure has begun  access to key users, technical experts, and financial experts has been obtained

36 Justify to be performed checklist  implementation alternatives were identified and considered  economic feasibility of each alternative was determined  cost/benefit analysis was performed  technical feasibility of each alternative was determined  operational feasibility of each alternative was determined  alternatives were suggested to senior management for approval  risk assessment document has been update  decisions (both made and forgone) were documented into group memory  metrics have been collected

37 INITIATE PHASE Define infrastructure Stage Checklists

38 Define infrastructure entrance conditions checklist  development of the initial requirements has begun  development of the project plan has begun  development of the feasibility study has begun  existing infrastructure is available

39 Define infrastructure to be performed checklist  project team has been defined  skill assessment for each team member has been defined  required training for each member has been defined and performed  project skill matrix was developed  potential subcontractors have been contracted  project deliverables have been negotiated with senior management and agreed to  group memory has been organized  shared library of books etc. is available  reusable artifacts have been identified  risk assessment document has been updated  decisions (both made and forgone) were documented into group memory  metrics have been collected

40 Define infrastructure exit conditions checklist  the team has been accepted by senior management  the tailored software process has been accepted by the team members  the tailored software process has been accepted by senior management  group memory has been initiated

41 PoznámkyPoznámky Co je to studie proveditelnostiCo je to studie proveditelnosti Co je to infrastruktura projektuCo je to infrastruktura projektu Rizika v inicializační fáziRizika v inicializační fázi Co je to Group MemoryCo je to Group Memory Co je to týmCo je to tým Co je to Change requestCo je to Change request

42 Feasibility study can the system be built (technically feasible) can we afford to build the system (economically feasible) can we maintain and support the system (operationally feasible)

43 Project infrastructure team defined for the project tools defined for the project processes defined/selected for the project

44 Potential risks in initiate phase senior management pressures to start too early pressure to bring people on the project too early beware the new toy syndrome resistance to change

45 Group memory records of what team accomplished decisions made lessons learned

46 Team definition description of who will be involved with a project incl. its reporting structure project skill matrix organization chart

47 Change requests software change request for potential improvements of the deliverable or inconsistency with the requirements software problem report of potential software defects identified

48 nastavit procesy včetně rolí participantů v procesech  zajistit potřebnou infrastrukturu (projektová kancelář, nástroje,...)  vyřešit problém měření kvality  vhodně nastavit motivační faktory podporovat objektově orientované paradigma  shromažďovat znovupožitelné komponenty (CONSTRUCT/generalize)  uchovávat všechna rozhodnutí a informace, budovat “group memory”  využívat “group memory” (INITIATE/justify)  rozvíjet lidský potenciál (DELIVER/assess) rozlišovat platformy (vývojová, testovací, provozní)  není možné se spoléhat na “zázračné” vlastnosti moderních nástrojů A na závěr! Pro řízení velkých projektů využívajících objektovou technologii je třeba

49