MODUL REKAYASA PERANGKAT LUNAK STMIK DHARMAPALA RIAU

(1)

MODUL REKAYASA

PERANGKAT LUNAK

(2)

1. What and Why Sofware

Engineering ?

I. INTRODUCTION TO

SOFTWARE ENGINEERING

(3)

1.1 Software Engineering (

_Rekayasa

Perangkat Lunak

)

 Ekonomi dari semua bangsa-bangsa maju tergantung pada

perangkat lunak

 Semakin banyak sistem yang dikendalikan oleh perangkat

lunak

 Rekayasa Perangkat Lunak mempunyai kaitan dengan

teori, metode, dan perkakas (tools) untuk pengembangan perangkat lunak profesional

 Rekayasa Perangkat Lunak sudah menjadi bagian yang

penting untuk menghadirkan pendapatan nasional pada semua negara maju

(4)

1.2 Software Costs

(

_{Biaya-Biaya Perangkat Lunak}

)

 Biaya-biaya perangkat lunak sering mendominasi

biaya-biaya sistem. Biaya-biaya perangkat lunak pada suatu PC sering lebih besar dari harga

perangkat keras.

 Biaya-biaya perawatan perangkat lunak lebih

besar dibanding dengan pengembangan perangkat lunak, karena sistem dengan masa pakai lama,

biaya pemeliharaan mungkin beberapa kali biaya-biaya pengembangan.

 Rekayasa Perangkat Lunak mempunyai kaitan

dengan biaya-biaya pengembangan perangkat lunak yang ekonomis.

(5)

1.3 FAQs about Software Engineering

(Pertanyaan-pertanyaan Seputar SE)

 Apakah _software itu?

 Apakah _{software engineering} itu?

 Apa perbedaan antara _{software engineering} dan _{computer science}?  Apa perbedaan antara _{software engineering} dan _{system engineering}?  Apakah _{software process} itu?

(6)

FAQs about Software Engineering

_(Lanjutan)

 Apa saja yang merupakan biaya-biaya rekayasa perangkat

lunak itu?

 Apa saja metode rekayasa perangkat lunak itu?

 Apakah CASE (Computer-Aided Software Engineering) itu?  Apa saja atribut dari perangkat lunak yang baik?

 Apakah yang merupakan tantangan kunci dalam

(7)

What is software?

 perintah (program komputer) yang bila dieksekusi

memberikan fungsi dan unjuk kerja seperti yang diinginkan;

 struktur data yang memungkinkan program

memanipulasi informasi secara proporsional; dan

 dokumen yang menggambarkan operasi dan

kegunaan program.

 Produk Perangkat lunak mungkin :

 Generic (_Umum) - yang dikembangkan untuk dijual ke

bidang pelanggan berbeda;

 Bespoke/Custom (_Pesanan) - dikembangkan untuk

(8)

What is software engineering?

 _{Software engineering} adalah suatu disiplin rekayasa (rancang-bangun)

yang terkait dengan semua aspek produksi perangkat lunak.

 Engineer perangkat lunak mengadopsi pendekatan sistematis dan

terorganisir untuk pekerjaan mereka dan menggunakan teknik dan tools yang disesuaikan dengan masalah yang dihadapi untuk

(9)

IEEE Definition

(IEEE = Institute of Electrical and Electronic Engineers)

Software engineering adalah:

1. Aplikasi dari sebuah pendekatan yang bersifat kuantifiabel, disiplin, dan sistematis bagi pengembangan, operasi, dan pemeliharaan perangkat lunak.

2. Studi tentang pendekatan-pendekatan seperti pada (1)

(10)

What is the difference between

_{software engineering}

and

_{computer science}

?

 _{Computer science} mempunyai kaitan dengan _{theory and fundamentals}; _software

engineering mempunyai kaitan dengan practicalities of developing and delivering useful software.

 _{Computer science} sekarang ini tidak cukup lengkap untuk bertindak sebagai

(11)

What is the difference between

_software

engineering

and

system engineering

?

 _{System engineering} mempunyai kaitan dengan semua aspek

pengembangan sistem berbasis-komputer yang mencakup perangkat keras, perangkat lunak ,dan yang terkait

dengan proses bisnis.

 _{Software engineering} berkonsentrasi pada komponen

perangkat lunak sistem yang lebih besar.

 _{System engineers} mencakup spesifikasi sistem, desain

(12)

What is a software process?

 Software process merupakan himpunan aktivitas tujuan

pengembangan atau evolusi perangkat lunak.

 Aktivitas umum dalam semua proses perangkat lunak

adalah:

 _{Specification} (Spesifikasi)- hal-hal yang diperlukan oleh sistem dan

batasan pengembangannya.

 _Development (Pengembangan)- produksi sistem perangkat lunak.  _Validation (Pengesahan) - pemeriksaan perangkat lunak sesuai

dengan keinginan pelanggan.

 _Evolution (Evolusi) - pengubahan perangkat lunak sesuai dengan

(13)

What is

a software process model?

 Software process model merupakan representasi

sederhana suatu _{software process}, yang

diperkenalkan dari suatu perspektif spesifik.

 Contoh perspektif proses adalah

 _{Workflow Perspektif -} Urutan aktivitas  _{Data-Flow Perspektif} - Arus Informasi  _{Role/Action Perspektif –} Peran dan Aksi

 Proses umum model

 _Waterfall

 _{Evolutionary development}  _{Formal transformation}

(14)

What are the costs of software engineering?

 Perkiraan kasar adalah 60% untuk biaya pengembangan, sedangkan 40% untuk biaya pengujian. Untuk custom sofware, biaya-biaya evolusi sering melebihi biaya-biaya pengembangan.

 Biaya-biaya berubah-ubah tergantung pada jenis sistem yang

dikembangkan dan kebutuhan atribut sistem seperti kehandalan dan reliabilitas sistem.

 Distribusi biaya-biaya tergantung pada model pengembangan yang

(15)

What are software engineering

methods?

Software engineering methods merupakan

pendekatan terstruktur dalam pengembangan

perangkat lunak yang meliputi model sistem, notasi, aturan, desain advice, dan panduan proses.

 Model Descriptions (Uraian Model)

Uraian tentang model grafis yang harus diproduksi.

 Rules (Aturan-aturan)

Batasan yang berlaku pada model sistem.

 Recommendations (Rekomendasi)

Rekomendasi untuk praktik desain yang baik.

 Process guidance (Panduan Proses) Aktivitas yang mengikuti.

(16)

What is CASE

_{(Computer-Aided}

Software Engineering)

?

 _CASE_adalah_{System software} yang digunakan untuk mendukung

otomatisasi aktivitas proses perangkat lunak. CASE sering digunakan untuk mendukung metode.

 Upper-Case

Tools untuk mendukung aktivitas proses awal kebutuhan dan desain.

 Lower-Case

Tools untuk mendukung aktivitas selanjutnya seperti _programming,

(17)

What are the attributes of good

software?

Software perlu memiliki fungsi kebutuhan dan kemampuan yang diperlukan oleh pemakai dan harus _{maintainable, dependable ,}

efficient, dan usable.

 Maintainability

Software harus dapat ditingkatkan dan diubah sesuai dengan kebutuhan.

 Dependability

Software harus dapat dipercaya (trustworthy).

 Efficiency

Software seharusnya tidak membuat penggunaan sumber daya sistem menjadi boros.

 Usability

Software harus dapat dipakai oleh para pemakai yang direncanakan.

(18)

What are the key challenges facing

software engineering?

Tantangan : mengatasi sistem warisan (_{legacy systems}), meningkatnya heterogenitas (_Heterogenity) sistem, dan tuntutan permintaan percepatan penyerahan(_Delivery₎ sistem.

 Legacy systems

Sistem warisan (sistem lama) harus dirawat dan dibaharui.

 Heterogenity

Sistem terdistribusikan dalam bentuk campuran antara perangkat keras dan lunak.

 Delivery

Adanya peningkatan tekanan untuk penyerahan perangkat lunak lebih cepat.

(19)

1.4 Professional and Ethical

Responsibility

 _{Software engineering} melibatkan tanggung-jawab lebih luas dibanding hanya

aplikasi kecakapan teknis.

 _{Software engineer} harus bertindak secara etis, bertanggung jawab, dan jujur

jika mereka diharapkan untuk terhormat sebagai seorang profesional.

 Perilaku etis tidak hanya sekedar menegakkan hukum saja tetapi harus lebih

(20)

Issues of professional responsibility

 Confidentiality (Kerahasiaan)

Engineer seharusnya menghormati kerahasiaan dari klien mereka tanpa tergantung dengan ya atau

tidaknya suatu persetujuan kerahasiaan formal ditandatangani.

 Competence (Kemampuan)

Engineer mestinya tidak salah menggambarkan tingkatan kemampuannya. Mereka mestinya tidak dengan sadar menerima pekerjaan yang di luar kemampuannya.

(21)

Issues of professional responsibility

(lanjutan)

 Intellectual property rights (Hak milik intelektual)

Engineers harus sadar akan hukum lokal yang mengatur penggunaan dari properti intelektual seperti hak paten, hak cipta, dll. Mereka harus seksama untuk memastikan bahwa intelektual properti klien harus dilindungi.

 Computer misuse (Penyalahgunaan Komputer)

Software engineers mestinya tidak menggunakan kecakapan teknis mereka untuk menyalahgunakan komputer orang lain. Penyalahgunaan komputer dari yang relatif sepele (misal untuk bermain game) sampai yang serius (pemberian virus).

(22)

2 The Software

Product

(23)

2.1 The Evolving Role of Software

Peran Perangkat Lunak saat ini:

 Berfungsi sebagai sebuah produk

 mengantarkan potensi penghitungan yang dibangun oleh perangkat lunak

komputer. Perangkat lunak sebagai transformer informasi yang

memproduksi, mengatur, memperoleh, memodifikasi, menampilkan atau memancarkan informasi, sehingga pekerjaan menjadi semakin mudah

 Berfungsi sebagai kendaraan yang mengantarkan sebuah produk

 Dasar untuk kontrol komputer (sistem operasi), komunikasi informasi

(jaringan) dan penciptaan serta kontrol dari program-program lain (piranti dan lingkungan perangkat lunak)

(24)

2.2 Evolution of Software

1st _Era

2

st

_Era

₃

st

_Era

1950 1960 1970 1980 1990 2000

4

st

_Era

• Batch orientation • Limited distribution • Custom software • Multiuser • Real-time • Database • Product software • Distributed systems • Embedded ‘intelligence’ • Low cost hardware • Powerful desk-top systems • Object-oriented technologies • Expert systems • Artificial neural networks • Parallel computing • Network computers

(25)

2.3 Serangkaian masalah perangkat lunak sehubungan dengan evolusi sistem berbasis komputer

 Kemajuan perangkat keras terus berlanjut melampaui

kemampuan engineer dalam membangun perangkat lunak yang sesuai dengan perangkat keras yang ada.

 Kemampuan engineer untuk membangun program baru tidak

dapat memenuhi kebutuhan akan program baru dan tidak

dapat membangun program yang cukup cepat untuk memenuhi kebutuhan bisnis dan pasar.

 Pemakaian komputer yang tersebar luas membuat masyarakat

semakin tergantung pada operasi perangkat lunak yang reliabel. Kerusakan ekonomi yang besar dan potensi

penderitaan manusia dapat muncul bila terjadi kegagalan perangkat lunak.

 Kita masih berjuang untuk membangun perangkat lunak

komputer dengan reliabilitas dan kualitas yang tinggi.

 Kemampuan kita untuk mendukung program yang ada

terhambat oleh buruknya desain serta sumber daya yang tidak memadai.

(26)

2.4 Software Characteristics

Perangkat lunak lebih merupakan

elemen

logika

dan bukan merupakan elemen fisik,

sehingga perangkat lunak memiliki ciri yang

berbeda dari perangkat keras.

 Perangkat lunak dibangun dan dikembangkan,

tidak dibuat dalam bentuk yang klasik (manufaktur).

 Perangkat lunak tidak pernah usang.

 Sebagian besar perangkat lunak dibuat secara

custom-built, serta tidak dapat dirakit dari komponen yang sudah ada.

(27)

Failure Curve of Hardware

kurva ideal Tingkat kegagalan kematian segera usang Waktu

(28)

Failure Curve for Software

(idealized)

Tingkat kegagalan

pada tingkat yang sama sampai usang

(29)

Actual Failure Curve for Software

Tingkat kegagalan

perubahan

laju kegagalan meningkat sehubungan dengan efek

sampingan kurva ideal kurva aktual Waktu

(30)

2.5 Software Components



Komponen perangkat lunak adalah informasi yang

tersimpan dalam dua bentuk dasar, yaitu

komponen yang tidak bisa dieksekusi (

non

machine executable

) dan yang dapat dieksekusi

mesin (

machine executable

).



_Reusability

merupakan suatu ciri penting dari

(31)

2.6. Software Myths

 Software Miths (mitos-mitos perangkat lunak) adalah

asumsi-asumsi permasalahan yang kebenarannya tidak dapat

dipertanggungjawabkan berkaitan dengan pengembangan perangkat lunak

 Tiga kelompok yang terkait dalam pengembangan perangkat

lunak

 Management : manajer yang bertanggungjawab terhadap

pengembangan perangkat lunak

 Customer : pelanggan yang memesan perangkat lunak

 Practitioner’s : praktisi yang mengembangkan perangkat

(32)

2.6.1 Management Myths

 Dengan memiliki buku berisi standard dan prosedur yang

banyak untuk pengembangan perangkat lunak, maka

pekerjaan pasti lancar.

 _{Buku-buku itu memang lengkap, tapi apakah digunakan ?}

Apakah praktisi perangkat lunak sadar dengan keberadaannya. Apakah cocok dengan pengembangan yang modern ? Apakah benar-benar lengkap ?

 Untuk menghasilkan perangkat lunak yang berkualitas, maka

kita perlu membeli komputer terbaru.

 _{Untuk mendapatkan perangkat lunak yang berkualitas, CASE}

tools lebih penting daripada perangkat keras.

 Bila terlambat maka tambahlah jumlah programer

(33)

2.6.2 Customer Myths

 Tujuan sistem secara umum cukup untuk memulai menulis program,

rincian belakangan saja.

 _{Definisi awal yang buruk merupakan sebab utama gagalnya kerja perangkat}

lunak

 _{Rincian kebutuhan sistem sangat penting:}

 _fungsi  _performance  _antar-muka  _{batasan rancangan}  _{kriteria validasi}  _dll

 Perangkat lunak bersifat fleksibel, perubahan kebutuhan mudah

diakomodasi oleh pengembang perangkat lunak

(34)

2.6.3 Practitioner’s Myths



Program selesai, pekerjaan selesai

 _{50% - 70% usaha dihabiskan setelah program}

diserahkan ke user untuk pertama kalinya.



Kualitas

hanya bisa diketahui setelah

program berjalan (running)

 _{Kualitas dapat dijaga sejak PL dikembangkan.}



Yang diserahkan ke user adalah program

 _{Yang diserahkan adalah program, dokumen, dan data.}

(35)

3. The Software

Process

(36)

3.1 Software Engineering Layers

Tools Methods

Process

(37)

3.2 A Generic View of Software

Engineering

 Engineering meliputi kegiatan analisis, desain, konstruksi,

verifikasi, dan manajemen kesatuan teknik atau sosial.

 Pertanyaan-pertanyaan yang harus dimunculkan dan dijawab:  _{Apa masalah yang akan dipecahkan?}

 _{Karakteristik entitas yang manakah yang dipakai untuk}

menyelesaikan masalah tersebut?

 _{Bagaimanakah entitas (dan pemecahan) tersebut diadakan?}  _{Bagaimanakah entitas tersebut dibangun?}

 _{Pendekatan apakah yang akan dipakai untuk menemukan}

kesalahan-kesalahan yang dibuat dalam desain dan kontruksi dari entitas tersebut?

 _{Bagaimanakah entitas tersebut ditopang selama proses adaptasi}

yang lama, pada saat koreksi, serta ketika perbaikan dibutuhkan oleh para pemakai entitas tersebut?

(38)

3.3 General Phase to Software

Engineering

 Definition phase  berfokus pada ‘apa’ (what):

 informasi yang akan diproses

 fungsi dan perfomance yang dibutuhkan  tingkah laku sistem yang diharapkan  interface yang akan dibangun

 batasan sistem yang sukses

 Development phase  berfokus pada ‘bagaimana’ (how):

 data dikonstruksikan

 fungsi-fungsi diimplementasikan

 detail prosedur akan diimplementasikan  interface dikarakterisasi

 rancangan akan diterjemahkan ke dalam pemrograman  pengujian dilakukan

 Maintenance phase  berfokus pada ‘perubahan’ (change):

 dihubungkan dengan koreksi kesalahan

 ketika lingkungan perangkat lunak berkembang

(39)

3.4 Changes in Phase Development

 Correction (Koreksi)

 membetulkan cacat atau kerusakan

 Adaptation (Adaptasi)

 modifikasi perangkat lunak karena perubahan kebutuhan fungsional

original (CPU, OS, aturan bisnis, karakteristik produk eksternal, dll)

 Enhancement (Perkembangan)

 memperluas perangkat lunak sehingga melampaui kebutuhan fungsi

originalnya

 Prevention (Pencegahan)

Engineering Institute)

 Level 1: Initial

Software process yang ditandai seperti ad hoc dan chaotic (kesemrawutan).

 Level 2: Repeatable

Tracking / penelusuran masalah biaya, jadwal, dan fungsionalitas proyek-proyek terdahulu.

 Level 3: Defined

Pendokumentasian, standarisasi, dan pengintegrasian software proses pada perangkat lunak organisasi besar.

 Level 4: Managed

Pengukuan detail dan kualitas produksi perangkat lunak.

 Level 5: Optimizing

Penambahan proses melalui umpan balik kuantitatif, gagasan inovatif pengujian, dan teknologi.

(44)

3.8. Software Process Models

 Linier Sequential Model

 Waterfall Model  V Model  RAD Model  Prototyping Model  Evolutionary Model  Incremental Model  Spiral Model

 Component Assembly Model  Concurrent Development Model

 Formal Model

(45)

3.8.1. Linier Sequential Model

Analysis Design Code Test

System/Information Engineering

(46)

3.8.1.1 Waterfall Model

 Sebuah pendekatan pengembangan perangkat

lunak yang sistematik dan sekuensial.

 Disebut juga ‘Classic Life Cycle’.

 Paradigma yang sudah lama sekali, tetapi masih

banyak yang memakai karena dianggap masih sesuai dengan keadaan sekarang.

(47)

Waterfall Model Diagram

Requirements definition System and software design Implementation and unit testing

Integration and system testing

Operation and maintenance

(48)

Modified Waterfall Model

(M.Kochanski)

Waterfall with Spiral Introduction Sashimi

(49)

3.8.1.2 V Model

REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING

UNIT & INTE-GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE Verify design Validate requirements

(50)

3.8.1.3 RAD Model

 RAD = Rapid Application Development  Adaptasi dari waterfall model yang:

 menekankan siklus pengembangan perangkat lunak yang sangat pendek;  menggunakan pendekatan konstruksi berbasis komponen.

(51)

RAD Model Diagram

business modeling data modeling process modeling application generation testing & turnover business modeling data modeling process modeling application generation testing & turnover business modeling data modeling process modeling application generation testing & turnover 60 - 90 hari team #1 team #2 team #3

(52)

RAD Model Phases

 Business Modelling

Memodelkan fungsi-fungsi bisnis untuk menjawab pertanyaan-pertanyaan:

Informasi apa yang mengendalikan proses bisnis ? Informasi apa yang dimunculkan? Ke mana infomasi itu pergi? Siapa yang memprosesnya?

 Data Modelling

Aliran informasi yang didefinisikan pada fase business modelling ditransformasikan ke dalam serangkaian obyek data.

 Process Modelling

Mentransformasikan obyek data pada suatu fungsi yang menghasilkan aliran informasi yang dibutuhkan.

 Application Generation

Mengkonstruksi perangkat lunak dengan memakai komponen yang ada (bila memungkinkan) atau menciptakan komponen yang dapat dipakai lagi.

 Testing and Turnover

(53)

3.8.2 Prototyping Model

Dipakai jika:

 Sistem mempunyai resiko tinggi  tidak jelas permasalahannya

 Lebih fokus pada perancangan dialog user - komputer

 bagaimana membuat dialog yang baik, ramah, mudah ?  Sistem diminati oleh banyak pemakai

 mencari kesepakatan (dasar untuk menyamakan persepsi)  User ingin cepat selesai

 user tidak sabar menunggu

 prototipe segera memperlihatkan bentuk kerja sistem  Masa pakai singkat

 sistem hanya dipakai beberapa kali saja  Ingin menunjukkan inovasi

 pengembang dapat menunjukkan kecanggihan  Kebutuhan berubah-ubah

(54)

Types of Prototyping

 Evolutionary prototyping

Dimulai dari model, kemudian dikembangkan dan akhirnya dipakai.

 Throw-away prototyping

(55)

Evolutionary Prototyping

Prototype Programming Prototype Requirements Reviews Release Validates?

(56)

Throw-away prototyping

Release System Testing System Programming Reviews Validates? Prototype Programming Prototype Requirements Reviews Validates?

(57)

Prototyping Speciality

 Frekuensi komunikasi user – developer meningkat

 pengembang akan selalu meminta pendapat user

 Membantu analis dalam

 menentukan kebutuhan user yang sebenarnya  meminimalkan salah persepsi

 Peran user meningkat

 evaluasi oleh user berkali-kali

 user bisa memberikan masukan setiap saat

 Pengembangan lebih cepat

 program bisa langsung dibuat

 user melihat perkembangan tahap demi tahap

 Implementasi mudah

 user sudah mengenal perangkat lunak yang dikembangkan  user tidak akan merasa asing

(58)

Prototyping Weakness

 User sibuk

 user & pengembang harus sama-sama memiliki komitmen

menyediakan waktu untuk bertemu.

 User sulit melakukan evaluasi

 bentuk prototipe sering berubah, disesuaikan dengan kebutuhan

user.

 User ingin cepat selesai

 bentuk program sudah terlihat sejak awal.  user merasa tidak akan lama lagi selesai.

 pengembang sering mengabaikan dokumentasi.

 User berharap terlalu banyak

 keseringan evaluasi & komunikasi membuat user menjadi berubah

keinginan dan tidak pasti dengan kebutuhan.

 Prototipe bekerja tidak efisien

(59)

3.8.3 Evolutionary Model

3.8.3.1 Incremental Model



Incremental Model merupakan gabungan antara

model linier sekuensial dan prototyping.



Setiap linier sekuen menghasilkan produk yang

deliveriables.



Increment pertama merupakan produk inti (core),

yang mengandung persyaratan/kebutuhan dasar.



Penambahan dilakukan pada increment-increment

(60)

Incremental Model Diagram

analysis design code test

system/information engineering increment 2 increment 3 increment 4 delivery of 1st increment delivery of 2nd increment delivery of 3rd increment delivery of 4th increment

(61)

3.8.3.2 Spiral Model

 Evolutionary process (pengembangan bertingkat)  Menggabungkan keunggulan prototyping dan

waterfall

 Memungkinkan dikembangkannya perangkat lunak

secara bertahap (incremental) dan cepat.

 Terbagi atas 6 tahapan

 customer communication  planning

 risk analysis  engineering

 construction & release  customer evaluation

(62)

Spiral Model Diagram

Planning Risk Analysis Engineering Customer Evaluation _Construction & Release Customer Communication Project Entry Point analisa resiko berdasarkan kebutuhan awal analisa resiko berdasarkan evaluasi user produk-jadi prototipe awal prototipe tingkat berikutnya menentukan tujuan, alternatif, batasan sistem

dan budget Requirements development plan Integration and test plan

(63)

3.8.3.3 Component Assembly Model

planning engineering risk analysis customer evaluation entry point identify candidate components look up components in library extract components if available build components if unavailable put new components in library construct n-th iteration of system Customer communication Engineering,

(64)

3.8.3.4 Concurrent Development Model

none Under development A waiting changes Under revision Under review baselined done Analysis activity

(65)

Konkurensi Tercapai dengan Cara:



aktivitas sistem dan komponen yang berlangsung

secara

simultan

dan dapat

dimodelkan

dengan

menggunakan pendekatan orientasi keadaan;



aplikasi klien/server khusus yang

diimplementasikan dengan

banyak komponen

yang

masing-masing bisa dirancang dan direalisasikan

secara konkuren.

(66)

3.8.4 Formal Model

 mencakup sekumpulan aktivitas yang membawa

kepada spesifikasi matematis perangkat lunak komputer;

 memungkinkan software engineer untuk

mengkhususkan, mengembangkan, dan

mem-verifikasi sistem berbasis komputer dengan menggunakan notasi matematis yang tepat;

 Variasi dari pendekatan ini disebut clean-room

software engineering.

(67)

3.8.5 Fourth Generation Techniques

(4GT)

 Terkait dengan penggunaan tools.

 Pengembang software mendefinisikan karakteristik

software secara 'high level'; tool secara otomatis akan membangkitkan kode.

 4GT mempercepat proses pengembangan perangkat lunak.  Proses perancangan dan dokumentasi baik.

 Masih dipertanyakan beberapa pihak: efisiensi kode yang

(68)

4GT Techniques

requirements gathering design strategy implementation using 4GL testing ***

(69)

69

4. Konsep Manajemen Proyek

Perangkat Lunak

4.1 People

4.1.1 Para Pemain (Stakeholder) 4.1.2 Pemimpin Tim

4.1.3 Tim Perangkat Lunak

4.1.4 Tiga Organisasi Tim (Mantei)

4.1.5 Faktor-faktor dalam Perencanaan Struktur Tim RPL (Mantei)

4.1.6 Pengaruh Karakteristik Proyek pada Struktur Tim 4.1.7 Masalah Koordinasi dan Komunikasi

4.1.8 Teknik Koordinasi Proyek (Kraul dan Streeter)

4.2 Problem

4.2.1 Ruang Lingkup Masalah

4.2.2 Dekomposisi Masalah 4.3 Proses

4.3.1 Menggabungkan Masalah dan Proses

4.3.2 Dekomposisi Proses

4.3.3 Contoh Dekomposisi (simple project) 4.3.4 Contoh Dekomposisi (complex project)

(70)

70

Konsep Manajemen Proyek

Perangkat Lunak



Manajemen Proyek Perangkat Lunak merupakan

suatu aktivitas pelindung (umbrella activity)

untuk mengelola proyek perangkat lunak, yang

difokuskan pada 3P: People (manusia); Problem

(masalah) dan Process (proses)

 People: semua orang yang terlibat dalam proyek

perangkat lunak

 Problem: menentukan ruang lingkup dan batasan proyek

perangkat lunak sekaligus teknik pemecahannya.

 Process: kerangka kerja yang komprehensif dalam

(71)

71

4.1 People

4.1.1 Para Pemain (Stakeholder)

 Senior managers: yang menentukan isu-isu bisnis yang sering

memiliki pengaruh penting dalam proyek.

 Project (technical) managers: yang harus merencanakan,

memotivasai, mengorganisasi, dan mengontrol sebuah produk atau aplikasi.

 Practitioners: yang menyampaikan keteranpilan teknik yang

diperlukan untuk merekayasa sebuah produk atau aplikasi.

 Customers: yang menentukan jenis kebutuhan bagi perangkat

lunak yang akan direkayasa.

(72)

72

4.1.2 Pemimpin Tim



Pemimpin tim (team leaders): seseorang yang

memimpin sebuah proyek perangkat lunak.



Syarat : Model Kepemimpinan MOI (Weinberg):

 Motivasi: kemampuan untuk memberi dorongan

pada staf teknis untuk menghasilkan sesuatu dengan kemampuan terbaiknya.

 Organisasi: kemampuan untuk membentuk proses

yang sedang berlangsung yang memungkinkan

konsep dasar diterjemahkan ke dalam suatu hasil akhir.

 Gagasan dan Inovasi: kemampuan untuk

mendorong manusia untuk menciptakan dan bertindak kreatif meskipun mereka bekerja di dalam suatu ikatan yang dibangun untuk suatu produk perangkat lunak yang spesifik.

(73)

73

4.1.3 Tim Perangkat Lunak



Alternatif pemanfaatan SDM pada proyek perangkat

lunak:

 n individu diberi m tugas fungsional yang berbeda (m >

n), ada individu yang merangkap kombinasi kerja.

 n individu diberi m tugas yang berbeda (m < n), secara tidak

langsung terbentuk tim informal.

 n individu dibagi menjadi t tim, setiap tim mempunyai tugas

yang spesifik.



Struktur tim yang terbaik

berdasarkan gaya

manajemen, jumlah orang, tingkat keahlian,

kompleksitas masalah.

(74)

74

4.1.4 Tiga Organisasi Tim (Mantei)

 Democratic Decentralized (DD); tidak ada pimpinan yang tetap,

keputusan diambil secara bersama-sama, hubungan horizontal.

 Controlled Decentralized (CD); ada pimpinan untuk setiap 'task' dan

sub-pimpinan untuk 'sub-task', terjadi komunikasi horizontal & vertikal.

 Controlled Centralized (CC); ada team leader untuk top-level problem

(75)

75

4.1.5 Faktor-faktor dalam Perencanaan

Struktur Tim RPL (Mantei)

 Tingkat kesulitan masalah

 Besarnya program (dalam LOC atau FP)  Team lifetime

 Tingkat modularitas program  Kualitas dan reliabilitas program  Batas waktu pengembangan

(76)

76

4.1.6 Pengaruh Karakteristik Proyek

pada Struktur Tim

Team type: Difficulty high low Size large small Team lifetime short long Modularity high low Reliability high low Delivery date strict lax Sociability high low DD CD CC x x x x x x x x x x x x x x x x x x x x x

(77)

77

4.1.7 Masalah Koordinasi dan Komunikasi

Ada banyak hal yang menyebabkan proyek perangkat lunak bermasalah, penyebabnya diantaranya adalah:

 Scale (skala): skala proyek yang demikian besar, sehingga koordinasi sulit.  Uncertainty (ketidakpastian): perubahan-perubahan yang terus-menerus.  Interoperability (interoperabilitas): perangkat lunak yang dibuat harus dapat

(78)

78

4.1.8 Teknik Koordinasi Proyek

(Kraul dan Streeter)

 Pendekatan impersonal, formal.

Dokumen, memo teknis, milestone proyek, schedule, error tracking report, dll

 Prosedur interpersonal, formal.

Difokuskan pada jaminan kualitas kegiatan, diantaranya inspeksi desain dan kode.

 Prosedur interpersonal, informal.

Group meeting untuk bertukar informasi dan problem solving, requirement gathering dan pengembangan staff.

 Komunikasi elektronik.

E-mail, E-BB, web sites, video conference.

 Jaringan interpersonal.

(79)

79

4.2 Problem



Manajer proyek perangkat lunak berhadapan

dengan dilema awal proyek, yaitu menentukan

perkiraan kuantitatif dan rencana organisasi

tetapi informasi yang akurat belum tersedia.



Requirement analysis yang lengkap dibutuhkan

untuk melakukan estimasi, tetapi memerlukan

waktu yang lama dan kadang-kadang

kebutuhan berubah-ubah pada saat proyek

berjalan.

Solusi:

definisikan scope (ruang lingkup) dengan

benar dan segera.

(80)

80

4.2.1 Ruang Lingkup Masalah



dibatasi oleh:

 Context

Bagaimana perangkat lunak yang dibangun dapat

memenuhi sebuah sistem, produk, atau konteks bisnis yang lebih besar, serta apa batasan yang ditentukan sebagai hasil dari konteks tersebut?

 Information Objectives

Obyek data pelanggan apa yang dihasilkan sebagai

output dari perangkat lunak, dan obyek data apa yang diperlukan sebagai input?

 Function dan performance

Fungsi apa yang dilakukan oleh perangkat lunak untuk mentransformasi input data menjadi output?

(81)

81

4.2.2 Dekomposisi Masalah

 Dekomposisi masalah disebut juga partitioning (pembagian), merupakan

aktivitas yang mendudukkan inti dari analisis kebutuhan perangkat lunak.

 Dekomposisi dilakukan dalam 2 area:

 Fungsionalitas yang harus dihasilkan

 Proses yang akan dipakai untuk menghasilkan sesuatu

 Manusia cenderung melakukan dekomposisi jika menghadapi masalah

(82)

82

4.3 Proses

 Fase-fase generik dan menandai proses perangkat lunak: definisi,

pembangunan, dan pemeliharaan

 Fase generik dijalankan menggunakan salah satu model rekayasa

perangkat lunak.

 Project manager harus memilih model rekayasa yang paling tepat

(83)

83

 Tahap awal project planning dimulai dengan penggabungan

problem dan process.

 Setiap fungsi yang akan direkayasa harus melampaui

sejumlah aktivitas yang sudah ditentukan

 Misal organisasi mengadopsi kerangka aktivitas sbb:

 Customer communication – membangun komunikasi yang efektif

antara pengembang dan pelanggan

 Planning – menentukan sumber daya, ketepatan waktu, dan

informasi proyek yang lain

 Risk analysis – menentukan resiko-resiko manajemen dan teknis  Engineering – membangun aplikasi perangkat lunak

 Construction and release – membangun, menguji, menginstal,

dan memberikan dukungan kepada pemakai (dokumen dan pelatihan)

 Customer evaluation – umpan balik pelanggan

 Selanjutnya dibuat matriksnya.

4.3.1 Menggabungkan Masalah dan

Proses

(84)

84

Software Engineering Tasks

Product Functions

Text input

Editing & formatting

Automatic copy edit

Page layout capability

Automatic indexing & TOC

File management Document production COMMON PROCESS FRAMEWORK ACTIVITIES c u s to m e r c o m m u n ic a tio n p la n n in g ris k a n a ly s is e n g in e e rin g

(85)

85

4.3.2 Dekomposisi Proses



Memilih paradigma

rekayasa perangkat lunak

yang paling baik sesuai dengan tingkat

relativitas dari perangkat lunak.

 Bila proyek relatif kecil dan mirip dengan proyek

sebelumnya, maka dapat dipilih pendekatan linier sekuensial

 Bila masalah dapat dipecah-pecah dan batasan

waktu yang ketat, maka dapat dipilih model RAD.

 Bila batas waktunya ketat, tetapi fungsionalitas

tidak dapat optimal, maka dapat dipilih strategi pertambahan. dll

 Sekali model dipilih, kerangka kerja umum

(CPF=common Process Framework) harus disesuaikan dengan model.

(86)

86

4.3.3 Contoh Dekomposisi

(simple project)

 Membuat daftar klarifikasi

 Bertemu dengan customer untuk klarifikasi  Bersama-sama menentukan scope

 Review scope

(87)

87

4.3.4 Contoh Dekomposisi

(complex project)

_ _Mengkaji_{kebutuhan customer}

 Merencanakan dan menjadwal sebuah pertemuan formal dengan

customer

 Melakukan penelitian untuk menentukan pemecahan yang

diusulkan

 Mempersiapkan dokumen kerja serta agenda untuk pertemuan

formal

 Mengadakan pertemuan

 Secara bersama-sama mengembangkan spesifikasi detail yang

merefleksikan data, fungsi, dan karakteristik yang berhubungan dengan perilaku perangkat lunak

 Mengkaji setiap spesifikasi detail tersebut untuk upaya perbaikan, konsistensi, dan mengurangi ambiguitas

 Mencantumkan spesifikasi detail ke dalam sebuah dokumen ruang lingkup

 Mengkaji dokumen ruang lingkup dengan semua pendapat yang

ada.

 Memodifikasi dokumen ruang lingkup sesuai dengan kebutuhan.

(88)

88

5. Proses Perangkat Lunak dan Metrik Proyek

5.1 Domain Metrik

5.1.1 Tujuan Umum Pengukuran

5.1.2 Determinan Kualitas dan Efektivitas Perangkat Lunak

5.2 Pengukuran Perangkat Lunak

5.2.1 Size-Oriented Metrics

5.2.2 Function-Oriented Metrics 5.2.2.1 Function Points

5.2.2.2 Penghitungan Metrik Function Points

5.2.2.3 Feature Points

5.2.2.4 Penentuan Kompleksitas Transformasi Function Points

5.3 Penyatuan Pendekatan Metrik yang Berbeda

5.4 Kualitas Perangkat Lunak

5.4.1 Faktor yang Mempengaruhi Kualitas

5.4.2 Faktor yang Mempengaruhi Kualitas (Gilb)

(89)

89

Proses Perangkat Lunak dan Metrik Proyek

 Measure (mengukur); kuantitatif luasan, jumlah, dimensi,

kapasitas, atau ukuran dari atribut sebuah proses atau produk.

 Measurement (pengukuran); kegiatan menentukan sebuah

measure.

 Metrics (IEEE): ukuran kuantitatif dari tingkat di mana

sebuah sistem, komponen, atau proses memiliki atribut tertentu

 Indikator adalah sebuah metrik atau kombinasi dari metrik

yang memberikan pengetahuan ke dalam proses perangkat lunak, sebuah proyek perangkat lunak, atau produk

(90)

90

5.1 Domain Metrik

 Pengukuran perangkat lunak dilakukan pada proses dan proyek

perangkat lunak.

 Indikator proses memungkinkan:

 Software engineer memperoleh pengetahuan tentang reliabilitas sebuah

proses yang sedang berlangsung.

 Manajer dan pelaksana memperkirakan hal-hal yang harus dikerjakan dan yang

tidak

 Indikator proyek, memungkinkan manajer proyek:

 Memperkirakan status proyek

 Menelusuri resiko-resiko potensial

 Menemukan area masalah sebelum menjadi kritis  Menyesuaikan aliran kerja atau tugas-tugas

(91)

dari penerapan sebuah metoda;

mencari

paradigma

andalan



Dasar untuk melakukan

perkiraan

;

pedoman

di

masa mendatang



Membantu untuk memastikan apakah dibutuhkan

(92)

92

5.1.2 Determinan Kualitas dan

Efektivitas Perangkat Lunak

Product Technology People Process Cu stomer Ch ara cte ris tic s Development Environment Bu s_ine s_s Co nd ition s

(93)

93

5.2 Pengukuran Perangkat Lunak

 Size-Oriented Metrics: metrik yang berorientasi pada besar fisik ukuran

perangkat lunak

 Function-Oriented Metrics: metrik yang berorientasi pada fungsionalitas dan

utilitas perangkat lunak, menggunakan:

 Function Points  Feature Points

(94)

94

5.2.1 Size-Oriented Metrics



Normalisasi kualitas dan produktivitas dengan

mengukur besar-kecilnya (LOC/KLOC)

perangkat lunak, sehingga diperoleh:

 Error per KLOC

 Defect (cacat) per KLOC  Rupiah (Rp) per LOC

 Halaman dokumentasi per KLOC



Metrik lain dapat diturunkan:

 Error per orang-bulan  LOC per orang-bulan

(95)

95

Contoh (size-oriented metrics)

alpha 12,100 24 168 365 134 29 3

beta 27,200 62 440 1224 321 86 5

gamma 20,200 43 314 1050 256 64 6

.. .. .. .. .. .. .. ..

(96)

96

Kontroversi Size-Oriented Metrics



Metrik size-oriented

tidak diterima secara universal

;

kontroversi terletak pada pemakaian LOC.



Pendukung: LOC merupakan artifak proyek

pengembangan perangkat lunak yang

mudah dihitung.



Penentang: LOC

tergantung bahasa pemrograman

,

LOC tidak mendukung desain yang baik tetapi

program singkat, tidak dapat dengan mudah

mengakomodasi bahasa non-prosedural, dan

pemakaiannya membutuhkan tingkat detail yang sulit

dicapai.

(97)

97

5.2.2 Function-Oriented Metrics



Mengukur secara tidak langsung.



Ditekankan pada fungsional & utilitas program.



Diusulkan pertama kali oleh Albrecht, dengan usulan

cara perhitungan yang disebut:

function

point (FP).



FP diturunkan dengan menggunakan hubungan empiris

berbasis pada sesuatu yang terukur dari domain

file



Jumlah

interface eksternal

: semua interface yang

dibaca oleh mesin untuk memindahkan informasi ke

sistem lain.

(99)

99

5.2.2.2 Penghitungan Metrik Function

Points

number of user inputs x 3 4 6 =

number of user outputs x 4 5 7 =

number of user inquiries x 3 4 6 =

number of files x 7 10 15 =

number of external interfaces x 5 7 10 =

total

measurement parameter count simple averagecomplex

Weighting Factor

FP= total x [0.65 + 0.01 x



F

_i

]

Domain kompleksitas

F_i (i = 1 s/d 14) adalah ‘complexity adjustment values’ berdasarkan

(100)

100

Pertanyaan-Pertanyaan

Untuk menghitung Fi, pertanyaan-pertanyaan di bawah ini dijawab dengan memberi nilai antara 0 s/d 5

Apakah sistem memerlukan backup dan recovery? Apakah diperlukan fasilitas komunikasi data?

Apakah diperlukan fasilitas ‘distributed processing’? Apakah kinerja sangat penting?

Apakah sistem akan dijalankan pada lingkungan yang sudah ada yang sudah terpakai secara penuh? Apakah memerlukan pemasukan data secara ‘on-line’?

Apakah pemasukan data ‘on-line’ terjadi pada transaksi input thd layar atau operasi ganda? Apakah file master di’update’ secara on-line?

Apakah input,output, file secara inquiry begitu kompleks? Apakah proses internal begitu kompleks?

Apakah kode yang dibuat harus dapat digunakan ulang? Apakah konversi dan instalasi termasuk dalam perancangan?

Apakah sistem dirancang untuk dapat diinstall pada berbagai organisasi yang berbeda?

(101)

berikut dipakai



Index = I + O + Q + F + E + T + R

Keterangan : I = input O = output

Q = inquiry, F = internal data structure E = external file, T = transformation, R = transition.

(102)

102

5.2.2.4 Penentuan Kompleksitas

Transformasi Function Points

Semantic Statements Processing Steps 1 - 5 6 - 10 11 + 1 - 10 11 - 20 21 +

low low average

low average high

(103)

103

Perhitungan 3D function point index

internal data structures x 7 + x 10 + x 15 =

external data x 5 + x 7 + x 10 =

number of user inputs x 3 + x 4 + x 6 =

number of user outputs x 4 + x 5 + x 7 =

number of user inquiries x 3 + x 4 + x 6 =

transformations x 7 + x 10 + x 15 =

transitions x n/a + x n/a + x n/a =

3D function point index

measurement element low average high

(104)

104 assembly language C Cobol Fortran Pascal Ada object-oriented languages

fourth generation languages (4GLs) code generators

spreadsheets

graphical languages (icons)

320 128 105 105 90 70 30 20 15 6 4

Programming Language LOC/FP (average)

Banyaknya LOC yang dibutuhkan untuk membangun 1 FP

5.3 Penyatuan Pendekatan

Metrik yang Berbeda

(105)

105

5.4 Kualitas Perangkat Lunak

5.4.1 Faktor yang Mempengaruhi Kualitas

McCall dan Cavano mendefinisikan satu set quality factors yang merupakan tahap awal untuk mengembangkan metrik untuk pengukuran kualitas

perangkat lunak:

 product operation (using it),

 product revision (changing it), dan  product transition (porting it).

(106)

106

5.4.2 Faktor yang Mempengaruhi Kualitas

(Gilb)

 Correctness: perangkat lunak bekerja dengan baik & benar ( correctness =

kesalahan / kloc )

 Maintainability: mudah dirawat; mttc (mean time to change) kecil  Integrity: tahan gangguan; tingkat sekuriti yang baik

(107)

107

5.5 Penyatuan Metrik-metrik dalam

Proses Perangkat Lunak

software engineering process software project software product data collection data collection data collection measures metrics indicators ***

(108)

108

6.1 Observasi pada Estimasi

6.2 Tujuan Perencanaan Proyek

6.3. Ruang Lingkup Perangkat Lunak

6.3.1. Rangkaian Pertanyaan SW Scope

6.3.1.1 Contoh Rangkaian Pertanyaan Pertama

6.3.1.2 Contoh Rangkaian Pertanyaan Kedua

6.3.1.3 Contoh Rangkaian Pertanyaan Ketiga

6.3.2. Contoh Scoping

6.3.2.1 Penjelasan Gambar

6.3.2.2 Dekomposisi Pernyataan

6.3.2.3 Kesimpulan Contoh Scoping 6.4 Sumber Daya

6.4.1 Sumber Daya Manusia

6.4.2 Reusable Software Resources

6.4.3 Environmental Resources

6.5. Estimasi Proyek Perangkat Lunak

6.5.1. Teknik Dekomposisi

6.5.1.1 Software Sizing

6.5.1.2 Problem-based Estimation

6.5.1.3 Contoh Estimasi Berbasis-LOC

6.5.1.4 Contoh Estimasi Berbasis FP

6.5.1.5 Contoh Estimasi Berbasis Proses

6.5.2 Empirical Estimation Models

6.5.2.1 Beberapa Model Estimasi

6.5.2.2 COnstructive COst MOdel (COCOMO)

6.5.2.3 Persamaan Perangkat Lunak

6. Perenc. Proyek Perangkat Lunak (Software

Project Planning)

(109)

109

 Project planning adalah serangkaian aktivitas-aktivitas kolektif dalam proses

manajemen proyek perangkat lunak.

 Estimation adalah aktivitas pertama dalam project planning

 Estimation menjadi dasar bagi aktivitas perencanaan proyek yang lain.

 Project planning menjadi peta jalan bagi kesuksesan rekayasa perangkat lunak

(110)

110

6.1 Observasi pada Estimasi



Estimasi pada project planning meliputi estimasi

sumber daya, biaya, dan jadwal

pengembangan

perangkat lunak.



Hal-hal yang mempengaruhi estimasi:

 Project complexity (kompleksitas proyek); berpengaruh

terhadap ketidakpastian yang inheren dalam perencanaan

 Project size (ukuran project); berpengaruh terhadap akurasi

estimasi

 Structural uncertainty (ketidakpastian struktural);

(111)

111

6.2 Tujuan Perencanaan Proyek

 menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat

estimasi yang dapat dipertanggungjawabkan mengenai sumber daya, biaya, dan jadwal.

 Tujuan project planning dapat tercapai melalui proses penemuan informasi

(112)

112

6.3. Ruang Lingkup Perangkat Lunak

(Software Scope)



Fungsi (functions)



Kinerja (perfomance)



Batasan(constraints)



Antarmuka (interface)



Keandalan (reliability)

(113)

113

6.3.1. Rangkaian Pertanyaan SW Scope

 Lingkup PL yang akan dibuat ditentukan melalui

pertemuan-pertemuan antara customer dengan developer

 Untuk menjembatani jurang komunikasi antara

customer dengan developer, Gause & Weinberg mengusulkan 3 rangkaian pertanyaan berikut:

 Rangkaian pertanyaan pertama adalah sekumpulan

pertanyaan bebas konteks yang memusatkan pada customer, sasaran keseluruhan PL yang dibuat, dan keuntungan yang akan diperoleh.

 Rangkaian pertanyaan kedua adalah sekumpulan

pertanyaan yang memungkinkan analis mendapatkan

pemahaman yang lebih baik atas problem, dan customer dapat menyuarakan persepsinya atas suatu solusi.

 Rangkaian pertanyaan ketiga adalah

pertanyaan-pertanyaan yang memusatkan pada efektivitas dari pertemuan itu sendiri (disebut meta-questions).

(114)

114

6.3.1.1 Contoh Rangkaian Pertanyaan Pertama

 Siapa di belakang permintaan pekerjaan ini?  Siapa yang akan menggunakan solusi ini?

 Keuntungan ekonomis apa yang diperoleh dari solusi ini?  Adakah sumber daya lain untuk solusi ini?

(115)

115

6.3.1.2 Contoh Rangkaian Pertanyaan Kedua



Bagaimana anda mengkarakterisir keluaran “yang

baik” yang akan dimunculkan oleh solusi ini?



Problem apa saja yang akan dihadapi oleh solusi

ini?



Dapatkan anda menunjukkan kepada kami (atau

menjelaskan) lingkungan di mana solusi ini akan

dipakai?



Adakah batasan atau isu kinerja khusus yang akan

(116)

116

6.3.1.3 Contoh Rangkaian Pertanyaan Ketiga

 Apakah anda orang yang tepat untuk menjawab pertanyaan-pertanyaan

ini? Apakah jawaban anda “resmi”?

 Apakah pertanyaan-pertanyaan kami relevan untuk problem yang anda

punya?

 Apakah saya terlalu banyak pertanyaan?

 Apakah ada orang lain yang dapat memberikan informasi-informasi

tambahan?

(117)

117

6.3.2. Contoh Scoping

1 2 3 4 5 6 ID No. ID No. ID No. ID No. SORTING STATION _control connection conveyor line motion shunt bar code

(118)

118

6.3.2.1 Penjelasan Gambar

 Conveyor Line Sorting System (CLSS) menyortir box-box

yang bergerak pada ban berjalan.

 Setiap box diidentifikasi dengan bar code yang

menyatakan nomor part.

 Box-box tersebut akan disortir ke dalam 6 wadah

berdasarkan nomor part.

 Box-box tersebut melewati stasiun sortir yang berisi

pembaca bar code dan sebuah PC (Personal Computer).

 PC di stasiun sortir dihubungkan dengan mekanisme

langsiran (shunt) yang akan menyortir box-box tersebut ke dalam wadah-wadah yang sesuai.

 Box-box tersebut lewat dengan urutan yang acak dan

berjarak sama.

 PL CLSS menerima informasi masukan dari pembaca bar

code dengan interval waktu sesuai dengan kecepatan ban berjalan.

(119)

119

6.3.2.1 Penjelasan Gambar(lanj)

 Data bar code tersebut akan didekodekan ke dalam format

identifikasi box.

 PL akan melakukan look-up pada basis data part number

yang berisi maksimum 1000 entry untuk menentukan lokasi

wadah yang sesuai bagi box yang saat itu di stasiun sortir.

 Lokasi wadah yang sesuai diberikan pada sorting shunt yang

akan menempatkan box tersebut pada wadah yang sesuai.

 Sebuah catatan (record) yang berisi wadah tujuan dari

setiap box dibangkitkan untuk recovery nantinya dan pelaporan.

 PL CLSS juga menerima masukan dari sebuah tachometer

pulsa yang akan dipakai untuk sinkronisasi sinyal kontrol ke mekanisme shunting.

 Berdasarkan pada jumlah pulsa yang akan dibangkitkan

antara stasiun sortir dan shunt, PL akan menghasilkan sebuah sinyal kontrol ke shunt untuk menenpatkan box tersebut dengan benar.

(120)

120

6.3.2.2 Dekomposisi Pernyataan

 Dekomposisi dari pernyataan di atas, dapat diekstrak

menjadi fungsi-fungsi penting dari PL yang akan dibuat; yaitu:

 read bar code input (membaca input bar code)

 read pulse tachometer (membaca pulsa tachometer)

 decode part code data (mengkodekan bagian data kode)  do database look-up (mengerjakan look-up database)  determine bin location (menentukan lokasi kotak

penyimpanan

 produce control signal for shunt (memproduksi sinyal

kontrol untuk shunt)

 maintain record of box destinations (memelihara

(121)

121

6.3.2.3 Kesimpulan Contoh Scoping



Kinerja sistem ini ditentukan oleh kecepatan ban

berjalan.

Pemrosesan setiap box harus selesai

sebelum box berikutnya tiba di pembaca bar code

.



Kendala-kendala yang membatasi PL CLSS adalah

meliputi

perangkat keras

yang harus diakses

(pembaca bar code, shunt, PC), memori yang

tersedia, dan konfigurasi keseluruhan dari lini ban

berjalan tersebut.

(122)

122

6.3.2.3 Kesimpulan Contoh Scoping (lanj)



Interface

: PL yang dibuat berinteraksi dengan

elemen-elemen lain dari sistem berbasis komputer

ini. Konsep interface mempunyai arti;

(1) hardware yang mengeksekusi PL dan perangkat lain yang secara tidak langsung dikontrol oleh PL tersebut.

(2) software yang telah ada dan harus dilink dengan software yang baru (dibuat) tersebut.

(3) orang yang menggunakan PL tersebut via keyboard atau I/O devices lainnya.

(4) prosedur-prosedur yang mengawali atau mengakhiri (mengikuti) PL tersebut sebagai urutan operasi yang sekuensial.

(123)

123

6.4 Sumber Daya

Hardware/Software Tools Reusable Software Components People

(124)

124

6.4.1 Sumber Daya Manusia

 Diperlukan keahlian untuk menyelesaikan pengembangan PL; baik dari segi

posisi organisasional (misal: manager, senior software engineer, dsb) maupun spesialisasi (misal: telekomunikasi, basis data, dsb).

 Sedangkan jumlah banyaknya personil yang dibutuhkan ditentukan setelah

(125)

125

6.4.2 Reusable Software Resources



Off-the-shelf components;

memanfaatkan

yang telah

dibuat pada proyek internal sebelumnya.



Full-experience components;

mereview

spesifikasi,

kode, desain atau pengujian data dari proyek

sebelumnya



Partial-experience components; aplikasi, kode, desain

atau data dari proyek sebelumnya

dihubungkan

dengan proyek sekarang

(126)

126

6.4.3 Environmental Resources

 Lingkungan yang mendukung proyek PL, disebut juga software engineering

environment (SEE); meliputi

 hardware  software

(127)

127

6.5. Estimasi Proyek Perangkat Lunak

(

Software project estimation

)

 Ada 2 teknik dalam melakukan estimasi proyek perangkat lunak, yaitu:



Decomposition Techniques

(128)

128

6.5.1. Teknik Dekomposisi

(Decomposition techniques)

 Dekomposisi masalah : memecah-mecah masalah yang

kompleks menjadi serangkaian masalah yang lebih kecil.

 Ketelitian estimasi proyek PL diprediksi pada sejumlah hal:

(1) derajat ketepatan estimasi ukuran produk yang akan dibuat,

(2) kemampuan menterjemahkan ukuran terestimasi

tersebut ke dalam beban kerja, waktu kalender, dan rupiah,

(3) derajat rencana proyek yang mencerminkan kemampuan tim software, dan

(4) kestabilan persyaratan-persyaratan produk dan lingkungan yang mendukung upaya software engineering.

(129)

129

6.5.1.1 Software Sizing



Dalam kontek project planning, size mengacu pada

hasil-hasil proyek PL yang dapat dikuantifikasi.



Putnam & Myers mengusulkan 4 cara untuk

pengukuran problem;

 Fuzzy-logic sizing; menggunakan teknik reasoning

aproksimasi

 Function point sizing; mengembangkan estimasi karakteristik

domain informasi

 Standard component sizing; menggunakan

komponen-komponen standar yang ada.

 Change sizing; memodifikasi PL dengan banyak cara,

menggunakan suatu rasio kerja setiap perubahan, sehingga ukuran perubahan dapat diperkirakan

(130)

130

6.5.1.2 Problem-based Estimation

 Data LOC dan FP dipakai dalam dua hal selama estimasi proyek PL:

(1) sebagai suatu estimation variable yang dipakai untuk “memberi ukuran”

pada setiap elemen PL yang akan dibuat, dan

(2) sebagai baseline metrics yang dikumpulkan dari proyek terdahulu dan dipakai bersama-sama dengan estimation variable untuk menghitung proyeksi biaya dan beban kerja.

(131)

131

 Tanpa memandang variabel estimasi yang dipakai, project planner mulai

dengan mengestimasi rentang nilai untuk setiap fungsi atau nilai domain informasi.

 Dengan menggunakan data historis atau intuisi, ditentukan ukuran nilai

yang optimistik (sopt), rata-rata (sm), dan yang pesimistik (spess).

 Kemudian dihitung nilai yang diharapkan (three-point atau expected

value) sbb.

 EV = (sopt + 4 sm + spess)/6