james nowotarski 24 october 2006 se 325/425 principles and practices of software engineering autumn...
Post on 20-Dec-2015
218 views
TRANSCRIPT
James Nowotarski
24 October 2006
SE 325/425Principles and
Practices of Software Engineering
Autumn 2006
2
Topic Duration
Planning and metrics recap 20 minutes
Analysis modeling 60 minutes
*** Break
Current event reports 20 minutes
Analysis modeling (cont.) 30 minutes
Design modeling 30 minutes
Today’s Agenda
3
People trump process
“A successful software methodology (not new, others have suggested it):
(1) Hire really smart people(2) Set some basic direction/goals(3) Get the hell out of the way
In addition to the steps about, there's another key: RETENTION”
http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html
4
Planning process
Usersrequirements 1
Negotiatereqts
negotiatedrequirements
2
Decom-pose
workbreakdownstructure
4
Estimateresources
workmonths
3
Estimatesize
deliverablesize
5
Developschedule
schedule
Iterate as necessary
productivity rate
5
1. Breaks project into a hierarchy.
2. Creates a clear project structure.
3. Avoids risk of missing project elements.
4. Enables clarity of high level planning.
Work Breakdown Structure
6
Usersrequirements 1
Negotiatereqts
negotiatedrequirements
2
Decom-pose
workbreakdownstructure
4
Estimateresources
workmonths
3
Estimatesize
deliverablesize
5
Developschedule
schedule
Iterate as necessary
productivity rate
Planning process
Computing Function PointsMeasurement parameter Count Sim-
pleAvg Com
-plex
Number of user inputs X 3 4 6 =
Number of user outputs X 4 5 7 =
Number of user inquiries
X 3 4 6 =
Number of files X 7 10 15 =
Number of external interfaces
X 5 7 10 =
Count (Unadjusted Function Points) UFP
5
8
10
8
2
15
32
40
80
10
177
10
Project Management
Communication project initiation requirements
Modeling analysis design
Construction code test
Deployment delivery support
Planning & Managing
top down estimating bottom up estimating
Empirical Estimation Models Empirical data supporting most empirical models is derived
from a limited sample of projects.
NO estimation model is suitable for all classes of software projects.
USE the results judiciously.
General model:
E = A + B X (ev)c where A, B, and C are empirically derived constants.E is effort in person monthsev is the estimation variable (either in LOC or FP)
Be sure to include contingency
The earlier “completed programs” size and effort data points in Figure 2 are the actual sizes and efforts of seven software products built to an imprecisely-defined specification [Boehm et al. 1984]†. The later“USAF/ESD proposals” data points are from five proposals submitted to the U.S. Air Force Electronic Systems Division in response to a fairly thorough specification [Devenny 1976].
http://sunset.usc.edu/research/COCOMOII/index.html
13
Usersrequirements 1
Negotiatereqts
negotiatedrequirements
2
Decom-pose
workbreakdownstructure
4
Estimateresources
workmonths
3
Estimatesize
deliverablesize
5
Developschedule
schedule
Iterate as necessary
productivity rate
Planning process
14
GANTT Schedule
• View Project in Context of time.
• Critical for monitoring a schedule.
• Granularity 1 –2 weeks.
15
Objectives of Software Measurement Help a systems development unit understand their
performance
Evaluate performance relative to goals
Allow for comparisons to, e.g.,: Other organizations Alternative development approaches (custom,
packaged, outsourced, etc.) and technologies Other standards/targets
Improve estimating ability
Promote desired behaviors, e.g., reuse
16
GQM Example (High Level)
Improve systems delivery performanceGoal
What is the qualityof our deliverables? How predictable is
our process?How quickly do we deliver?
How efficient are we?
Question
MetricFault density Delivery rate Productivity rate Duration variance
percentage
17
Example: Speed of delivery
0
10
20
30
40
50
60
70
0 2000 4000 6000 8000 10000 12000
Developed Function Points
Ela
pse
d M
onth
s
= Is a single project release (Average elapsed months =14.8, n=33).
Industry Average line is determined from Software Productivity Research
18
Example: Schedule reliability
0%
10%
20%
30%
40%
50%
60%
2000 4000 6000 8000 10000 12000
Developed Function Points
Sch
edu
le V
aria
nce
abo
ve c
omm
itmen
t
= Is a single project release (n=33).
Industry Average line is determined from Software Productivity Research
19
Example: Software quality
0
1000
2000
3000
4000
5000
6000
7000
0 2000 4000 6000 8000 10000 12000
Developed Function Points
Fau
lts (
3 m
onth
s)
Faults reported over the first three months in operations (n=27) An estimated industry average for faults found in the first three months of operations. The assumption is that half the total faults are found in the first three months in operation. This average is one half of the industry average of the total faults from C. Jones, Applied Software Measurement, 1996, p.232.
20
Example: Productivity
0
2
4
6
8
10
12
0 2000 4000 6000 8000 10000 12000
Developed Function Points
Fun
ctio
n P
oint
s pe
r S
taff
Mon
th
Is a single project release (n=33) Industry Average line is determined from SoftwareProductivity Research.
22
Continuous Process Improvement
Approach to Quality and Measurement
Plan
Do
Check
Act
1. Identify performance standards and goals
2. Measure project performance
3. Compare metrics against goals
4. Eliminate causes of deficient performance- fix defects- fix root causes
23
Metrics Programs Need to Address People, Process, Technology
QUALITY MANAGEMENT
Enable
Change
Technology
Process
People
Metrics Awareness Education
Metrics Network
Vital Few Metrics Definitions Vital Few Metrics Implementation
Technology Strategy
KM Support for Measurement Community of Practice
Measurement Process Improvement
Large Project Network
Metrics Strategy Commitment / Ownership
Distributed Support Units
Metrics Repository and tools
Measurement Process Definition
Roles & Responsibilities
PROGRAM MANAGEMENT
Achieve-1
Change
Sustain
Change
Achieve-2
Change
Metrics Rollout Education/Training
Pilot Project Group
Ongoing Metrics Education / Training
System Building Improvement Goals
Metrics Definition & Implementation for Delivery Centers
Metrics Embedded in System Building Methods
Dashboard metrics Implementation
Pilot Selected Projectsand Selected Delivery Centers
Enable Large Projectsand Remaining Centers
24
Most metrics programs fail within first 2 years
Lack of [visible] executive sponsorship Lack of alignment with organizational goals Tendency to collect too much data Measures not calibrated, normalized, or
validated Not comparing apples-to-apples
Fear of [individual] evaluation Learning curve (e.g., function points) Cost overhead
Reasons
25
Key Success Factors Ensure that measurement is part of something larger,
typically performance improvement “Trojan Horse” strategy Ensure alignment with organizational goals
Start small, iterate Strongly recommend doing a pilot test
Automate capture of metrics data Rigorously define a limited, balanced set of metrics
“Vital Few” Portfolio approach Comparability
Aggregate appropriately Focus should be on processes, not individuals
Obtain [visible] executive sponsorship Understand and address the behavioral implications
26
Other Quotes
“Count what is countable, measure what is measurable, and what is not measurable,
make measurable”
Galileo
28
Some Courses at DePaul SE 468: Software Measurement and
Estimation Software metrics. Productivity, effort and defect models.
Software cost estimation. PREREQUISTE(S):CSC 423 and either SE 430 or CSC 315 or consent
SE 477: Software and System Project Management Planning, controlling, organizing, staffing and directing
software development activities or information systems projects. Theories, techniques and tools for scheduling, feasibility study, cost-benefit analysis. Measurement and evaluation of quality and productivity. PREREQUISTE(S):SE 465 or CSC 315
29
Topic Duration
Planning and metrics recap 20 minutes
Analysis modeling 60 minutes
*** Break
Current event reports 20 minutes
Analysis modeling (cont.) 30 minutes
Design modeling 30 minutes
Today’s Agenda
30
Context
Communication project initiation requirements
Modeling analysis design
Construction code test
Deployment delivery support
Planning & Managing
elicitationRequirementsengineeringtasks (Ch. 7-8)
elaborationspecification
Primarydeliverables
functional reqtsnon-functional reqts
analysis modelsoftware reqts spec
31
Use case often first part of analysis model to be developed
Communication project initiation requirements
Modeling analysis design
Construction code test
Deployment delivery support
Planning & Managing
elicitationRequirementsengineeringtasks (Ch. 7-8)
elaborationspecification
Use casedeliverables
preliminaryuse cases
refineduse cases
32
Use cases
A user scenario A thread of usage Tells a story of an actor (end user or
device) interacting with the system
33
Use-Case Diagram
homeowner
Arms/ disarms system
Accesses system via Internet
Reconfigures sensors and related
system features
Responds toalarm event
Encounters anerror condition
system administrator
sensors
34
Use case description – narrative
“If I’m at a remote location, I can use any PC with appropriate browser software to log on to the SafeHome Products Web site . . . “
Use-case: Activate the system
35
Use case description – ordered sequence
1. The homeowner observes . . .
2. The homeowner uses the keypad . .
3. The homeowner selects and keys in stay or away . . .
4. When activation occurs . . .
Use-case: Activate the system
36
Use case description - template
Use-case: ActivateSystem
Actor: Homeowner
Pre-conditions:
Trigger:
Scenario:
Exceptions:
. . .
Use-case: Activate the system
38
Key Definitions
A data model is aFormal representation of the data to
be used for a business system. A data model should illustrate:
The people, places and things about which data is collected,
And how they are related to each other
39
Data Modeling
Entity-relationship diagram (ERD) Entity descriptions Attribute descriptions Relationship descriptions
A logical data model deliverable includes an ERD and descriptions of entities, attributes, and relationships
Components of a Logical Data Model
41
Examples of Attributes
Entity: Person Attributes:
• first_name• last_name• eye_color• date_of_birth• address
Entity: Classroom Attributes:
• room_no• max_capacity
42
Depicting Entities, Attributes and Identifiers
Entity name
Attributes
Identifier
Or, usecd_id (PK)
43
Identifiers
An identifier should have the following characteristics:Its value should not change over the life of
each instanceIts value should never be “null” or emptyIt should be composed of the minimal
number (preferably one) of attributes required to ensure uniqueness
44
Relationships
Relationships represent connections, links, or associations between entities
• e.g., Patient-Appointment
Relationships have some important properties:
1. Names, that should be active verbs• (A patient schedules appointments)
2. Cardinality
3. Modality.
45
Cardinality and Modality
Department Employee
Cardinality: Implies that an employee is assigned to only one department.
Cardinality: Implies that there may be many employees in a department
contains
Modality: Mandatory implies that an employee MUST be assigned to a department
Modality: Optional implies that there may be a situation in which a department has no employees.
There are several other ERD notations, unfortunately there is no single standard!
is assigned to
47
Cardinality
Cardinality refers to the number of times instances in one entity can be related to instances in another entity One instance in an entity refers to one and
only one instance in the related entity (1:1) One instance in an entity refers to one or
more instances in the related entity (1:M) One or more instances in an entity refer to
one or more instances in the related entity (M:M)
48
Modality
Modality Indicates whether a particular data object MUST participate in the relationship. Modality = 0: No particular need for the
relationship. Modality = 1: Relationship is mandatory refers to the minimum number of times that
an instance in one entity can be related to an instance in another entity
One means that the relationship is mandatory Zero means the relationship is optional
51
What Is an ERD?
A picture of the logical data model, i.e., an ERD shows the information
created, stored, and used by a business system.
53
Independent Entities
An independent entity exists without the help of another entityCommon entities such as student,
professors, customers, productsThe identifier is created by the entity’s
own attributesUsually on the “1” side of a relationshipa.k.a. fundamental entity (in Visual
Analyst, e.g.) or strong entity
54
Dependent Entities Alternatively, a dependent entity cannot
exist without the help of another entitySpecial entities such as emp_dependent
(needs an employee to exist)The identifier is usually based on another
entity’s attributes (emp_ssn & dep_ssn)Usually on the “M” side of a relationshipa.k.a. weak entity
55
Intersection entities
An intersection entity exists based on the relationship between two entities.They have attributes that are peculiar to
the relationship between those entity instances, not the individual entities themselves
They are created to store information about two entities sharing an M:M relationship
a.k.a. associative entities
56
An Intersection Entity Example
A CD may be a part of many orders.
An order may contain many CDs.
The CD-order relationship is M:M.
Where do you store quantity of CD’s on an
order?
57
Adding Intersection Entities
1. Create an intersection entity
(line item).
3. The “1” side goes
on the original
entities.
2. Move the “M’s” adjacent to the
intersection entity.
58
M:N to 1:Ms
Rule: The M always go to the intersection entity.
Orders
CD_No CD_Title Order_No CD_No Qty Order_No234 Best of Lawrence Welk 100101 234 12 100101235 Living Daylights Soundtrack 100101 236 3 100102236 Moody Blues Greatest Hits 100102 234 5 100108
100102 235 2100102 236 6100108 236 1
CD Line Items
59
Summary
The ERD is the most common technique for drawing data models. The building blocks of the ERD are:Entities (nouns), describe people,
places, or thingsAttributes (nouns), capture information
about the entityRelationships (active verb sentences)
associate data across entities; they have cardinality and modality
60
From Analysis to Design
ER Model Relational Model
Database Spreadsheet
Entity Relation Table, File Table
Instance Tuple Record Row
Attribute Attribute Field Column
Identifier Key Key Key
Analysis Design
62
Structure Chart
PROCESS_PAYROLL for each employee get_data(:employee_data) calc_salary(employee_data:salary) calc_tax(salary:tax) print_check(employee_data, salary, tax)
GET_DATA
employee_data
CALC_SALARY
employee_ data
salary
CALC_TAX
salary
tax
PRINT_CHECK
employee_data
salary
tax
63
Program Graph
READ_DATA
CALC_SALARY
CALC_TAXES
PRINT_PAYCHECK
employee_data
employee_data
salary
salary
taxes
64
Program Graph
READ_DATA
CALC_SALARY
CALC_TAXES
PRINT_PAYCHECK
employee_data
employee_data
salary
salary
taxes
Big idea: As a prelude to creating a design, represent the basic computational requirement for the system to be designed in more abstract terms, i.e., in terms of data flow
65
Data Flow Diagrams A Data Flow Diagram (DFD) is a graphical
technique for: Depicting information flow The transforms that are applied as data move
from input to output DFD also known as a data flow graph or a
bubble chart DFDs can be modeled at multiple levels of
abstraction Level 0 DFD is called the context diagram or
context model and represents the entire system as a single bubble with inputs and outputs
66
DFD Context Model for SafeHome Security System
SafeHomesoftware
Controlpanel
Sensors Telephoneline
Alarm
Controlpanel
displayUser commandsand data
Sensorstatus
Telephonenumber tones
Alarmtype
Displayinformation
This highest level model is also called a Level 0 model or a Fundamental model.
67
Basic DFD NotationExternal
entity
A producer or consumer of information that resides outside the bounds (or at the boundaries) of the system to be modeled.
ProcessA transformer of information (a function) that resides within the bounds of the system to be modeled.
Data object
A data object; the arrowhead indicates the direction of data flow.
D1 Data storeA repository of data that is to be stored for use by one or more processes; may be as simple as a buffer or queue or as sophisticated as a relationship database.
69
Level 0 Tips
Generally move from top to bottom, left to right
Minimize crossed lines Iterate as needed
The DFD is often drawn many times before it is finished, even with very experienced systems analysts
70
Some Rules for External Entities
External people, organizations, systems and data stores
Reside outside the system, but interact with system
Either receive info from system or trigger system into motion
Examples: Customers, managers
Not clerks or other staff
ExternalEntities
71
SafeHomesoftware
Controlpanel
Sensors Telephoneline
Alarm
Controlpanel
displayUser commandsand data
Sensorstatus
Telephonenumber tones
Alarmtype
Displayinformation
Perform a grammatical parse on the narrative that describes the context level bubble.
Isolate nouns (& noun phrases), and verbs (& verb phrases).
The safeHome security function enables the homeowner to configure the security system when it is installed, monitors all sensors connected to the security system, and interacts with the homeowner through the internet, a PC, or a control panel.
During installation, the SafeHome PC is used to program and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event occurs.
Refining Level 0 to Level 1
72
Refining Level 0 to Level 1
When a sensor event is recognized, the software invokes an audible alarm attached to the system. After a delay time that is specified by the homeowner during system configuration activities, the software dials a telephone number of a monitoring service, provides information about the location, reporting the nature of the event that has been detected. The telephone number will be redialed every 20 seconds until a telephone connection is obtained.
The homeowner receives security information via a control panel, the PC, or a browser, collectively called an interface. The interface displays prompting messages and system status information on the control panel, the PC, or the browser window. Homeowner interaction takes the following form.
Process
VERBS
Externalentity
Data object
Data store
NOUNS
73
Level 1 DFD for SafeHome security function
Controlpanel
Interactwithuser
Processpassword
Configuresystem
Activate/deactivate
system
MonitorsensorsSensors Telephone
line
Alarm
Controlpanel
display
User commands & data
Password
Configurerequest
Start /stop
A/dmsg
Valid ID msg
Sensorstatus
Configuration information
Configuration data
Configuration data
Sensorinformation
Configurationdata
Displayinform-ationDisplay
messages& status
Alarmtype
Telephone number tones
MonitorsensorsSensor
status
Sensorinformation
Alarmtype
Telephone number tones
Configurationdata
74
Level 2 DFD for SafeHome’s “Monitor Sensors” process
Configuration information Formatfor
display
Configuration data
Assessagainstsetup
Generatealarmsignal
Readsensors
Dialphone
Sensor ID type, location
Sensor Information
Alarm type
Alarmdata
Telephonenumber
Telephonenumbertones
Sensor status
Sensor ID type
75
Some Rules for Data Stores
Internal to the system Data at rest Include in system if the system
processes transform the data Create, Update, Delete
Every data store on DFD should correspond to an entity on an ERD
Must have at least one input data flow (or else they never contain any data)
Usually have at least one output data flow
Data StoresD1
76
Some Rules for Data Flows
Data in motionFrom external entity
(“source”) to systemFrom system to external
entity (“sink”)From internal symbol to
internal symbol, but data flows always either start or end at a process
Data Flow
77
Some Rules for Processes
Always internal to system Law of conservation of data:
#1: Data stays at rest unless
moved by a process.
#2: Processes cannot consume or manufacture data Must have at least 1 input data flow (to avoid miracles) Must have at least 1 output data flow (to avoid black holes) Should have sufficient inputs to create outputs (to avoid
gray holes)
0.
Processes
79
Level 1 DFD for SafeHome security function
Controlpanel
Interactwithuser
Processpassword
Configuresystem
Activate/deactivate
system
MonitorsensorsSensors Telephone
line
Alarm
Controlpanel
display
User commands & data
Password
Configurerequest
Start /stop
A/dmsg
Valid ID msg
Sensorstatus
Configuration information
Configuration data
Configuration data
Sensorinformation
Configurationdata
Displayinform-ationDisplay
messages& status
Alarmtype
Telephone number tones
MonitorsensorsSensor
status
Sensorinformation
Alarmtype
Telephone number tones
Configurationdata
80
Key Definition
Decomposition is the process of modeling the system and its components in increasing levels of detail.
Balancing involves insuring that information presented at one level of a DFD is accurately represented in the next level DFD.
81
Summary
The Data Flow Diagram (DFD) is an essential tool for creating formal descriptions of business processes and data flows.
Use cases record the input, transformation, and output of business processes.
Eliciting scenario descriptions and modeling business processes are critically important skills for the software engineer to master.
83
A large class of applications are: Driven by events rather than by data, Produce control information rather than reports and displays Process information with heavy concern for time and
performance
To select candidate events consider: All sensors read by the system All interrupt conditions All “switches” that are actuated by an operator All data conditions Look for “control items” in the existing DFD Describe the behavior of the system as a set of states.
Consider how each state is reached. Look for possible omissions. (i.e., is there more than one way to
reach this state?)
Creating a control flow model
84
State Transition Diagram A safe has a combination lock that can be in one of
three positions, labeled 1, 2, and 3. The dial can be turned left (L) or right (R). Therefore there are only six possible dial movements:
1L (left to 1), 1R, 2L, 2R, 3L, 3R The combination is 1L, 3R, 2L.
Locked A B Unlocked
Alarm
1L 3R 2L
Any other dial movement
Any other dial movement
Any other dial movement
85
Students at a university
Inquiry Lead Applicant
Admitted
Rejected
Withdrawn
Enrolled Matriculated Graduated
Drop Out
86
SafeHome Security
Resetting
Entry/set systemStatus “inactive”Entry/set displayMsg1 “Starting system”Entry/set displayMsg2 “Please wait”Entry/set displayStatus showBlinkingDo: run diagnostics
Idle
Entry/set systemStatus “inactive”Entry/set displayMsg1 “Ready”Entry/set displayMsg2 “”Entry/set displayStatus steadykeyHit/handleKey
ActingOnAlarm
Entry/set systemStatus “monitorAndAlarm”Entry/set displayMsg1 “ALARM”Entry/set displayMsg2 triggeringSensor Entry/set displayStatus fastBlinkingDo: soundAlarmDo: notifyAlarmResponderskeyHit/handleKey
MonitoringSystemStatus
Entry/set systemStatus “monitoring”Entry/set displayMsg1 “Armed”Entry/set displayMsg2 “”Entry/set displayStatus steadyDo: monitorAndControlSystemKeyHit/handleKey
Start/ stop switch power “on”
failureDetected / set displayMsg2 “contact Vendor”
SystemOK
Reset
Activate
deactivatePassword
falseAlarm
timeOut
sensorTriggered/startTimer
sensorTriggered/restartTimer
deactivate Password
off/powerOff
87
The relationship between data and control models
DFDs
PSPECSs
CFDs
CSPECSs
data input data output
process activators
data conditions
control inputcontrol output
Process model
Control model
89
Topic Duration
Planning and metrics recap 20 minutes
Analysis modeling 60 minutes
*** Break
Current event reports 20 minutes
Analysis modeling (cont.) 30 minutes
Design modeling 30 minutes
Today’s Agenda
90
Design
Communication project initiation requirements
Modeling analysis design
Construction code test
Deployment delivery support
Planning & Managing
Primary deliverablesDesign model:• Data/Class • Architecture• Interfaces• Components
92
Abstraction
There is a limit to the number of ideas you can comprehend at any one time 7 +/- 2
Raise the level of detail by creating relationshipsExample: Grouping
Think in logical instead of physical terms
93
What’s easier to understand and retain?
Grapes Oranges
Milk Butter
Potatoes Apples
Eggs Sour cream
Carrots
Dairy Fruit Vegetable
Milk
ButterEggs
Sour cream
94
Modular design Reduces complexity Facilitates change Results in easier implementation by supporting parallel
development of different parts of the system.
Information hiding
Functional independence
Modularity
95
CohesionA measure of the relative functional strength of a module
High Cohesion (good)
CouplingA measure of the relative interdependence among modules.
High coupling (bad)
Func A-1
Func A-2
Func A-3
Func B-1
Func B-2
Func B-3
Two qualitative criteria
96
Cohesion "Cohesion is the degree to which the tasks performed by a single module are functionally related.“ IEEE, 1983
"Cohesion is the "glue" that holds a module together. It can be thought of as the type of association among the component elements of a module. Generally, one wants the highest level of cohesion possible.“ Bergland, 1981
"A software component is said to exhibit a high degree of cohesion if the elements in that unit exhibit a high degree of functional relatedness. This means that each element in the program unit should be essential for that unit to achieve its purpose.“ Sommerville, 1989
97
Cohesion A cohesive module performs a single task within a software
procedure, i.e., it should do JUST ONE THING.
Strive for HIGH cohesion.
Low High
“Scatter-brained” “Single-minded”
Coincidental
Logical
Temporal
Procedural
Communicational
Sequential
Functional
Strive for high cohesion.
Often acceptable. Almost as good as high cohesion.
Much worse than mid level cohesion.
98
Low Cohesion Logical Cohesion
Tasks related very loosely. (e.g., a module that produces ALL output regardless of its type).
public void logical_example( int flag ) { switch ( flag ) {
case 1: // “1” related functionality;break;case 2:// “2” related functionality;break;case 3:// “3” related functionality;break;
}}
Solution: Isolate each functionality into a separate operation / class etc.
99
Low Cohesion Temporal Cohesion
Tasks related by the fact that they must all be executed within the same span of time.
Common examples include startup or end of job clean-up routines.
procedure initializeData() { font = "times"; windowSize = "200,400"; foo.name = "Not Set"; foo.size = 12; foo.location = "/usr/local/lib/java";
}
Give each object a constructor and destructor.
100
Example of Low Cohesion A module that performs the following tasks when computed data exceed pre-specified bounds.
Computes supplementary data based on original computed data. Produces an error report (with graphical content) on the user’s workstation Performs follow-up calculations requested by the user Updates a database Enables menu selection for subsequent processing.
These functions are loosely connected but could best be implemented through individual modules.
101
Moderate Cohesion Relatively close to one another in the degree of module independence.
Procedural CohesionProcessing elements are related and must be executed in a specific order.
Communicational CohesionAll processing elements concentrate on one area of a data structure.
Sequential CohesionThe output data from one processing element serves as input data for the next processing element
102
Functional Cohesion If the operations of a module can be collectively
described as a single specific function in a coherent way, the module has functional cohesion. If not, the module has a lower type of cohesion.
In an O-O system,
Each operation in public interface of an object should be functional cohesive
Each object should represent a single cohesive concept
103
Coupling A measure of interconnection among modules in a
program structure.
Depends on The interface complexity between modules The point at which entry or reference is made to a module The data that pass across the interface.
Goal is LOW coupling in order to increase understandability and reduce the rippling effect during change.
Low High
No direct
coupling Data
coupling Stamp
coupling Control
coupling External
coupling Common
coupling Content
coupling
104
Types of coupling
a
b c
d
e
f g h
i
j k
Global data area
Data structure
Data (variables)
No direct coupling
Controlflag
Module M Module M’
Data Coupling
Stamp Coupling
ControlCoupling
CommonCoupling
105
Low Coupling
Data couplingCoupling is via a simple argument list through which simple data are passed.
Stamp couplingSame as data coupling except a portion of a data structure is passed.
Control couplingPassage of control between modules. (For example setting a control flag to control decisions in a subordinate module.)Very common in most software designs.
106
High Coupling Common Coupling
High level of coupling occurs when variables are tied to an environment external to software:
I/O couples a module to specific devices, formats, communication protocols.
In the example on the previous slide, c, g, and k all access a common data area.
c initializes it, g updates it incorrectly, later k uses and an error occurs. It appears that the error is in k – whereas actually it is in g.
The use of global data is not absolutely bad but:
Should be used sparingly
Developers should understand the possible implications.
107
Highest Coupling Content Coupling
One module makes use of data or control information maintained within the boundary of another module.
Branches are made into the middle of a module.
AVOID Content coupling.
Information hiding hiding helps prevent content coupling.
108
Design Heuristics1. Evaluate the first iteration of the program structure to reduce coupling and improve cohesion.
Implode or explode modules
2. Minimize structures with high fan-out; strive for fan-in as depth increases.
Avoid structures as shown below:
109
Design Heuristics3. Keep scope of effect of a module within the scope of control of that module.
The scope of control of a includes all modules that are subordinate to module a. (i.e., b,c,d,e,f)
If module a makes a decision that impacts module h, then this heuristic is violated.
a
b c d
g
h i
e f
112
Change Control Process
Create InitialSections
Create/ModifyDraft
Review Draft(V&V)
Create Changes to Incorporate
Changes Needed In Document
DocumentApproved
Create Review Revise ReviewReview Approved
Time
...
Document in Production and Under Formal Change Control
Document in Production and Under Formal Change Control
Document Under Development and User Change Control
Document Under Development and User Change Control
113
Waterfall model
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
Source: Royce, W. "Managing the Development of Large Software Systems."
114
Technology
ProcessPeople
The focus of SE 425 is the process component of software engineering
Core Concepts
Technology
ProcessPeople
… for the delivery of technology-enabled business solutions
115
LOC-Oriented Estimation Models
E = 5.2 X (KLOC)0.91 Walston-Felix Model
E = 5.5 + 0.73 X (KLOC)1.16 Bailey-Basili Model
E = 3.2 X (KLOC)1.05 Boehm simple model
E = 5.288 X (KLOC)1.047 Dot Model for KLOC > 9
FP-Oriented Estimation Models
E = -13.39 + 0.0545 FP Albrecht and Gaffney Model
E = 60.62 X 7.728 X 10-8 FP3
Kemerer model
E = 585.7 + 15.12 FP Matson, Barnett, Mellichamp model
The COCOMO ModelA hierarchy of estimation models
Model 1: BasicComputes software development effort (& cost) as a function of size expressed in estimated lines of code.
Model 2: IntermediateComputes effort as a function of program size and a set of “cost drivers” that include subjective assessments of product, hardware, personnel, and project attributes.
Model 3: AdvancedIncludes all aspects of the intermediate model with an assessment of the cost driver’s impact on each step (analysis, design, etc).
Three classes of software projectsOrganic
Relatively small, simple. Teams with good application experience work to a set of less rigid requirements.
Semi-detachedIntermediate in terms of size and complexity. Teams with mixed experience levels meet a mix of rigid and less rigid requirements. (Ex: transaction processing system)
EmbeddedA software project that must be developed within a set of tight hardware, software and operational constraints. (Ex: flight control software for an aircraft)
Basic COCOMO Model
Basic COCOMO equations
Nominal effort in person months: E = abKLOCbb
Development time in chronological monthsD = cbE
eb
Software Project ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
Major Software Functions
EstLOC
User interface and control facilities UICF 2,300
Two-dimensional geometric analysis 2DGA 5,300
Three-dimensional geometric analysis 3DGA 6,800
Database management DBM 3,350
Computer graphics display features CGDF 4,950
Peripheral control PC 2,100
Design analysis modules DAM 8,400
Estimated lines of code 33,200
E = abKLOCbb
E = 2.3(KLOC)1.05
= 2.3(33.2)1.05
= 95 person-months
D = 2.5E0.35
D = 2.5( 95)0.35
= 12.3 months.
Software Project
ab bb cb db
Organic 2.4 1.05 2.5 3.8
An example of Basic COCOMO
Intermediate COCOMO Model
Intermediate COCOMO equations
Effort in person months: E = abKLOCbb X EAFwhere EAF = an effort adjustment factor
Development time in chronological monthsD = cbE
eb
Software Project ab bb
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20
Major Software Functions
EstLOC
User interface and control facilities UICF 2,300
Two-dimensional geometric analysis 2DGA 5,300
Three-dimensional geometric analysis 3DGA 6,800
Database management DBM 3,350
Computer graphics display features CGDF 4,950
Peripheral control PC 2,100
Design analysis modules DAM 8,400
Estimated lines of code 33,200
E = abKLOCbb X EAF
E = 3.2(KLOC)1.05 X 1
= 3.2 (33.2)1.05 X 1
Software Project ab bb
Organic 3.2 1.05
The same example in Intermediate COCOMO
EAF is calculated as a product of the multipliers. In this case we set them all to NOMINAL.
http://sern.ucalgary.ca/courses/seng/621/W98/johnsonk/cost.htm#Intermediate
122
Structured EnglishCommon Statements Example
Action Statement Profits = Revenues - Expenses Generate Inventory - Report Add Product record to Product Data Store
If Statement IF Customer Not in Customer Data Store THEN Add Customer record to Customer Data Store ELSE Add Current-Sale to Customer’s Total-Sales Update Customer record in Customer Data Store
For Statement FOR all Customers in Customer Data Store Generate a new line in the Customer-Report Add Customer’s Total-Sales to Report-Total
Case Statement CASEIf Income < 10,000: Marginal-tax-rate = 10%If Income < 20,000: Marginal-tax-rate = 20%If Income < 30,000: Marginal-tax-rate = 31%If Income < 40,000: Marginal-tax-rate = 35%ELSE Marginal-tax-rate = 38%
ENDCASE
123
Processes Logical process models omit any processes that do
nothing more than move or route data, thus leaving the data unchanged. Valid processes include those that: Perform computations (e.g., calculate grade point
average) Make decisions (e.g., determine availability of ordered
products) Sort, filter or otherwise summarize data (e.g., identify
overdue invoices) Organize data into useful information (e.g., generate a
report or answer a question) Trigger other processes (e.g., turn on the furnace or
instruct a robot) Use stored data (create, read, update or delete a record)
124
Creating Data Flow Diagrams
Creating DFDs is a highly iterative process of gradual refinement.
General steps:
1. Create DFD fragments for each use case/requirement
2. Create a Level 0 diagram from fragments
3. Decompose to Level 1,2,…
4. Go to step 1 and revise as necessary
5. Validate DFDs with users.
125
Some Data Flow Rules
External entity Process Data store
External entityCustomer
information
Process
Data store N/A
Data moved TO:
Data Moving FROM
A process moves data from place to place in the system. On a data flow diagram, processes may move data between certain symbols (data stores, external entities, and other processes). However, data may not be moved without a process. To help you understand and appreciate this, fill in the empty cells in the following table. The cell entries should either be 1) An example of how data could be moved; 2) N/A to indicate this cannot be done.
In this example, “customer information” may be moved from an external entity to a process (e.g., a customer gives their address and credit card information to a sales agent).
The “N/A” suggests data cannot be moved from a data store directly to an external entity, which is true (you need a process in between them).