Professional Documents
Culture Documents
LIKMI/RA
OS /2
The need for a comprehensive
definition of requirements
RA /5
McCall’s Factor Model
RA /8
Product Operation Software
Quality Factors - Reliability
RA//9
Product Operation Software Quality
Factors - Efficiency
RA /10
Product Operation Software Quality
Factors - Integrity
RA /11
Product Operation Software Quality
Factors - Usability
OS /12
Product Revision software Quality
Factors
RA/13
Product Revision software Quality
Factors - Maintability
Maintability requirements determine the efforts
that will be needed by users and maintenance
personnel to identify the reasons for software
failures, to correct the failures, and to verify the
success of the corrections.
This factor’s requirements determine refer to the
modular structure of software, the internal
program documentation, and the programmer’s
manual, among other items.
Example typical maintability requirements :
a. The size of a software module will not exceed
30 statements.
b. The programming will adhere to the company
coding standards and guidelines.
RA /14
Product Revision software Quality
Factors - Flexibility
RA/15
Product Revision software Quality
Factors - Testability
OS /16
Product Transition software
Quality Factors - Portability
RA /17
Product Transition software
Quality Factors - Reusability
RA /18
Product Transition software
Quality Factors - Interoperability
OS /20
Who is interested in the
definition of quality
requirements?
Some quality factors not included in the
typical client’s requirements document
may, in many case, interest the developer.
The following lists of quality factors usualyy
interest the developer whereas they may
raise very little interest on the part of the
client :
Portability
Reusability
Verifiability
RA/21
Requirements Documents
RA /22
Software Compliance with
Quality Factors
RA /24
Factors and sub-factors (cont.)
RA /25
Factors and sub-factors (cont.)
OS /26
Summary
RA /28
Tugas
1. Perangkat lunak dari peralatan produksi yang
diperlukan untuk memproses hasil (output)
sesuai dengan struktur data standar yang
kemudian dapat berfungsi sebagai masukan
untuk sejumlah sistem informasi.
2. Perangkat lunak rumah sakit ini harus
dikembangkan untuk dapat diadaptasi
kemudian untuk berbagai rumah sakit swasta
lainnya.
3. Pelatihan teknisi laboratorium, yang
membutuhkan perangkat lunak tidak lebih dari
tiga hari untuk dapat dengan mahir
menggunakan perangkat lunak.
RA /29
Tugas
4. Perangkat lunak yang dikembangkan untuk sistem
operasi Linux harus kompatibel untuk aplikasi dalam
lingkungan Windows NT
5.Peluang sistem perangkat lunak terjadi kegagalan
saat jam sibuk (09:00-16:00) berada di bawah 0,5%.
6.“Super-lab” software system memungkinkan untuk
transfer hasil lab secara langsung ke file pasien rumah
sakit pada paket software “MD-FILE”
7.“Super-lab” subsystem harus sesuai dengan tagihan
pasien di sistem poliklinik yang digunakan.
8.Software system harus beroperasi pada 12
workstations, 8 mesin pengujian otomatis dan 1 server
utama termasuk communication server untuk 25 jalur
komunikasi.
RA /30
The Components of the
software quality assurance
system-overview
Chapter 4
09/21/15 15:23
3
1
The SQA System – an SQA
architecture
An SQA system always combine a wide
range of SQA components, all of which
are employed to challenge the multitude
of sources of software errors and to
achieve an acceptable level of software
quality.
The task of SQA is unique in the area of
quality assurance due to the special
characteristics of software (Chapter 1)
The environment in which software
development and maintenance is
undertaken directly influences the SQA
components.
09/21/15 15:23R
A/
“The software quality shrine” – the SQA
architecture
SQA system components can be
classified into six classes:
1. Pre-project components-1
1. Contract review
Definisi :
Memeriksa Draft Proposal Proyek
Draft Kontrak
Aktifitas :
Klarifikasi kebutuhan pelanggan
Review jadwal proyek dan perkiraan
kebutuhan sumber daya
Evaluasi kemampuan staf profesional untuk
melaksanakan proyek
Evaluasi kemampuan pelanggan untuk
memenuhi kewajibannya
Evaluasi resiko-resiko dari pengembangan
2. Development and quality plans.
09/21/15 15:233
5
1. Pre-project components-2
09/21/15 15:233
6
Development and quality plans.
09/21/15 15:233
7
Development and quality plans.
09/21/15 15:23R
A/
Formal design Reviews (DRs)
09/21/15 15:23R
A/
Peer Reviews
09/21/15 15:23R
A/
2.2 Expert Opinions
Expert Opinions support quality assessment efforts by
introducing additional external capabilities into the
organization’s in-house development process.
Turning to outside experts may be particularly useful in the
following situations:
Insufficient in-hose professional capabilities in a given area
In small organizations in many cases it is difficult to find
enough suitable candidates to participate in the design
review teams.
In small organizations or in situations characterized by
extreme work pressures, an outside expert’s opinion can
relace an inspection.
Temporary inaccessibility of in-house professional
In cases of major disagreement among the organization’s
senior professional, an outside expert may support a
decision.
09/21/15 15:23R
A/
2.3 Software Testing
09/21/15 15:23R
A/
2.5 Assurance of the Quality of the
External Participant’s work
09/21/15 15:234
7
4.Management SQA components
09/21/15 15:234
8
5. SQA standards, system
certification, and assessment
components
the main objectives of this class of
components are:
1.Utilization of international professional
knowledge.
2.Improvement of coordination with
other organizations’ quality systems.
3.Objective professional evaluation and
measurement of the achievements of
the organization’s quality systems.
09/21/15 15:234
9
6. Organizing for SQA – the human
components
09/21/15 15:235
0
6. Organizing for SQA – the human
components
09/21/15 15:235
1
Questions ?
Thank you
TUGAS 2
RA /53