Rekayasa Perangkat Lunak

Rekayasa Perangkat Lunak studi dengan pendekatan aplikasi yang bersifat sistematik, disipilin dengan
mendekati metode pengembangan, operasi, dan maintetenance dari perangkat lunak serta pendekatan
untuk
mendapatkan software yang bersifat ekonomis dan dapa t bekerja secara efisien pada real machines

i |S T M I K Royal

Kata Pengantar
Modul Rekayasa Perangkat Lunak
Dalam modul ini akan dibicarakan perlunya metodologi pengembangan perangkat lunak, modelmodel pengembangan perangkat lunak, prinsip dan pemodelan analisis perangkat lunak, konsep desain
perangkat lunak, desain struktur data, desain arsitektur, desain antarmuka, desain prosedur dan testing
perangkat lunak. Pengelolaan proyek pengembangan perangkat lunak akan dibicarakan secara singkat.
Setelah mempelajari modul ini mahasiswa akan mampu menganalisa sistem untuk menen tukan
kebutuhan perangkat lunak sistem, merancang perangkat lunak sistem dan mengimplementasikan
rancangan tersebut. Mahasiswa juga akan mempunyai pengetahuan yang diperlukan untuk mengelola
proyek pengembangan perangkat lunak sistem.
Materi Pengajaran :
Modul 01 : Pengantar Rekayasa Perangkat Lunak
Modul 02 : Model Dan Proses Perangkat Lunak
Modul 03 : Manajemen Proyek Perangkat Lunak
Modul 04 : Penjadwalan Proyek dan Tracking
Modul 05 : Jaminan Kualitas Perangkat Lunak
Modul 06 : Prinsip & Konsep Analisa Kebutuhan
Modul 07 : Pemodelan Analisa
Modul 08 : Konsep dan Prinsip Desain
Modul 09 : Software Architecture Design
Modul 10 : Metode Desain
Modul 11 : Interface Design
Modul 12 : Teknik Pengujian Software
Modul 13 : Lampiran soal latihan.

WASSALAM,

Zulfikar.S,kom

ii |S T M I K Royal

Daftar isi
Rekayasa Perangkat Lunak............................................................................................................................. i
Kata Pengantar.............................................................................................................................................. ii
Daftar isi ...................................................................................................................................................... iii
Modul-1 ........................................................................................................................................................ 1
Pengantar Rekayasa Perangkat Lunak ...................................................................................................... 1
Evolusi Perangkat Lunak ....................................................................................................................... 1
Karakteristik Perangkat Lunak .............................................................................................................. 1
Pengertian Rekayasa Perangkat Lunak ................................................................................................. 3
Objektif Dan Tujuan Utama Rekayasa Perangkat Lunak ....................................................................... 5
Modul-2 ........................................................................................................................................................ 6
Model Dan Proses Perangkat Lunak ......................................................................................................... 6
Model Proses Perangkat Lunak ................................................................................................................. 6
Model WaterFall ................................................................................................................................ 7
Model Prototyping ............................................................................................................................. 7
Model RAD ......................................................................................................................................... 8
Evolusi Model Proses Software ................................................................................................................. 8
Model Incremental ............................................................................................................................... 8
Model Spiral .......................................................................................................................................... 8
Model Komponen Rakitan .................................................................................................................... 9
Model Concurrent Develo pment ......................................................................................................... 9
Modul-3 ...................................................................................................................................................... 10
Manajemen Proyek Perangkat Lunak ..................................................................................................... 10
Management Spectrum ...................................................................................................................... 10
People (Manusia) .................................................................................................................................... 11
People Software Team .................................................................................................................... 11
People Coordination dan Communication Issues ........................................................................... 12
Problem Software Scope ..................................................................................................................... 13
Problem Decomposition ..................................................................................................................... 13
Process Decomposition ....................................................................................................................... 14
Modul-4 ...................................................................................................................................................... 14

iii |S T M I K Royal

Penjadwalan Proyek dan Tracking......................................................................................................... 15

Penjelasan Suatu Tugas Jaringan ........................................................................................................ 16
Penjadwalan........................................................................................................................................ 16
Penjadwalan Tracking ......................................................................................................................... 17
Rencana Proyek................................................................................................................................... 17
Modul-5 ...................................................................................................................................................... 17
Jaminan Kualitas Perangkat Lunak .......................................................................................................... 17
Konsep Kualitas ................................................................................................................................... 17
Kualitas kontrol ................................................................................................................................... 18
Cost dari Kualitas................................................................................................................................. 18
Jaminan Kualitas Software .................................................................................................................. 19
Jaminan Kualitas Statistik.................................................................................................................... 22
Modul-6 ...................................................................................................................................................... 23
Prinsip & Konsep Analisa Kebutuhan ...................................................................................................... 23
Analisa Kebutuhan .............................................................................................................................. 23
Proses Rancang Bangun Kebutuhan ....................................................................................................... 25
Proses Analisa Kebutuhan................................................................................................................... 25
Prinsip Analisa ..................................................................................................................................... 26
Prototipe Software.............................................................................................................................. 27
Spesifikasi Software ............................................................................................................................ 28
Modul-7 ...................................................................................................................................................... 28
Pemodelan Analisa.................................................................................................................................. 28
Elemen -elemen Pemodelan Analis ........................................................................................................ 29
Pemodelan Data.................................................................................................................................. 29
Pemodelan Functional dan Aliran Informasi....................................................................................... 30
Mekanika Analisa Struktur .................................................................................................................. 30
Modul-8 ...................................................................................................................................................... 32
Konsep dan Prinsip Desain ...................................................................................................................... 32
Desain Software ................................................................................................................................. 32
Proses Desain ...................................................................................................................................... 32
Kualitas Desain .................................................................................................................................... 33
Prinsip Desain...................................................................................................................................... 33
iv |S T M I K Royal

Konsep Desain ..................................................................................................................................... 33

Arsitektur Software ............................................................................................................................. 34
Modul-9 ...................................................................................................................................................... 36
Software Architecture Design ................................................................................................................. 36
Architectural Design - The Repository Model .................................................................................. 36
Architectural Design - The Client -Server Model............................................................................... 38
Architectural Design - The Abstract Machine Model ........................................................................ 38
Architectural Design - The Control Model ........................................................................................ 38
Data Design ......................................................................................................................................... 38
Modul-10 .................................................................................................................................................... 39
Metode Desain ........................................................................................................................................ 39
Metode -metode Desain Software ..................................................................................................... 39
Metode Desain Software .................................................................................................................... 39
Desain Data ......................................................................................................................................... 40
Desain File Data................................................................................................................................... 40
Desain Database.................................................................................................................................. 40
Desain Prosedur .................................................................................................................................. 41
Modul-11 .................................................................................................................................................... 42
Interface Design ...................................................................................................................................... 42
User Interface Design Principles ........................................................................................................ 42
Interface Design Guidelines ................................................................................................................ 43
User System Interactions .................................................................................................................... 43
Model Interface ............................................................................................................................... 44
Information Representation ............................................................................................................... 45
User Guidance ..................................................................................................................................... 46
User Documentation ........................................................................................................................... 46
Modul-12 .................................................................................................................................................... 47
Teknik Pengujian Software..................................................................................................................... 47
Prinsip -Prinsip Pengujian Software ........................................................................................................ 47
Kompleksitas Cyclomatic ........................................................................................................................ 49
Kesamaan Penyekatan ............................................................................................................................ 49
Kelas Kesamaan................................................................................................................................... 50
v |S T M I K Royal

Analisis Nilai Batas .............................................................................................................................. 50

Modul-13 .................................................................................................................................................... 50
Contoh -Contoh Soal ............................................................................................................................... 50

vi |S T M I K Royal

Modul-1
Pengantar Rekayasa Perangkat Lunak
Evolusi Perangkat Lunak
Beberapa tahun lalu:
- Batch orientation
- Limited distribution
- Custom software
Era tahun ke -2:
- Multiuser
- Real-time
- Database
- Product software
Era tahun ke - 3:
- Distributed systems
- Embedded intelligence
- Low cost hardware
- Consumer impact
Era tahun ke - 4:
- Powerful desk-top systems
- Object-oriented technologies
- Expert systems
- Artificial neural networks
- Parallel computing
- Network computers

Karakteristik Perangkat Lunak

Software memiliki fungsi ganda. Software dapat disebut sebagai produk, tetapi juga dapat disebut
sebagai sarana yang dapat mengantarkan produk itu sendiri
Software bersifat logical dibanding elemen fisik dari sistem
Software memiliki beberapa karakteristik yang dapat membedakan dari hardware
Software dikembangkan atau dibangun, tetapi tidak menghasilkan classical sense
Banyak software yang sudah bisa diguna kan secara langsung atau bersifat custom built, tetapi ada
pula yang masih menggabungkan antar beberapa komponen.
Aplikasi Software
System Software - Kumpulan dari beberapa program yang dibuat untuk memberikan servis terhadap
program lainnya pada setiap level. Contohnya : compiler, operating sistem
1 |S T M I K Royal

Real-time Software - Program yang dapat memonitor/menganalisa/mengontrol kejadian nyata yang

terjadi di dunia ini
Business Software - Program yang dapat mengakses, menganalisa dan memproses informasi bisnis.
Engineering and Scientific Software - Software yang menggunakan algoritma number crunching
untuk membedakan science dan application s. Sistem simulation, computer-aided design.
Embedded Software - Software terletak pada read only memory dan digunakan untuk mengontrol
produk dan sistem yang akan dikirimkan untuk konsumen dan industrial markets.
Artificial Intelligence (AI) Software - program yang digunakan untuk teknik AI dan metodenya
digunakan untuk memecahkan masalah yang kompleks. Contohnya : expert sistem, pengenalan
pola, games.
Internet Software - program yang mensupport pengaksesan internet. Contohnya : search engine,
browser, e-commerce software,authoring tools.
Software Tools and CASE environment - tools dan program yang dapat membantu pembuatan
aplikasi software dan sistem.contohnya : test tools dan version control tools.

Krisis Perangkat Lunak

In the software industry, we have had a crisis that has been with us for close to 30 years.
Meaning of the word crisis
a turning point in the course of anything; decisive or crucial time, stage or event.
the turning point in the course of a disease, when it becomes clear whether the patient will live
or die.
What we actually have in software industry is a chronic affliction.
It means --> lasting a long time, recurring often, continuing indefinitely.
Software crisis or software affliction
a set of problems encountered in software production.
Problems in developing software
Problems in maintain a growing volume of existing software
Typical examples:
Build a wrong product.
Project schedule problems
Cost estimation problems
Mitos Seputar Perangkat Lunak
Many causes of a software affliction can be traced to a mythology that arose during the early history
of software development.
Software myths propagated misinformation and confusions. They had a no. of attributes that
made them insidious.
Software managers often under pressure to maintain budgets, keep schedules from slipping,
and improve quality.
Myths --> misleading attitudes of people ---> serious problems in software production
Management Myths:
2 |S T M I K Royal

We already have a book thats full of standards and procedures for building software. Wont that
provide my people with everything they need to know?
My people do have state -of-the-art software development tools. After all, we but them the newest
computers.
If we get behind schedule, we can add more programmers and catch up.
Customers dari software mungkin berasal dari :
di luar perusahaan yang telah merequest software dibawah kontrak seseorang yang berasal dari dalam
(in house group) marketing atau sales group.
Customer Myths:
pernyataan umum adalah memulai dengan menulis program secukupnya kemudian kita dapat
memberikan penjelasan dengan detail
project requirement secara langsung berubah, tetapi perubahan dengan mudah dapat ditampung
karena software bersifat fleksibel
Pelaksana Software:
Planing group - System analysts, system architects
Development group - Software engineers
Verification group - Test engineers, quality assurance group
Support group - Customer supporters, technical supports
Marketing/sales - Marketing people and product sales
Practitioners Myths:
pertama kali kita menulis program dan kemudian mendapatkan pekerjaan, sehingga pekerjaan
kita selesai
sampai pada akhirnya program dapat di running, sampai benar- benar yakin bahwa program
tidak ada cara untuk meningkatkan quality
software dapat diserahkan apabila telah berhasil (telah sukses)
Major task dari pembuatan software adalah teknik penulisan program.
Schedule dan requirement merupakan hal yang penting ketika kita menulis program

Pengertian Rekayasa Perangkat Lunak

Walaupun ratusan pengarang telah mengembangkan definisi tersendiri tentang software
engineering, definisi ini diusulkan oleh Fritz Bauer[NAU 69] yang menyediakan basis :
[Software engineering adalah] prinsip yang digunakan pada sound engineering yang digunakan
untuk mendapatkan software yang bersifat ekonomis dan dapat bekerja secara efisien pada real
machines
The IEEE [IEE93] telah mengembangkan definisi yang lebih lengkap dengan pernyataan :
Software Engineering : (1) aplikasi yang bersifat sistematik, disipilin dengan mendekati metode
pengembangan, operasi, dan maintemaintenance dari software; (2) studi dengan pendekatan
pada definisi nomor (1)
Pressmans view:
Software engineering is a layered technology seperti ilustrasi dibawah

3 |S T M I K Royal

Software methods:
Metode Software engineering menyediakan teknik how to untuk membangun software.
Metode --> meliputi bagaimana menyelesaikan task :
requirement analisis, design, coding, testing dan maintenance
Software process:
Proses Software engineering mendekatkan dengan :
teknologi bersama
memungkinkan secara rational dan pengenbangan secara bertahap dari software komputer
Proses Software engineering merupakan set framework dari area key process yang dibentuk dari
basis untuk :
project management, budget, dan schedule control
teknik metode aplikasi
kualitas produk control
Software tools:
Program menyediakan sistem otomatis atau semi otomatis untuk proses dan metode.
Program yang memberikan dukungan pada engineers untuk menyelesaikan
masing-masing task.
Pandangan Umum Rekayasa Perangkat Lunak
Engineering --> analysis, design, construction, verification, and management of technical (or social)
entities.
Tiga phase dalam production software
1. phase definition
2. phase development
3. phase maintenance
Phase definition : (dilakukan dalam tahap pendefinisian dan perencenaan dari software sistem)
Phase definition terfokus pada apa yang terjadi dalam software sistem.
informasi apa yang harus diproses pada sistem?
fungsi apa saja yang harus disediakan oleh sistem?
performance sistem dan kriteria yang diperlukan oleh sistem?
apa yang diperlukan pada sistem behavior?
dengan cara apa requirement akan direpresentasikan?
Tiga tugas utama pada phase definisi :
1. sistem atau informasi engineering
2. software project planning
3. requirement analisis
Phase Development : (terjadi selama proses pengembangan dari software sistem)
Phase development terfokus pada bagaimana.
bagaimana sistem menjadi terstruktur?
bagaimana data-data yang ada menjadi terstruktur?
bagaiman informasi dapat diproses?
bagaimana fungsi dapat diimplementasikan?
4 |S T M I K Royal

bagaiamana karakteristik dari interface?

bagaimana design dapat menjadi lebih spesifik?
bagaimana testing dapat ditunjukkan?
Terdapat tiga tipe task dari phase development :
1. software design
2. code generation, dan
3. software testing
Phase maintenance : -> evaluasi dari produk software setelah sistem testing.
Phase maintenance mengulang kembali langkah -langkah pada phase definisi dan pengembangan Phase
development terfokus pada perubahan software sistem.
Error correction apabila ini terjadi maka dilakukan perubahan software sehingga software
menjadi benar.
Adaptation memodifikasi software untuk mengakomodasi perubahan yang terjadi terhadap
lingkungan.
Enhancement mengembangkan software dengan melakukan penambahan f ungsi-fungsi yang baru
untuk customer/user.
Prevention - preventive maintenance, called software reengineering.
dengan membuat perubahan pada software sehingga dapat lebih mudah dikoreksi, ditangani.

Objektif Dan Tujuan Utama Rekayasa Perangkat Lunak

Objectives:
Mengidentifikasi masalah baru dan solusi dari produk software
Mempelajari sistematik petode terbaru, prinsisp, pendekatan untuk sistem analisis, design,
implementasi, testing, maintenance.
Menyediakan teknik kontrol terbaru, manage, dan monitor proses software
Membangun tools software terbaru dan environment untuk mendukung software engineering.
Major Goals:
Untuk meningkatkan produktivitas dan kualitas
Untuk meningkatkan efektivitas dari kontrol schedule software dan planning. --- Untuk
mengurangi cost dari development proses
Untuk memenuhi keinginan dan requirements dari customer.
Untuk menangani konduksi dari proses software engineering.
Untuk meningkatkan practice software engineering.
Untuk memberikan dukungan pada engineers terhadap aktivitas yang sistematik dan lebih
efisien.

5 |S T M I K Royal

Modul-2
Model Dan Proses Perangkat Lunak
Proses Perangkat Lunak
Kerangka kerja proses common software :
Bisa digunakan untuk semua proyek software.
banyaknya kumpulan tugas, termasuk tugas, milestone, pengiriman dan SQO points.
Aktivitas Umbrella :
project tracking and control
technical reviews (formal or informal)
software quality assurance (SQA)
konfigurasi management
dokumentasi
Pengukuran
manajemen reuse dan resiko

Model Proses Perangkat Lunak

Konsep:
Sebuah model proses atau paradigma rekayasa software:
Menunjukkan suatu strategi untuk melindungi proses, metode dan alat bantu yang secara bersama
mengelola secara efektif dan mengirim produk software.
Pemilihan model proses berdasarkan pada:
proyek dan aplikasi yang alami
metode dan alat bantu yang digunakan
kontrol dan pengiriman
Terdapat empat dasar aktivitas proses :
1) Software specification.
2) Software development
3) Software validation
4) Software maintenance (or evolution)
Pemecahan Masalah Yang Terulang
Semua pembuatan software bisa dilihat sebagai pemecahan masalah yang terulang
Itu memiliki empat tingkatan :
definisi masalah-indetifikasi masalah dan definisinya
pembuatan teknik-menemukan solusi untuk memecahkannya
integrasi solusi-menggunakan solusi dan mengirimkan ke sistem
status QUO Bagian yang ada kesalahan.

6 |S T M I K Royal

Model WaterFall
The waterfall model - the linear sequential model , disebut juga classic life cycle
sistematika, pendekatan yang secara terurut untuk pembuatan software yang mulai dari level sistem
dan progres menuju analisa, design, coding, testing dan perawatan.
Model waterfall adalah yang paling lama dan banyak secara luas digunakan paradigma untuk rekayasa
software.
Keuntungan:sederhana,langkah-secara terurut,fokus,dan mudah diikuti.
Masalah Pada Model WaterFall :
Tidak flesible sebab proyek yang nyata jarang mengikuti aliran yang terurut untuk menyusun Model.
Sangat sulit untuk customer terhadap mengahadapi semua kebutuhan yang eksplisit.
Customer harus memiliki kesabaran untuk menunggu keabsahan produk software dalam fase
Yang terlambat.(sampai program dimplementasikan) Customer tercakup dalam awal proyek.
Pembuat sering ditunda secara tidak berhubungan diantara fase.

Model Prototyping
The waterfall model - the linear sequential model , disebut juga classic life cycle
step 1: Kebutuhan bersama
step 2: A design yang cepat -> folus pada fungsi yang nyata dan kebiasaan dari produk
step 3: konstruksi Prototype
step 4: evaluasi Customer dari prototype ulangi langkah 1.
Keuntungan:
Mudah dan cepat identifikasi kebutuhan customer
Customer mengecek protipe di awal tingkatan dan menyediakan input dan umpan baliknya.
Persetujuan yang baik dengan mengikuti kasus:
Customer tidak bisa menyediakn kebutuhan yang jelas.
Sangat rumit interaksi sistem dari pengguna
Menggunakan teknologi baru, hardware dan alg oritma
Membuat domain baru sistem aplikasi
Masalah:
Prototipe bisa melayani sebagai sistem pertama.Brooks merekomendasikan untuk membuangnya.
Developer biasa ikut membuat produk didasarkan pada prototipe.
Developer sering membuat perjanjian implement asi dalam memerintahkan untuk dapat prototipe
bekerja secara cepat.
Customer boleh terkejut bahwaa protipe adalah tidak sebuah produk, yang dibuat dengannya.

7 |S T M I K Royal

Model RAD
Rapid Application Development (RAD) adalah model proses pembuatan software yang teru rut secara
linear yang memberikan pembuatan daur hidup yang singkat.
Kecepatan tinggi adaptasi dari model terurut secara linear
Konstruksi component-based
Efektif ketika kebutuhan dimengerti secara baik dan lingkup proyek dibatasi.
Keuntungan:
Waktu pembuatan yang pendek
Pengurangan biaya supaya software digunakan kemabali dan konstruksi dasar komponen
Masalah:
Untuk yang besar, tetapi proyek yang berskala, RAD butuh sumber yang cukup.
RAD butuh developer dan pelanggan yang diijinkan untuk menyusun.
Pembuatan software adalah spesifik proyek, dan tidak boleh dimodulkan secara baik.
Kualitasnya tergantung pada kualitas dari komponen yang ada.
Proyek yang tidak akurat dengan resiko teknik yang tinggi dan teknologi baru.

Evolusi Model Proses Software

Model proses klasik tidak dirancang untuk mengirimkan sistem yang produktif sehingga asumsinya pada:
Sistem yang sempurna akan dikirimkan setelah urutan linear diselesaikan
Customer mengetahui yang mereka inginkan di tingkatan awal
Realita dalam proses pemuatan software
banyaknya kebutuhan perubahan selama latihan pembuatan
Banyaknya aktivitas iterasi dan bekerja sebab evolusi alami dari produksi software
Persetujuan yang sulit dengan evolusi produk, beberapa evolusi model proses yang disusun :
the incremental model
the spiral model
the component assembly model
the concurrent development model

Model Incremental
Incremental Model mengabungkan elemen dari model yang terurut secara linear dengan iterasi filosofi
dari prototipe. Peningkatan pertama adalah inti produk.
Proses incremental model:
Berulang secara alami, seperti prototipe
Fokus pada pengiriman dari operasional produk dengan setiap penambahan.
Kebiasaann penggunaan ketika staff tidak hadir untuk menyelesaikan implementasi oleh deadline
bisnis.

Model Spiral
spiral model (by Boehm[BOE88])
adalah sebuah evolusi model proses software
8 |S T M I K Royal

pasangan iterasi yang murni dari prototipe

mencakup aspek sistematik dari model terurut yang linear.
menyediakan kegunaan untuk pembuatan yang cepat dari versi pertam bahan dari software..
Model spiral dibagi kedalam banyak daerah aktiitas:
customer communication
planning (resources, timelines, etc.)
risk analysis
engineering
construction & release
customer evaluation
Setiap bagian dipopulasi oleh rangkaian dari tugas kerja.
Spiral model pendekatan yang nyata untuk pembuatan dari skala sistem yang besar dan software.
Mungkin sulit untuk menyakinkan customer bahwa evolusi pendekatan yang terkendali.
Sebuah model baru yang relatif dan tidak digunakan secara luas sebagai u rutan linear atau
Paradigma prototipe

Model Komponen Rakitan

Object Technologies -> kerangka kerja teknis untuk sebuat model proses komponen dasar untuk
rekayasa software
Model komponen rakitan banyak tidak bekerja dari sifat dari model spiral adalah evolusi yang alami
meminta sebuah pedekatan secara berulang untuk membuat suatu software memimpin penggunaan
kemabali software
Keuntungan:
permintaan software digunakan kembali
biaya berkurang
pengurangan waktu daur pembuatan

Model Concurrent Develo pment

Model concurrent development disebut rekayasa terjadi pada waktu yang sama --> Menyediakan
sebuah bagian akurat dari bagian yang ada dari sebuah proyek Fokus pada kegiatan rekayasa waktu
yang sama dalam proses rekayasa software Seperti prototipe,model analisa,spesifikasi kebutuhan dan
rancangan. Membuat skema sebagai rangkaian dari kegiatan teknis yang umum, tugas, dan bagian yang
terkait. Dijelaskan sebagai rangkaian dari event yang transisi dari bagian ke bagian untuk Setiap suatu
kegiatan rekayasa software
Dua cara meningkatkan konkruen:
aktivitas sistem dan komponen terjadi simultan dan bisa dimodelkan menggunakan pendekatan
orientasi bagian sebuah tipe aplikasi client/server yang diimplementasikan dengan banyak komponen,
setiapnya bisadirancang dan dianggap konkruen.
Aplikasi: semua tipe dari pembuatan software
Software Process Maturity
Lima proses maturity level:
9 |S T M I K Royal

Level 1: Inisial - Proses Software --> ad hoc, dan biasa pada bagian yang sulit.
Level 2: Repeatable - Proses manajemen proyek dasar yang dibuat untuk menyiapkan biaya, jadwal
dan fungsional.
Level 3: Defined - Dalam proses software,kedua manajemen dan aktivitas rekayasa
didokumentasikan,standarisasi dan dimasukan kedalam sebuah proses software organisasi yang
luas.
Level 4: Managed - Penghitungan yang jelas dari proses software dan kualitas produk dikumpulkan.
Kedua proses dan produk software adalah jumlah yang dimengerti dan dikontrol mengunakan
penghitungan yang jelas.
Level 5: Optimizing - Pengembangan proses berlangsung ada oleh jumlah umpan balik dari proses
dan dari uji coba ide yang inovasi dan teknologi.

Modul-3
Manajemen Proyek Perangkat Lunak
Management Spectrum
Software project management yang efektif terfokus pada tiga P yaitu : (1) people, (2) problem, dan
(3) process People
Software engineering bekerja secara intensive Kemampuan management pada maturity model
(PM-CMM)
key practice areas for software people:
teknik praktis untuk software people : recruiting, selection, performance, m anagement,
training, compensation, career development, organization dan work design,dan
team/culture development
Kontributor yang paling penting agar software project berhasil memiliki orang yang pintar
dengan kemampuan yang baik
Organisasi dengan high levels maturity pada management people mengimplementasikan
effective software engineering Propblem/Masalah (berhubungan dengan project )
Sebelum memulai project, kita memerlukan untuk mengidentifikasi :
Objectives dan scope Alternative solutions
Technical dan management constraints
Faktor lain yang berhubungan:
delivery deadlines, budgetary restrictions, personnel availability
echnical interfaces, dan lainnya
Tanpa informasi ini , tidak mungkin untuk :
10 |S T M I K Royal

mendefinisikan estimasi biaya

menginginkan efektif assesssment dari resiko.
melakukan project task yang lebih realistis
menghasilkan project schedule yang teratur
Process:
Software process menyediakan framework berupa p erencanaan yang komprehensiv dari
software development
Beberapa perbedaan task dari semua project software tasks, milestones, deliverables, dan
quality assurance points
Aktifitas pelindung -> terjadi melalui proses
software quality assurance
software configuration management
measurement

People (Manusia)
Pada software process, terdapat 5 tipe dari players:
Senior managers, yang mendefinisikan dari masalah bisnis (berpengaruh kuat terhadap project)
Practitioners, yang akan mengantar pada kemampuan teknik untuk engineering software
Project (technical) managers, s eseorang yang harus merencanakan, memotivasi, dan
mengorganisasikan
Customers, seseorang yang akan menspesifikasikan requirements dari software
End users, seseorang yang berinteraksi software yang akan direleased
Project management merupakan aktivitas dari orang-orang yang bersifat intensive
Bagaimana memilih team manager yang baik?
Model MOI yang disarankan oleh Jerry Weinberg [WEi86]:
Motivation kemampuan untuk mengumpulkan teknik dari perorangan
Organization kemampuan untuk menyediakan proses yang dianggap sebagai initial konsep yang
akan ditranslasikan menjadi final product
Ideas or innovation kemampuan untuk mengumpulkan kreatifitas perorangan
Software managers harus terkonsentrasi pada
pengertian masalah yang akan dipecahkan
pengaturan ide
membiarkan seseorang dalam team mengetahui jumlah kualitas
Empat kunci utama sebagai project management yang efektif
Problem solving
Managerial identity
Achievement
Influence dan team building

People Software Team

Mantei [MAN81] menyarankan tiga team organisasi yang kuat :
Democratic decentralized (DD):
11 |S T M I K Royal

software engineering tidak memiliki pemimpin yang tetap.

keputusan dibuat dari ketetapan group
komunikasi diantara team harus bersifat horisontal

Controlled decentralized (CD):

1.
2.
3.
4.
5.

memiliki pemimpin -> koordinasi antara spesific task dan pemimpin kedua
pemimpin kedua harus memiliki tanggung jawab untuk masing- masing subtask
komunikasi horisontal terjadi diantara subgroups dan individual
komunikasi vertikal terjadi pada struktur kontrol
keputusan dibuat oleh pemimpin

Controlled centralized (CC):

pemimpin mengatur pemecahan masalah pada top level dan koordinasi team internal
komunikasi antara pemimpin dan anggota team adalah vertikal
7 faktor project yang terhubung dengan struktur team project :
1. Kesulitan dalam pemecahan masalah
2. Ukuran dari resultant program
3. Modularity dari program
4. Reliability dari software
5. Team life time
6. Rigidity dari delivery date
7. Tingkat dari sociability (communication overhead)
Constantine [CON93] menyarankan empat organization paradigms Untuk team software engneering:
1. A closed paradigm: Team denga tradisional hirarki pada authority (seperti CC)
2. Random paradigm: Team yang tergantung dari initiative individual dari anggota team Open
paradigm: heavy communication + control structure like CC
3. Synchronous paradigm:
4. Chief programmer team(by Harlan Mills described in Bakers [BAK72]): senior engineer (1),
technical staff (2-5), a backup engineer, support staff (e.g. technical writers), software
librarian(1).
Book Peopleware oleh DeMarco dan Lister discussed jelled team:.
jelled team merupakan group dari people . Mereka tidak mengerti cara mengatur secara
tradisional, mereka tidak memerlukan motivasi.

People Coordination dan Communication Issues

Beberapa kegagalan disebabkan dari project software. Disini terdapat beberapa yang berhubungan
dengan komunikasi dan koordinasi dari project :
Skala yang lebih luas dari development efforts
kompleksitas, konfusion, dan kesulitan yang signifikan pada koordinasi team
Ketidakpastian pada perubahan requirement dan status team
Interoperability interoperations diantara systems
12 |S T M I K Royal

Mekanisme komunikasi formal dan informal yang baik dan efektif :

Pendekatan formal impersonal
documents, deliverables, memos, pr oject milestones, schedules, project control tools, perubahan
permintaan , dan related documents, error tracking reports dan data.
Formal, interpersonal procedures
aktivitas jaminan kualitas (code dan design inspection, review meeting)
Informal, interpersonal procedures
informal group meeting (seperti meeting dengan customers dan users)
Electronic communication (email, web sites, video-based conference)
Interpersonal network

Problem Software Scope

Project manager dari software harus terhubung dengan masalah awal pada project software
engineering
Software scope:

a) Context:
Bagaimana software dibuat secara lengkap kedalam sistem yang luas, product atau bisnis?
Apa yang menjadi constraint dalam hasil konteks?

b) Information objectives:
Apakah customer sesuai dengan data objects yang dihasilkan sebagai output dari software?
Apakah data object dibutuhkan untuk input?

c) Function and performance:

Apakah fungsi akan menunjukkan software untuk mentransform input data menjadi out put?
Apakah ada beberapa karakteristik special performance yang akan digunakan?

Problem Decomposition
Problem decomposition --> problem partitioning.
Problem decomposition --> dua area:
functionality dari delivery software system
process yang akan digunakan untuk mengantarkan system
Functional decomposition:
mengidentifikasi dan mendefinisikan cakupan fungsi dari sistem
mengaplikasikan metode dekomposisi pada masing-masing feature
Sebagai contoh pada function feature untuk word processing system :
spell checking
sentence grammar checking
reference checking untuk large documents
section dan chapter reference validation untuk large documents.
Melding Problem Dan Process
Masing-masing fungsi akan menjadi engneered dari team software melalui aktivitas framework :
13 |S T M I K Royal

Komunikasi customer tugas untuk membangun komunikasi yang efektif diantara customer
Planning tugas untuk mendefinisikan resource, timelines dsb
Analisis resiko tugas untuk menerima resiko teknik dan management
Engineering tugas untuk membangun sistem aplikasi
Construction dan release - installation, release control, dan customer support.
Customer evaluation tugas untuk mendapatkan feedback dari customer dan hasil evaluasi

Process Decomposition
Process decomposition:
Partition the software process based on the tasks and activities
memilih model software process untuk project
mendefinisikan preliminary project plan berdasarkan aktivitas proses framework.
common process framework (CPF)
Project yang kecil memerlukan beberapa tugas :
mendevelop list dari masalah yang telah diklarifikasi
bertemu dengan customer untuk mengklarifikasikan masalah
menggabungkan cakupan dari beberapa statement
mereview state dari scope
memodifikasikan cakupan statement yang diperlukan.
Project yang komplit memerlukan beberapa tugas :
Mereview permintaan customer
Merencanakan dan menjadwalkan secara formal, fasilitas pertemuan dengan customer
Mengharapkan penelitian untuk mendefinisikan solusi dan pendekatan yang ada
Menyiapkan dokumen pekerjaan dan agenda untuk pertemuan formal
Mengharapkan terjadinya pertemuan
Mengembangkan mini-spec untuk perbaikan, konsistensi, dan kelemahan pada ambiguitas
Memodifikasi cakupan dokumen yang diperlukan

Modul-4
14 |S T M I K Royal

Penjadwalan Proyek dan Tracking

Penjadwalan Proye k (Prinsip Dasar)
Penjadwalan Software proyek adalah suatu aktivitas yang mendistribusikan perkiraan usaha
melewati durasi rencana proyek dengan mengalokasi usaha ke software spesifik tugas rancang bangun.
Pertama, suatu jadwal makroskopik dikembangkan.
suatu jadwal terperinci digambarkan kembali untuk masing -masing isi jadwal yang makroskopik
itu.
Sebuah jadwal meningkat dari waktu ke waktu.
Prinsip dasar memandu software Penjadwalan Proyek :
Bagian
Saling bergantung
Alokasi waktu
Alokasi usaha
Pengesahan usaha
Tanggung-Jawab yang definisikan
Hasil yang digambarkan
Tonggak mil yang digambarkan
Penjelasan Suatu Tugas Untuk Proyek Software
Penjelasan Suatu Tugas Menetapkan Karena Software Merancang
Tidak ada rangkaian tugas tunggal yang adalah sesuai dengan semua proyek.
Suatu proses software yang efektif perlu menggambarkan suatu koleksi tugas menetapkan, masing masing dirancang untuk memenuhi kebutuhan dari jenis proyek yang berbeda.
Suatu tugas di-set adalah suatu koleksi s oftware rancang-bangun bekerja-> tugas, tonggak mil, dan
deliverables.
Perangkat Tugas dirancang untuk mengakomodasi jenis proyek yang berbeda dan derajat tingkat
kekakuan berbeda.
Jenis proyek khas:
Proyek Pengembangan Konsep
Pengembangan Aplikasi Proyek Baru
Proyek Peningkatan Aplikasi
Proyek Pemeliharaan Aplikasi
Proyek Rancang Bangun Kembali
Memperoleh Informasi
Derajat Kekakuan :
Peristiwa kebetulan
Tersusun
Tegas
Reaksi Cepat
Penjelasan Ukuran-Ukuran Adaptasi:
Ini digunakan untuk menentukan derajat tingkat kekakuan yang direkomendasikan.
15 |S T M I K Royal

Sebelas ukuran-ukuran digambarkan untuk software proyek:

1. Ukuran proyek
2. Jumlah para pemakai potensi
3. Kekritisan misi
4. Aplikasi umur yang panjang
5. Merampas customer/pengembang komunikasi
6. Kedewasaan teknologi bisa diterapkan
7. Batasan capaian
8. Karakteristik yang ditanamkan/tidak ditanamkan
9. Merancang susunan kepegawaian
10. Faktor Rancang Bangun.

Penjelasan Suatu Tugas Jaringan

Tugas tugas Individu dan subtasks sudah interdependencies berdasar pada uru tan mereka.
Suatu jaringan tugas adalah suatu penyajian grafis menyangkut tugas alir untuk suatu proyek.
Gambar dibawah menunjukkan suatu jaringan menurut bagan untuk suatu proyek pengembangan
konsep.
Jalur kritis: tugas pada suatu jalur kritis harus diselesaikan sesuai jadwal untuk membuat keseluruhan
proyek sesuai jadwal.

Penjadwalan
Penjadwalan dari suatu software proyek tidak sangat berbeda dari penjadwalan tentang segala
multi tugas usaha rancang-bangun .
Metode penjadwalan dua proyek:
Evaluasi Program dan Tinjauan ulang Teknik
Analisa jalur kritis
Kedua metoda dikemudikan oleh informasi yang dikembangkan dalam kegiatan -kegiatan
perencanaan proyek lebih awal:
Perkiraan usaha
Suatu pembusukan fungsi produk
Pemilihan dari proses sesuai model
Pemilihan tugas dan jenis proyek yang ditetapkan
Kedua metoda mengijinkan suatu perencana untuk melakukan :
menentukan jalur kritis
penilaian waktu
mengkalkulasi batas untuk masing-masing tugas
Batas waktu:
waktu yang paling awal dan waktu terakhir untuk mulai suatu tugas
waktu yang paling awal dan waktu terakhir untuk melengkapi suatu tugas
waktu molor
Timeline Charts (Gantt charts)
16 |S T M I K Royal

Penjadwalan Tracking
Jadwal proyek menyediakan suatu peta jalan untuk suatu software manager proyek.
Itu menggambarkan tonggak mil dan tugas.
Beberapa jalan untuk menjejaki suatu jadwal proyek:
pelaksanaan status proyek berkala [yang] bertemu
mengevaluasi tinjauan ulang akibat proses software
menentukan jika tonggak mil proyek formal telah terpenuhi(Gambar 7.4)
bandingkan tanggal start nyata untuk merencanakan tanggal start untuk masing-masing tugas
pertemuan informal dengan praktisi
Manager proyek mengambil kendali dari jadwal di dalam aspek:
proyek susunan kepegawaian
merancang permasalahan
merancang sumber daya
tinjauan ulang
merancang anggaran

Rencana Proyek
Rencana Proyek adalah suatu dokumen yang ringkas yang menunjukkan suatu pendengar berbeda.
Itu harus berisi berikut:
lingkup komunikasi, sumber daya, susunan kepegawaian, dan pelanggan
menggambarkan manajemen resiko teknik dan resiko
menggambarkan harga dan membuat jadwal tinjauan ulang manajemen
menyediakan suatu keseluruhan pendekatan ke pengembangan software
menguraikan secara singkat bagaimana mutu akan dipastikan dan perubahan akan diatur.
Rencana berkonsentrasi pada suatu laporan umum dari apa dan sebuah statemen yang spesifik
seberapa banyak dan seberapa lama.
Tujuan suatu rencana proyek adalah:
membantu menetapkan kelangsungan hidup dari pengembangan software usaha.
Rencana proyek tidak perlu berupa suatu dokumen kompleks dan panjang.

Modul-5
Jaminan Kualitas Perangkat Lunak
Konsep Kualitas
Jaminan Kualitas Software menjadi pelindung aktivitas yang diaplikasikan melalui software process.
17 |S T M I K Royal

SQA terdiri dari:

1. Pendekatan manajemen kualitas
2. Teknologi software engineering yang efektif
3. formal technical reviews
4. multi-tiered testing strategy
5. Dokumen perubahan kontrol
6. Pengembangan software yang bersifat standard dan kontrol prosedur
7. Mekanisme measurement dan reporting
Kualitas --> tertuju pada karakteristik dari software. Items ini dapat dibandingkan dari standard
yang telah diberikan.
Dua type kontrol kualitas:
Design Kualitas -> karakteristik bagi designer yang dispesifikasikan bagi item
Terdiri dari: requirements, specifications, dan design system.
Quality of conformance -> tingkatan dimana design spesifikasi dapat diikuti. Yang berfokus pada
implementasi yang berdasar pada design

Kualitas kontrol
Apa yang dimaksud kualitas kontrol rangkaian dari in spections, review dan test yang digunakan
melalui phase development pada software product.
Kualitas kontrol termasuk dari feedback loop untuk proses.
Objective meminimalkan biaya produk, menambah kualitas produk
Pendekatan implementasi :
Fully automated
Entirely manual
kombinasi dari tools yang terotomatisasi dengan interaksi manusia.
Kunci utama konsep dari kualitas kontrol :
membandingkan spesifikasi produk dengan measurable standards
Jaminan Kualitas terdiri dari :
fungsi manajemen auditing dan reporting
Tujuannya --> menyediakan manajemen dengan data yang penting mengenai kualitas produk.
mendapatkan pengetahuan dan kenyamanan dari kualitas produk

Cost dari Kualitas

Cost dari Kualitas --> termasuk dari semua biaya- biaya yang terjadi di dalam kualitas yang sesuai
atau menunjukkan kualitas yang berhuibungan dengan pekerjaan
Quality cost terdiri dari:
1. prevention cost:
quality planning
formal technical reviews
testing equipment
training
18 |S T M I K Royal

2. appraisal cost:
in-process dan inter-process
equipment calibration dan maintenance
testing
3. failure cost:
internal failure cost:
rework, repair, dan failure mode analysis
4. external failure cost:
complaint resolution
product return dan replacement
help line support
warranty work

Jaminan Kualitas Software

Tujuannya : untuk mendapatkan produk software yang berkualitas tinggi
Quality definition:
Definisi dari Kualitas :
performance requirement, standar pengembangan dokumen secara eksplisit dan karakteristik
secara implisit yang didapatkan dari software yang telah dikembangkan
Tiga point penting dari kualitas measurement :
penggunaan requirements sebagai pondasi
penggunaan standard yang spesifik sebagai kriteria
termasuk dalam requirement implisit
Mengenai Jaminan Kualitas :
Pertama kalinya jaminan kualitas dan fungsi kontrol diperkenalkan oleh Bell Labs pada tahun
1916 pada dunia manufacturing Selama tahun 1950 dan 1960, terdiri dari kontrol programmer dari
masing -masing kualitas produk Selama tahun 1970, jaminan kualitas standard telah diperkenalkan
pertama kali oleh contract software development Pada tahun 1987, perluasan definisi diberikan oleh
[SCH87]
Kelompok SQA.
Siapa saja yang termasuk kedalam aktivitas jaminan kualitas ?
Software engineers, project managers, customers, sale people, SQA group
Engineers termasuk pada jaminan kualitas yang bekerja pada :
mencoba metode teknikal
menginginkan teknikal review
menunjukkan perencanaan yang baik pada software testing
Aturan-aturan dari SQA group - > menyediakan pelayanan secara representativ bagi customer, team
software engineering untuk mendapatkan kualitas yang tinggi.
Tanggung jawab dari SQA group :
perencanaan diluar jaminan kualitas, record keeping, analisis dan reporting
19 |S T M I K Royal

Tugas-tugas dari SQA group :

- menyiapkan perencanaan SQA utnuk project
- memberikan dukungan pada phase pengembangan dari diskripsi project software
- mengulang aktivitas engineering untuk memverifikasi dengan definisi proses
- mengaudit pekerjaan software produk untuk memverifikasi dengan definisi proses
- mengumpulkan beberapa noncompliance dan reports dari senior manajemen
Software Reviews
Apa yang dimaksud software review?
merupakan filter (penyaring) dari proses software engineering
Tujuannya : memberikan pelayanan untuk menyelesaikan error yang terjadi pada tahap analisis,
design, coding, dan testing
Mengapa software harus direview?
untuk mengatasi human error
mudah untuk mengatasi error yang dilakukan oleh engineer
Review suatu cara untuk mengidentifikasi peningkatan keperluan dari bagian masing-masing produk
mengkonfirmasikan peningkatan bagian masing-masing produk
mendapatkan teknik bekerja yang lebih uniform, predicable, dan lebih teratur
Perbedaan tipe review :
- informal review :
informal meeting dan informal desk checking
- formal review : (merancang bagi audience customer, management, dan staff) melalui,
inspection, dan round robin review
Terms antara defect dan fault adalah sama
permasalahan kualitas didapatkan setelah software direlease
Kegagalan software tertuju pada permasalahan kualitas yang didapatkan dari engineers sebelum
software direlease.

Formal Technical Reviews (FTR)

- Objective dari FTR :
Untuk mengkover error yang terjadi pada fungsi, logic, atau implementasi
Untuk memverifikasi software diantara review pada masing-masing requirements
Untuk mengensure software yang telah direpresentasikan berdasarkan standard yang belum
terdefinisi
Untuk mengembangkan software pada uniform manner
Untuk membuat project agar lebih teratur
- Tujuan dari FTR :
Memberikan pelayanan berupa training bagi junior engineers
Memberikan backup and continuity
- Batasan-batasan review meeting :
3-5 orang dimasukkan kedalam review
20 |S T M I K Royal

Mengembangkan preparation (tidak lebih dari 2 jam untuk masing -masing orang)
Selang waktu dari review meeting harus kurang dari 2 jam
Terfokus pada bagian yang lebih spesifik dari software produk
Orang-orang yang termasuk pada review meeting :
producer, review leader, 2 atau 3 reviewers (one of them is recorder)
Formal Technical Review Meeting
Preparation dari review meeting
meeting agenda dan schedule (oleh review leader)
review material dan distribution (oleh the producer)
review in advance (oleh reviewers)
Review meeting menghasilkan:
list review issues
report yang terdapat review yang simple
keputusan meeting :
menerima work product w/o further modification
menolak work produk bersamaan dengan error
menerima work berdasarkan kondisi (seperti perubahan dan review)
sign-off sheet
Review summary report (project historical record) menjawab pertanyaan-pertanyaan berikut :
apa saja yang telah direview?
siapa yang telah mereview?
apa saja yang telah ditemukan dan konklusinya?
List review issue memiliki dua tujuan :
untuk mengidentifikasi area masalah pada project
untuk memberikan pelayanan pada aksi-aksi item checklist
Review Guidelines (for FTR)
minimum set dari guidelines untuk FTR:
Review product, tidak pada producer
Set agenda dan maintain
Limit debate dan rebuttal
Enunciate problem areas, tetapi tidak untuk mencegah pencegahan setiap masalah yang telah
tercatat.
memberikan catatan yang telah tertulis
jumlah dari participant dan preparation yang telah diukembangkan
mengembangkan checklist untuk masing- masing produk yang telah direview
mengalokasikan resource dan waktu schedule untuk FTR
menginginkan training agi semua reviewer
- mereview kembali apa yang telah direview

21 |S T M I K Royal

Jaminan Kualitas Statistik

Jaminan kualitas statistik berpengaruh pada perkembangan industri untuk menjadi lebih kuantitatif
tentang kualitas.
Jaminan Kualitas Statistik mengikuti langkah-langkah berikut :
Informasi tentang software yang telah terkumpul dan yang telah dikategorikan.
Untuk mencegah yang menyebabkan trace pada masing- masing masalah
Menggunakan prinsip Pareto (80 persen dapat menyebabkan 20 persen akan di trace dan
diisolaso sekitar 20 persen )
Salah satu hal utama yang menyebabkan masalah tidak terdefinisi
Penyebab dari errors:
incomplete or erroneous specification (IES)
misinterpretation of customer communication (MCC)
intentional deviation from specification (IDS)
violation of programming standards (VPS)
error in data representation (EDR)
inconsistent module interface (IMI)
error in design logic (EDL)
incomplete or erron eous testing (IET)
inaccurate or incomplete documentation (IID)
error in programming language translation of design (PLT)
ambiguous or inconsistent human -computer interface (HCI)
miscellaneous (MIS)
Statistical Quality Assurance
Software developers dapat menghitung error index (EI) untuk masing- masing langkah utama pada
proses software engineering
Setelah proses analisis, design, coding, testing, dan release, maka data berikutnya akan terkumpul :
Ei = jumalh total error yang terjadi selama langkah- langkah proses
Si = urutan error yang terjadi
Mi = urutan moderate error
Ti = urutan minor error
PS = ukuran dari masing-masing produk pada langkah yang ke-I
Pada masing-masing step pada software engineering process phase index (PI i) dapat dihitung :

PI i = ws (Si/Ei) + wm(Mi/Ei) + wt(Ti/Ei)

Error index dapat dihitung dengan rumus berikut :

EI = (PI 1 + 2 PI 2 + 3 PI 3 + iPI I)/PS

Perencanaan dari SQA
Plan SQA menyediakan road map untuk jaminan kualitas software
Gambar 8.5 menampilkan outline dari plan SQA dari IEEE[IEEE94]
22 |S T M I K Royal

Dasar items
tujuan dari perencanaan dan scope
management
struktur organisasi, tugas SQA, lokasi pada proses
aturan dan responsibilities yang berhubungan dengan kualitas prod uk.
dokumentasi
project documents, models, technical documents, user documents
standards, practices, dan conventions
reviews dan audits
test
test plan dan procedure
problem reporting, dan correction actions
tools
code control
media control
supplier control
records collection, maintenance, dan retention
training
risk managements.

Modul-6
Prinsip & Konsep Analisa Kebutuhan
Analisa Kebutuhan
Analisa kebutuhan Adalah Suatu proses penemuan, perbaikan, modeling, dan spesifikasi.
Sepanjang proses, kedua-duanya pelanggan dan pengembang mengambil suatu peran aktif.
23 |S T M I K Royal

Terpusat pada: apa sebagai pengganti bagaimana

Input dari proses analisa kebutuhan:
Rencana Proyek Software - Spesifikasi sistem ( jika terdapat)
Output Adalah Spesifikasi dokumen kebutuhan software - menyediakan software insinyur dengan
model yang dapat diterjemahkan ke dalam data, secara ilmu bangunan, alat penghubung, dan disain
prosedur.
pengembang dan pelanggan dapat memeriksa mutu dari software dan menyedi akan pengaruh
arus balik.
Yang melaksanakan analisa kebutuhan: analis system
- Usaha dan tugas utama :
Pengenalan masalah ( atau pemahaman sistem)
Menemukan dan memahami kebutuhan system
Menyuling kebutuhan
Sintese dan Evaluasi:
apakah yang merupakan solusi alternative
memusatkan pada solusi apa harus dipilih atau digunakan sebagai ganti bagaimana cara
menerapkan suatu solusi.
- Modeling:
untuk menghadirkan berbagai aspek dari system
data yang diperlukan
informasi dan mengendalikan arus
perilaku operasi
- Spesifikasi:
fungsi software, dan tampilan
menghubungkan antar unsur-unsur system
batasan system
- Studi kelayakan:
Mengidentifikasi dan perkiraan untuk melihat jika kebutuhan pemakai dapat dicukupi
dengan menggunakan teknologi dan teknik sekarang.
Analisa kebutuhan:
Proses menurunkan kebutuhan sistem melalui pengamatan atas sistem yang berjalan,
diskusi dengan para pemakai dan pelanggan, analisis tugas, dan seterusnya.
- Definisi kebutuhan:
Menterjemahkan informasi ke dalam suatu REQ. dokumen.
- Spesifikasi kebutuhan:
Menggambarkan kebutuhan sistem yang menggunakan suatu ketepatan yang konsisten, dan
cara lengkap.
Penggunaan beberapa metoda spesifikasi kebutuhan.

24 |S T M I K Royal

Proses Rancang Bangun Kebutuhan

Proses Analisa Kebutuhan
Pemahaman daerah:
Pemahaman daerah aplikasi.
Koleksi kebutuhan:
Proses dari saling berinteraksi dengan pelanggan, para pemakai untuk menemukan
kebutuhan untuk sistem itu.
Penggolongan kebutuhan:
Menggrupkan dan menggolongkan kebutuhan yang dikumpulkan itu.
Resolusi konflik:
Memecahkan kebutuhan konflik.
Prioritisasi:
Mengidentifikasi dan mendaftar kebutuhan menurut kepentingan mereka
Pengesahan kebutuhan:
Memeriksa dan mengesahkan kebutuhan yang dikumpulkan untuk melihat jika mereka lengkap,
benar, dan serasi
Teknik Komunikasi
Memulai Proses
Q1 menetapkan: Konteks bebas bertanya untuk memimpin pemahaman dasar dari masalah
Siapakah di belakang solusi?
Siapa yang akan menggunakan solusi?
Q2 menetapkan: Mempertanyakan untuk memperoleh suatu pemahaman yan g lebih baik
menyangkut masalah dan persepsi konsumen tentang suatu solusi.
Bagaimana kamu akan menandai baik keluaran yang akan dihasilkan oleh suatu solusi sukses?
Apa permasalahan tujuan solusi ini?
Q3 menetapkan: Meta-Questions memusatkan pada efektivitas dari pertemuan.
Apakah kamu orang yang tepat untuk menjawab pertanyaan ini? Apakah jawab mu resmi?

Teknik Spesifikasi Yang Dimudahkan

Software insinyur dan Pelanggan sering mempunyai suatu tak sadar kita dan mereka pikirkan.
Ini mungkin menyebabkan: kesalah pahaman, kehilangan informasi penting,.
Untuk memecahkan masalah, pendekatan FAST diusulkan.
FAST mendorong kreasi dari suatu gabungan regu dari pengembang dan pelanggan.
Mereka bekerja sama untuk mengidentifikasi masalah dan mengu sulkan dan
untuk merundingkan unsur-unsur solusi yang berbeda dan pendekatannya.
Petunjuk dasar dari FAST
pegangan suatu pertemuan pada suatu lokasi netral
menetapkan aturan untuk keikutsertaan dan persiapan
mempunyai suatu agenda rapat formal
mengendalikan pertemuan dasar dengan sebuah penghubung
25 |S T M I K Royal

menggunakan sebuah mekanisme definisi

mempunyai suatu gol umum untuk
mengidentifikasi masalah
mengusulkan unsur-unsur kebutuhan dan solusi
merundingkan pendekatan berbeda
Penyebaran Fungsi Mutu
Penyebaran Fungsi Mutu ( QFD) adalah teknik manajemen mutu
Menterjemahkan kebutuhan dari pelanggan ke dalam kebutuhan teknis untuk software.
QFD mengidentifikasi tiga jenis kebutuhan:
Kebutuhan normal:
Sasaran hasil dan tujuan:
contoh: jenis pajangan grafis, fungsi sistem spesifik
Kebutuhan yang diharapkan:
kebutuhan yang terkandung:
contoh: merampas human-machine interaksi ,merampas software instalasi
Kegairahan kebutuhan:
Corak pergi di luar customers harapan

Prinsip Analisa
Masing-masing metoda analisa mempunyai suatu segi pandangan unik.
Semua metoda analisa terkait oleh satu set prinsip operasional:
menghadirkan dan memahami daerah informasi- menggambarkan fungsi software
menghadirkan perilaku dari software menggunakan model untuk melukiskan informasi,
fungsi, dan perilaku--> membongkar detil di dalam suatu lapisan pertunjukan.
bergerak dari informasi penting ke arah yang lebih detil.
Satu set petunjuk untuk rancang-bangun kebutuhan:
memahami masalah sebelum permulaan untuk menciptakan model analisa
mengembangkan prototipe untuk membantu pemakai untuk memahami bagaimana interaksi
manusia dan mesin
merekam asal dan pertimbangan untuk tiap -tiap kebutuhan
menggunakan berbagai pandangan kebutuhan
memprioritaskan kebutuhan
bekerja untuk menghapuskan kerancuan
Daerah Informasi Software
Software dibangun untuk memproses data, untuk mengubah bentuk data dari yang satu dengan
yang lain.
Software juga memproses peristiwa.
Prinsip analisis operasi yang pertama perlu untuk menguji daerah informasi.
Daerah informasi berisi tiga pandangan yang berbeda menyangkut data dan kendali:
hubungan dan isi informasi:
26 |S T M I K Royal

isi informasi--> menghadirkan data individu dan object kendali ada hubungan berbeda antara
object dan data
- arus informasi:
menghadirkan cara di mana data dan kontrol berubah dari masing -masing gerak melalui suatu
sistem. Data dan control bergerak antara dua perubahan bentuk ( fungsi).
- struktur informasi:
menghadirkan organisasi yang internal dari berbagai data dan materi kendali- struktur pohon
data - data tebel ( n-dimensi)
Pemodelan
Selama modeling software kebutuhan analisa, kita menciptakan model menyangkut sistem untuk
dibangun.
Model terpusat pada :- apa yang sistem harus lakukan, bukan bagaimana sistem
mengerjakan itu.
Model pada umumnya mempunyai suatu notasi grafis untuk dihadirkan:
informasi, pengolahan, perilaku sistem, dan corak lain
Yang kedua dan ketiga analisis operasi prinsip memerlukan:
membangun model perilaku dan fungsi
Model Fungsional
Software Model fungsional mengubah bentuk informasi. Tiga fungsi umum: - masukan,
memproses, keluaran
Model Perilaku
Kebanyakan perilaku model software bereaksi terhadap peristiwa dari dunia luar. Suatu model
perilaku menciptakan suatu penyajian menyangkut status software dan peristiwa yang
menyebabkan perangkat lunak untuk berubah status
Peran penting model:
Model menopang analis di dalam pemahaman informasi, fungsi, dan perilaku dari suatu sistem.
Model menjadi titik -api untuk tinjauan ulang di dalam aspek kelengkapan, konsistensi, dan
ketelitian dari spesifikasi itu.
Model menjadi pondasi untuk disain, menyediakan perancang dengan suatu penyajian penting
dari software.
Penyekatan
Penyekatan menguraikan suatu masalah ke dalam bagian utamanya.
Menetapkan suatu penyajian informasi hirarkis ( atau fungsi):
pembongkaran terus meningkat detil dengan bergerak secara vertical di dalam hirarki
menguraikan masalah bergerak secara horisontal di dalam hirarki

Prototipe Software
Dalam beberapa hal adalah mungkin untuk menerapkan analisis operasi prinsip dan memperoleh
suatu model software dari suatu disain yang dapat dikembangkan.
Memilih pendekatan prototipe:
27 |S T M I K Royal

Pendekatan closed-ended disebut lembaran prototype iklan.

Sebuah prototipe melayani sebagai demonstrasi keras dari kebutuhan.
Pendekatan open-ended disebut evolusiner membuat prototip.
suatu prototipe bertindak sebagai evolusi pertama dari sistem yang telah selesai.
Gambar 11.7 memilih pendekatan prototipe yang sesuai.
Prototipe Perkakas dan Metoda:
Teknik Generasi Keempat
Komponen Software dapat dipakai kembali
Spesifikasi Formal dan Lingkungan Prototipe

Spesifikasi Software
Prinsip Spesifikasi
Memisahkan kemampuan dari implementasi
Mengembangkan suatu model menyangkut perilaku yang diinginkan dari suatu system
Menetapkan konteks di mana software beroperasi
Menggambarkan lingkungan di mana sistem beroperasi
Menciptakan suatu model teori dibanding suatu implementasi atau disain model
Spesifikasi adalah suatu model abstrak dari suatu sistem riil
Menetapkan struktur dan isi dari suatu spesifikasi ( mudah untuk diubah)
Petunjuk untuk penyajian:
Isi dan Format penyajian harus relevan kepada masalah
Informasi yang dimasukkan di dalam spesifikasi harus sekumpulan
Diagram dan notasil format lain harus terbatas dalam jumlah dan digunakan secara konsisten.
Penyajian harus bisa berhadap-hadapan kembali
Standar spesifikasi kebuthan software:
IEEE ( standard No. 830-1984) dan U.S. Departemen Pertahanan
Dalam banyak kesempatan, suatu persiapan penggunaan manual harus disajikan untuk
menghadiahi perangkat lunak sebagai black-box.

Modul-7
Pemodelan Analisa
Analisa model (sekumpulan model) adalah langkah pertama memberikan gambaran teknis.
Dua tipe analisa model: analisa struktur, analisa berorientasi object.
Analisa struktur adalah metode pemodelan klasik.
28 |S T M I K Royal

Deskripsi tentang analisa struktur oleh Tom Demarco[DEM79].

Produk/ hasil analisa harus yang sangat dapat dipelihara.
Cara efektif untuk mempartisi permasalahan Menggunakan notasi grafis
Membedakan bagian logis dan phisik
Menjaga kesinambungan antar model
Tool baru untuk memberikan gambaran kebijakan dan logika
Sejarah pemodelan analisa:
Pada akhir tahun 1960an dan awal tahun 1970, awal pekerjaan di dalam pemodelan analisa
dimulai diperagakan.
analisa struktur dimasukkan oleh Douglas Ross pada [DEM79].
Pada pertengahan tahun 1980, analisa struktur mulai diragukan
Ward dan Mellor, dan yang lainnya diperkenalkan ekstensi untuk real-time pada 1985.
Notasi konsisten berikutnya [BU88] diusulkan pada tahun 1988.
CASE tool [YOU89] digunakan pada tahun 1989.

Elemen -elemen Pemodelan Analis

Tiga sasaran pokok model analisa:
1) untuk menguraikan apa yang dibutuhkan pelanggan
2) sebagai pedoman dalam pembuatan suatu desain software
3) untuk mendefinisikan sekumpulan kebutuhan yang dapat diwujudkan
Komponennya a.l:
kamus data
berisi uraian dari semua object data dalam software
- Entity-relationship diagram (ERD)
menetapkan atribut data dari obyek data.
melukiskan hubungan antar obyek data.
- Data flow diagram (DFD)
menyediakan suatu indikasi bagaimana data ditransformasikan melalui sistem itu
melukiskan fungsi yang mentransform data flow
- State-transition diagram(STD)
menandai bagaimana sistem bertindak sebagai sebuah konsekuensi dari event(peristiwa)
eksternal.

Pemodelan Data
Pemodelan Data menjawab sekumpulan pertanyaan spesifik:
Apa obyek data utama yang akan diproses pada sistem?
Apa komposisi tiap obyek data?
Apa atribut yang menggambarkan obyek?
Relasi apa antara tiap obyek dan obyek lainnya?
29 |S T M I K Royal

Apa relasi antara obyek dan proses yang terkait?

Masalah apa yang akan menjadi solusinya?
Model ERD :
ERD adalah sebuah metode yang sangat berguna untuk pemodelan data .
Fokus pada data, merepresentasikan sebuah data network pada sistem.
Merepresentasikan: obyek data, atribut obyek, dan relasi antara obyek
Kardinalitas:
Spesifikasi menyangkut banyaknya kejadian dari satu(obyek) yang dapat dihubungkan dengan
banyaknya kejadian yang lain(obyek).
Tiga tipe:
One-to-one (1:1)
One-to-many (1:N)
Many-to-many (M:N)
Suatu cara dilakukan kepada pasangan relasi obyek.
Mandatory(Wajib):
menetapkan bahwa obyek penting untuk semua situasi
bagi suatu relasi.
Optional:
menyiratkan bahwa mungkin ada suatu situasi di mana obyek tidak penting bagi suatu
hubungan.

Pemodelan Functional dan Aliran Informasi

Informasi diubah saat mengalir melalui suatu sistem berbasis-komputer.
Beberapa model digunakan:
Data flow diagrams (DFDs)
Perluasan untuk sistem real-time
Perluasan Ward dan Mellow
Perluasan Hately dan Pirbhai.
Ward dan Mellow melakukan perluasan mereka untuk suatu sistem real-time:
Aliran informasi yang dikumpulkan atau diproduksi pada suatu basis time-continuous
mengendalikan informasi yang dilewati melalui sistem dan berhubungan dengan proses kendali.
berbagai kejadian menyangkut transformasi yang sama dengan situasi multitasking.
status sistem dan mekanisme yang menyebabkan transisi antar state.

Mekanika Analisa Struktur

Menggunakan ERD untuk menetapkan:
obyek data (obyek data input, internal, dan output),
atribut di dalam obyek data
relasi diantaranya cardinalitas dan modality-nya
Sebagai tambahan, hirarki menambahkan obyek data, dan relasi asosiasi dan pengumpulan data.
Menggunakan DFD untuk menetapkan model domain informasi dan domai n fungsi.
30 |S T M I K Royal

DFD Level 0
suatu sistem pokok model (suatu konteks model)
merepresentasikan keseluruhan software sebagai satu proses dan input dan output -nya.
DFD Level 1
merepresentasikan aliran data dalam kaitan dengan partisi proses ..
Menggunakan CFD untuk menetapkan model con trol flow sistem.
Menggunakan CSPEC (seperti STD) untuk menetapkan perilaku state sistem.
Spesifikasi Control Flow
Spesifikasi control flow menggunkan sebuah control flow diagram (CFD) untuk menetapkan control
flow pada sistem.
sebuah state-transition diagram (STD) - suatu spesifikasi urutan perilaku.
Model Perilaku
Spesifikasi control (CSPEC) merepresentasikan perilaku sistem.
sebuah state-transition diagram (STD) suatu urutan spesifikasi perilaku.
Spesifikasi Proses
Spesifikasion proses (SPECS) digunakan untuk menggambarkan semua proses model aliran yang
muncul pada level akhir perbaikan.
Dua metode representasi:
teks narasi
sebuah bahasa desain pemrograman/program design language(PDL)
Kamus Data
Mengapa Kamus Data:
Untuk menyediakan deskribsi terorganisir untuk menggambarkan karakteristik tiap data obyek
dan item yang dikontrol.
Apa itu Kamus Data?
Kamus data adalah suatu daftar terorganisir dari semua elemen -elemen data yang berkait dengan
sistem, dengan definisi tepat, kaku sehingga analis sistem dan user akan mempunyai suatu
pemahaman umum input, output, dan komponen -komponen penyimpanan, dan bahan kalkulasi.
Format kamus data:
nama
alias
dimana-digunakan/bagaimana-menggunakan
deskripsi isi
informasi tambahan (tipe, batasan)
Data gabungan:
sebagai sebuah urutan item data
sebagai sebuah seleksi dari sekumpulan item data
sebagai sebuah pengulangan grup item data

31 |S T M I K Royal

Modul-8
Konsep dan Prinsip Desain
Desain Software dan Software Engineering
Desain -> Langkah pertama dalam fase pengembangan untuk prodengineer manapun.
Bertindak sebagai pondasi untuk semua software engineering dan pemeliharaan software dengan
langkah -langkah yang mengikutinya.
Tujuan seorang perancang adalah menghasilkan suatu model(atau penyajian) dari sebuah entitas
yang akan dibangun
- Input desain software : Model analisa kebutuhan dan dokumentasi spesifikasi
- Output desain software : Model desain dan dokumentasi spesifikasi desain
Desain - menerjemahkan kebutuhan ke model desain lengkap untuk sebuah produk software.
menyediakan representasi software yang dapat diduga untuk kualitas.

Desain Software
Sejumlah metode desain dapat digunakan untuk menghasilkan desain software:
Desain data: mentransformasi model domain informasi ke struktur data
Desain arsitektur: menggambarkan relasi antar elemen struktural utama program
Desain interface : mendeskripsikan bagaimana software berkomunikasi with user
Desain prosedur: mentransformasikan elemen structural arsitektur program ke sebuah
deskripsi prosedur dari komponen software.
Evolusi desain software:
Konstruksi program modular[DEN73] dan metode perbai kan top-down[WIR71].
Pemrograman terstruktur [DAH71, MIL72].
Perpindahan data flow/data structure ke sebuah defenisi desain[JAC75][WAR74].
Pendekatan berorientasi object[JAC92][GAM95].
Fitur umum metode desain software:
Sebuah mekanisme untuk perpindahan sebuah model analisa ke representasi desain
Sebuah notasi untuk merepresentasi komponen fungsional dan interface -nya.
Heuristic untuk perbaikan dan partisi
Panduan untuk assessment kualitas

Proses Desain
Desain software --> sebuah proses iteratif dimana kebutuhan diterjemahkan ke sebauh blueprint
untuk mengkonstruksi software.
Desain direpresentasikan pada level atas abstraction. Saat iterasi desain terjadi, perbaikan
subsequent membawa ke representasi desain pada level abstraksi yang lebih bawa h.
Kualitas desain sangat penting. Dua metode digunakan untuk mengecek kualitas:
Tinjauan ulang teknis formal, dan b) desain walkthrough
Tiga fitur umum sebuah desain yang baik dari McGlaughlins [McG91]:
32 |S T M I K Royal

1. Desain harus mengimplementasikan semua kebutuhan(eksplisit/implisit)

2. Desain harus dapat dibaca dan dimengerti
3. Desain harus menyediakan suatu gambar lengkap software pada aspek -aspek data, fungsi dan
perilaku.

Kualitas Desain
Untuk mengevaluasi sebuah desain software, sebauh criteris kualitas desain dapat digunakan.
Berikut panduan untuk sebuah desain yang baik:
Sebuah desain harus A design should exhibit a hierarchical organization about software
Sebuah desain harus modular berdasarkan pada partisi logical.
Sebuah desain terdiri dari data dan abstraksi prosedural.
Sebuah desain harus membawa ke modul dengan fitur fungsional yang independen.
Sebuah desain harus membawa interface yang sederhana antar modul.
Sebuah desain harus diturunkan menggunakan metode yang dapat berulang.
Proses desain software memacu desain yang baik dalam aplikasi dengan prinsip desain fundamental,
metodologi yang sistematik, dan melalui review(pengulangan).

Prinsip Desain
David [DAV95] memaparkan sekumpulan prinsip untuk desain software:
Proses desain seharusnya tidak bertahan dari tunnel vision.
Desain harus dapat di trace ke model analisa.
Desain seharusnya tidak menemukan/invent wheel.
Desain harus memperkecil jarak intellectual antara software dan masalah-masalah pada dunia
nyata.
Desain harus mengeluarkan uniformity dan integrasi.
Desain harus terstruktur untuk mengakomodasi perubahan.
Desain harus terstruktur untuk mendegradasi secara halus(degrade gently).
Desain bukan coding.
Desain harus di-assessed untuk kualitas.
Desain harus diulang untuk meminimalis kesalahan konsep.
Faktor kualitas eksternal: diobservasi oleh user.
Faktor kualitas internal: penting untuk engineer.

Konsep Desain
Abstraksi:
Tiap langkah pada proses software engineering adalah sebuah perbaikan pada tingkatan abstraksi
dari solusi software.
Abstraksi data: Sekumpulan data
Abstraksi prosedural:
Satu urutan instruksi pada sebuah fungsi spesifik
Abstraksi kontrol:
33 |S T M I K Royal

Sebuah program mengkontrol mekanisme tanpa menspesifikasikan detail internal.

Refinement(perbaikan): Perbaikan sebenarnya adalah sebuah proses dari elaborasi.
Stepwise dari perbaikan adalah sebuah strategi desain top-down dikeluarkan oleh Niklaus [WIR71].
Arsitektur sebuah program dikembangkan dengan sukses memperbaiki level detail
procedural.
Proses perbaikan program analog terhadap proses perbaikan dan partisi yang digunakan selama analisa
kebutuhan. Perbedaan utama berada pada level detail implementasi, disamping pendekatannya.
Abstraksi dan perbaikan secara komplemen dikonsep.
Abstraksi memungkinkan seorang desainer untuk menspesifikasi prosedur dan data w/o detail.
Perbaikan membantu desainer untuk me -reveal detail low-level.
Konsep Desain - Modularity
Konsep modularity telah dipakai selama hampir empat dekade. Software dibagi komponen dengan
nama dan alamat yang berbeda, disebut modul.
Meyer [MEY88] mendefenisikan lima kriteria yang memungkinkan kita mengevaluasi sebuah metode
desain dengan bergantung kepada kemampuannya mendefenisikanfive sebuah sistem modular efektif:
- Modular decomposability:
sebuah metode desain menyediakan sebuah mekanisme sistematik untuk mendecompose atau
membagi masalah ke sub-masalah mengurangi kompleksitas dan mendapatkan modularity
- Modular composability:
sebuah metode desain memungkin kan komponen desain yang telah ada dirakit ke sebuah sistem
baru.
- Modular understandability:
sebuah modul dapat dimengerti sebagai sebuah unit yang berdiri sendiri dan akan lebih mudah
membangun dan mengubahnya.
- Modular continuity:
perubahan kecil terhad ap kebutuhan sistem menghasilkan perubahan pada tiap modul, dibanding
perubahan system-wide.
- Modular protection:
sebuah kondisi aberrant terjadi dalam sebuah modul dan efeknya di-constrain dalam modul.

Arsitektur Software
Arsitektur software adalah struktue hirarki dari komponen program components dan interaksinya. Shaw
dan Garlan [SHA95a] menggambarkan sekumpulan properti desain arsitektur:
Properti structural :
Desain arsitektur mendefenisikan komponen sistem dan interaksinya.
Properti extra-functional :
Desain arsitektur harus meng -address bagaimana arsitektur desain menerima kebutuhan untuk
performance, kapasitas, ketersediaan(reliability), adaptability, keamanan.
Kumpulan sistem yang berhubungan:
desain arsitektur harus menggambar pola yang dapat diulang pada desain dengan sistem yang
sama.
34 |S T M I K Royal

Model structural: merepresentasikan arsitektur sebagai sebuah koleksi terorganisir dari komponen
Model framework: meningkatkan level desain abstraksi dengan mengidentifikasi secara berulang
framework desain arsitektur(pola-pola)
Model dinamis: meng-address aspek-aspek perilaku arsitektur program
Model prosess: fokus pada desain bisnis atau proses teknis
Model functional: dapat digunakan untuk merepresentasikan hierarki fungs ional sebuah sistem
Partisi Structural
Struktur program harus dipartisi secara horizontal dan vertikal.
Partisi horizontal menggambarkan cabang -cabang yang terbagi dari hierarki modular untuk tiap fungsi
program utama.
Cara termudah adalah mempartisi sebuah sistem menjadi:
input, transformasi data(pemrosesan), dan output
Keuntungan dari partisi horizontal:
mudah untuk diuji, di-maintain, dan extend
efek yang lebih kecil pada perubahan propagasi atau error propagasi
Kerugian: lebih banyak data dilewatkan melalui interface modul
menyulitkan kontrol keseluruhan dari aliran program
Partisi vertical memaparkan kontrol dan work harus terdistribusi top-down dalam struktur program.
Keuntungan: baik pada kesesuain untuk perubahan:
mudah untuk me-maintain perubahan
mengurangi pengaruh perubahan dan propagasi.
Desain Modular Efektif
Informasi yang disimpan:
Modul-modul seharusnya dispesifikasi dan didesain sehingga detail internal dari modul darus dapat
terlihat atau dapat diakses terhadap modul lainnya.
Keuntungan utama: mengurangi pengaruh perubahan pada testing(pengujian) dan
maintenance(perawatan).
Independen fungsional:
Mendesain modul-modul berdasarkan fitur fungsional independen.
Keuntungan utama: modularity efektif
Cohesion: sebuah ekstensi alami dari konsep informasi yang disimpan
sebuah modul dapat menampilkan sejumlah tusk
Sebuah modul cohesive menampilkan sebuha task tunggal dalam sebuah prosedur dengan interaksi
kecil dengan lainnya.
Goal: untuk mencapai cohesion yang tinggi untuk modul -modul pada sebuah sistem.
Tipe-tipe yang berbeda dari cohesion:
coincidentally cohesive: sekumpulan task yang berhubungan satu sama lain
secara bebas.
35 |S T M I K Royal

logically cohesive: koneksi logical antara elemen-elemen pemrosesan

communication cohesion: data di-share antar elemen-elemen pemrosesan procedural cohesion:
pemesanan antara elemen-elemen pemrosesan
Coupling: (Gambar 13.8)
Suatu ukuran interkoneksi antar modul -modul dalam sebuah struktur program.
Coupling tergantung pada kompleksitas interface antar modul.
Goal: mencoba untuk coupling terendah yang mungkin antar modul.
Coupling yang baik
mengurangi atau mencegah pengaruh perubahan dan efek ripple.
mengurangi biaya pada perubahan program, testing, maintenance
Tipe-tipe coupling:
data coupling: parameter passing atau interaksi data
control coupling: share logical kontrol yang berhubungan (untuk sebuah data kontrol)
common coupling: sharing data umum
content coupling: modul, penggunaan data atau pengontrolan informasi di- maintain modul lain.

Modul-9
Software Architecture Design
Software Architectural Design
Sistem yang besar dapat dipecah dalam sub sistem yang memiliki beberapa kumpulan relasi service.
Desain arsitektur mengacu pada :
pembagian sistem dalam sebuah sub sistem logika dan modul -modul
mengidentifikasi interaksi dan relasinya
Penstrukturan sistem :
Sistem disusun dalam beberapa principal sub- sistem
Masing-masing adalah unit software yang bebas, dan berkomunikasi satu sama lain.
Permodelan kontrol:
membuat model umum relasi kontrol antara bagian sistem
Modular decomposition:
Membagi tiap sub sistem ke dalam modul- modul kecil Desainn arsitektur harus mengidentifikasi
modul-modul ini dan pengaruhnya.

Architectural Design - The Repository Model

Dua cara untuk memakai informasi data bersama-sama pada lingkungan terdistribusi :
Share a central database
Tiap sub sistem dibuat database lokal
Model Penyimpanan (Model Repository):
36 |S T M I K Royal

Keuntungan : cara efisien untuk share d ata dalam jumlah yang besar
Kerugian : - Sub sistem harus di-share pada model data penyimpanan yang sama
Evolusi sistem sulit
Masalah toleransi kesalahan
Sub sistem yang berbeda kemungkinan mempunyai kebutuhan yang berbeda.
Software Architecture
Arsitektur perangkat lunak adalah struktur terurut dai komponen program dan interksinya.
Shaw and Garlan [SHA95a] mendeskripsikan properti desain arsitektur :
Properti Struktural:
Desain arsitektur mendefinisikan komponen sistem dan interksinya.
Properti ekstra-fungsional:
Desain arsitektur harus mengalamati dimana penyimpanan desain arsitekturnya requirements
untuk performance, capacity, reliability, adaptability, security.
Families of related systems:
desain arsitektur harus menggambarkan bentuk perulangan pada desain keluarga pada sistem yang
sama.
Metode desain arsitektur yang lain :
Structural models: merepresentasikan arsitektur sebagai sebuah kumpulan komponen yang sudah
tersusun.
Framework model menambah tingkat abstraksi desain dengan mengidentifikasi berulang-ulang.
architecture design frameworks (patterns)
Dynamic models: mengalamati aspek behavior pada arsitekutur program
Process models: fokus pada desain bisnis dan proses teknis
Functional models: biasanya dapat merepresentasikan susunan fungsional sistem
Structural Partitioning
Program terstruktur biasanya dibagi secara horisontal dan vertikal
(1) Pembagian horisontal mendefinisikan cabang terpisah pada hirarki modular untuk tiap
fungsi utama program.
Cara paling simpel adalah membagi sistem dalam:
input, data transformation (processing), dan output
Keuntungan pembagian horisontal:
mudah di tes, dikembangkan dan diperluas
berpengaruh lebih kecil sewaktu terjadi perubahan dan error
Kerugian: banyak data yang dilewati pada module interfaces compleks pada keseluruhan kontrol
aliran program
(2) Pembagian vertikal menekankan control dan kerja harus terdistribusi atas -bawah pada
37 |S T M I K Royal

struktur program.
Keuntungan : bagus pada hal yang behubungan dengan perubahan:
mudah untuk memaintain perubahan
mengurangi pengaruh dan penyebaran bila terjadi perubahan

Architectural Design - The Client -Server Model

Componen utama pada model ini:
Kumpulan server yang berdiri sendiri yamg menawarkan servis untuk sub sistem yang lain
Kumpulan client yang memanggil servis yang diberikan server
Sebuah jaringan yang memungkinkan client untuk mengakses servis ini
Keuntungan paling utama: distribusi akses user dan jari ngan terpusat

Architectural Design - The Abstract Machine Model

Model mesin abstrak (a layered model):
Menyusun sistem dalam sebuah rangkaian layer dimana, tiap layer menyediakan rangkaian servis.
Tiap layer mendefinsikan mesin abstrak. Contohnya adalah Model OSI.
Mendukung pengembangan sistem.
Keuntungan: changeable and portable.
Kerugian:
penstrukturan sistem sulit.
Performance bisa jadi masalah.

Architectural Design - The Control Model

Model kontrol berhubungan dengan aliran kontrol antar sub sistem.
Model kontrol tambahan untuk model terstruktur.
Dua pengembangan umum: a) centralized control and b) event -based control
Event-based control:
tiap sub sistem dapat merespon kejadian yang terjadi secara eksternal.
Model kontrol berhubungan dengan aliran kontrol antar sub sistem.
Model kontrol tambahan untuk model terstruktur.
Dua pengembangan umum: a) centralized control and b) event -based control
Event-based control:
tiap sub sistem dapat merespon kejadian yang terjadi secara eksternal.

Data Design
Panduan untuk desain data:
Tentukan analisa sistematis data
38 |S T M I K Royal

data objects, relationships, dan data flow beserta isinya

Identifikasi semua data dan operasi yang berhubungan dengannya
Buat kamus datanya (data dictionary)
data objects dan relationshipnya beserta semua constraints
Bedakan keputusan desain low-level sampai dengan proses desainnya
Gunakan informasi yang tersembunyi pada desain struktur data
Library yang berguna untuk struktur data dan operasi
reusable data objects
reusable data structure templates
Gunakan desain software dan bahasa pemrograman untuk mendukung spesifikasi dan abstraksi Data.

Modul-10
Metode Desain
Metode -metode Desain Software
Desain --> sebagai sebuah proses dengan beberapa tahap dimana kita mendesain:
a) struktur data
b) struktur program
c) karakteristik interface
d) detail prosedur berdasarkan pada informasi kebutuhan.
Perubahan bentuk memproses dari model analisa kebutuhan
menghasilkan spesifikasi desain
Desain data:
Focus utama adalah struktur data dan representasi logikanya untuk tiap komponen pada sebuah
sistem software.
Artinya: informasi yang disembunyikan dan abstrak data
Desain arsitektur dan desain struktural
Sasaran pokok adalah mengembangkan suatu struktur program modular dan merepresentasikan
hubungan kendali antar modul-modul.
Menyediakan suatu gambaran arsitektur tentang sistem software.

Metode Desain Software

Desain interface :
Fokus utama adalah:
desain interface antara modul-modul software
desain interface antara software dan komponen-komponen eksternal, seperti hardware.
desain user interface
Desain prosedur atau desain yang terperinci:
Sasaran utama adalah untuk menyediakan algoritma dan desain detil yang berorientasi prosedur
untuk tiap tugas atau fungsi suatu modul.
39 |S T M I K Royal

Gunakan satu bahasa spesifikasi yang jelas untuk menulis prosedur.

Desain Data
Panduan desain data :
Terapkan analisa yang sistematis terhadap data
obyek data, relasi, dan aliran data sebagai isi.
Identifikasi semua struktur data dan operasi yang berhubungan
Menetapkan suatu kamus data
obyek data dan relasinya sebagai batasan
Menunda keputusan desain yang low-level sampai di dalam proses desain
Gunakan informasi yang tersembunyi dalam desain struktur data
Suatu perpustakaan dari operasi dan struktur data yang bermanfaat
data obyek yang dapat digunakan kembali
template struktur data yang dapat digunakan kembali
Gunakan sebuah desain software dan bahasa pemrograman untuk mendukung spesifikasi data dan
abstraksi.

Desain File Data

Panduan untuk File Data:
Desain untuk file data:
a) tipe dan struktur file :
file text ASCII, file sequential, file direct access, file index
ukuran buffer dan ukuran record
b) Struktur file record:
field data, tipe data, dan format
c) Aplikasi file data:
konfigurasi, data aktif, data input/output, log operasi
d) Operasi file data:
open(buka), close(tutup), creation(membuat), deletion(menghapus),read and update (membaca
dan memperbaharui)
e) Operasi untuk record data:
append(menambah),insert(menyisipkan),delete(menghapus),update(memperbaharui),read(membaca)

Desain Database
Evaluasi ERD untuk database.
obyek data
relasi
atribut data pada tiap obyek
Perbaikan ERD pada relasi, atribut data.
Memilih tipe target database:
database jaringan
database relasi
40 |S T M I K Royal

database berorientasi obyek

Gambarkan skema database:
Gambarkan tabel atau obyek database
Tentukan key data(primary key d an foreign key)
Tentukan tipe data
Tentukan nilai default
Normalisasi skema database
Menulis defenisi database dalam sebuah bahasa pre-defined (dengan sebuah vendor database)
Langkah -langkah Desain Software:
Langkah 1: Tinjau ulang model sistem pokok
Langkah 2: Tinjau ulang dan refine diagram aliran data untuk software
Langkah 3: Tentukan apakah DFD memiliki mempunyai karakteristik flow transformasi atau
transaksi.
Langkah 4: Isolasikan pusat transformasi dengan penetapan batasan flow yang datang dan
keluar.
Langkah 5: Lakukan first-level factoring
Langkah 6: Lakukan second-level factoring
Langkah 7: Refine iterasi pertama struktur program menggunakan desain heuristic untuk
meningkatkan kualitas software.
Langkah -langkah Pemetaan Transaksi:
Langkah-langkah desain untuk pemetaan transaksi adalah sama dan dalam beberapa kasus identik
dengan langkah-langkah untuk pemetaan transformasi. Perbedaan utama pada pemetaan dari DFD ke
struktur software.
Langkah 1: Tinjau ulang model sistem pokok
Langkah 2: Tinjau ulang dan refine diagram aliran data untuk software
Langkah 3: Tentukan apakah DFD memiliki mempunyai karakteristik flow transformasi atau
transaksi.
Langkah 4: Isolasikan pusat transaksi dan karakteristik aliran sepanjang tiap action path.
Langkah 5: Petakan DFD dalam sebuah struktur program yang amenable terhadap proses
transaksi.
Langkah 6: Faktor-kan dan refine struktur transaksi dan struktur tiap action path.
Langkah 7: Refine iterasi pertama struktur program menggunakan design heuristic untuk
meningkatkan kualitas software.

Desain Prosedur
Desain prodedur terjadi setelah desain data, arsite ktur, dan interface dibangun . Ini menggambarkan
detail algoritmic.
Kita dapat menspesifikasi desain detail dalam sejumlah cara:
A) Pemrograman struktur
menggunakan konstruksi, seperti sequence(urutan), condition(kondisi), dan
repetition(pengulangan) untuk menspesifikasi algoritma.
41 |S T M I K Royal

B) Notasi desain grafis

flowchart (Gambar 14.17, dan 14.18),
box diagram (Gambar 14.19)
C) Notasi desain tabular (tabel keputusan pada Gambar 14.20, 14.21)
Tabel keputusan menyediakan sebuah notasi yang menerjemahkan action dan kondisi
(digambarkan pada narasi proses) ke bentuk tabular
D) program design language (PDL) atau bahasa desain program
dikenal sebagai structured English atau pseudocode (Gambar 14.22)

Modul-11
Interface Design
Interface Design
Desain interface berfokus pada tiga area:
desain interfaces antar modul software
desain interfaces antara software dan prosedur non manual yang lain dan informasi customer
desain interface antara manusia dan komputer
Desain internal and external interface:
desain interface program internal, ---> dinamakan desain intermodular interface -----> interfaces
antara proses fungsional internal dalam DFD.
memetakan transaksi dengan proses.
Desain external interface ---->
memeriksa external entities dalam DFD.
mendesain interface antara external entities dan proses internal.
mengerjakan sesuatu pada data externaldan kontrol eksternal

User Interface Design Principles

Kebiasaan user:
Interface harus menggunakan aturan dan konsep yang diperoleh dari pengalaman user terdahulu.
Ketentuan:
Interface harus konsisten pada operasi yang sama yang harus diaktifkan pada suatu saat.
Minimal surprise:
User seharusnya tidak pernah terkejut dengan behavior sistem
Recoverability:
interface harus memasukkan mekanisme untuk mengijinkan user menemukan error.
konfirmasi tindakan yang merusak fasilitas untuk undo
Pedoman user:
interface harus menggabungkan beberapa bentuk context -sensitive pedoman user dan asisten.
42 |S T M I K Royal

Interface Design Guidelines

Interaksi umum:
konsisten/tetap
Menyediakan feedback yang berarti
Menanyakan verifikasi tindakan yang dapat merusak sistem
Mengijinkan beberapa tindakan untuk dapat kembali dengan mudah
Mengurangi beberapa informasi yang harus diingat antara tindakan
Memberikan efisiensi pada dialog, gerakan, dan pikiran
Mentoleransi kesalahan
Menggolongkan tindakan sesuai fungsi dan mengorganisasikan sesuai dengan screen
geography
Menyediakan fasilitas bantuan yang sensitif
Memekai kata-kata yang sederhana atau pendek untuk menamakan perintah

User System Interactions

Model Interaksi:
A) manipulasi langsung:
iterface manipulasi langsung memberikan user model informasi spacenya. Mereka berinteraksi
dengan informasi ini melalui tindakan langsung, misalnya penggantian informasi, pemindahan
informasi dan sebagainya.
contohnya: editor layar atau work processors
B) sistem menu:
pada interface menu, user memilih satu atau beberapa kemungkinan untuk memberi perintah
kepada mesin. Mereka bisa memakai mouse, seperti menunjuk, memindahkan, memilih.
C) Interface Command-line:
interface perintah membutuhkan user mengetikan teks perintah pada sistem. Perintahnya bisa
jadi query, permintaan untuk servis tertentu atau mungkin lanjutan dari perintah yang lain.
Manipulasi langsung:
Keuntungan :
User merasa komputer berada dalam kontrol dan tidak ketakutan karenenya.
Waktu pembelajaran user relatif pendek.
User mendapatkan feedback dengan segera untuk tindakannya. Kesalahan dapa t dideteksi dan
dikoreksi dengan cepat.
Masalah:
Bagaimana model dan ilustrasi informasi yang tepat dapat diperoleh?
Memberikan user space informasi yang besar, bagaimana mereka dapat menjalankan sepanjang
space-nya dan selalu mengetahui posisisnya sekarang?
Interface-nya biasanya kompleks.
Satu pengembangan simpel:
43 |S T M I K Royal

form pada interface berikut:

Sistem menu:
(a) Menu pull-down: (terprediksi, tapi butuh lebih banyak
screen space)
Menampilkan judul menu.
User dapat memilih perintah yang ada pada menu ini.
(b) Menu pop -up: (fleksibel, dapat disesuaikan, mungkin
membuat user terkejut)
Berhubungan dengan entity(misalnya sebuah field).
Memilih entity ketikan tombol mouse di klik.
--> Menyebabkan menu ditampilkan.
Keuntungan:
- User tidak perlu tau nama perintahnya.
- Meminimalkan pengetikan.
- Beberapa error karena user bisa dihindari.
- Bantuan keadaan saling ketergantungan dapat disediakan.
Masalah:
- Perawatan stuktur menu yang besar.
Solusi: a) scrolling menus, b) hierarchical menus
c) walking menus,
d) associated control panels
Interface Command-line:
Keuntungan:
Implementasinya mudah dan simpel sesuai dengan bahasa pemrosesan.
Dapat mendukung sistem yang sangat kompleks dengan banyak perintah.
User interface memerlukan sedikit effort.
Meminimalkan pengetikan.
Beberapa error karena user bisa dihindari.
Bantuan keadaan saling ketergantungan dapat disediakan.
Problems:
User harus mempelajari dan mengingat semua perintah
Berat untuk mempelajari sistem dan tidak mudah untuk mengoperasikannya.
User pasti membuat error.
Perhatian: interface command-line and interface menu-based tidak saling terpisah.

Model Interface
GUI interfaces dengan well-predefined format dan gaya GUI.
(X windows and Motif, Micro software Windows, .)
Termasuk elemen-elemen:
buttons, switches, menus, indicators, displays, sliders.
windows, panels, dialog boxes,
icons, tool bars, .
44 |S T M I K Royal

Keuntungan:
GUI sangat interaktif sesuai dengan GUI styles/ formats.
sangat mudah untuk dipelajari dan dioperasikan.
Masalah:
GUI styles and formats harus distandarisasi.
desain GUI rumit.
implementasinya kompleks dan luas.
Biasanya merupakan kombinasi dari:
menu-systems, command-line interfaces,
direct manipulation, ...

Information Representation
Ada beberapa cara untuk merepresentasikan informasi dalam user interface:
Text, data, tabel
gambar 2-D (or 3-D), diagram
Multi-media (gambar, animasi, suara, video, )
Representasinya dapat digunakan faktor berikut:
warna, ukuran, gerakan, resolusi,
layar (or window) layout, operational sequence
GUI hierarchical structure
Tipe representasi informasi:
Input data (data yang diketikan, data terpilih, default data)
Output data, tabel, report, diagram, or gambar
pesan kesalahan (Error messages) dan pesan peringatan(waning messages)
GUI elements:
windows (screens), panels
menus (pull-down, pop-up, nested-menu)
buttons, tool bars, icons
check list, selection list, choice box, radio box
text field, text area, label,
Information Representation - Display
Display Guidelines:
Tampilkan informasi yang relevan pada konteks saat ini.
Jangan menyembunyikan datadari user, gunakan format presentasi.
Gunakan label yang konsisten, singkatan yang standar, dan warna yang terlihat
Ijinkan user untuk mengembangkan konteks visual.
Hasilkan pesar error yang berarti.
Gunakan upper dan lower case, indention, dan text grouping untuk membantu pemehaaman
user.
Gunakan windows untuk menggolongkan informasi dengan tipe yang berbeda.
45 |S T M I K Royal

Gunakan tampilan analog untuk merepresentasikan informasi yang lebih mudah dipahami
dengan form representasi ini.
Perimbangkan ketersediaan tempat pada layar dan gunakan dengan efektif.
Information Representation - Input
Input Data Guidelines:
Minimalkan jumlah input yang dibutuhkan untuk action user.
(selective data, default data)
Pertahankan konsistensi antara informasi yang ditampilkan dengan input data.
(color, size, and placement)
Interaksi harus fleksibel tetapi juga sesuai dengan mode yang dipilih input user. (for example,
keyboard input, or mouse input)
Nonaktifkan perintah yang tidak bisa dilakukan pada konteks saat ini.
Biarkan user mengatur aliran interaktif.
Sediakan bantuan untuk membantu semua action input.
Hilangkan input mickey mouse (default values)

User Guidance
Tiga tipe petunjuk user:
- Pesan yang dihasilkan sistem dalam merespon tindakan user
- Sistem bantuan on-line
- Dokumentasi yang melengkapi sistem

User Documentation
User Interface Evaluation
Evaluation Guidelines:
Kuisioner yang mengumpulkan informasi dari user tentang interface:
Pembelajaran:
berapa lama yang dibutuhkan user baru untuk terbiasa dengan operasi sistem?
Kecepatan operasi:
seberapa bagus respon sistem cocok dengan praktek kerja user?
Kelemahan:
bagaimana toleransi sistem terhadap error yang dibuat oleh user?
Recoverability:
seberapa bagus sistem memulihkan error yang dibuat user?
Adaptability:
seberapa dekat ikatan sistem dengan sebuah model kerja?
Observasi user pada saat bekerja dengan sistem dan berpikir keras tentang bagaimana mereka
mencoba menggunakan sistem untuk menyelesaikan tugas;
Video snapshots of typical system use;
Memasukkan software untuk mengidentifikasi fasilitas yang sering dipakai dan error yang sering
46 |S T M I K Royal

dibuat.

Modul-12
Teknik Pengujian Software
Test Pokok Software
Test Software
adalah sebuah unsur kritis dari jaminan kualitas dan menghadirkan tinjauan ulang spesifikasi, desain
dan persandian.
Test Software menunjukkan bahwafungsi software tampak seperti bekerja menurut spesif ikasi dan
syarat tampilan
Tujuan Pengujian:
Myers [ MYE79] negara sebuah aturan yang dapat melayani baik seperti menguji sasaran hasil:
Pengujian
adalah suatu proses pelaksanaan suatu program dengan tujuan menemukan suatu kesalahan.
Suatu kasus test yang baik adalah apabila test tersebut mempunyai kemungkinan menemukan
sebuah kesalahan yang tidak terungkap.
Suatu test yang sukses adalah bila test tersebut membongkar suatu kesalahan tidak ditemukan
hingga kini.
Tujuan utama dari pengujian adalah untuk mendasain test yang secara sistematik membongkar jenis
kesalahan dengan usaha dan waktu minimum

Prinsip -Prinsip Pengujian Software

Davids [ DAV95] menyarankan satu set pengujian prinsip:
Semua test harus dapat dilacak ke kebutuhan pelanggan.
Test harus direncanakan dengan baik sebelum pengujian mulai.
Prinsip Pareto berlaku untuk pengujian
80% dari semua kesalahan yang terungkap selama pengujian akan mudah dapat dilacak bagi20%
dari semua modul program
Pengujian seharusnya mulai dari yang kecil dan pengujian perkembangan ke arah yang
besar.
Pengujian menyeluruh adalah tidak mungkin.
Paling efektif, pengujian harus diselenggarakan oleh suatu pihak ketiga mandiri.
Software Testability
Kemampuan Test Software Menurut Yakobus Bach:
Pengujian kemampuan Software adalah contoh bagaimana dengan mudahnya suatu program
komputer dapat diuji.
47 |S T M I K Royal

Satu perangkat karakteristik program mendorong kearah kemampuan pengujian software:

Kemampuan Mengoperasi makin baik berjalan, maka semakin efisien dapat diuji.
Kemampuan Observasi : Apa yang kamu lihat adalah apa yang kamu uji.
Kemampuan mengendalikan : Makin baik kita dapat mengendalikan software, semakin
pengujian dapat diotomatiskan dan dioptimalkan.
Kemampuan memisahkan: Dengan mengendalian lingkup pengujian, kita dapat dengan cepat
mengisolasikan permasalahan dan melaksanakan pengujian kembali yang lebih baik.
Kesederhanaan: Semakin sedikit yang diuji, semakin dengan cepat kita dapat menguji itu.
Stabilitas: Lebih sedikit perubahan, lebih sedikit gangguan untuk menguji.
Kemampuan memahami :Semakin banyak informasi yang kita punya , semakin lebih baik kita
dalam menguji.
Kasus Tes Mendisain
Dua software umum menguji pendekatan:
Pengujian Black Box dan White Box
Pengujian Black-Box:
Mengetahui fungsi yang spesifik dari suatu software, test disain untuk mempertunjukkan
masing-masing fungsi dan mengecek kesalahannya.
Fokus utama: fungsi, operasi, alat penghubung eksternal, informasi dan data eksternal
Pengujian White-Box :
Mengetahui internal dari suatu software, tes disain untuk melatih semua internal-internal dari
suatu software untuk meyakinkan mereka dapat beroperasi menurut spesifikasi dan disain
Fokus utama: struktur internal, alur logika, arus kendali, aliran data, struktur data internal,
kondisi-kondisi, pengulangan dan lain lain
Pengujian White Box dan Pengujian Alur Basis
Pengujian White-Box, juga dikenal sebagai pengujian glass-box.
Ini merupakan suatu kasus test mendisain metoda yang digunakan s truktur kendali dari disain
prosedur mengenai cara untuk memperoleh test kasus.
Menggunakan metode pengujian white-box, kita memperoleh kasus
test yang Menjamin bahwa semua alur mandiri di dalam suatu modul telah dicoba paling sedikit
sekali.
Melatih semua keputusan logis satu sisi benar dan salah
Melaksanakan semua pengulangan pada batasan-batasan mereka dan di dalam batas
operasional mereka.
Melatih struktur data internal untuk meyakinkan kebenarannya.
Pengujian Alur basis dasar ( suatu teknik penguj ian white-box):
Diusulkan pertama oleh Tommccabe [ MCC76].
Dapat digunakan untuk memperoleh suatu ukuran kompleksitas logis untuk suatu disain
prosedur.
Digunakan sebagai suatu panduan untuk penjelasan suatu basis perangkat alur pelaksanaan.
Jaminan untuk melaksanakan tiap-tiap statemen di dalam program sedikitnya sekali.
48 |S T M I K Royal

Kompleksitas Cyclomatic
Kompleksitas Cyclomatic adalah suatu perangkat lunak metrik -> menyediakan suatu ukuran yang
kwantitatif menyangkut kompleksitas yang global dari suatu program.
Manakala metrik ini digunakan dalam konteks pengujian alur basis, nilai menghitung untuk
kompleksitas cyclomatic menggambarkan banyaknya alur mandiri di dalam basis satuan suatu
program.
Tiga jalan untuk menghitung kompleksitas cyclomatic:
Banyaknya daerah dari grafik arus sesuai dengan kompleksitas yang cyclomatic itu.
Kompleksitas Cyclomatic, V(G), untuk suatu grafik arus G digambarkan sebagai V(G)= E- N + 2 di
mana E adalah banyaknya arus tepi grafik dan N adalah banyaknya puncak arus.
Kompleksitas Cyclomatic, V(G)= P+ 1 di mana P adalah banyaknya tangkai predikat terdapat di grafik
arus G.
Menurunkan Kasus Test
Langkah 1: Menggunakan kode atau disain sebagai pondasi, menggambarsuatu bersesuaian grafik arus.
Langkah 2: Menentukan kompleksitas cyclomatic dari resultan aliran grafik.
Langkah 3: Menentukan suatu basis satuan secara linier alur mandiri.
Sebagai contoh,
alur 1: 1-2-10-11-13
alur 2: 1-2-10-12-13
alur 3: 1-2-3-10-11-13 a
alur 4: 1-2-3-4-5-8-9-2-
alur 5: 1-2-3-4-5-6-8-9-2-..
alur 6: 1-2-3-4-5-6-7-8-9-2-..
Langkah 4: Menyiapkan kasus test yang akan memaksa pelaksanaan dari tiap alur di dalam
perangkat basis
Alur 1: menguji kasus:
nilai ( k)= input yang valid, di mana k< I digambarkan di bawah.
nilai ( i)= - 999, di mana 2 <= I<= 100
hasil diharapkan: mengoreksi rata-rata didasarkan pada nilai k menilai dan jumlah yang tepat

Kesamaan Penyekatan
Kesamaan Penyekatan adalah suatu metode pengujian black -box
membagi daerah masukan dari suatu program ke dalam kelas data
memperoleh kasus test berdasar pada sekat ini.
Test Kasus mendisain untuk penyekatan kesamaan didasarkan pada suatu evaluasi kelas kesamaan
untuk suatu daerah masukan.
Suatu kelas kesamaan menghadirkan satu sperangkat yang valid atau yang tida k valid untuk kondisi
input..
Suatu kondisi masukan adalah:
suatu nilai klasifikasi spesifik, bidang nilai-nilai- satu set nilai
49 |S T M I K Royal

nilai terkait, atau suatu kondisi Boolean

Kelas Kesamaan
Kelas Kesamaan dapat digambarkan penggunaannya dengan petunjuk berikut :
Jika suatu kondisi masukan menetapkan suatu cakupan, yang sah dan dua kelas kesamaan
cacat digambarkan.
Jika suatu kondisi input memerlukan suatu nilai spesifik, yang sah dan dua kelas kesamaan cacat
digambarkan.
Jika suatu kondisi input menetapkan suatu anggota dari suatu set, satu yang sah dan satu kelas
kesamaan cacat digambarkan.
Jika suatu kondisi masukan adalah Boolean, satu sah dan satu kelas cacat digambarkan.
Contoh:
kode area: kondisi input, Boolean- kode area boleh atau tidak mungkin disajikan.
kondisi input, cakupan- nilai digambarkan antara 200 dan 900
kata sandi: kondisi input, Boolean- suatu kata sandi tidak atau tidak mungkin disajikan.
Kondisi input, nilai- enam rangkaian karakter.
perintah: kondisi input, perangkat- yang berisi perintah yang dicatat sebelumnya

Analisis Nilai Batas

Analisis nilai Batas Batas menghargai analysis(BVA)
suatu kasus test mendisain teknik
melengkapi ke sasaran sekat kesamaan:
Analisis nilai batas memimpin ke arah suatu pemilihan kasus test yang dicoba membatasi nilai-nilai.
Petunjuk:
Jika suatu kondisi input menetapkan suatu cakupan yang dibatasi oleh nilai a dan b, kasus
pengujian harus dirancang dengan nilai a dan b, sedikit di atas dan di bawah a dan b.
Contoh:
Bilangan bulat D dengan kondisi input [ - 3, 10],
nilai test : - 3, 10, 11, - 2, 0
Jika suatu kondisi input menetapkan suatu nilai -nilai nomor;jumlah, kasus test harus
dikembangkan untuk berlatih angka-angka maksimum dan yang minimum. Nilai yang sedikit di
atas dan di bawah maksimum dan minimum juga diuji.
Contoh:
Menyebut satu persatu data E dengan kondisi input: { 3, 5, 100, 102} nilai test : 3, 102, - 1, 200, 5}.

Modul-13
Contoh -Contoh Soal
1. Jelaskan kelebihan dan kekurangan dari, oleh karena sifat tersebut berikan contoh aplikasi seperti apa
yang cocok dibuat dengannya, gambarkan pula arsitekturnya :
Web Based Application.
50 |S T M I K Royal

 Client Server (Form) Based Application.

Jawaban :
Tipe
Arsitektur
Keuntungan Kerugian Contoh
Aplikasi
Programming
Tool yang cocok
Arsitektur
Web-Base
Client/Server

2. Teknik integrasi 2 aplikasi yang berbeda dengan 2 database (RDBMS) yang berbeda dapat di buat
dengan tiga cara seperti dibawah ini, jelaskan apa yang dikerjakan oleh aplikasi diantara kedua
aplikasi tersebut, jelaskan pula data apa yang dipertukarkan diantara kedua aplikasi tersebut,
beritahukan kelebihan dan kelemahan dari masing masing teknik dibawah ini
o Teknik Database To Database.
o Teknik Interface.
App1 App2
DB1
Trigger
DB2
Trigger
dll
Tugas RPL Software System Safety Report
Deskripsi :
Software yang mencatat input semua kejadian kecelakaan yang terjadi dalam sebuah pabrik pada
database system dan melakukan perhitungan statistik, baik statistik karyawan maupun klasifikasi
kejadian dengan efektif dan cepat, didukung database karyawan yang terintegrasi.
Arsitektur Sistem
Platform System :
` Desktop Based
` Bahasa Pemrograman : Java
` OS : Windows / Linux
` DBMS : MySQL / Java DB
Daftar Fitur Software Lihat, Tambah, Edit, Delete Karyawan
` Lihat, Tambah, Edit, Delete Divisi
51 |S T M I K Royal

`
`
`
`
`
`

Lihat, Tambah, Edit, Delete Jenis Klasifikasi Kejadian

Input Pencatatan Kejadian
Lihat, Edit/Update Daftar Kejadian
Pencarian Kejadian
Pembuatan Laporan Statistik Kejadian
Pembuatan Laporan Statistik Karyawan

Use Case Diagram

Entity Relationship Diagram
DFD Level 0
DFD Level -1
Class Diagram
ScreenShot Aplikasi
FIGURE 1: LAYAR LOGIN
FIGURE 2 :L AYAR HOME
FIGURE 3: LAYAR INPUT KEJADIAN
FIGURE 4 : LAYAR PENCARIAN KEJADIAN

52 |S T M I K Royal