Ž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

Learning objective Context

„ how information systems are designed „ software engineering

z management is involved as client
z IT management, „ the modelling method
z IT specialists as suppliers
„ process models
„ information systems development as an
„ product models
engineering process
z software engineering
z civil engineering
„ some similarities
z one of a kind product
z work on multiple projects
3 4
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)
z structured method
z UML (object oriented method)
„ Lab: UML

5 6

Software Engineering — Some Software Characteristics

Introduction
„ What is Software Engineering (SE)? „ Software is
z The process of building a software product. engineered or
developed, not
„ Some questions to put SE in perspective:
manufactured in
z What are the sizes of some typical software products?
the traditional
z Maple.exe = 1.3 Mbytes.--
Mbytes.-- System over 3.8 Mbytes sense.
z Netscape.exe = 1.26 megabytes.
„ Software does not
z 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.
z What would you do if a bug could cost lives and $2 „ Right: hardware
billion? failure rate
z What would you do if a delay could cost $100’s of
millions? 7 8
Some Software Characteristics Some Software Characteristics
„ In theory, software „ Reality is more like
does not wear out this.
„ Most serious
at all.
corporations control
„ BUT, and constrain
z Hardware changes.
upgrades. „ Most software is
z 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
building software.
„ Make heavy use of reusable software
components.
„ Use modern languages that support good
software development practices, e.g., Ada95,
Java.
„ Use 4th generation languages.
„ But, almost everything is a two-edged sword.
z Consider long term tool maintenance.
z Right now, this is a major problem for NASA.
11
„ adding another button to an alarm clock costs
money during manufacturing of each piece
„ the cost is manufacturer’s
„ adding a butting to a program may cost
something during software development (or not)
„ consequence is more complex software
„ more difficult to use
„ the user pays
12
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.
z Reality: Requirements changes are a major cause of z Reality: Formal reviews of various types both can give good
software degradation. information and are critical to success in large projects.
„ Myth: The only deliverable that matters is working code.
„ Myth: We can solve schedule problems by
z Reality: Documentation, test history, and program configuration
adding more programmers. are critical parts of the delivery.
z Reality: Maybe. It increases coordination efforts and
„ Myth: I am a (super) programmer. Let me program it,
may slow things down.
and I will get it done.
„ Myth: While we don’t have all requirements in z 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.
z Reality: Incomplete up-
up-front definition is the major
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.
z 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
A Layered Technology Some Generic Engineering
Phases: Building
„ Tools „ System or information engineering (leading to
z Editors requirements)
z Design aids z Software project planning
z Compilers z Requirements analysis
z Computer Aided Software Engineering (CASE) z Development
„ Methods z Software design
z Includes standards (formal or informal) „ Coding
z May include conventions,
conventions, e.g., low level such as „ Testing
naming, variable, language construct use, etc.
„ Migration
z 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. z versions, group of versions = configuration
„ Enhancement -- changing customer needs „ Documentation
„ Prevention -- software reengineering „ Reusability management
„ Measurements
„ Risk management

19 20
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
z incremental Requirements Analysis Design Code
Requirements Analysis Design Code
z spiral
z component assembly
z concurrent development
Test
Test
„ Other
z formal
z 4GL
z process technology Maintain
Maintain

23 24
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
Evolutionary Process Models: Other Models
Concurrent Development Model
„ Formal Methods
z Rigorous mathematical representation of
requirements
z Provides basis for automatic verification test
generation
„ Fourth Generation Techniques
z Use code generators to produce specific parts of
product
„ Process Technology
z 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

Why is project management important?
„ Cost
z DoD already spending $30 billion annually on
software in late 80’s
z The US spent $150 billion
z $225 billion worldwide
„ Projects frequently fail or have severe difficulties
z “New” FAA air traffic control system
z They don’t meet specifications
z They take much longer than expected
Undertakings Often Fail?
Large projects often fail for two principal reasons:
„ Communication: Inadequate communication
leads to project failure
„ Coordination: Lack of communication implies
that the team can not coordinate. Thus each
group moves in an independent direction and
the project will grind to a halt.
„ no news to civil engineers!

31 32
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
z People software project.
z Problem „ Senior Managers - who define business issues.
z 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
The Problem:The best programmers often make
poor team leaders.
z Different skills are required.
„ Technical leadership model
z Motivation - the ability to encourage technical people
to produce to their best ability.
z Organization - the ability to mold existing processes
that will enable the initial concept to be translated
into reality.
z Ideas and Innovation - the ability to invite
creativeness even within a set of restrictions.
35
Marilyn Mantei Model
„ Democratic decentralized (DD). -- Does not have a
defined leader. “Task Coordinators” are appointed to
assure that a particular job is to be executed. These are
later replaced by other “Task Coordinators” as new tasks
arise.
„ Controlled decentralized (CD) -- Has a defined leader
who coordinates tasks, and secondary leaders who carry
out subtasks. Problem solving is done by the group,
implementation is done by subgroups.
„ Controlled Centralized (CC) - Top-
Top-level problem solving
and team coordination managed by the team leader.
The communication between the leader and members is
vertical.
36
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
z Who evaluates person for raises?
z Independence of reporting for safety & quality issues?
z Who is boss?

39 40
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. z Structured Analysis
„ Software management includes the people, the z Object-
Object-oriented analysis
problem, and the process.
„ Some important considerations
„ The most critical element in all software system
z Analysis products must be maintainable
projects is the people. The team can have an
number of structures that effect the way work is z Effective partitioning is essential
accomplished. z Graphics should be used whenever possible
„ However, complete, consistent problem z Distinguish between logical and implementation
definition and an effective process are also
essential ingredients. „ Separate presentations!
43 44
 Ž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:
z product metrics
CMIT 558:
z project metrics
Information Systems for Construction
Management z process metrics
„ Software Measurement
z size-
size-oriented metrics
z function-
function-oriented metrics
End of the short z metrics for Software Quality

version
46

Measure, Metrics, and Indicator Use of Software Metrics

„ Measure -- Provides a quantitative indication of
the extent, amount, dimensions, capacity, or
size of some product or process attribute (1000
lines)
„ Metrics -- A quantitative measure of the degree
to which a system, component, or process
possesses a given attribute (40%)
„ Software Metrics -- refers to a broad range of
measurements for computer software
„ Indicator -- a metric or combination of metrics
that provide insight into the software process, a
software project, or the product itself.
„ Use common sense and organizational sensitivity.
„ Provide regular feedback to individuals and teams.
„ Don’t use metrics to appraise individuals.
„ Set clear goal and metrics.
„ Never use metrics to threaten individuals or teams
„ Problems != negative. These data are merely an
indicator for process improvement.
„ Don’t obsess on a single metric to the exclusion of other
important metrics.
„ Do not rely on metrics to solve your problems.
„ Beware of people performing to metrics rather than
product quality or safety.
47 48
Typical Causes of Product
Defects
49
Measures of Software Quality:
Integrity and Usability
„ Integrity is a system’s ability to withstand
attacks (both accidental and intentional) on its
security
„ Usability - an attempt to quantify “user
friendliness” physical/intellectual requirement to
learn ...
z time required to become moderately efficient
z the net increase in productivity
z user attitudes toward system
51
Measures of Software Quality:
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:
z adapted if the environment changes
z enhanced if the customer desires changes in
requirements
z based on the time-
time-oriented measure mean time to
change.
50
Summary
„ Metrics are a tool which can be used to improve
the productivity and quality of the software
system
„ Process metrics takes a strategic view to the
effectiveness of a software process
„ Project metrics are tactical that focus on project
work flow and technical approach
„ Size-oriented metrics use the line of code as a
normalizing factor
„ Function-oriented metrics use function points
„ Quality metrics are correctness, integrity,
maintainability, and usability.
52
Software Project Planning Software Scope

Steps to Software Planning: What scope means:

„ Functions
„ Define Software Scope z Literally refers to all functions performed by a system
„ Determine Resources „ Performance
z Refers to processing and response time requirements
„ Create Project Estimates
„ Constraints
„ Make or buy decision
z Limits placed on the software by external hardware,
available memory or existing systems
z Interfaces
z Reliability

53 54

Scope Scope Information

„ Obtaining the information „ Some typical questions

„ Overall Goals
z Communication, communication, communication!!!
z Who’s request
z Meet with customer as often as needed. z What benefit
z Have free form discussion z Who else has solution
z Try to understand his/her goals/constraints, not just „ Understanding The Problem
what she/he thinks they want. z What output
z What Problem
„ Beware if ones provides detailed written z What Issues
specifications on what they want. z What Constraints
z The problem is that those writing them probably „ Effectiveness of Meeting
didn’t fully understand, and they will change. z Are answers official
z Are my questions relevant
z Other sources of Info.
55 56
Scoping - Subsequent Meetings Human Resources

„ Begin high level planning „ Scope and skills required

z Know the capabilities of existing software and staff
z Joint teams of customer and developers/analysts
z Checklist of items to cover
„ Organization of Information
z Get everything down with diagrams
z Create and save transcripts of Meetings
z Possibly use Web.
„ Organizational position and specialty must both
be considered
„ As estimate of development effort is essential to
determine the number of people required for the
project.

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
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 z optimistic
z Base estimates on similar projects z most likely
z Use simple decomposition (possibly in combination z pessimistic
with other methods
z Use one or more empirical models, I.e., „ Then combine as:
• For example # of people = LOC ÷(Duration*(LOC/PM))

LOC = line of code EV = (S

(Sopt + 4*S
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
z LOC and
z FP estimation
z or separately
„ If estimated separately, then there are two or three
„ Suppose:
distinct cost estimates
z 620 LOC/PM z Reconcile differences
z $8,000/PM z If radically different, perhaps
z 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
Summary Risk Management

„ Project planner must estimate three things: „ Introduction

z how long project will take „ Risk Identification
z how much effort will be required „ Risk Projection
z how many people will be required
„ Risk Mitigation, Monitoring, and
„ Must use decomposition and empirical modeling Management
z Most empirical techniques need to be calibrated to
„ Safety Risks and Hazards
individual situations.
z 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:
z Recall earlier questions raised about safety, costs, z Risk concerns future happenings
etc. z 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: z Risk involves choice, and the uncertainty that choice
z “possibility of loss or injury” itself entails
z “the chance of loss or the perils to the subject matter „ Risk Characteristics :
of an insurance contract” and z uncertainty: may or may not happen
z “the degree of probability of such loss.” z loss: unwanted consequences

67 68
Introduction Types of risk strategies

„ Management is „ Reactive „ Proactive

z Software team does z Begins long before
z “the act or art of managing” and
nothing about risks until technical work is initiated
z “judicious use of means to accomplish an end”(1) something goes wrong z Identification of potential
z “fire fighting mode” risks (studies of probability,
„ RISK MANAGEMENT can be defined as:
z At best, monitors the impact and priorities)
z “A logical process for identifying and analyzing projects for likely risks z Objective: AVOID RISK
leading to appropriate methods for handling and z Responds are in a
monitoring exposures to loss” controlled and effective
manner
„ Risk management deals with:
z Systematic identification of an exposure to the risk of
loss, &
z 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

z budgetary, schedule, personnel, resource, customer specify threats to the project plan
„ Technical Risks
z design, implementation, interfacing, verification Identify known and predictable risks

„ Business Risks Generic Product-specific

z market, strategic, management,budget ` Product size
` Business impact
` Customer characteristics

„ Risks may be: What characteristics of ` Process definition

this product may threaten` Development environment
our project plan? ` Technology to be built
z Known ` Staff size and experience
z Predictable
z Unpredictable „ Risk Item List
71 72
Risk Identification Product Size Risk :

„ product „ Estimated size of the product in LOC or FP?

„ Percentage deviation in size of product from average for
„ business
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?
„ Visibility of this product to senior management?
„ Amount & quality of product documentation to be
produced?
„ Governmental constraints on the construction of the
product?
„ Have you worked with the customer in the past?
„ Does the customer have a solid idea of what is
required?
„ Will the customer agree to have meetings?
„ Is the customer technically sophisticated in the
product area?
„ Does the customer understand the software
process?

75 76
Technology Risks: Process Risks
„ Does senior management support a written policy statement that
„ Is the technology to be built new to your
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?
„ Are quality/productivity metrics collected for all software projects?
projects?
77 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
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 70%
PS 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
z 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
z 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
Risk Matrix Risk Mitigation, Monitoring, and
Management
L „ An effective strategy must consider three issues:
5
I z risk avoidance,
z risk monitoring, and
k
4 z 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
z meet with current staff to determine causes for turnover
o
1 z assume turnover will occur and develop techniques to ensure
d
continuity when people leave.
1 2 3 4 5 z 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:
z general attitude of team members based on project pressures,
z the degree to which the team has jelled,
z interpersonal relationship among team members,
„ availability of jobs within the company and outside it
z In addition of these factors, the project manager should monitor
the effectiveness of risk mitigation steps. Risk management and
contingency planning assumes that mitigation efforts have failed
and that the risk has become reality.
„ Software safety and hazard analysis are
software quality assurance activities that focus
on the identification and assessment of potential
hazard that may impact software negatively and
cause an entire system to fail.
„ If hazards can be identified early in the software
engineering process, software design features
can be specified that will either eliminate or
control potential hazards.

87 88
SEI Risk Management Paradigm Summary

a Risk analysis is an important part of most software projects.

a) Identify a Risk analysis requires a significant amount of project
b) Analyze planning effort.
c) Plan
d) Track a Understanding risk helps you know where to commit your
e) Control resources.
f) Communicate
a If you don’t actively attack the risks, they will actively
attack you.
a Major projects should all have a risk management plan..

89 90