software engineering processes lecture 3. advanced software engineering- asst prof athar mohsin,...

Software Engineering Processes

Lecture 3

Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST2

Terms & Definitions • Process

– A process describes the sequence of steps that a knowledgeable professional should follow to do a specified task.

• Defined Processes– A documented sequence of steps required to do a specific job.

• Processes are usually defined for jobs that are done repeatedly and need to be done in the same way each time that they are performed.

• Process & Plans– Processes and Plans include both the process steps and other

elements required for a specific instantiation of that process:• such as resources needed, roles of various project members, schedules,

budget, goals and objectives, commitments, and identified risks.

• Process Phases – A defined process consists of a set of steps,

• Any process must have three phases: planning, development, and postmortem.

Software Process • A software process can be defined as the coherent set of policies,

organizational structures, technologies, procedures, and artifacts that are needed to conceive, develop, deploy, and maintain a software product.

– Software Process: A Roadmap by Alfonso Fuggetta

– Software development technology:• Technological support used in the process (Tools, Techniques, infrastructure, envo

etc).

– Software development methods and techniques:• organizations and people

– Organizational behavior:• Science of organizations and people

– Marketing and economy. • must address real customers’ needs in specific market settings.

• Software process models often represent a networked sequence of activities and events that represent strategies for accomplishing software evolution.



Essential Phases of any Software Development Process

• Essential Phases:

– Requirements Elicitation, Analysis, Specification

– System Design

– Program Implementation

– Test

• Each Phase has an “Output”– Software Requirements

Specification (SRS), Use Cases– Design Document, Design

Classes, – Code– Test Report, Change Requests

• Process Model – Different projects may interpret these phases differently.– Each particular style is called a “Software Life-Cycle Model”– Serve as a basis for planning, organizing, staffing, coordinating,

budgeting, and directing software development activities• How software is or should be developed.


SWEBOK Guide = 10 Knowledge AreasMapped TO ISO/IEC 12207:1995 processes

Software Quality

Software Engineering Tools and Methods

Software Engineering Process

Software Engineering Management

Software Configuration Management

MaintenanceTestingConstructionDesignRequirements

Primary Processes

Supporting Processes


Criticism

• Criticism on software development

• Counter criticism– widespread adaptation and use of software process

methodologies


Requirem entsEngineeringProces sRequirem entsE lic itationRequirem entsAnalysisRequirem entsSpecif icationRequirem entsValidationRequirem entsM anagem en t

S o ftw a reR e q u ire m e n ts

Software DesignBasic ConceptsKey Issues inSoftware DesignSoftware S tructureand ArchitectureSoftware DesignQ uality analysisand Ev aluationSoftware DesignNotationsSoftware DesignStrategies andM ethods

S o ftw a reD e s ign

Linguistic M ethodsForm al M ethodsV isual M ethods

Reduc ation inCom plexity


Anticipation o fD iversity


Structuring for validation


Use of Externa lS tandards

S o ftw a reC o n s tru c tion

Basic ConceptsandDefin itionsTest LevelsTest TechniquesTest-related M easuresM anaging the Tes tProces s

S o ftw a reT e s t

BasicConceptsM aintenanc eProces sKey issuesInSoftwareM aintenanc eTechn iquesforM aintenanc e

S o ftw a reM a in te na n ce

M anagem ent of theSCM ProcessSoftwareConfigurationIdentficationSoftwareConfigurationContro lSoftwareConfigurationS tatus AccountingSoftwareConfigurationAuditingSoftware Releas eM anagem en tandDelivery

S o ftw a reC o n fig u ra tionM a na ge m e nt

O rgaqnizationa lM anagem en tProcess/ProjectM anagem en tSoftwareEngineeringM easurem en t

S o ftw a reE n g in e ering

M a na ge m e nt

Engineering P roces sConceptsProcess InfrastructureProcess M easurem en tProcess DefinitionQ ualitative Proces sAnalysisProces sIm plem entationand C hange


P ro ce ss

Requirem entsToolsDesign toolsConstruc tion toolsTesting toolsM aintenance toolsEngineering P roces sToolsQ uality toolsCongifurationM anagem en tToolsEngineeringM anagem en tToolsInfrastructureSuppor tToolsM iscellaneous too lIssues

SoftwareTools

Heuristic M ethodsForm al M ethodsPrototyping M ethodsM iscellaneous m ethodIssues

SoftwareM ethods


T o o ls & M eth o ds

Q ualityConceptsDefin ition& P lanningfor Q ualityTechn iquesRequ iring2 or m orePeopleSupport toothe rTechn iquesTesting Specia lToSQ A or V&VDefect F indingTechn iquesM easurem ent inSoftware Q ualityAnalysis

S o ftw a re Q u a lity

S W E B O K

• A structured framework for development

Software Engineering Body of Knowledge

(IEEE/ACM Stone-man Version 0.9 February 2001)…

WWW.SWEBOK.ORG


Today’s Discussion

• The Software Engineering Process KA can be examined on two levels. – First level encompasses:

• The technical and managerial activities within the software life cycle processes that are performed during software acquisition, development, maintenance, and retirement.

– Second is the meta-level, which is concerned with the:

• Definition, implementation, assessment, measurement, management, change, and improvement of the software life cycle processes themselves.

(IEEE/ACM Stone-man Version 0.9 February 2001)…


Software Engineering Process• The term “software engineering process” can be

interpreted in different ways, and this may cause confusion.– One meaning, where the word the is used (the software

engineering process), could imply that there is only one right way of performing software engineering tasks.

• Avoid this interpretation, because no such process exists.

– IEEE12207 standard Software engineering processes, meaning:

• There are many processes involved, such as Development Process or Configuration Management Process.


Software Engineering Process- SWEBOK

• Another meaning refers to the general discussion of processes related to software engineering.

• Yet another meaning could signify the actual set of activities performed within an organization, which could be viewed as one process, especially from within the organization.

• Software engineering process related activities are relevant to and have been performed successfully:– Large organizations, Small Organizations, Teams, and

Individuals.


Software Process Many different software processes but all involve:

Specification – defining what the system should do; Design and implementation – defining the organization of the system

and implementing the system; Validation – checking that it does what the customer wants; Evolution – changing the system in response to changing customer

needs.

A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

Basic Steps of Software ProcessThe basic Software Process has three phases. 1. Planning: Produce a plan to do the work. 2. Development: Perform the work.

a. Define the requirements b. Design the program c. Review the design and fix all defects d. Code the program e. Review the code and fix all defects f. Build / compile and fix all defects g. Test the program and fix all defects

3. Postmortem: Compare actual performance against the plan, record process data, produce a summary report, and document all ideas for process improvement.


Software Process Knowledge Area


Software Engineering Process • Focuses on organizational change. It

describes:– The infrastructure, activities, models, and

practical considerations for process implementation and change

• Process evolution

• Process Infrastructure– The resources must be available and the

responsibilities assigned• Competent staff, tools, funding and commitment


Software Process Management Cycle• The mgmt of SW processes consists of four

activities sequenced in an iterative cycle:– Establish Process Infrastructure activity– The Planning activity:

• To understand the current business objectives• To identify strengths and weaknesses• To make a plan for process implementation and

change.– The Process Implementation and Change activity:

• To execute the plan, deploy new processes (involve, the deployment of tools and training of staff)

– Process Evaluation:• Finding out how well the implementation and change went.


Process Infrastructure activity• A team using a well structured Programming

language to develop a system, effect of change ( from C to OOP):– Technical issues

• Effect of change e.g from C to OOP, requires education, training, techniques and appropriate time to get conversant

– Management problem• understand the implications of using the new technology plus the

change in culture within the organization, • secondly managing the current system, plus the time lost through

all the training and education plus the change over to the new system.

– Resourcing issues including:• cost of training, loss of technical and managerial resource during

training, cost of additional consultancy etc,


Process Definition • Software Life Cycle Models

– serve as a high-level definition of the phases that occur during development.

– Aimed to highlight the key activities and their interdependencies

• Waterfall model, through away prototyping model, evolutionary development, incremental/iterative delivery, the spiral model, the reusable software model

• Software Life Cycle Processes– More detailed than software life cycle models

• Information Technology — Software Life Cycle Processes [IEEE 12207.0-96].

• Some software life cycle processes emphasize rapid delivery and strong user participation, namely agile methods such as Extreme Programming


Development Vs Process models – Software process models based on the evolutionary development of

applications are being recognized as important for success in the production of commercial software. (Argument #1)

– Important aspect of software development is conformance to an appropriate process model? (Argument #2)

• Take any process model as example and view it from verity of following – Good technical team– Use of the right tools– Use of the right method of computation– Clear and stable set of requirements– Good configuration management and change control– Good project management (technical and personnel)– Good planning


IEEE Support to Process Lifecycle • The IEEE 1074:1997 standard on developing life cycle

processes:– Provides a list of processes and activities for software development

and maintenance• A list of life cycle activities which can be mapped into processes and

organized in the same way as any of the software life cycle models

– Standard identifies and links other IEEE software standards to these activities

– Standard can be used to build processes conforming to any of the life cycle models

• Standards which focus on maintenance processes are IEEE Std 1219-1998 and ISO 14764: 1998

• IEEE/EIA12207, contain mechanisms and recommendations for accomplishing the adaptation.


IEEE Std 1074: Standard for Software Lifecycle

IEEE Std 1074IEEE Std 1074

Project Management

Project Management

Pre-Development

Pre-Development

Develop-ment

Develop-ment

Post-Development

Post-Development

Cross-Development

(Integral Processes)

Cross-Development

(Integral Processes)

> Project Initiation>Project Monitoring &Control> Software Quality Management

> Concept Exploration> System Allocation

> Requirements Analysis> Design> Implemen- tation

> Installation> Operation & Support> Maintenance> Retirement

> V & V> Configuration Management> Documen- tation> Training

Process Group

Processes


IEEE/ISO 12207 • ISO 12207 offers a framework for software life-cycle

processes from concept through retirement. – Suitable for acquisitions:

• Recognizes the roles of acquirer and supplier– It is not applicable to the purchase of commercial-off-the-shelf (COTS)

software products.

– Provides a structure of processes using mutually accepted terminology

• “shall" to indicate mandatory provisions, • "should" for recommendations, and • "may" for permissible actions

• The standard is based on two basic principles: – modularity and responsibility.

• Modularity means processes with minimum coupling and maximum cohesion.

• Responsibility means to establish a responsibility for each process, facilitating the application of the standard in projects where many people can be legally involved.


A Sample 12207 Development Process

Process Implementation Activity

Supporting Processes: Documentation, CM, QA, Verification, Validation, Joint Review, Audit, Problem resolution

Organizational Processes: Management, Infrastructure, Improvement, Training

One example of applying 12207 to the Waterfall development strategy

SystemQual Test

System Integra-

tion

Software Installation

Software Acceptance Support

Software Item 1:

Sys ArchDesign

System Reqts

Analysis

SoftwareQual TestSoftware

Integra- tionSoftware

Code & TestSoftware

Detailed Design

Software Arch.

DesignSoftware Reqts.

Analysis

Software Item 2:

SoftwareQual TestSoftware

Integra- tionSoftware

Code & TestSoftware

Detailed Design

Software Arch.

DesignSoftware Reqts.

Analysis

Hardware items


Tailoring 12207• 12207 should be tailored for a project - no two projects are

the same• Tailoring considerations:

– Life cycle activity: prototyping, maintenance– Software characteristics: COTS, reuse, embedded firmware – Org’s policies, languages, hardware reserve, culture– Acquisition strategy: contract type, contractor involvement– Life cycle strategy: waterfall, evolutionary, spiral, etc.

• The Tailoring Process (12207.0 )1. Identify project environment - strategy, activity, requirements2. Solicit inputs - from users, support team, potential bidders3. Select processes, activities, documentation, responsibilities4. Document tailoring decisions and rationale

What CAN’T be tailored: the intent or objectives

What CAN be tailored: number of phases/activities, roles, responsibilities, document formats, formality/frequency of reports or reviews


Example Process activities

• Software specification– The process of establishing what services are required

and the constraints on the system’s operation and development.

• Software design and implementation– The process of converting the system specification into an

executable system. Major Process activities are:• Architectural design, Abstract specification, Interface design• Component design, Data structure design, Algorithm design

– Software design• Design a software structure that realises the specification;

– Implementation• Translate this structure into an executable program;


The software design process• Deriving a solution which satisfies software requirements

– Architectural design: Identify sub-systems.

– Abstract specification: Specify sub-systems.

– Interface design: Describe sub-system interfaces.

– Component design: Decompose sub-systems into components.

– Data structure design: Design data structures to hold problem data.

– Algorithm design: Design algorithms for problem functions.

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products


Process Activities • Different processes organise activities in different ways &

are described at different levels of details.– Real time software in aircraft

• has to be completely specified before the development

– eCommerce system • the development and the specification could be together

• Use of inappropriate process, – probably reduce the quality or the usefulness of the software

product

• Generic process models– Waterfall– Evolutionary development– Integration from reusable components

• CBSE– Upper-CASE Tools to support the early process activities of requirements and

design– Lower-CASE Tools to support later activities such as programming, debugging and

testing

• There are many variants of these models


Plan-driven and agile processes

Plan-driven processes:Processes where all of the process activities are planned

in advance and progress is measured against this plan.

Agile processes:Planning is incremental and it is easier to change the

process to reflect changing customer requirements.

In practice, most practical processes include elements of both plan-driven and agile approaches.

There are no right or wrong software processes.


Why focus on process? •Process provides a constructive, high-leverage focus...–as opposed to a focus on people

• Your work force is as good as it is trained to be.• Working harder is not the answer.• Working smarter, through process, is the answer.

–as opposed to a focus on technology• Technology applied without a suitable roadmap will not

result in significant payoff.• Technology provides the most benefit in the context of an

appropriate process roadmap.


Software lifecycle Process Models • Lifecycle - The steps through which the product

progresses• Software life cycle models serve as a high-level definition of

the phases that occur during development. – They are not aimed at providing detailed definitions but at

highlighting the key activities and their interdependencies. – Examples of software life cycle models are

• Build-and-fix model

• Waterfall model

• Rapid prototyping model

• Incremental model

• Extreme programming

• Synchronize-and-stabilize model

• Spiral model ………… Process Models

Process Improvement


Build and Fix Model• Problems

– No specifications– No design

• Totally unsatisfactory for any reasonable size software

• Need life-cycle model– Phases– Milestones


Waterfall Model• The only widely-used model

until the early 80’s• Characterized by

– Feedback loops– Documentation-driven – Each phase needs to be

approved by SQA

• Advantages – Enforced disciplined approach– Documentation– Maintenance easier

• Disadvantages– Specifications not easily

understood by clients

• Deficiencies – All requirements must be known upfront– Deliverables created for each phase are considered

frozen – inhibits flexibility– Can give a false impression of progress– Does not reflect problem-solving nature of software

development – iterations of phases– Integration is one big bang at the end– Little opportunity for customer to preview the system

(until it may be too late)

• When to use – Requirements are very well known– Product definition is stable– Technology is understood– New version of an existing product– Porting an existing product to a new platform.


Rapid Prototyping Model• Rapid prototype – a working

model functionally equivalent to a subset of the product– Determine what the client needs– When developed, the client and

users try using it– When they are satisfied, the

process moves to the next phase

• Linear model– Specifications are drawn from the

rapid prototype– Feedback loops are not used

• “Rapid” is the key


Integrating Waterfall and Rapid Prototyping Models

• Waterfall model– Many successes– Client needs may not be met

• Rapid prototyping model– Some success but not really proven – Has own problems

• Solution– Rapid prototyping for requirements phase– Waterfall for rest of life cycle


SDLC• V-Shaped SDLC Model

– A variant of the Waterfall that emphasizes the verification and validation of the product.

– Testing of the product is planned in parallel with a corresponding phase of development

• Project and Requirements Planning – allocate resources

• Product Requirements and Specification Analysis – complete specification of the software system

• Architecture or High-Level Design – defines how software functions fulfill the design

• Detailed Design – develop algorithms for each architectural component

• Production, operation and maintenance – provide for enhancement and corrections

• System and acceptance testing – check the entire software system in its environment

• Integration and Testing – check that modules interconnect correctly

• Unit testing – check that each module acts as expected

• Coding – transform algorithms into software

• Strengths – Emphasize planning for verification and validation of

the product in early stages of product development– Each deliverable must be testable– Project management can track progress by

milestones– Easy to use

• Deficiencies – Does not easily handle concurrent events– Does not handle iterations or phases– Does not easily handle dynamic changes in

requirements– Does not contain risk analysis activities

• When to use– Excellent choice for systems requiring high

reliability – hospital patient control applications

– All requirements are known up-front– When it can be modified to handle changing

requirements beyond analysis phase – Solution and technology are known


Incremental Model• The product is designed,

implemented, integrated and tested as a series of builds

• A build consists of code pieces from various modules interacting to provide a specific functionality

• Too few builds can lead to build-and-fix model

• Too many builds can lead to inefficient development


Concurrent Incremental Model

• More risky version—pieces may not fit– CABTAB (code a bit and test a bit) and its dangers


Spiral Model• Simplified Waterfall model

plus risk analysis– Uses rapid prototypes

• Precede each phase by– Alternatives– Risk analysis

• Follow each phase by– Evaluation– Planning of next phase


Spiral SDLC Model• Adds risk analysis, and RAD

prototyping to the waterfall model

• Each cycle involves the same sequence of steps as the waterfall process model

– Objectives: functionality, performance, hardware/software interface, critical success factors, etc.

– Alternatives: build, reuse, buy, sub-contract, etc.– Constraints: cost, schedule, interface, etc.

Spiral QuadrantDetermine objectives, alternatives and constraints

Spiral QuadrantEvaluate alternatives, identify and resolve risks

• Study alternatives relative to objectives and constraints

• Identify risks (lack of experience, new technology, tight schedules, poor process, etc.

• Resolve risks (evaluate if money could be lost by continuing system development

Spiral QuadrantDevelop next-level product

• Typical activities:– Create a design, Review design– Develop code, Inspect code– Test product

Spiral QuadrantPlan next phase• Typical activities

– Develop project plan

– Develop configuration management plan

– Develop a test plan

– Develop an installation plan

• Strength – Provides early indication of risks, without much cost– Users see the system early because of rapid

prototyping tools– Critical high-risk functions are developed first– The design does not have to be perfect – Users can be closely tied to all lifecycle steps– Early and frequent feedback from users– Cumulative costs assessed frequently

• Deficiencies – Time spent for evaluating risks too large for small or low-risk

projects– Time spent planning, resetting objectives, doing risk analysis and

prototyping may be excessive– The model is complex – Risk assessment expertise is required– Spiral may continue indefinitely– Developers must be reassigned during non-development phase

activities– May be hard to define objective, verifiable milestones that indicate

readiness to proceed through the next iteration

• When to use – When creation of a prototype is appropriate– When costs and risk evaluation is important– For medium to high-risk projects– Long-term project commitment unwise because of

potential changes to economic priorities– Users are unsure of their needs– Requirements are complex– New product line – Significant changes are expected (research and

exploration)

• Suitability to modern SDLC– Appreciation of risk, – The possibility of stopping a project that

exhibited too much risk, – knowledge of the phases (determine objectives,

identify and assess risk, develop and verify next-level product, and plan next phase)


Agile SDLC’s• Speed up or bypass one or more life cycle phases

– Usually less formal and reduced scope– Used for time-critical applications– Used in organizations that employ disciplined methods

• Some Agile methods – Adaptive Software Development (ASD) – Feature Driven Development (FDD) – Crystal Clear – Dynamic Software Development Method (DSDM) – Rapid Application Development (RAD)– Scrum – Extreme Programming (XP) – Rational Unify Process (RUP)


Extreme Programming

• Approach based on the incremental model– Development team determines stories (features client

wants)– Estimate duration and cost of each story– Select stories for next build– Each build is divided into tasks– Test cases for task are drawn up first– Pair programming– Continuous integration of tasks


Differences of Agile• Focus on collaboration:

– Less paperwork and more conversation– Stakeholders actively involved

• Focus on working software:– Greater feedback makes agile projects easier to manage– Less documentation is required– Less bureaucracy

• Agilists are generalizing specialists:– Less hand offs between people– Less people required– Specialists find it difficult at first to fit into the team

• Agile is based on practice, not theory:– This is a significant change from traditional

– You need to see how agile works in practice to truly understand it

Agile Common Practices •Regular Deployment of Working Software•Pair Programming•Refactoring•Continuous Integration•Test Driven Development (TDD)•Shared Code Ownership•Active Stakeholder Participation

Agile Common Practices •Regular Deployment of Working Software•Pair Programming•Refactoring•Continuous Integration•Test Driven Development (TDD)•Shared Code Ownership•Active Stakeholder Participation


Agile Myths Vs Reality

Myth1. No Documentation

2. Undisciplined

3. No Planning

4. Not Predictable

5. Does Not Scale

6. Is a fashion

7. Silver Bullet

8. RUP isn’t agile

9. Not Fixed Price

Reality

1. Agile Documentation

2. Requires great discipline

3. Just-in-time (JIT) planning

4. Far more predictable

5. Eclipse is agile

6. It’s quickly becoming the norm

7. It requires skilled people

8. RUP is agile

9. Agile provides stakeholders control over the budget, schedule, and scope


Agile vs. Plan Driven Processes

1. Small products and teams; scalability limited

2. Untested on safety-critical products

3. Good for dynamic, but expensive for stable environments.

4. Require experienced Agile personnel throughout

5. Personnel succeed on freedom and chaos

1. Large products and teams; hard to scale down

2. Handles highly critical products; hard to scale down

3. Good for stable, but expensive for dynamic environments

4. Require experienced personnel only at start if stable environment

5. Personnel succeed on structure and order


Organization& Meetings

Roles &Responsibilities

Processes

Measures

Policies &Standards

Mission & Principles

Agility - Set of Practices

Practical Governance Body

Staged Program Delivery

Simple And Relevant Metrics

Continuous Project Monitoring

Iterative Development

Adapt The Process

Risk-Based Milestones

Continuous Improvement

Embedded Compliance

Manage Project Pipeline By Business Value

Scenario-Driven Development

Self-Organizing Teams

Align HR Policies With IT Values

Align Organization Structure With Architecture

Integrated Lifecycle Environment

Valued Corporate Assets

Flexible Architectures


References• Guide to the Software Engineering Body of Knowledge: 2004

• Trip, Leonard L., Professionalization of Software Engineering: Next Steps,

• “A Summary of the ACM Position on Software Engineering as a Licensed Engineering Profession”,

• “An Assessment of Software Engineering Body of Knowledge Efforts: A Report to the ACM Council“,

• Humphrey, W.S. (1990). Managing the Software Process. Addison-Wesley Publishing Company, New York, NY.

• Process Models in Software Engineering, Walt Scacchi, Institute for Software Research, University of California, Irvine

• M. B. Chrissis, M. Konrad and S. Shrum, CMMI: Guidelines for Process Integration and Product Improvement, Pearson Education Inc., Boston, 2003.

• Scott W. Ambler, www-306.ibm.com/software/rational/bios/ambler.html

software engineering processes lecture 3. advanced software engineering- asst prof athar mohsin,...

Documents