CHAPTER 03 THE SOFTWARE PROCESS

Lecture — Software Engineering 

CHAPTER 03 

THE SOFTWARE PROCESS 


Topics 

● Introduction 

● The Unified Process 

● Iteration and Incrementation within the Object-Oriented 

Paradigm 

● The Requirements Workflow 

● The Analysis Workflow 

● The Design Workflow 

● The Implementation Workflow 

● The Test Workflow 

● Postdelivery Maintenance 

● Retirement 


Topics 

● The Phases of the Unified Process 

● One- versus Two-Dimensional Life-Cycle Models 

● Improving the Software Process 

● Capability Maturity Models 

● Other Software Process Improvement Initiatives 

● Costs and Benefits of Software Process Improvement 


Reference 

● Schach, S.R. (2010). Object-Oriented and Classical Software 

Engineering, Eighth Edition. McGraw-Hill, ISBN: 978-0-07- 

337618-9.

Introduction 

● Software process — The way software is produced 

● Incorporates: Methodology, software life-cycle model, 

techniques, tools, and individuals building the software 

● Different organizations have different software processes 

● Documentation 

• Self-documenting to documentation intensive 

● Testing intensity 

• Half of budget for testing to minimal testing and relying on 

users 

● Postdelivery maintenance 

• 20 years of maintenance to research labs (leaving it to others) 

● Software development process is structured around five 

workflows: Requirements, analysis (specification), design, 

implementation, and test 

The Unified Process 

● Primary object-oriented methodology today is Unified Process 

● Collaborative effort of Three Amigos 

• Jim Rumbaugh: Object modeling technique (OMT), 1991 

General Electric Research and Development Center, 

Schenectady, NY 

• Grady Booch: Booch’s method, 1994 

Rational, Inc., Santa Clara, CA 

• Ivar Jacobson: Objectory methodology 

• All at Rational, Inc. by 1995 

● Developed Unified Modeling Language (UML) 

• A notation for representing an object-oriented software product 

• Version 1.0 published in 1997 

• International standards for UML by Object Management Group 

(OMG) an association of world companies 

The Unified Process 

● UML — today the international standard notation for 

representing object-oriented products 

● Publishing a complete software development methodology that 

unified their three separate methodologies 

• First called the Rational Unified Process (RUP) 

• Rational bought by IBM in 2003 

• Name Unified Software Development Process (USDP) was used 

• Term Unified Process is generally used today 

● Unified Process is not a specific series of steps for 

construction of a software product 

• An adaptable methodology 

• Modified for the specific software product to be developed 

• Some features inapplicable to small and medium products 

• Much is used for software products of all sizes 

Iteration and Incrementation within the Object- 

Oriented Paradigm 

● Object-oriented paradigm uses modeling throughout 

• A model is a set of UML diagrams 

• Representing one or more aspects of the software product 

• UML is tool to represent (model) target software product 

• UML diagrams enable software professionals to communicate 

● Object-oriented paradigm is an iterative and incremental 

methodology 

● Each workflow consists of a number of steps repeatedly 

performed 

• Until members are satisfied with an accurate UML model 

● UML diagrams are modified as more knowledge is gained 

• Made more accurate (iteration) 

• Extended (incrementation)

Iteration and Incrementation within the Object- 

Oriented Paradigm 

● Unified Process 

• Proficiency requires extensive study 

• Developed primarily for large, complex software 

• Example case studies with specifications over 1000 pages 

● Five core workflows 

• Requirements 

• Analysis 

• Design 

• Implementation 

• Testing 

The Requirements Workflow 

● Development process usually begins when client approaches a 

development organization 

● Aim of requirement workflow: For development organization 

to determine the client’s needs 

● First task: Acquire a basic understanding of application 

domain 

● At any stage, if the client stops believing that software will 

be cost effective: Development will terminate 

● Business case — A document demonstrating the costeffectiveness 

of product 

• A vital aspect of software development 

● At an initial meeting, client outlines product 

● Descriptions may be vague, unreasonable, contradictory, or 

impossible 


● Developers must determine what client needs and constraints 

• Major constraints: Deadline and cost 

• Other constraints: reliability, size, etc. 

● Cost 

• Client rarely tells how much money is available 

• Bidding procedure 

• After finalizing specifications, developers determine price 

● Concept exploration: Preliminary investigation of client’s 

needs 

● Functionality of proposed product successively refined and 

analyzed 

• For technical feasibility and financial justification 

• Meetings between developers and client 


● What developers think client wanted may not be same as what 

client actually needed 

● Client may not truly understand what is going on in own 

organization 

● Software is complex and difficult to visualize its functionality 

● Unified Process can help in this regard 

● UML diagrams can assist client in better understanding

The Analysis Workflow 

● Aim of analysis workflow: Analyze and refine requirements to 

achieve detailed understanding of requirements 

● Requirements workflow is in language of client 

• Comprehended by client 

● Analysis workflow is in a more precise language 

• Ensures design and implementation are correctly carried out 

• Includes details not relevant to the client’s understanding 

● Specification of product constitute a contract 

• Delivering a product that satisfies acceptance criteria of 

specifications 

• Should not include imprecise terms (e.g., suitable, convenient, 

ample) 

• Should not include terms that sound exact but are imprecise 

(e.g., optimal, 98 percent complete) 


• Should be written as if they will be used in a trial: Potential 

lawsuits 

• Are essential for both testing and maintenance 

• When Unified Process is used: No specification document, 

instead a set of UML artifacts 

● Issues with classical analysis 

• Ambiguity — Certain sections with more than one valid 

interpretation (intrinsic to natural languages) 

• Incompleteness — Some relevant fact or requirement may be 

omitted 

• Contradictions 

● UML diagrams together with descriptions are less likely to 

contain ambiguity, incompleteness, and contradictions 


● Once client approves specifications: Detailed planning and 

estimating commences 

• Estimating duration and cost of project 

• Clients will not authorize without the estimates (underestimating 

and overestimating) 

• Assigning appropriate personnel to the various workflows 

● A software project management plan must be drawn up 

● Reflects separate workflows of development process 

● Shows which members are involved in each task 

● Shows the deadlines for completing each task 

● Major components 

• Deliverables — What client is going to get 

• Milestones — When client gets them 

• Budget — How much it is going to cost 


● Describes software process in fullest details 

• Life-cycle model 

• Organizational structure, project responsibilities 

• Managerial objectives and priorities 

• Techniques and CASE tools 

• Detailed schedules, budgets, and resource allocations 

● Underlying entire plan: Duration and cost estimates

The Design Workflow 

● Aim of design workflow: Refine analysis artifacts until 

material in a form that can be implemented by programmers 

● Design shows how product is to do what it is specified to do 

● Classical design phase 

• Determine internal structure of product 

• Architectural design — Decompose product into modules 

(independent pieces of code with well-defined interfaces) 

• Detailed design — Selection of algorithms and data structures 

for each module 

● Object-oriented paradigm 

• Bases is class (specific type of module) 

• Extracted during analysis workflow 

• Designed during design workflow 

The Design Workflow 

● Design team must keep a record of design decisions 

• Backtracking in case of dead ends 

• Maintenance and future enhancements 

The Implementation Workflow 

● Aim of implementation workflow: Implement target software 

product 

• In the chosen programming language(s) 

● Large products partitioned into subsystems 

• Implemented in parallel by coding teams 

● Subsystems consist of components (code artifacts) 

• Implemented by individual programmers 

● Only documentation given to programmer: Design artifact 

• Detailed design provide enough information to implement 

• Rarely shown architectural design 

• Cause of failure can be design, not implementation 

The Test Workflow 

● In Unified Process testing is carried out in parallel with other 

workflows 

● Two major aspects of testing 

• A software professional has to test and retest each artifact 

developed or maintained 

• Next, SQA group performs independent testing of artifact 

● Nature of test workflow changes depending on artifacts being 

tested 

● A feature important to all artifacts is traceability 

• Trace every item in analysis back to a requirements artifact 

• Similarly for design artifacts and implementation artifacts


Requirements Artifacts 

● Requirements artifacts must have traceability 

● Requirements should be presented methodically 

• Properly numbered 

• Cross-referenced 

• Indexed 

● Developers can trace through subsequent artifacts 

• Ensuring they are a true reflection of a client’s requirements 

● Traceability simplifies task of SQA group 


Analysis Artifacts 

● Both analysis team and SQA group must check analysis 

artifacts 

• Must detect faults in specifications 

• Must ensure specifications are feasible 

● Reviews are a good way of checking analysis artifacts 

• Representatives of analysis team and of client 

• Meeting usually chaired by a member of SQA group 

• Checking for faults in analysis artifacts 

• Walkthroughs and inspections 


● Checking of detailed planning and estimating 

● Once client signs off specifications 

● Every aspect of SPMP is checked 

● Particular attention to plan’s duration and cost estimates 

● Management can obtain two or more independent estimates 

• Reconcile any significant differences 

● If duration and cost estimates are satisfactory: Client will 

give permission to proceed 


Design Artifacts 

● A critical aspect of testing is traceability 

• Every part of design can be linked to an analysis artifact 

• Whether design agrees with specifications 

• Whether every part of specifications is reflected in design 

● Design reviews are similar to specifications reviews 

• Client usually not present 

• Members of design team and SQA group work through design 

● Faults to look for 

• Logic faults 

• Interface faults 

• Lack of exception handling 

• Nonconformance to the specifications


Implementation Artifacts 

● Informal testing by programmer 

• Each component tested while being implemented (desk checking) 

• Each component tested after being implemented (against test 

cases) 

● Unit Testing: SQA group tests components methodically 

● Code review: A powerful, successful technique for detecting 

programming faults 

• Programmer guides review team through listing 

• Must include an SQA representative 

• A record of activities is kept 

● Coded components are combined and tested 

• SQA group determines whether product functions correctly 


● Critical influence on quality of results 

• Way in which components are integrated: All at once or one at a 

time 

• Specific order: Top-down or bottom-up 

● Purpose of integration testing 

• Check that components combine correctly 

• To achieve a product that satisfies its specification 

• Testing of component interfaces: Matching number, order, and 

types of formal and actual arguments 

● Product testing 

• Performed after integration testing 

• By SQA 

• Functionality checked against specifications 

• Listed constraints must be tested 

• Robustness of product is tested 


• Effects on existing computer operations are tested 

• Checking that source code and documentations are complete 

• A senior manager decides whether product is ready 

● Acceptance testing 

• Final aspect of integration testing 

• Software delivered to client 

• Client tests software on actual hardware, using actual data 

● COTS software 

• Alpha release — Versions of complete product supplied to 

selected possible future clients for testing on site 

• Beta release — Corrected alpha release, close to final version 

● Alpha and beta releases important 

• Faults can result in poor sales and huge losses 


● Alpha and beta sites 

• Free copies of delivered version 

• Problems with wasting of time and energy, damages to databases 

● Software organizations should not use alpha testing in place 

of thorough product testing by the SQA

Postdelivery Maintenance 

● Postdelivery maintenance is an integral part of software 

process 

● Must be planned for from beginning 

● Design should take future enhancements into account 

● Coding must be performed with future maintenance kept in 

mind 

● More money is spent on postdelivery maintenance than on all 

other software activities combined 

● Entire software development effort must be carried out in 

such a way to minimize impact of inevitable future 

postdelivery maintenance 

● A common problem with postdelivery maintenance is 

documentation, or lack there of it 

Postdelivery Maintenance 

• Against a time deadline: Original analysis and design artifacts 

are not updated and database manuals are not written 

• High rate of personnel turnover 

● Two aspects to testing changes made to a product during 

postdelivery maintenance 

• Checking that required changes have been implemented correctly 

• Regression testing — Ensuring that no inadvertent changes were 

made 

● Product tested against previous test cases 

• All previous test cases must be retained 

● A major aspect of postdelivery maintenance is a record of all 

changes made 

• Together with reason for each change 

• Regression test cases are a central form of documentation 

Retirement 

● Final stage in software life cycle is retirement 

• After many years of service 

• Stage when further postdelivery maintenance is no longer costeffective 

● Reasons for product retirement 

(1) When proposed changes are so drastic that design has to be 

changed: Less expensive to redesign and recode entire 

product 

(2) So many changes to original design can result in 

interdependencies inadvertently being built into the product: 

A small change can have drastic effects 

(3) When documentation is not adequately maintained, there is 

increasing risk of regression faults: safer to recode than 

maintain 

Retirement 

(4) When hardware or operating systems is to be replaced: More 

economical to rewrite from scratch than to modify 

● In each of these instance, current version is replaced by a 

new version 

• Software process continues 

● True retirement: When a product has outgrown its usefulness 

• Somewhat rare event 

• Client organization no longer requires functionality

The Phases of the Unified Process 

● Phases of Unified Process correspond to increments 

• In theory: development could be performed in any number of 

increments 

• In practice: usually consists of four increments 

● Every step performed in Unified Process falls into 

• One of five core workflows: Requirements, analysis, design, 

implementation, and test 

• And also into one of four phases: Inception, elaboration, 

construction, and transition 

● E.g., building a business model 

• Part of requirements workflow 

• Also part of inception phase 

● Figure 3.1 



The Inception Phase 

● Aim of inception phase: Determine whether it is worthwhile to 

develop target software product 

• Determine whether proposed software product is economically 

viable 

● Two steps of requirements workflow 

• Understand the domain 

• Build a business model 

● Questions to be answered, by end of the inception phase, 

before proceeding with project 

• Is proposed software product cost effective 

• Can the proposed software product be delivered on time 

• What risks are involved in developing the software product, and 

how can these risks be mitigated 


● Next step: Identify risks, in three major risk categories 

• Technical risks: E.g., is new hardware needed 

• Not getting requirements right: Risk mitigated by performing 

requirements workflow correctly 

• Not getting architecture right: Architecture may not be 

sufficiently robust 

● Risks need to be ranked: Critical risks are mitigated first 

● Inception phase of other workflows 

• Analysis workflow: Extracting information needed for design of 

architecture 

• Implementation workflow: Frequently no coding, occasionally 

proof of concept prototype 

• Test workflow: Ensuring that requirements are accurately 

determined


● Planning is an essential part of every phase 

• Insufficient information at beginning of inception phase to plan 

entire development 

• Planning for inception phase itself 

● Documentation is also an essential part of every phase 

● Deliverables of inception phase 

• Initial version of domain model 

• Initial version of business model 

• Initial version of requirements artifacts 

• A preliminary version of analysis artifacts 

• A preliminary version of architecture 

• Initial list of risks 

• The initial use cases 

• Plan for elaboration phase 

• Initial version of business case 


● Obtaining initial version of business case is overall aim of 

inception phase 

• If proposed software product is to be marketed: Business case 

includes revenue projections, market estimates, and initial cost 

estimates 

• If proposed software product is to be used in-house: Business 

case includes initial cost-benefit analysis 


The Elaboration Phase 

● Aim of elaboration phase 

• Refine initial requirements 

• Refine architecture 

• Monitor risks 

• Refine business case 

• Produce software project management plan 

● Deliverables of elaboration phase 

• Completed domain 

• Completed business model 

• Completed requirements artifacts 

• Completed analysis artifacts 

• An updated version of architecture 

• An updated list of risks 


• Software project management plan 

• Completed business case


The Construction Phase 

● Aim of construction phase: Produce first operational-quality 

version of software products 

• So-called beta release 

● Deliverables of construction phase 

• Initial user manual and other manuals 

• All artifacts (beta release versions) 

• Completed architecture 

• Updated risk list 

• Software project management plan 

• If necessary, updated business case 


The Transition Phase 

● Aim of transition phase: Ensure that client’s requirements 

have indeed been met 

• Phase driven by feedback from beta testing 

• Faults in software are corrected 

• Manuals are completed 

● Deliverables of transition phase 

• All artifacts 

• Completed manuals 

One- versus Two-Dimensional Life-Cycle Models 

● A classical life-cycle model is a one-dimensional model 

• Represented by a single axis 

● Underlying Unified Process is a two-dimensional life-cycle 

model 

• Represented by two axes 


One- versus Two-Dimensional Life-Cycle Models 

● Unified process currently best methodology available 

• For treating a large problem as a set of smaller, largely 

independent subproblems 

• Provides a framework for incrementation and iteration 

• Handles well challenge of inevitable changes 

● In the future, it will be superseded by some new methodology 

• Software professionals looking for next major breakthrough

Improving the Software Process 

● Global economy depends critically on computers and hence on 

software 

● Governments of many countries are concerned about the 

software process 

● 1987 task force report of U.S. Department of Defense (DoD) 

• problem of inability to manage the software process 

● The Software Engineering Institute (SEI) 

• In response to concerns about the software process 

• Founded by DoD at Carnegie Mellon University 

● Major success: Capability Maturity Model (CMM) initiative 

● Related software process improvement efforts 

• ISO 9000-series standards of International Organization for 

Standardization 

• ISO/IEC 15504 international software improvement initiative 

(involving more than 40 countries) 

Capability Maturity Models 

● Capability maturity models are a related group of strategies 

for improving software process 

• Irrespective of actual life-cycle model used 

• Developed by Software Engineering Institute (SEI) 

• Maturity — A measure of goodness of process itself 

● CMMs 

• SW-CMM: Software 

• P-CMM: Management of human resources (people) 

• SE-CMM: System engineering 

• IPD-CMM: Integrated product development 

• SA-CMM: Software acquisition 

● Capability Maturity Model Integration (CMMI) 

• Inconsistencies and redundancies between models 

• A single integrated framework for maturity models 


• Incorporates all five CMMs 

• Additional disciplines may be added in the future 

● SW–CMM 

• Proposed in 1986 

• Incorporates both technical and managerial aspects of software 

production 

● Based on ideas 

• Use of new software techniques will not result in increased 

productivity and profitability 

• Problems are caused by how software process is managed 

• Improving the management of software process can result in 

improvements in techniques 

• Improvement in the process as a whole should result in betterquality 

software: Fewer software projects with time and cost 

overruns 


● Improvements in software process cannot occur overnight 

• SW-CMM induces changes incrementally 

• Five levels of maturity are defined 

• An organization advances slowly in a series of small steps 

● Five levels of CMM 

● Maturity level 1: Initial level 

• No sound software engineering management practice 

• Everything done on an ad hoc basis 

• Most activities are responses to crises: Rather than pre-planned 

tasks 

• Software process is unpredictable 

• Unfortunate majority of world software organizations are of 

this type


● Maturity level 2: Repeatable level 

• Basic software project management practices 

• Planning and management based on experiences with similar 

products 

• Measurements are taken: Essential first step for an adequate 

process 

• Typical measurements: Tracking of costs and schedules 

• Managers identify problems as they arise and take immediate 

corrective actions: Prevent them from becoming crises 

● Maturity level 3: Defined level 

• Process for software production is fully documented 

• Both managerial and technical aspects of process are clearly 

defined 

• Continual efforts to improve the process wherever possible 


• Reviews are used to achieve software quality goals 

• Can introduce new technology such as CASE environments to 

increase quality and productivity 

• A number of organizations have reached levels 2 and 3 

• Few organizations have reached levels 4 and 5: Targets for the 

future 

● Maturity level 4: Managed level 

• Sets quality and productivity goals for each project 

• These quantities are measured continually 

• Corrective action is taken when unacceptable deviations from 

goal 

• Statistical quality controls in place to enable management to 

distinguish random and meaningful deviations 

• E.g., number of faults detected per 1000 LOC and objective to 

reduce it 


● Maturity level 5: Optimizing level 

• Ggoal is continuous process improvement 

• Statistical quality and process control techniques are used 

• Knowledge gained from each project utilized in future projects 

• Positive feedback loop: Steady improvement in productivity and 

quality 

● For an organization to improve its software process 

• First, attempts to understand its current process 

• Then, formulates the intended process 

• Next, actions to achieve this process improvement are 

determined and ranked in priority 

• Finally, a plan to accomplish this improvement is drawn up and 

executed 


● This series of steps is repeated 

• Organization improving its software process 

• Progression from level to level 

● Advancing a complete maturity level 

• Takes 18 months to 3 years 

• From level 1 to level 2 can take 3 to 5 years 

• Difficult to instill a methodical approach in an organization with 

an ad hoc and active approach




● A series of key process areas (KPAs) are highlighted that an 

organization should target to reach next maturity level 

• By SEI 

● KPAs for level 2 

• Requirements management: Determine the client’s needs 

• Project planning: Draw up a plan 

• Project tracking: Monitor deviations from that plan 

• Configuration management: Control various pieces of product 

• Software quality assurance: Ensure that product is fault free 

● KPAs for level 5 

• Fault prevention 

• Technology change management 

• Process change management 


● Within each KPA is a group of related goals 

• Between two to four 

• If achieved: KPA is attained 

• E.g., one project planning goal: Development of a plan that 

appropriately and realistically covers activities of software 

development 

● To aid an organization to reach higher maturity levels 

• A series of questionnaires are developed that form basis of an 

assessment by an SEI team 

• To highlight current shortcomings 

• To indicate ways in which organization can improve 

● One of original goals of CMM program was to raise quality of 

software 

• By evaluating processes of contractors who produce software 

for DoD 

• Awarding contracts to contractors with a mature process 


• Any software development organization that wants to be a DoD 

contractor must conform to SW-CMM level 3 by 1998 

● The SW-CMM program has moved far beyond limited goal of 

improving DoD software 

● Implemented to improve software quality and productivity

Other Software Process Improvement Initiatives 

● A different attempt to improve software quality is based on 

the International Organization for Standardization (ISO) 

9000-series standards 

• A series of five related standards 

• Applicable to a variety of industrial activities including design, 

development, production, installation, and servicing 

• Not just a software standard 

• Within the ISO 9000 series, Standard ISO 9001 for quality 

systems most applicable to software development 

• ISO 9000-3 is specific guidelines to assist in applying ISO 9001 

to software 

● Features distinguishing ISO 9000 from CMM 

• ISO 9000 stresses documenting process in both words and 

pictures 


● Adherence to ISO 9000 standard does not guarantee a high 

quality product 

• Rather reduces risk of a poor-quality product 

● ISO 9000 is only one part of a quality system, also requiring 

• Management commitment to quality 

• Intensive training of workers 

• Setting, achieving goals for continual quality improvement 

● ISO 9000-series standards have been adopted by over 60 

countries 

• Including U.S., Japan, Canada, and the European Union 

• ISO 9000-compliant certifications may be required 

• Required by EU clients from U.S. software organizations 

● A certified registrar (auditor) has to examine company’s 

process: Certify that process complies with the ISO standard 

● More U.S. organizations are requiring ISO 9000 certification 


● ISO/IEC 15504 is an international process improvement 

initiative 

● Like ISO 9000 

● Formerly known as SPICE 

• Software Process Improvement Capability dEtermination 

• Contributions from over 40 countries 

• Initiated by the British Ministry of Defense (MOD) 

● First version completed in 1995 

● Taken over by a joint committee of ISO and the International 

Electrotechnical Commission (IEC) 

● Name changed from SPICE to ISO/IEC 15504 

Costs and Benefits of Software Process Improvement 

● Results indicate that implementing software process 

improvement leads to increased profitability 

● Hughes Aircraft Software Engineering Division 

• Spent $0.5 million between 1987 and 1990 

• For assessments and improvement programs 

• Moved up from maturity level 2 to level 3 

• Expectations of future levels 4 and 5 

• Estimated annual savings of $2 million 

• Decreased overtime hours 

• Fewer crises 

• Improved employee morale 

• lower turnover of software professionals


● Raytheon Equipment Division 

• Moved from level 1 to level 3 

• From 1988 to 1993 

• Twofold increase in productivity 

• Return of $7.70 for every $1 invested in process improvement 

● Tata Consultancy Services in India 

• Used ISO 9000 and CMM 

• From 1996 to 2000 

• Errors in effort estimation decreased from 50% to 15% 

• Effectiveness of reviews (percentage of faults found) increased 

from 40% to 80% 

• Efforts devoted to reworking projects dropped from 12% to 6% 

● Capability maturity models are applied relatively widely within 

U.S. software industry and abroad 


● Motorola Government Electronics Division (GED) 

● Involved in SEI’s software process improvement program 

● 34 GED projects 

● Categorized according to maturity level of group 

● Quality measured in terms of faults per million equivalent 

assembler source lines (MEASL) 

• To compare projects implemented in different languages 

• Number of lines of source code converted into MEASL 

● Productivity relative to level 2 

• not measured at level 1 

● Motorola does not publish actual productivity 

● More organizations worldwide are realizing that process 

improvement is cost effective 




● Process improvement movement has resulted in interactions 

between software process improvement initiatives and 

software engineering standards 

● ISO/IEC 12207: Full life-cycle software standard (1995) 

● IEEE/EIA 12207: Incorporates U.S. software “best 

practices” (1998) 

• Many can be traced back to CMM 

• By Institute of Electrical and Electronics Engineers (IEEE) and 

Electronic Industries Alliance (EIA) 

● To achieve compliance with IEEE/EIA 12207: An organization 

must be at or near CMM level 3 

● This interplay between software engineering standards 

organizations and software process improvement initiatives 

will lead to even better software processes

CHAPTER 03 THE SOFTWARE PROCESS

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?