Process Models

PROCESS MODELS

Muhammad Adil Raja

Roaming Researchers, Inc.

cbna

April 28, 2015

OUTLINE

1 INTRODUCTION

2 GENERIC PROCESS MODELS

3 PROCESS ASSESSMENT AND IMPROVEMENT

4 PERSPECTIVE PROCESS MODELS

5 SPECIALIZED PROCESS MODELS

6 THE UNIFIED PROCESS

7 PERSONAL AND TEAM PROCESS MODELS

8 PROCESS TECHNOLOGY

9 PRODUCT AND PROCESS

10 SUMMARY

11 REFERENCES

OUTLINE

1 INTRODUCTION









10 SUMMARY

11 REFERENCES

OUTLINE

1 INTRODUCTION









10 SUMMARY

11 REFERENCES

OUTLINE

1 INTRODUCTION









10 SUMMARY

11 REFERENCES

OUTLINE

1 INTRODUCTION









10 SUMMARY

11 REFERENCES

OUTLINE

1 INTRODUCTION









10 SUMMARY

11 REFERENCES

OUTLINE

1 INTRODUCTION









10 SUMMARY

11 REFERENCES

OUTLINE

1 INTRODUCTION









10 SUMMARY

11 REFERENCES

OUTLINE

1 INTRODUCTION









10 SUMMARY

11 REFERENCES

OUTLINE

1 INTRODUCTION









10 SUMMARY

11 REFERENCES

OUTLINE

1 INTRODUCTION









10 SUMMARY

11 REFERENCES

INTRODUCTION

• What is a software process?• What are the generic framework activities that are present

in every software process?• How are processes modeled and what are process

patterns?• What are the prescriptive process models and what are

their strengths and weaknesses?• Why is agility a watchword in modern software engineering

work?• What is agile software development and how does it differ

from more traditional process models?

PROCESS MODELS I

• What is it? When you work to build a product or system,it’s important to go through a series of predictable steps –a road map that helps you create a timely, high-qualityresult. The road map that you follow is called a “softwareprocess”.

• Who does it? Software engineers and their managersadapt the process to their needs and then follow it. Inaddition, the people who have requested the software havea role to play in the process of defining, building, andtesting it.

PROCESS MODELS II

• Why is it important? Because it provides stability, control,and organization to an activity that can, if left uncontrolled,become quite chaotic. However, a modern softwareengineering approach must be “agile”. It must demandonly those activities, controls, and work products that areappropriate for the project team and the product that is tobe produced.

• What are the steps? At a detailed level, the process thatyou adopt depends on the software that you’re building.One process might be appropriate for creating software foran aircraft avionics system, while an entirely differentprocess would be indicated for the creation of a website.

• What is the work product? From the point of view of asoftware engineer, the work products are the programs,documents, and data that are produced as a consequenceof the activities and tasks defined by the process.

PROCESS MODELS III

• How do I ensure that I’ve done it right? There are anumber of software process assessment mechanisms thatenable organizations to determine the “maturity” of theirsoftware process. However, the quality, timeliness, andlong-term viability of the product you build are the bestindicators of the efficacy of the process that you use.

GENERIC PROCESS MODELS I

DEFINITION

A process is defined as a collection of work activities, actions,and tasks that are performed when some work product is to becreated. Each of these activities, actions, and tasks residewithin a framework or model that defines their relationship withthe process and with one another.

• Each framework activity is populated by a set of softwareengineering actions.

• Each software engineering action is defined by a task setthat identifies the work tasks that are to be completed, thework products that will be produced, the quality assurancepoints that will be required, and the milestones that will beused to indicate progress.

GENERIC PROCESS MODELS II

• The hierarchy of technical work within the software processis activities, encompassing actions, populated by tasks.

• a generic process framework for software engineeringdefines five framework activities – communication,planning, modeling, construction, and deployment.

• In addition, a set of umbrella activities – project trackingand control, risk management, quality assurance,configuration management, technical reviews, and others –are applied throughout the process.

• A process flow – describes how the framework activitiesand the actions and tasks that occur within each frameworkactivity are organized with respect to sequence and time.

• What actions are appropriate for a framework activity,given the nature of the problem to be solved, thecharacteristics of the people doing the work, and thestakeholders who are sponsoring the project?

GENERIC PROCESS MODELS III

• For a small software project the communication activitycould be:

1 Make contact with stakeholder via telephone.2 Discuss requirements and take notes.3 Organize notes into a brief written statement of

requirements.4 E-mail to stakeholder for review and approval.

TASK SET I

• A task set defines the actual work to be done toaccomplish the objectives of a software engineering action.

• For example, elicitation (more commonly called“requirements gathering”) is an important softwareengineering action that occurs during the communicationactivity.

• The goal of requirements gathering is to understand whatvarious stakeholders want from the software that is to bebuilt.

• For a small, relatively simple project, the task set forrequirements gathering might look like this:

1 Make a list of stakeholders for the project.2 Invite all stakeholders to an informal meeting.3 Ask each stakeholder to make a list of features and

functions required.4 Discuss requirements and build a final list.

TASK SET II

5 Prioritize requirements.6 Note areas of uncertainty.

• For a larger, more complex software project, a differenttask set would be required.

• It might encompass the following work tasks:1 Make a list of stakeholders for the project.2 Interview each stakeholder separately to determine overall

wants and needs. Build a preliminary list of functions andfeatures based on stakeholder input.

3 Schedule a series of facilitated application specificationmeetings.

4 Conduct meetings.5 Produce informal user scenarios as part of each meeting.6 Refine user scenarios based on stakeholder feedback.7 Build a revised list of stakeholder requirements.8 Use quality function deployment techniques to prioritize

requirements.

TASK SET III

9 Package requirements so that they can be deliveredincrementally.

10 Note constraints and restrictions that will be placed on thesystem.

11 Discuss methods for validating the system.

• Both of these task sets achieve “requirements gathering”,but they are quite different in their depth and formality.

• The software team chooses the task set that will allow it toachieve the goal of each action and still maintain qualityand agility.

PROCESS PATTERNS I

DEFINITION

Every software team encounters problems as it moves throughthe software process. It would be useful if proven solutions tothese problems were readily available to the team so that theproblems could be addressed and resolved quickly. A processpattern describes a process-related problem that isencountered during software engineering work, identifies theenvironment in which the problem has been encountered, andsuggests one or more proven solutions to the problem. Statedin more general terms, a process pattern provides you with atemplate – a consistent method for describing problemsolutions within the context of the software process. Bycombining patterns, a software team can solve problems andconstruct a process that best meets the needs of a project.

PROCESS PATTERNS II

• Patterns can be defined at any level of abstraction.• In some cases, a pattern might be used to describe a

problem (and solution) associated with a complete processmodel (e.g., prototyping).

• In other situations, patterns can be used to describe aproblem (and solution) associated with a framework activity(e.g., planning) or an action within a framework activity(e.g., project estimating).

• A pattern template provides a consistent means fordescribing a pattern.

• Ambler has proposed a template for describing a processpattern:

• Pattern Name.

PROCESS PATTERNS III

• The pattern is given a meaningful name describing it withinthe context of the software process (e.g.,TechnicalReviews).

• Forces. The environment in which the pattern isencountered and the issues that make the problem visibleand may affect its solution.

• Type. The pattern type is specified.• Ambler suggests three types:

1 Stage pattern – defines a problem associated with aframework activity for the process. Since a frameworkactivity encompasses multiple actions and work tasks, astage pattern incorporates multiple task patterns (see thefollowing) that are relevant to the stage (frameworkactivity).

2 An example of a stage pattern might beEstablishingCommunication.

PROCESS PATTERNS IV

3 This pattern would incorporate the task patternRequirementsGathering and others.

4 Task pattern – defines a problem associated with asoftware engineering action or work task and relevant tosuccessful software engineering practice (e.g.,RequirementsGathering is a task pattern).

5 Phase pattern – define the sequence of frameworkactivities that occurs within the process, even when theoverall flow of activities is iterative in nature. An example ofa phase pattern might be SpiralModel or Prototyping.

AN EXAMPLE PROCESS PATTERN I

• The following abbreviated process pattern describes anapproach that may be applicable when stakeholders havea general idea of what must be done but are unsure ofspecific software requirements.

• Pattern name. RequirementsUnclear• Intent. This pattern describes an approach for building a

model (a prototype) that can be assessed iteratively bystakeholders in an effort to identify or solidify softwarerequirements.

• Type. Phase pattern.• Initial context. The following conditions must be met prior

to the initiation of this pattern:1 Stakeholders have been identified.2 A mode of communication between stakeholders and the

software team has been established.

AN EXAMPLE PROCESS PATTERN II

3 the overriding software problem to be solved has beenidentified by stakeholders.

4 an initial understanding of project scope, basic businessrequirements, and project constraints has been developed.

• Problem. Requirements are hazy or nonexistent, yet thereis clear recognition that there is a problem to be solved,and the problem must be addressed with a softwaresolution. Stakeholders are unsure of what they want; thatis, they cannot describe software requirements in anydetail.

• Solution. A description of the prototyping process would bepresented here and is described later in a later section.

• Resulting context. A software prototype that identifiesbasic requirements (e.g., modes of interaction,computational features, processing functions) is approvedby stakeholders.

AN EXAMPLE PROCESS PATTERN III

• Following this,1 the prototype may evolve through a series of increments to

become the production software or2 the prototype may be discarded and the production

software built using some other process pattern.

• Related patterns.• The following patterns are related to this pattern:

• CustomerCommunication,• IterativeDesign,• IterativeDevelopment,• CustomerAssessment,• RequirementExtraction.

• Known uses and examples.• Prototyping is recommended when requirements are

uncertain.

PROCESS ASSESSMENT AND IMPROVEMENT I

• Assessment attempts to understand the current state ofthe software process with the intent of improving it.

• The existence of a software process is no guarantee thatsoftware will be delivered on time, that it will meet thecustomer’s needs, or that it will exhibit the technicalcharacteristics that will lead to long-term qualitycharacteristics. Process patterns must be coupled withsolid software engineering practice.

• In addition, the process itself can be assessed to ensurethat it meets a set of basic process criteria that have beenshown to be essential for a successful softwareengineering.

• A number of different approaches to software processassessment and improvement have been proposed overthe past few decades:

PROCESS ASSESSMENT AND IMPROVEMENT II

• Standard CMMI Assessment Method for ProcessImprovement (SCAMPI) – provides a five-step processassessment model that incorporates five phases: initiating,diagnosing, establishing, acting, and learning.

• The SCAMPI method uses the SEI CMMI as the basis forassessment.

• CMM-Based Appraisal for Internal ProcessImprovement (CBA IPI) – provides a diagnostic techniquefor assessing the relative maturity of a softwareorganization; uses the SEI CMM as the basis for theassessment.

• SPICE (ISO/IEC15504) – a standard that defines a set ofrequirements for software process assessment.

• The intent of the standard is to assist organizations indeveloping an objective evaluation of the efficacy of anydefined software process.

PROCESS ASSESSMENT AND IMPROVEMENT III

• ISO 9001:2000 for Software – a generic standard thatapplies to any organization that wants to improve theoverall quality of the products, systems, or services that itprovides.

• Therefore, the standard is directly applicable to softwareorganizations and companies.

PERSPECTIVE PROCESS MODELS I

• Prescriptive process models were originally proposed tobring order to the chaos of software development.

• History has indicated that these traditional models havebrought a certain amount of useful structure to softwareengineering work and have provided a reasonably effectiveroad map for software teams.

THE WATERFALL MODEL I

• The waterfall model, sometimes called the classic lifecycle, suggests a systematic, sequential approach 6 tosoftware development that begins with customerspecification of requirements and progresses throughplanning, modeling, construction, and deployment,culminating in ongoing support of the completed software.

THE V-MODEL I

• A variation in the representation of the waterfall model iscalled the V-model.

• The V-model illustrates how verification and validationactions are associated with earlier engineering actions.

• As a software team moves down the left side of the V,basic problem requirements are refined into progressivelymore detailed and technical representations of the problemand its solution.

• Once code has been generated, the team moves up theright side of the V, essentially performing a series of tests(quality assurance actions) that validate each of themodels created as the team moved down the left side.

• In reality, there is no fundamental difference between theclassic life cycle and the V-model.

THE V-MODEL II

• The V-model provides a way of visualizing how verificationand validation actions are applied to earlier engineeringwork.

THE WATERFALL MODEL I

• The waterfall model is the oldest paradigm for softwareengineering.

• However, over the past three decades, criticism of thisprocess model has caused even ardent supporters toquestion its efficacy.

• Among the problems that are sometimes encounteredwhen the waterfall model is applied are:

1 Real projects rarely follow the sequential flow that the modelproposes. Although the linear model can accommodateiteration, it does so indirectly. As a result, changes cancause confusion as the project team proceeds.

2 It is often difficult for the customer to state all requirementsexplicitly. The waterfall model requires this and has difficultyaccommodating the natural uncertainty that exists at thebeginning of many projects.

THE WATERFALL MODEL II

3 The customer must have patience. A working version of theprogram(s) will not be available until late in the project timespan. A major blunder, if undetected until the workingprogram is reviewed, can be disastrous.

THE INCREMENTAL MODEL I

• The incremental model delivers a series of releases, calledincrements, that provide progressively more functionalityfor the customer as each increment is delivered.

• The incremental model combines elements of linear andparallel process flows.

• Referring to Figure 2.5, the incremental model applieslinear sequences in a staggered fashion as calendar timeprogresses.

• Each linear sequence produces deliverable “increments” ofthe software in a manner that is similar to the incrementsproduced by an evolutionary process flow (Section 2.3.3).

THE INCREMENTAL MODEL II

• For example, word-processing software developed usingthe incremental paradigm might deliver basic filemanagement, editing, and document production functionsin the first increment; more sophisticated editing anddocument production capabilities in the second increment;spelling and grammar checking in the third increment; andadvanced page layout capability in the fourth increment.

• Your customer demands delivery by a date that isimpossible to meet. Suggest delivering one or moreincrements by that date and the rest of the software(additional increments) later.

• It should be noted that the process flow for any incrementcan incorporate the prototyping paradigm.

• When an incremental model is used, the first increment isoften a core product.

THE INCREMENTAL MODEL III

• That is, basic requirements are addressed but manysupplementary features (some known, others unknown)remain undelivered.

• The core product is used by the customer (or undergoesdetailed evaluation).

• As a result of use and/or evaluation, a plan is developed forthe next increment. The plan addresses the modification ofthe core product to better meet the needs of the customerand the delivery of additional features and functionality.

• This process is repeated following the delivery of eachincrement, until the complete product is produced.

• The incremental process model focuses on the delivery ofan operational product with each increment.

• Early increments are stripped-down versions of the finalproduct, but they do provide capability that serves the userand also provide a platform for evaluation by the user.

THE INCREMENTAL MODEL IV• Incremental development is particularly useful when

staffing is unavailable for a complete implementation by thebusiness deadline that has been established for theproject.

• Early increments can be implemented with fewer people.• If the core product is well received, then additional staff (if

required) can be added to implement the next increment.• In addition, increments can be planned to manage

technical risks.• For example, a major system might require the availability

of new hardware that is under development and whosedelivery date is uncertain.

• It might be possible to plan early increments in a way thatavoids the use of this hardware, thereby enabling partialfunctionality to be delivered to end users without inordinatedelay.

THE EVOLUTIONARY PROCESS MODEL I

• Evolutionary process models produce an increasinglymore complete version of the software with each iteration.

• Evolutionary models are iterative.• They are characterized in a manner that enables you to

develop increasingly more complete versions of thesoftware.

• In the paragraphs that follow, I present two commonevolutionary process models.

PROTOTYPING I

• When your customer has a legitimate need, but is cluelessabout the details, develop a prototype as a first step.

• The prototyping paradigm begins with communication.• You meet with other stakeholders to define the overall

objectives for the software, identify whatever requirementsare known, and outline areas where further definition ismandatory.

• A prototyping iteration is planned quickly, and modeling (inthe form of a “quick design”) occurs. A quick designfocuses on a representation of those aspects of thesoftware that will be visible to end users (e.g., humaninterface layout or output display formats).

• The quick design leads to the construction of a prototype.

PROTOTYPING II

• The prototype is deployed and evaluated by stakeholders,who provide feedback that is used to further refinerequirements.

• Iteration occurs as the prototype is tuned to satisfy theneeds of various stakeholders, while at the same timeenabling you to better understand what needs to be done.

• Resist pressure to extend a rough prototype into aproduction product.

• Quality almost always suffers as a result.

THE SPIRAL MODEL I

• The spiral model can be adapted to apply throughout theentire life cycle of an application, from conceptdevelopment to maintenance.

• Using the spiral model, software is developed in a series ofevolutionary releases.

• During early iterations, the release might be a model orprototype. During later iterations, increasingly morecomplete versions of the engineered system are produced.

• The spiral model is a realistic approach to the developmentof large-scale systems and software.

• Because software evolves as the process progresses, thedeveloper and customer better understand and react torisks at each evolutionary level.

THE SPIRAL MODEL II

• The spiral model uses prototyping as a risk reductionmechanism but, more important, enables you to apply theprototyping approach at any stage in the evolution of theproduct.

• It maintains the systematic stepwise approach suggestedby the classic life cycle but incorporates it into an iterativeframework that more realistically reflects the real world.

THE CONCURRENT MODELS I

• The concurrent development model, sometimes calledconcurrent engineering, allows a software team torepresent iterative and concurrent elements of any of theprocess models described in this chapter.

• For example, the modeling activity defined for the spiralmodel is accomplished by invoking one or more of thefollowing software engineering actions: prototyping,analysis, and design.

• The concurrent model is often more appropriate forproduct engineering projects where different engineeringteams are involved.

SPECIALIZED PROCESS MODELS I

• Specialized process models take on many of thecharacteristics of one or more of the traditional modelspresented in the preceding sections.

• However, these models tend to be applied when aspecialized or narrowly defined software engineeringapproach is chosen.

COMPONENT-BASED DEVELOPMENT I

• Commercial off-the-shelf (COTS) software components,developed by vendors who offer them as products, providetargeted functionality with well-defined interfaces thatenable the component to be integrated into the softwarethat is to be built.

• The component-based development model incorporatesmany of the characteristics of the spiral model.

• It is evolutionary in nature, demanding an iterativeapproach to the creation of software.

• However, the component-based development modelconstructs applications from prepackaged softwarecomponents.

• An evolutionary approach is pursued as follows:

COMPONENT-BASED DEVELOPMENT II

1 Available component-based products are researched andevaluated for the application domain in question.

2 Component integration issues are considered.

3 A software architecture is designed to accommodate thecomponents.

4 Components are integrated into the architecture.

5 Comprehensive testing is conducted to ensure properfunctionality.

THE FORMAL METHODS MODEL I

• The formal methods model encompasses a set of activitiesthat leads to formal mathematical specification of computersoftware.

• Formal methods enable you to specify, develop, and verifya computer-based system by applying a rigorous,mathematical notation.

• A variation on this approach, called cleanroom softwareengineering, is currently applied by some softwaredevelopment organizations.

• When formal methods are used during development, theyprovide a mechanism for eliminating many of the problemsthat are difficult to overcome using other softwareengineering paradigms.

THE FORMAL METHODS MODEL II

• Ambiguity, incompleteness, and inconsistency can bediscovered and corrected more easily – not through ad hocreview, but through the application of mathematicalanalysis.

• When formal methods are used during design, they serveas a basis for program verification and therefore enableyou to discover and correct errors that might otherwise goundetected.

• the formal methods model offers the promise of defect-freesoftware.

• Concerns.1 The development of formal models is currently quite time

consuming and expensive.2 Because few software developers have the necessary

background to apply formal methods, extensive training isrequired.

THE FORMAL METHODS MODEL III

3 It is difficult to use the models as a communicationmechanism for techni- cally unsophisticated customers.

ASPECT-ORIENTED PROGRAMMING I

DEFINITION

ASPECT-ORIENTED PROGRAMMING II

AOCE uses a concept of horizontal slices throughvertically-decomposed software components, called “aspects”,to characterize cross-cutting functional and non-functionalproperties of components. Common, systemic aspects includeuser interfaces, collaborative work, distribution, persistency,memory management, transaction processing, security,integrity and so on. Components may provide or require one ormore “aspect details” relating to a particular aspect, such as aviewing mechanism, extensible affordance and interface kind(user interface aspects); event generation, transport andreceiving (distribution aspects); data store/retrieve and indexing(persistency aspects); authentication, encoding and accessrights (security aspects); transaction atomicity, concurrencycontrol and logging strategy (transaction aspects); and so on.Each aspect detail has a number of properties, relating tofunctional and/or non-functional characteristics of the aspectdetail.

THE UNIFIED PROCESS I

• A “use case driven, architecture-centric, iterative andincremental” software process.

• Phases of the UP:• UP phases are similar in intent to the generic framework

activities.• The inception phase of the UP encompasses both

customer communication and planning activities.• By collaborating with stakeholders, business requirements

the software are identified; a rough architecture for thesystem is proposed; and a plan for the iterative,incremental nature of the ensuing project is developed.

• Fundamental business requirements are describedthrough a set of preliminary use cases that describe whichfeatures and functions each major class of users desires.

THE UNIFIED PROCESS II

• Architecture at this point is nothing more than a tentativeoutline of major subsystems and the function and featuresthat populate them.

• Later, the architecture will be refined and expanded into aset of models that will represent different views of thesystem.

• Planning identifies resources, assesses major risks,defines a schedule, and establishes a basis for the phasesthat are to be applied as the software increment isdeveloped.

• The elaboration phase encompasses the communicationand modeling activities of the generic process model.

THE UNIFIED PROCESS III

• Elaboration refines and expands the preliminary use casesthat were developed as part of the inception phase andexpands the architectural representation to include fivedifferent views of the software – the use case model, therequirements model, the design model, the implementationmodel, and the deployment model.

• In some cases, elaboration creates an “executablearchitectural baseline” that represents a “first cut”executable system.

• The architectural baseline demonstrates the viability of thearchitecture but does not provide all features and functionsrequired to use the system.

• In addition, the plan is carefully reviewed at the culminationof the elaboration phase to ensure that scope, risks, anddelivery dates remain reasonable.

• Modifications to the plan are often made at this time.

THE UNIFIED PROCESS IV

• The construction phase of the UP is identical to theconstruction activity defined for the generic softwareprocess.

• Using the architectural model as input, the constructionphase develops or acquires the software components thatwill make each use case operational for end users.

• To accomplish this, requirements and design models thatwere started during the elaboration phase are completedto reflect the final version of the software increment.

• All necessary and required features and functions for thesoftware increment (i.e., the release) are thenimplemented in source code.

• As components are being implemented, unit tests 21 aredesigned and executed for each.

• In addition, integration activities (component assembly andinte- gration testing) are conducted.

THE UNIFIED PROCESS V

• Use cases are used to derive a suite of acceptance teststhat are executed prior to the initiation of the next UPphase.

• The transition phase of the UP encompasses the latterstages of the generic construction activity and the first partof the generic deployment (delivery and feedback) activity.

• Software is given to end users for beta testing and userfeedback reports both defects and necessary changes.

• In addition, the software team creates the necessarysupport information (e.g., user manuals, troubleshootingguides, installation procedures) that is required for therelease.

• At the conclusion of the transition phase, the softwareincrement becomes a usable software release.

• The production phase of the UP coincides with thedeployment activity of the generic process.

THE UNIFIED PROCESS VI

• During this phase, the ongoing use of the software ismonitored, support for the operating environment(infrastructure) is provided, and defect reports andrequests for changes are submitted and evaluated.

• It is likely that at the same time the construction, transition,and production phases are being conducted, work mayhave already begun on the next software increment.

• This means that the five UP phases do not occur in asequence, but rather with staggered concurrency.

• A software engineering workflow is distributed across allUP phases. In the context of UP, a workflow is analogousto a task set (described earlier in this chapter).

• That is, a workflow identifies the tasks required toaccomplish an important software engineering action andthe work products that are produced as a consequence ofsuccessfully completing the tasks.

THE UNIFIED PROCESS VII

• It should be noted that not every task identified for a UPworkflow is conducted for every software project.

• The team adapts the process (actions, tasks, subtasks,and work products) to meet its needs.

PERSONAL AND TEAM PROCESS MODELS I

• The best software process is one that is close to thepeople who will be doing the work.

• If a software process model has been developed at acorporate or organizational level, it can be effective only if itis amenable to significant adaptation to meet the needs ofthe project team that is actually doing software engineeringwork.

• In an ideal setting, you would create a process that bestfits your needs, and at the same time, meets the broaderneeds of the team and the organization.

• Alternatively, the team itself can create its own process,and at the same time meet the narrower needs ofindividuals and the broader needs of the organization.

PERSONAL SOFTWARE PROCESS (PSP) I

• The PSP model defines five framework activities:• Planning: This activity isolates requirements and develops

both size and resource estimates. In addition, a defectestimate (the number of defects projected for the work) ismade. All metrics are recorded on worksheets ortemplates. Finally, development tasks are identified and aproject schedule is created.

• High-level design: External specifications for eachcomponent to be constructed are developed and acomponent design is created. Prototypes are built whenuncertainty exists. All issues are recorded and tracked.

• High-level design review: Formal verification methodsare applied to uncover errors in the design. Metrics aremaintained for all important tasks and work results.

PERSONAL SOFTWARE PROCESS (PSP) II

• Development: The component-level design is refined andreviewed. Code is generated, reviewed, compiled, andtested. Metrics are maintained for all important tasks andwork results.

• Postmortem: Using the measures and metrics collected(this is a substantial amount of data that should beanalyzed statistically), the effectiveness of the process isdetermined. Measures and metrics should provideguidance for modifying the process to improve itseffectiveness.

TEAM SOFTWARE PROCESS (TSP) I

• Objectives for TSP:• Build self-directed teams that plan and track their work,

establish goals, and own their processes and plans.• These can be pure software teams or integrated product

teams (IPTs) of 3 to about 20 engineers.• Show managers how to coach and motivate their teams

and how to help them sustain peak performance.• Accelerate software process improvement by making CMM

Level 5 behavior normal and expected.• Provide improvement guidance to high-maturity

organizations.• Facilitate university teaching of industrial-grade team skills.• TSP defines the following framework activities: project

launch, high-level design, implementation, integration andtest, and postmortem.

TEAM SOFTWARE PROCESS (TSP) II

• TSP scripts define elements of the team process andactivities that occur within the process.

PROCESS TECHNOLOGY

• Process Modeling Tools.• Objective: If an organization works to improve a business

(or software) process, it must first understand it.• Process modeling tools (also called process technology or

process management tools) are used to represent the keyelements of a process so that it can be better understood.

• Such tools can also provide links to process descriptionsthat help those involved in the process to understand theactions and work tasks that are required to perform it.

• Process modeling tools provide links to other tools thatprovide support to defined process activities.

• Mechanics: Tools in this category allow a team to definethe elements of a unique process model (actions, tasks,work products, QA points), provide detailed guidance onthe content or description of each process element, andthen manage the process as it is conducted.

• In some cases, the process technology tools incorporatestandard project management tasks such as estimating,scheduling, tracking, and control.

PRODUCT AND PROCESS

• On the duality of product and process.

SUMMARY I

• A generic process model for software engineeringencompasses a set of framework and umbrella activities,actions, and work tasks.

• Each of a variety of process models can be described by adifferent process flow – a description of how the frameworkactivities, actions, and tasks are organized sequentiallyand chronologically.

• Process patterns can be used to solve common problemsthat are encountered as part of the software process.

• Prescriptive process models have been applied for manyyears in an effort to bring order and structure to softwaredevelopment.

SUMMARY II

• Each of these models suggests a somewhat differentprocess flow, but all perform the same set of genericframework activities: communication, planning, modeling,construction, and deployment.

• Sequential process models, such as the waterfall and Vmodels, are the oldest software engineering paradigms.

• They suggest a linear process flow that is ofteninconsistent with modern realities (e.g., continuouschange, evolving systems, tight time lines) in the softwareworld.

• They do, however, have applicability in situations whererequirements are well defined and stable.

• Incremental process models are iterative in nature andproduce working versions of software quite rapidly.

SUMMARY III

• Evolutionary process models recognize the iterative,incremental nature of most software engineering projectsand are designed to accommodate change.

• Evolutionary models, such as prototyping and the spiralmodel, produce incremental work products (or workingversions of the software) quickly.

• These models can be adopted to apply across all softwareengineering activities – from concept development tolong-term system maintenance.

• The concurrent process model allows a software team torepresent iterative and concurrent elements of any processmodel.

SUMMARY IV

• Specialized models include the component-based modelthat emphasizes component reuse and assembly; theformal methods model that encourages a mathematicallybased approach to software development and verification;and the aspect-oriented model that accommodatescrosscutting concerns spanning the entire systemarchitecture.

• The Unified Process is a “use case driven,architecture-centric, iterative and incremental” softwareprocess designed as a framework for UML methods andtools.

• Personal and team models for the software process havebeen proposed.

• Both emphasize measurement, planning, and self-directionas key ingredients for a successful software process.

REFERENCES

• Images and content for developing these slides have beentaken from the follwoing book.

• Software Engineering: A Practitioner’s Approach, Roger S.Pressman.

• This presentation is developed using Beamer:• Pittsburgh, monarca.