1. Žiga Turk, Assoc.Prof.
ziga.turk@uni-lj.si CMIT 558 Map
University of Ljubljana, Faculty of Civil and Geodetic Engineering
Istanbul Technical University IT strategies
construction
MBA in Construction Informatics in Construction Management
as a new
economy visions,
strategies, software product
requirements engineering databases
CMIT 558: limits of
Web
Information Systems for Construction technology
technologies,
Management analysis and Java, XML document
design management
modelling client-server
product method technology
modelling computer
process development integrated
Software Engineering modelling construction
thesauri new ways of
classification working
distance
systems
information use working
retrieval management
2
Learning objective Context
how information systems are designed software engineering
management is involved as client
IT management, the modelling method
IT specialists as suppliers
process models
information systems development as an
product models
engineering process
software engineering
civil engineering
some similarities
one of a kind product
work on multiple projects
3 4

2. Content Literature
What is software engineering Pressman, Software Engineering, A Practitioner’s
Software as a process Approach, McGraw Hill
Software project management Rational Website www.rational.com
Software metrics (short)
Risk management
Analysis and design (separate presentations)
structured method
UML (object oriented method)
Lab: UML
5 6
Software Engineering — Some Software Characteristics
Introduction
What is Software Engineering (SE)? Software is
The process of building a software product. engineered or
developed, not
Some questions to put SE in perspective:
manufactured in
What are the sizes of some typical software products?
the traditional
Maple.exe = 1.3 Mbytes.-- System over 3.8 Mbytes
Mbytes.-- sense.
Netscape.exe = 1.26 megabytes.
Software does not
Microsoft Office 97 > 180 megabytes. wear out in the
How many people would it take to build these in same sense as
1 year? 2? hardware.
What would you do if a bug could cost lives and $2 Right: hardware
billion? failure rate
What would you do if a delay could cost $100’s of
millions? 7 8

3. Some Software Characteristics Some Software Characteristics
In theory, software Reality is more like
does not wear out this.
at all. Most serious
corporations control
BUT, and constrain
Hardware changes.
upgrades. Most software is
Software upgrades. custom built, and
customer never really
Right: failure curve
knows what she/he
for software wants
Right: actual failure
rate for software
9 10
Some General Approaches Software is complex
Develop and use good engineering practices for adding another button to an alarm clock costs
building software. money during manufacturing of each piece
Make heavy use of reusable software the cost is manufacturer’s
components.
Use modern languages that support good adding a butting to a program may cost
software development practices, e.g., Ada95, something during software development (or not)
Java. consequence is more complex software
Use 4th generation languages. more difficult to use
But, almost everything is a two-edged sword. the user pays
Consider long term tool maintenance.
Right now, this is a major problem for NASA.
11 12

4. Software Myths Software Myths
Myth: It’s in the software. So, we can easily Myth: I can’t tell you how well we are doing until I get
change it. parts of it running.
Reality: Requirements changes are a major cause of Reality: Formal reviews of various types both can give good
software degradation. information and are critical to success in large projects.
Myth: We can solve schedule problems by Myth: The only deliverable that matters is working code.
Reality: Documentation, test history, and program configuration
adding more programmers. are critical parts of the delivery.
Reality: Maybe. It increases coordination efforts and
may slow things down. Myth: I am a (super) programmer. Let me program it,
and I will get it done.
Myth: While we don’t have all requirements in Reality: A sign of immaturity. A formula for failure. Software
writing yet, we know what we want and can projects are done by teams, not individuals, and success
start writing code. requires much more than just coding.
Reality: Incomplete up-front definition is the major
up-
cause of software project failures.
13 14
Software Myths Software as a Process
Myth: Writing Definition: Software Engineering is the
code is the major establishment and use of sound engineering
part of creating a
principles in order to obtain economically
software product.
Reality: Coding
software that is reliable and works efficiently on
may be as little real machines.
as 10% of the
effort, and 50 - Software Engineering is a layered technology.
70% may occur
after delivery.
Below: Impact of
change.
15 16

5. A Layered Technology Some Generic Engineering
Phases: Building
Tools System or information engineering (leading to
Editors requirements)
Design aids Software project planning
Compilers Requirements analysis
Computer Aided Software Engineering (CASE) Development
Methods Software design
Includes standards (formal or informal) Coding
May include conventions, e.g., low level such as
conventions, Testing
naming, variable, language construct use, etc.
Migration
May involve design methodologies.
methodologies.
Maintenance
17 18
Some Generic Engineering Typical activities in these phases
Phases: Maintenance
Maintenance Project tracking and control
Formal reviews
Correction -- bugs will appear Software quality assurance
Adaptation -- to changing operating systems, Configuration management
CPU’s, etc. versions, group of versions = configuration
Enhancement -- changing customer needs Documentation
Prevention -- software reengineering Reusability management
Measurements
Risk management
19 20

6. SEI Software Process Maturity Software Process Models
Model
Level 1: Initial -- The software process is characterized phases of problem
as ad hoc, and occasionally even chaotic. Few processes solving loop
defined.
Level 2: Repeatable -- Basic project management
processes established to track cost, schedule and
functionality.
Level 3: Defined -- Process for both management and
engineering is documented, standardized and integrated. problem solving
Level 4: Managed -- Detailed measures of the process applied recursively
and product quality collected. Both are quantitatively
understood and controlled.
Level 5: Optimizing -- Continuous process improvement
enabled by quantitative feedback and testing innovative
ideas.
SEI = Software Engineering Institute, CMU. 21 22
Process models Waterfall Model
Waterfall
Rapid Prototyping System/Information
Engineering
Evolutionary
incremental Requirements
Requirements Analysis
Analysis Design
Design Code
Code
spiral
component assembly
concurrent development
Test
Test
Other
formal
4GL
process technology Maintain
Maintain
23 24

7. The Rapid Prototyping Model Evolutionary process models:
Incremental Model
25 26
Evolutionary Process Models: Evolutionary Process Models:
The Spiral Model Component Assembly Model
27 28

8. Evolutionary Process Models: Other Models
Concurrent Development Model
Formal Methods
Rigorous mathematical representation of
requirements
Provides basis for automatic verification test
generation
Fourth Generation Techniques
Use code generators to produce specific parts of
product
Process Technology
Provides a variety of tools to aid software developers,
e.g., workload flow, configuration management,
quality assurance management, etc.
29 30
Project Management Concepts Why Do Major Engineering
Undertakings Often Fail?
Why is project management important? Large projects often fail for two principal reasons:
Cost Communication: Inadequate communication
DoD already spending $30 billion annually on leads to project failure
software in late 80’s Coordination: Lack of communication implies
The US spent $150 billion that the team can not coordinate. Thus each
$225 billion worldwide group moves in an independent direction and
Projects frequently fail or have severe difficulties the project will grind to a halt.
“New” FAA air traffic control system
They don’t meet specifications
no news to civil engineers!
They take much longer than expected
31 32

9. The Spectrum of Management People
Concerns
Effective Software management encompasses The Players -- It is important to recognize the
three main areas: different categories of people involved in a large
People software project.
Problem Senior Managers - who define business issues.
Process Project Managers - who plan, motivate, organize
and control the practitioners
Practitioners - who deliver the technical skill that
are necessary to engineer the project
Customers - who specify the requirements
End users - who interact with the software once
it is released.
33 34
Team Leadership -- Organisational Models:
A Critical Item Marilyn Mantei Model
The Problem:The best programmers often make Democratic decentralized (DD). -- Does not have a
poor team leaders. defined leader. “Task Coordinators” are appointed to
assure that a particular job is to be executed. These are
Different skills are required.
later replaced by other “Task Coordinators” as new tasks
Technical leadership model arise.
Motivation - the ability to encourage technical people Controlled decentralized (CD) -- Has a defined leader
to produce to their best ability. who coordinates tasks, and secondary leaders who carry
Organization - the ability to mold existing processes out subtasks. Problem solving is done by the group,
that will enable the initial concept to be translated implementation is done by subgroups.
into reality. Controlled Centralized (CC) - Top-level problem solving
Top-
Ideas and Innovation - the ability to invite and team coordination managed by the team leader.
creativeness even within a set of restrictions. The communication between the leader and members is
vertical.
35 36

10. Project Features Impacting Impact of Project Characteristics
Organization
Difficulty of problem to be solved. democratic
decentralised
Expected size of the resultant program.
controlled
The time the team will remain together. decentralised
The degree to which the problem can be controlled
modularized. centralised
The required quality and reliability of the
system.
The rigidity of the delivery date.
The degree of communication required for the
project.
37 38
Underlying Organizational Factors: How Do We Communicate?
Matrix model
The organization has divisions organized by Informally - Good phone/electronic service, a
skills, e.g., engineering, safety and mission clear definition of group interdependencies and
assurance, human factors, etc. good relationships help encourage
Projects “rent” people from the divisions, as communication
needed.
Issues
Who evaluates person for raises?
Independence of reporting for safety & quality issues?
Who is boss?
39 40

11. Project Coordination techniques Value and use of coordination
and communication techniques
Formal, impersonal approaches - software engineering
documents and deliverables, technical memos, project
milestones, schedules and control tools
Formal interpersonal procedures - quality assurance
activities - reviews and design and code inspections
Informal, interpersonal procedures - group meetings
Electronic communication - Email, bulletin boards, web
sites, extension and video conferences
Interpersonal network - discussions with those outside of
the project.
41 42
Summary Analysis and Design
Software project management is an umbrella
activity that continues throughout the life cycle Two primary methods today
of the system. Structured Analysis
Software management includes the people, the Object-oriented analysis
Object-
problem, and the process.
Some important considerations
The most critical element in all software system
projects is the people. The team can have an Analysis products must be maintainable
number of structures that effect the way work is Effective partitioning is essential
accomplished. Graphics should be used whenever possible
However, complete, consistent problem Distinguish between logical and implementation
definition and an effective process are also
essential ingredients. Separate presentations!
43 44

12. Žiga Turk, Assoc.Prof. Software Process and Project
ziga.turk@uni-lj.si
University of Ljubljana, Faculty of Civil and Geodetic Engineering Metrics: Outline
Istanbul Technical University
MBA in Construction Informatics in Construction Management
Software Metrics Domains:
product metrics
CMIT 558:
project metrics
Information Systems for Construction
Management process metrics
Software Measurement
size-oriented metrics
size-
function-oriented metrics
function-
End of the short metrics for Software Quality
version
46
Measure, Metrics, and Indicator Use of Software Metrics
Measure -- Provides a quantitative indication of Use common sense and organizational sensitivity.
the extent, amount, dimensions, capacity, or Provide regular feedback to individuals and teams.
size of some product or process attribute (1000 Don’t use metrics to appraise individuals.
lines) Set clear goal and metrics.
Metrics -- A quantitative measure of the degree Never use metrics to threaten individuals or teams
to which a system, component, or process Problems != negative. These data are merely an
possesses a given attribute (40%) indicator for process improvement.
Don’t obsess on a single metric to the exclusion of other
Software Metrics -- refers to a broad range of important metrics.
measurements for computer software Do not rely on metrics to solve your problems.
Indicator -- a metric or combination of metrics Beware of people performing to metrics rather than
that provide insight into the software process, a product quality or safety.
software project, or the product itself. 47 48

13. Typical Causes of Product Measures of Software Quality:
Defects Correctness and Maintainability
Correctness is the degree to which the software
performs its required function. The most
common measure for correctness is defects per
KLOC
Maintainability is the ease that a program can be
corrected:
adapted if the environment changes
enhanced if the customer desires changes in
requirements
based on the time-oriented measure mean time to
time-
change.
49 50
Measures of Software Quality: Summary
Integrity and Usability
Integrity is a system’s ability to withstand Metrics are a tool which can be used to improve
attacks (both accidental and intentional) on its the productivity and quality of the software
security system
Usability - an attempt to quantify “user Process metrics takes a strategic view to the
effectiveness of a software process
friendliness” physical/intellectual requirement to
learn ... Project metrics are tactical that focus on project
work flow and technical approach
time required to become moderately efficient
Size-oriented metrics use the line of code as a
the net increase in productivity
normalizing factor
user attitudes toward system
Function-oriented metrics use function points
Quality metrics are correctness, integrity,
maintainability, and usability.
51 52

14. Software Project Planning Software Scope
Steps to Software Planning: What scope means:
Functions
Define Software Scope Literally refers to all functions performed by a system
Determine Resources Performance
Create Project Estimates Refers to processing and response time requirements
Make or buy decision Constraints
Limits placed on the software by external hardware,
available memory or existing systems
Interfaces
Reliability
53 54
Scope Scope Information
Obtaining the information Some typical questions
Communication, communication, communication!!! Overall Goals
Who’s request
Meet with customer as often as needed. What benefit
Have free form discussion Who else has solution
Try to understand his/her goals/constraints, not just Understanding The Problem
what she/he thinks they want. What output
What Problem
Beware if ones provides detailed written What Issues
specifications on what they want. What Constraints
The problem is that those writing them probably Effectiveness of Meeting
didn’t fully understand, and they will change. Are answers official
Are my questions relevant
Other sources of Info.
55 56

15. Scoping - Subsequent Meetings Human Resources
Begin high level planning Scope and skills required
Know the capabilities of existing software and staff Organizational position and specialty must both
Joint teams of customer and developers/analysts be considered
Checklist of items to cover As estimate of development effort is essential to
Organization of Information determine the number of people required for the
Get everything down with diagrams project.
Create and save transcripts of Meetings
Possibly use Web.
57 58
Reusable Software Resources Software Engineering
Environmental Resources
Compilers
Off-the-shelf components
Editors
The validity pedigree is critical
Design tools
Full experience components Configuration management tools
Partial experience components Management tracking tools
New validation will have to be performed Problem Reporting And Corrective Action
(PRACA) tools
Documentation tools
Hardware resources
Network support
59 60

16. Software Project Estimation Software Project Estimation
Estimation critical -- software costs usually Precise estimation is difficult. So, make three
dominate project. estimates:
Categories of estimation techniques optimistic
Base estimates on similar projects most likely
Use simple decomposition (possibly in combination pessimistic
with other methods
Use one or more empirical models, I.e., Then combine as:
• For example # of people = LOC ÷(Duration*(LOC/PM))
LOC = line of code (S 4*S
EV = (Sopt + 4*Sm + Spess)/6
PM = person month
61 62
Estimation Table Process Based Estimation
Decompose the process into a set of activities or tasks
Estimate effort or cost to perform each task
Estimate cost cost of each function
May be done using
LOC and
FP estimation
or separately
Suppose: If estimated separately, then there are two or three
distinct cost estimates
620 LOC/PM Reconcile differences
$8,000/PM If radically different, perhaps
based upon historical data. Then, • problem is not well understood, or
• productivity data is obsolete, or
Est. Cost = 33,200*$8,000/620 = $421,000 63 • the models have not been used correctly. 64

17. Summary Risk Management
Project planner must estimate three things: Introduction
how long project will take Risk Identification
how much effort will be required Risk Projection
how many people will be required
Risk Mitigation, Monitoring, and
Must use decomposition and empirical modeling Management
Most empirical techniques need to be calibrated to
individual situations.
Safety Risks and Hazards
Use multiple techniques to gain confidence in result The RMMM plan
SEI Technical Reviews
Summary
65 66
Introduction Introduction
Risk management is a process that is used Robert Charette presented the following
extensively for various purposes conceptual definitions of risk:
Recall earlier questions raised about safety, costs, Risk concerns future happenings
etc. Risk involves change, such as changes of mind,
According to “Webster’s Seventh New Collegiate opinion, action or places
Dictionary”, risk is defined as a: Risk involves choice, and the uncertainty that choice
“possibility of loss or injury” itself entails
“the chance of loss or the perils to the subject matter Risk Characteristics :
of an insurance contract” and uncertainty: may or may not happen
“the degree of probability of such loss.” loss: unwanted consequences
67 68

18. Introduction Types of risk strategies
Management is Reactive Proactive
“the act or art of managing” and Software team does Begins long before
nothing about risks until technical work is initiated
“judicious use of means to accomplish an end”(1) something goes wrong Identification of potential
RISK MANAGEMENT can be defined as: “fire fighting mode” risks (studies of probability,
At best, monitors the impact and priorities)
“A logical process for identifying and analyzing projects for likely risks Objective: AVOID RISK
leading to appropriate methods for handling and Responds are in a
monitoring exposures to loss” controlled and effective
manner
Risk management deals with:
Systematic identification of an exposure to the risk of
loss, &
Making decisions on the best methods for handling
these exposures to minimize losses
69 70
Kinds of risks Risk Identification
Project Risks Risk identification is a systematic attempt to
budgetary, schedule, personnel, resource, customer specify threats to the project plan
Technical Risks
design, implementation, interfacing, verification Identify known and predictable risks
Business Risks Generic Product-specific
market, strategic, management,budget Product size
Business impact
Customer characteristics
What characteristics of Process definition
Risks may be: this product may threaten Development environment
our project plan? Technology to be built
Known Staff size and experience
Predictable
Unpredictable Risk Item List
71 72

19. Risk Identification Product Size Risk :
product Estimated size of the product in LOC or FP?
business Percentage deviation in size of product from average for
previous products?
customer Number of users/projected changes to the requirements
technlogy for the product?
Amount of reused software?
73 74
Business Impact risks: Customer related risks:
Effect of this product on the company revenue? Have you worked with the customer in the past?
Visibility of this product to senior management? Does the customer have a solid idea of what is
Amount & quality of product documentation to be required?
produced?
Governmental constraints on the construction of the
Will the customer agree to have meetings?
product? Is the customer technically sophisticated in the
product area?
Does the customer understand the software
process?
75 76

20. Technology Risks: Process Risks
Is the technology to be built new to your Does senior management support a written policy statement that
emphasizes a standard process for software development ?
organization? Is there a written description of the software process to be used?
used?
Does the SW interface with new or unproven Is the software process used for other projects ?
HW/SW? Is configuration management used to maintain consistency among
system/software requirements, design, code and test?
Do requirements demand creation of new Is a procedure followed for tracking subcontractor performance?
components ? Are facilitated application specification techniques used to aid in
communication between the customer and developer ?
Do requirements impose excessive performance
Are specific methods used for software analysis?
constraints ? Do you use specific method for data and architectural design?
Are software tools used to support the software analysis and
design?
Are tools used to create software prototypes?
77
Are quality/productivity metrics collected for all software projects?
projects? 78
Development Environment Risks: Risk Associated with Staff Size
and Experience:
Is a software project/process management tool Are the best people available?
available? Do the people have the right combination of
Are tools for analysis and design available?? skills?
Are testing tools available and appropriate for Are staff committed for entire duration of the
the product? project?
Are all SW tools integrated with one another? Do staff have the right expectations about the
Have members of the project team received job at hand?
training in each of the tools? Will turnover among staff be low enough to
allow continuity?
79 80

21. Risk Components and Drivers Risk Identification Table
(U.S. Air Force guidelines)
COMPONENTS
Performance risk: the degree of uncertainty that
PERFORMANCE SUPPORT COST SCHEDULE
the product will meet its requirements and be fit CATEGORY
Failure to meet the requirements would Failure results in increased costs and
for its intended use 1 schedule delays with expected values in
result in mission failure excesss of $500k
CATASTROPHIC
Significant Nonresponsive or Significant financial Unachievable
degradation to
Cost risk: the degree of uncertainty that the 2 unsupportable shortages, budget
nonachievement of
technical performance software overrun likely delivery date
project budget will be maintained Failure to meet the requirements would Failure results in operational delays
1 degrade system performance to a point and/or increased costs with expected
where misssion success is questionable values of $100k to $500k
CRITICAL
Support risk:the degree of uncertainty that the Some reduction in Minor delays in Some shortage of Possible slippage in
2 software financial resources,
technical performance modifications possible overruns delivery date
software will be easy to correct, adapt, and Failure to meet the requirements would Cost, impacts, and/or recoverable
1 result in degradation of secondary schedule slips with expected value of $1
enhance MARGINAL misssion to $100K
Minimal to small Responsive Sufficient financial Realistic,
2 reduction in technical
Schedule risk: the degree of uncertainty that the performance software support resources achievable schedule
Failure to meet the requirements would Error in minor cost and/or schedule
1 create inconvenience or nonoperational impact with expected value of less than
NEGLIGIBLE
project schedule will be maintained impact $1k
No reduction in Easily supportable Possible budget Early achievable
2
technical performance software underrun delivery date
81 82
Risk Projection Risk Projection
Also called risk estimation, attempts to rate each risk in
two ways: Risks Category Probability Impact RMMM
Likelihood (probability) Size estimate may be significantly low PS 60% 2
Larger number of users than planned PS 30% 3
Consequences Less reuse than planned PS 70% 2
End users resist system BU 40% 3
Delivery deadline will be tightened BU 50% 2
Develop a risk table Funding will be lost CU 40% 1
A risk table provides a project manager with a simple technique Customer will change requirements PS 80% 2
for risk projection Technology will not meet expectations TE 30% 1
Lack of training on tools DE 80% 2
For each identified risk, list likelihood, consequence and impact
impact
Staff inexperienced ST 30% 2
Risk Assessment: Examine the accuracy of the estimates Staff turnover will be high ST 60% 2
.
that were made during risk projection. A risk referent .
.
level must be defined and the referent point or break
point should be established
83 84

22. Risk Matrix Risk Mitigation, Monitoring, and
Management
L 5 An effective strategy must consider three issues:
I risk avoidance,
k risk monitoring, and
4 risk management and contingency planning. A proactive approach
e to risk avoidance is the best strategy.
l
3 Develop a plan for risk mitigation. For example: assume
I
that high staff turnover is noted as a project risk r1, some
h
2 of the possible steps to be taken are these:
o
meet with current staff to determine causes for turnover
o
1 assume turnover will occur and develop techniques to ensure
d
continuity when people leave.
1 2 3 4 5 define a backup staff member for every critical technologies.
Consequences
85 86
Risk Mitigation, Monitoring, and Safety Risks and Hazards
Management
As the project proceeds, the following factors can be
monitored: Software safety and hazard analysis are
general attitude of team members based on project pressures, software quality assurance activities that focus
the degree to which the team has jelled, on the identification and assessment of potential
interpersonal relationship among team members,
hazard that may impact software negatively and
availability of jobs within the company and outside it cause an entire system to fail.
In addition of these factors, the project manager should monitor
the effectiveness of risk mitigation steps. Risk management and If hazards can be identified early in the software
contingency planning assumes that mitigation efforts have failed engineering process, software design features
and that the risk has become reality.
can be specified that will either eliminate or
control potential hazards.
87 88

23. SEI Risk Management Paradigm Summary
Risk analysis is an important part of most software projects.
a) Identify Risk analysis requires a significant amount of project
b) Analyze planning effort.
c) Plan
d) Track Understanding risk helps you know where to commit your
e) Control resources.
f) Communicate
If you don’t actively attack the risks, they will actively
attack you.
Major projects should all have a risk management plan..
89 90