Illinois Institute of Technology

1. Illinois Institute of Technology CS487 Software Engineering David A. Lash

2. Project Elements • The planning & monitoring & control of people, process and event as software evolves • 2-4 developers working together may not need much but ... What about 30-40, 300? • Organized customer communication, right development process, estimated effort, quality checkpoints, on-going monitoring of tasks • Output is project plan with set(s) of tasks. • Manage, People, Product, Process and Project

3. Problem • What is the appropriate level of rigor? • What, if any, standards apply? • Software Scope • Context. • How does this item fit into a larger picture • Information objective. • What is the customer going to see. • Function and performance. • How is the software going to process the information.

4. People • All people who work in the development process are not interchangeable. • Many people find it objectionable to be called a resource. • Any time there are more than 1 person working to solve a problem, an organization is recommended

5. Development Team • What is teamwork? • Joint action by a group of people, in which individual interests are subordinated to group unity and efficiency; coordinated effort, as of an athletic team. • Team size about 4 people. Requires minimal training for the leader. • Each individual should have a unique primary function i.e. leader, librarian, developer, tester. • Periodically switch functions to cross train.

6. Development Team Organization • Democratic decentralized – no traditional leader. Works best when the average experience is 15 years +. Consensus decisions • Controlled decentralized – a defined leader with secondary leaders. Multiple teams. • Controlled Centralized – Managed by a team leader. Good for a cross section of people. Lead gets top-level decisions and internal coordination

7. Process • Selecting the right process? • Waterfall – Traditional

8. Process • Incremental – Solves a number of problems • Spiral – Must be adopted at the enterprise level.

9. How do you evaluate process? Are you using the process correctly? Are you using the correct process? What can you do better?

10. Capability Maturity Model • Developed and controlled by the Software Engineering Institute (SEI) • What is the CMM? • Arbitrary • Not a process • Develop for the DOD to evaluate software contractors. • Being adopted by a number of regulators. • Defines activities that should be going on. • Arranged to make easy to progress through the 5 levels.

11. CMM - Review 1. Chaotic - Productivity and Quality are based on individual effort. No control 2. Repeatable - Requirements Management, Project Planning, Quality Assurance, Configuration Management, Subcontractor management 3. Defined - Organization Process Focus, Organization Process Definition, Training Program 4. Managed - Quantitative Process Management, Software Quality Management 5. Optimizing - Defect Prevention, Technology change management, Process change management

12. Project Planning What are the tasks necessary for this project? How do these tasks relate to each other? Planning and scheduling are different: Planning defines the tasks, personnel and equipment necessary to deliver the product. To determine personnel requirements you must estimate the size of each task. Planning is done at the beginning of the project when you know the least about the problem

13. Estimating How long is the project going to take? First, how long is are the tasks going to take?

14. Estimating • Done early in the process high degree of error • Can only accurately estimate the next step. • Must re-plan at the beginning of each phase. • Establish size metric. • Estimation requires • Experience building this specific application • Knowledge of the Environment • History of similar projects

15. General Estimation Formula Where E is one person effort A, B and C are empirically derived constants EV is an estimation of some measure of size The values of A & B are calibrated for local environment using regression analysis and real data.

16. Three-point • Three-point or expected value Where Sopt - Optimistic Estimate Sm - Most-likely Estimate Spess - Pessimistic Estimate EV - Estimation Variable

17. Three-point • For example, assume to build a software module. Have some LOC estimates: • optimistic - 4600 • most likely - 6900 • pessimistic - 8600 • (4600 + 6900*4 + 8600)/6 = 6800 • Can also be useful for time to complete

18. Function Points • Good method for IT projects. Use Feature Points for embedded and systems projects • An estimation technique that uses the types of I/O for a problem to determine the size of the project • Called an early measure of size • Function Points convert directly to KLOC

19. Function Points • Method • Count of Information elements • Input files • Output files • Inquiry transactions • Logical files • External interfaces • Total “complexity” factors

20. Function Point Counting

21. Function Points Calculation • Where: - FP unadjusted = previous calculation - Fi = sum of complexity adjustment values based on subjective ratings from 0-5 on 14 complexity items:- 0 - no influence - 1 - incidental - 2 - moderate - 3 - average - 4 - significant - 5 - Essential

22. Complexity Factors

23. Complexity Factors

24. COCOMO Estimation • COnstructive COst Model - BB[89] COCOMO II BB[96] • Uses function points, KLOC or object points (A BB funct PT like metrics with different elements) • A hierarchy of estimation models for prototype, requirements established and post-architecture stages • Basic - Compute development effort as a function of size in KLOC • Intermediate - Compute development effort as a function of size and cost drivers (HW, people) • Advanced - Intermediate version plus assessment of cost driver impact on each step (e.g., analysis design, architecture)

25. COCOMO Project Types • Organic • In-house development • Small teams with extensive application experience • Characteristics • Stable development environment • Minimal need for innovative data processing • Low premium on early completion

26. COCOMO Project Types • Semidetached • One of two types of projects 1. An intermediate level of the project 2. A mixture of the organic and embedded • Characteristics • Team members have an intermediate level of experience • Team has a wide mixture of experienced and inexperienced people • Team members have experience related to some aspects of the system under development, but not others

27. COCOMO Project Types • Embedded • Not limited to our current definition of embedded meaning firmware, but also includes large scale turn-key system • A major distinguishing factor is a need to operate within tight constraints • Require a high degree of rigor

28. COCOMO: Basic Where E = Effort in person months D = Chronological months

29. COCOMO: Basic

30. COCOMO: Intermediate

31. COCOMO: Intermediate Where E = Effort in person months D = Chronological months EAF = Effort Adjustment Factor - based on subjective rating from very low to extra high on 15 project attributes

32. Effort Adjustment Cost Factors

33. Effort Adjustment Cost Factors

34. COCOMO example • Suppose used three-point analysis to estimate 33,200 LOC. • Using basic model get • E = 2.4(KLOC)**1.05 • -2.4(33.2)**1.05 • 96 person months • Duration would be • D = 2.5E**.38 • 2.5(95)**.38 • 12.3 months • Number of people = N=E/D N=96/12.3 = 8

35. Project Estimation Problems • No Requirements • No Designs • What is a KLOC? • 1000 lines of source code • Are all definitions of a line of code the same?

36. Project Scheduling and Tracking When will the project finish? Where is the project now?

37. Project Scheduling • Project Scheduling • Adding resources and personnel to establish a list of dates that monitor the development process • The last completion is when the project is complete • Adding more personnel will make it later. It also can change a projects profile • It is always better to be early than late

38. Project Scheduling Methods • PERT/CPM Charts • Calculate the path with the least amount of slack • Slack is the amount of time between when a task can begin and must begin • Timeline Charts

39. Project Tracking • Get status in a timely manner • Weekly at a low level • Monthly at a high level • Time sheet status reports • Separate time into project and non-project • Project time bill to specific task not project, category or charge code • To avoid 90% complete for 80% of the project. Use Earned Value to determine % completed

40. Project Tracking • Earned Value tells you where you are based on the completed tasks of your plan • Earned Value = task / project * 100 • Example: • In a 1000 hour project, a 15 hour task is 1.5% of the project. When it completes it adds 1.5% to the completion • Projected Earned Value tells you where your plan should be