BAB II LANDASAN TEORI
Pada bab ini akan dibahas mengenai teori- teori yang melandasi penulisan tugas akhir ini. Teori ini akan menjadi dasar dari pembangunan sistem, terutama mengenai konsep dasar sistem, teori Software engineering risk management (SERIM) dan Unified Model Language.
2.1
Konsep Dasar Sistem
2.1.1
Definisi Sistem Pada umumnya setiap organisasi selalu mempunyai suatu sistem informasi
untuk mengumpulkan, menyimpan, melihat dan menyalurkan informasi. Sistem informasi dapat terbentuk karena didorong oleh kebutuhan akan informasi yang terus meningkat yang dibutuhkan oleh pengambil keputusan. Berikut beberapa definisi sistem diantaranya : a. Sistem adalah sekelompok bagian yang disusun dan diatur dengan baik yang bekerjasama untuk melakukan suatu maksud. b. Sistem adalah suatu grup dari elemen-elemen baik yang berbentuk fisik maupun bukan fisik yang menunjukan suatu kumpulan yang saling berhubungan dan berinteraksi bersama-sama menuju satu atau lebih tujuan, sasaran, atau akhir dari system. Dari beberapa definisi sistem diatas dapat disimpulkan bahwa sistem dikelompokan menjadi dua bagian yang menekankan pada prosedurnya dan ada yang menekankan pada elemennya. Kedua kelompok ini adalah benar dan tidak bertentangan, yang berbeda adalah cara pendekatannya.
II-1
II-2
2.1.2
Karakteristik Sistem Suatu sistem mempunyai karakteristik dan memiliki sifat-sifat tertentu
dimana ada komponen sistem, batasan, lingkungan luar, penghubung, masukan sistem, keluaran sistem, pengolahan sistem, serta sasaran sistem. Yang dijelaskan sebagai berikut:
a. Komponen Sistem (Components) Suatu sistem terdiri dari sejumlah komponen yang saling berinteraksi, yang artinya
saling bekerja sama membentuk satu kesatuan. Komponen-
komponen sistem atau elemen-elemen sistem dapat berupa suatu sub sistem atau bagian-bagian dari sistem yang mempunyai sifat-sifat dari sistem untuk menjalankan suatu fungsi tertentu dan mempengaruhi proses sistem secara keseluruhan. b. Batas Sistem (Boundary) Batas sistem merupakan suatu daerah yang membatasi antara suatu sistem dengan sistem yang lainnya atau dengan lingkungan luarnya, yang menunjukkan ruang lingkup (scope) sistem tersebut. c. Lingkungan Luar Sistem (Environment) Lingkungan luar dari suatu sistem adalah segala sesuatu di luar batas sistem yang mempengaruhi operasi sistem, dapat bersifat menguntungkan dan dapat juga bersifat merugikan sistem tersebut. Lingkungan luar sistem yang menguntungkan yaitu energi dari sistem dan dengan demikian harus tetap dijaga dan dipelihara. Sedangkan lingkungan luar sistem yang merugikan harus ditahan dan dikendalikan, kalau tidak akan menggangu kelangsungan hidup sistem. d. Penghubung Sistem (Interface) Penghubung merupakan media penghubung antara satu subsistem dengan subsistem yang lainnya. Dengan penghubung satu subsistem dapat berinteraksi dengan subsistem lainnya membentuk satu kesatuan. Keluaran dari satu subsistem memungkinkan menjadi masukan untuk subsitem lainnya melalui media penghubung.
II-3
e. Masukan Sistem (Input) Masukan adalah energi yang dimasukan ke dalam sistem dan menentukan keluaran sistem. Masukan dapat berupa masukan perawatan (maintenance input) dan masukan sinyal (signal input). Maintenance input adalah energi yang dimasukan supaya system tersebut dapat beroperasi. Signal input adalah energi yang diproses untuk mendapatkan keluaran. f.
Keluaran Sistem (Output) Keluaran adalah hasil dari energi yang diolah dan diklasifikasikan menjadi keluaran yang berguna dan sisa pembuangan. Keluaran dapat merupakan masukan untuk subsistem lain.
g. Pengolah Sistem (Process) Pengolah merupakan bagian yang merubah masukan menjadi keluaran. h. Sasaran Sistem (Objectives) atau Tujuan (Goal) Jika suatu sistem tidak mempunyai sasaran, maka operasi sistem tidak akan ada gunanya. Sasaran dari sistem sangat menentukan masukan yang akan dibutuhkan oleh sistem dan keluaran yang akan dihasilkan sistem. Suatu sistem dikatakan berhasil bila mengenai sasaran atau tujuannya.
2.1.3
Klasifikasi Sistem Sistem dapat diklasifikasikan dari beberapa sudut pandang. Mulai dari
Sistem abstrak, alamiah, sistem tertentu, system tertutup, yang dijelaskan sebagai berikut: a. Sistem Abstrak (Abstract System) dan Sistem Fisik (Physical System) Sistem abstrak adalah sistem yang berupa pemikiran atau ide-ide yang tidak tampak secara fisik. Sistem fisik merupakan sistem yang ada secara fisik. b. Sistem Alamiah (Natural System) dan Sistem Buatan Manusia (Human Made System) Sistem alamiah adalah sistem yang terjadi melalui proses alam, tidak dibuat manusia. Sistem buatan manusia adalah sistem yang dirancang dan dibuat oleh manusia.
II-4
c. Sistem Tertentu (Deterministic System) dan Sistem Tak Tentu (Probabilistic System) Sistem tertentu beroperasi dengan tingkah laku yang sudah dapat diprediksi. Sistem tak tentu adalah sistem yang kondisi masa depannya tidak dapat diprediksi karena mengandung unsur probabilitas. d. Sistem Tertutup (Closed System) dan Sistem Terbuka (Open System) Sistem tertutup merupakan sistem yang tidak berhubungan dan tidak terpengaruh dengan lingkungan luarnya. Sistem ini bekerja secara otomatis tanpa adanya turut campur dari pihak luarnya. Sistem terbuka adalah sistem yang berhubungan dan terpengaruh dengan lingkungan luarnya. Sistem ini menerima masukan dan menghasilkan keluaran untuk lingkungan luar atau subsistem yang lainnya.
2.2
Pengertian SERIM (Software Engineering Risk Management)[1] SERIM (Software Engineering Risk Management) merupakan model yang
digunakan untuk memberikan manajemen pemecahan alternatif resiko pada suatu proyek perangkat lunak[1]. SERIM digunakan sebagai pendekatan untuk menghitung resiko perangkat lunak. Pendekatan berdasarkan subyek-subyek kemungkinan berdasarkan pengalaman dan analogi kejadian. SERIM dihitung berdasarkan pertanyaan matrik resiko perangkat lunak. Nilai yang didapatkan dari pertanyaan tersebut akan selalu berbeda antara satu orang dengan yang lain, hal ini disebabkan jawaban didasarkan pada perasaan setiap orang dari pengalaman masing-masing terhadap produk bisnis dan lingkungan dalam membangun perangkat lunak.
2.2.1 Ruang Lingkup SERIM (Software Engineering Risk Management) Beberapa penelitian mengenai manajemen resiko telah diperkenalkan dan dikembangkan oleh beberapa peneliti. Kumpulan penelitian tersebut tidak dapat kita perbandingkan antara satu dengan yang lainnya, disebabkan ruang lingkup penelitian manajemen resiko yang digunakan berbeda-beda.
II-5
Manajemen resiko perangkat lunak harus dapat dianalisis, dinilai dan dievaluasi dari berbagai ruang lingkup proyek. Pada SERIM ruang lingkup manajemen resiko terdiri dari : elemen resiko, aktivitas resiko, faktor resiko, matrik resiko dan metodelogi life cycle.
2.2.1.1 Elemen Resiko Penerapan manajemen resiko pada proyek perangkat lunak tidak lepas dari pertimbangan teknologi dan bisnis. Perspektif teknologi menjelaskan alat bantu (tools), teknik dan lingkungan, dimana perangkat lunak tersebut diterapkan. Perspektif bisnis menjelaskan sumber daya, jadwal dan dampak bisnis (keberhasilan pembangunan perangkat lunak). Perangkat lunak JIT mampu untuk mengelola resiko perangkat lunak, baik menurut prespektif teknologi maupun bisnis
[1]
. Tidak
semua resiko dalam prespektif di atas masuk ke dalam resiko perangkat lunak. Hanya terdapat 3 elemen dari resiko yang digunakan dalam perangkat lunak JIT yaitu teknologi, biaya dan penjadwalan. Elemen teknologi berhubungan dengan kinerja perangkat lunak, yaitu : kehandalan, kualitas, fungsi, pemeliharaan dan kegunaan kembali. Elemen biaya berhubungan dengan biaya perangkat lunak selama pembangunan perangkat lunak seperti variable cost, fix cost dan budget. Sedangkan elemen penjadualan berhubungan dengan jadual proyek selama membangun perangkat lunak, seperti : jadual realisasi,
jadual
pertemuan
dengan
pelanggan
dan
anggota
pengembang dan jadual perubahan waktu proyek.
2.2.1.2 Aktivitas Resiko Aktivitas resiko merupakan cara melakukan evaluasi terhadap resiko berdasarkan pandangan dari operasional, strategi, teknologi, bisnis, industri dan para praktisi
[1]
. Terdapat 6 (enam)
II-6
aktivitas yang dilakukan dalam mengevaluasi manajemen resiko perangkat lunak yaitu : 1. Identifikasi resiko yaitu melakukan pengumpulan informasi mengenai
proyek
perangkat
lunak
dan
mengklasifikasikan
informasi tersebut untuk menentukan resiko yang paling potensial dari suatu proyek. Informasi dikumpulkan dengan merujuk data pada proyek perangkat lunak yang pernah dikerjakan. 2. Strategi
dan
perencanaan
resiko
yaitu
mengembangkan
alternatifalternatif resiko yang akan muncul selama pembangunan perangkat lunak. 3. Penilaian resiko adalah memutuskan dampak resiko yang paling potensial melalui suatu penilaian. 4. Pengurangan/penghindaran resiko yaitu aktivitas yang dilakukan dalam meminimalkan atau menghindari efek resiko. 5. Membuat
laporan
digunakan
untuk
mendokumentasikan
pengelolaan resiko dari proyek perangkat lunak, termasuk melakukan perbandingan status resiko dengan resiko proyek yang pernah dikerjakan. 6. Prediksi resiko yaitu melakukan prediksi tentang perkembangan resiko dari proyek dengan menggunakan interasi data dan pengetahuan
2.2.1.3 Faktor- faktor Resiko Perangkat Lunak Meskipun secara tidak langsung berpengaruh terhadap perangkat lunak. Faktor resiko sangat bermanfaat dalam menjelaskan karakteristik proyek yang dikerjakan pada masa lalu. Penelitian dari Mc Call dan Boehm menjelaskan terdapat 10 faktor resiko perangkat lunak, dimana faktor resiko tersebut berhubungan dengan kualitas dan kehandalan produk perangkat lunak.
II-7
Satu faktor resiko dapat berhubungan lebih dari satu elemen resiko. Faktor resiko juga berpengaruh terhadap proses dan produk perangkat lunak. Berdasarkan pengalaman industri perangkat lunak, setiap faktor resiko diberi pembobotan penilaian berupa tinggi, sedang dan rendah seperti terlihat pada tabel 2.1, dimana bobot tersebut menyatakan derajat pengaruh faktor resiko terhadap elemen resiko.
Faktor Resiko
Elemen ResikoPerangkat Lunak Teknologi
Biaya
Penjadwalan
Organization
Rendah
Tinggi
Tinggi
Estimation
Rendah
Tinggi
Tinggi
Monitoring
Sedang
Tinggi
Tinggi
Development Methodology
Sedang
Tinggi
Tinggi
Tools
Sedang
Sedang
Sedang
Risk Culturre
Tinggi
Sedang
Sedang
Usability
Tinggi
Rendah
Rendah
Correctness
Tinggi
Rendah
Rendah
Reability
Tinggi
Rendah
Rendah
Personnel
Tinggi
Tinggi
Tinggi
Tabel 2.1 Derajat Pengaruh Faktor Resiko Terhadap Elemen Resiko
2.2.1.4 Matrik Resiko Matrik resiko digunakan untuk menilai faktor resiko dalam perangkat lunak. Konsep ini dikemukan pertama kali oleh Mc Call dan Boehm yang berfungsi untuk mendapatkan perangkat lunak yang berkualitas dan handal. Matrik resiko perangkat lunak merupakan kumpulan pertanyaan (kuesioner) dengan jawaban yang diberi bobot nilai sesuai dengan pendapat para manajemen proyek perangkat lunak.
II-8
2.2.2 Contoh Kasus Pada sesi ini, peneliti mencoba untuk menerapkan SERIM dalam proyek perangkat lunak, dimana penelitian dilakukan Universitas Tapanuli Utara pada unit UNITA Center. Tugas utama unit UNITA center adalah mengembangkan seluruh perangkat lunak berada di bawah lingkungan universitas. Pada tahun 2009 UNITA center merencanakan untuk membangun sistem akademik yang terpadu, sehingga memungkinan dosen, mahasiswa dan orang tua dapat berinteraksi dalam suatu wadah. Perangkat lunak
tersebut,
direncanakan
dibangun
selama
8
bulan
dengan
mempekerjakan 8 programmer, 1 sistem analis dengan bahasa pemrograman dasar PHP dan java. Untuk menghindari kegagalan dalam proyek tersebut, peneliti dan pihak UNITA center merencanakan melakukan analisis resiko pada tahap awal pembangunan perangkat lunak. Adapun tujuan yang ingin dicapai dalam penelitian ini adalah : Menerapkan aplikasi estimasi resiko dalam proyek, sehingga dapat mengetahui ruang lingkup resiko proyek dan strategi melakukan analisis dan penilaian terhadap resiko yang muncul.
2.2.3 Pengumpulan Data Penggunaan kuisoner merupakan salah satu metode paling popular dan luas untuk mengumpulkan data dan informasi. Kuesioner matrik resiko yang digunakan pada penelitian, terdiri 81 pertanyaan yang berfungsi melakukan evaluasi terhadap ruang lingkup aplikasi estimasi resiko. Sedangkan analis dan programmer merupakan representatif responden dari informasi yang dikumpulkan. Pertanyaan yang digunakan dalam penelitian ini dapat dilihat pada lampiran dengan contoh pertanyaan sebagai berikut:[2]
II-9
Organizations O1. Are you using or do you plan to use experienced software managers? O2. Has your company been producing software similar to this in the past? O3. Is there a documented organizational structure either in place or planned? O4. Is the organizational structure stable? O5. What is the confidence level of your management team? O6. Does good communication exist between different organizations supporting the development of the software project? O7. Are software configuration management functions being performed? O8. Are software Quality function being performed?
Estimation E1. What Estimation method is used? a. Guess b. Analogy c. Price to win d. Dictated by circumstances e. Top-down f. Bottom-up g. Other E2. Is a Software cost model used? E3. Is the estimation based on past software productivity metrics? E4. Are the schedule estimates based on past software projects?
II-10
E5. Are estimates revised on a monthly or more frequent basis? E.6 How accurate are your past cost estimates compared to actual costs? E7. How accurate are your past schedule estimates compared to actual schedule?
Monitoring M1. For each major software effort, are there distinct milestones set for each software development phase? M2. Is a detailed WBS used to track and report, costs and budget for each piece of major software development? M3. Is there a monitoring system setup for cost, schedule, and earnedvalue? M4. Are cost, Schedule, and earned-value reports available on demand? M5. Are costs, schedule and earned-value reports updated on a monthly or more frequented basis? M6. Is there a problem log or action log system? Is it used and updated on a weekly basis? M7. Does a means exist to address and record technical problems? Is it used and updated on a weekly basis?
Development and methodology. DM1. Is there a documented software development methodology or plan used for the project, and it is being adhered to closely?
II-11
DM2. Are the software developers trained in the development methodology? DM3. How closely is the development methodology followed? DM4. Does the development methodology include requirements, design, and code reviews/walkthroughs/inspection? DM5. Does the development methodology require test plans and/or test procedures for all software functions? DM6. Does the development methodology require documentations such as requirements, design, and software development folders? DM7. Is regression testing performed? Tools T1. Are the software developers trained in using the tools? T2. Are the automated tools used for software design? T3. Are automated tools used for testing? T4. Are automated tools used for test procedure generation? T5. Are automated tools used for regression testing? T6. Are automated tools used for requirements traceability? T7. Are automated tools used for re-engineering (identifying, existing characteristic of the software based on its code, such as its structure, data dictionary, and so forth)? T8. How stable is your compiler/linker/debugger? T9. Are tools readily available to the software development personnel when needed?
II-12
Risk culture RC1. Is your company willing to trade additional budget risk for additional profit? RC2. Is your company willing to trade additional schedule risk for additional profit? RC3. Is your company willing to trade additional technical risk for additional profit? RC4. Is your company willing to trade less budget risk for less profit? RC5. Is your company willing to trade less schedule risk for less profit? RC6. Is your company willing to trade less technical functionality for less profit? RC7. Is your company marked-driven? RC8. Is your company culture conservative in its decision-making? RC9. How does your company’s investment in new products and technology rate? RC10. Does your company tend to build or to acquire new product and/or technology? RC11. Does your company practice risk management?
Usability U1. Is there a user manual for the software? U2. Are there help function for each input or output screen?
II-13
U3. Is the user involved in reviewing prototypes or earlier versions of the software? U4. Is the user interface designed to an industry standard or to a standard familiar to the user? U5. Have user response times been identified? U6. Has the design been evaluated to minimize keystrokes and data entry?
Correctness C1. Have all the software requirements been identified and documented? C2. Have the software requirements been traced to the design? C3. Are the software requirements traceable to the code? C4. Are the software requirements traceable to the test procedures? C5. Have there been, or are there expected to be, many changes made in the requirements? C6. Are the software designs traceable to the code? C7. Is the software design traceable to the test procedures? C8. Have the all open action items been addressed and implemented prior to delivery to the customer? C9. Has software functional testing been performed prior to customer delivery?
II-14
Reliability R1. Are there error handling conditions within the software design and code? R2. When an error condition is detected, does processing continue? R3. Are error tolerances defined for input and output data? R4. Are inputs checked for valid values before processing begins? R5. Are hardware faults detected and processed in the software? R6. Is the use of global data types minimized? R7. Is defect data collected during software integration? R8. Is defect data being logged-in and closed-out prior to delivery to the customer? R9. Is a software reliability model used to predict reliability? R10. Are tests performed with test plans? R11. Has stress testing been performed? R12. Is testing performed by a group separate from the software development group?
Personnel P1. Are personnel resources available and identified? P2. How experienced are the personnel resources in the product type being developed? P3. How experienced are the personnel resources in the development environment?
II-15
P4. How experienced are the personnel resources in the implementation language? P5. How large will the number of software development personnel be at peak? Secara
umum
bobot
yang dibangkitkan
untuk
menjawab
pertanyaan pada matrik resiko adalah nilai probabilitas antara 0 sampai 1 seperti yang terlihat pada tabel 2.2
Nilai Jawaban
Keterangan
0.0 – 0.2
Tidak Pernah
0.2 – 0.4
Jarang
0.4 – 0.6
Kadang- Kadang
0.6 – 0.8
Sering
0.8 – 1.0
Pasti
Tabel 2.2 Bobot Nilai Setiap Jawaban Kuisioner Matrik Resiko
Berdasarkan tabel di atas, maka kita dapat menjawab setiap pertanyaan matrik resiko dengan menggunakan nilai jawaban yang kita sesuaikan dengan derajat persetujuan pada kolom keterangan. Pertanyaan no 1. dari contoh, kita dapat memberikan nilai 0.1, jika perangkat lunak yang dibangun tidak berdasarkan pengalaman proyek sebelumnya. Nilai 0.3, jika pembangunan perangkat lunak jarang menggunakan pengalaman proyek sebelumnya. Nilai 0.5, jika pembangunan perangkat lunak kadang-kadang menggunakan pengalaman proyek sebelumnya. Nilai 0.6, jika pembangunan perangkat lunak sering menggunakan pengalaman proyek sebelumnya. Nilai 0.9, jika pembangunan perangkat lunak pasti menggunakan pengalaman proyek sebelumnya.
II-16
Pada tabel 2.3 memperlihatkan nilai respon pertanyaan matrik resiko yang diberikan kepada responden. Q1 = 0.70
Q21 = 0.50
Q41 = 0.57
Q61 = 0.40
Q2 = 0.70
Q22 = 0.90
Q42 = 0.85
Q62 = 0.55
Q3 = 0.50
Q23 = 0.30
Q43 = 0.65
Q63 = 0.55
Q4 = 0.75
Q24 = 1.00
Q44 = 0.65
Q64 = 0.40
Q5 = 0.85
Q25 = 0.60
Q45 = 0.50
Q65 = 0.45
Q6 = 0.80
Q26 = 0.70
Q46 = 0.80
Q66 = 0.45
Q7 = 0.70
Q27 = 0.50
Q47 = 0.70
Q67 = 0.30
Q8 = 0.70
Q28 = 0.90
Q48 = 0.55
Q68 = 0.45
Q9 = 0.50
Q29 = 0.30
Q49 = 0.60
Q69 = 0.40
Q10 = 0.90
Q30 = 0.50
Q50 = 0.60
Q70 = 0.30
Q11 = 0.30
Q31 = 0.40
Q51 = 0.70
Q71 = 0.50
Q12 = 1.00
Q32 = 0.30
Q52 = 0.80
Q72 = 0.50
Q13 = 0.60
Q33 = 0.70
Q53 = 0.50
Q73 = 0.40
Q14 = 0.70
Q34 = 0.50
Q54 = 0.70
Q74 = 0.40
Q15 = 0.50
Q35 = 0.20
Q55 = 0.65
Q75 = 0.40
Q16 = 0.90
Q36 = 0.40
Q56 = 0.40
Q76 = 0.40
Q17 = 0.30
Q37 = 0.40
Q57 = 0.50
Q77 = 0.80
Q18 = 1.00
Q38 = 0.40
Q58 = 0.45
Q78 = 0.90
Q19 = 0.60
Q39 = 0.90
Q59 = 0.40
Q79 = 0.70
Q20 = 0.70
Q40 = 0.70
Q60 = 0.55
Q80 = 0.70 Q81 = 0.75
Tabel 2.3 Hasil Respon Pertanyaan Matriks Resiko
Variabel Qn menunjukan pertanyaan (Q) dan nomor (n) dari matrik resiko, dimana n = 1,2,3 ....81. Bobot nilai pertanyaan diisi oleh responden sesuai dengan persetujuan dan pengalaman mereka masing-masing dalam membangun perangkat lunak.
II-17
Gambar 2.1 P(A) menunjukan total kesuksesan proyek perangkat lunak. P(A1), P(A2) dan P(A3) menjelaskan elemen resiko berupa teknologi, biaya dan penjadualan. P(A4) sampai P(A13) memperlihatkan 10 faktor resiko. P(B) sampai P(G) memperlihatkan tahapan life cycle, sedangkan P(H) sampai P(M) menjelaskan aktivitas dalam evaluasi resiko.
Gambar 2.1 Integrasi Model Manajemen Resiko (Sumber : Software Engineering Risk Management, Dale Walter Karolak)[2]
Gambar 2.2 Menjelaskan hubungan antara faktor resiko dengan proses pembangun dan produk perangkat lunak. P(N) menjelaskan kesuksesan proyek berdasarkan proses dan P(O) menjelaskan kemungkinan kesuksesan berdasarkan produk.
II-18
Gambar 2.2 Model Hubungan Faktor Resiko Dengan Proses Dan Produk (Sumber : Software Engineering Risk Management, Dale Walter Karolak)[2]
Untuk menerapkan model penyelesaian dari gambar 2.1 dan gambar 2.2, beberapa parameter dan persamaan harus dipertimbangkan. Dibawah ini beberapa persamaan yang digunakan untuk memecahkan masalah dari pohon kemungkinan[2]. 1. P(A) = [ ∑3n=1 P(An)]/3 asumsi bahwa setiap elemen resiko harus memiliki bobot nilai, jika bobot nilai setiap elemen berbeda, maka persamaan yang digunakan adalah P(A) = w1 P(A1) + w2 P(A2) + w3 P(A3) dimana wadalah angka positif dan w1 + w2 + w3 = 1. 2. P(A1) = [ ∑13n=4 wnP(An)] dimana w4 = 0.043, w5 = 0.043, w6 = 0.087, w7 = 0.087, w8 = 0.087, w9 = 0.13, w10 = 0.13, w11 = 0.13, w12 = 0.13, w13 = 0.13. Berdasarkan tabel 2.1, maka bobot 0.043 merupakan nilai terendah, 0.087 nilai sedang dan 0.13 untuk nilai tinggi. 3. P(A2) = [ ∑13n=4 wnP(An)] dimana w4 = 0.136, w5 = 0.136, w6 = 0.136, w7 = 0.136, w8 = 0.09, w9 = 0.09, w10 = 0.045, w11 = 0.045, w12 = 0.045, w13 = 0.136. Berdasarkan tabel 2.1, maka bobot 0.045 merupakan nilai terendah, 0.09 nilai sedang dan 0.136 untuk nilai tinggi. 4. P(A3) = [ ∑13n=4 wnP(An)] dimana w4 = 0.136, w5 = 0.136, w6 = 0.136, w7 = 0.136, w8 = 0.09, w9 = 0.09, w10 = 0.045, w11 = 0.045, w12 = 0.045, w13 = 0.136. Berdasarkan tabel 2.1, maka bobot 0.045 merupakan nilai terendah, 0.09 nilai sedang dan 0.136 untuk nilai tinggi.
II-19
5. P(A4) = [ ∑8n=1(On]/8 domana On adalah nilai matrik untuk nomor pertanyaan mengenai faktor resiko organisasi yang berjumlah 8 pertanyaan. Persamaan ini digunakan kembali untuk menyelesaikan matrik resiko P(A5) sampai P(A13) dengan mengubah nomor pertanyaan dari masing- masing faktor resiko. 6. P(B) ∑ (Q1, Q2, Q3, Q4, Q5, Q9, Q10, Q11, Q12, Q14, Q15, Q16, Q17, Q18, Q19, Q21, Q22, Q23, Q24, Q28, Q30, Q35, Q38, Q39, Q40, Q41, Q42, Q43, Q44, Q45, Q46, Q47, Q48, Q49, Q60, Q77, Q78, Q79, Q80, Q81)/40 7. P(C)= ∑ (Q1, Q2, Q3, Q4, Q5, Q6, Q7, Q8, Q13, Q14, Q15, Q18, Q19, Q20, Q21, Q22, Q24, Q25, Q26, Q28, Q30, Q35, Q38, Q39, Q40, Q41, Q42, Q43, Q44, Q51, Q52, Q54, Q56, Q60, Q76)/34 8. P(D)= ∑ (Q1, Q3, Q4, Q5, Q6, Q7, Q8, Q13, Q14, Q15, Q18, Q19, Q20, Q21, Q22, Q24, Q25, Q26, Q28, Q30, Q31, Q35, Q38, Q39, Q40, Q41, Q42, Q43, Q44, Q51, Q53, Q55, Q57, Q60, Q65, Q66, Q67, Q69)/38 9. P(E)= ∑ (Q1, Q3, Q4, Q5, Q6, Q7, Q8, Q13, Q14, Q15, Q18, Q19, Q20, Q21, Q22, Q24, Q25, Q26, Q28, Q30, Q35, Q37, Q38, Q39, Q40, Q41, Q42, Q43, Q44, Q45, Q51, Q58, Q60, Q61, Q65, Q66, Q67, Q68, Q69, Q70)/39 10. P(F)= ∑ (Q1, Q3, Q4, Q5, Q6, Q7, Q8, Q13, Q14, Q15, Q18, Q19, Q20, Q21, Q22, Q24, Q25, Q27, Q28, Q29, Q30, Q32, Q34, Q35, Q36, Q38, Q39, Q40, Q41, Q42, Q43, Q44, Q51, Q59, Q60, Q62, Q64, Q71, Q73, Q74, Q75, Q76)/42 11. P(G)= ∑ (Q1, Q3, Q4, Q5, Q6, Q7, Q8, Q13, Q14, Q15, Q18, Q19, Q20, Q21, Q22, Q24, Q25, Q28, Q30, Q35, Q36, Q38, Q39, Q40, Q41, Q42, Q43, Q44, Q50, Q51, Q60, Q63, Q72)/33 12. P(H) = [ ∑81n=1 Qn)]/81 dimana Qn adalah seluruh pertanyaan yang ada pada matrik resiko. 13. P(I) = ∑ (Q3, Q9, Q10, Q11, Q12, Q14, Q15, Q16, Q23, Q49, Q77)/12 14. P(J)= ∑ (Q1, Q2, Q3, Q7, Q8, Q10, Q11, Q12, Q13, Q14, Q15, Q20, Q21, Q22, Q25, Q29, Q31, Q32, Q33, Q34, Q35, Q36, Q52, Q53, Q55, Q56,
II-20
Q57, Q58, Q59, Q60, Q61, Q62, Q63, Q64, Q65, Q67, Q68, Q69, Q70, Q71, Q72, Q73, Q74, Q75, Q76, Q77)/46 15. P(K) = ∑ (Q1, Q3, Q4, Q6, Q7, Q8, Q10, Q11, Q12, Q13, Q16, Q17, Q18, Q19, Q20, Q21, Q22, Q23, Q24, Q26, Q27, Q28, Q29, Q30, Q48, Q49, Q52, Q54, Q56, Q57, Q58, Q59, Q61, Q62, Q72, Q73, Q74, Q75, Q75, Q76, Q77, Q78, Q79, Q80)/42 16. P(L) = ∑ (Q13, Q17, Q18, Q19, Q20, Q21, Q22)/7 17. P(M) = [ ∑81n=1 Qn)]/81 dimana Qn adalah seluruh pertanyaan yang ada pada matrik resiko. 18. P(N) = [ ∑13n=4 wn P(An)] dimana w4 = 0.125, w5 = 0.125, w6 = 0.125, w7 = 0.125, w8 = 0.125, w9 = 0.125, w10 = 0.04, w11 = 0.04, w12 = 0.04, w13 = 0.125. Bobot 0.04 merupakan faktor resiko yang berpengaruh minor terhadap proses dan 0.125 merupakan faktor resiko yang berpengaruh mayor terhadap proses. 19. P(O) = [ ∑13n=4 wn P(An)] dimana w4 = 0.045, w5 = 0.045, w6 = 0.045, w7 = 0.045, w8 = 0.14, w9 = 0.14, w10 = 0.14, w11 = 0.14, w12 = 0.14, w13 = 0.14. Bobot 0.045 merupakan faktor resiko yang berpengaruh minor terhadap produk dan 0.14 merupakan faktor resiko yang berpengaruh mayor terhadap produk.
2.2.4 Hasil Contoh Kasus Model SERIM yang terdapat pada tabel 2.4. memperlihatkan hasil penelitian dari permbangunan perangkat lunak akademik. P(A) menjelaskan kesuksesan pembangunan perangkat lunak secara keseluruhan. P(A1) sampai P(A3) menunjukan komponen elemen resiko. P(A4) sampai P(A13) menunjukan faktor resiko. P(B) sampai P(G) menjelaskan phase pembangunan lifecycle dan P(H) sampai P(M) menjelaskan aktivitas resiko. Sedangkan P(N) dan P(O) menunjukan resiko dari proses dan produk perangkat lunak. Berdasakan penelitian proyek perangkat lunak akademik memiliki nilai kemungkinan P(A) 0.65, dimana nilai tersebut
II-21
menyatakan bahwa proyek memiliki tingkat kesuksesan (keberhasilan) yang cukup baik. Untuk melihat kesuksesan suatu proyek, nilai P(A) terletak antara nilai kemungkinan 0 (paling buruk) sampai 1 (sukses). Tabel 2.4. juga memperlihatkan 3 (tiga) nilai kemungkinan terendah dari keberhasilan proyek sistem informasi akademik yaitu tool P(A8)=0.42, correctness (P11)=0.48 dan reability P(A12)= 0.41. Rendahnya nilai pada faktor resiko tool, correctness dan reability memungkinan pengambil keputusan untuk mengubah strategi untuk mengurangi atau menghindari resiko. misalnya proyek menerapkan tool yang dapat bekerja automatis untuk pengujian perangkat lunak, sehingga jadual yang ketat dalam penyelesaian proyek dapat diatasi. Nilai kemungkinan terbaik terdapat pada organization P(A4) dan personel P(A13) dengan nilai kemungkinan 0.71 dan 0.78, hal ini menerangkan bahwa unit UNITA center memiliki kemampuan sumber daya manusia dan pengalaman organisasi yang baik dalam membangun perangkat lunak akademik.
Tabel SERIM Penilaian Perangkat
Tabel SERIM Penilaian Perangkat
Lunak
Lunak (Lanjutan)
Probabilitas Resiko
Nilai
Probabilitas
Nilai
Resiko P (A)
0.65
P (B)
0.63
P (A1)
0.71
P (C)
0.67
P (A2)
0.66
P (D)
0.56
P (A3)
0.62
P (E)
0.64
P (A4)
0.71
P (F)
0.73
P (A5)
0.64
P (G)
0.68
P (A6)
0.70
P (H)
0.69
P (A7)
0.61
P (I)
0.72
P (A8)
0.42
P (J)
0.66
II-22
P (A9)
0.61
P (K)
0.72
P (A10)
0.60
P (L)
0.66
P (A11)
0.48
P (M)
0.68
P (A12)
0.41
P (N)
0.72
P (A13)
0.78
P (O)
0.69
Tabel 2.4 Tabel SERIM Penilaian Perangkat Lunak
Berdasarkan tabel penilaian di atas, terlihat model SERIM dapat melakukan penilaian dan prediksi dari seluruh aspek resiko pembangunan perangkat lunak dengan menyatukan seluruh phase pengembangan perangkat lunak, faktor resiko, elemen resiko, aktivitas resiko, proses dan produk. Model SERIM juga sangat membantu kita untuk memahami cara penggunaan model dalam manajemen resiko dengan menganalisis penilaian yang ada pada tabel 2.4.
2.3 Manajemen Perangkat Lunak Defenisi konseptual mengenai resiko [15] 1. Resiko berhubungan dengan kejadian di masa yang akan datang. 2. Resiko melibatkan perubahan (seperti. perubahan pikiran, pendapat, aksi, atau tempat) 3. Resiko melibatkan pilihan & ketidakpastian bahwa pilihan itu akan dilakukan.
Strategi Resiko Reaktif vs Proaktif a. Strategi reaktif memonitor proyek terhadap kemungkinan resiko. Sumber-sumber daya dikesampingkan, padahal seharusnya sumbersumber daya menjadi masalah yang sebenarnya/penting. b. Strategi proaktif dimulai sebelum kerja teknis diawali. Resiko potensial diidentifikasi, probabilitas & pengaruh proyek diperkirakan, dan diprioritaskan menurut kepentingan, kemudian membangun suatu
II-23
rencana untuk manajemen resiko. Sasaran utama adalah menghindari resiko.
Resiko Perangkat Lunak Karakteristik resiko : 1. Ketidakpastian 2. Kerugian Kategori resiko :
Resiko proyek
Resiko teknis
Resiko bisnis
a. Resiko proyek Resiko Proyek mengancam rencana proyek. Bila resiko proyek menjadi kenyataan maka ada kemungkinan jadwal proyek akan mengalami slip & biaya menjadi bertambah. Resiko proyek mengidenifikasi :
Biaya
Jadwal
Personil (staffing & organisasi)
Sumber daya
Pelanggan
Masalah persyaratan
b. Resiko teknis Resiko teknis mengancam kualitas & ketepatan waktu PL yang akan dihasilkan. Bila resiko teknis menjadi kenyataan maka implementasinya menjadi sangat sulit atau tidak mungkin. Resiko teknis mengidentifikasi :
Desain potensial
Ambiquitas
Implementasi
II-24
Spesifikasi
Interfacing
Ketidakpastian teknik
Verivikasi
Keusangan teknik
Masalah pemeliharaan
Teknologi yang leading edge
c. Resiko bisnis Resiko bisnis mengancam viabilitas PL yang akan dibangun. Resiko bisnis membahayakan proyek atau produk. 5 resiko bisnis utama : 1. Pembangunan produk atau sistem yang baik sebenarnya tidak pernah diinginkan oleh setiap orang (resiko pasar) 2. Pembangunan sebuah produk yang tidak sesuai dengan keseluruhan strategi bisnis bagi perusahaan (resiko strategi) 3. Pembangunan sebuah produk dimana sebuah bagian pemasaran tidak tahu bagaimana harus menjualnya. 4. Kehilangan dukungan manajemen senior sehubungan dengan perubahan pada fokus atau perubahan pada manusia (resiko manajemen) 5. Kehilangan hal-hal yang berhubungan dengan biaya atau komitmen personal (resiko biaya). Tahapan dalam manajemen resiko [15] 1. Identifikasi 2. Analisis 3. Prioritas 4. Mitigasi
II-25
Identifikasi Sebelum dapat mengelola sesuatu hal yang pertama adalah harus mengetahui terlebih dahulu. Demikian dengan manajemen resiko,diawali dengan mengenali resiko dan memprediksikan konsekuensinya.
Analisis Analisis
resiko
merupakan
tahap
kedua
yang
bertujuan
untuk
mengestimasi peluang terjadinya resiko dan memprediksi letak potensi resiko itu berada dengan menggunakan metode tertentu dengan persamaan-persamaan matematis. Dimana besar probabilitasnya direpresentasikan dalam bentuk angka.
Prioritas Prioritas merupakan tahap ketiga dalam manajemen resiko. Dimana pada tahap ini, seluruh variabel yang memiliki probabilitas tinggi akan terjadinya resiko, dianalisa berdasarkan dampat yang akan ditimbulkannya. Dengan menggunakan metode tertentu, dampak resiko diukur sesuai metode dan persamaan yang digunakan.
Mitigasi Tahap ini merupakan tahap terakhir dalam manajemen proyek, dimana probabilitas yang memiliki dampak besar terhadap proyek baik itu secara teknis, biaya dan waktu akan disediakan alternatif penanganan. Tahap mitigasi ada 4 a. Menghindari resiko b. Menyediakan solusi bagi resiko c. Menyerahkan resiko ke pihak lain d. Menerima resiko (tidak melakukan apapun terhadap resiko yang datang)
II-26
2.4 Pembangunan Sistem dengan Waterfall Model [3] Dalam pembangunan aplikasi ini digunakan model pengembangan waterfall. Inti dari metode waterfall adalah pengerjaan dari suatu sistem dilakukan secara berurutan atau secara linear[3]. Jadi jika langkah satu belum dikerjakan maka tidak akan bisa melakukan pengerjaan langkah 2, 3 dan seterusnya. Secara otomatis tahapan ke-3 akan bisa dilakukan jika tahap ke-1 dan ke-2 sudah dilakukan.
Gambar 2.3 Waterfall Model
Secara garis besar model waterfall mempunyai langkah-langkah sebagai berikut : 1. Requirements Definition Langkah ini merupakan analisa terhadap kebutuhan sistem. Pengumpulan data dalam tahap ini bisa melakukan sebuah penelitian, wawancara atau study literatur. Seorang sistem analis akan menggali informasi sebanyakbanyaknya dari user sehingga akan tercipta sebuah sistem komputer yang bisa melakukan tugas-tugas yang diinginkan oleh user tersebut. Tahapan ini akan menghasilkan dokumen user requirement atau bisa dikatakan sebagai data yang berhubungan dengan keinginan user dalam pembuatan sistem. Dokumen ini lah yang akan menjadi acuan sistem analis untuk menterjemahkan ke dalam bahasa pemprogram.
II-27
2. System and Software Design Proses desain akan menerjemahkan syarat kebutuhan ke sebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuat coding. Proses ini berfokus pada : struktur data, arsitektur perangkat lunak, representasi interface, dan detail (algoritma) prosedural. Tahapan ini akan menghasilkan dokumen yang disebut software requirement. Dokumen inilah yang akan digunakan proggrammer untuk melakukan aktivitas pembuatan sistemnya. 3. Implementation and Unit Testing Coding merupakan penerjemahan design dalam bahasa yang bisa dikenali oleh komputer. Dilakukan oleh programmer yang akan meterjemahkan transaksi yang diminta oleh user. Tahapan ini lah yang merupakan tahapan secara nyata dalam mengerjakan suatu sistem. Dalam artian penggunaan komputer akan dimaksimalkan dalam tahapan ini. Setelah pengkodean selesai maka akan dilakukan testing terhadap sistem yang telah dibuat tadi. Tujuan testing adalah menemukan kesalahan-kesalahan terhadap sistem tersebut dan kemudian bisa diperbaiki. 4. Integration and System Testing Tahapan ini bisa dikatakan final dalam pembuatan sebuah sistem. Setelah melakukan analisa, design dan pengkodean maka sistem yang sudah jadi akan digunakan oleh user. 5. Operation and Maintenance Perangkat lunak yang sudah disampaikan kepada pelanggan pasti akan mengalami perubahan. Perubahan tersebut bisa karena mengalami kesalahan karena perangkat lunak harus menyesuaikan dengan lingkungan (periperal atau sistem operasi baru) baru, atau karena pelanggan membutuhkan perkembangan fungsional. 2.5 Unified Modeling Language (UML)[4] UML adalah bahasa grafis untuk mendokumentasi, menspesifikasi, dan membangun sistem perangkat lunak. UML berorientasi objek, menerapkan banyak level abstraksi, tidak bergantung proses pengembangan, tidak bergantung
II-28
bahasa dan teknologi, pemaduan beberapa notasi di beragam metodologi, usaha bersama dari banyak pihak, didukung oleh kakas-kakas yang diintegrasikan lewat XML (XMI). Standar UML dikelola oleh OMG (Object Management Group)[4]. UML
adalah
bahasa
pemodelan
untuk
menspesifikasikan,
memvisualisasikan, membangun dan mendokumentasikan artifak-artifak dari sistem : 1. Di dalam system intensive process, metode diterapkan sebagai proses untuk menurunkan atau mengevolusikan sistem. 2. Sebagai bahasa, UML digunakan untuk komunikasi yaitu alat untuk menangkap pengetahuan (semantiks) mengenai satu subyek dan mengekspresikan pengetahuan (sintaks) yang memperdulikan subyek untuk maksud berkomunikasi. Subyek adalah sistem yang dibahas. 3. Sebagai bahasa pemodelan, UML fokus pada pemahaman subyek melalui formulasi model dari subyek (dan konteks yan terhubung). Model memuat pengetahuan pada subyek, dan aplikasi dari pengetahuan ini berkaitan dengan intelejensia. 4. Berkaitan dengan unifikasi. UML memadukan praktek rekayasa terbaik sistem informasi dan industri, meliputi beragam tipe sistem (perangkat lunak dan non perangkat lunak), domain (bisnis, perangkat lunak), dan proses siklus hidup. 5. Begitu diterapkan untuk menspesifikasi sistem, UML dapat digunakan untuk mengkomunikasi “apa” yang diperlukan dari sistem dan “bagaimana” sistem dapat direalisasikan. 6. Begitu diterapkan untuk memvisualisasikan sistem, UML dapat digunakan untuk menjelaskan sistem secara visual sebelum direalisasikan. 7. Begitu diterapkan untuk membangun sistem, UML dapat digunakan untuk memandu realisasi sistem serupa dengan “blueprint”. 8. Begitu diterapkan untuk mendokumentasikan sistem, UML dapat digunakan untuk menangkap pengetahuan mengenai sistem pada seluruh siklus hidup.
II-29
2.5.1
Tujuan UML Tujuan utama perancangan UML adalah : 1. Memberikan model yang siap pakai, bahasa pemodelan visual yang ekspresif untuk mengembangkan dan saling menukar model dengan mudah dan dimengerti secara umum. 2. Memberikan bahasa pemodelan yang bebas dari berbagai bahasa pemrograman dan proses rekayasa. 3. Menyatukan praktek-praktek terbaik yang terdapat dalam pemodelan. Konsep-konsep yang diterapkan di UML adalah satu model berisi informasi
mengenai sistem (atau domain), model-model berisi elemen-elemen model seperti kelas-kelas,
simpul-simpul,
paket-paket,
dan
sebagainya.
Satu
diagram
menunjukkan satu pandangan tertentu dari model.
2.5.2
Kegunaan Diagram Kegunaan diagram pada pemodelan adalah untuk formalisasi ekspresi
model objek secara koheren, presisi dan mudah dirumuskan. Pemodelan berorientasi objek memerlukan kakas untuk mengekspresikan model. UML (Unified
Modeling
Language)
menyediakan
sejumlah
diagram
untuk
mengekspresikan pemodelan berorientasi objek yang dilakukan. UML adalah bahasa untuk menspesifikasikan, memvisualisasikan, dan mendokumentasi artifak-artifak sistem perangkat lunak. UML merupakan sistem notasi (termasuk semantiks untuk notasi itu) yang membantu pemodelan sistem menggunakan konsep berorientasi objek.
2.5.3
Diagram dan Teknik Pemodelan Diagram mengemukakan banyak hal, penggunaan notasi yang terdefinisi
baik dan ekspresif adalah penting pada proses pengembangan perangkat lunak, yaitu : 1. Notasi standar memungkinkan pengembang mendeskripsikan skenario atau rumusan arsitektur dan kmudian mengkomunikasikan secara tidak ambigu.
II-30
2. Notasi yang bagus membebaskan otak untuk berkonsentrasi pada masalahmasalah yang lebih lanjut. 3. Notasi yang baik memungkinkan mengeliminasi keperluan pemeriksaan konsistensi dan kebenaran keputusan-keputusan dengan menggunakan tool terotomatisasi.
Diagram Struktur Diagram ini untuk memvisualisasi, menspesifikasikan, membangun dan mendokumentasikan aspek statik dari sistem. Diagram struktur di UML terdiri dari : 1. Diagram kelas (Class diagram) 2. Diagram objek (Object diagram) 3. Diagram komponen (Component diagram) 4. Diagram deployment (Deployment diagram)
Diagram perilaku Diagram ini untuk memvisualisasi, menspesifikasikan, membangun dan mendokumentasikan aspek dinamis dari sistem. Diagram perilaku di UML terdiri dari : 1. Diagram use-case (Use case diagram) 2. Diagram sekuen (Sequence diagram) 3. Diagram kolaborasi (Collaboration diagram) 4. Diagram statechart (Statechart diagram) 5. Diagram aktivitas (Activity diagram) Diagram kelas (Class diagram) Diagram ini menunjukan sekumpulan kelas, interface dan kolaborasi dan keterhubungannya. Diagram kelas ditujukan untuk pandangan statistik terhadap sistem.
II-31
frmpendaftaran
frmlogin
menu utama
Gambar 2.4 Class Diagram
Diagram objek (Object Diagram) Diagram ini menunjukan sekumpulan objek dan keterhubungannya. Diagram ini menunjukan potongan statik dari instan-instan yang ada di diagram kelas. Diagram ini untuk memperlihatkan satu prototipe atau kasus tertentu yang mungkin terjadi. Diagram objek menyediakan notasi grafis formal guna memodelkan objek, kelas, dan saling keterhubungan. Diagram objek berguna untuk abstract modeling dan perancangan program-program sesungguhnya. Pada pendekatan ini, bentukan dasar dari sistem perangkat lunak adalah objek atau kelas. Kelas adalah deskripsi dari objek-objek yang common. Setiap objek mempunyai indentitas, state dan perilaku.
Diagram use-case (Use case Diagram) Diagram ini menunjukan sekumpulan kasus fungsional dan aktor (jenis kelas khusus) dan keterhubungannya.
mencatat
Admin
Login
Gambar 2.5 Use Case Diagram Diagram sekuen (Sequence Diagram) Diagram ini menunjukan interaksi yang terjadi antar objek. Diagram ini merupakan pandangan dinamis terhadap sistem. Diagram ini menekankan pada basis keberurutan waktu dari pesan-pesan yang terjadi.
II-32
Form Menu_Utam a
Admin
Form Kelola_User
Pilih form kelola user Tampil form kelola user
Gambar 2.6 Sequence Diagram Diagram kolaborasi (Colaboration Diagram) Diagram ini juga merupakan diagram interaksi. Diagram ini menekankan pada organisasi srtuktur dari objek-objek yang mengirim dan menerima pesan. 1:
Form Menu_Utam a : Form Us er
Admin : Adm in
2:
Form Kelola_Us er : Form Us er
Gambar 2.7 Collaboration Diagram
Diagram statechart (Statechart Diagram) Diagram ini adalah state-machine diagram,berisi state,transisi, kejadian dan aktivitas. Statechart merupakan pandangan dinamis dari sistem. Diagram ini penting dalam memodelkan perilaku antarmuka, kelas, kolaborasi dan menekankan pada urutan kejadian. Penting untuk sistem reaktif yang dipicu kejadian di dunia nyata. menunggu username & password 2.1
username atau password salah
1.2
Masukkan username & password
1.1
cancel login
3 cek username & password
username & password benar
Masuk ke menu utama
Cancel 2.2
Gambar 2.8 Statechart Diagram Diagram aktivitas (Activity diagram) Diagram ini untuk menunjukan aliran aktivitas di sistem. Diagram ini adalah pandangan dinamis terhadap sistem. Diagram ini penting untuk
II-33
memodelkan fungsi sistem dan menekankan pada aliran kendali diantara objekobjek.
start meminta info
memberi info
daftar cek pendaftaran
end
Gambar 2.9 Activity Diagram
Diagram komponen (Component diagram) Diagram ini menunjukan organisasi dan kebergantungan diantara sekumpulan komponen. Diagram ini merupakan pandangan statik terhadap implementasi sistem. <<standard EXE>> SPP
<
> userservices
Gambar 2.10 Component Diagram
Diagram deployment (Deployment diagram) Diagram ini menunjukan konfigurasi pemrosesan saat jalan dan komponen-komponen yang terdapat didalamnya. Diagram ini merupakan pandangan statik dari arsitektur. NewDevi ce
NewPro cessor
NewPro cessor2
NewPro cessor3
Gambar 2.11 Deployment Diagram Pilihan model dan diagram yang digunakan dipengaruhi oleh bagaimana persoalan ditangani dan bagaimana solusi dibentuk. Abstraksi, fokus pada yang relevan sambil mengabaikan rincian-rincian yang tidak relevan merupakan
II-34
kuncinya. Karena itu, setiap sistem kompleks perlu didekati melalui sekumpulan pandangan model yang kompleks. Setiap model diekspresikan pada level-level berbeda. Model-model yang terbaik dapat dikoneksikan ke kenyataan.
