Transparency Masters for Software Engineering: A Practitioner ...

Managing Software Projects Part VI California State University, cs437, Fall 2007 1 Chapter 21 Project Management Concepts California State University, cs437, Fall 2007 2 The 4 Ps People the most important element of a successful project Product the software to be built.

Process the set of framework activities and software engineering tasks to get the job done Project all work required to make the product a reality. California State University, cs437, Fall 2007 3 Stakeholders Senior managers who define the business issues that often have significant influence on the project. Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work. Practitioners who deliver the technical skills that are necessary to engineer a product or application. Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome.

End-users who interact with the software once it is released for production use. California State University, cs437, Fall 2007 4 Software Teams How to lead? How to organize? How to collaborate? How to motivate? California State University, cs437, Fall 2007 How to create good ideas? 5 Team Leader The MOI Model

Motivation. The ability to encourage (by push or pull) technical people to produce to their best ability. Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application. California State University, cs437, Fall 2007 6 Software Teams The following factors must be considered when selecting a software project team structure ... 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 California State University, cs437, Fall 2007 7 Teams Organizational Paradigms closed paradigmstructures a team along a traditional hierarchy of authority (example: the chief programmer team). random paradigmstructures a team loosely and depends on individual initiative of the team members open paradigmattempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using

the random paradigm synchronous paradigmrelies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves suggested by Constantine California State University, cs437, Fall 2007 8 Avoid Team Toxicity A frenzied work atmosphere in which team members waste energy and lose focus on the objectives of the work to be performed. High frustration caused by personal, business, or technological factors that cause friction among team members. Fragmented or poorly coordinated procedures or a poorly defined or improperly chosen process model that becomes a

roadblock to accomplishment. Unclear definition of roles resulting in a lack of accountability and resultant finger-pointing. Continuous and repeated exposure to failure that leads to a loss of confidence and a lowering of morale. California State University, cs437, Fall 2007 9 Agile Teams Team members must have trust in one another. The distribution of skills must be appropriate to the problem. Mavericks may have to be excluded from the team, if team cohesiveness is to be maintained. Team is self-organizing

An adaptive team structure Uses elements of Constantines random, open, and synchronous paradigms Significant autonomy California State University, cs437, Fall 2007 10 Coordination & Communication Issues Reasons why projects get into trouble: Large scale of the development efforts. Complexity, Confusion, Coordination difficulties. Uncertainty leading to a stream of changes. Interoperability of many systems. New SW must communicate with existing SW to satisfy existing constraints. New SW may have interface with existing HW. California State University, cs437, Fall 2007 11 Team Coordination & Communication

Formal, impersonal approaches include software engineering documents and work products (including source code), technical memos, project milestones, schedules, and project control tools, change requests and related documentation, error tracking reports, and repository data. Formal, interpersonal procedures focus on quality assurance activities applied to software engineering work products. These include status review meetings and design and code inspections. Informal, interpersonal procedures include group meetings for information dissemination and problem solving and collocation of requirements and development staff. Electronic communication encompasses electronic mail, electronic bulletin boards, and by extension, video-based conferencing systems. Interpersonal networking includes informal discussions with team members and those outside the project who may have experience or insight that can assist team members. California State University, cs437, Fall 2007 12 The Product Scope

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? Software project scope must be unambiguous and understandable at the management and technical levels. California State University, cs437, Fall 2007 13 Problem Decomposition

Sometimes called partitioning or problem elaboration Once scope is defined It is decomposed into constituent functions It is decomposed into user-visible data objects or It is decomposed into a set of problem classes Decomposition process continues until all functions or problem classes have been defined and understood. California State University, cs437, Fall 2007 14 The Process

Once a process framework has been established Consider project characteristics Determine the degree of rigor required Define a task set for each software engineering activity Task set = Software engineering tasks Work products Quality assurance points Milestones California State University, cs437, Fall 2007 15 Melding the Problem and the Process

California State University, cs437, Fall 2007 16 The Project Projects get into trouble when Software people dont understand their customers needs. The product scope is poorly defined. Changes are managed poorly. The chosen technology changes. Business needs change [or are ill-defined]. Deadlines are unrealistic. Users are resistant. Sponsorship is lost [or was never properly obtained]. The project team lacks people with appropriate skills. Managers [and practitioners] avoid best practices and lessons

learned. California State University, cs437, Fall 2007 17 Common-Sense Approach to Projects Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objectives and expectations. Maintain momentum. The project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the teams way. Track progress. For a software project, progress is tracked as work products (e.g., models, source code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity. Make smart decisions. In essence, the decisions of the project

manager and the software team should be to keep it simple. Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project. California State University, cs437, Fall 2007 18 To Get to the Essence of a Project Why is the system being developed? What will be done? When will it be accomplished? Who is responsible? Where are they organizationally located? How will the job be done technically and managerially? How much of each resource (e.g., people, software, tools, database) will be needed? Barry Boehms W5HH

California State University, cs437, Fall 2007 19 Critical Practices Formal risk management Empirical cost and schedule estimation Metrics-based project management Earned value tracking Defect tracking against quality targets People aware project management California State University, cs437, Fall 2007 20 Chapter 22 Process and Project Metrics When you measure what you are speaking about and express it in numbers, you know something about it; but when you cannot measure, when you

cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of a science. Lord Kelvin California State University, cs437, Fall 2007 21 A Good Manager Measures process process metrics measurement project metrics product metrics product California State University, cs437, Fall 2007 What do we use as a basis? size? function?

22 Why Do We Measure? assess the status of an ongoing project track potential risks uncover problem areas before they go critical, adjust work flow or tasks, evaluate the project teams ability to control quality of software work products. California State University, cs437, Fall 2007 23 Process Measurement We measure the efficacy of a software process indirectly.

That is, we derive a set of metrics based on the outcomes that can be derived from the process. Outcomes include measures of errors uncovered before release of the software defects delivered to and reported by end-users work products delivered (productivity) human effort expended calendar time expended schedule conformance other measures. We also derive process metrics by measuring the characteristics of specific software engineering tasks. California State University, cs437, Fall 2007 24

Process Metrics Guidelines 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. California State University, cs437, Fall 2007

25 Software Process Improvement Process model Improvement goals Process metrics California State University, cs437, Fall 2007 SPI Process improvement recommendations 26 Process Metrics Quality-related Productivity-related

error categorization & analysis Defect removal efficiency Production of work-products related to effort expended Statistical SQA data focus on quality of work products and deliverables propagation of errors from process activity to activity Reuse data The number of components produced and their degree of reusability California State University, cs437, Fall 2007 27 Project Metrics

used to minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks used to assess product quality on an ongoing basis and, when necessary, modify the technical approach to improve quality. every project should measure: inputsmeasures of the resources (e.g., people, tools) required to do the work. outputsmeasures of the deliverables or work products created during the software engineering process. resultsmeasures that indicate the effectiveness of the deliverables. California State University, cs437, Fall 2007 28 Typical Project Metrics

Effort/time per software engineering task Errors uncovered per review hour Scheduled vs. actual milestone dates Changes (number) and their characteristics Distribution of effort on software engineering tasks California State University, cs437, Fall 2007 29 Typical Size-Oriented Metrics errors per KLOC (thousand lines of code) defects per KLOC $ per LOC

pages of documentation per KLOC errors per person-month Errors per review hour LOC per person-month $ per page of documentation California State University, cs437, Fall 2007 30 Typical Function-Oriented Metrics errors per FP (function points) defects per FP $ per FP pages of documentation per FP FP per person-month California State University, cs437, Fall 2007 31 Comparing LOC and FP

Programming Language Ada Assembler C C++ COBOL Java JavaScript Perl PL/1 Powerbuilder SAS Smalltalk SQL Visual Basic LOC per Function point avg. median low high 154 337 162 66 315 109

53 104 91 33 29 205 694 704 178 77 63 58 60 78 32 40 26 40 47 77 53 63 67 31 41

19 37 42 14 77 42 22 11 33 10 7 16 400 75 263 105 49 55 110 158 Representative values developed by QSM (Quantitative Software Management) California State University, cs437, Fall 2007 32

Why Opt for FP? Programming language independent Used readily countable characteristics that are determined early in the software process Does not penalize inventive (short) implementations that use fewer LOC that other more clumsy versions Makes it easier to measure the impact of reusable components California State University, cs437, Fall 2007 33 Object-Oriented Metrics

Number of scenario scripts (use-cases) Number of support classes (required to ( implement the system but are not immediately related to the problem domain) Average number of support classes per key class (analysis class) Number of subsystems (an aggregation of classes that support a function that is visible to the enduser of a system) California State University, cs437, Fall 2007 34 WebE Project Metrics Number of static Web pages (the end-user has no control over the

content displayed on the page) Number of dynamic Web pages (end-user actions result in customized content displayed on the page) Number of internal page links (internal page links are pointers that provide a hyperlink to some other Web page within the WebApp) Number of persistent data objects Number of external systems interfaced Number of static content objects Number of dynamic content objects Number of executable functions California State University, cs437, Fall 2007 35 Measuring Quality Correctness the degree to which a program operates according to specification Maintainabilitythe degree to which a program is amenable to change Integritythe degree to which a program is impervious to outside attack

Integrity = [1-(threat*(1-security))] Ex: threat=25%/50%, security=95%/25%, Integrity=99%/63% Threat=prob that an attack will occur; Security=Prob. that the attack will be repelled. Usabilitythe degree to which a program is easy to use California State University, cs437, Fall 2007 36 Defect Removal Efficiency 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. California State University, cs437, Fall 2007

37 Metrics for Small Organizations time (hours or days) elapsed from the time a request is made until evaluation is complete, tqueue. effort (person-hours) to perform the evaluation, Weval. time (hours or days) elapsed from completion of evaluation to assignment of change order to personnel, teval. effort (person-hours) required to make the change, Wchange. time required (hours or days) to make the change, tchange. errors uncovered during work to make change, Echange.

defects uncovered after change is released to the customer base, Dchange. California State University, cs437, Fall 2007 38 Establishing a Metrics Program The Software Engineering Institute, SEI, has developed a comprehensive Guidebook for establishing a goal-driven software metric program. The suggested steps are: Identify your business goals. Identify what you want to know or learn. Identify your subgoals. Identify the entities and attributes related to your subgoals. Formalize your measurement goals.

Identify quantifiable questions and the related indicators that you will use to help you achieve your measurement goals. Identify the data elements that you will collect to construct the indicators that help answer your questions. Define the measures to be used, and make these definitions operational. Identify the actions that you will take to implement the measures. Prepare a plan for implementing the measures. California State University, cs437, Fall 2007 39 Chapter 23 Estimation for Software Projects California State University, cs437, Fall 2007 40 Software Project Planning The overall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project. Why? So the end result gets done on time, with

quality and within budget! California State University, cs437, Fall 2007 41 Project Planning Task Set-I Establish project scope Determine feasibility Analyze risks Risk analysis is considered in detail in Chapter 25. Define required resources Determine require human resources Define reusable software resources Identify environmental resources

California State University, cs437, Fall 2007 42 Project Planning Task Set-II Estimate cost and effort Decompose the problem Develop two or more estimates using size, function points, process tasks or use-cases Reconcile the estimates Develop a project schedule Scheduling is considered in detail in Chapter 24.

Establish a meaningful task set Define a task network Use scheduling tools to develop a timeline chart Define schedule tracking mechanisms California State University, cs437, Fall 2007 43 Estimation Estimation of resources, cost, and schedule for a software engineering effort requires experience access to good historical information (metrics). the courage to commit to quantitative predictions when qualitative information is all that exists. Estimation carries inherent risk and this risk leads to uncertainty California State University, cs437, Fall 2007

44 Write it Down! Project Scope Estimates Risks Schedule Control strategy California State University, cs437, Fall 2007 Software Project Plan 45 To Understand Scope ... Understand the customers needs

understand the business context understand the project boundaries understand the customers motivation understand the likely paths for change Even when understand that you ... understand, nothing is guaranteed! California State University, cs437, Fall 2007 46 What is Scope? Software scope describes

the functions and features that are to be delivered to endusers the data that are input and output the content that is presented to users as a consequence of using the software the performance, constraints, interfaces, and reliability that bound the system. Scope is defined using one of two techniques: A narrative description of software scope is developed after communication with all stakeholders. A set of use-cases is developed by end-users. California State University, cs437, Fall 2007 47 Resources number software tools skills hardware

people environment location network resources project OTS components reusable software full-experience components California State University, cs437, Fall 2007 new components part.-experience components

48 Project Estimation California State University, cs437, Fall 2007 Project scope must be understood Elaboration (decomposition) is necessary Historical metrics are very helpful At least two different techniques should be used Uncertainty is inherent in the process 49 Estimation Techniques Past (similar) project experience Conventional estimation techniques

task breakdown and effort estimates size (e.g., FP) estimates Empirical models Automated tools California State University, cs437, Fall 2007 50 Estimation Accuracy Predicated on the degree to which the planner has properly estimated the size of the product to be built the ability to translate the size estimate into human

effort, calendar time, and dollars (a function of the availability of reliable software metrics from past projects) the degree to which the project plan reflects the abilities of the software team the stability of product requirements and the environment that supports the software engineering effort. California State University, cs437, Fall 2007 51 Functional Decomposition Statement of Scope California State University, cs437, Fall 2007 Perform a Grammatical parse functional decomposition 52 Conventional Methods:

LOC/FP Approach compute LOC/FP using estimates of information domain values use historical data to build estimates for the project California State University, cs437, Fall 2007 53 Example: LOC Approach Average productivity for systems of this type = 620 LOC/pm. Burdened labor rate =$8000 per month, the cost per line of code is approximately $13. Based on the LOC estimate and the historical productivity data, the total estimated project cost is $431,000 and the estimated effort is 54 personmonths. California State University, cs437, Fall 2007 54 Example: FP Approach

The estimated number of FP is derived: FPestimated = count-total 3 [0.65 + 0.01 3 S (Fi)] FPestimated = 375 organizational average productivity = 6.5 FP/pm. burdened labor rate = $8000 per month, the cost per FP is approximately $1230. Based on the FP estimate and the historical productivity data, the total estimated project cost is $461,000 and the estimated effort is 58 personmonths. California State University, cs437, Fall 2007 55 Process-Based Estimation Obtained from process framework framework activities application functions California State University, cs437, Fall 2007 Effort required to accomplish each framework activity for each application function 56 Process-Based Estimation Example

Activity CC Planning Risk Analysis Task Engineering Construction Release analysis design code test 0.50 0.75 0.50 0.50 0.50

0.25 0.50 2.50 4.00 4.00 3.00 3.00 2.00 2.00 0.40 0.60 1.00 1.00 0.75 0.50 0.50 5.00 2.00 3.00 1.50 1.50 1.50 2.00 4.50

16.50 CE Totals n/a n/a n/a n/a n/a n/a n/a 8.40 7.35 8.50 6.00 5.75 4.25 5.00 Function UICF 2DGA 3DGA CGDF DSM PCF

DAM Totals 0.25 0.25 0.25 3.50 20.50 % effort 1% 1% 1% 8% 45% 10% 46.00

36% CC = customer communication CE= CE =customer customerevaluation evaluation cc=customer communication Based on an average burdened labor rate of $8,000 per month, the total estimated project cost is $368,000 and the estimated effort is 46 person-months. California State University, cs437, Fall 2007 57 Tool-Based Estimation project characteristics calibration factors LOC/FP data California State University, cs437, Fall 2007 58 Estimation with Use-Cases

use cases scenarios pages scenarios pages e subsystem 6 10 6 12 5 User interface subsystem Engineering subsystem group subsystem group 10 20 8 16 8 Infrastructure subsystemgroup group e subsystem 5 6 5 10

6 Total LOC estimate stimate LOC LOC estimate 560 3,366 3100 31,233 1650 7,970 42,568 Using 620 LOC/pm as the average productivity for systems of this type and a burdened labor rate of $8000 per month, the cost per line of code is approximately $13. Based on the use-case estimate and the historical productivity data, the total estimated project cost is $552,000 and the estimated effort is 68 person-months. California State University, cs437, Fall 2007

59 Empirical Estimation Models General form: effort = tuning coefficient * size exponent usually derived as person-months of effort required either a constant or a number derived based on complexity of project California State University, cs437, Fall 2007 empirically derived usually LOC but may also be function point 60 COCOMO-II

COCOMO II is actually a hierarchy of estimation models that address the following areas: Application composition model. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity are paramount. Early design stage model. Used once requirements have been stabilized and basic software architecture has been established. Post-architecture-stage model. Used during the construction of the software. California State University, cs437, Fall 2007 61 The Software Equation A dynamic multivariable model E = [LOC x B0.333/P]3 x (1/t4) where E = effort in person-months or person-years

t = project duration in months or years B = special skills factor P = productivity parameter California State University, cs437, Fall 2007 62 Estimation for OO Projects-I Develop estimates using effort decomposition, FP analysis, and any other method that is applicable for conventional applications. Using object-oriented analysis modeling (Chapter 8), develop usecases and determine a count. From the analysis model, determine the number of key classes (called analysis classes in Chapter 8). Categorize the type of interface for the application and develop a multiplier for support classes:

Interface type No GUI Text-based user interface GUI Complex GUI California State University, cs437, Fall 2007 Multiplier 2.0 2.25 2.5 3.0 63 Estimation for OO Projects-II Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support classes. Multiply the total number of classes (key + support) by the average number of work-units per class. Lorenz and Kidd

suggest 15 to 20 person-days per class. Cross check the class-based estimate by multiplying the average number of work-units per use-case California State University, cs437, Fall 2007 64 Estimation for Agile Projects Each user scenario (a mini-use-case) is considered separately for estimation purposes. The scenario is decomposed into the set of software engineering tasks that will be required to develop it. Each task is estimated separately. Note: estimation can be based on historical data, an empirical model, or experience. Estimates for each task are summed to create an estimate for the scenario.

Alternatively, the volume of the scenario can be estimated in LOC, FP or some other volume-oriented measure (e.g., use-case count). Alternatively, the volume estimate for the scenario is translated into effort using historical data. The effort estimates for all scenarios that are to be implemented for a given software increment are summed to develop the effort estimate for the increment. California State University, cs437, Fall 2007 65 The Make-Buy Decision simple (0.30) build difficult (0.70) minor changes (0.40) system X reuse simple (0.20)

buy contract major changes (0.60) complex (0.80) minor changes (0.70) major changes (0.30) without changes (0.60) $380,000 $450,000 $275,000 $310,000 $490,000 $210,000 $400,000 $350,000 $500,000 with changes (0.40)

California State University, cs437, Fall 2007 66 Computing Expected Cost expected cost = (path probability) x (estimated path cost) i i For example, the expected cost to build is: expected cost = 0.30 ($380K) + 0.70 ($450K) build similarly, reuse expected cost expected costbuy expected costcontr California State University, cs437, Fall 2007 = $429 K = $382K = $267K = $410K 67

Chapter 24 Project Scheduling and Tracking California State University, cs437, Fall 2007 68 Why Are Projects Late? an unrealistic deadline established by someone outside the software development 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 California State University, cs437, Fall 2007 69 Scheduling Principles compartmentalizationdefine distinct tasks interdependencyindicate task interrelationship effort validationbe sure resources are available defined responsibilitiespeople must be assigned defined outcomeseach task must have an output defined milestonesreview for quality

California State University, cs437, Fall 2007 70 Effort and Delivery Time Effort Cost Ea = m (td4 / ta4) Impossible region Ea = effort in person-months td = nominal delivery time for schedule to = optimal development time (in terms of cost) ta = actual delivery time desired Ed Eo td to development time Tmin = 0.75T d California State University, cs437, Fall 2007

71 Effort Allocation 40-50% 15-20% California State University, cs437, Fall 2007 customer communication analysis design review and modification construction activities

30-40% front end activities coding or code generation testing and installation unit, integration white-box, black box regression 72 Defining Task Sets determine type of project assess the degree of rigor required identify adaptation criteria select appropriate software engineering tasks

California State University, cs437, Fall 2007 73 Task Set Refinement Concept scoping 1.1 determines the overall scope of the project. Task definition: Task 1.1 Concept Scoping 1.1.1 Identify need, benefits and potential customers; 1.1.2 Define desired output/control and input events that drive the application; Begin Task 1.1.2 1.1.2.1 FTR: Review written description of need FTR indicates that a formal technical review (Chapter 26) is to be conducted. 1.1.2.2 Derive a list of customer visible outputs/inputs 1.1.2.3

FTR: Review outputs/inputs with customer and revise as required; endtask Task 1.1.2 1.1.3 Define the functionality/behavior for each major function; Begin Task 1.1.3 is refined to 1.1.3.1 FTR: Review output and input data objects derived in task 1.1.2; 1.1.3.2 Derive a model of functions/behaviors; 1.1.3.3 FTR: Review functions/behaviors with customer and revise as required; endtask Task 1.1.3 1.1.4 Isolate those elements of the technology to be implemented in software; 1.1.5

Research availability of existing software; 1.1.6 Define technical feasibility; 1.1.7 Make quick estimate of size; 1.1.8 Create a Scope Definition; endTask definition: Task 1.1 California State University, cs437, Fall 2007 74 Define a Task Network I.5a Concept Implement. I.3a Tech. Risk Assessment I.1

Concept scoping I.2 Concept planning California State University, cs437, Fall 2007 I.3b Tech. Risk Assessment I.4 Proof of Concept I.5b Concept Implement. I.3c Tech. Risk Assessment I.5c Concept Implement.

Three I.3 tasks are applied in parallel to 3 different concept functions Three I.3 tasks are applied in parallel to 3 different concept functions Integrate a, b, c I.6 Customer Reaction 75 Timeline Charts Tasks Week 1 Week 2 Week 3 Week 4

Week n Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Task 9 Task 10 Task 11 12 Task California State University, cs437, Fall 2007 76 Use Automated Tools to Derive a Timeline Chart Work tasks I.1.1

I.1.2 I.1.3 I.1.4 I.1.5 I.1.6 I.1.7 I.1.8 week 1 week 2 week 3 week 4 week 5 Identify need and benefits Meet with customers Identify needs and project constraints Establish product statement Milestone: product statement defined Define desired output/control/input (OCI) Scope keyboard functions

Scope voice input functions Scope modes of interaction Scope document diagnostics Scope other WP functions Document OCI FTR: Review OCI with customer Revise OCI as required; Milestone; OCI defined Define the functionality/behavior Define keyboard functions Define voice input functions Decribe modes of interaction Decribe spell/grammar check Decribe other WP functions FTR: Review OCI definition with customer Revise as required Milestone: OCI defintition complete Isolate software elements Milestone: Software elements defined Research availability of existing software Reseach text editiong components Research voice input components Research file management components Research Spell/Grammar check components Milestone: Reusable components identified Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessed

Make quick estimate of size Create a Scope Definition Review scope document with customer Revise document as required Milestone: Scope document complete California State University, cs437, Fall 2007 77 Schedule Tracking conduct periodic project status meetings in which each team member reports progress and problems. evaluate the results of all reviews conducted throughout the software engineering process. determine whether formal project milestones (the diamonds shown in Figure 24.3) have been accomplished by the scheduled date.

compare actual start-date to planned start-date for each project task listed in the resource table (Figure 24.4). meet informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon. use earned value analysis (Section 24.6) to assess progress quantitatively. California State University, cs437, Fall 2007 78 Progress on an OO Project-I Technical milestone: OO analysis completed All classes and the class hierarchy have been defined and reviewed. Class attributes and operations associated with a class have been defined and reviewed. Class relationships (Chapter 8) have been established and reviewed.

A behavioral model (Chapter 8) has been created and reviewed. Reusable classes have been noted. Technical milestone: OO design completed The set of subsystems (Chapter 9) has been defined and reviewed. Classes are allocated to subsystems and reviewed. Task allocation has been established and reviewed. Responsibilities and collaborations (Chapter 9) have been identified. Attributes and operations have been designed and reviewed. The communication model has been created and reviewed. California State University, cs437, Fall 2007 79 Progress on an OO Project-II Technical milestone: OO programming completed

Each new class has been implemented in code from the design model. Extracted classes (from a reuse library) have been implemented. Prototype or increment has been built. Technical milestone: OO testing The correctness and completeness of OO analysis and design models has been reviewed. A class-responsibility-collaboration network (Chapter 8) has been developed and reviewed. Test cases are designed and class-level tests (Chapter 14) have been conducted for each class. Test cases are designed and cluster testing (Chapter 14) is completed and the classes are integrated. System level tests have been completed.

California State University, cs437, Fall 2007 80 Earned Value Analysis (EVA) Earned value is a measure of progress enables us to assess the percent of completeness of a project using quantitative analysis rather than rely on a gut feeling provides accurate and reliable readings of performance from as early as 15 percent into the project. [FLE98] California State University, cs437, Fall 2007 81 Computing Earned Value-I

The budgeted cost of work scheduled (BCWS) is determined for each work task represented in the schedule. BCWSi is the effort planned for work task i. To determine progress at a given point along the project schedule, the value of BCWS is the sum of the BCWSi values for all work tasks that should have been completed by that point in time on the project schedule. The BCWS values for all work tasks are summed to derive the budget at completion, BAC. Hence, BAC = (BCWSk) for all tasks k California State University, cs437, Fall 2007 82 Computing Earned Value-II 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. the distinction between the BCWS and the BCWP is that the former represents the budget of the activities that were planned to be completed and the latter represents the budget of the activities that actually were completed. [WIL99] Given values for BCWS, BAC, and BCWP, important progress indicators can be computed: Schedule performance index, SPI = BCWP/BCWS Schedule variance, SV = BCWP BCWS SPI is an indication of the efficiency with which the project is utilizing scheduled resources. California State University, cs437, Fall 2007 83 Computing Earned Value-III

Percent scheduled for completion = BCWS/BAC Percent complete = BCWP/BAC provides an indication of the percentage of work that should have been completed by time t. provides a quantitative indication of the percent of completeness of the project at a given point in time, t. Actual cost of work performed, ACWP, is the sum of the effort actually expended on work tasks that have been completed by a point in time on the project schedule. It is then possible to compute Cost performance index, CPI = BCWP/ACWP Cost variance, CV = BCWP ACWP California State University, cs437, Fall 2007

84 Chapter 25 Risk Management California State University, cs437, Fall 2007 85 Project Risks What can go wrong? What is the likelihood? What will the damage be? What can we do about it? California State University, cs437, Fall 2007 86 Reactive Risk Management

project team reacts to risks when they occur mitigationplan for additional resources in anticipation of fire fighting fix on failureresource are found and applied when the risk strikes crisis managementfailure does not respond to applied resources and project is in jeopardy California State University, cs437, Fall 2007 87 Proactive Risk Management formal risk analysis is performed organization corrects the root causes of risk TQM concepts and statistical SQA examining risk sources that lie beyond the bounds of the software developing the skill to manage change

California State University, cs437, Fall 2007TQM = Total Quality Management 88 Seven Principles Maintain a global perspectiveview software risks within the context of system and the business problem Take a forward-looking viewthink about the risks that may arise in the future; establish contingency plans Encourage open communicationif someone states a potential risk, dont discount it. Integratea consideration of risk must be integrated into the software process Emphasize a continuous processthe team must be vigilant throughout the software process, modifying identified risks as more information is known and

adding new ones as better insight is achieved. Develop a shared product visionif all stakeholders share the same vision of the software, it likely that better risk identification and assessment will occur. Encourage teamworkthe talents, skills and knowledge of all stakeholder should be pooled California State University, cs437, Fall 2007 89 Risk Management Paradigm control track RISK identify plan analyze California State University, cs437, Fall 2007 90 Risk Identification

Product sizerisks associated with the overall size of the software to be built or modified. Business impactrisks associated with constraints imposed by management or the marketplace. Customer characteristicsrisks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner. Process definitionrisks associated with the degree to which the software process has been defined and is followed by the development organization. Development environmentrisks associated with the availability and quality of the tools to be used to build the product. Technology to be builtrisks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system. Staff size and experiencerisks associated with the overall technical and project experience of the software engineers who will do the work. California State University, cs437, Fall 2007

91 Assessing Project Risk-I Have top software and customer managers formally committed to support the project? Are end-users enthusiastically committed to the project and the system/product to be built? Are requirements fully understood by the software engineering team and their customers? Have customers been involved fully in the definition of requirements? Do end-users have realistic expectations? California State University, cs437, Fall 2007 92 Assessing Project Risk-II

Is project scope stable? Does the software engineering team have the right mix of skills? Are project requirements stable? Does the project team have experience with the technology to be implemented? Is the number of people on the project team adequate to do the job? Do all customer/user constituencies agree on the importance of the project and on the requirements for the system/product to be built? California State University, cs437, Fall 2007 93 Risk Components

performance riskthe degree of uncertainty that the product will meet its requirements and be fit for its intended use. cost riskthe degree of uncertainty that the project budget will be maintained. support riskthe degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance. schedule riskthe degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time. California State University, cs437, Fall 2007 94 Risk Projection Risk projection, also called risk estimation, attempts to rate each risk in two ways

the likelihood or probability that the risk is real the consequences of the problems associated with the risk, should it occur. The are four risk projection steps: establish a scale that reflects the perceived likelihood of a risk delineate the consequences of the risk estimate the impact of the risk on the project and the product, note the overall accuracy of the risk projection so that there will be no misunderstandings. California State University, cs437, Fall 2007 95 Building a Risk Table Risk Probability Impact RMMM

Risk Mitigation Monitoring & Management California State University, cs437, Fall 2007 96 Building the Risk Table Estimate the probability of occurrence Estimate the impact on the project on a scale of 1 to 5, where 1 = low impact on project success 5 = catastrophic impact on project success sort the table by probability and impact California State University, cs437, Fall 2007

97 Risk Exposure (Impact) The overall risk exposure, RE, is determined using the following relationship [HAL98]: RE = P x C where P is the probability of occurrence for a risk, and C is the cost to the project should the risk occur. California State University, cs437, Fall 2007 98 Risk Exposure Example Risk identification. Only 70 percent of the software components scheduled for reuse will, in fact, be integrated into the application. The remaining functionality will have to be custom developed.

Risk probability. 80% (likely). Risk impact. 60 reusable software components were planned. If only 70 percent can be used, 18 components would have to be developed from scratch (in addition to other custom software that has been scheduled for development). Since the average component is 1000 LOC and local data indicate that the software engineering cost for each LOC is $14.00, the overall cost (impact) to develop the components would be 18 x 1000 x 14 = $252,000. Risk exposure. RE = 0.80 x 252,000 ~ $202,000. California State University, cs437, Fall 2007 99 Risk Mitigation, Monitoring, and Management mitigationhow can we avoid the risk? monitoringwhat factors can we track that will enable us to determine if the risk is becoming more or less likely? managementwhat contingency plans do we have if the risk becomes a reality?

California State University, cs437, Fall 2007 100 Risk Due to Product Size Attributes that affect risk: estimated size of the product in LOC or FP? estimated size of product in number of programs, files, transactions? percentage deviation in size of product from average for previous products? size of database created or used by the product? number of users of the product? number of projected changes to the requirements for the product? before delivery? after delivery? amount of reused software? California State University, cs437, Fall 2007 101 Risk Due to Business Impact Attributes that affect risk: affect of this product on company revenue? visibility of this product by senior management? reasonableness of delivery deadline? number of customers who will use this product interoperability constraints

sophistication of end users? amount and quality of product documentation that must be produced and delivered to the customer? governmental constraints costs associated with late delivery? costs associated with a defective product? California State University, cs437, Fall 2007 102 Risks Due to the Customer Questions that must be answered: Have you worked with the customer in the past? Does the customer have a solid idea of requirements? Has the customer agreed to spend time with you? Is the customer willing to participate in reviews? Is the customer technically sophisticated? Is the customer willing to let your people do their jobthat is, will the customer resist looking over your shoulder during technically detailed work? Does the customer understand the software

engineering process? California State University, cs437, Fall 2007 103 Risks Due to Process Maturity Questions that must be answered: Have you established a common process framework? Is it followed by project teams? Do you have management support for software engineering Do you have a proactive approach to SQA? Do you conduct formal technical reviews? Are CASE tools used for analysis, design and testing? Are the tools integrated with one another? Have document formats been established? California State University, cs437, Fall 2007 104 Technology Risks Questions that must be answered: Is the technology new to your organization?

Are new algorithms, I/O technology required? Is new or unproven hardware involved? Does the application interface with new software? Is a specialized user interface required? Is the application radically different? Are you using new software engineering methods? Are you using unconventional software development methods, such as formal methods, AI-based approaches, artificial neural networks? Are there significant performance constraints? Is there doubt the functionality requested is "do-able?" California State University, cs437, Fall 2007 105 Staff/People Risks Questions that must be answered: Are the best people available? Does staff have the right skills?

Are enough people available? Are staff committed for entire duration? Will some people work part time? Do staff have the right expectations? Have staff received necessary training? Will turnover among staff be low? California State University, cs437, Fall 2007 106 Recording Risk Information Project: Embedded software for XYZ system Risk type: schedule risk Priority (1 low ... 5 critical): 4 Risk factor: Project completion will depend on tests which require hardware component under development. Hardware component delivery may be delayed Probability: 60 % Impact: Project completion will be delayed for each day that hardware is unavailable for use in software testing Monitoring approach: Scheduled milestone reviews with hardware group Contingency plan: Modification of testing strategy to accommodate delay using software simulation Estimated resources: 6 additional person months beginning 7-1-96

California State University, cs437, Fall 2007 107 Chapter 26 Quality Management California State University, cs437, Fall 2007 108 Quality The American Heritage Dictionary defines quality as a characteristic or attribute of something. For software, two kinds of quality may be encountered:

Quality of design encompasses requirements, specifications, and the design of the system. Quality of conformance is an issue focused primarily on implementation. user satisfaction = compliant product + good quality + delivery within budget and schedule California State University, cs437, Fall 2007 109 Software Quality Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software. California State University, cs437, Fall 2007 110 Cost of Quality Prevention costs include

Internal failure costs include quality planning formal technical reviews test equipment Training rework repair failure mode analysis External failure costs are California State University, cs437, Fall 2007

complaint resolution product return and replacement help line support warranty work 111 Software Quality Assurance Process Definition & Standards Formal Technical Reviews Analysis & Reporting Measurement California State University, cs437, Fall 2007 Test Planning & Review

112 Role of the SQA Group-I Prepares an SQA plan for a project. The plan identifies evaluations to be performed audits and reviews to be performed standards that are applicable to the project procedures for error reporting and tracking documents to be produced by the SQA group amount of feedback provided to the software project team Participates in the development of the projects software process description.

The SQA group reviews the process description for compliance with organizational policy, internal software standards, externally imposed standards (e.g., ISO-9001), and other parts of the software project plan. California State University, cs437, Fall 2007 113 Role of the SQA Group-II Reviews software engineering activities to verify compliance with the defined software process. Audits designated software work products to verify compliance with those defined as part of the software process. identifies, documents, and tracks deviations from the process and verifies

that corrections have been made. reviews selected work products; identifies, documents, and tracks deviations; verifies that corrections have been made periodically reports the results of its work to the project manager. Ensures that deviations in software work and work products are documented and handled according to a documented procedure. Records any noncompliance and reports to senior management. Noncompliance items are tracked until they are resolved. California State University, cs437, Fall 2007 114 Why SQA Activities Pay cost to find Off? and fix a defect and fix a defect 100 60.00-100.00 log

scale 10 1 10.00 0.75 Req. California State University, cs437, Fall 2007 1.00 1.50 Design 3.00 test system code test field use 115

Reviews & Inspections ... there is no particular reason why your friend and colleague cannot also be your sternest critic. Jerry Weinberg California State University, cs437, Fall 2007 116 What Are Reviews? a meeting conducted by technical people for technical people a technical assessment of a work product created during the software engineering process a software quality assurance mechanism a training ground California State University, cs437, Fall 2007

117 What Reviews Are Not A project summary or progress assessment A meeting intended solely to impart information A mechanism for political or personal reprisal! California State University, cs437, Fall 2007 118 The Players review leader standards bearer (SQA) producer maintenance oracle reviewer recorder

user rep California State University, cs437, Fall 2007 119 Conducting the 1. be preparedevaluate Review product before the review 2. review the product, not the producer 3. keep your tone mild, ask questions instead of making accusations 4. stick to the review agenda 5. raise issues, don't resolve them 6. avoid discussions of stylestick to technical correctness 7. schedule reviews as project tasks 8. record and report all review results California State University, cs437, Fall 2007 120 Review Options Matrix trained leader agenda established reviewers prepare in advance

producer presents product reader presents product recorder takes notes checklists used to find errors errors categorized as found issues list created team must sign-off on result IPR * WT IN no maybe maybe maybe no maybe no no no no yes yes yes yes

no yes no no yes yes yes yes yes no yes yes yes yes yes yes RRR yes yes yes no no yes no no yes maybe

* IPRinformal peer review WTWalkthrough INInspection RRRround robin review California State University, cs437, Fall 2007 121 Sample-Driven Reviews (SDRs) SDRs attempt to quantify those work products that are primary targets for full FTRs (Formal Technical Reviews). To accomplish this Inspect a fraction ai of each software work product, i. Record the number of faults, fi found within ai. Develop a gross estimate of the number of faults within work product i by multiplying fi by 1/ai. Sort the work products in descending order according to the gross estimate of the number of faults in each.

Focus available review resources on those work products that have the highest estimated number of faults. California State University, cs437, Fall 2007 122 Metrics Derived from Reviews inspection time per page of documentation inspection time per KLOC or FP inspection effort per KLOC or FP errors uncovered per reviewer hour errors uncovered per preparation hour errors uncovered per SE task (e.g., design) number of minor errors (e.g., typos) number of major errors (e.g., nonconformance to req.) number of errors found during preparation California State University, cs437, Fall 2007 123 Statistical SQA Product & Process Collect information on all defects

Find the causes of the defects Move to provide fixes for the process measurement ... an understanding of how to improve quality ... California State University, cs437, Fall 2007 124 Statistical SQA: An Example Defect Acronym Defect Name IES Incomplete or erroneous specifications MCC Misinterpretation of customer communication IDP Intentional deviation from specification

VPS Violation of programming standards EDR Error in data representation ICI Inconsistent component interface EDL Error in design logic IET Incomplete or erroneous testing IID Inaccurate or incomplete documentation PLT Error in programming language translation or design

HCI Ambiguous or inconsistent human/computer interface MIS Miscellaneous California State University, cs437, Fall 2007 125 Statistical SQA: An Example Total Serious Moderate Minor Error No. % No.

% No. % No. % IES 205 22 34 27 68 18 103 24

MCC 156 17 12 9 68 18 76 17 IDP 48 5 1 1 24

6 23 5 VPS 25 3 0 0 15 4 10 2 EDR 130

14 26 20 68 18 36 8 ICI 58 6 9 7 18 5 31

7 EDL 45 5 14 11 12 3 19 4 IET 95 10 12

9 35 9 48 11 IID 36 4 2 2 20 5 14 3 PLT

60 6 15 12 19 5 26 6 HCI 28 3 3 2 17

4 8 2 MIS 56 6 0 0 15 4 41 9 942 100% 128

100% 379 100% 435 100% Totals California State University, cs437, Fall 2007 126 Six-Sigma for Software Engineering The term six sigma is derived from six standard deviations3.4 instances (defects) per million occurrences implying an extremely high quality standard. The Six Sigma methodology defines three core steps:

Define customer requirements and deliverables and project goals via well-defined methods of customer communication Measure the existing process and its output to determine current quality performance (collect defect metrics) Analyze defect metrics and determine the vital few causes. If an existing SW is in place, but improvement is required , Six Sigma suggests two additional steps: Improve the process by eliminating the root causes of defects. Control the process to ensure that future work does not reintroduce the causes of defects. California State University, cs437, Fall 2007 127 Software Reliability and Availability A simple measure of reliability is mean-timebetween-failure (MTBF), where MTBF = MTTF + MTTR

The acronyms MTTF and MTTR are mean-timeto-failure and mean-time-to-repair, respectively. Software availability is the probability that a program is operating according to requirements at a given point in time and is defined as Availability = [MTTF/(MTTF + MTTR)] x 100% California State University, cs437, Fall 2007 128 Software Safety E.I. Smith, captain of the Titanic: Titanic I cannot imagine any condition which would cause this ship to founder. Modern shipbuilding has gone beyond that. Software safety is a software quality assurance activity that focuses on the identification and assessment of potential hazards that may affect software negatively and cause an entire system to fail. If hazards can be identified early in the software process, software design features can be specified that will either eliminate or control potential hazards.

California State University, cs437, Fall 2007 129 Mistake-Proofing Poka-yoke (mistake-proofing or fail-safing) devices mechanisms that lead to the prevention of a potential quality problem before it occurs or the rapid detection of quality problems if they are introduced. An effective poka-yoke device exhibits a set of common characteristics: It is simple and cheap. If a device is too complicated or

expensive, it will not be cost effective. It is part of the process. That is, the poka-yoke device is integrated into an engineering activity. It is located near the process task where the mistakes occur. Thus, it provides rapid feedback and error correction. From the Japanese (at Toyota): avoiding - yokeru; inadvertent errors - yoka California State University, cs437, Fall 2007 130 ISO 9001:2000 Standard ISO 9001:2000 is the quality assurance standard that applies to software engineering. The standard contains 20 requirements that must be present for an effective quality assurance system. The requirements delineated by ISO 9001:2000 address topics such as management responsibility, quality system, contract review, design control, document and data control, product identification and traceability, process control,

inspection and testing, corrective and preventive action, control of quality records, internal quality audits, training, servicing, and statistical techniques. California State University, cs437, Fall 2007 131 Chapter 27 Change Management California State University, cs437, Fall 2007 132 The First Law No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle. Bersoff, et al, 1980 California State University, cs437, Fall 2007 133 What Are These

Changes? changes in business requirements changes in technical requirements changes in user requirements Project Plan software models data Test California State University, cs437, Fall 2007 other documents code 134 The Software Configuration programs

The pieces California State University, cs437, Fall 2007 documents data 135 Baselines The IEEE (IEEE Std. No. 610.12-1990) defines a baseline as: A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. a baseline is a milestone in the development of software that is marked by the delivery of one or more Software Configuration Items, SCIs, and the approval of these SCIs that is obtained through a formal technical review

California State University, cs437, Fall 2007 136 Baselines modified SCIs Project database Software engineering tasks SCIs Formal technical reviews approved SCIs stored SCIs extracted SCM controls SCIs

BASELINES: System Specification Software Requirements Design Specification Source Code Test Plans/Procedures/Data Operational System California State University, cs437, Fall 2007 137 Software Configuration Objects Data model Design specification data design architectural design module design interface design Component N Test specification interface description algorithm description PDL test plan test procedure

test cases Source code California State University, cs437, Fall 2007 138 SCM Repository The SCM repository is the set of mechanisms and data structures that allow a software team to manage change in an effective manner The repository performs or precipitates the following functions [FOR89]: Data integrity Information sharing Tool integration Data integration Methodology enforcement

Document standardization California State University, cs437, Fall 2007 139 Repository Content business rules business funct ions organizat ion st ruct ure informat ion archit ect ure Business Content use-cases analysis model scenario-based diagrams flow-orient ed diagrams class-based diagrams behavioral diagrams design model archit ect ural diagrams int erface diagrams component -level diagrams t echnical met rics source code object code

syst em build inst ruct ions Construction Content t est cases t est script s t est result s qualit y met rics Model Content V&V Content Project Management Content project est imat es project schedule SCM requirement s change request s change report s SQA requirement s project report s/ audit report s project met rics California State University, cs437, Fall 2007

Documents Project Plan SCM/ SQA Plan Syst em Spec Requirement s Spec Design Document Test Plan and Procedure Support document s User manual 140 Repository Features Versioning. Dependency tracking and change management. Provides the ability to track all the design and construction components and deliverables that result from a specific requirement specification.

Configuration management. The repository manages a wide variety of relationships among the data elements stored in it. Requirements tracing. saves all of these versions to enable effective management of product releases and to permit developers to go back to previous versions. Keeps track of a series of configurations representing specific project milestones or production releases. Version management provides the needed versions, and link management keeps track of interdependencies. Audit trails. establishes additional information about when, why, and by whom changes are made. California State University, cs437, Fall 2007

141 SCM Elements Component elementsa set of tools coupled within a file management system (e.g., a database) that enables access to and management of each software configuration item. Process elementsa collection of procedures and tasks that define an effective approach to change management (and related activities) for all constituencies involved in the management, engineering and use of computer software. Construction elementsa set of tools that automate the construction of software by ensuring that the proper set of validated components (i.e., the correct version) have been assembled. Human elementsto implement effective SCM, the software team uses a set of tools and process features (encompassing other CM elements) California State University, cs437, Fall 2007 142

The SCM Process Addresses the following questions How does a software team identify the discrete elements of a software configuration? How does an organization manage the many existing versions of a program (and its documentation) in a manner that will enable change to be accommodated efficiently? How does an organization control changes before and after software is released to a customer? Who has responsibility for approving and ranking changes? How can we ensure that changes have been made properly? What mechanism is used to appraise others of changes that are made? California State University, cs437, Fall 2007 143 The SCM Process

Software Vm.n reporting configuration auditing version control change control identification SCIs California State University, cs437, Fall 2007 144 Version Control Version control combines procedures and tools to manage different versions of configuration objects that are created during the software process A version control system implements or is directly integrated with four major capabilities:

a project database (repository) that stores all relevant configuration objects a version management capability that stores all versions of a configuration object (or enables any version to be constructed using differences from past versions); a make facility that enables the software engineer to collect all relevant configuration objects and construct a specific version of the software. an issues tracking (also called bug tracking) capability that enables the team to record and track the status of all outstanding issues associated with each configuration object. California State University, cs437, Fall 2007 145 Change Control STOP California State University, cs437, Fall 2007 146 Change Control ProcessI

need for change is recognized change request from user developer evaluates change report is generated change control authority decides request is queued for action change request is denied user is informed change change control control processII processII California State University, cs437, Fall 2007 147 Change Control Process-II assign people to SCIs check-out SCIs make the change review/audit the change establish a baseline for testing change change control control processIII processIII

California State University, cs437, Fall 2007 148 Change Control Process-III perform SQA and testing activities check-in the changed SCIs promote SCI for inclusion in next release rebuild appropriate version review/audit the change include all changes in release California State University, cs437, Fall 2007 149 Auditing Change Requests SCIs SQA Plan SCM Audit California State University, cs437, Fall 2007

150 Status Accounting SCIs Change Change Requests Reports ECOs Status Accounting Reporting California State University, cs437, Fall 2007 151 SCM for Web Engineering-I Content. A typical WebApp contains a vast array of contenttext, graphics, applets, scripts, audio/video files, forms, active

page elements, tables, streaming data, and many others. The challenge is to organize this sea of content into a rational set of configuration objects (Section 27.1.4) and then establish appropriate configuration control mechanisms for these objects. People. Because a significant percentage of WebApp development continues to be conducted in an ad hoc manner, any person involved in the WebApp can (and often does) create content. California State University, cs437, Fall 2007 152 SCM for Web Engineering-II Scalability. As size and complexity grow, small changes can have farreaching and unintended affects that can be problematic. Therefore, the rigor of configuration control mechanisms should be directly proportional to application scale.

Politics. Who owns a WebApp? Who assumes responsibility for the accuracy of the information on the Web site? Who assures that quality control processes have been followed before information is published to the site? Who is responsible for making changes? Who assumes the cost of change? California State University, cs437, Fall 2007 153 Content Management-I The collection subsystem encompasses all actions required to create and/

or acquire content, and the technical functions that are necessary to convert content into a form that can be represented by a mark-up language (e.g., HTML, XML organize content into packets that can be displayed effectively on the client-side. The management subsystem implements a repository that encompasses the following elements: Content databasethe information structure that has been established to store all content objects Database capabilitiesfunctions that enable the CMS to search for specific content objects (or categories of objects), store and retrieve objects, and manage the file structure that has been established for the content Configuration management functionsthe functional elements and associated workflow that support content object identification, version control, change management, change auditing, and reporting. California State University, cs437, Fall 2007 154

Content Management-II The publishing subsystem extracts from the repository, converts it to a form that is amenable to publication, and formats it so that it can be transmitted to client-side browsers. The publishing subsystem accomplishes these tasks using a series of templates. Each template is a function that builds a publication using one of three different components [BOI02]: Static elementstext, graphics, media, and scripts that require no further processing are transmitted directly to the client-side Publication servicesfunction calls to specific retrieval and formatting services that personalize content (using predefined rules), perform data conversion, and build appropriate navigation links. External servicesprovide access to external corporate information infrastructure such as enterprise data or back-room applications. California State University, cs437, Fall 2007

155 Content Management configuration objects database Content Management System templates HTML code + scripts client-side browser server-side California State University, cs437, Fall 2007 156 Change Management for WebApps-I classify t he request ed change

class 4 change class 1 change class 3 change class 2 change acquire relat ed object s assess impact of change develop brief writ t en descript ion of change t ransmit t o all t eam members for review develop brief writ t en descript ion of change t ransmit t o all st akeholders for review changes required in relat ed object s furt her evaluat ion is required

California State University, cs437, Fall 2007 OK t o make furt her evaluat ion is required OK t o make 157 Change Management for WebApps-II check out object(s) to be changed make changes design, construct, test check in object(s) that were changed publish to WebApp California State University, cs437, Fall 2007 158

Recently Viewed Presentations

  • Crisis Management - USC Davis School of Gerontology

    Crisis Management - USC Davis School of Gerontology

    Pfizer will donate $10 million to local and international relief organizations operating in the region. These will include the American Red Cross/International Red Cross and Red Crescent Societies, International Rescue Committee, Catholic Relief Services, CARE, UNICEF, and Save the Children...
  • Super Critical Liquid Chromatography

    Super Critical Liquid Chromatography

    Super critical liquid chromatography: It is a type of column chromatography in which super critical fluid is used as a mobile Phase for the separation of mixtures. Super critical fluid: A super critical fluid is that which contains temperature and...
  • Lecture 22 Dimitar Stefanov Go-to-goal wheelchairs Autonomously transition

    Lecture 22 Dimitar Stefanov Go-to-goal wheelchairs Autonomously transition

    The system outcome for a nonholonomic system is path-dependent. Holonomic kinematics can be expressed in terms of algebraic equations which constrain the internal, rotational coordinates of a robot to the absolute position/orientation of the body of interest. Nonholonomic kinematics are...
  • Conjunctions - Weebly

    Conjunctions - Weebly

    Why "Coordinating Conjunctions?" Helena vacuumed the hedgehog, and Taylor polished the artichoke. Helena vacuumed the hedgehog, but . Taylor polished the artichoke. Helena vacuumed the hedgehog, or . Taylor polished the artichoke.
  • Life in the middle ages

    Life in the middle ages

    Life in the middle ages 400 to 1000 AD still commonly referred to as the Dark Ages Intellectual life in Europe had ceased Even Charlemagne was illiterate
  • Motivation and self assessment in second language learning

    Motivation and self assessment in second language learning

    This marked weakness in the language of school is reflected in remarkably low PISA scores (OECD, 2018) and self reported difficulty (Gu├░mundsson, 2013) Performance is hard to predict from background variables. ... Motivation and self assessment in second language learning
  • Introduction to(GMAW) Gas Metal Arc Welding

    Introduction to(GMAW) Gas Metal Arc Welding

    GMAW Unit 1 Lesson 1. Objective: Demonstrate proper setup and maintenance of GMAW equipment. GMAW Process. Gas Metal Arc Welding (GMAW) uses an electric arc to melt a consumable wire electrode and fuse it with the base metal. The arc...
  • Child Protection Policies Training Prepared by: SUNY Office

    Child Protection Policies Training Prepared by: SUNY Office

    Physical Abuse: Physical contact with a child by a covered person which is intended to cause, or causes, pain or physical injury, including punching, beating, shaking, throwing, kicking, biting and burning, or directing a child, outside the norm of the...