MCA Software Engg Unit 1 Ppt 1

Software Engineering (MCA-403)

Prepared By:

Mr. Sujit Kumar Singh

[email protected]

A.P in M.C.A department

MCA 1/338

mailto:[email protected]

Unit -1

Software Engineering Paradigms: Software Characteristics, Software myths, Software Applications,

Software Engineering Definitions, Software Process Models, Process iteration, Process activities,

Computer-aided software engineering (CASE) and CASE Tools.

Software Project Management: Management activities, Project planning, Project scheduling, Risk management and activities.

MCA 2/338

Objectives

• To introduce software engineering and to explain its importance

• To set out the answers to key questions about software engineering

• To introduce ethical and professional issues and to explain why they are of concern to software engineers

Software Engineering

• The economies of ALL developed nations are dependent on software.

• More and more systems are software controlled• Software engineering is concerned with

theories, methods and tools for professional software development.

• Expenditure on software represents a significant fraction of GNP in all developed countries.

What is software engineering?

• Software engineering is an engineering discipline that is concerned with all aspects of software production.

• Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available.

What is the difference between software engineering and computer

science?

• Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software.

• Computer science theories are still insufficient to act as a complete underpinning for software engineering (unlike e.g. physics and electrical engineering).

What is the difference between software engineering and system engineering?

• System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this process concerned with developing the software infrastructure, control, applications and databases in the system.

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

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 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 combinatories 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 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 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

Objectives

• To introduce software process models• To describe three generic process models and

when they may be used• To describe outline process models for

requirements engineering, software development, testing and evolution

• To explain the Rational Unified Process model• To introduce CASE technology to support

software process activities

Software Engineering Objectives

The software process

• A structured set of activities required to develop a software system– Specification;

– Design;

– Validation;

– Evolution.

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

Software Process

Topics covered

• Software process models

• Process iteration

• Process activities

• The Rational Unified Process

• Computer-aided software engineering

Software Process

What is a software process?

• A set of activities whose goal is the development or evolution of software.

• Generic activities in all software processes are:– Specification - what the system should do and its

development constraints– Development - production of the software system– Validation - checking that the software is what the

customer wants– Evolution - changing the software in response to changing

demands.

What is a software process model?

• A simplified representation of a software process, presented from a specific perspective.

• Examples of process perspectives are– Workflow perspective - sequence of activities;

– Data-flow perspective - information flow;

– Role/action perspective - who does what.

• Generic process models– Waterfall;

– Iterative development;

– Component-based software engineering.

Generic software process models

• The waterfall model– Separate and distinct phases of specification and development.

• Evolutionary development– Specification, development and validation are interleaved.

• Component-based software engineering– The system is assembled from existing components.

• There are many variants of these models e.g. formal development where a waterfall-like process is used but the specification is a formal specification that is refined through several stages to an implementable design.

Generic Software process Models

Waterfall model

Requirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation and

maintenance

Waterfall Models

Waterfall model phases

• Requirements analysis and definition• System and software design• Implementation and unit testing• Integration and system testing• Operation and maintenance• The main drawback of the waterfall model is the difficulty of

accommodating change after the process is underway. One phase has to be complete before moving onto the next phase.

Phases of Waterfall Models

Waterfall model problems

• Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.

• Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.

• Few business systems have stable requirements.

• The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites.

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 Model


Concurrentactivities

ValidationFinal

version

DevelopmentIntermediate

versions

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.

Evolutionary Development

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

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.

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 2

Prototype 3Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

Code

Unit test

IntegrationtestAcceptance

testService Develop, verifynext-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 development of Software Process


• 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.

What are the costs of software engineering?


• Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs.

• Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability.

• Distribution of costs depends on the development model that is used.

What are the attributes of good software?

• The software should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable.

• Maintainability– Software must evolve to meet changing needs;

• Dependability– Software must be trustworthy;

• Efficiency– Software should not make wasteful use of system resources;

• Acceptability– Software must accepted by the users for which it was designed. This

means it must be understandable, usable and compatible with other systems.

What are the attributes of Software?

What are software engineering methods?

• Structured approaches to software development which include system models, notations, rules, design advice and process guidance.

• Model descriptions– Descriptions of graphical models which should be produced;

• Rules– Constraints applied to system models;

• Recommendations– Advice on good design practice;

• Process guidance– What activities to follow.

What are software engineering Methods?

Process activities

• Software specification

• Software design and implementation

• Software validation

• Software evolution

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.

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

specification

Algorithmspecification


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.

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.

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


Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand test

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

ServiceAcceptance

testSystem

integration testSub-system

integration test

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.

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


• 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


• 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


• 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.


• 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

Software Lifecycle Models

• Waterfall Model

• V Model

• Phased Development Model

– Incremental Model

• Prototyping Model

• Spiral Model

Software Development LifecycleWater Fall 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

Prototyping Model

Listen to

Customer

Customer

Test-drives

Mock-up

Build/Revise

Mock-Up

Prototyping Model

LIST OFREVISIONS

LIST OFREVISIONS

LIST OFREVISIONS

PROTOTYPEREQUIREMENTS

PROTOTYPEDESIGN

PROTOTYPESYSTEM

TEST

DELIVEREDSYSTEMSYSTEM

REQUIREMENTS(sometimes informal

or incomplete)

reviseprototype

user/customerreview

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 2

Prototype 3Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

Code

Unit test

IntegrationtestAcceptance

testService Develop, verifynext-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 development

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.

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


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

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

specification

Algorithmspecification


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

• 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


Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand test

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

ServiceAcceptance

testSystem

integration testSub-system

integration 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 410

30

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 and

design

Integratedenvironments

Process-centredenvironments

Filecomparators

CompilersEditors

EnvironmentsWorkbenchesTools

CASEtechnology

Debugging Tools

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

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.

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

Characteristics of Software Products

General characteristics

Usability

Maintainability

Dependability

Efficiency

Good software products require good programming,

Software as a Product

Software is expensive!!

Every software project has a trade-off between:

Functionality

Resources (cost)

Timeliness

Risk Management

What can go wrong in a software project?

How can the risk be reduced?

System and Software Design

System design: Partition the requirements to hardware or software systems. Establishes an overall system architecture

Software design: Represent the software system functions in a form that can be transformed into one or more executable programs

Unified Modeling Language (UML)

Programming and Unit Testing

The software design is realized as a set of programs or program units. (Written specifically, acquired from elsewhere, or modified.)

Individual components are tested against specifications.

Integration and System Testing

The individual program units are:

integrated and tested as a complete system

tested against the requirements as specified

delivered to the client

Operation and Maintenance

Operation: The system is put into practical use.

Maintenance: Errors and problems are identified and fixed.

Evolution: The system evolves over time as requirements change, to add new functions or adapt the technical environment.

Phase out: The system is withdrawn from service.

Projects

Teams that are planning to carry out the Internet Butler project, please meet with me after the lecture.

Documentation

• Reasons for documentation:

visibility (e.g., project plan, interim report)

user support (e.g., user manual)

team communication (e.g., interface specifications)

maintenance and evolution (e.g., requirements)

• Characteristics of documentation:

accurate and kept current

appropriate for audience

maintained online (usually)

simple but professional in style and appearance

Documentation is expensive --> Quality not volume

Form of Documentation

External

• Printed

• Web site

Internal

• Program documentation

• Program context (e.g., copyright notices)

Requirements Analysis

1. Understand the requirements in depth:

• Domain understanding

Examples: Tote Investors, Philips light bulbs

• Stakeholders

Example: Andrew project

Interviews with Clients

Clients may have only a vague concept of requirements.

• Prepare before you meet with them

• Keep full notes

• If you don't understand, delve further

• Small group meetings are often most effective

Clients often confuse the current system with the underlying requirement.

Requirements Analysis

2. Organize the requirements:

• Classification into coherent clusters

(e.g., legal requirements)

• Recognize and resolve conflicts

(e.g., functionality v. cost v. timeliness)

Example: Dartmouth general ledger system

Copyright

A copyright gives the owner the exclusive right to:

• reproduce

• distribute

• perform

• display

• license

Gradually extended to cover text, music, photographs, designs, software, ...

Copyright

Copyright at creation

• Works for hire

• Contracts and licenses

• First sale

• Fair use

• Infringement (contamination)

International differences

• Moral rights

• Copyright registration

Objectives

• To explain the main tasks undertaken by project managers

• To introduce software project management and to describe its distinctive characteristics

• To discuss project planning and the planning process

• To show how graphical schedule representations are used by project management

• To discuss the notion of risks and the risk management process

S/W Project Management

Topics covered

• Management activities

• Project planning

• Project scheduling

• Risk management


• Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software.

• Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software.

Software project management


• The product is intangible.

• The product is uniquely flexible.

• Software engineering is not recognized as an engineering discipline with the sane status as mechanical, electrical engineering, etc.

• The software development process is not standardised.

• Many software projects are 'one-off' projects.

Software management distinctionsS/W Project Management Distinction

• Proposal writing.

• Project planning and scheduling.

• Project costing.

• Project monitoring and reviews.

• Personnel selection and evaluation.

• Report writing and presentations.

Management activitiesManagement Activities

Project staffing

• May not be possible to appoint the ideal people to work on a project– Project budget may not allow for the use of highly-paid staff;

– Staff with the appropriate experience may not be available;

– An organisation may wish to develop employee skills on a software project.

• Managers have to work within these constraints especially when there are shortages of trained staff.

Project Staffing

Project planning

• Probably the most time-consuming project management activity.

• Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available.

• Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget.

Project Planning

Types of project plan

Plan Description

Quality plan Describes the quality procedures and standards that will beused in a project. See Chapter 27.

Validation plan Describes the approach, resources and schedule used forsystem validation. See Chapter 22.

Configurationmanagement plan

Describes the configuration management procedures andstructures to be used. See Chapter 29.

Maintenance plan Predicts the maintenance requirements of the system,maintenance costs and effort required. See Chapter 21.

Staff developmentplan.

Describes how the skills and experience of the project teammembers will be developed. See Chapter 25.

Types of Project Plan

The project plan

• The project plan sets out:

– The resources available to the project;

– The work breakdown;

– A schedule for the work.

Project plan structure

• Introduction.

• Project organisation.

• Risk analysis.

• Hardware and software resource requirements.

• Work breakdown.

• Project schedule.

• Monitoring and reporting mechanisms.

Project Plan Structure

Project scheduling

• Split project into tasks and estimate time and resources required to complete each task.

• Organize tasks concurrently to make optimal use of workforce.

• Minimize task dependencies to avoid delays caused by one task waiting for another to complete.

• Dependent on project managers intuition and experience.

Project Scheduling

The project scheduling process

Estimate resourcesfor activities

Identify activitydependencies

Identifyactivities

Allocate peopleto activities

Softwarerequirements

Activity chartsand bar charts

Create projectcharts

Risk management

• Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project.

• A risk is a probability that some adverse circumstance will occur – Project risks affect schedule or resources;– Product risks affect the quality or performance of the

software being developed;– Business risks affect the organisation developing or

procuring the software.

The risk management process

• Risk identification– Identify project, product and business risks;

• Risk analysis– Assess the likelihood and consequences of these risks;

• Risk planning– Draw up plans to avoid or minimise the effects of the risk;

• Risk monitoring– Monitor the risks throughout the project;


Risk avoidanceand contingency

plans

Risk planning

Prioritised risklist

Risk analysis

List of potentialrisks

Riskidentification

Riskassessment

Riskmonitoring

Risk identification

• Technology risks.

• People risks.

• Organisational risks.

• Requirements risks.

• Estimation risks.

Risks and risk types

Risk type Possible risks

Technology The database used in the system cannot process as many transactions per secondas expected.Software components that should be reused contain defects that limit theirfunctionality.

People It is impossible to recruit staff with the skills required.Key staff are ill and unavailable at critical times.Required training for staff is not available.

Organisational The organisation is restructured so that different management are responsible forthe project.Organisational financial problems force reductions in the project budget.

Tools The code generated by CASE tools is inefficient.CASE tools cannot be integrated.

Requirements Changes to requirements that require major design rework are proposed.Customers fail to understand the impact of requirements changes.

Estimation The time required to develop the software is underestimated.The rate of defect repair is underestimated.The size of the software is underestimated.

Risk analysis

• Assess probability and seriousness of each risk.

• Probability may be very low, low, moderate, high or very high.

• Risk effects might be catastrophic, serious, tolerable or insignificant.

Risk analysis (i)

Risk Probability Effects

Organisational financial problems force reductions inthe project budget.

Low Catastrophic

It is impossible to recruit staff with the skills requiredfor the project.

High Catastrophic

Key staff are ill at critical times in the project. Moderate Serious

Software components that should be reused containdefects which limit their functionality.

Moderate Serious

Changes to requirements that require major designrework are proposed.

Moderate Serious

The organisation is restructured so that differentmanagement are responsible for the project.

High Serious

Risk analysis (ii)


The database used in the system cannot process asmany transactions per second as expected.

Moderate Serious

The time required to develop the software isunderestimated.

High Serious

CASE tools cannot be integrated. High Tolerable

Customers fail to understand the impact ofrequirements changes.

Moderate Tolerable

Required training for staff is not available. Moderate Tolerable

The rate of defect repair is underestimated. Moderate Tolerable

The size of the software is underestimated. High Tolerable

The code generated by CASE tools is inefficient. Moderate Insignificant

Risk planning

• Consider each risk and develop a strategy to manage that risk.• Avoidance strategies

– The probability that the risk will arise is reduced;• Minimisation strategies

– The impact of the risk on the project or product will be reduced;

• Contingency plans– If the risk arises, contingency plans are plans to deal with

that risk;

Risk monitoring

• Assess each identified risks regularly to decide whether or not it is becoming less or more probable.

• Also assess whether the effects of the risk have changed.

• Each key risk should be discussed at management progress meetings.

Objectives

• To introduce the concepts of user and system requirements

• To describe functional and non-functional requirements

• To explain how software requirements may be organised in a requirements document.

Risk monitoring

Objectives




Software Requirement Objectives

Objectives




Risk monitoring

The Aim of Project Management

To complete a project:

• On time

• On budget

• With required functionality

• To the satisfaction of the client

• Without exhausting the team

Role of Project Manager

• Create and maintain the schedule

• Should track progress against schedule

• Keep some slack in the schedule

• Be continually making adjustments:

Start activities before previous activity complete

Sub-contract activities

Renegotiate deliverables

• Keep senior management informed

Project Planning Methods

The Critical Path Method, Gantt charts, Activity bar charts, etc. are roughly equivalent.

These methods are best when:

• Model is updated regularly (e.g., monthly)

• The structure of the project is well understood

• The time estimates are reliable

• Activities do not share resources

[Critical Path Method is excellent for large construction

projects.]

Scheduling: Critical Path Method

An activity

A dummy activity

An event

A milestone

Critical Path Method

Edit Unit 3

Print Unit 3

Revise Unit 3

Mail Unit 3

Other

activities

START END


Edit Unit 3

Type set Unit 3

Revise Unit 3

Mail Units 3/4

Other activities

Edit Unit 4

Print Units 3/4

Revise Unit 4

Other activities

Type set Unit 4

START


START

Edit Unit 3

Script

TV 2

Make

TV 2

Edit Unit 4

Prototype Computer 1

Program Computer 1

Document

Computer 1

Mail

Delivery

Time Estimates for Activities (Weeks)

64

2

2

3

3

13

3

82

1 1

4

1212

1

4

What is a software process model?

• A simplified representation of a software process, presented from a specific perspective.

• Examples of process perspectives are– Workflow perspective - sequence of activities;

– Data-flow perspective - information flow;

– Role/action perspective - who does what.

• Generic process models– Waterfall;

– Iterative development;

– Component-based software engineering.


• Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs.

• Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability.

• Distribution of costs depends on the development model that is used.

What is CASE (Computer-Aided Software

Engineering)• Software systems that are intended to provide automated

support for software process activities.

• CASE systems are often used for method support.

• 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.

The software process

• A structured set of activities required to develop a software system– Specification;

– Design;

– Validation;

– Evolution.

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

Generic software process models

• The waterfall model– Separate and distinct phases of specification and development.

• Evolutionary development– Specification, development and validation are interleaved.

• Component-based software engineering– The system is assembled from existing components.

• There are many variants of these models e.g. formal development where a waterfall-like process is used but the specification is a formal specification that is refined through several stages to an implementable design.

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 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.

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.

Objectives

• To explain the main tasks undertaken by project managers

• To introduce software project management and to describe its distinctive characteristics

• To discuss project planning and the planning process

• To show how graphical schedule representations are used by project management

• To discuss the notion of risks and the risk management process

Project Management

Topics covered

• Management activities

• Project planning

• Project scheduling

• Risk management

Project Management

• Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software.

• Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software.

Software project managementProject Management

• The product is intangible.

• The product is uniquely flexible.

• Software engineering is not recognized as an engineering discipline with the sane status as mechanical, electrical engineering, etc.

• The software development process is not standardised.

• Many software projects are 'one-off' projects.

Software management distinctionsProject Management

• Proposal writing.

• Project planning and scheduling.

• Project costing.

• Project monitoring and reviews.

• Personnel selection and evaluation.

• Report writing and presentations.

Management activitiesManagement Activities

• These activities are not peculiar to software management.

• Many techniques of engineering project management are equally applicable to software project management.

• Technically complex engineering systems tend

to suffer from the same problems as software systems.

Management commonalities

Management Commonalities

Project staffing

• May not be possible to appoint the ideal people to work on a project– Project budget may not allow for the use of highly-paid staff;

– Staff with the appropriate experience may not be available;

– An organisation may wish to develop employee skills on a software project.

• Managers have to work within these constraints especially when there are shortages of trained staff.

Project Staffing

Project planning

• Probably the most time-consuming project management activity.

• Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available.

• Various different types of plan may be developed to support the main

software project plan that is concerned with schedule and budget.

Project Planning

Types of project plan

Plan Description

Quality plan Describes the quality procedures and standards that will beused in a project. See Chapter 27.

Validation plan Describes the approach, resources and schedule used forsystem validation. See Chapter 22.

Configurationmanagement plan

Describes the configuration management procedures andstructures to be used. See Chapter 29.

Maintenance plan Predicts the maintenance requirements of the system,maintenance costs and effort required. See Chapter 21.

Staff developmentplan.

Describes how the skills and experience of the project teammembers will be developed. See Chapter 25.

Types of Project Plan

Project planning process

Establish the project constraints

Make initial assessments of the project parameters

Define project milestones and deliverables

while project has not been completed or cancelled loop

Draw up project schedule

Initiate activities according to schedule

Wait ( for a while )

Review project progress

Revise estimates of project parameters

Update the project schedule

Re-negotiate project constraints and deliverables

if ( problems arise ) then

Initiate technical review and possible revision

end if

end loop

The project plan

• The project plan sets out:– The resources available to the project;– The work breakdown;– A schedule for the work.

Project plan structure

• Introduction.

• Project organisation.

• Risk analysis.

• Hardware and software resource requirements.

• Work breakdown.

• Project schedule.

• Monitoring and reporting mechanisms.

Project Plan Structure

Activity organization

• Activities in a project should be organised to produce tangible outputs for management to judge progress.

• Milestones are the end-point of a process activity.• Deliverables are project results delivered to customers.• The waterfall process allows for the straightforward definition of progress

milestones.

Activities Organization

Milestones in the RE process

Evaluationreport

Prototypedevelopment

Userrequirements

Requirementsanalysis

Feasibilityreport

Feasibilitystudy

Architecturaldesign

Designstudy

Systemrequirements


ACTIVITIES

MILESTONES

Milestone Re Project

Project scheduling

• Split project into tasks and estimate time and resources required to complete each task.

• Organize tasks concurrently to make optimal use of workforce.

• Minimize task dependencies to avoid delays caused by one task waiting for another to complete.

• Dependent on project managers intuition and experience.

Project Scheduling

The project scheduling process

Estimate resourcesfor activities

Identify activitydependencies

Identifyactivities

Allocate peopleto activities

Softwarerequirements

Activity chartsand bar charts

Create projectcharts

Scheduling problems

• Estimating the difficulty of problems and hence the cost of developing a solution is hard.

• Productivity is not proportional to the number of people working on a task.

• Adding people to a late project makes it later because of communication overheads.

• The unexpected always happens. Always allow contingency in planning.

Scheduling Problem

Bar chartBar charts and activity networkss and

activity networks• Graphical notations used to illustrate the project schedule.

• Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two.

• Activity charts show task dependencies and the the critical path.

• Bar charts show schedule against calendar time.

Bar Charts & Activity Network

Task durations and dependencies

Activity Duration (days) Dependencies

T1 8

T2 15

T3 15 T1 (M1)

T4 10

T5 10 T2, T4 (M2)

T6 5 T1, T2 (M3)

T7 20 T1 (M1)

T8 25 T4 (M5)

T9 15 T3, T6 (M4)

T10 15 T5, T7 (M7)

T11 7 T9 (M6)

T12 10 T11 (M8)

Bar Charts & Activity Network

Activity network

start

T2

M3T6

Finish

T10

M7T5

T7

M2T4

M5

T8

4/7/03

8 days

14/7/03 15 days

4/8/03

15 days

25/8/03

7 days

5/9/03

10 days

19/9/03

15 days

11/8/03

25 days

10 days

20 days

5 days25/7/03

15 days

25/7/03

18/7/03

10 days

T1

M1 T3T9

M6

T11

M8

T12

M4

Activity Network

Activity timeline

4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T1T2

M1

T7T3

M5

T8

M3

M2

T6

T5

M4

T9

M7

T10

M6

T11M8

T12

Start

Finish

Activity Timeline

Staff allocation

4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T8 T11

T12

T1

T3

T9

T2

T6 T10

T7

T5

Fred

Jane

Anne

Mary

Jim

Activity Timeline

Risk management

• Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project.

• A risk is a probability that some adverse circumstance will occur – Project risks affect schedule or resources;– Product risks affect the quality or performance of

the software being developed;– Business risks affect the organisation developing

or procuring the software.

Software risks

Risk Affects Description

Staff turnover Project Experienced staff will leave the project before it is finished.

Management change Project There will be a change of organisational management withdifferent priorities.

Hardware unavailability Project Hardware that is essential for the project will not bedelivered on schedule.

Requirements change Project andproduct

There will be a larger number of changes to therequirements than anticipated.

Specification delays Project andproduct

Specifications of essential interfaces are not available onschedule

Size underestimate Project andproduct

The size of the system has been underestimated.

CASE tool under-performance

Product CASE tools which support the project do not perform asanticipated

Technology change Business The underlying technology on which the system is built issuperseded by new technology.

Product competition Business A competitive product is marketed before the system iscompleted.


• Risk identification– Identify project, product and business risks;

• Risk analysis– Assess the likelihood and consequences of these risks;

• Risk planning– Draw up plans to avoid or minimise the effects of the risk;

• Risk monitoring– Monitor the risks throughout the project;


Risk avoidanceand contingency

plans

Risk planning

Prioritised risklist

Risk analysis

List of potentialrisks

Riskidentification

Riskassessment

Riskmonitoring

Risk identification

• Technology risks.

• People risks.

• Organisational risks.

• Requirements risks.

• Estimation risks.

Risks and risk types

Risk type Possible risks

Technology The database used in the system cannot process as many transactions per secondas expected.Software components that should be reused contain defects that limit theirfunctionality.

People It is impossible to recruit staff with the skills required.Key staff are ill and unavailable at critical times.Required training for staff is not available.

Organisational The organisation is restructured so that different management are responsible forthe project.Organisational financial problems force reductions in the project budget.

Tools The code generated by CASE tools is inefficient.CASE tools cannot be integrated.

Requirements Changes to requirements that require major design rework are proposed.Customers fail to understand the impact of requirements changes.

Estimation The time required to develop the software is underestimated.The rate of defect repair is underestimated.The size of the software is underestimated.

Risk analysis

• Assess probability and seriousness of each risk.

• Probability may be very low, low, moderate, high or very high.

• Risk effects might be catastrophic, serious, tolerable or insignificant.

Risk analysis (i)


Organisational financial problems force reductions inthe project budget.

Low Catastrophic

It is impossible to recruit staff with the skills requiredfor the project.

High Catastrophic

Key staff are ill at critical times in the project. Moderate Serious

Software components that should be reused containdefects which limit their functionality.

Moderate Serious

Changes to requirements that require major designrework are proposed.

Moderate Serious

The organisation is restructured so that differentmanagement are responsible for the project.

High Serious

Risk analysis (ii)


The database used in the system cannot process asmany transactions per second as expected.

Moderate Serious

The time required to develop the software isunderestimated.

High Serious

CASE tools cannot be integrated. High Tolerable

Customers fail to understand the impact ofrequirements changes.

Moderate Tolerable

Required training for staff is not available. Moderate Tolerable

The rate of defect repair is underestimated. Moderate Tolerable

The size of the software is underestimated. High Tolerable

The code generated by CASE tools is inefficient. Moderate Insignificant

Risk planning

• Consider each risk and develop a strategy to manage that risk.

• Avoidance strategies– The probability that the risk will arise is reduced;

• Minimisation strategies– The impact of the risk on the project or product will

be reduced;

• Contingency plans– If the risk arises, contingency plans are plans to deal

with that risk;

Risk management strategies (i)

Risk Strategy

Organisationalfinancial problems

Prepare a briefing document for senior managementshowing how the project is making a very importantcontribution to the goals of the business.

Recruitmentproblems

Alert customer of potential difficulties and thepossibility of delays, investigate buying-incomponents.

Staff illness Reorganise team so that there is more overlap of workand people therefore understand each other’s jobs.

Defectivecomponents

Replace potentially defective components with bought-in components of known reliability.

Risk management strategies (ii)

Risk Strategy

Requirementschanges

Derive traceability information to assess requirementschange impact, maximise information hiding in thedesign.

Organisationalrestructuring

Prepare a briefing document for senior managementshowing how the project is making a very importantcontribution to the goals of the business.

Databaseperformance

Investigate the possibility of buying a higher-performance database.

Underestimateddevelopment time

Investigate buying in components, investigate use of aprogram generator

Risk monitoring

• Assess each identified risks regularly to decide whether or not it is becoming less or more probable.

• Also assess whether the effects of the risk have changed.

• Each key risk should be discussed at management progress meetings.

Risk indicators

Risk type Potential indicators

Technology Late delivery of hardware or support software, many reportedtechnology problems

People Poor staff morale, poor relationships amongst team member,job availability

Organisational Organisational gossip, lack of action by senior management

Tools Reluctance by team members to use tools, complaints aboutCASE tools, demands for higher-powered workstations

Requirements Many requirements change requests, customer complaints

Estimation Failure to meet agreed schedule, failure to clear reporteddefects

MCA Software Engg Unit 1 Ppt 1

Documents

Transcript of MCA Software Engg Unit 1 Ppt 1