0
SE
Empirical Estimation Models
Introduction
• Estimation models for computer software use empirically derived
formulas to predict effort as a function of...
COCOMO
• Stands for COnstructive COst MOdel
• Introduced by Barry Boehm in 1981 in his book “Software Engineering
Economic...
COCOMO Models
• Application composition model - Used during the early stages of
software engineering when the following ar...
COCOMO Cost Drivers
• Personnel Factors
–
–
–
–
–
–
–
–

Applications experience
Programming language experience
Virtual m...
COCOMO Cost Drivers (continued)
•

•

Platform Factors
–
–
–
–
–
–

Execution time constraint
Main storage constraint
Comp...
Introduction
• Before an estimate can be made and decomposition techniques applied,
the planner must
– Understand the scop...
Approaches to Software Sizing
• Function point sizing
– Develop estimates of the information domain characteristics (Ch. 1...
Problem-Based Estimation
1)
2)
3)
4)

5)

Start with a bounded statement of scope
Decompose the software into problem func...
Problem-Based Estimation (continued)
• In general, the LOC/pm and FP/pm metrics should be computed by project
domain
– Imp...
Problem-Based Estimation (continued)
• For both approaches, the planner uses lessons learned to estimate an
optimistic, mo...
Process-Based Estimation
1)
2)
3)

Identify the set of functions that the software needs to perform as
obtained from the p...
Process-Based Estimation
(continued)
4)

Apply average labor rates (i.e., cost/unit effort) to the effort
estimated for ea...
Two Unit Testing Techniques
• Black-box testing
– Knowing the specified function that a product has been designed to perfo...
White-box Testing
White-box Testing
• Uses the control structure part of component-level design to derive the
test cases
• These test cases
...
Basis Path Testing
• White-box testing technique proposed by Tom McCabe
• Enables the test case designer to derive a logic...
Flow Graph Notation
• A circle in a graph represents a node, which stands for a sequence of one
or more procedural stateme...
Flow Graph Example
FLOW CHART

FLOW GRAPH

0

0

1

R4

1

2

2
3

R3

3
4

6

6

4

R2
7

8

5

7

R1

8

5

9
9
11

10

...
Independent Program Paths
• Defined as a path through the program from the start node until the
end node that introduces a...
Cyclomatic Complexity
• Provides a quantitative measure of the logical complexity of a program
• Defines the number of ind...
Deriving the Basis Set and Test Cases
1)

2)
3)
4)

Using the design or code as a foundation, draw a corresponding flow
gr...
A Second Flow Graph Example
1
2
3
4

5
6
7
8
9
10

A: x++;
if (x > 999)
goto D;
if (x % 11 == 0)
goto B;
else goto A;

11
...
A Sample Function to Diagram and Analyze
1
2
3

int functionZ(int y)
{
int x = 0;

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
...
A Sample Function to Diagram and Analyze
1
2
3

3

int functionZ(int y)
{
int x = 0;

4
5
6
7
8
9
10
11
12
13
14
15
16
17
...
Loop Testing - General
• A white-box testing technique that focuses exclusively on the validity of
loop constructs
• Four ...
Testing of Simple Loops
1)
2)
3)
4)
5)

Skip the loop entirely
Only one pass through the loop
Two passes through the loop
...
Testing of Nested Loops
1)
2)

3)

4)

Start at the innermost loop; set all other loops to minimum values
Conduct simple l...
Testing of Concatenated Loops
• For independent loops, use the same approach as for simple loops
• Otherwise, use the appr...
Testing of Unstructured Loops
• Redesign the code to reflect the use of structured programming practices
• Depending on th...
Black-box Testing
Black-box Testing
• Complements white-box testing by uncovering different classes of
errors
• Focuses on the functional re...
Black-box Testing Categories
•
•
•
•
•

Incorrect or missing functions
Interface errors
Errors in data structures or exter...
Questions answered by
Black-box Testing
•
•
•
•
•
•
•

How is functional validity tested?
How are system behavior and perf...
Example Timeline Chart

36
The RMMM Plan
• The RMMM plan may be a part of the software development plan
(Paragraph 5.19.1) or may be a separate docum...
Seven Principles of Risk Management
•

Maintain a global perspective
– View software risks within the context of a system ...
What is Quality Management
•
•

•
•
•

Also called software quality assurance (SQA)
Serves as an umbrella activity that is...
Quality Defined
• Defined as a characteristic or attribute of something
• Refers to measurable characteristics that we can...
Quality Defined (continued)
•

Two kinds of quality are sought out
– Quality of design
• The characteristic that designers...
Quality Control
• Involves a series of inspections, reviews, and tests used throughout the
software process
• Ensures that...
Quality Assurance Functions
• Consists of a set of auditing and reporting functions that assess the
effectiveness and comp...
The Cost of Quality
• Includes all costs incurred in the pursuit of quality or in performing
quality-related activities
• ...
Kinds of Quality Costs
• Prevention costs
– Quality planning, formal technical reviews, test equipment, training

• Apprai...
SQA Activities
• Prepares an SQA plan for a project
• Participates in the development of the project's software process de...
Introduction
Definition of Risk
• A risk is a potential problem – it might happen and it might not
• Conceptual definition of risk
– Ri...
Risk Categorization – Approach #1
• Project risks
– They threaten the project plan
– If they become real, it is likely tha...
Risk Categorization – Approach #1
(continued)
• Sub-categories of Business risks
– Market risk – building an excellent pro...
Risk Categorization – Approach #2
• Known risks
– Those risks that can be uncovered after careful evaluation of the projec...
Reactive vs. Proactive Risk Strategies
• Reactive risk strategies
– "Don't worry, I'll think of something"
– The majority ...
Steps for Risk Management
1)
2)
3)
4)

Identify possible risks; recognize what can go wrong
Analyze each risk to estimate ...
Risk Identification
Background
• Risk identification is a systematic attempt to specify threats to the
project plan
• By identifying known and...
CHAPTER 6
OBJECT ORIENTED ANALYSIS

SIM3301

Object-Oriented Analysis

56
Learning Objectives
• Understand object oriented concepts
• Be able to understand and/or draw object
oriented analysis mod...
Object-Oriented Concepts
• Must be understood to apply classbased elements of the analysis model
• Key concepts:
– Classes...
Classes
• object-oriented thinking begins with
the definition of a class, often
defined as:
– template
– generalized descr...
Building a Class
Class name

Attributes

Operations

SIM3301

Object-Oriented Analysis

60
Encapsulation/Hiding
Class encapsulates
both data and the logical
procedures required to
manipulate the data
method

Reduc...
Class Hierarchy
PieceOfFurniture (superclass)

Table

Chair

Desk

”Chable"
Subclass
inherit both
attributes and
operation...
Methods
(a.k.a. Operations, Services)
An executable procedure that is
encapsulated in a class and is designed
to operate o...
Attributes
A collection of data values that
describe a class

SIM3301

Object-Oriented Analysis

64
Objects
• Instances of a specific class
• Inherit a class attributes and operations

Class : STUDENT
Object instance (obje...
Example
STUDENT
Name
DOB
Address
Phone

Calculate_age
Calculate_gpa
Register_course

SIM3301

Object-Oriented Analysis

66
Object Oriented Analysis (OOA)
Based on objects rather than data or processes

The intent of OOA is to define all classes ...
THE OOA PROCESS
Use Case Modeling – shows
functions

Class-based Modeling – Class
diagram, CRC

Behavioral Model – State
D...
 USE CASE MODELING
Illustrates the manner in which an actor interacts with the system

Actor = “ Anything that communicat...
Use-Cases
•
•
•

A collection of user scenarios that describe the thread of usage of a system
Each scenario is described f...
Use-Case Diagram
SafeHome

Access camera
surveillance via the
Internet

cameras

ConfigureSafeHome
system parameters
homeo...
Eg: consider the interactions between a Bank Customer and an ATM
Bank ATM Machine

Withdraw Cash

Bank Customer

Check Bal...
Writing Use-Cases (Scenario)
• Use case:Access camera surveillance-display camera views
(ACS-DCV)
• Actor:homeowner
If I’m...
Use-Case Modeling
• Relationships Between Use Cases
– Use cases may participate in relationships with
other use-cases
– Tw...
Example:
Use-case diagram for a university registration system
(Correction: arrow direction should be in opposite directio...
SIM3301

Object-Oriented Analysis

76
Selecting Classes—Criteria
• Retained Information
• Needed services – have a set of identifiable
operations
• Multiple att...
CRC Modeling
• Analysis classes have “responsibilities”
– Responsibilities are the attributes and operations
encapsulated ...
Class Types
• Entity classes, also called model or business classes, are extracted
directly from the statement of the prob...
Collaborations
• Classes fulfill their responsibilities in one of two ways:
– A class can use its own operations to manipu...
Behavioral Modeling
• The behavioral model indicates how software will
respond to external events or stimuli. To create th...
Behavioral Modeling
• make a list of the different states of a
system (How does the system behave?)
• indicate how the sys...
Sequence diagram
A representation of how events cause flow from one object
to another as a function of time.

 Events ar...
Sequence Diagram
anOrder

Object
Object and Class

anOrder:
Order

Message/event
prepare()

needsToReorder()

SIM3301

Sel...
object
Object A:
Class A

Object B:
Class B

: Actor

messageA( )

message
messageB(string)

messageC( )

activation
(opti...
Identifying events with the Use-Case
• Use case for a small portion of the SafeHome
security function
The homeowner uses t...
Sequence Diagram
co n t ro l p an el

h o meo w n er

syst em
read y

A

sen so rs
sen so rs

syst em

read in g

p assw o...
Class diagram

Sequence diagram
Bob:
ClockStaff
Ali : User

printRecord( )
STAFF
printRecord
calculateSalary

CLOCKSTAFF

...
Order

OrderLine

DeliveryItem

orderNumber
date
etc…

itemnumber
quantity
etc…

itemnumber
quantity
etc…

prepare()

prep...
anOrder Entry
window

anOrder

anOrder Line

aStock Item

AReorder
Item

aDelivery
Item

choose()

prepare()

* prepare()
...
Computer

PrintServer

Printer

status(): integer

uses

print(file)

print(filename)

print(file)

Managed by

Queue

sto...
aComputer:
Computer

aPrintServer:
PrintServer

aPrinter:
Printer

aQueue:
Queue

aUser: User
print
(filename)
print(file)...
Collaboration Diagram
 Shows the relationships among objects
 Consists of:
 Objects
 Lines connecting the objects
 Me...
1. keyInCourseInfo

Course
Form

Interaction diagrams

Student
2. addCourse

Academic
Staff

: Student
3. newCourse

Acade...
Upcoming SlideShare
Loading in...5
×

Se final-slides

125

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
125
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Se final-slides"

  1. 1. SE
  2. 2. Empirical Estimation Models
  3. 3. Introduction • Estimation models for computer software use empirically derived formulas to predict effort as a function of LOC or FP • Resultant values computed for LOC or FP are entered into an estimation model • The empirical data for these models are derived from a limited sample of projects – Consequently, the models should be calibrated to reflect local software development conditions 3
  4. 4. COCOMO • Stands for COnstructive COst MOdel • Introduced by Barry Boehm in 1981 in his book “Software Engineering Economics” • Became one of the well-known and widely-used estimation models in the industry • It has evolved into a more comprehensive estimation model called COCOMO II • COCOMO II is actually a hierarchy of three estimation models • As with all estimation models, it requires sizing information and accepts it in three forms: object points, function points, and lines of source code (More on next slide) 4
  5. 5. COCOMO Models • Application composition model - Used during the early stages of software engineering when the following are important – – – – Prototyping of user interfaces Consideration of software and system interaction Assessment of performance Evaluation of technology maturity • Early design stage model – Used once requirements have been stabilized and basic software architecture has been established • Post-architecture stage model – Used during the construction of the software 5
  6. 6. COCOMO Cost Drivers • Personnel Factors – – – – – – – – Applications experience Programming language experience Virtual machine experience Personnel capability Personnel experience Personnel continuity Platform experience Language and tool experience – – – – – – Required software reliability Database size Software product complexity Required reusability Documentation match to life cycle needs Product reliability and complexity • Product Factors (More on next slide) 6
  7. 7. COCOMO Cost Drivers (continued) • • Platform Factors – – – – – – Execution time constraint Main storage constraint Computer turn-around time Virtual machine volatility Platform volatility Platform difficulty Project Factors – – – – – – Use of software tools Use of modern programming practices Required development schedule Classified security application Multi-site development Requirements volatility 7
  8. 8. Introduction • Before an estimate can be made and decomposition techniques applied, the planner must – Understand the scope of the software to be built – Generate an estimate of the software’s size • Then one of two approaches are used – Problem-based estimation • Based on either source lines of code or function point estimates – Process-based estimation • Based on the effort required to accomplish each task 8
  9. 9. Approaches to Software Sizing • Function point sizing – Develop estimates of the information domain characteristics (Ch. 15 – Product Metrics for Software) • Standard component sizing – Estimate the number of occurrences of each standard component – Use historical project data to determine the delivered LOC size per standard component • Change sizing – Used when changes are being made to existing software – Estimate the number and type of modifications that must be accomplished – Types of modifications include reuse, adding code, changing code, and deleting code – An effort ratio is then used to estimate each type of change and the size of the change The results of these estimates are used to compute an optimistic (low), a most likely, and a pessimistic (high) value for software size 9
  10. 10. Problem-Based Estimation 1) 2) 3) 4) 5) Start with a bounded statement of scope Decompose the software into problem functions that can each be estimated individually Compute an LOC or FP value for each function Derive cost or effort estimates by applying the LOC or FP values to your baseline productivity metrics (e.g., LOC/person-month or FP/person-month) Combine function estimates to produce an overall estimate for the entire project (More on next slide) 10
  11. 11. Problem-Based Estimation (continued) • In general, the LOC/pm and FP/pm metrics should be computed by project domain – Important factors are team size, application area, and complexity • LOC and FP estimation differ in the level of detail required for decomposition with each value – For LOC, decomposition of functions is essential and should go into considerable detail (the more detail, the more accurate the estimate) – For FP, decomposition occurs for the five information domain characteristics and the 14 adjustment factors • External inputs, external outputs, external inquiries, internal logical files, external interface files pm = person month 11
  12. 12. Problem-Based Estimation (continued) • For both approaches, the planner uses lessons learned to estimate an optimistic, most likely, and pessimistic size value for each function or count (for each information domain value) • Then the expected size value S is computed as follows: S = (Sopt + 4Sm + Spess)/6 • Historical LOC or FP data is then compared to S in order to cross-check it 12
  13. 13. Process-Based Estimation 1) 2) 3) Identify the set of functions that the software needs to perform as obtained from the project scope Identify the series of framework activities that need to be performed for each function Estimate the effort (in person months) that will be required to accomplish each software process activity for each function (More on next slide) 13
  14. 14. Process-Based Estimation (continued) 4) Apply average labor rates (i.e., cost/unit effort) to the effort estimated for each process activity Compute the total cost and effort for each function and each framework activity (See table in Pressman, p. 655) Compare the resulting values to those obtained by way of the LOC and FP estimates 5) 6) • • If both sets of estimates agree, then your numbers are highly reliable Otherwise, conduct further investigation and analysis concerning the function and activity breakdown This is the most commonly used of the two estimation techniques (problem and process) 14
  15. 15. Two Unit Testing Techniques • Black-box testing – Knowing the specified function that a product has been designed to perform, test to see if that function is fully operational and error free – Includes tests that are conducted at the software interface – Not concerned with internal logical structure of the software • White-box testing – Knowing the internal workings of a product, test that all internal operations are performed according to specifications and all internal components have been exercised – Involves tests that concentrate on close examination of procedural detail – Logical paths through the software are tested – Test cases exercise specific sets of conditions and loops 15
  16. 16. White-box Testing
  17. 17. White-box Testing • Uses the control structure part of component-level design to derive the test cases • These test cases – Guarantee that all independent paths within a module have been exercised at least once – Exercise all logical decisions on their true and false sides – Execute all loops at their boundaries and within their operational bounds – Exercise internal data structures to ensure their validity “Bugs lurk in corners and congregate at boundaries” 17
  18. 18. Basis Path Testing • White-box testing technique proposed by Tom McCabe • Enables the test case designer to derive a logical complexity measure of a procedural design • Uses this measure as a guide for defining a basis set of execution paths • Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing 18
  19. 19. Flow Graph Notation • A circle in a graph represents a node, which stands for a sequence of one or more procedural statements • A node containing a simple conditional expression is referred to as a predicate node – Each compound condition in a conditional expression containing one or more Boolean operators (e.g., and, or) is represented by a separate predicate node – A predicate node has two edges leading out from it (True and False) • An edge, or a link, is a an arrow representing flow of control in a specific direction – An edge must start and terminate at a node – An edge does not intersect or cross over another edge • Areas bounded by a set of edges and nodes are called regions • When counting regions, include the area outside the graph as a region, too 19
  20. 20. Flow Graph Example FLOW CHART FLOW GRAPH 0 0 1 R4 1 2 2 3 R3 3 4 6 6 4 R2 7 8 5 7 R1 8 5 9 9 11 10 11 10 20
  21. 21. Independent Program Paths • Defined as a path through the program from the start node until the end node that introduces at least one new set of processing statements or a new condition (i.e., new nodes) • Must move along at least one edge that has not been traversed before by a previous path • Basis set for flow graph on previous slide – – – – Path 1: 0-1-11 Path 2: 0-1-2-3-4-5-10-1-11 Path 3: 0-1-2-3-6-8-9-10-1-11 Path 4: 0-1-2-3-6-7-9-10-1-11 • The number of paths in the basis set is determined by the cyclomatic complexity 21
  22. 22. Cyclomatic Complexity • Provides a quantitative measure of the logical complexity of a program • Defines the number of independent paths in the basis set • Provides an upper bound for the number of tests that must be conducted to ensure all statements have been executed at least once • Can be computed three ways – The number of regions – V(G) = E – N + 2, where E is the number of edges and N is the number of nodes in graph G – V(G) = P + 1, where P is the number of predicate nodes in the flow graph G • Results in the following equations for the example flow graph – Number of regions = 4 – V(G) = 14 edges – 12 nodes + 2 = 4 – V(G) = 3 predicate nodes + 1 = 4 22
  23. 23. Deriving the Basis Set and Test Cases 1) 2) 3) 4) Using the design or code as a foundation, draw a corresponding flow graph Determine the cyclomatic complexity of the resultant flow graph Determine a basis set of linearly independent paths Prepare test cases that will force execution of each path in the basis set 23
  24. 24. A Second Flow Graph Example 1 2 3 4 5 6 7 8 9 10 A: x++; if (x > 999) goto D; if (x % 11 == 0) goto B; else goto A; 11 12 13 B: if (x % y == 0) goto C; else goto A; 14 15 C: printf("%dn", x); goto A; 16 17 18 D: printf("End of listn"); return 0; } 3 int functionY(void) { int x = 0; int y = 19; 4 5 6 8 13 9 16 11 10 7 17 12 14 15 24
  25. 25. A Sample Function to Diagram and Analyze 1 2 3 int functionZ(int y) { int x = 0; 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 while (x <= (y * y)) { if ((x % 11 == 0) && (x % y == 0)) { printf(“%d”, x); x++; } // End if else if ((x % 7 == 0) || (x % y == 1)) { printf(“%d”, y); x = x + 2; } // End else printf(“n”); } // End while 20 21 22 printf("End of listn"); return 0; } // End functionZ 25
  26. 26. A Sample Function to Diagram and Analyze 1 2 3 3 int functionZ(int y) { int x = 0; 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 while (x <= (y * y)) { if ((x % 11 == 0) && (x % y == 0)) { printf(“%d”, x); x++; } // End if else if ((x % 7 == 0) || (x % y == 1)) { printf(“%d”, y); x = x + 2; } // End else printf(“n”); } // End while 20 21 22 printf("End of listn"); return 0; } // End functionZ 4 6 12 13 7 9 10 15 16 18 20 21 26
  27. 27. Loop Testing - General • A white-box testing technique that focuses exclusively on the validity of loop constructs • Four different classes of loops exist – – – – Simple loops Nested loops Concatenated loops Unstructured loops • Testing occurs by varying the loop boundary values – Examples: for (i = 0; i < MAX_INDEX; i++) while (currentTemp >= MINIMUM_TEMPERATURE) 27
  28. 28. Testing of Simple Loops 1) 2) 3) 4) 5) Skip the loop entirely Only one pass through the loop Two passes through the loop m passes through the loop, where m < n n –1, n, n + 1 passes through the loop „n‟ is the maximum number of allowable passes through the loop 28
  29. 29. Testing of Nested Loops 1) 2) 3) 4) Start at the innermost loop; set all other loops to minimum values Conduct simple loop tests for the innermost loop while holding the outer loops at their minimum iteration parameter values; add other tests for out-of-range or excluded values Work outward, conducting tests for the next loop, but keeping all other outer loops at minimum values and other nested loops to “typical” values Continue until all loops have been tested 29
  30. 30. Testing of Concatenated Loops • For independent loops, use the same approach as for simple loops • Otherwise, use the approach applied for nested loops 30
  31. 31. Testing of Unstructured Loops • Redesign the code to reflect the use of structured programming practices • Depending on the resultant design, apply testing for simple loops, nested loops, or concatenated loops 31
  32. 32. Black-box Testing
  33. 33. Black-box Testing • Complements white-box testing by uncovering different classes of errors • Focuses on the functional requirements and the information domain of the software • Used during the later stages of testing after white box testing has been performed • The tester identifies a set of input conditions that will fully exercise all functional requirements for a program • The test cases satisfy the following: – Reduce, by a count greater than one, the number of additional test cases that must be designed to achieve reasonable testing – Tell us something about the presence or absence of classes of errors, rather than an error associated only with the specific task at hand 33
  34. 34. Black-box Testing Categories • • • • • Incorrect or missing functions Interface errors Errors in data structures or external data base access Behavior or performance errors Initialization and termination errors 34
  35. 35. Questions answered by Black-box Testing • • • • • • • How is functional validity tested? How are system behavior and performance tested? What classes of input will make good test cases? Is the system particularly sensitive to certain input values? How are the boundary values of a data class isolated? What data rates and data volume can the system tolerate? What effect will specific combinations of data have on system operation? 35
  36. 36. Example Timeline Chart 36
  37. 37. The RMMM Plan • The RMMM plan may be a part of the software development plan (Paragraph 5.19.1) or may be a separate document • Once RMMM has been documented and the project has begun, the risk mitigation, and monitoring steps begin – Risk mitigation is a problem avoidance activity – Risk monitoring is a project tracking activity • Risk monitoring has three objectives – To assess whether predicted risks do, in fact, occur – To ensure that risk aversion steps defined for the risk are being properly applied – To collect information that can be used for future risk analysis • The findings from risk monitoring may allow the project manager to ascertain what risks caused which problems throughout the project 37
  38. 38. Seven Principles of Risk Management • Maintain a global perspective – View software risks within the context of a system and the business problem that is is intended to solve • Take a forward-looking view – Think about risks that may arise in the future; establish contingency plans • Encourage open communication – Encourage all stakeholders and users to point out risks at any time • Integrate risk management – Integrate the consideration of risk into the software process • Emphasize a continuous process of risk management – Modify identified risks as more becomes known and add new risks as better insight is achieved • Develop a shared product vision – A shared vision by all stakeholders facilitates better risk identification and assessment • Encourage teamwork when managing risk – Pool the skills and experience of all stakeholders when conducting risk management activities 38
  39. 39. What is Quality Management • • • • • Also called software quality assurance (SQA) Serves as an umbrella activity that is applied throughout the software process Involves doing the software development correctly versus doing it over again Reduces the amount of rework, which results in lower costs and improved time to market Encompasses – A software quality assurance process – Specific quality assurance and quality control tasks (including formal technical reviews and a multi-tiered testing strategy) – Effective software engineering practices (methods and tools) – Control of all software work products and the changes made to them – A procedure to ensure compliance with software development standards – Measurement and reporting mechanisms 39
  40. 40. Quality Defined • Defined as a characteristic or attribute of something • Refers to measurable characteristics that we can compare to known standards • In software it involves such measures as cyclomatic complexity, cohesion, coupling, function points, and source lines of code • Includes variation control – A software development organization should strive to minimize the variation between the predicted and the actual values for cost, schedule, and resources – They should make sure their testing program covers a known percentage of the software from one release to another – One goal is to ensure that the variance in the number of bugs is also minimized from one release to another 40
  41. 41. Quality Defined (continued) • Two kinds of quality are sought out – Quality of design • The characteristic that designers specify for an item • This encompasses requirements, specifications, and the design of the system – Quality of conformance (i.e., implementation) • The degree to which the design specifications are followed during manufacturing • This focuses on how well the implementation follows the design and how well the resulting system meets its requirements • Quality also can be looked at in terms of user satisfaction User satisfaction = compliant product + good quality + delivery within budget and schedule 41
  42. 42. Quality Control • Involves a series of inspections, reviews, and tests used throughout the software process • Ensures that each work product meets the requirements placed on it • Includes a feedback loop to the process that created the work product – This is essential in minimizing the errors produced • Combines measurement and feedback in order to adjust the process when product specifications are not met • Requires all work products to have defined, measurable specifications to which practitioners may compare to the output of each process 42
  43. 43. Quality Assurance Functions • Consists of a set of auditing and reporting functions that assess the effectiveness and completeness of quality control activities • Provides management personnel with data that provides insight into the quality of the products • Alerts management personnel to quality problems so that they can apply the necessary resources to resolve quality issues 43
  44. 44. The Cost of Quality • Includes all costs incurred in the pursuit of quality or in performing quality-related activities • Is studied to – Provide a baseline for the current cost of quality – Identify opportunities for reducing the cost of quality – Provide a normalized basis of comparison (which is usually dollars) • Involves various kinds of quality costs (See next slide) • Increases dramatically as the activities progress from – Prevention  Detection  Internal failure  External failure "It takes less time to do a thing right than to explain why you did it wrong." Longfellow 44
  45. 45. Kinds of Quality Costs • Prevention costs – Quality planning, formal technical reviews, test equipment, training • Appraisal costs – Inspections, equipment calibration and maintenance, testing • Failure costs – subdivided into internal failure costs and external failure costs – Internal failure costs • Incurred when an error is detected in a product prior to shipment • Include rework, repair, and failure mode analysis – External failure costs • Involves defects found after the product has been shipped • Include complaint resolution, product return and replacement, help line support, and warranty work 45
  46. 46. SQA Activities • Prepares an SQA plan for a project • Participates in the development of the project's software process description • Reviews software engineering activities to verify compliance with the defined software process • Audits designated software work products to verify compliance with those defined as part of the software process • Ensures that deviations in software work and work products are documented and handled according to a documented procedure • Records any noncompliance and reports to senior management • Coordinates the control and management of change • Helps to collect and analyze software metrics 46
  47. 47. Introduction
  48. 48. Definition of Risk • A risk is a potential problem – it might happen and it might not • Conceptual definition of risk – Risk concerns future happenings – Risk involves change in mind, opinion, actions, places, etc. – Risk involves choice and the uncertainty that choice entails • Two characteristics of risk – Uncertainty – the risk may or may not happen, that is, there are no 100% risks (those, instead, are called constraints) – Loss – the risk becomes a reality and unwanted consequences or losses occur 48
  49. 49. Risk Categorization – Approach #1 • Project risks – They threaten the project plan – If they become real, it is likely that the project schedule will slip and that costs will increase • Technical risks – They threaten the quality and timeliness of the software to be produced – If they become real, implementation may become difficult or impossible • Business risks – They threaten the possibility of the software to be built – If they become real, they put in danger the project or the product (More on next slide) 49
  50. 50. Risk Categorization – Approach #1 (continued) • Sub-categories of Business risks – Market risk – building an excellent product or system that no one really wants – Strategic risk – building a product that no longer fits into the overall business strategy for the company – Sales risk – building a product that the sales force doesn't understand how to sell – Management risk – losing the support of senior management due to a change in focus or a change in people – Budget risk – losing budgetary or personnel commitment 50
  51. 51. Risk Categorization – Approach #2 • Known risks – Those risks that can be uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed, and other reliable information sources (e.g., unrealistic delivery date) • Predictable risks – Those risks that are extrapolated from past project experience (e.g., past turnover) • Unpredictable risks – Those risks that can and do occur, but are extremely difficult to identify in advance 51
  52. 52. Reactive vs. Proactive Risk Strategies • Reactive risk strategies – "Don't worry, I'll think of something" – The majority of software teams and managers rely on this approach – Nothing is done about risks until something goes wrong • The team then flies into action in an attempt to correct the problem rapidly (fire fighting) – Crisis management is the choice of management techniques • Proactive risk strategies – Steps for risk management are followed (see next slide) – Primary objective is to avoid risk and to have a contingency plan in place to handle unavoidable risks in a controlled and effective manner 52
  53. 53. Steps for Risk Management 1) 2) 3) 4) Identify possible risks; recognize what can go wrong Analyze each risk to estimate the probability that it will occur and the impact (i.e., damage) that it will do if it does occur Rank the risks by probability and impact - Impact may be negligible, marginal, critical, and catastrophic Develop a contingency plan to manage those risks having high probability and high impact 53
  54. 54. Risk Identification
  55. 55. Background • Risk identification is a systematic attempt to specify threats to the project plan • By identifying known and predictable risks, the project manager takes a first step toward avoiding them when possible and controlling them when necessary • Generic risks – Risks that are a potential threat to every software project • Product-specific risks – Risks that can be identified only by those a with a clear understanding of the technology, the people, and the environment that is specific to the software that is to be built – This requires examination of the project plan and the statement of scope – "What special characteristics of this product may threaten our project plan?" 55
  56. 56. CHAPTER 6 OBJECT ORIENTED ANALYSIS SIM3301 Object-Oriented Analysis 56
  57. 57. Learning Objectives • Understand object oriented concepts • Be able to understand and/or draw object oriented analysis modeling: – Use case diagram – Activity diagram – Class diagram – Sequence diagram – Collaboration diagram – State diagram SIM3301 Object-Oriented Analysis 57
  58. 58. Object-Oriented Concepts • Must be understood to apply classbased elements of the analysis model • Key concepts: – Classes and objects – Attributes and operations – Encapsulation and instantiation – Inheritance SIM3301 Object-Oriented Analysis 58
  59. 59. Classes • object-oriented thinking begins with the definition of a class, often defined as: – template – generalized description – “blueprint” ... describing a collection of similar items • a superclass establishes a hierarchy of classes • once a class of items is defined, a specific instance of the class can be identified SIM3301 Object-Oriented Analysis 59
  60. 60. Building a Class Class name Attributes Operations SIM3301 Object-Oriented Analysis 60
  61. 61. Encapsulation/Hiding Class encapsulates both data and the logical procedures required to manipulate the data method Reduces the propagation of side effects when changes occur method #2 #1 data method #3 method #6 method #5 method #4 Achieves “information hiding” SIM3301 Object-Oriented Analysis 61
  62. 62. Class Hierarchy PieceOfFurniture (superclass) Table Chair Desk ”Chable" Subclass inherit both attributes and operations from a superclass subclasses of the Subclasses of the furniture superclass Instances of chair instances of Chair SIM3301 Object-Oriented Analysis 62
  63. 63. Methods (a.k.a. Operations, Services) An executable procedure that is encapsulated in a class and is designed to operate on one or more data attributes that are defined as part of the class. A method is invoked via message passing. SIM3301 Object-Oriented Analysis 63
  64. 64. Attributes A collection of data values that describe a class SIM3301 Object-Oriented Analysis 64
  65. 65. Objects • Instances of a specific class • Inherit a class attributes and operations Class : STUDENT Object instance (object): Ali attributes : name, date of birth, etc. operations :calc_age, calc_cgpa, etc. SIM3301 Object-Oriented Analysis 65
  66. 66. Example STUDENT Name DOB Address Phone Calculate_age Calculate_gpa Register_course SIM3301 Object-Oriented Analysis 66
  67. 67. Object Oriented Analysis (OOA) Based on objects rather than data or processes The intent of OOA is to define all classes (and the relationships and behavior with them) that are relevant to the problem to be solved • There are various OOA methods. Booch Method, Jacobson Method and Rumbaugh Method have collaborated into. Unified Approach – Unified Modeling Language (UML) SIM3301 Object-Oriented Analysis 67
  68. 68. THE OOA PROCESS Use Case Modeling – shows functions Class-based Modeling – Class diagram, CRC Behavioral Model – State Diagram, Sequence Diagram SIM3301 Object-Oriented Analysis 68
  69. 69.  USE CASE MODELING Illustrates the manner in which an actor interacts with the system Actor = “ Anything that communicates with the system and that is external to the system” Represent actor Can be people or devices Represent the roles that people/devices play as the system operates Represent a use case •Use Case Depiction of a system’s behavior or functionality under various conditions as the system responds to requests from users Full functioning for a specific business purpose SIM3301 Object-Oriented Analysis 69
  70. 70. Use-Cases • • • A collection of user scenarios that describe the thread of usage of a system Each scenario is described from the point-of-view of an “actor” Each scenario answers the following questions: (eg: refer handout “Use Case Template for Surveillance”) – – – – – – – – – – SIM3301 Who is the primary actor, the secondary actor (s)? What are the actor’s goals? What preconditions should exist before the story begins? What main tasks or functions are performed by the actor? What extensions might be considered as the story is described? What variations in the actor’s interaction are possible? What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes? Object-Oriented Analysis 70
  71. 71. Use-Case Diagram SafeHome Access camera surveillance via the Internet cameras ConfigureSafeHome system parameters homeowner Set alarm SIM3301 Object-Oriented Analysis 71
  72. 72. Eg: consider the interactions between a Bank Customer and an ATM Bank ATM Machine Withdraw Cash Bank Customer Check Balance Create Online Transaction SIM3301 Object-Oriented Analysis 72
  73. 73. Writing Use-Cases (Scenario) • Use case:Access camera surveillance-display camera views (ACS-DCV) • Actor:homeowner If I’m at remote location, I can use any PC with appropriate browser software to log on to the SafeHome Products Web site. I enter my user ID and two levels of passwords and, once I’m validated, I have access to all functionality for my installed SafeHome system. To access specific camera view, I select “surveillance” from the major function buttons displayed, I then select “pick camera”, and the floor plan of the house is displayed. I then select the camera that I’m interested in. Alternatively, I can look at thumbnail snapshots from all cameras simultaneously by selecting “all cameras” as my viewing choice. Once I choose a camera, I select “view” and a one-frame-per-second view appears in a viewing window that is identified by the camera ID. If I want to switch cameras, I select “pick a camera” and the original viewing window disappears and the floor plan of the house is displayed again. I then select the camera that I’m interested in. A new viewing window appears. • A variation of this narrative use case is an ordered sequence of user actions – refer handout “Use Case Template for Surveillance “(Pressman, R. (2005). Software Engineering : A Practitioner's Approach, 6th edition. New York : McGraw-Hill) • . SIM3301 Object-Oriented Analysis 73
  74. 74. Use-Case Modeling • Relationships Between Use Cases – Use cases may participate in relationships with other use-cases – Two types • Extends – Adds new behaviors or actions to a use case • Include – One use case references another use case 20.74 SIM3301 Object-Oriented Analysis 74
  75. 75. Example: Use-case diagram for a university registration system (Correction: arrow direction should be in opposite direction) 20.75 SIM3301 Object-Oriented Analysis 75
  76. 76. SIM3301 Object-Oriented Analysis 76
  77. 77. Selecting Classes—Criteria • Retained Information • Needed services – have a set of identifiable operations • Multiple attributes • Common attributes • Common operations • Essential requirements SIM3301 Object-Oriented Analysis 77
  78. 78. CRC Modeling • Analysis classes have “responsibilities” – Responsibilities are the attributes and operations encapsulated by the class • Analysis classes collaborate with one another – Collaborators are those classes that are required to provide a class with the information needed to complete a responsibility. – In general, a collaboration implies either a request for information or a request for some action. SIM3301 Object-Oriented Analysis 78
  79. 79. Class Types • Entity classes, also called model or business classes, are extracted directly from the statement of the problem (e.g., FloorPlan and Sensor). • Boundary classes are used to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used. • Controller classes manage a “unit of work” [UML03] from start to finish. That is, controller classes can be designed to manage – the creation or update of entity objects; – the instantiation of boundary objects as they obtain information from entity objects; – complex communication between sets of objects; – validation of data communicated between objects or between the user and the application. SIM3301 Object-Oriented Analysis 79
  80. 80. Collaborations • Classes fulfill their responsibilities in one of two ways: – A class can use its own operations to manipulate its own attributes, thereby fulfilling a particular responsibility, or – a class can collaborate with other classes. • Collaborations identify relationships between classes • Collaborations are identified by determining whether a class can fulfill each responsibility itself • three different generic relationships between classes [WIR90]: – the is-part-of relationship – the has-knowledge-of relationship – the depends-upon relationship SIM3301 Object-Oriented Analysis 80
  81. 81. Behavioral Modeling • The behavioral model indicates how software will respond to external events or stimuli. To create the model, the analyst must perform the following steps: • Evaluate all use-cases to fully understand the sequence of interaction within the system. • Identify events that drive the interaction sequence and understand how these events relate to specific objects. • Create a sequence for each use-case. • Build a state diagram for the system. • Review the behavioral model to verify accuracy and consistency. SIM3301 Object-Oriented Analysis 81
  82. 82. Behavioral Modeling • make a list of the different states of a system (How does the system behave?) • indicate how the system makes a transition from one state to another (How does the system change state?) – indicate event – indicate action • draw a state diagram or a interaction diagram (sequence diagram or collaboration diagram) SIM3301 Object-Oriented Analysis 82
  83. 83. Sequence diagram A representation of how events cause flow from one object to another as a function of time.  Events are identified by examining a use case  Is a shorthand version of a use case Sequence diagram consists of: • Objects • Lifeline • Messages/Event objects message/even t lifeline (time) SIM3301 Object-Oriented Analysis 83
  84. 84. Sequence Diagram anOrder Object Object and Class anOrder: Order Message/event prepare() needsToReorder() SIM3301 Self Delegation Object-Oriented Analysis 84
  85. 85. object Object A: Class A Object B: Class B : Actor messageA( ) message messageB(string) messageC( ) activation (optional) lifeline SIM3301 Object-Oriented Analysis 85
  86. 86. Identifying events with the Use-Case • Use case for a small portion of the SafeHome security function The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action. SIM3301 Object-Oriented Analysis 86
  87. 87. Sequence Diagram co n t ro l p an el h o meo w n er syst em read y A sen so rs sen so rs syst em read in g p assw o rd en t ered req u est lo o ku p co mp arin g resu lt pas s word = c orrec t req u est act ivat io n num berOf Tries > m ax Tries lo cked A t imer > lo cked Time select in g act ivat io n su ccessfu l act ivat io n su ccessfu l Figure 8 .2 7 Sequence diagram (part ial) f or SIM3301 Object-Oriented Analysis Saf eHome securit y f unct ion 87
  88. 88. Class diagram Sequence diagram Bob: ClockStaff Ali : User printRecord( ) STAFF printRecord calculateSalary CLOCKSTAFF COMISSIONSTAFF printRecord calculateSalary printRecord calculateSalary SIM3301 Object-Oriented Analysis Bob: ClockStaff Ali : User calculateSalary( ) 88
  89. 89. Order OrderLine DeliveryItem orderNumber date etc… itemnumber quantity etc… itemnumber quantity etc… prepare() prepare() new() is_for StockItem OrderEntryWindow choose() SIM3301 orderNumber minQuantity date etc… ReOrderItem itemnumber quantity etc… new() check():boolean remove() needsToReorder(): boolean Object-Oriented Analysis 89
  90. 90. anOrder Entry window anOrder anOrder Line aStock Item AReorder Item aDelivery Item choose() prepare() * prepare() check() [check=“true”] remove() needsToReorder() [needsToReorder=“true”] new [check=“true”] new SIM3301 Object-Oriented Analysis 90
  91. 91. Computer PrintServer Printer status(): integer uses print(file) print(filename) print(file) Managed by Queue store(file) SIM3301 Object-Oriented Analysis 91
  92. 92. aComputer: Computer aPrintServer: PrintServer aPrinter: Printer aQueue: Queue aUser: User print (filename) print(file) [printer free] print(file) [printer busy] store(file) SIM3301 Object-Oriented Analysis 92
  93. 93. Collaboration Diagram  Shows the relationships among objects  Consists of:  Objects  Lines connecting the objects  Messages Object A 1. message1 SIM3301 2. Message2 3. Message3 Object C Object B Object-Oriented Analysis 93
  94. 94. 1. keyInCourseInfo Course Form Interaction diagrams Student 2. addCourse Academic Staff : Student 3. newCourse Academic Staff Student Schedule keyInCourseInfo addCourse Student Schedule SIM3301 Course Form newCourse Object-Oriented Analysis 94
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×