Download - MCA Software Engg Unit 1 Ppt 1
Software Engineering (MCA-403)
Prepared By:
Mr. Sujit Kumar Singh
A.P in M.C.A department
MCA 1/338
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
Evolutionary development
Concurrentactivities
ValidationFinal
version
DevelopmentIntermediate
versions
SpecificationInitial
version
Outlinedescription
Evolutionary Development
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
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.
What are the costs of software engineering?
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
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.
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.
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.
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
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
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
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
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
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
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
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
• 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.
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
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
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
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
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
S/W 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 management
S/W 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;
The risk management process
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)
Risk Probability Effects
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
• 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.
Software Requirement Objectives
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
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.]
Critical Path Method
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
Critical Path Method
START
Edit Unit 3
Script
TV 2
Make
TV 2
Edit Unit 4
Prototype Computer 1
Program Computer 1
Document
Computer 1
Delivery
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.
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 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
Requirementsspecification
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.
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;
The risk management process
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)
Risk Probability Effects
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