Overview of Software Engineering

CS 330

Spring 2007

Key Ingredients in successful organizations

People

Technology

Process

A better viewProcess and Technology supporting people

Processes Technology

People

Pyramids are stable. Wedges are not!

What is software? Computer programs and associated documentation

Software products may be developed for a particular customer or may be developed for a general market

Software products may be– Generic/COTS - developed to be sold to a range of different

customers– Custom- developed for a customer according to their

specification

Engineering

Engineering is …– The application of scientific principles and methods to the

construction of useful structures & machines Examples

– Mechanical engineering– Computer engineering– Civil engineering– Chemical engineering– Electrical engineering– Nuclear engineering– Aeronautical engineering

Software Engineering The term is 35 years old: NATO Conferences

– Garmisch, Germany, October 7-11, 1968– Rome, Italy, October 27-31, 1969

The reality is it is finally beginning to arrive– Computer science one the scientific basis

• Years of studies/experience/statistics provide basis too– Many aspects have been made systematic

• Methods/methodologies/techniques• Languages• Tools• Processes

Why Engineer Software ? The problem is complexity Many sources, but size is a key:

– Mozilla contains 3 Million lines of code– UNIX contains 4 million lines of code– Windows 2000 contains 108 lines of code

Second is role and combinatorics of “state” Third is uncertainty of “inputs” and their timing Fourth is the continuing changing “environment” and

demands. Software engineering is about managing

all the sources of complexity to produce effective software.

Software Engineering in a Nutshell

Development of software systems whose size/complexity warrants team(s) of engineers– multi-person construction of multi-version software

[Parnas 1987] Scope

– study of software process, development/management principles, techniques, tools and notations

Goal– production of quality software, delivered on time, within

budget, satisfying customers’ requirements and users’ needs

What does a software engineer do?

Software engineers should – adopt a systematic and organised approach to all

aspects of software development.– use appropriate tools and techniques depending on

• the problem to be solved, • the development constraints and • the resources available

– Understand and communicate processes for improved software development within their organization

– Be effective team members and/or leaders.– Can be very technical or more managerial depending

on organizational need.

What is the difference between software engineering and computer science?

Computer Science Software Engineeringis concerned with

Computer science theories are currently insufficient to act as a complete underpinning for software engineering, BUT it is a foundation for practical aspects of software engineering

theory fundamentals

the practicalities of developing delivering useful software

What is the difference between software engineering and system engineering?

Software engineering is part of System engineering System engineering is concerned with all aspects of

computer-based systems development including – hardware, – software and – process engineering

System engineers are involved in system specification, architectural design, integration and deployment

Difficulties? SE is a unique brand of engineering

– Software is malleable– Software construction is human-intensive– Software is intangible and generally invisible– Software problems are unprecedentedly complex– Software directly depends upon the hardware

• It is at the top of the system engineering “food chain”

– Software solutions require unusual rigor– Software “state” means behaviors can depend on history. – Software has discontinuous operational nature

Software Engineering ≠ Software Programming

Software programming– Single developer– “Toy” applications– Short lifespan– Single or few stakeholders

• Architect = Developer = Manager = Tester = Customer = User

– One-of-a-kind systems– Built from scratch– Minimal maintenance

Software Engineering ≠ Software Programming

Software engineering– Teams of developers with multiple roles– Complex systems– Indefinite lifespan– Numerous stakeholders

• Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User

– System families– Reuse to amortize costs– Maintenance accounts for 60%-80% of overall

development costs

Economic and Management Aspects of SE

Software Engineering is about improved ROI (can be Capital and/or Social ROI)

Software production =development + maintenance

Maintenance costs 60%-80% of all (successful) development costs– 20% corrective (12%-16% total costs)– 30% adaptive (18%-24% total costs)– 50% perfective (30-40% total costs)

Quicker development is not always preferable– higher up-front costs may defray downstream costs– poorly designed/implemented software is a critical cost factor in

system cost and delays

Relative Costs of Fixing Software Faults

Requirements Specification Planning Design Implementation Integration Maintenance

1 2 3 410

30

200

Mythical Man-Monthby Fred Brooks

Published in 1975, republished in 1995– Experience managing development of OS/360 in 1964-65

Central argument– Large projects suffer management problems different in kind than small

ones, due to division in labor– Critical need is the preservation of the conceptual integrity of the

product itself Central conclusions

– Conceptual integrity achieved through chief architect– Implementation achieved through well-managed effort– “software developers” are not interchangeable work units.

Brooks’ Law– Adding personnel to a late project makes it later

Software Engineering:From Principles to Tools

PRINCIPLES

METHODS ANDTECHNIQUES

METHODOLOGIES

TOOLS

Software Qualities Qualities are goals in the practice of

software engineering, and directly relate to many of the guiding principles.

External vs. Internal qualities Product vs. Process qualities

Software Qualities Critical Quality Attributes

– Correctness– Maintainability– Dependability– Usability– Reliability

Other Attributes– Completeness– Compatibility– Portability– Internationalization– Understandability– Scalability– Robustness– Testability– Reusability– Customizability– Efficiency

External vs. Internal Qualities External qualities are visible to the user

– reliability, usability, efficiency (maybe), robustness, scalability

Internal qualities are the concern of developers– they help developers achieve external qualities– verifiability, maintainability, extensibility,

evolvability, adaptability, portability, testability, reusability

Product vs. Process Qualities Product qualities concern the developed

artifacts– maintainability, performance, understandability,

Process qualities deal with the development activity– products are developed through process– maintainability, productivity, predictability

Some Software Qualities Correctness

– ideal quality– established w.r.t. the requirements/specification– absolute

Reliability– statistical property– probability that software will operate as expected

over a given period of time/inputs– relative

Some Software Qualities (cont.) Robustness

– “reasonable” behavior in unforeseen circumstances

– subjective– a specified requirement is an issue of

correctness;an unspecified requirement is an issue of robustness

Usability– ability of end-users to easily use software – extremely subjective

Some Software Qualities (cont.) Understandability

– ability of developers to easily understand produced artifacts

– internal product quality– subjective

Verifiability– ease of establishing desired properties – performed by formal analysis or testing– internal quality

Some Software Qualities (cont.) Performance

– equated with efficiency– assessable by measurement, analysis, and

simulation Evolvability

– ability to add or modify functionality– addresses adaptive and perfective maintenance– problem: evolution of implementation is too easy– evolution should start at requirements or design

Some Software Qualities (cont.) Reusability

– ability to construct new software from existing pieces– must be planned for– occurs at all levels: from people to process, from

requirements to code Interoperability

– ability of software (sub)systems to cooperate with others

– easily integratable into larger systems– common techniques include APIs, distributed

programming interfaces (CORBA, DCOM), plug-in protocols, etc.

Some Software Qualities (cont.) Scalability

– ability of a software system to grow in size while maintaining its properties and qualities

– assumes maintainability and evolvability– goal of component-based development

Process Principles

Prescribes all major activities Uses resources, within a set of constraints, to

produce intermediate and final products May be composed of sub-processes Each activity has entry and exit criteria Activities are organized in a sequence Has a set of guiding principles to explain goals Constraints may apply to activity, resource or

product

Software Development Stages Requirements Analysis & Specification Conceptual/System/Architectural Design Detailed/Program Design Implementation/Coding Unit & Integration Testing System Testing/Validation System Delivery/Deployment Maintenance

– Note there are many “variations” on the names. You are responsible for the main categories above (an on the next pages)..

Software Lifecycle Models Waterfall Model V Model Phased Development Model

– Incremental Model Prototyping Model Spiral Model

Software Development LifecycleWaterfall Model

Requirements

Design

Implementation

Integration

Validation

Deployment

Plan/Schedule

Replan/Reschedule

V Model

REQUIREMENTSANALYSIS

SYSTEMDESIGN

PROGRAMDESIGN

CODING

UNIT & INTE-GRATION TESTING

SYSTEMTESTING

ACCEPTANCETESTING

OPERATION& MAINTENANCE

Verify design

Validate requirements

[Pfleeger 98]

Phased Development Model

Development systems

Production systems

DEVE

LOPE

RSUS

ERS

Build Release 1

Use Release 1

Build Release 2

Use Release 2

Build Release 3

Use Release 3

Time

[Pfleeger 98]

Software Development Lifecycle Incremental Model

Requirements Design

Implementation Integration

Validation Deployment

Requirements Design

Implementation Integration

Validation Deployment

Requirements Design

Implementation Integration

Validation Deployment

Version 1:Complete General Design

Version 2:Design/Implement first set of planned “new” features.

Note overlap with V1 schedule

Version 3:Design/Implement second set

of planned “new” features

Prototyping Model

[Pressman 97]

Listen to Customer

CustomerTest-drives

Mock-up

Build/ReviseMock-Up

Prototyping Model

LIST OFREVISIONS

LIST OFREVISIONS

LIST OFREVISIONS

PROTOTYPEREQUIREMENTS

PROTOTYPEDESIGN

PROTOTYPESYSTEM

TEST

DELIVEREDSYSTEMSYSTEM

REQUIREMENTS(sometimes informal

or incomplete)

reviseprototype

user/customerreview

[Pfleeger 98]

Spiral development Process is represented as a spiral rather than as a

sequence of activities with backtracking. Each loop in the spiral represents a phase in the

process. No fixed phases such as specification or design -

loops in the spiral are chosen depending on what is required.

Risks are explicitly assessed and resolved throughout the process.

Spiral model of the software process

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

designCode

Unit testIntegration

testAcceptancetestService Develop, verify

next-level product

Evaluate alternatives,identify, resolve risks

Determine objectives,alternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW

Spiral model sectors Objective setting

– Specific objectives for the phase are identified. Risk assessment and reduction

– Risks are assessed and activities put in place to reduce the key risks.

Development and validation– A development model for the system is chosen which

can be any of the generic models. Planning

– The project is reviewed and the next phase of the spiral is planned.

Evolutionary development Exploratory development

– Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer.

Throw-away prototyping– Objective is to understand the system requirements.

Should start with poorly understood requirements to clarify what is really needed.

Evolutionary development

Concurrentactivities

ValidationFinal

version

Development Intermediateversions

SpecificationInitial

version

Outlinedescription

Evolutionary development Problems

– Lack of process visibility;– Systems are often poorly structured;– Special skills (e.g. in languages for rapid prototyping)

may be required. Applicability

– For small or medium-size interactive systems;– For parts of large systems (e.g. the user interface);– For short-lifetime systems.

Component-based software engineering

Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems.

Process stages– Component analysis;– Requirements modification;– System design with reuse;– Development and integration.

This approach is becoming increasingly used as component standards have emerged.

Reuse-oriented development

Requirementsspecification

Componentanalysis

Developmentand integration

System designwith reuse

Requirementsmodification

Systemvalidation

Component-Based Development Develop generally applicable components of a

reasonable size and reuse them across systems Make sure they are adaptable to varying contexts Extend the idea beyond code to other

development artifacts Question: what comes first?

– Integration, then deployment– Deployment, then integration

Different Flavors of Components Third-party software “pieces” Plug-ins / add-ins Applets Frameworks Open Systems Distributed object infrastructures Compound documents Legacy systems

Process iteration System requirements ALWAYS evolve in the

course of a project so process iteration where earlier stages are reworked is always part of the process for large systems.

Iteration can be applied to any of the generic process models.

Two (related) approaches– Incremental delivery;– Spiral development.

Incremental delivery

Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality.

User requirements are prioritised and the highest priority requirements are included in early increments.

Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.

Incremental development

Validateincrement

Develop systemincrement

Design systemarchitecture

Integrateincrement

Validatesystem

Define outline requirements

Assign requirements to increments

System incomplete

Finalsystem

Incremental development advantages

Customer value can be delivered with each increment so system functionality is available earlier.

Early increments act as a prototype to help elicit requirements for later increments.

Lower risk of overall project failure. The highest priority system services tend to

receive the most testing.

Extreme programming An approach to development based on the

development and delivery of very small increments of functionality.

Relies on constant code improvement, user involvement in the development team and pairwise programming.

Covered in Chapter 17

Software Development LifecycleWaterfall Model

Requirements

Design

Implementation

Integration

Validation

Deployment

Plan/Schedule

Replan/Reschedule

Software specification The process of establishing what services are

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

Requirements engineering process– Feasibility study;– Requirements elicitation and analysis;– Requirements specification;– Requirements validation.

Requirements

Problem Definition → Requirements/Specification– determine exactly what the customer and user need (maybe want)– Requirements develop a contract with the customer– Specification say what the software product is to do

Difficulties– client is computer/software illiterate (no idea what is doable)– client asks for wrong product (want vs need)– client is computer/software literate (specifies solution not need)– specifications are ambiguous, inconsistent, incomplete

Studies have shown that the percentage of defects originating during requirements engineering is estimated at more than 50 percent. The total percentage of project budget due to requirements defects is 25 to 40 percent.

The requirements engineering process

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

Software design and implementation

The process of converting the system specification into an executable system.

Software design– Design a software structure that realises the

specification; Implementation

– Translate this structure into an executable program; The activities of design and implementation are

closely related and may be inter-leaved.

Design process activities Architectural design Abstract specification Interface design Component design Data structure design Algorithm design

The software design process

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specificationAlgorithm

specification

Requirementsspecification

Design activities

Design products

Structured methods Systematic approaches to developing a software

design. The design is usually documented as a set of

graphical models. Possible models

– Object model;– Sequence model;– State transition model;– Structural model;– Data-flow model.

Architecture vs. Design[Perry & Wolf 1992]

Architecture is concerned with the selection of architectural elements, their interactions, and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design.

Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements.

Architecture/Design Requirements/Specification → Architecture/Design

– architecture: decompose software into modules/objects/components with interfaces

– design: develop module/object/component specifications (algorithms, data types) and communication details

– maintain a record of design decisions and traceability– specifies how the software product is to do its tasks

Difficulties– miscommunication between module designers– design may be inconsistent, incomplete, ambiguous– “How” to achieve a requirement may be unknown

Planning/Scheduling Before undertaking cost of development, need to

estimate the costs/sizes of various steps– Estimate Code size– Estimate tools needed– Estimate personnel

Often Done after Architecture and before rest of design, but revised again after full design.

Develop schedule for aspects of project lifecycle If doing predictive/quantitative SE, build on past

experience, considering how to improve process.

Implementation & Integration

Design → Implementation– implement modules; verify that they meet their

specifications– combine modules according to the design– specifies how the software design is realized

Difficulties– module interaction errors– order of integration may influence quality and

productivity

Programming and debugging Translating a design into a program and removing

errors from that program. Programming is a personal activity - there is no

generic programming process. Programmers carry out some program testing to

discover faults in the program and remove these faults in the debugging process.

The debugging process

Locateerror

Designerror repair

Repairerror

Re-testprogram

Software validation Verification and validation (V & V) is intended

to show that a system conforms to its specification and meets the requirements of the system customer.

Involves checking and review processes and system testing.

System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system.

Verification and Validation Analysis

– Static– “Science”– Formal verification– Informal reviews and walkthroughs

Testing– Dynamic– “Engineering”– White box vs. black box– Structural vs. behavioral– Issues of test adequacy

The testing process

Componenttesting

Systemtesting

Acceptancetesting

Testing stages

Component or unit testing– Individual components are tested independently; – Components may be functions or objects or coherent

groupings of these entities. System testing

– Testing of the system as a whole. Testing of emergent properties is particularly important.

Acceptance testing– Testing with customer data to check that the system

meets the customer’s needs.

Testing phases

Requirementsspecification

Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand test

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

Service Acceptancetest

Systemintegration test

Sub-systemintegration test

Quality Assurance Done as part of each step Reduce costs by catching errors early. Help determine ambiguities/inconsistencies Help ensure quality product.

Requirements Specification Planning Design ImplementationIntegration Maintenance1 2 3 4 1030

200

Deployment Completed End-User Documentation

– Separate from Developer documentation Installation Process(es) Customer test procedures Support Processes (help desk, etc…) Trouble Tracking Repair/rework to address bugs Regression testing (as bugs are fixed)

Maintenance & Evolution Operation → Change

– maintain software during/after user operation– determine whether the product still functions correctly

Difficulties– Rigid or fragile designs– lack of documentation– personnel turnover

Software evolution Software is inherently flexible and can change. As requirements change through changing

business circumstances, the software that supports the business must also evolve and change.

Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new.

System evolution

Assess existingsystems

Define systemrequirements

Propose systemchanges

Modifysystems

Newsystem

Existingsystems

Why I include CASE Tools Computer Aides Software

Engineering tools support good SE processes (e.g. UML)

Some tools absolute requirement for scaling e.g. build and configuration management.

Integrated CASE (ICASE) tools embody good processes and improve productivity (E.g. Rational tool set)

Some tools (e.g. debuggers, Purify) do almost impossible for humans.

But.. Tools change– No SE tools from my first

3 jobs exist (except Fortran/C languages)

– I use regularly use 3 SE tools from my next set of jobs.

– Other tools I learned have been replaced with similar but expanded concepts.. Understanding today;s tools gives a basis for learning future ones.

ICASE Design Tools Rational Rose and

Rational Unified Development.

From UML drawing to code and back.

Generates stubs and eventually testing code.

Supports multiple languages

p u b l i c c l a s s C a r {

p u b l i c D r i v e r t h e D r i v e r ;/ * *

* @ r o s e u i d 3 E A F F 1 7 E 0 3 5 B* /

p u b l i c C a r ( ) {

}}

p u b l i c c l a s s D r i v e r {

/ * ** @ r o s e u i d 3 E A F F 5 3 F 0 2 F D* /

p u b l i c D r i v e r ( ) {

}}

Car Driver

Configuration Management

CM is a discipline whose goal is to control changes to large software through the functions of– Component identification– Change tracking– Version selection and baselining– Managing simultaneous updates (team work)– Build processes with automated regression

testing– Software manufacture

CM in Action

1.1

1.2

1.4

2.0

2.1

2.2

3.1

3.0

1.5

4.0

1.0

1.3

Build Tools Necessary for large projects. Keep track of what depends

upon on what, and what needs recompiled or regenerated when things change.

Important even for small 1-person projects as soon as you have multiple files.

Can do much more than just “compile”, can generate document (if using code-based docs), generate manufactured code (e.g. SOAP interfaces), even send emails or suggest alternatives.

E.g. in our “IUE” project, edit some files compile was one in seconds, edit another and a rebuild taking days would be needed. If more than 30 files impacted, our make process recommend a new “branch” to avoid conflicts!

Debugging Tools How do you see what the code is really doing (not

what it seems it should do)? How to you see what happened to code during

compiler optimization? How do you find/track down the cause of

Segfault/GFP in code you’ve never seen before? How can you “test” various possibilities without

generating special code or recompiling. How do you track down a memory leak?

Tools, workbenches, environments

Single-methodworkbenches

General-purposeworkbenches

Multi-methodworkbenches

Language-specificworkbenches

Programming TestingAnalysis anddesign

Integratedenvironments

Process-centredenvironments

FilecomparatorsCompilersEditors

EnvironmentsWorkbenchesTools

CASEtechnology

The Rational Unified Process A modern process model derived from the work

on the UML and associated process. Normally described from 3 perspectives

– A dynamic perspective that shows phases over time;– A static perspective that shows process activities;– A practive perspective that suggests good practice.

RUP phase model

Phase iteration

Inception Elaboration Construction Transition

RUP phases Inception

– Establish the business case for the system. Elaboration

– Develop an understanding of the problem domain and the system architecture.

Construction– System design, programming and testing.

Transition– Deploy the system in its operating environment.

RUP good practice Develop software iteratively Manage requirements Use component-based architectures Visually model software Verify software quality Control changes to software

Static workflows

Workflow Description

Business modelling The business processes are modelled using business use cases.

Requirements Actors who interact with the system are identified and use cases aredeveloped to model the system requirements.

Analysis and design A design model is created and documented using architecturalmodels, component models, object models and sequence models.

Implementation The components in the system are implemented and structured intoimplementation sub-systems. Automatic code generation from designmodels helps accelerate this process.

Test Testing is an iterative process that is carried out in conjunction withimplementation. System testing follows the completion of theimplementation.

Deployment A product release is created, distributed to users and installed in theirworkplace.

Configuration andchange management

This supporting workflow managed changes to the system (seeChapter 29).

Project management This supporting workflow manages the system development (seeChapter 5).

Environment This workflow is concerned with making appropriate software toolsavailable to the software development team.

Computer-aided software engineering

Computer-aided software engineering (CASE) is software to support software development and evolution processes.

Activity automation– Graphical editors for system model development;– Data dictionary to manage design entities;– Graphical UI builder for user interface construction;– Debuggers to support program fault finding;– Automated translators to generate new versions of a

program.

Case technology Case technology has led to significant

improvements in the software process. However, these are not the order of magnitude improvements that were once predicted– Software engineering requires creative thought - this is

not readily automated;– Software engineering is a team activity and, for large

projects, much time is spent in team interactions. CASE technology does not really support these.

CASE classification Classification helps us understand the different types

of CASE tools and their support for process activities. Functional perspective

– Tools are classified according to their specific function. Process perspective

– Tools are classified according to process activities that are supported.

Integration perspective– Tools are classified according to their organisation into

integrated units.

Functional tool classification

Tool type Examples

Planning tools PERT tools, estimation tools, spreadsheets

Editing tools Text editors, diagram editors, word processors

Change management tools Requirements traceability tools, change control systems

Configuration management tools Version management systems, system building tools

Prototyping tools Very high-level languages, user interface generators

Method-support tools Design editors, data dictionaries, code generators

Language-processing tools Compilers, interpreters

Program analysis tools Cross reference generators, static analysers, dynamic analysers

Testing tools Test data generators, file comparators

Debugging tools Interactive debugging systems

Documentation tools Page layout programs, image editors

Re-engineering tools Cross-reference systems, program re-structuring systems

Activity-based tool classification

Specification Design Implementation Verificationand

Validation

Re-engineering tools

Testing tools

Debugging tools

Program analysis tools

Language-processingtools

Method support tools

Prototyping tools

Configurationmanagement tools

Change management tools

Documentation tools

Editing tools

Planning tools

CASE integration Tools

– Support individual process tasks such as design consistency checking, text editing, etc.

Workbenches– Support a process phase such as specification or

design, Normally include a number of integrated tools.

Environments– Support all or a substantial part of an entire software

process. Normally include several integrated workbenches.

Boult’s view of SE SE must balance risks in software development process:

– Risks of error in • requirements • specification, • design, • implementation, • and integration

– Risks of exceeding available resources– Risks of being late on delivery or missing the market

Don’t let push for formality dominate your process. Don’t let push for expedience destroy your process.

Software Process Qualities Process is reliable if it consistently leads to high-

quality products Process is robust if it can accommodate

unanticipated changes in tools and environments

Process performance is productivity Process is evolvable if it can accommodate new

management and organizational techniques Process is reusable if it can be applied across

projects and organizations

Assessing Software Qualities

Qualities must be measurable/quantifiable Measurement requires that qualities be

precisely defined Improvement requires accurate and

consistent measurements For most SD groups, qualities are informally

defined and are difficult to assess

Software Engineering “Axioms” Adding developers to a project will likely result in further delays and

accumulated costs The longer a fault exists in software

– the more costly it is to detect and correct– the less likely it is to be properly corrected

Up to 70% of all faults detected in large-scale software projects are introduced in requirements and design– detecting the causes of those faults early may reduce their resulting costs by a

factor of 200 or more Basic tension of software engineering

– better, cheaper, faster — pick any two!– functionality, scalability, performance — pick any two!

Want/Need Management’s buy in to formal SE process. If you don’t document your process, you don’t have one!

Boehm’s Spiral Model

PLAN DEVELOP AND TEST

DETERMINE GOALS,ALTERNATIVES,CONSTRAINTS

EVALUATE ALTERNATIVESAND RISKS

Requirements,life-cycle plan

Budget 1

Alternatives1

Constraints1

Risk analysis 1

Risk analysis 2

Risk analysis 3

Risk analysis 4

Constraints 2

Constraints 3

Constraints 4

Budget 2Budget 3Budget 4

Alternativ

es2

Alternati

ves3

Alternati

ves4

Prototype 1

Proto -type 2

Proto -type 3

Proto -type 4

Concept ofoperation

Software

requir

emen

ts

Validated

requirements

DevelopmentplanIntegration

and test plan

Softw

arede

sign

Validated,

verified design

Detaileddesign

Code

Unit test

SystemtestAcceptance

testImplementation

plan

start

Key points Software processes are the activities involved in

producing and evolving a software system. Software process models are abstract representations of

these processes. General activities are specification, design and

implementation, validation and evolution. Generic process models describe the organisation of

software processes. Examples include the waterfall model, evolutionary development and component-based software engineering.

Iterative process models describe the software process as a cycle of activities.

Key points Requirements engineering is the process of developing

a software specification. Design and implementation processes transform the

specification to an executable program. Validation involves checking that the system meets to

its specification and user needs. Evolution is concerned with modifying the system

after it is in use. The Rational Unified Process is a generic process

model that separates activities from phases. CASE technology supports software process activities.