Slides made by Sommerville adapted by Letizia Jaccheri, all the slides are part of the syllabus This lecture will be filmed

Transkript

1 Chapter 22 Project Management Chapter 23 Project Planning Letizia Jaccheri Professor Institutt for Datateknikk (IDI) Office 106, tel. (735)93469, Course home page Slides made by Sommerville adapted by Letizia Jaccheri, all the slides are part of the syllabus This lecture will be filmed 1

2 Project Management - software Altinn: Utviklingskontrakten hadde en kostnad på rundt 400 millioner kroner, mens den samlede prislappen var på rundt 1 milliard kroner. Grovt estimat Felles prosjekt 1MNOK cost Organization Budget Schedule Development team Process software functions quality 2

3 Management activities forvalting high-level.activity.violet Proposal: skriftlig forslag om å vinne en kontrakt for å utføre et arbeid. Forslaget beskriver målene for prosjektet og hvordan det skal gjennomføres Planning: Workbreakdown, estimering, scheduling (tildeling av resurser) (+++) Rapportering: Rapportering om fremdriften i et prosjekt til kunder og ledere (f.e. Fellesprosjekt, Accenture) Risikostyring: vurdere risikoene som kan påvirke et prosjekt, overvåke disse risikoene og iverksette tiltak når problemer oppstår (++) Ledelse: velg folk for team og etablere måter å jobbe som fører til effektiv laginnsats (+) 3

4 Planning 1. workbreakdown: bryte ned arbeidet i deler 2. Estimere kostnader (hardware, software, travel, training and effort costs) 3. Scheduling: plan til kalender og tildele tilgjengelige resurser Hvorfor? Prosjektplanen (som er opprettet ved starten av et prosjekt) blir brukt til å kommunisere hvordan arbeidet vil bli gjort til prosjektgruppen og kunder, og for å vurdere fremdriften på prosjektet. Når? proposal (pris); startfase; regelmessig

5 Project plan Introduction Project organization Risk analysis Hardware and software resource requirements Work breakdown Project schedule Monitoring and reporting mechanisms Ex: Suggestion: finn tilsvarende planer for OSS prosjekter Quality (++) Validation(++) Configuration management (++) Maintenance (++) Staff development

6 Schedule representation Graphical notations are normally used to illustrate the project schedule. These show the project breakdown into tasks. Tasks should not be too small. They should take about a week or two. Bar charts are the most commonly used representation for project schedules. They show the schedule as activities or resources against time.

7 The project planning process Figure 23.3 Violet

8 Scheduling: Tasks, durations, and dependencies Figure 23.5 See Open Proj View Gantt And View Network For effort see Exel Task Effort (persondays) Duration (days) T T Dependencies milestone T T1 (M1) T T T2, T4 (M3) T T1, T2 (M4) T T1 (M1) T T4 (M2) T T3, T6 (M5) T T7, T8 (M6) T T9 (M7) T T10, T11 (M8)

9 Activity bar chart Figure 23.7 Open Proj View Gantt

10 Staff allocation chart Figure 23.7 Open Proj View Resources See exel file

11 Project scheduling Scheduling bestemmer hvordan arbeidet i et prosjekt vil bli organisert som egne oppgaver, og når og hvordan disse oppgavene skal utføres. Man anslår kalenderen tiden som er nødvendig for å utføre oppgaven, og hvilke resurser som vil jobbe på de oppgavene som er identifisert. Man beregner de ressursene som trengs for å fullføre hver oppgave, for eksempel diskplass kreves på en server, den tiden som kreves på spesialisert maskinvare (cloudservices), og reisebudsjett

12 Milestones and deliverables Milepæler (milestones) er punkter i tidsplanen mot der man kan vurdere framdrift, for eksempel overlevering av system for testing. Leveranser (deliverables) er arbeid produkter som leveres til kunden, f.eks et krav dokumentet for systemet.

13 The project scheduling process Figure 23.4 Violet

14 Agile planning I motsetning til plan-drevet tilnærminger, er funksjonaliteten til disse trinn ikke planlagt på forhånd, men avgjøres i løpet av utviklingen. Release planlegging, som ser fremover i flere måneder og bestemmer hvilke funksjoner som bør inkluderes i en utgivelse av et system. + + Iterasjon planlegging, som har en kortere sikt, og fokuserer på planlegging av neste iterasjon av et system. Dette er vanligvis 2-4 uker med arbeid for team et.

15 Planning in XP Figure 23.8 Model Violet

16 The risk management process Risk identification Identify project, product and business risks; Risk analysis Assess the likelihood and consequences of these risks; Risk planning Draw up plans to avoid or minimise the effects of the risk; Risk monitoring Monitor the risks throughout the project; 16

17 Examples of common project, product, and business risks Figure 22.1 Risk Affects Description Staff turnover Project Experienced staff will leave the project before it is finished. Management change Project There will be a change of organizational management with different priorities. Hardware unavailability Project Hardware that is essential for the project will not be delivered on schedule. Requirements change Project and product There will be a larger number of changes to the requirements than anticipated. Specification delays Project and product Specifications of essential interfaces are not available on schedule. Size underestimate Project and product The size of the system has been underestimated. CASE tool underperformance Product CASE tools, which support the project, do not perform as anticipated. Technology change Business The underlying technology on which the system is built is superseded by new technology. Product competition Business A competitive product is marketed before the system is completed. Chapter 22 Project management 17

18 Examples (Instances) of different risk types Fig Det er lov å «kopiere» hvis det er relevant Risk type Technology Possible risks The database used in the system cannot process as many transactions per second as expected. (1) Reusable software components contain defects that mean they cannot be reused as planned. (2) People It is impossible to recruit staff with the skills required. (3) Key staff are ill and unavailable at critical times. (4) Required training for staff is not available. (5) Organizational The organization is restructured so that different management are responsible for the project. (6) Organizational financial problems force reductions in the project budget. (7) Tools The code generated by software code generation tools is inefficient. (8) Software tools cannot work together in an integrated way. (9) Requirements Changes to requirements that require major design rework are proposed. (10) Customers fail to understand the impact of requirements changes. (11) Estimation The time required to develop the software is underestimated. (12) The rate of defect repair is underestimated. (13) The size of the software is underestimated. (14) Chapter 22 Project management 18

19 Risk types and examples (ERRATA!) Figure 22.4 Risk examples: probability and effects Risk Probability Effects Organizational financial problems force reductions in the project budget (7). It is impossible to recruit staff with the skills required for the project (3). Low High Catastrophic Catastrophic Key staff are ill at critical times in the project (4). Moderate Serious Faults in reusable software components have to be repaired before these components are reused. (2). Changes to requirements that require major design rework are proposed (10). The organization is restructured so that different management are responsible for the project (6). The database used in the system cannot process as many transactions per second as expected (1). Moderate Moderate High Moderate Serious Serious Serious Serious Chapter 22 Project management 19

20 (2) Risk Probability Effects The time required to develop the software is underestimated (12). High Serious Software tools cannot be integrated (9). High Tolerable Customers fail to understand the impact of requirements changes (11). Moderate Tolerable Required training for staff is not available (5). Moderate Tolerable The rate of defect repair is underestimated (13). Moderate Tolerable The size of the software is underestimated (14). High Tolerable Code generated by code generation tools is inefficient (8). Moderate Insignificant Chapter 22 Project management 20

21 Estimation techniques Erfaringsbaserte teknikker Anslaget for fremtidige innsats er basert på lederens (organisasjonens) erfaring fra tidligere prosjekter og søknaden domenet. Lederen gjør en vurdering av hva innsatsen er sannsynlig til å være. Algoritmisk kostnader prosjektet innsats beregnes basert på estimater for produktattributter, for eksempel størrelse, og prosessen egenskaper Cocomo II modellen er en algoritmisk kostnadsmodell som bruker prosjekt, produkt, maskinvare og personell attributter samt produkt størrelse og kompleksitet attributter for å beregne et kostnadsoverslag. Pensum - forståelsenivå

22 Experience-based approaches Erfaringsbaserte teknikker stole på vurdering basert på erfaring fra tidligere prosjekter og innsats Vanligvis identifiserer man leveransen og de forskjellige software komponenter som skal utvikles. Man dokumenterer aktiviteter i et regneark, anslår dem individuelt og beregne den totale innsatsen (effort) It usually helps to get a group of people involved in the effort estimation and to ask each member of the group to explain their estimate.

23 Staffing requirements Person allokering er mer komplisert enn å dele ut personer utover planen Antallet personer som jobber på et prosjekt varierer avhengig av hvilken fase av prosjektet. En svært hurtig oppbygging av resurser kan være uhensiktsmessig

24 Ledelse - Teamwork Software engineering handler om grupper som utvikler programvare Forskjellige prosesser har forkjellig fokus på lederskap, f.e. hvem som planlegger Viktig kommunikasjon tiltak som forbedrer samarbeid Les kapittel og reflekter over emner før og gjennom fellesprosjekt Andre fag som Arbeid i Team, Eksperter i team Chapter 22 Project management 24

25 Conclusions Ch 22 and 23 Estimering (23) ++ Risiko (22) ++ Managing people (22) Teamwork (22) Chapter 22 Project management 25