BUS-119A Lecture #11 dbg SJSU 4/8/03

1. - Homework #2 is due today • “Effort” to produce a Product i.e.. Staffing • Complexity – key: the Number of interactions • Effort by Project Phase (Design, Test, etc) • Optimal Module size (for large products) • Homework #3 assigned, due next week. BUS-119A Lecture #11 dbg SJSU 4/8/03

2. - Project Needs in resources (workforce) first increase then decrease over time - Number of people on a project peaks prior to shipping the product - Module size needs to be limited (complexity) - Complexity of interactions - Interactions between people and teams - Interactions between modules in a product Effort over Time and Modularization

3. Project with more people is more complex Product with more modules is more complex INTERACTION (I) OF N=6 ITEMS: Complexity Depends on Number Of Items 1 2 I=N*(N-1)/2 I=6*5/2=15 I ~ K* N**2 3 6 5 4

4. CENTRALIZED HIERARCHICAL One Manager Two Team Leaders Six Items: CENTRALIZED and HIERARCHICAL 2 1 2 1 6 3 6 3 4 5 4 5 I=N-1 I=6-1=5 I=1+2*(N-1) I=1+2*2=5

5. Putnam's formula: S=Spending per month or per week (mostly cost of the workforce) D= Time when number of people on the project reaches its peak (Sp) Ts=Time when the product is ready to ship which is at time when S falls to Sp/2 Te= Time when product reaches "End of Life" K=Total spending over life of the project is equal to the area under the curve S=(K*t/D**2)*e(-t**2/(2*D**2)) Workforce profile Over Project Time

6. K=60, D=6 putnam.123 dbg 11/7/00

7. staffing.prz dbg 11/7/00 Project needs 8 (Person*Years) effort. How to estimate staff size by month: Staffing over Time Rectangular Distribution Rectangular Distribution Rectangular Distribution Triangular Distribution # of people working each month # of people working each month # of people working each month # of people working each month 16 16 8 8 8 8 8 12 12 12 6 12 12 time in months time in months time in months time in months time in months time in months

8. Approximate ratio of Phase Cost to Cumulative cost to ship time (varies by project and by experience of the team): Effort Distribution by Product Phase - Requirements 8% 8 - Fn. Spec 6% 14 - Logic 6% 20 - Module design 12% 32 - Coding 13% 45 - Unit Testing 13% 58 - Function Test 24% 82 - System Test 12% 94 • User Documentation 6% 100% • Total effort on project=100%

9. Optimal Module Size - Tradeoff between: - Intramodule Complexity and - Intermodule Complexity - Small modules (50 LOC) result in a large number of modules in a large product. - Large modules (1000 LOC) result in a hard to understand module to maintain. - Optimum is around 200 LOC/Module Example: A product estimated to be 50 KLOC = 50,000 LOC should have around M=50,000/200=500/2=250 modules.

10. (a) In homework #2 you determined the size of your product that is measured in LOC and then you calculated the Effort (in Person*Months or PY) that is needed to develop the product. Now we learned that the workforce increases and then decreases over project time (use triangular distribution). Determine (a1) what will be the the peak number of employees on the project and (a2) At what time from the beginning of the project is that peak reached? (b) How many modules will have to be written if we use the optimal module size stated in the lecture? (c) Assuming effort distribution over phases as stated in the lecture, how much effort i.e (how many Person*Months) would be needed for Coding your product? Homework #3 due at next lecture

11. If a product size is estimated at: 12,300 LOC and Productivity is 2KLOC/PY then the effort is E=(12.3 KLOC)/(2KLOC/PY)=6.1 PY If the project needs to be completed in 6 months, then we need 12.3 people working on it for 6 mo. Assuming triangular workforce distribution we need a peak workforce of 24.3=25 people at the time 3 months from the start of the project. Number of modules is 12.3/.2=61.5=62. The effort for coding is = .13*6.1 PY=.79 PY. Example of Estimation for Software Projects

12. Acceptability - Interest and need of customers to get a product and use it. Adaptability - Change in one component does not require extensive changes in others. Applicability - Match between functional claims that product offers and customer needs. Assistability - Degree to which a product helps customers in doing certain tasks. Availability - Percent of time that a product is able to run out of all required time Capability - Functionality or Ability (FUNCTION) This is the key ability Feasibility - Likelihood of achieving objectives (or requirements) Flexibility - System's ability to adapt to changing requirements. Functionality - Systems scope of functions it can perform (ex. Sort, Print etc.) Installability - How easy it is to install the product Interoperability - Ability of the different HW and SW to work in unison Maintainability - Ability to modify, understand and test when changes are needed. Modularity - Product built in a way where change in one module has minimal impact on others. Performance - Primarily speed of transfer or processing. It may mean all "abilities". Reliability - Time or frequency that the system or program failing (QUALITY) Reusability - Ability of products to be used in new systems or with heavy modifications. Portability - Ability of a product to run on different hardware and different operating systems Profitability - Ratio of (Revenue-Cost)/Cost Serviceability - Ease of repair. Depends on built in debugging facilities and documentation. Usability - Nature of the product where user can easily install, learn and use the product. Upgradeability - Ease of adding an increase in a resource. For example going from 128MBy to 256 MBy) Viability – Likelihood of making the product a success RAS = Reliability, Availability, and Serviceability Product Abilities – Function and Quality are the key