UNIT-I

1. SOFTWARE ENGINEERING PROCESS PARADIGMS

What is Software Engineering? Many Definitions the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. (Bauer 1969) The application of science and mathematics by which the capabilities of computer equipment are made useful to man via computer programs, procedures, and associated documentation. (Boehm 1981) The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is the application of engineering to software. (IEEE 1993) Designing, building and maintaining large software systems in a cost-effective way. SOFTWARE PROCESS MODELS

THE LINEAR SEQUENTIAL MODEL:

One phase has to be complete before moving onto the next phase. Each phase terminates only when the documents are complete and approved by the SQA group. Phases: Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance Advantages Disciplined approach Careful checking by the Software Quality Assurance Group at the end of each phase. Testing in each phase. Documentation available at the end of each phase. Disadvantages It is difficult to respond to changing customer requirements. Therefore, this model is only appropriate when the requirements are well-understood. Few business systems have stable requirements. The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway.One phase has to be complete before moving onto the next phase. The customer must have patience. A working version of the program will not be available until late in the project time-span Feedback from one phase to another might be too late and hence expensive. PROTOTYPING MODEL:

Often, a customer defines a set of general objectives for software but does not identify detailed input, processing, or output requirements. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system. In this case prototyping paradigm may offer the best approach.

The quick design leads to the construction of a prototype. The prototype is evaluated by the customer. Advantages Requirements can be set earlier and more reliably Customer sees results very quickly. Customer is educated in what is possible helping to refine requirements. Requirements can be communicated more clearly and completely Between developers and clients Requirements and design options can be investigated quickly and Cheaply Disadvantages Requires a rapid prototyping tool and expertise in using ita cost for the development organization looks like a working version, but it is not. THE RAD MODEL Rapid application development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle. The RAD model is a high-speed adaptation of the linear sequential model in which rapid development is achieved by using component-based construction. If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a fully functional system within very short time periods (e.g., 60 to 90 days) RAD phases

 Business modeling Data modeling Process modeling Application generation Testing and turnover Business modeling: What information drives the business process? What information is generated? Who generates it? Data Modeling: The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristics ( called attributes) of each object are identified and the relationships between these objects are defined Process modeling: The data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding , modifying, deleting, or retrieving a data object Application generation: RAD assumes the use of 4 generation techniques. Rather than creating software using conventional 3 generation programming languages, the RAD process works to reuse existing program components (when possible) or created reusable components (when necessary) Testing and Turnover: Since the RAD process emphasizes reuse, many of the program components have already been testing. This reduces over all testing time. However, new components must be tested and all interfaces must be fully exercised Advantages: Extremely short development time. Uses component-based construction and emphasizes reuse and code generation Disadvantages: Large human resource requirements (to create all of the teams). Requires strong commitment between developers and customers for rapid-fire activities. High performance requirements maybe cant be met (requires tuning the components). EVOLUTIONARY SOFTWARE PROCESS MODELS: Evolutionary models are iterative. They are characterized in a manner that enables software engineers to develop increasingly more complete versions of the software. Advantages: Deals constantly with changes Provides quickly an initial version of the system Involves all development teams Disadvantages: Quick fixes may be involved

Invisible process, not well-supported by documentation The systems structure can be corrupted by continuous change Special tools and techniques may be necessary The client may have the impression the first version is very close to the final product and thus be less patient Applicability: When requirements are not well understood When the client and the developer agree on a rapid prototype that will be thrown away Good for small and medium-sized software systems Phases: The Incremental Model The Spiral Model The WINWIN Spiral Model The Concurrent Development Model 1. The Incremental Model

Advantages Provides better support for process iteration Reduces rework in the software construction process Some decisions on requirements may be delayed Allows early delivery of parts of the system Supports easier integration of sub-systems Lower risk of project failure Delivery priorities can be more easily set

Disadvantages: Increments need be relatively small Mapping requirements to increments may not be easy Common software facilities may be difficult to identify Applicability: When it is possible to deliver the system part-by-part 2. The Spiral Model

The spiral model, originally proposed by Boehm Using the spiral model, software is developed in a series of incremental releases. During early iterations, the incremental release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced. A spiral model is divided into a number of framework activities, also called task regions. Typically spiral model that contains six task regions. Customer communication tasks required to establish effective communication between developer and customer. Planning tasks required to define resources, timelines, and other project related information. Risk analysis tasks required to assess both technical and management risks. Engineering tasks required to build one or more representations of the application. Construction and release tasks required to construct, test, install, and provide user support (e.g., documentation and training). Customer evaluation tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.

Advantages: Focuses attention on reuse options. Focuses attention on early error elimination. Puts quality objectives up front. Integrates development and maintenance. Provides a framework for hardware/software Development. Risk reduction mechanisms are in place Supports iteration and reflects real-world practices Systematic approach Disadvantages: Requires expertise in risk evaluation and reduction Complex, relatively difficult to follow strictly Applicable only to large systems Applicability: Internal development of large systems 3. The WINWIN Spiral Model The objective of this activity is to elicit project requirements from the customer. The best negotiations strive for a win-win result.

Activities: 1. Identification of the system or subsystems key stakeholders.8 2. Determination of the stakeholders win conditions. 3. Negotiation of the stakeholders win conditions to reconcile them into a set of win-win conditions for all concerned (including the software project team). The WINWIN spiral model introduces three process milestones, called anchor points. The first anchor point, life cycle objectives (LCO), defines a set of objectives for each major software engineering activity.

The second anchor point, life cycle architecture (LCA), establishes objectives that must be met as the system and software architecture is defined. Initial operational capability (IOC) is the third anchor point and represents a set of objectives associated with the preparation of the software for installation. 4. The Concurrent Development Model Sometimes called concurrent engineering, by Davis and Sitaram.

COMPONENT-BASED DEVELOPMENT The component-based development (CBD) model incorporates many of the characteristics of the spiral model. component-based development model composes applications from prepackaged software components (called classes).

THE FORMAL METHODS MODEL Use of mathematical techniques to specify the requirements of the system e.g. the B method, Z, VDM, Object-Z Mainly used in life or mission-critical applications, e.g heart pacemakers, NASA Can get very high quality software Problems o Time-consuming and expensive o Few developers have necessary skills, so extensive training required o Difficult to use as a tool to communicate with users FOURTH GENERATION TECHNIQUES The term fourth generation techniques (4GT) encompasses a broad array of software tools that have one thing in common. The tool then automatically generates source code based on the developer's specification. Large projects require as much or more analysis, design and testing to achieve the time gains from the elimination of coding Often problems with efficiency of automatically generated code.

2. PROJECT MANAGEMENT
THE MANAGEMENT SPECTRUM Effective software project management focuses on the four Ps: people, product, process, and project. The People The Product The Process The Project

THE PEOPLE 1. The Players: 1. Senior managers who define the business issues that often have significant influence on the project. 2. Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work. 3. Practitioners who deliver the technical skills that are necessary to engineer a product or application. 4. Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. 5. End-users who interact with the software once it is released for production use. 2. Team Leaders: o Project management is a people-oriented activity People with great technical skills dont necessarily make good team leaders people skills are needed too o Weinberg suggests an MOI model of leadership Motivation Ability to encourage technical people to work to the best of their abilities (push or pull) Organization Ability to adapt existing processes, or devise new ones, to enable the concept to be turned into a product Ideas/Innovation Ability to encourage people to create, and to feel creative, within the bounds of the particular product Another view of what makes a good team leader: o Problem solving Decide which technical and organizational issues are most important Create a systematic solution to the problem or motivate others to do so Apply lessons from past projects to new ones Remain flexible enough to change direction if initial proposed solution doesnt work o Managerial Identity Confidence to take charge of project when necessary, but also to let good technical people use their initiative o Achievement Reward initiative and accomplishment Demonstrate that controlled risk-taking will not be punished o Influence and Team building Be able to read people understand both verbal and non-verbal signals from team members, and react to their needs 3. The Software Team:

Democratic decentralized (DD) Communication among team members is horizontal. Controlled decentralized (CD) - Communication among subgroups and individuals is horizontal. Controlled Centralized (CC) - Communication between the leader and team members is vertical. seven project factors The difficulty of the problem to be solved. The size of the resultant program(s) in lines of code or function points The time that the team will stay together (team lifetime). The degree to which the problem can be modularized. The required quality and reliability of the system to be built. The rigidity of the delivery date. The degree of sociability (communication) required for the project. 4. Coordination and Communication Issues: Scale: many projects are large, leading to complexity, confusion and major difficulties in coordinating people Uncertainty: scope and requirements change is common, often resulting in continuous addition to the team load Interoperability: new software must communicate with existing systems. Project Coordination Techniques o Formal, impersonal approaches Software engineering documents and deliverables (including source), technical memos, project milestones, schedules and PM tools, change requests & documentation, error tracking reports, etc. o Formal, interpersonal procedures Focus on quality assurance activities applied to the work products: status review meetings, design and code inspections (walkthroughs) o Informal, interpersonal procedures Group meetings for communication of information, problem solving, and getting requirements and development staff together o Electronic communication Email, bulletin boards, video conferencing o Interpersonal network Informal discussions with team members and outside experts You should consider applying some or all of these techniques in your group project THE PRODUCT 1. Software Scope Context - How does the software to be built fit into a larger system, product, or business context and what constraints are imposed as a result of the context? Information objectives - What customer-visible data objects are produced as output from the software? What data objects are required for input?

Function and performance - What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed? 2. Problem Decomposition Called partitioning or problem elaboration Two major areas: (1) the functionality that must be delivered and (2) the process that will be used to deliver it. THE PROCESS The project manager must decide which process model is most appropriate for (1) the customers who have requested the product and the people who will do the work (2) the characteristics of the product itself (3) the project environment in which the software team works. 1. Melding the Product and the Process: Customer communicationtasks required to establish effective requirements elicitation between developer and customer. Planningtasks required to define resources, timelines, and other project related information. Risk analysistasks required to assess both technical and management risks. Engineeringtasks required to build one or more representations of the application. Construction and releasetasks required to construct, test, install, and provide user support Customer evaluationtasks required to obtain customer feedback based on evaluation of the software. 2. Process Decomposition: Once the process model has been chosen, the common process framework (CPF) is adapted to it. In every case, the CPF discussed earlier in this chaptercustomer communication, planning, risk analysis, engineering, construction and release, customer evaluationcan be fitted to the paradigm. THE PROJECT Ten signs that indicate that a project is in trouble: Technical people dont understand customers needs Product scope is poorly defined Change management is poor Change in technology chosen for solution Business needs change or are not well defined Deadlines are not realistic Users are resistant to the proposed solution Sponsorship is lost, or was never actually obtained Project team lacks people with the right skills Managers and team members resist best-practice, and lessons learned on previous projects How does a project manager avoid these problems? Start on the right foot Work very hard to understand the problem Set realistic objectives and expectations for team Give team members autonomy, authority and appropriate technology

Maintain momentum Provide incentives to minimize turnover of personnel Ensure that team emphasizes quality in every task Avoid getting in teams way! Track progress Work products are produced and approved by formal technical review Project and process metrics can be gathered and compared with historical data Make smart decisions Keep It Simple, Stupid Use off-the-shelf software and/or components where possible Avoid custom interfaces if a standard is available Identify and avoid obvious risks Allocate more time than you think is needed to risky or complex tasks Conduct a post-mortem analysis Establish a mechanism for extracting lessons-learned from completed projects: planned vs. actual schedule, metrics, feedback from team members and customers Record findings in written form THE W5HH PRINCIPLE Why is the system being developed? What will be done, by when? Who is responsible for a function? Where are they organizationally located? How will the job be done technically and managerially? How much of each resource is needed?

3. PROCESS AND PROJECT METRICS

WHAT ARE METRICS? Software process and project metrics are quantitative measures They are a management tool They offer insight into the effectiveness of the software process and the projects that are conducted using the process as a framework Basic quality and productivity data are collected These data are analyzed, compared against past averages, and assessed The goal is to determine whether quality and productivity improvements have occurred The data can also be used to pinpoint problem areas Remedies can then be developed and the software process can be improved REASON TO MEASURE To characterize in order to

o Gain an understanding of processes, products, resources, and environments o Establish baselines for comparisons with future assessments To evaluate in order to o Determine status with respect to plans To predict in order to o Gain understanding of relationships among processes and products o Build models of these relationships To improve in order to o Identify roadblocks, root causes, inefficiencies, and other opportunities for improving product quality and process performance

MEASURES, METRICS, AND INDICATORS metric as a quantitative measure of the degree to which a system, component, or process possesses a given attribute. An indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself. METRICS IN THE PROCESS AND PROJECT DOMAIN Process indicators enable a software engineering organization to gain insight into the efficacy of an existing process. Project indicators enable a software project manager (1) assess the status of an ongoing project (2) track potential risks, (3) uncover problem areas before they go critical, (4) adjust work flow or tasks, (5) evaluate the project teams ability to control quality of software work products. 1. Process Metrics and Software Process Improvement private metrics include defect rates (by individual), defect rates (by module), and errors found during development. Public metrics generally assimilate information that originally was private to individuals and teams. Project level defect, effort, calendar times, and related data are collected and evaluated in an attempt uncover indicators that can improve organizational process performance. software metrics etiquette: Use common sense and organizational sensitivity when interpreting metrics data. Provide regular feedback to the individuals and teams who collect measures and metrics. Dont use metrics to appraise individuals. Work with practitioners and teams to set clear goals and metrics that will be used to achieve them. Never use metrics to threaten individuals or teams. Metrics data that indicate a problem area should not be considered negative. These data are merely an indicator for process improvement. Dont obsess on a single metric to the exclusion of other important metrics. Statistical software process improvement (SSPI): 1. All errors and defects are categorized by origin. 2. The cost to correct each error and defect is recorded.

3. The number of errors and defects in each category is counted and ranked in descending order. 4. The overall cost of errors and defects in each category is computed. 5. Resultant data are analyzed to uncover the categories that result in highest cost to the organization. 6. Plans are developed to modify the process with the intent of eliminating (or reducing the frequency of) the class of errors and defects that is most costly. 2. Project Metrics The first application of project metrics on most software projects occurs during estimation. Metrics collected from past projects are used as a basis from which effort and time estimates are made for current software work. Another model of software project metrics suggests that every project should measure: Inputs measures of the resources (e.g., people, environment) required to do the work. Outputs measures of the deliverables or work products created during the software engineering process. Results measures that indicate the effectiveness of the deliverables. SOFTWARE MEASUREMENT Direct measures lines of code (LOC) produced, execution speed, memory size, and defects reported over some set period of time. Indirect measures functionality, quality, complexity, efficiency, reliability, maintainability, and many other "abilities" 1. Size-Oriented Metrics

A set of simple size-oriented metrics can be developed for each project: Errors per KLOC (thousand lines of code). Defects4 per KLOC. $ per LOC. Page of documentation per KLOC. In addition, other interesting metrics can be computed:

 Errors per person-month. LOC per person-month. $ per page of documentation. 2. Function-Oriented Metrics

Function-oriented metrics were first proposed by Albrecht, who suggested a measure called the function point. Errors per FP. Defects per FP. $ per FP. Pages of documentation per FP. FP per person-month. 3. Extended Function Point Metrics A function point extension called feature points The feature point measure accommodates applications in which algorithmic complexity is high. The feature point metric counts a new software characteristicalgorithms. 3D function point: data dimension functional dimension control dimension RECONCILING DIFFERENT METRICS APPROACHES LOC and FP depends upon the programming languages.

METRICS FOR SOFTWARE QUALITY The overriding goal of software engineering is to produce a high-quality system, application, or product. To achieve this goal, software engineers must apply effective methods coupled with modern tools within the context of a mature software process. 1. An Overview of Factors That Affect Quality (1) product operation (using it), (2) product revision (changing it), (3) product transition (modifying it). 2. Measuring Quality Correctness: The most common measure for correctness is defects per KLOC. Maintainability: mean-time-to-change (MTTC) Spoilage Integrity: measures a system's ability to withstand attacks to its security. Attacks can be made on all three components of software: programs, data, and documents. Threat is the probability that an attack of a specific type will occur within a given time. Security is the probability that an attack of a specific type will be repel. integrity = summation [(1 threat)*(1 security)] Usability: 3. Defect Removal Efficiency DRE is a measure of the filtering ability of quality assurance and control activities. DRE = E/(E + D) E is the number of errors found before delivery of the software to the end-user D is the number of defects found after delivery. The ideal value for DRE is 1.

INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS 1. Arguments for Software Metrics If we do not measure, there no real way of determining whether we are improving. And if we are not improving, we are lost. 2. Establishing a Baseline By establishing a metrics baseline, benefits can be obtained at the process, project, and product levels. The metrics baseline consists of data collected from past software development projects. (1) data must be reasonably accurate (2) data should be collected for as many projects as possible; (3) measures must be consistent, (4) applications should be similar to work 3. Metrics Collection, Computation, and Evaluation Data collection requires a historical investigation of past projects to reconstruct required data. Metrics must be evaluated and applied during estimation, technical work, project control, and process improvement.

4. SOFTWARE ESTIMATION
To achieve reliable cost and effort estimates, a number of options arise: 1. Delay estimation until late in the project 2. Base estimates on similar projects that have already been completed. 3. Use relatively simple decomposition techniques to generate project cost and effort estimates. 4. Use one or more empirical models for software cost and effort estimation. EMPIRICAL ESTIMATION MODELS An estimation model for computer software uses empirically derived formulas to predict effort as a function of LOC or FP. 1. The Structure of Estimation Models E = A + B x (ev)C A, B, and C are empirically derived constants, E is effort in person-months ev is the estimation variable (either LOC or FP). LOC-oriented estimation models E = 5.2 x (KLOC)0.91 (Walston-Felix model)

E = 5.5 + 0.73 x (KLOC)1.16 (Bailey-Basili model) E = 3.2 x (KLOC)1.05 (Boehm simple model) E = 5.288 x (KLOC)1.047 (Doty model for KLOC > 9) FP-oriented estimation models. E = 13.39 + 0.0545 FP (Albrecht and Gaffney model) E = 60.62 x 7.728 x 10-8 FP3 (Kemerer model) E = 585.7 + 15.12 FP (Matson, Barnett, and Mellichamp model) 2. The COCOMO Model COnstructive COst Model COCOMO II: o Application composition model(during the early stages of software engineering) o Early design stage model (once requirements have been stabilized and basic software architecture has been established.) o Post-architecture-stage model (during the construction of the software.) Three different sizing options are available as part of the model hierarchy: o object points, function points, and lines of source code. The COCOMO II application composition model uses object points The object point is an indirect software measure that is computed using counts of the number of (1) screens, (2) reports, (3) components likely to be required to build the application.

Each object instance is classified into one of three complexity levels (i.e., simple, medium, or difficult) NOP = (Object points) x [(100 %reuse)/100] o new object points PROD = NOP/person-month o Productivity rate Estimated effort = NOP/PROD 2. The Software Equation The software equation is a dynamic multivariable model. The model has been derived from productivity data collected for over 4000 contemporary software projects. E = [LOC B0.333/P]3 (1/t4) o E = effort in person-months or person-years o t = project duration in months or years o B = special skills factor16

o P = productivity parameter that reflects: Overall process maturity and management practices The extent to which good software engineering practices are used The level of programming languages used The state of the software environment The skills and experience of the software team The complexity of the application The software equation has two independent parameters: o an estimate of size (in LOC) o an indication of project duration in calendar months or years. Putnam and Myers suggest a set of equations derived from the software equation. Minimum development time is defined as tmin = 8.14 (LOC/P)0.43 in months for tmin > 6 months (5-4a) E = 180 Bt3 in person-months for E 20 person-months

5. RISK ANALYSIS
REACTIVE VS. PROACTIVE RISK STRATEGIES A reactive strategy monitors the project for likely risks. Software team does nothing about risks until something goes wrong. Then, the team flies into action in an attempt to correct the problem rapidly. This is often called a fire fighting mode. More intelligent strategy for risk management is to be proactive. A proactive strategy begins long before technical work is initiated. Potential risks are identified, their probability and impact are assessed, and they are ranked by importance. Then, the software team establishes a plan for managing risk. SOFTWARE RISKS Risk always involves two characteristics: Uncertaintythe risk may or may not happen; that is, there are no 100% probable risks. Lossif the risk becomes a reality, unwanted consequences or losses will occur. Different categories of risks: Project risks - threaten the project plan. Technical risks - threaten the quality and timeliness of the software Business risks - threaten the viability of the software to be built. Another general categorization of risks has been proposed by Charette: Known risks Predictable risks Unpredictable risks RISK IDENTIFICATION

Systematic attempt to specify threats to the project plan o Generic risks - potential threat to every software project. o Product-specific risks - can be identified only by those with a clear understanding of the technology, the people, and the environment that is specific to the project at hand. One method for identifying risks is to create a risk item checklist. o Product size o Business impact o Customer characteristics o Process definition o Development environment o Technology to be built o Staff size and experience

1. Assessing Overall Project Risk 1. Have top software and customer managers formally committed to support the project? 2. Are end-users enthusiastically committed to the project and the system/product to be built? 3. Are requirements fully understood by the software engineering team and their customers? 4. Have customers been involved fully in the definition of requirements? 5. Do end-users have realistic expectations? 6. Is project scope stable? 7. Does the software engineering team have the right mix of skills? 8. Are project requirements stable? 9. Does the project team have experience with the technology to be implemented? 10. Is the number of people on the project team adequate to do the job? 11. Do all customer/user constituencies agree on the importance of the project and on the requirements for the system/product to be built? 2. Risk Components and Drivers The risk components: Performance risk Cost risk Support risk Schedule risk Four impact categories: negligible marginal critical catastrophic.

RISK PROJECTION Also called risk estimation. Four risk projection activities: (1) establish a scale that reflects the perceived likelihood of a risk (2) delineate the consequences of the risk (3) estimate the impact of the risk on the project and the product (4) note the overall accuracy of the risk projection 1. Developing a Risk Table

2. Assessing Risk Impact Three factors affect the consequences that are likely if a risk does occur: o its nature, o its scope, o its timing. The overall risk exposure, RE, is determined using the following relationship o RE = P x C o P is the probability of occurrence for a risk o C is the cost to the project should the risk occur. 3. Risk Assessment a set of triplets of the form [ri, li, xi] o ri is risk, o li is the likelihood (probability) of the risk, o xi is the impact of the risk.

During risk assessment, we perform the following steps: 1. Define the risk referent levels for the project. 2. Attempt to develop a relationship between each (ri, li, xi) and each of the referent levels. 3. Predict the set of referent points that define a region of termination, bounded by a curve or areas of uncertainty. 4. Try to predict how compound combinations of risks will affect a referent level. RISK REFINEMENT condition-transition-consequence (CTC) Given that <condition> then there is concern that (possibly) <consequence>. RISK MITIGATION, MONITORING, AND MANAGEMENT An effective strategy must consider three issues: risk avoidance risk monitoring risk management and contingency planning If a software team adopts a proactive approach to risk, avoidance is always the best strategy. This is achieved by developing a plan for risk mitigation. SAFETY RISKS AND HAZARDS Software safety and hazard analysis are software quality assurance activities that focus on the identification and assessment of potential hazards that may affect software negatively and cause an entire system to fail. THE RMMM PLAN Risk Mitigation, Monitoring and Management Plan. The RMMM plan documents all work performed as part of risk analysis and is used by the project manager as part of the overall project plan. Each risk is documented individually using a risk information sheet. In most cases, the RIS is maintained using a database system, so that creation and information entry, priority ordering, searches, and other analysis may be accomplished easily Risk mitigation is a problem avoidance activity. Risk monitoring is a project tracking activity.

6. PROJECT SCHEDULING AND TRACKING

BASIC CONCEPTS why software is delivered late: An unrealistic deadline established by someone outside the software development group and forced on managers and practitioner's within the group. Changing customer requirements that are not reflected in schedule changes. An honest underestimate of the amount of effort and/or the number of resources that will be required to do the job. Predictable and/or unpredictable risks that were not considered when the project commenced. Technical difficulties that could not have been foreseen in advance. Human difficulties that could not have been foreseen in advance. Miscommunication among project staff that results in delays. A failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem. 1. Comments on Lateness What should we do when management demands that we make a deadline that is impossible? 1. Perform a detailed estimate using historical data from past projects. Determine the estimated effort and duration for the project.

2. Using an incremental process model, develop a software engineering strategy that will deliver critical functionality by the imposed deadline, but delay other functionality until later. Document the plan. 3. Meet with the customer and explain why the imposed deadline is unrealistic. 4. Offer the incremental development strategy as an alternative 2. Basic Principles Software project scheduling is an activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks. During early stages of project planning, a macroscopic schedule is developed Each entry on the macroscopic schedule is refined into a detailed schedule.

A number of basic principles guide software project scheduling: o Compartmentalization define distinct tasks o Interdependency- parallel and sequential tasks o Time allocation - assigned person days, start time, ending time) o Effort validation - be sure resources are available o Defined responsibilities people must be assigned o Defined Outcomes- each task must have an output o Defined milestones - review for quality THE RELATIONSHIP BETWEEN PEOPLE AND EFFORT As the size of a project increases, more people must become involved. 1. An Example Consider four software engineers, each capable of producing 5000 LOC/year when working on an individual project. When these four engineers are placed on a team project, six potential communication paths are possible. Team productivity will be reduced by 250 LOC/year for each communication path Team productivity is 20,000 (250 x 6) = 18,500 LOC/year7.5 percent less than what we might expect. 2. An Empirical Relationship The number of delivered lines of L, is related to effort and development time by the equation: o L = P x E1/3t4/3 where E is development effort in person-months, P is a productivity parameter

t is the project duration in calendar months. Rearranging this software equation, we can arrive at an expression for development effort E: o E = L3/( P3t4 ) 3. Effort Distribution

DEFINING A TASK SET FOR THE SOFTWARE PROJECT Determine type of project Assess the degree of rigor required identify adaptation criteria compute task set selector (TSS) value interpret TSS to determine degree of rigor Select appropriate software engineering tasks Software Project Types Concept Development projects New Application Development Projects Application Enhancement Project Application Maintenance Project Reengineering Project 1. Degree of Rigor Casual Structured Strict Quick reaction 2. Defining Adaptation Criteria Size of the project Number of potential users Mission criticality Application longevity Stability of requirements Ease of customer/developer communication Maturity of applicable technology Performance constraints Embedded and nonembedded characteristics Project staff Reengineering factors 3. Computing a Task Set Selector Value

4. Interpreting the TSS Value and Selecting the Task Set

SELECTING SOFTWARE ENGINEERING TASKS Concept development projects are approached by applying the following major tasks: Concept scoping o determine overall project scope Preliminary concept planning o establishes development team's ability to undertake the proposed work Technology risk assessment o evaluates the risk associated with the technology implied by the software scope Proof of concept o demonstrates the feasibility of the technology in the software context Concept implementation o concept represented in a form that can be used to sell it to the customer Customer reaction to concept o solicits feedback on new technology from customer

REFINEMENT OF MAJOR TASKS Refinement begins by taking each major task and decomposing it into a set of subtasks DEFINING A TASK NETWORK A task network, also called an activity network, is a graphic representation of the task flow for a project. An activity network diagram provides a notation for documenting a network of tasks needed to complete a project, their interdependencies the times required for each task.

SCHEDULING

o Both techniques (PERT and CPM) are driven by information already developed in earlier project planning activities: o Estimates of efforts o Decomposition of product function o selection of appropriate process model and task set o Decomposition of tasks Both PERT and CPM provides quantitative tools to o determine the critical path o establish the most likely time estimated for individual tasks by applying statistical models o calculate boundary time for a particular task

1. Timeline Charts timeline chart, also called a Gantt chart

2. Tracking the Schedule It is a road map for the Software Project It defines the tasks and milestones Tracking can be done by: o Conducting periodic project status meetings o Evaluating the results of all reviews o Determining whether milestones were reached by the scheduled date o Compare actual start date to planned start date o Meeting informally with professionals to get their subjective opinion o Using earned value analysis EARNED VALUE ANALYSIS a technique for performing quantitative analysis of progress does exist. It is called earned value analysis (EVA). To determine the earned value, the following steps are performed: The budgeted cost of work scheduled (BCWS) is determined for each work task represented in the schedule. The BCWS values for all work tasks are summed to derive the budget at completion (BAC), BAC = (BCWSk) for all tasks k

Next, the value for budgeted cost of work performed (BCWP) is computed. The value for BCWP is the sum of the BCWS values for all work tasks that have actually been completed by a point in time on the project schedule. Schedule performance index, SPI = BCWP/BCWS Schedule variance, SV = BCWP BCWS An SPI value close to 1.0 indicates efficient execution of the project schedule. Percent scheduled for completion = BCWS/BAC Percent complete = BCWP/BAC actual cost of work performed, ACWP Cost performance index, CPI = BCWP/ACWP Cost variance, CV = BCWP ACWP A CPI value close to 1.0 provides a strong indication that the project is within its defined budget.

ERROR TRACKING Any errors that are not uncovered are considered to be defects, D. DRE = E/(E + D) Allows comparison of current work to past projects and provides a quantitative indication of the quality of the work being conducted. The more quantitative the approach to project tracking and control, the more likely problems can be anticipated and dealt with in a proactive manner. THE PROJECT PLAN The Software Project Plan is a relatively brief document that is addressed to a diverse audience. (1) communicate scope and resources to software management, technical staff, and the customer; (2) define risks and suggest risk aversion techniques; (3) define cost and schedule for management review; (4) provide an overall approach to software development for all people associated with the project; (5) outline how quality will be ensured and change will be managed.