Software Quality Management

1
Software Quality Management

• Software Quality
• SEI - Capability Maturity Model

2
ISO 9126 SW quality characteristics

• Functionality Suitability
• Accuracy
• Interoperability
• Functionality compliance
• Security
• Relaibility Maturity
• Fault tolerance
• Recoverability
• Reliability compliance

3
ISO 9126 SW quality characteristics

• Usability Understandability
• Learnability
• Operability
• Attractiveness
• Usability compliance
• Efficiency Time behavior (Response time)
• Resources utilization
• Efficiency compliance

4
ISO 9126 SW quality characteristics

• Maintainability Analysability
• Changeability
• Stability
• Testability
• Maintability compliance
• Portability Adaptability
• Installability
• Co-existence
• Replaceability
• Portability compliance

5
Product vs process quality

• Entry requirements
• Implementation requirements
• Exit requirements

6
Techniques to enhance SW quality

• Inspections
• Remove superficial errors
• Motivates developers
• Spread good programming practices
• Enhance team spirit
• Clean Room
• Formal Methods
• SW quality circles

7
History

• In the 1980s, realization about the inability to
  manage the software process
• Projects late, over budget, or plain failures
• 1986-1987 Software Engineering Institute (SEI)
• Began developing a process maturity framework
• 1991 CMM-SW 1.0
• 1993 CMM-SW 1.1

8
An Example Process RUP
Development Process
Consists of
Management
produce
Phases
Artifacts
monitor
has
end with
Iterations
Release
focus
Engineers
Use
Workflows
The Rational Unified Process Model
9
Structure of CMM
Goals
Maturity Level
indicate
contain
achieve
Key PA
Infrastructure/ Activities
Process Capability
organized by
Common Features
describe
Implementation
address
contain
Key Practices
10
Maturity Levels

• Initial
• No process, Ad-hoc response
• Repeatable
• Disciplined Process
• Defined
• Standard, Consistent Process
• Managed
• Predictable Process
• Optimizing
• Continuous Improvements

11
Structure of CMM
Maturity Level
indicate
contain
Process Capability
Key PA
organized by
achieve
Goals
Common Features
address
contain
Implementation
Key Practices
describe
Infrastructure/ Activities
12
Level 1 - Key Process Areas

• None that can be observed

13
Level 2 - Key Process Areas

• Software configuration management
• Software quality assurance
• Software subcontract management
• Software project tracking and oversight
• Software project planning
• Requirements management

14
Level 3 - Key Process Areas

• Peer reviews
• Inter-group coordination
• Software product engineering
• Integrated software management
• Training program
• Organization process definition
• Organization process focus

15
Level 4 - Key Process Areas

• Quality management
• Process measurement
• Software quality management
• Quantitative process management

16
Level 5 - Key Process Areas

• Process change management
• Technology change management
• Defect prevention

17
Software Maturity An Overview

• Just to sum up again
• Initial (No process, Ad-hoc response)
• Repeatable (Disciplined Process)
• Defined (Standard, Consistent Process)
• Managed (Predictable Process)
• Optimizing (Continuous Improvements)

18
ISO 9001 Vs CMM

• Almost all concerns raised by ISO 9001 are
  encompassed by CMM.
• ISO 9001 describes the minimum criteria for
  adequate quality management systems - rather than
  process improvement. CMM address process
  improvement as well as provides a clear path to
  achieving it.
• CMM provides more detailed guidance and greater
  breadth provided to software organizations.
• Building competitive advantage should be focused
  on improvement, not on achieving a score (which
  is the primary focus of ISO 9001).

19
Software Configuration Management
20
Types of Changes

• The typical distribution of these changes is
  (from Lientz Swanson 1981)
• Perfective (50)
• Adaptive (25)
• Corrective (21)
• Preventive (4)
• These figures will change depending on the system
  and project

21
Facets of SCM

• The four core aspects of SCM are
• Configuration identification
• Configuration control and change management
• Configuration auditing
• Status accounting

22
Version Allocation

• Examples
• Report.Java (version 1.23)
• Major version 1.0
• Minor version 23 (indicative of number of
  revisions to this file)
• Project plan (version 6.34d)
• Major version 6
• Minor version 34
• The d is indicative of draft
• Versioning scheme is developed by the company to
  suite their needs

23
Terminology Review 3

• Version an initial release or re-release of a
  configuration item (ideally different versions
  should have different functionality)
• Revision minor changes to a version that
  correct errors in the design/code (typically
  revisions do not affect expected functionality)
• Release the formal distribution of a baseline

24
Configuration Management

• To ensure proper tracking the following
  information needs to be collected
• When was the change made
• Who made the change
• What was changed (items modified)
• Who authorized the change and who was notified
• How can this request be cancelled
• Who is responsible for the change
• Priority and severity
• How long did the change take (vs estimate)

25
Configuration Auditing 1

• Key philosophy is trust by verify
• Configuration auditing is a process to
• Verify that the baseline is complete accurate
• Check that changes made and recorded
• Documentation reflects updates
• Audits can be rigorous, or on a random set of
  configuration items
• A regular audit is required to ensure that SCM is
  working efficiently
• Can reveal weaknesses in processes, tools, plans
  as well as resources

26
Status Accounting

• Simple record that can identify all items under
  SCM
• Location of the component, who placed it under
  SCM etc
• The current version
• Revision history (change log)
• Pending CRs
• Impact analysis trends
• Status accounting is vital to enable control and
  effective management

27
Keywords

• Configuration item
• Version
• Baseline
• Release
• Revision
• Change management
• Configuration management

28
Software Processes
29
Yazilim Süreci ile Ilgili Standartlar
29
30
Generic software process models

• The waterfall model
• Separate and distinct phases of specification and
  development.
• Evolutionary development
• Specification, development and validation are
  interleaved.
• Component-based software engineering
• The system is assembled from existing components.
• There are many variants of these models e.g.
  formal development where a waterfall-like process
  is used but the specification is a formal
  specification that is refined through several
  stages to an implementable design.

31
Waterfall model
32
Evolutionary development
33
Evolutionary development

• Problems
• Lack of process visibility
• Systems are often poorly structured
• Special skills (e.g. in languages for rapid
  prototyping) may be required.
• Applicability
• For small or medium-size interactive systems
• For parts of large systems (e.g. the user
  interface)
• For short-life time systems.

34
Component-based software engineering

• Based on systematic reuse where systems are
  integrated from existing components or COTS
  (Commercial-off-the-shelf) systems.
• Process stages
• Component analysis
• Requirements modification
• System design with reuse
• Development and integration.
• This approach is becoming increasingly used as
  component standards have emerged.

35
Reuse-oriented development
36
Process iteration

• System requirements ALWAYS evolve in the course
  of a project so process iteration where earlier
  stages are reworked is always part of the process
  for large systems.
• Iteration can be applied to any of the generic
  process models.
• Two (related) approaches
• Incremental delivery
• Spiral development.

37
Incremental delivery

• Rather than deliver the system as a single
  delivery, the development and delivery is broken
  down into increments with each increment
  delivering part of the required functionality.
• User requirements are prioritised and the highest
  priority requirements are included in early
  increments.
• Once the development of an increment is started,
  the requirements are frozen though requirements
  for later increments can continue to evolve.

38
Incremental development
39
Spiral development

• Process is represented as a spiral rather than as
  a sequence of activities with backtracking.
• Each loop in the spiral represents a phase in the
  process.
• No fixed phases such as specification or design -
  loops in the spiral are chosen depending on what
  is required.
• Risks are explicitly assessed and resolved
  throughout the process.

40
Spiral model of the software process
41
Requirement Management Tools
Ilgili gereksinim dokümani (SRS) seçildikten
sonra, o SRSin templatei açilir, ve üzerinde
düzeltmeler yapilip, menüden Generate Report ile
doküman üretilir.
42
Test Senaryosu
43
Satinalma Fonksiyon Agaci (Functional
Decomposition)
Satinalma
Ana Veri Ynt.
Ihtiyaçlar
Satinalma Siparisi
Teslimat
Fatura Kontrolü
Siparisin Yaratilmasi
Mlz.Iht.Hes.
Mal Girisi
Satici
Fatura Bilgileri Kontrolü
ERA
Siparisin Gönderilmesi
Demand- based
Girdi Kalite Kontrolü
Malzeme
Faturanin Iliskilendirilmesi (Posting)
Letter/telefax
Con- sumption- based
Supplier Terms
Depoya Transfer
E-mail
Üretim Hatti Talebi
Satici Kotasi
Siparisin Izlenmesi
Satinalma Dokümani
Sürekli sistemin daha detayda NE yapacagi
sorularak, fonksiyonlarin atomik seviyeye
(transaction) indirgenmesidir. Asil
fonksiyonlara odaklanmak için kontrol
noktalarinda çikan farkli kosullar/istisnai
durumlar bu detayda yer almaz. (Örn. girdi kalite
kontrol sonucunun negatif olmasi durumu )
Kisaltmalar ERA Entity-Relationship Analysis
44
ERA (Entity-Relationship Analysis)
Satici No.
Org.Birim No.
Mlz. No.
Satici
Org. Birim
Satinalma Ihtiyaci
Satici No. Mlz. No.
CC No.
Satici Kotasi
Cost Center
Dok.No. Dok.Yayin Tarihi Satici No. Org.Birim
No. Satinalma No. Satinalma Tarihi
Satinalma Dokümani
Mlz. No.
Malzeme
Satinalma Talebi
Satinalma Siparisi
Satici No. Satinalma No.
Fatura
Supplier Terms
Hesap Kodu
Teslimat (Envanter)
Satinalma No. Teslimat Tarihi
COB No.
Cost Objective
Hesap Kodu
Kalite Kontrol Plani
Hesap Plani
Depo

• Satici hesabi
• Envanter hesabi
• (depolanan mlz., duran varlik)
• Harcama hesabi
• (sarf mlz., hemen kullanima verilen mlz.)

Mlz. Seri No.
45
Ihtiyaç hesaplamasi sonuçlari geldi
Üretim hattindan ihtiyaç talebi geldi
Ihtiyaç hesaplamasi sonuçlari
Consumption based
V
Demand based
Satinalma talebinin ilgili genel muhasebe ve
maliyet muhasebesi kalemleriyle iliskilendirilmesi
Process purchasing requisition,account
coding (CC, COB)
Satinalma is akisi (süreci)
V
Kota var (güncel)
Quotes Up-to-date
New quote necessary
Ek kota ihtiyaci var
Supplier inquiries
Ek kota talebinin yapilmasi
Sürekli NE ve NEDEN sorulari sorularak,
fonksiyonlarin mantiksal bir akis halinde kontrol
ve entegrasyon noktalarini da içerecek sekilde
detaylandirilmasi.
Solicited Quotes received
Ek kota alindi
Temel kota bilgilerinin güncellenmesi
Update basic data
Basic data updated
Temel bilgiler güncellendi
V
Siparis edilecek miktarin girilmesi, ilgili
muhasebe kayitlarinin (borç olarak) güncellenmesi
, proforma fatura bilgilerinin girilmesi
Stipulation of supplier and order
quantityaccount codes, accounts payablegeneral
ledger accountwriting of proforma invoice
Satinalma bilgileri hazir
Purchase data provided
Siparisin geçilmesi (mektup, fax, e-mail vb.)
Order writing transmission
Siparis satici tarafindan teyit edildi
Order confirmation by supplier
46
Order monitoring
Siparisin izlenmesi
V
Teslim zamani geçti
Schedule delivery deadline exceeded
Satinalma is akisi (süreci)
Generate past due notice
Teslim zamaninin geçtigi bildirimi
V
Outsourced resources received
Teslimat alindi
?
V
Teslimat bilgilerinin girilmesi
Posting receivings
Quality inspection
Kalite kontrolü
Posting completed
Invoice received
V
Inspection o.k.
Inspection not o.k.
?
Fatura alindi
Kalite kontrolü tamam
Fatura kontrolü
Uymazlik açilmasi, Teslimat bilgilerinin
düzeltilmesi
Invoice control
Prepare complaint Correct data
V
Receiving data corrected
Invoice o.k.
Invoice not o.k
V
Faturanin düzeltilmesi
Correct invoice
V
Teslimatlarin depoya transferi
Invoice corrected
Routing to warehouse, posting
Faturanin sisteme girilmesi
V
Routing completed
Invoice posted
Post invoice
47
Karmasiklik Farkli Görünümlerle Azalir
Veri Görünümü
Ortam verileri
Olay
Olay
Fonksiyon
Fonksiyon
Fonksiyon Görünümü
Hizmetler
Org. Birim
Personel
Hizmet Görünümü
Organizasyon Görünümü
48
Is Süreçleri Bilesenleri
Personel Fonksiyonlardan sorumludur
Dogan Bey
Personel
Org. Birim
Stok kontrolü
Geri Bildirim
Müsteri- siparis geldi
Müsteri siparisi teyidi
Müsteri siparisiteyit edildi
Can Bey
Üretim plani hazirlandi
Üretim- planlama
Personel
Org. Birim
Org. Birim
Banu Hn.
Personel
49
Süreç Optimizasyonu Için Hedefler
50
(No Transcript)