se lect12 btech
DESCRIPTION
TRANSCRIPT
Deliverables by Phase
2
Deliverables by Phase
SoftwareConcept
Requirements
Analysis
Design
Coding andDebugging
SystemsTesting
Deployment &Maintenance
Possible Deliverables by Phase Concept Document Statement of Work (SOW) Project Charter RFP & Proposal
Requirements Document (Software Requirements Specification) Work Breakdown Structure (WBS)
Functional Specification ( Top Level Design Specification) Entity Relationship Diagram Data Flow Diagram
Detailed Design Specification Object Diagrams Detailed Data Model
Coding Standards Working Code Unit Tests
Acceptance Test Procedures Tested Application
Maintenance Specification Deployed Application
Project Development Plan (Software Development Plan ) Baseline Project Plan Quality Assurance Plan Configuration Management Plan Risk Management Plan
Integration Plan Detailed SQA Test Plan SQA Test Cases
User Documentation Training Plan
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 risksRisk Risk type DescriptionStaff 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 which is essential for theproject will not be delivered onschedule.
Requirements change Project andproduct
There will be a larger number ofchanges to the requirements thananticipated.
Specification delays Project andproduct
Specifications of essential interfacesare not available on schedule
Size underestimate Project andproduct
The size of the system has beenunderestimated.
CASE tool under-performance
Product CASE tools which support theproject do not perform as anticipated
Technology change Business The underlying technology on whichthe system is built is superseded bynew technology.
Product competition Business A competitive product is marketedbefore the system is completed.
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 risksTechnology The database used in the system cannot process as many
transactions per second as expected.Software components which should be reused contain defectswhich limit their functionality.
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 managementare responsible for the project.Organisational financial problems force reductions in the projectbudget.
Tools The code generated by CASE tools is inefficient.CASE tools cannot be integrated.
Requirements Changes to requirements which require major design rework areproposed.Customers fail to understand the impact of requirementschanges.
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 – insignificant
Risk analysis
Risk Probability EffectsOrganisational financial problems force reductionsin the project budget.
Low Catastrophic
It is impossible to recruit staff with the skillsrequired for the project.
High Catastrophic
Key staff are ill at critical times in the project. Moderate SeriousSoftware components which should be reusedcontain defects which limit their functionality.
Moderate Serious
Changes to requirements which require majordesign rework are proposed.
Moderate Serious
The organisation is restructured so that differentmanagement are responsible for the project.
High Serious
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 TolerableCustomers fail to understand the impact ofrequirements changes.
Moderate Tolerable
Required training for staff is not available. Moderate TolerableThe rate of defect repair is underestimated. Moderate TolerableThe size of the software is underestimated. High TolerableThe 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 reducedContingency plans
If the risk arises, contingency plans are plans to deal with that risk
Risk management strategies
Risk StrategyOrganisationalfinancial problems
Prepare a briefing document for senior management showinghow the project is making a very important contribution to thegoals of the business.
Recruitmentproblems
Alert customer of potential difficulties and the possibility ofdelays, investigate buying-in components.
Staff illness Reorganise team so that there is more overlap of work andpeople therefore understand each other’s jobs.
Defectivecomponents
Replace potentially defective components with bought-incomponents of known reliability.
Requirementschanges
Derive traceability information to assess requirements changeimpact, maximise information hiding in the design.
Organisationalrestructuring
Prepare a briefing document for senior management showinghow the project is making a very important contribution to thegoals of the business.
Databaseperformance
Investigate the possibility of buying a higher-performancedatabase.
Underestimateddevelopment time
Investigate buying in components, investigate use of a programgenerator.
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 factors
Risk type Potential indicatorsTechnology Late delivery of hardware or support software, many
reported technology problemsPeople Poor staff morale, poor relationships amongst team
member, job availabilityOrganisational organisational gossip, lack of action by senior
managementTools reluctance by team members to use tools, complaints
about CASE tools, demands for higher-poweredworkstations
Requirements many requirements change requests, customercomplaints
Estimation failure to meet agreed schedule, failure to clearreported defects
Software Measurement & Matrices
16
Software Measurement Objectives
– Assessing status• Projects• Products for a specific project or projects• Processes• Resources
– Identifying trends• Need to be able to differentiate between a healthy project and one
that’s in trouble
– Determine corrective action• Measurements should indicate the appropriate corrective action, if
any is required.
17
Software Measurement Objectives
• Types of information required to understand, control, and improve projects:– Managers
• What does the process cost?• How productive is the staff?• How good is the code?• Will the customer/user be satisfied?• How can we improve?
– Engineers• Are the requirements testable?• Have all the faults been found?• Have the product or process goals been met?• What will happen in the future?
18
The Scope of Software Metrics
– Cost and effort estimation– Productivity measures and models– Data collection– Quality models and measures– Reliability models– Performance evaluation and models– Structural and complexity metrics– Capability-maturity assessment– Management by metrics– Evaluation of methods and tools
19
The Scope of Software Metrics
• The Scope of Software Metrics – some details– Possible productivity model
Productivity
ValueCost
QuantityQuality
Reliability Defects FunctionalitySize
Personnel Resources Complexity
Time
Money
HW
SW
Env Cnstrst
Problem difficulty
20
The Scope of Software Metrics• The Scope of Software Metrics – some
details– Software quality model
Use Factor Criteria
Product Operation
Product Revision
Usability
Reliability
Efficiency
Reusability
Maintainability
Portability
Testability
Communicativeness
Accuracy
Consistency
Device Efficiency
Completeness
Structuredness
Conciseness
Device Independence
Legibility
Self-descriptiveness
Traceability
Accessibility
Metrics
Direct and Indirect Matrices
22
Measurement Basics
• Direct and Indirect Measurement– Direct measure – relates an attribute to a number or
symbol without reference to no other object or attribute (e.g., height).
– Indirect measure• Used when an attribute must be measured by combining
several of its aspects (e.g., density)
• Requires a model of how measures are related to each other
23
Measurement Basics
• Direct and Indirect Measures for Software – examples– Direct
• Length or source code (lines of code)• Duration of testing process• Number of defects discovered during test• Time a developer spends on a project
– Indirect• Programmer productivity (LOC/workmonths of effort)• Module defect density (number of defects/module size)• Defect detection efficiency (# defects detected/total defects)• Requirements stability (initial # requirements/total # requirements)• Test effectiveness ratio (number of items covered/total number of items)• System spoilage (effort spent fixing faults/total project effort)
Quality Models and Measures
Software product quality metrics
• The quality of a product:
- the “totality of characteristics that bear on its ability to satisfy stated or implied needs”.
Metrics of the external quality attributes producer’s perspective: “conformance to
requirements” customer’s perspective: “fitness for use”
- customer’s expectations
Quality metrics
• Two levels of software product quality metrics:
Intrinsic product quality
Customer oriented metrics
Intrinsic product quality metrics:
Reliability: number of hours the software can run
before a failure
Defect density (rate):
number of defects contained in software, relative
to its size.
Customer oriented metrics:
Customer problems
Customer satisfaction
Intrinsic product quality metrics
Reliability --- Defect density
• Correlated but different!
• Both are predicted values.
• Estimated using static and dynamic models
Defect: an anomaly in the product (“bug”)
Software failure: an execution whose effect is not conform to software specification
Reliability
Reliability metrics:
MTBF (Mean Time Between Failures)
MTTF (Man Time To Failure)
MTBF (Mean Time Between Failures):
the expected time between two successive failures of a system
expressed in hours
a key reliability metric for systems that can be repaired or restored
(repairable systems)
applicable when several system failures are expected.
For a hardware product, MTBF decreases with the its age.
MTTF (Man Time To Failure):
the expected time to failure of a system
in reliability engineering metric for non-repairable systems
non-repairable systems can fail only once; example, a satellite is not repairable.
Mean Time To Repair (MTTR): average time to restore a system after a failure
When there are no delays in repair: MTBF = MTTF + MTTR
Software products are repairable systems!
Reliability models neglect the time needed to restore the system after a failure.
with MTTR =0 MTBF = MTTF
Availability = MTTF / MTBF = MTTF / (MTTF + MTTR)
3.1.2. Defect rate (density)
Number of defects per KLOC or per Number of Function Point,
in a given time unit
Example:
“The latent defect rate for this product, during next four years, is 2.0
defects per KLOC”.
Crude metric: a defect may involve one or more lines of code
Lines Of Code
-Different counting tools
-Defect rate metric has to be completed with the counting method for LOC!
-Not recommended to compare defect rates of two products written in
different languages
Reliability or Defect Rate ?
Reliability:
often used with safety-critical systems such as: airline traffic control systems,
avionics, weapons.
(usage profile and scenarios are better defined)
Defect density:
in many commercial systems (systems for commercial use)
• there is no typical user profile
• development organizations use defect rate for maintenance cost and
resource estimates
• MTTF is more difficult to implement and may not be representative of all
customers.
Customer Oriented Metrics
Customer Problems MetricCustomer Problems Metric
Customer problems when using the product:
valid defects, usability problems, unclear documentation, user errors.
Problems per user month (PUM) metric:
PUM = TNP/ TNM
TNP: Total number of problems reported by customers for a time period
TNM: Total number of license-months of the software during the period
= number of install licenses of the software x number of months in the period
3.2.2. Customer satisfaction metrics
Often measured on the five-point scale:1. Very satisfied2. Satisfied3. Neutral4. Dissatisfied5. Very dissatisfied IBM: CUPRIMDSO (capability/functionality, usability, performance, reliability,
installability, maintainability, documentation /information, service and overall)
Hewlett-Packard: FURPS (functionality, usability, reliability, performance and service)
Ishikawa’s Seven Basic Tools for Quality Control
• Checklist (or Check Sheet) – to facilitate gathering data and to arrange data so it can be easily used later
• Pareto Diagram – a frequency chart of bars in descending order; the bars are usually associated with types of problems
• Histogram – a graphic representation of frequency counts of a sample or a population
• Scatter Diagram – portrays the relationship of two interval variables; can make outliers clear
• Run Chart – tracks the performance of the parameter of interest over time; used for trend analysis
• Control Chart – an advance form of a run chart for situations in which the process capability can be defined
• Cause and Effect Diagram (fishbone diagram) – it shows the relationship between a characteristic and the factors that affect that relationship
Ishikawa’s Seven Basic Tools for Quality Control
Checklists
• Summarize the key points of the software development process
• More effective than lengthy process documents• Help ensure that all tasks are complete and the
important factors or quality characteristics of each task are covered
• Examples of checklists are:– Design review checklist– Code inspection checklist– Moderator (for review and inspection) checklist– Pre-code-integration checklist– Entrance and exit criteria for system tests– Product readiness checklist
Pareto Diagram
• Identifies areas that cause most of the problems
Pareto Analysis of Software Defects
Pareto Diagram of Defect by Component Problem Index
Histograms
Profile of Customer Satisfaction with a Software Product
Scatter Diagram of Program Complexity and Defect Level
Correlation of Defect Rates of Reused Components Between Two Platforms
Grouping of Reused Components Based on Defect Rate Relationship
Pseudo-Control Chart of Test Defect Rate—First Iteration
Pseudo-Control Chart of Test Defect Rate—Second Iteration
Pseudo-Control Chart of Inspection Effectiveness
Cause-and-Effect Diagram
Cause-and-Effect Diagram of Design Inspection
A Schematic Representation of a Relations Diagram