software engineering

SOFTWARE ENGINEERING 1

Software EngineeringDEVELOPMENT PLAN & REQUIREMENTS ANALYSIS


Mau buat apa? Bagaimana memulainya?Apa pekerjaan pertama yang harus dilakukan?

Pekerjaan pertama → analisis◦ Analisis itu apa?◦ Apakah sebelum analisis tidak ada pekerjaan lainnya?◦ Analisis → requirements analysis◦ Requirements → sesuatu yang dimiliki oleh pengguna maupun yang

berkepentingan, baik secara eksplisit maupun potensial

Requirements analysis◦ Mengidentifikasi requirements yang dimiliki pengguna dan stakeholders,

untuk kemudian didefinisikan requirements specification.◦ → menentukan apa yang akan dibuat


Apakah mau dibuat? Requirements analysis tidak semudah yang dibayangkan

◦ Apakah sistem harus dibuat?◦ Apakah memang harus dipertimbangkan pembuatan sistem?◦ Untuk bisa menentukan itu, harus tahu terlebih dahulu sistem seperti apa

yang dibayangkan

"Mau buat apa?" dan "Mau dibuat atau tidak?"◦ Harus dipikirkan bersama-sama

Nilai yang dimiliki oleh (sistem) software◦ ekonomi, psikologi, analisis pasar, identifikasi masalah dan pencarian solusi,

dan hal lain yang banyak dipengaruhi oleh faktor manusia◦ → jobs of system analyst


Systemization ≠ Computerization

Apa itu sistem?

Sistem adalah, mekanisme untuk menghasilkan sesuatu (suatu tujuan, target) secara terus menerus

Sistemisasi (atau sistematisasi) adalah, upaya untuk membangun mekanisme itu

Sistemisasi tidak selalu sama dengan komputerisasi


Pertimbangan pembuatan sistem

Selain fungsi yang diminta, juga perlu dipertimbangkan◦ Manfaat, keuntungan◦ Biaya◦ Waktu (pengembangan), jadwal◦ Sumber daya◦ Manajemen, organisasi, pasar, peraturan, social, dan constraint lainnya

Pada tahap awal pengembangan sistem, faktor ini dibahas secara keseluruhan, berdasarkan itu, diputuskan apakah proyek dilaksanakan atau tidak

Pengambilan keputusan diambil tidak hanya oleh manajer saja, namun juga oleh developer dan pihak terkait lainnya (stakeholders)


Hasil perencanaan sistem

Isi dokumen perencanaan sistem:◦ Latar belakang◦ Tujuan pengembangan◦ Target domain (cakupan)◦ Kondisi bisnis (pekerjaan) saat ini◦ Kondisi bagian yang sudah disistemkan◦ Ringkasan sistem yang akan dibuat◦ Efek/manfaat◦ Syarat dan kondisi atau constraint◦ Rencana pengembangan dan implementasi◦ Estimasi biaya pengembangan◦ Sumber daya yang diperlukan


Metode analisis sistemMetode Maker Metode Maker

EPG Fujitsu F-SPAN Fuji Film

C-NAP Fujitsu BSP IBM

PPDS Hitachi CPS IBM

STEPS/E Nichiden TUPPS Toshib

NUPS Unisys


Estimasi biaya Tidak ada metode yang pasti, namun yang umum dilakukan

◦ dengan metode tertentu ditentukan skala besarnya software◦ dari skala besarnya software, dengan metode tertentu, ditentukan

production-cost-nya (man-hour, man-month, dsb)◦ dari production-cost, ditentukan waktu/jadwal dan jumlah personil

The mythical man-month◦ Jika ada proyek pengembangan software yang terlambat, kalau ditambah

personil, akan menjadi lebih terlambat (F. P. Brooks, Jr)


Relasi orang bulan

teori

Hukum Brooks


Requirements Engineering

Lahir pertengahan tahun 1970-1980

Contoh metode dalam RE◦ PSL/PSA

D. Teichrow (Michigan Univ), dalam proyek ISDOS (Information System Design and Optimization System), membuat PSL (Problem Statement Language) dan PSA (Problem Statement Analysis)

◦ SREM (Software Requirement Engineering Methodology)Metode yang dibangun di TRW Huntsville Lab; RSL (Requirements Specification Languange), R-Net (Requirements Network), untuk realtime system

◦ SADT (Structured Analysis Design Technique)Dibangun oleh D.T. Ross from Softech Corp; Input, Output, Control data, dan Resources, dihubungkan dengan tanda panah dari kiri kanan atas bawah.Selanjutnya berkembang menjadi IDEF0 (Integration Definition for Functional Modeling)


Konsep requirements analysis

Terbagi menjadi dua proses◦ Proses untuk memperjelas apa yang diinginkan dari kondisi yang tidak

jelas/ambigu menjadi kondisi yang jelas→ requirements analysis, problem analysis, atau analisis saja

◦ Proses untuk mendeskripsikan apa yang diinginkan, menggunakan specification definition model/language→ requirements specification, specification description

Tipe analisis permintaan◦ Extraction of requirements

needs/Idea → requirements◦ Goals oriented

hierarchy of goals◦ Domain model


Contoh skenario Drink Vending Machine

1. Pembeli memasukkan uang kertas atau koin atau keduanya ke dalam mesin2. Jumlah uang yang dimasukkan muncul, dan lampu pada minuman yang

harganya sesuai dengan jumlah uang yang dimasukkan akan menyala3. Pembeli menekan tombol yang lampunya menyala, dan minuman akan

keluar, kemudian jumlah uang akan berkurang4. Jika pembeli akan membeli minuman yang lain, bisa dilakukan selama

lampu pada minuman/tombol masih menyala5. Pembeli bisa kembali ke nomor 1, yaitu memasukkan uang, kemudian

mengulang nomor 2 dan seterusnya6. Jika masih ada sisa uang, pembeli dapat menekan tombol "Kembali" untuk

mengeluarkan sisa uang


Contoh goal deployment


Tipe permintaan Terbagi menjadi functional dan non-functional

Non-functional misalnya◦ performa/kinerja◦ kemudahan dalam penggunaan◦ keamanan◦ kemudahan dalam pemeliharaan/perawatan◦ portabilitas atau kemudahan dalam mobilitas◦ dsb. (berbagai macam bergantung referensinya)

Antar permintaan bisa saling bentrok, selalu ada tradeoff→ Harus ada penyeimbangan


Spesifikasi vs Requirements

spesifikasi, karakteristik lingkungan → requirements

program, karakteristik mesin → specification


Apa yang harus dispesifikasi

Komponen dalam spesifikasi◦ Functional specification◦ Performance specification◦ Reliability specification◦ Interface specification◦ dsb. (berbagai macam bergantung referensinya)

Namun dalam prakteknya, tidak semudah yang dibayangkan◦ Contoh: program untuk mencari pembagi terbesar dari dua bilangan

Yang harus membuat spesifikasi◦ Pihak yang harus menyampaikan permintaan (pemesan)◦ Pihak yang merealisasikan permintaan (pembuat)


Syarat spesifikasi yang baik

Syarat spesifikasi yang bai◦ Legitimate

Jelas, konsisten, tidak ada kontradiksi, dan tidak ada yang terlewat◦ Strict

Tegas, tidak ada yang ambigu, seluruhnya terdefinisi◦ Readable

Mudah dibaca dan dimengerti◦ Verifiable

Konsistensinya bisa diverifikasiJika bisa diverifikasi secara otomatis lebih baik

◦ Possible/feasibleBisa direalisasikan dengan implementasi yang konkrit

Selalu ada tradeoff

software engineering

Documents