1. Teoria di Putnam Un tentativo di giustificare la valutazione di E, T e P con un modello matematico che fornisce una sorta di legge fondamentale (Equazione del Software) Una serie dimpatti interessanti (in particolare quello del tempo minimo di delivery)

2. Norden/Rayleigh distribution of H-resources usage a=2 a=.5 a=.25 a=.125 Max number of h-resources in the project

3. Full Effort E=K*0,4

4. Difficulty Factor Difficulty

5. Productivity Equation Basic foundation of the Putnams theory: Empirically justified! + L=S/E software equation C n is a technology constant

6. The Software Equation C is a technology constant (type of project) K – effort in man years including maintenance T- development time in years S - size of software in LOC C - 1500 for real-time embedded, 4984 for batch, 10040 for well-supported, organized environment E=K*0,4 For a given project (S estimation is fixed)

7. Minimal Time to Deliver If cost2 and C are known, than it is possible to estimate K and T (T is called the minimal time to deliver, before this minimal T the project would probably fail) For a given type of project: Add a new relationship Or (in Pressman): or

8. Classical Putnams Theory Tmin Required productivity Maximal personal productivity (per type of software) L p ; each person contribute to deliver LOC, L= L p

9. Personale e Tempo in Putnam Aumentando P è possibile diminuire T: Ciò è vero solo se tutti i P contribuiscono effettivamente alla definizione delle LOC

10. Impact I Tmin Estimated time to deliver LOC: Tdel New estimated time to deliver LOC: NewTdel Estimate delivery of LOC New effort to deliver on time Tdel Estimated effort to deliver by Tdel

11. Impact II Tmin Estimated time to deliver LOC: Tdel New estimated time to deliver LOC: NewTdel Estimate delivery of LOC New effort to deliver on time Tdel Estimated effort to deliver by Tdel

12. Impact III Tmin E T

13. Impact on Planning Develop the DB structure Develop the module A (accessing the DB) Develop the module B(accessing the DB) The minimal delivery time can be interpreted as the maximal parallel decomposition in tasks for a given project Indeed, project management tends to parallelize tasks as much as possible

14. Time to deliver and Tasks The parallel tasks of project plan can degenerate in a sequence if the number of h- resources are reduced Develop the DB structure Develop the module A (accessing the DB) Develop the module B (accessing the DB) Develop the DB structure Develop the module A (accessing the DB) Develop the module B(accessing the DB) If the programmer is the same person

15. Delivery time and Project Plan and Personnel It is very difficult adding personnel and changing project plans trying to parallellise taks Develop the DB structure Develop the module A (accessing the DB) Develop the module B (accessing the DB) Unplanned Communication Task Develop the DB structure Develop the module A (accessing the DB) Develop the module B(accessing the DB)