Lecture 1 Software Engineering Layers

Introduction to Software Engineering Tools->methods->process model->a “quality” focus

Software Definition
 Software is:  Tools: Software Tools (Word Processors, Diagramming
Tools, Project Tools, Compilers, etc.)
◦ A product
 Methods: Modeling methods (DFD, ERD, Gantt Chart,etc.)
◦ A vehicle for delivering another product
 Process: Waterfall, Spiral, Incremental, etc.
 Software is collection of:
◦ Program
Software Engineering Phases
◦ Documentation
 Definition Phase (What)
◦ Data Procedure
◦ Systems Engineering, Project Planning, Requirements
Analysis
Software Characteristics  Development Phase (How)
 Software is engineered, not manufactured
◦ Software Design, Code Generation, Software Testing
 Software does not wear out
 Support Phase (Change)
 Most software continues to be custom built
◦ Correction, Adaptation, Enhancement, Prevention
Failure Curves for software
Umbrella Activities
 Umbrella activities are activities that are applied throughout
the software process:
◦ Project tracking and control
◦ Software Quality Assurance
◦ Software Configuration Management
◦ Document Preparation and Management

Capability Maturity Model

Software Myths
 Myth: If we get behind schedule, add more programmers.
 Reality: Adding people to a late software project makes it
later.
 Myth: Software Engineering will make us create many and
unnecessary documentation.
 Reality: Software engineering is not about creating
documents. It is about creating quality. Better quality
leads to reduced rework. Reduced rework results in faster
delivery times.
Software Crisis
 During 1960-1970, most software development faced the
following problems:
◦ Overdue schedule
◦ Exceeding initial budget
◦ Inadequate software quality
◦ High software maintenance cost
Software Engineering
 Software engineering is first coined in 1968 at a software
conference organized by NATO at Garmisch, Germany as
a solution to the software crisis.
 Software engineering is the establishment and use of sound
engineering principles in order to obtain economically
software that is reliable and works efficiently on real
machines.
Engineering Principles
 The engineering principles used in software engineering
comprises: Analysis, Design, Implementation, Testing
 CMM is used to determine an organization’s current state
of process maturity
 Five levels of CMM:
◦ Level 1: Initial (Ad Hoc)
◦ Level 2: Repeatable (Basic project management)
◦ Level 3: Defined (Process standardization)
◦ Level 4: Managed (Quantitative Management)
◦ Level 5: Optimized (Continuous process improvement)
CMM Level 1: Initial
 The software process is characterized as ad hoc and
occasionally even chaotic. Few processes are defined, and
success depends on individual effort.
CMM Level 2: Repeatable
 Basic Project Management processes are established to track
cost, schedule, and functionality.
CMM Level 3: Defined
 The process is “tailored from the organization’s set of
standard processes according to the organization’s tailoring
guidelines, and contributes work products, measures, and
other process-improvement information to the organizational
process assets”.
CMM Level 4: Managed
 Detailed measures of the software process and product
quality are collected.
CMM Level 5: Optimized
 The process area is adapted and optimized using quantitative
means to meet changing customer needs and to continually
improve the efficacy of the process area under consideration.
Personal Software Process
 The Personal Software Process (PSP) emphasizes personal
measurement of both the work product that is produced and
the resultant quality of work product (Humphrey 1997).
 The PSP process model defined five framework activities:
◦ Planning, High-Level Design, High-Level Design Review,
Development. Postmortem.
 PSP stresses the need for each software engineer to identify
errors early and, as important, to understand the types of
errors that he/she is likely to make.
 This is accomplished through a rigorous assessment activity
performed on all work products produced by the software
engineer.
 PSP can improve the productivity and software quality.
However, PSP has not been widely adopted throughout the
industry due to human nature and organizational inertia.
Team Software Process (TSP)
 TSP is an extension of PSP.
 The goal of TSP is to build a “self-directed” project team
that organizes itself to produce high-quality software:
◦ Build self-directed teams that plan and track their work,
establish goals, and own their processes and plans.
◦ Show managers how to coach and motivate their teams.
◦ Accelerate software process improvement.
◦ Provide improvement guidance to high-maturity
organizations.
◦ Facilitate university teaching of industrial-grade team skills.
Summary
 Software Engineering is a discipline that integrates process,
methods, and tools for the development of computer
software.
 The Capability Maturity Model Integration (CMMI) is a
comprehensive process meta-model that describes the
specific goals, practices, and capabilities that should be
present in a mature software process.
 Personal and Team Software process emphasize
measurement, planning, and self-direction as key ingredients
for a successful software process.
Lecture 2
Software Development Methodologies
Software Process Model
 A software development methodology is chosen based on
the nature of the project and application, the methods and
tools to be used, and the controls and deliverables that are
required. Classical Waterfall Model, Iterative Waterfall
Model, Prototyping Model, Incremental Model, Spiral
Model.
Classical Waterfall Model
Feasibility Study
 Main aim of feasibility study:determine whether developing
the product
◦ financially worthwhile
◦ technically feasible.
 First roughly understand what the customer wants:
◦ different data which would be input to the system,
◦ processing needed on these data,
◦ output data to be produced by the system,
◦ various constraints on the behavior of the system.
Requirements Analysis and Specification
 Aim of this phase:
◦ understand the exact requirements of the customer,
◦ document them properly.
 Consists of two distinct activities:
◦ requirements gathering and analysis
◦ requirements specification
 Requirements are organized:
◦ into a Software Requirements Specification (SRS) document
Design
 Design phase transforms requirements specification:
◦ into a form suitable for implementation in some
programming language.
 In technical terms:
◦ during design phase, software architecture is derived from
the SRS document.
 Two design approaches:
◦ traditional approach,
◦ object oriented approach.
Implementation
 Purpose of implementation phase (aka coding and unit
testing phase): translate software design into source code.
 During the implementation phase:
◦ each module of the design is coded,
◦ each module is unit tested
 tested independently as a stand alone unit, and debugged,
◦ each module is documented.
 The purpose of unit testing:
◦ test if individual modules work correctly.
 The end product of implementation phase:
◦ a set of program modules that have been tested individually.
Integration and System Testing
 Different modules are integrated in a planned manner:
◦ modules are almost never integrated in one shot.
◦ Normally integration is carried out through a number of
steps.
 During each integration step,
◦ the partially integrated system is tested.
System Testing
 After all the modules have been successfully integrated and
tested: system testing is carried out.
 Goal of system testing:
◦ ensure that the developed system functions according to its
requirements as specified in the SRS document.
Maintenance
 Maintenance of any software product:
◦ requires much more effort than the effort to develop the
product itself.
◦ development effort to maintenance effort is typically 40:60.
Iterative Waterfall Model
 Classical waterfall model is idealistic:
◦ assumes that no defect is introduced during any development
activity.
◦ in practice:
 defects do get introduced in almost every phase of the life
cycle.
 Defects usually get detected much later in the life cycle:
◦ For example, a design defect might go unnoticed till the
coding or testing phase.
 Once a defect is detected:
◦ we need to go back to the phase where it was introduced
◦ Redo some of the work done during that and all subsequent
phases.
 Therefore we need feedback paths in the classical waterfall
model.
 Errors should be detected
◦ in the same phase in which they are introduced.
 For example:
◦ if a design problem is detected in the design phase itself,
 the problem can be taken care of much more easily
than say if it is identified at the end of the integration and
system testing phase
Phase containment of errors
 Reason: rework must be carried out not only to the design
but also to code and test phases.
 The principle of detecting errors as close to its point of
introduction as possible:
◦ is known as phase containment of errors.
 Iterative waterfall model is by far the most widely used
model.
◦ Almost every other model is derived from the waterfall
model.
Prototyping Model
 Before starting actual development,
◦ a working prototype of the system should first be built.
 A prototype is a toy implementation of a system:
◦ limited functional capabilities,
◦ low reliability,
◦ inefficient performance.
Reasons for developing a prototype
 Illustrate to the customer:
◦ input data formats, messages, reports, or interactive dialogs.
 Examine technical issues associated with product
development:
◦ Often major design decisions depend on issues like:
 response time of a hardware controller,
 efficiency of a sorting algorithm, etc.
 The third reason for developing a prototype is:
◦ it is impossible to ``get it right'' the first time,
◦ we must plan to throw away the first product
if we want to develop a good product.
 Start with approximate requirements.
 Carry out a quick design.
 Prototype model is built using several short-cuts:
◦ Short-cuts might involve using inefficient, inaccurate, or
dummy functions.
 A function may use a table look-up rather than performing
the actual computations.
 The developed prototype is submitted to the customer for his
evaluation:
◦ Based on the user feedback, requirements are refined.
◦ This cycle continues until the user approves the prototype.
 The actual system is developed using the classical waterfall
approach.
 Requirements analysis and specification phase becomes
redundant:
◦ final working prototype (with all user feedbacks
incorporated) serves as an animated requirements
specification.
 Design and code for the prototype is usually thrown away:
◦ However, the experience gathered from developing the
prototype helps a great deal while developing the actual
product.
 Even though construction of a working prototype model
involves additional cost --- overall development cost might
be lower for:
◦ systems with unclear user requirements,
◦ systems with unresolved technical issues.
 Many user requirements get properly defined and technical
issues get resolved:
◦ these would have appeared later as change requests and
resulted in incurring massive redesign costs.
Evolutionary Model
 Evolutionary model (aka successive versions or incremental
model):
◦ The system is broken down into several modules which can
be incrementally implemented and delivered.
 First develop the core modules of the system.
 The initial product skeleton is refined into increasing levels
of capability:
◦ by adding new functionalities in successive versions.
 Successive version of the product:
◦ functioning systems capable of performing some useful
work.
◦ A new release may include new functionality:
 also existing functionality in the current release might have
been enhanced.
Advantages of Evolutionary Model
 Users get a chance to experiment with a partially developed
system:
◦ much before the full working version is released,
 Helps finding exact user requirements:
◦ much before fully working system is developed.
 Core modules get tested thoroughly:
◦ reduces chances of errors in final product.
Disadvantages of Evolutionary Model
 Often, difficult to subdivide problems into functional units:
◦ which can be incrementally implemented and delivered.
◦ evolutionary model is useful for very large problems,
 where it is easier to find modules for incremental
implementation.
Evolutionary Model with Iteration
 Many organizations use a combination of iterative and
incremental development:
◦ a new release may include new functionality
◦ existing functionality from the current release may also have
been modified.
Evolutionary Model with iteration
 Several advantages:
◦ Training can start on an earlier release
 customer feedback taken into account
◦ Markets can be created:
 for functionality that has never been offered.
◦ Frequent releases allow developers to fix unanticipated
problems quickly.
Spiral Model
 Proposed by Boehm in 1988.
 Each loop of the spiral represents a phase of the software
process:
◦ the innermost loop might be concerned with system
feasibility,
◦ the next loop with system requirements definition,
◦ the next one with system design, and so on.
 There are no fixed phases in this model, the phases shown in
the figure are just examples.
 The team must decide:
◦ how to structure the project into phases.
 Start work using some generic model:
◦ add extra phases
 for specific projects or when problems are identified during a
project.
 Each loop in the spiral is split into four sectors (quadrants).
Objective Setting (First Quadrant)
 Identify objectives of the phase,
 Examine the risks associated with these objectives.
◦ Risk:
 any adverse circumstance that might hamper successful
completion of a software project.
 Find alternate solutions possible.
Risk Assessment and Reduction (Second Quadrant)
 For each identified project risk,
◦ a detailed analysis is carried out.
 Steps are taken to reduce the risk.
 For example, if there is a risk that the requirements are
inappropriate:
◦ a prototype system may be developed.
Spiral Model (CONT.)
 Development and Validation (Third quadrant):
◦ develop and validate the next level of the product.
 Review and Planning (Fourth quadrant):
◦ review the results achieved so far with the customer and
plan the next iteration around the spiral.
 With each iteration around the spiral:
◦ progressively more complete version of the software gets
built.
Spiral Model as a meta model
 Subsumes all discussed models:
◦ a single loop spiral represents waterfall model.
◦ uses an evolutionary approach --
 iterations through the spiral are evolutionary levels.
◦ enables understanding and reacting to risks during each
iteration along the spiral.
◦ uses:
 prototyping as a risk reduction mechanism
 retains the step-wise approach of the waterfall model.
Comparison of Life Cycle Models
 Iterative waterfall model
◦ most widely used model.
◦ But, suitable only for well-understood problems.
 Prototype model is suitable for projects not well understood:
◦ user requirements
◦ technical aspects
 Evolutionary model is suitable for large problems:
◦ can be decomposed into a set of modules that can be
incrementally implemented,
◦ incremental delivery of the system is acceptable to the
customer.
 The spiral model:
◦ suitable for development of technically challenging software
products that are subject to several kinds of risks.
Summary
 Software engineering is:
◦ systematic collection of decades of programming experience
◦ together with the innovations made by researchers.
 A fundamental necessity while developing any large
software product:
◦ adoption of a life cycle model.
 Adherence to a software life cycle model:
◦ helps to do various development activities in a systematic
and disciplined manner.
◦ also makes it easier to manage a software development
effort.
Lecture 3
Project Management Concepts
Introduction
 Software Project Management is an umbrella activity within
software engineering.
 Effective software project management focuses on the four
P’s: People, Product, Process, Project.
The People
 The people management maturity model defines the
following key practice areas for software people:
◦ Recruiting
◦ Selection
◦ Performance management
◦ Training
◦ Compensation
◦ Career Development
◦ Organization and work design
◦ Team/culture development
The Product
 The product management encompasses:
◦ Establishing objectives and scope
◦ Considering alternative solutions
◦ Identifying technical and management constrains
 Problem decomposition (Partitioning) is applied in two
major areas:
◦ The functionality that must be delivered.
◦ The process that will be used to deliver it.
The Process
 The process management comprises the choice of framework
(waterfall, spiral, etc.) to be used throughout the project,
depending on the nature of the system to be developed.
 A small number of framework activities are applicable to all
software projects, regardless their size or complexity (task,
milestones, work products, and quality assurance points).
 Umbrella activities (SQA, SCM, measurements) are
independent of any one framework activity and occur
throughout the process.
The Project
 Planning and controlling software project is the only way to
manage complexity.
 In 1998, industry data indicated that:
◦ 26% software project failed.
◦ 46% experienced cost and schedule overruns.
 To avoid project failure, a software project manager must:
◦ Avoid a set of common warning signs
◦ Understand the critical success factors for good management
◦ Develop common sense for planning, monitoring and
controlling the project
Project Team Structure
 Mantei (1981) suggests three generic team organizations:
◦ Democratic decentralized (DD)
No permanent leader, short duration coordination, group
decision making, horizontal communication, suits difficult
problems
◦ Controlled decentralized (CD) ◦ What will be done?
Defined leader, group decision making, horizontal and ◦ By When?
vertical communication, suits simple problems ◦ Who is responsible for a function?
◦ Controlled centralized (CC) ◦ Where are they organizationally located?
Team leader decision making, vertical communication, suits ◦ How to do the job technically and managerially?
simple problems (Fast) ◦ How much resource?

Project Team Structure Summary

 Constantine (1993) suggests four organizational paradigms
for software engineering teams:
◦ A closed paradigm uses traditional hierarchy of authority,
suitable for projects similar to past efforts.
◦ A random paradigm structures a team loosely, suitable for
innovation / technological breakthrough.
◦ An open paradigm combination between closed and random
paradigm, well suited for complex problems, but not as
efficient as those two.
◦ A synchronous paradigm organized team members to work
on pieces of the problem with little communication among
themselves.
 Software Project Management is an umbrella activity within
software engineering.
 The 4 P’s have substantial influence on software project
management:
◦ People must be organized into effective teams.
◦ Product requirements must be well communicated and
decomposed.
◦ Process must be adapted to the people and the problem.
◦ Project must be organized in a manner that enables the
software team to succeed.
 The project management activity encompasses measurement,
estimation, risk analysis, scheduling and tracking.

Chief Programmer Team Lecture 4

 Chief Programmer Team is one of the earliest software team Software Metrics
organization, using a closed paradigm structure, composed Why do we Measure?
of: To characterize, To evaluate, To predict,To improve
◦ A senior engineer (the chief programmer)
 Plans, coordinates, reviews all technical activities.
◦ Technical staff (2-5 people)
 Conducts analysis and development activities.
◦ A backup engineer
 Supports the senior engineer in his/her activities.
 The chief programmer may be served by one or more
specialists (e.g. telecommunication expert, database
designer), support staff (e.g. technical writers), and a
software librarian.

A high performance team

 To achieve a high-performance team:
◦ Team members must have trust in one another A Good Manager Measures
◦ Skill distribution must be appropriate to the problem Process Metrics
◦ Mavericks may have to be excluded from the team.  majority focus on quality achieved as a consequence of a
 A jelled team is a group of people so strongly knit that the repeatable or managed process
whole is greater than the sum of the parts.  statistical SQA data
◦ error categorization & analysis
Guidelines for a successful software project  defect removal efficiency
 Start on the right foot ◦ propagation from phase to phase
 Maintain momentum  reuse data
 Track progress
 Make smart decisions Project Metrics
 Conduct a postmortem analysis  Effort/time per SE task
 Errors uncovered per review hour
The W5HH Principle  Scheduled vs. actual milestone dates
 Boehm (1996) suggests an approach that addresses project  Changes (number) and their characteristics
objectives, milestones, and schedules, responsibilities,  Distribution of effort on SE tasks
management and technical approaches, and required
resources: Product Metrics
◦ Why is the system being developed?  focus on the quality of deliverables
 measures of analysis model
 complexity of the design
◦ internal algorithmic complexity
◦ architectural complexity
◦ data flow complexity
 code measures (e.g., Halstead)
 measures of process effectiveness
◦ e.g., defect removal efficiency

Metrics Guidelines Computing Function Points

 Use common sense and organizational sensitivity when
interpreting metrics data.
 Provide regular feedback to the individuals and teams who
have worked to collect measures and metrics.
 Don’t use metrics to appraise individuals.
 Work with practitioners and teams to set clear goals and
metrics that will be used to achieve them.
 Never use metrics to threaten individuals or teams.
 Metrics data that indicate a problem area should not be
considered “negative.” These data are merely an indicator
for process improvement.
 Don’t obsess on a single metric to the exclusion of other
important metrics.

Normalization for Metrics

Typical Size-Oriented Metrics Analyzing the Information Domain

 errors per KLOC (thousand lines of code)
 defects per KLOC
 $ per LOC
 page of documentation per KLOC
 errors / person-month
 LOC per person-month
 $ / page of documentation

The LOC-based Estimation (p. 128)

 Determining the major software functions
 Develop an estimation table based on historical data
 An Example: Taking Complexity into Account
Estimated lines of code (total): 33,200 LOC
Average productivity: 620 LOC / pm
Labor rate: $8000 per month
Cost per LOC: $13 (8000 / 620)
Total estimated project cost: $431,000 (13 x 33200)
Estimated effort: 54 pm (33200 / 620)

Typical Function-Oriented Metrics

 errors per FP (thousand lines of code)
 defects per FP
 $ per FP
 pages of documentation per FP
 FP per person-month FP-based Estimation (p. 129)
 Estimating the information domain values (input, output,
Why Opt for FP Measures? inquiries, files, external interfaces), calculating the count-
total
 Calculating the complexity adjustment factor  Schedule—how do we allocate resources along the timeline?
(0.65 + 0.01 x S Fi) what are the milestones?
 FP estimated = count-total x complexity adjustment factor.  Control strategy—how do we control quality? how do we
 An Example: control change?
Estimated FP (total): 375 FP
Average productivity: 6.5 FP / pm To Understand Scope ...
Labor rate: $8000 per month  Understand the customers needs
Cost per FP: $1230 (8000 / 6.5) Functions estimated LOC LOC/pm $/LOC Cost Effort (months)
Total estimated project cost: $461,000 (375 x 1230) UICF 2340 315 14 32,000 7.4
Estimated effort: 58 pm (375 / 6.5) 2DGA 5380 220 20 107,000 24.4
Measuring Quality 3DGA 6800 220 20 136,000 30.9
 Correctness — the degree to which a program operates DSM 3350 240 18 60,000 13.9
according to specification CGDF 4950 200 22 109,000 24.7
 Maintainability—the degree to which a program is amenable PCF 2140 140 28 60,000 15.2
to change DAM 8400 300 18 151,000 28.0
 Integrity—the degree to which a program is impervious to
Totals 33,360 655,000 145.0
outside attack
 Usability—the degree to which a program is easy to use  understand the business context
 understand the project boundaries
Defect Removal Efficiency  understand the customer’s motivation
 understand the likely paths for change

Cost Estimation

Summary
 Measurement enables managers and practitioners to improve
the software process; assist in the planning, tracking, and
control of a software project; and assess the quality of the
product (software) that is produced. Estimation Techniques
 Both size and function oriented metrics are used throughout  past (similar) project experience
the industry.  conventional estimation techniques
◦ Size oriented metrics use the LOC. ◦ task breakdown and effort estimates
◦ Function oriented metrics use the information domain and a ◦ size (e.g., FP) estimates
subjective assessment of problem complexity.  tools (e.g., Checkpoint)

Lecture 5 Functional Decomposition

Software Project Planning
Software Project Planning

Creating a Task Matrix

The Steps
 Scoping—understand the problem and the work that must be
done
 Estimation—how much effort? how much time?
 Risk—what can go wrong? how can we avoid it? what can
we do about it?
  you've arrived at an estimate, sleep on it
 adjust for the people who'll be doing the job—they have the
highest impact

Computing Expected Cost

Conventional Methods:
LOC/FP Approach Summary
 compute LOC/FP using estimates of information domain  The software project planner must estimate three things
values before a project begins:
 use historical effort for the project ◦ How long it will take.
◦ How much effort will be required.
Example: LOC Approach ◦ How many people will be involved.
 Accurate project estimates generally use at least two
estimation techniques in order to derive an accurate estimate.

Lecture 6
Risk Management
Example: FP Approach Reactive vs. Proactive Risk Strategies
measurement parameter count weight  Reactive:
number of user inputs 40 x 4 = 160 ◦ The software team does nothing about risks until something
number of user outputs 25 x 5 = 125 goes wrong.
number of user inquiries 12 x 4 = 48  Proactive:
number of files 4 x 7 = 28 ◦ The software team establishes a plan for managing risk.
0.25 p-m / FP = 120 p-m
number of ext.interfaces 4 x 7 = 28 ◦ The primary objective is to avoid risk.
algorithms 60 x 3 = 180 ◦ The team develop a contingency plan as a respond in case a
569
count-total risk can not be avoided.
complexity multiplier .84
478
feature points Risk Characteristics
 Uncertainty: The risk may or may not happen; that is, there
are no 100% probable risks.
Tool-Based Estimation
 Loss: If the risk becomes a reality, unwanted consequences
 project characteristics or losses will occur.
 calibration factors
 LOC/FP data
Categories of risks
 Project Risks: threatens project plan
Empirical Estimation Models
e.g. overdue schedule, increased budget.
 Technical Risks: threatens software quality
e.g. difficult / impossible implementation.
 Business Risks: threatens software viability
e.g. market risk, strategic risk, management risk, budget risk.

Another categorization of risks (Charette. 1989)

 Known risks: uncovered after careful evaluation of the
software project (unrealistic delivery date, lack of
documented requirements or software scope).
 Predictable risks: extrapolated from past project experience
Estimation Guidelines (staff turnover, poor customer communication).
 estimate using at least two techniques  Unpredictable risks: risks that are extremely difficult to
 get estimates from independent sources identify in advance, but they can and do occur.
 avoid over-optimism, assume difficulties
Stages of Risk Management Risk Table
 Risk Identification
 Risk Impact Assessment
 Risk Projection
 Building a Risk Table
 Determine Cutoff Line
 Develop RMMM Plan

Risk Identification
 Risk identification is a systematic attempt to specify threats
to the project plan (estimates, schedule, resource loading,
RMMM Plan
etc.).
 Once the first four columns of the risk table have been
 There are two distinct types of risks for each of the
completed, the table is sorted by probability and by impact.
categories previously presented:
 High probability, high impact risks are located at the top of
◦ Generic risks: a potential threat to every software project
the table.
◦ Product-specific risks: depends on the technology, people,  The project manager then defines a cutoff line, indicating
and the environment specific to the project that only risks that lie above the line will be given further
attention.
Risk Item Checklist  All risks that lie above the cutoff line must be managed, by
 Risk Item Checklist is one method for identifying risks. developing the RMMM plan.
 Generic risk subcategories:
◦ Product Size (PS) Risk Mitigation, Monitoring, and Management
◦ Business Impact (BU)
◦ Customer Characteristics (CU)  Risk Mitigation / Risk Avoidance
◦ Process Definition (PR) ◦ The software team adopts a proactive approach to risk.
◦ Development Environment (DE) ◦ Avoidance is always the best strategy.
◦ Technology to be built (TE)  Risk Monitoring
◦ Staff Size and Experience (ST) ◦ The project manager monitors factors that may provide an
indication of whether a risk is becoming more or less likely.
Risk Impact Assessment  Risk Management and contingency planning
 The impact of risks is divided into one of four impact ◦ Assumes that mitigation efforts have failed and that the risk
categories: has become reality
◦ Catastrophic: schedule delay, cost increase, project failure. An Example of RMMM
◦ Critical: schedule delay, cost increase, but not as high as the  Project Risk: High staff turnover
first one.  Probability: 70%
◦ Marginal: possible cost increase and schedule delay, but  Impact: 2 (Critical)
recoverable.  Mitigation: improve working environment, increase salary.
◦ Negligible: no effect to cost and schedule.  Monitoring: monitor the team member general attitude,
member interpersonal relationships.
 Management: assign backup team member.

Risk Projection Summary

 Risk Projection (Risk estimation) attempts to rate each risk
in two ways:
◦ The probability that risk is real.
◦ The consequences of the problems associated with the risk,
should it occur.
 When a lot is riding on a software project, common sense
dictates risk analysis.
 Risk Analysis can absorb a significant amount of project
planning effort. But the effort is worth it.
 Sun Tzu (500 BC) said, “If you know the enemy and know
yourself, you need not fear the result of a hundred battles.”
For the project manager, the enemy is risk.

SCRUM

Scrum building block disebut Sprint. Sprint adalah sebuah
kotak-waktu (yang biasanya mempunyai durasi 1 hingga 4
minggu) dimana tim pengembang fokus dalam mencapai
target yang jelas. Setiap Sprint selalu berakhir dengan
diikuti Sprint Review, dimana hasil yang sudah dibuat
dipresentasikan dan didemontrasikan didalam sebuah rapat
tim.
Istilah-istilah dalam Scrum
Product Backlog
Pemilik Proyek menyusun dan mengumpulkan semua
permintaan dan kebutuhan sistem, misalnya fitur-fitur yang
dibutuhkan dan-atau kebutuhan non-fungsional sistem. Setelah
tujuannya sudah ditetapkan, semua permintaan dan kebutuhan
tersebut dibagi-bagi menjadi bagian-bagian kecil yang mana
setiap bagian kecil tersebut harus mempunyai nilai dan layak
untuk dikembangkan..
Pemilik Proyek juga menentukan skala prioritas dalam
pengerjaan bagian-bagian kecil tersebut. Bagaimana dan
seperti apa bagian-bagian kecil tersebut diimplementasikan
dan di-deliver?
Pertanyaan tersebut akan menghasilkan sebuah to-do-list
berdasarkan kebutuhan pasar dan kebutuhan pelanggan yang
selalu berubah seiring dengan berjalannya waktu.
Backlog Refinement
Backlog harus di-maintain dengan baik dan tepat oleh Tim
Scrum untuk dilakukan perencanaan, sehingga Sprint dapat
berjalan dengan lancar. Hal-hal yang harus dilakukan dalam
me-maintain backlog antara lain adalah melakukan proses
estimasi dan breakdown kebutuhan, Hal tersebut dilakukan
agar kondisi Sprint (1-4 minggu) terpenuhi.
Sprint
Sprint adalah kotak-waktu yang berisi periode kerja dimana
pada sprint fokus terhadap delivery produk berdasarkan item-
item yang dipilih dari Product Backlog.
Didalam Sprint selalu ditetapkan waktu pekerjaan secara
konsisten dan Sprint yang baru dimulai sesegera mungkin
setelah sprint yang ada telah selesai dikerjakan.
Daily Scrum
Setiap hari, Tim Scruam harus melakukan pertemuan (rapat)
selama maksimal 15 menit. Hal ini dilakukan dengan tujuan
untuk mensinkronkan progres, mengidentifikasi masalah dan
menyelesaikan masalah yang ada dalam mengerjakan
pekerjaannya.
Pertanyaan yang biasa ditanyakan adalah :
 Apa yang anda lakukan sejak pertemuan terakhir ?
 Apa rencana yang anda lakukan sampai pertemuan
berikutnya ?
 Apa ada suatu masalah yang membuat anda tidak dapat
mengerjakan pekerjaan yang telah direncanakan sebelumnya
?
Pertanyaan ketiga digunakan untuk mencari solusi dari
permasalahan yang muncul. Mulai dari pertanyaan yang
bersifat teknis hingga non-teknis yang dinilai dapat
mengacaukan pekerjaan.
Sprint Review
Setiap Sprint selalu berakhir dengan mendemontrasikan dan
mempresentasikan fitur-fitur yang telah dikerjakan. Hal
tersebut dilakukan untuk memastikan bahwa fitur-fitur
tersebut dapat bekerja dengan baik.
Sprint Retrspective
Didalam Sprint Retrspective, Tim Scrum merefleksikan
bagaimana pekerjaan-pekerjaan berjalan pada Sprint
sebelumnya?
Harapan yang ingin dicapai pada Sprint Retrspective adalah
adanya perbaikan tindakan sehingga Sprint berikutnya dapat
dikerjakan dengan lebih baik lagi.
Perbaikan-perbaikan tersebut harus di-implementasi-kan pada
Sprint berikutnya.
ROLES
Development Team
Development team atau tim pengembang adalah team yang
mendesain dan melakukan proses problem-solvers. Biasanya
team tersebut terdiri dari 3-9 orang.
3-9 orang adalah team yang paling optimal dalam
menggunakan metode scrum berdasarkan beberapa penelitian
yang ada.
Pembagian tugas dan distribusi informasi ditentukan diantara
anggota tim itu sendiri. Setiap anggota tim bertanggungjawab
atas keberhasilan keluaran sprint yang dilakukan.
Product Owner
Product Owner atau pemilik proyek harus memastikan bawha
tim pengembang bekerja sesuai dengan target yang telah
ditetapkan dilihat dari kacamata bisnis.
Pemilik proyek melakukan manajemen terhadap Product
Backlog, yang dibreakdown menjadi to-do-list, sehingga
semua keinginan dan kebutuhan sistem dapat terekam dengan
baik berdasarkan keuntungan yang diterima dengan
mempertimbangkan sisi bisnisnya.
Pemilik proyek fokus pada bagaimana produk dihasilkan
nantinya. Selain itu pemilik proyek juga harus selalu melihat
berapa banyak dana yang dikeluarkan dalam mengembangkan
produk dan seberapa besar pendapatan yang dihasilkan oleh
produk tersebut.

Scrum Master
Scrum master atau tenaga ahli Scrum adalah kombinasi dari
pelatih, fixer dan penjaga gawang.
Hal yang paling penting dari Scrum Master adalah, Scrum
Master harus dapat mengarahkan dan melatih Tim
Pengembang dan Pemilik Proyek untuk memastikan bahwa
mereka selalu berada dalam kondisi terbaiknya dalam meraih
kesuksesan.
Scrum Master memimpin rapat setiap harinya - Daily Scrum.
Scrum master harus memastikan bahwa tim pengembang tidak
teralihkan fokusnya pada hal-hal diluar proyek/pekerjaan.

Scrum Team
Scrum Team atau Tim Scrum adalah gabungan dari Tim
Pengembang, Pemilik Proyek dan Tenaga Ahli Scrum.