CS /39 Illinois Institute of Technology CS487 Software Engineering David A. Lash

CS /39 Project Elements u 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

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

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

CS /39 Development Team u 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. u Team size about 4 people. Requires minimal training for the leader. u Each individual should have a unique primary function i.e. leader, librarian, developer, tester. u Periodically switch functions to cross train.

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

CS /39 Process u Selecting the right process? – Waterfall – Traditional

CS /39 Process – Incremental – Solves a number of problems – Spiral – Must be adopted at the enterprise level.

CS /39 How do you evaluate process? u Are you using the process correctly? u Are you using the correct process? u What can you do better?

CS /39 Capability Maturity Model u Developed and controlled by the Software Engineering Institute (SEI) u 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.

CS /39 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

CS /39 Project Planning u What are the tasks necessary for this project? u How do these tasks relate to each other? u 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

CS /39 Estimating u How long is the project going to take? u First, how long is are the tasks going to take?

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

CS /39 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.

CS /39 Three-point u Three-point or expected value Where S opt - Optimistic Estimate S m - Most-likely Estimate S pess - Pessimistic Estimate EV- Estimation Variable

CS /39 Three-point u For example, assume to build a software module. Have some LOC estimates: – optimistic – most likely – pessimistic – ( * )/6 = 6800 u Can also be useful for time to complete

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

CS /39 Function Points u Method – Count of Information elements u Input files u Output files u Inquiry transactions u Logical files u External interfaces – Total “complexity” factors

CS /39 Function Point Counting

CS /39 Function Points Calculation Where: - FP unadjusted = previous calculation - F i = sum of complexity adjustment values based on subjective ratings from 0-5 on 14 complexity items: no influence incidental moderate average significant Essential

CS /39 Complexity Factors

CS /39 Complexity Factors

CS /39 COCOMO Estimation u COnstructive COst Model - BB[89] COCOMO II BB[96] u Uses function points, KLOC or object points (A BB funct PT like metrics with different elements) u 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)

CS /39 COCOMO Project Types u Organic – In-house development – Small teams with extensive application experience – Characteristics u Stable development environment u Minimal need for innovative data processing u Low premium on early completion

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

CS /39 COCOMO Project Types u 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

CS /39 COCOMO: Basic Where E = Effort in person months D = Chronological months

CS /39 COCOMO: Basic

CS /39 COCOMO: Intermediate

CS /39 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

CS /39 Effort Adjustment Cost Factors

CS /39 Effort Adjustment Cost Factors

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

CS /39 Project Estimation Problems u No Requirements u No Designs u What is a KLOC? – 1000 lines of source code u Are all definitions of a line of code the same?

CS /39 Project Scheduling and Tracking u When will the project finish? u Where is the project now?

CS /39 Project Scheduling u 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

CS /39 Project Scheduling Methods u PERT/CPM Charts – Calculate the path with the least amount of slack u Slack is the amount of time between when a task can begin and must begin u Timeline Charts

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

CS /39 Project Tracking u Earned Value tells you where you are based on the completed tasks of your plan u Earned Value = task / project * 100 u 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 u Projected Earned Value tells you where your plan should be