BAB II LANDASAN TEORI
|
|
- Widya Yuliana Cahyadi
- 7 tahun lalu
- Tontonan:
Transkripsi
1 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 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
2 II 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. Komponenkomponen 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.
3 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 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.
4 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 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.
5 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 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 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)
6 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 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.
7 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 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.
8 II 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 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]
9 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?
10 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?
11 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?
12 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?
13 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?
14 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?
15 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 Tidak Pernah Jarang Kadang- Kadang Sering 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.
16 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, Bobot nilai pertanyaan diisi oleh responden sesuai dengan persetujuan dan pengalaman mereka masing-masing dalam membangun perangkat lunak.
17 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.
18 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) = [ 3 n=1 P(A n )]/3 asumsi bahwa setiap elemen resiko harus memiliki bobot nilai, jika bobot nilai setiap elemen berbeda, maka persamaan yang digunakan adalah P(A) = w 1 P(A 1 ) + w 2 P(A 2 ) + w 3 P(A 3 ) dimana wadalah angka positif dan w 1 + w 2 + w 3 = P(A 1 ) = [ 13 n=4 w n P(A n )] dimana w 4 = 0.043, w 5 = 0.043, w 6 = 0.087, w 7 = 0.087, w 8 = 0.087, w 9 = 0.13, w 10 = 0.13, w 11 = 0.13, w 12 = 0.13, w 13 = Berdasarkan tabel 2.1, maka bobot merupakan nilai terendah, nilai sedang dan 0.13 untuk nilai tinggi. 3. P(A 2 ) = [ 13 n=4 w n P(A n )] dimana w 4 = 0.136, w 5 = 0.136, w 6 = 0.136, w 7 = 0.136, w 8 = 0.09, w 9 = 0.09, w 10 = 0.045, w 11 = 0.045, w 12 = 0.045, w 13 = Berdasarkan tabel 2.1, maka bobot merupakan nilai terendah, 0.09 nilai sedang dan untuk nilai tinggi. 4. P(A 3 ) = [ 13 n=4 w n P(A n )] dimana w 4 = 0.136, w 5 = 0.136, w 6 = 0.136, w 7 = 0.136, w 8 = 0.09, w 9 = 0.09, w 10 = 0.045, w 11 = 0.045, w 12 = 0.045, w 13 = Berdasarkan tabel 2.1, maka bobot merupakan nilai terendah, 0.09 nilai sedang dan untuk nilai tinggi.
19 II P(A 4 ) = [ 8 n=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(A 5 ) sampai P(A 13 ) 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)/ 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)/ 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)/ P(H) = [ 81 n=1 Q n )]/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)/ 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,
20 II-20 Q57, Q58, Q59, Q60, Q61, Q62, Q63, Q64, Q65, Q67, Q68, Q69, Q70, Q71, Q72, Q73, Q74, Q75, Q76, Q77)/ 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)/ P(L) = (Q13, Q17, Q18, Q19, Q20, Q21, Q22)/7 17. P(M) = [ 81 n=1 Q n )]/81 dimana Qn adalah seluruh pertanyaan yang ada pada matrik resiko. 18. P(N) = [ 13 n=4 w n P(A n) ] dimana w 4 = 0.125, w 5 = 0.125, w 6 = 0.125, w 7 = 0.125, w 8 = 0.125, w 9 = 0.125, w 10 = 0.04, w 11 = 0.04, w 12 = 0.04, w 13 = Bobot 0.04 merupakan faktor resiko yang berpengaruh minor terhadap proses dan merupakan faktor resiko yang berpengaruh mayor terhadap proses. 19. P(O) = [ 13 n=4 w n P(A n) ] dimana w 4 = 0.045, w 5 = 0.045, w 6 = 0.045, w 7 = 0.045, w 8 = 0.14, w 9 = 0.14, w 10 = 0.14, w 11 = 0.14, w 12 = 0.14, w 13 = Bobot merupakan faktor resiko yang berpengaruh minor terhadap produk dan 0.14 merupakan faktor resiko yang berpengaruh mayor terhadap produk 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
21 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)= 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 Lunak Tabel SERIM Penilaian Perangkat Lunak (Lanjutan) Probabilitas Resiko Nilai Probabilitas Nilai Resiko P (A) 0.65 P (B) 0.63 P (A 1 ) 0.71 P (C) 0.67 P (A 2 ) 0.66 P (D) 0.56 P (A 3 ) 0.62 P (E) 0.64 P (A 4 ) 0.71 P (F) 0.73 P (A 5 ) 0.64 P (G) 0.68 P (A 6 ) 0.70 P (H) 0.69 P (A 7 ) 0.61 P (I) 0.72 P (A 8 ) 0.42 P (J) 0.66
22 II-22 P (A 9 ) 0.61 P (K) 0.72 P (A 10 ) 0.60 P (L) 0.66 P (A 11 ) 0.48 P (M) 0.68 P (A 12 ) 0.41 P (N) 0.72 P (A 13 ) 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 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
23 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
24 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
25 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)
26 II 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.
27 II 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
28 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.
29 II 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 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 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.
30 II 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.
31 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.
32 II-32 Admin Form Menu_Utama 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: Admin : Admin Form Menu_Utama : Form User 2: Form Kelola_User : Form User 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 cancel login 1.1 username atau password salah Masukkan username & password 1.2 cek username & password 3 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
33 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 <<COM>> 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
34 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.
BAB II TINJAUAN PUSTAKA
BAB II TINJAUAN PUSTAKA 2.1. Penelitian Terdahulu Penelitian ini dilakukan berdasarkan penelitian-penelitian terdahulu yang pernah dilakukan dan digunakan sebagai bahan kajian. Hasil-hasil penelitian yang
Lebih terperinciKeywords: Software Developer, Risk Management, Just-In-Time, SERIM,
Analisis Manajemen Resiko Perangkat Lunak dengan Pendekatan Just-in-Time: Studi Kasus Optimasi Organisasi dan Dokumentasi pada Organisasi Pengembang Perangkat Lunak (Thomas Suselo) Analisis Manajemen Resiko
Lebih terperinciSISTEM INFORMASI. Konsep Dasar Sistem
SISTEM INFORMASI Konsep Dasar Sistem Sistem: Suatu jaringan kerja dari prosedur-prosedur yang saling berhubungan, berkumpul bersama-sama untuk melakukan suatu kegiatan atau untuk menyelesaikan suatu sasaran
Lebih terperinciANALISIS PENILAIAN RISIKO PROYEK PEMBANGUNAN PERANGKAT LUNAK DENGAN MODEL PERANGKAT LUNAK JUST IN TIME DI NUSANTARA TECHNOLOGY SOLUTION
ANALISIS PENILAIAN RISIKO PROYEK PEMBANGUNAN PERANGKAT LUNAK DENGAN MODEL PERANGKAT LUNAK JUST IN TIME DI NUSANTARA TECHNOLOGY SOLUTION HERDINA SEPTIANI 1.05.11.279 Program Studi Sistem Informasi Fakultas
Lebih terperinciPerangkat Lunak JIT (Just In Time) untuk Memprediksi Resiko Proyek Perangkat Lunak
Perangkat Lunak JIT (Just In Time) untuk Memprediksi Resiko Proyek Perangkat Lunak Yasmi Afrizal 1*, Agus Harjoko 2 1 Universitas Komputer Indonesia, Bandung 2 Universitas Gadjah Mada, Yogyakarta email:
Lebih terperinciBAB I PENDAHULUAN I-1
BAB I PENDAHULUAN Pada bagian ini akan dijelaskan tentang pendahuluan dalam penyusunan Laporan Penelitian. Pendahuluan meliputi latar belakang masalah, rumusan masalah, maksud dan tujuan penelitian, batasan
Lebih terperinciBAB II LANDASAN TEORI. yang digunakan dalam penyelesaian Tugas Akhir ini, yaitu System Development
BAB II LANDASAN TEORI Dalam penyusunan tugas akhir ini dibutuhkan beberapa landasan teori sebagai acuan dalam penyusunannya. Landasan teori yang dibutuhkan antara lain teori tentang Rancang Bangun, teori
Lebih terperinciPENGANTAR RUP & UML. Pertemuan 2
PENGANTAR RUP & UML Pertemuan 2 PENGANTAR RUP Rational Unified Process (RUP) atau dikenal juga dengan proses iteratif dan incremental merupakan sebuah pengembangan perangkat lunak yang dilakukan secara
Lebih terperinciSURAT PERNYATAAN ABSTRACT ABSTRAK KATA PENGANTAR
DAFTAR ISI LEMBAR PENGESAHAN... i SURAT PERNYATAAN... ii ABSTRACT... iii ABSTRAK... iv KATA PENGANTAR... v DAFTAR ISI... vii DAFTAR TABEL... x DAFTAR GAMBAR... xi DAFTAR SIMBOL... xiii DAFTAR LAMPIRAN...
Lebih terperinciManajemen Risiko Proyek Perangkat Lunak Menggunakan Pendekatan Just In Time Pada Perusahaan Teknologi Informasi
Prayogo, Manajemen Risiko Proyek Perangkat Lunak Menggunakan Pendekatan Just In Time Pada Perusahaan Teknologi Informasi 119 Manajemen Risiko Proyek Perangkat Lunak Menggunakan Pendekatan Just In Time
Lebih terperinciKONSEP SISTEM INFORMASI
KONSEP SISTEM INFORMASI PENDAHULUAN Tulisan ini akan menjelaskan konsep dasar dari sistem informasi. Sebelum membahas suatu sistem lebih baik jika mengetahui dulu apa sistem itu, pada bagian berikutnya
Lebih terperincihttp://www.brigidaarie.com INPUT [ Source ] [ Requirements ] Process ACTIVITIES (TASKS), CONSTRAINTS, RESOURCES PROCEDURES TOOLS & TECHNIQUES OUTPUT [ Results ] [ Product ] [ Set of Goals ] [ Standards
Lebih terperinciBAB I PENDAHULUAN. 1.1.Latar Belakang
BAB I PENDAHULUAN 1.1.Latar Belakang PT Bank Mandiri Cabang Jakarta Mal Puri Indah, merupakan Perusahaan Perseroan (Persero) yang bergerak di bidang jasa perbankan dengan misi umum untuk memberikan pelayanan
Lebih terperinciBAB II LANDASAN TEORI
BAB II LANDASAN TEORI 2.1. Konsep Dasar Sistem Dalam mendefinisikan sistem terdapat dua kelompok pendekatan sistem, yaitu sistem yang lebih menekankan pada prosedur dan elemennya. Prosedur didefinisikan
Lebih terperinciBAB III METODOLOGI PENELITIAN
BAB III METODOLOGI PENELITIAN 3.1. Desain Penelitian Desain penelitian merupakan tahapan atau gambaran yang akan dilakukan dalam melakukan penelitian. Tahapan-tahapan yang dilakukan dalam penelitian ini
Lebih terperinciBAB II LANDASAN TEORI
4 BAB II LANDASAN TEORI 2.1 Definisi Sistem Sistem adalah sekumpulan unsur / elemen yang saling berkaitan dan saling mempengaruhi dalam melakukan kegiatan bersama untuk mencapai suatu tujuan. Contoh :
Lebih terperinciMENGELOLA RISIKO PROYEK PENGEMBANGAN SOFTWARE
Jurnal Teknik dan Ilmu Komputer MENGELOLA RISIKO PROYEK PENGEMBANGAN SOFTWARE (Managing the Risks of the Software Development Project) Endi Putro*, Maria Ariesta Fakultas Teknik dan Ilmu Komputer Jurusan
Lebih terperinciRational Unified Process (RUP)
Universitas IGM HD-UIGM-FK-01 Fakultas : Ilmu Komputer Pertemuan ke : 8 Program Studi : Teknik Informatika Handout ke : 1 Kode Matakuliah : Jumlah Halaman : 25 Matakuliah : Rekayasa Perangkat Lunak Mulai
Lebih terperinciBAB V KESIMPULAN. Pada bab ini akan menyatukan hasil temuan dalam penelitian ini. Pada bagian
BAB V KESIMPULAN 5.1. Pendahuluan Pada bab ini akan menyatukan hasil temuan dalam penelitian ini. Pada bagian pertama, hasil kesimpulan dari penelitian ini. Pada bagian kedua menggambarkan keterbatasan
Lebih terperinciABSTRAK. Kata kunci: diagram kelas, xml, java, kode sumber, sinkronisasi. v Universitas Kristen Maranatha
ABSTRAK Salah satu bidang kajian dalam bidang teknologi informasi adalah rekayasa perangkat lunak. Dalam rekayasa perangkat lunak, terdapat konsep yang mendasari berbagai jenis metodologi pengembangan
Lebih terperinciRANCANGAN APLIKASI LATIHAN BELAJAR TENSES DENGAN METODE OBJECT ORIENTED DESIGN
Seminar Nasional Teknologi Informasi 2015 RANCANGAN APLIKASI LATIHAN BELAJAR TENSES DENGAN METODE OBJECT ORIENTED DESIGN Qoriani Widayati, Irman Effendy 1) Sistem Informasi Akuntansi, Ilmu Komputer Jl.
Lebih terperinciABSTRAK. Kata kunci: pengelolaan, proyek, manajemen, resiko
ABSTRAK WIT merupakan instansi yang bergerak dalam bidang IT, khususnya dalam pembuatan software, aplikasi, web design & E-Commerce, Multimedia, Hardware dan Networking. Dalam memantau proyek-proyek yang
Lebih terperinciBAB 1 PENDAHULUAN. 1.1 Latar Belakang
BAB 1 PENDAHULUAN 1.1 Latar Belakang Perkembangan perusahaan di Indonesia dari tahun ke tahun semakin meningkat.khusus untuk perkembangan industri di Jawa Barat meliputi perkembangan industri kecil, industri
Lebih terperinciBAB III METODE PENELITIAN
BAB III METODE PENELITIAN 3.1 Alat dan Bahan 3.1.1 Alat Dalam penelitian ini, alat yang di gunakan adalah sebagai berikut: 1. Perangkat Keras (Hardware) a) Personal Computer (PC)/Laptop 32/64 bit architecture
Lebih terperinciBAB III METODE PENELITIAN. Dalam penelitian ini, alat yang di gunakan adalah sebagai berikut: 1. Perangkat Keras (Hardware)
BAB III METODE PENELITIAN 3.1 Alat dan Bahan 3.1.1 Alat Dalam penelitian ini dibutuhkan beberapa alat dan bahan sebagai penunjang keberhasilan penelitian. Alat dan bahan tersebut adalah sebagai berikut:
Lebih terperinciMANAJEMEN RESIKO. Aprilia Sulistyohati, S.Kom. Jurusan Teknik Informatika Universitas Islam Indonesia. Your Logo
MANAJEMEN RESIKO Aprilia Sulistyohati, S.Kom Jurusan Teknik Informatika Universitas Islam Indonesia Your Logo RESIKO Menurut Robert Charette (Software Engineering Risk Analysis and Management) 1. Resiko
Lebih terperinciUniversitas Gadjah Mada
A. Pengertian Sistem Secara umum sistem dapat diartikan sebagai sekumpulan objek, ide, berikut sating keterhubungannya (inter-relasi) dalam mencapai tujuan atau sasaran bersama. Kemudian, istilah subsistem
Lebih terperinciBAB I PENDAHULUAN. 1.1 Latar Belakang
BAB I 1.1 Latar Belakang PENDAHULUAN Teknologi Informasi adalah suatu teknologi yang digunakan untuk mengolah data, termasuk memproses, mendapatkan, menyusun, menyimpan dan memanipulasi data dalam berbagai
Lebih terperinciDAFTAR ISI... LEMBAR JUDUL LEMBAR PENGESAHAN... SURAT PERNYATAAN... ABSTRAK... ABSTRACT... KATA PENGANTAR... DAFTAR TABEL... DAFTAR GAMBAR...
DAFTAR ISI LEMBAR JUDUL LEMBAR PENGESAHAN... SURAT PERNYATAAN... ABSTRAK... ABSTRACT... KATA PENGANTAR... DAFTAR ISI... DAFTAR TABEL... DAFTAR GAMBAR... i iii iv v vi viii xiii xv BAB I BAB II PENDAHULUAN
Lebih terperinciBAB II LANDASAN TEORI
BAB II LANDASAN TEORI 2.1. Pengertian Sistem Menurut Azhar Susanto dalam bukunya Sistem Informasi Management ( hal.18 bag.1 konsep dasar SIM ). Bahwa sistem adalah kumpulan dari subsistem/ komponen/ bagian
Lebih terperinciPERANCANGAN APLIKASI ESTIMASI RESIKO PENGEMBANGAN SOFTWARE DENGAN METODE SERIM
PERANCANGAN APLIKASI ESTIMASI RESIKO PENGEMBANGAN SOFTWARE DENGAN METODE SERIM Falahah 1*, Daniel Silaban 2 *1,2 Program Studi Teknik Informatika, Universitas Widyatama Jl. Cikutra no. 204A Bandung 40125
Lebih terperinciBAB IV ANALISIS DAN PERANCANGAN SISTEM
BAB IV ANALISIS DAN PERANCANGAN SISTEM 4.1 Analisis Sistem yang Sedang Berjalan Tahap yang perlu dilakukan sebelum mengembangkan suatu sistem ialah menganalisis sistem yang sedang berjalan kemudian mencari
Lebih terperinciBAB II LANDASAN TEORI
3 BAB II LANDASAN TEORI 2.1. Pengertian Sistem Menurut Jogiyanto system dapat di definisikan sebagai suatu kesatuan yang terdiri dari dua atau lebih komponen / subsistem yang berinteraksi untuk mencapai
Lebih terperinciPENGERTIAN SISTEM DAN ANALISIS SISTEM
PENGERTIAN SISTEM DAN ANALISIS SISTEM A. MATERI 1. DEFINISI SISTEM Sistem adalah sekumpulan unsur / elemen yang saling berkaitan dan saling mempengaruhi dalam melakukan kegiatan bersama untuk mencapai
Lebih terperinciBAB II LANDASAN TEORI. Sistem adalah suatu jaringan kerja dari prosedur-prosedur yang saling
6 BAB II LANDASAN TEORI 2.1 Sistem Sistem adalah suatu jaringan kerja dari prosedur-prosedur yang saling berhubungan, berkumpul bersama-sama untuk melakukan suatu kegiatan atau untuk menyelesaikan suatu
Lebih terperinciBAB III. Metode Penelitian
BAB III Metode Penelitian 3.1 Desain Penelitian Dalam penelitian ini penulis menggunakan metode penelitian deskriptif dan tindakan(actionresearch). Menurut Prof. Dr. Suharsimi Arikunto (2005:234) : Penelitian
Lebih terperinciBAB 2 LANDASAN TEORI. Teori-teori yang menjadi dasar penulisan adalah sebagai berikut :
BAB 2 LANDASAN TEORI 2.1 Teori-teori Dasar/Umum Teori-teori yang menjadi dasar penulisan adalah sebagai berikut : 2.1.1 Sistem Pengertian sistem menurut Williams dan Sawyer (2005, p457) adalah sekumpulan
Lebih terperinciTeknik Informatika S1
Software Process(2) Teknik Informatika S1 Rekayasa Perangkat Lunak 1. Linear Sequential Model 1. Waterfall Model 2. V Model 3. RAD Model 2. Prototyping Model 3. Evolutionary Model 1. Incremental Model
Lebih terperinciBAB II LANDASAN TEORI
BAB II LANDASAN TEORI 2.1 Konsep Dasar Sistem Dalam membangun sebuah system informasi diperlukan suatu pemahaman mengenai system itu sendiri sehingga tujuan dari pembangunan system informasi dapat tercapai.
Lebih terperinciSoftware Proses. Model Proses Perangkat Lunak. Pengembangan Perangkat Lunak. Framework activities 3/20/2018. System Development Life Cycle (SDLC)
System Development Life Cycle (SDLC) Software Proses Planning Implementation Analysis Design Pengembangan Perangkat Lunak Sebuah Lapisan Teknologi Model Proses Perangkat Lunak 1. Linear Sequential Model
Lebih terperinciBAB I PENDAHULUAN. hal proses pengolahan data, baik itu data siswa, guru, administrasi sekolah maupun data
BAB I PENDAHULUAN 1.1. Latar Belakang Dalam dunia pendidikan, teknologi informasi sangat banyak membantu seperti dalam hal proses pengolahan data, baik itu data siswa, guru, administrasi sekolah maupun
Lebih terperinciRatna Wardani. Department of Electronic Engineering Yogyakarta State University
Ratna Wardani Department of Electronic Engineering Yogyakarta State University S/W Process Model Tahapan S/W Process Model Proses S/W Materi Model Waterfall Model Prototype Model Rapid Application Development
Lebih terperinciPENGENALAN. Perancangan Perangkat Lunak. (Software Engineering) Bertalya Program Pascasarjana Univesitas Gunadarma
PENGENALAN Perancangan Perangkat Lunak (Software Engineering) Bertalya Program Pascasarjana Univesitas Gunadarma Perangkat Lunak (Software) Merupakan program aplikasi berikut dengan dokumentasi dan data
Lebih terperinciBAB I PENDAHULUAN. dalam suatu perusahaan, karena persediaan akan dijual secara terus menerus untuk
BAB I PENDAHULUAN I.1. Latar Belakang Persediaan Barang merupakan komponen utama yang sangat penting dalam suatu perusahaan, karena persediaan akan dijual secara terus menerus untuk kelangsungan hidup
Lebih terperinciSystem Development Life Cycle (SDLC)
System Development Life Cycle (SDLC) SI-215 Analisa & Desain Sistem Informasi I Rosa Ariani Sukamto Permasalahan Perangkat Lunak Software used, but criticized or dropped 19% Software delivered and used
Lebih terperinciKebutuhan dan Spesifikasi Perangkat Lunak
Kebutuhan dan Spesifikasi Perangkat Lunak Disusun oleh : Rina Noviana 1 LINGKUP PEMBAHASAN Pengumpulan Kebutuhan Perangkat Lunak - Mengumpulkan Data mengenai analisa sistem dan masalah nya Teknik Pemodelan
Lebih terperinciABSTRAK OTOMATISASI SISTEM MANAJEMEN DAN INVENTORY VOUCHER ELEKTRONIK MKIOS CV. AKAR DAYA MANDIRI. Oleh IRVAN RAMDHANI HIDAYAT
ABSTRAK OTOMATISASI SISTEM MANAJEMEN DAN INVENTORY VOUCHER ELEKTRONIK MKIOS CV. AKAR DAYA MANDIRI Oleh IRVAN RAMDHANI HIDAYAT 10104359 Pada proses perkembangannya pola sistem manajemen perusahaan CV. Akar
Lebih terperinciA. Tujuan dan Ruang Lingkup Proyek Perancangan Rekayasa Perangkat Lunak
A. Tujuan dan Ruang Lingkup Proyek Perancangan Rekayasa Perangkat Lunak Secara umum tujuan RPL tidak berbeda dengan bidang rekayasa yang lain. Bidang rekayasa akan selalu berusaha menghasilkan output yang
Lebih terperinciSIKLUS REKAYASA PERANGKAT LUNAK (SDLC)
SIKLUS REKAYASA PERANGKAT LUNAK (SDLC) 1. Pengertian DLC atau Software Development Life Cycle adalah proses mengembangkan atau mengubah suatu sistem perangkat lunak dengan menggunakan model-model dan metodologi
Lebih terperinciMEMAHAMI PENGGUNAAN UML
MEMAHAMI PENGGUNAAN UML Reza Kurniawan Reza.kurniawan@raharja.info Abstrak Saat ini sebagian besar para perancang sistem informasi dalam menggambarkan informasi dengan memanfaatkan UML diagram dengan tujuan
Lebih terperinciFASE PENGEMBANGAN. MPSI sesi 7 & 8
FASE PENGEMBANGAN MPSI sesi 7 & 8 Fase Pengembangan Pelaksanaan pekerjaan pengembangan ini pada dasarnya adalah membangun sistem informasi dengan deliverables berupa software dan bagianbagian pendukungnya,
Lebih terperinciReview Rekayasa Perangkat Lunak. Nisa ul Hafidhoh
Review Rekayasa Perangkat Lunak Nisa ul Hafidhoh nisa@dsn.dinus.ac.id Software Process Sekumpulan aktivitas, aksi dan tugas yang dilakukan untuk mengembangkan PL Aktivitas untuk mencapai tujuan umum (komunikasi
Lebih terperinciBAB II. Landasan Teori. [Jog98] mendefinisikan pengembangan system (System Development)
BAB II Landasan Teori 2.1. Pengembangan Sistem [Jog98] mendefinisikan pengembangan system (System Development) dapat berarti menyusun suatu system yang baru untuk menggantikan system yang lama secara keseluruhan
Lebih terperinciBAB I PENDAHULUAN. laporan keuangan yang cepat dan akurat. Seorang akuntan memiliki tugas untuk
BAB I PENDAHULUAN I.1. Latar Belakang Dalam dunia usaha kita mengenal perusahaan jasa dan perusahaan dagang. Perusahaan jasa adalah perusahaan yang bergerak di bidang jasa, sedangkan perusahaan dagang
Lebih terperinciBAB III LANDASAN TEORI
BAB III LANDASAN TEORI 3.1 Sistem Sistem menurut Gordon B. Davis dalam bukunya menyatakan sistem bisa berupa abstrak atau fisis. Sistem yang abstrak adalah susunan yang teratur dari gagasan gagasan atau
Lebih terperinciBAB III METODOLOGI PENELITIAN
BAB III METODOLOGI PENELITIAN 3.1 Umum Pada bab ini akan dijelaskan mengenai pembuatan Rancang Bangun Aplikasi Perencanaan Stok Barang dengan Menggunakan Teori Trafik dari tahap awal perancangan sampai
Lebih terperinciBAB IV ANALISIS DAN PERANCANGAN SISTEM. mampu memperkirakan dan merincikan seluruh dokumen ataupun prosedur yang
BAB IV ANALISIS DAN PERANCANGAN SISTEM 4.1 Analisis Sistem Yang Berjalan Analisis terhadap sistem yang berjalan dimaksudkan untuk mempelajari terhadap suatu sistem yang sedang dijalanakan oleh suatu organisasi,
Lebih terperinciBAB IV ANALISIS DAN PERANCANGAN SISTEM. hasil analisis ini digambarkan dan didokumentasiakan dengan metodologi
BAB IV ANALISIS DAN PERANCANGAN SISTEM 4.1. Analisis Sistem yang Sedang Berjalan Kegiatan analisis sistem yang berjalan dilakukan dengan analisis yang berorientasi pada objek-objek yang diperlukan oleh
Lebih terperinciSystems Development Life Cycle (SDLC)
Systems Development Life Cycle (SDLC) OPINI 28 September 2010 14:04 Dibaca: 3263 Komentar: 2 0 SDLC (Systems Development Life Cycle) dalam rekayasa sistem dan rekayasa perangkat lunak adalah proses pembuatan
Lebih terperinciBAB IV ANALISA DAN PERANCANGAN
BAB IV ANALISA DAN PERANCANGAN 4.1 Analisisa Sistem Web Service Push and Pull Sistem Web Service Push and Pull ini akan dibangun dengan menggunakan Analisis dan Desain berorientasi objek. Analisis dan
Lebih terperinciBAB II LANDASAN TEORI. pendekatan komponen.dengan pendekatan prosedur, sistem dapat didefinisikan
6 BAB II LANDASAN TEORI 2.1. Konsep Dasar Sistem Sistem dapat didefinisikan dengan pendekatan prosedur dan dengan pendekatan komponen.dengan pendekatan prosedur, sistem dapat didefinisikan sebagai kumpulan
Lebih terperinciBAB III OBJEK DAN METODE PENELITIAN. domain & Web Hosting. Untuk lebih jelas mengenai gambaran umum perusahaan,
BAB III OBJEK DAN METODE PENELITIAN 3.1. Objek Penelitian Penulis melakukan objek penelitian pada Qwords.com perusahaan penyedia jasa layanan Web Hosting (Web Hosting Provider) yang melayani registrasi
Lebih terperinciBAB II TINJAUAN PUSTAKA
BAB II TINJAUAN PUSTAKA II.1. Pengertian Sistem Sistem merupakan salah satu yang terpenting dalam sebuah perusahaan yang dapat membentuk kegiatan usaha untuk mencapai kemajuan dan target yang dibutuhkan.
Lebih terperinci: ANALISA DAN PERANCANGAN SISTEM INFORMASI
MATA KULIAH BOBOT : ANALISA DAN PERANCANGAN SISTEM INFORMASI : 4 SKS ABSENSI : 10% TUGAS/QUIS : 20% UTS : 30% UAS : 40% Rudianto, S.Kom Email1: rudianto.alfarisi@yahoo.co.id Email2 : kumpulin.tugas@yahoo.co.id
Lebih terperinciMetodologi pengembangan sistem METODOLOGI PENGEMBANGAN SISTEM INFORMASI DIAN PALUPI RINI, M.KOM 1
Metodologi pengembangan sistem METODOLOGI PENGEMBANGAN SISTEM INFORMASI adalah metode-metode, prosedur-prosedur, konsep-konsep pekerjaan, aturan-aturan yang akan digunakan sebagai pedoman bagaimana dan
Lebih terperinciPENGEMBANGAN APLIKASI PENJUALAN SPAREPART DI BENGKEL ANUGRAH JAYA MOTOR BERBASIS DESKTOP
PENGEMBANGAN APLIKASI PENJUALAN SPAREPART DI BENGKEL ANUGRAH JAYA MOTOR BERBASIS DESKTOP Nugraha Setiadi 1, Ridwan Setiawan 2 Jurnal Algoritma Sekolah Tinggi Teknologi Garut Jl. Mayor Syamsu No. 1 Jayaraga
Lebih terperinciBAB II LANDASAN TEORI
BAB II LANDASAN TEORI 2.1 Rapat Menurut Sampebu (2010), rapat merupakan sarana berkumpulnya sekelompok orang untuk menyatukan pikiran, pertimbangan, dan pendapat terhadap suatu urusan, masalah, atau pekerjaan
Lebih terperinciDAFTAR ISI BAB I PENDAHULUAN... 1
Abstrak Dalam menjalankan roda pemerintahan, Organisasi Perangkat Daerah (OPD) Provinsi Jawa Barat membutuhkan biaya anggaran Untuk itu dibuatlah sistem penganggaran yang dinamakan Anggaran Pendapatan
Lebih terperinciSDLC Concepts. Muhammad Yusuf D3 Manajemen Informatika Universitas Trunojoyo
SDLC Concepts Muhammad Yusuf D3 Manajemen Informatika Universitas Trunojoyo Http://yusufxyz.wordpress.com Email: muhammadyusuf@trunojoyo.ac.id IVS Task Group Produk terdiri dari : hardware, software, dokumentasi,
Lebih terperinciPRAKTIKUM REKAYASA PERANGKAT LUNAK MODUL KE - 2 PENGENALAN UML dengan RATIONAL ROSE OLEH: ANISA ISTIQOMAH (KELAS 5 B)
PRAKTIKUM REKAYASA PERANGKAT LUNAK MODUL KE - 2 PENGENALAN UML dengan RATIONAL ROSE OLEH: ANISA ISTIQOMAH 09560018 (KELAS 5 B) LABORATORIUM RPL PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS TEKNIK UNIVERSITAS
Lebih terperinci2. BAB II LANDASAN TEORI. lanjut sehingga terbentuk suatu aplikasi yang sesuai dengan tujuan awal.
2. BAB II LANDASAN TEORI Dalam merancang dan membangun aplikasi, sangatlah penting untuk mengetahui terlebih dahulu dasar-dasar teori yang digunakan. Dasar-dasar teori tersebut digunakan sebagai landasan
Lebih terperinciSistem kumpulan dari elemen-elemen atau komponen-komponen atau subsistem-subsistem.
Sistem kumpulan dari elemen-elemen atau komponen-komponen atau subsistem-subsistem. Karakteristik Sistem a. Komponen Sistem (Components) suatu sistem terdiri dari sejumlah komponenyang saling berinteraksi,
Lebih terperinciBAB 1 PENDAHULUAN. 1.1 Latar Belakang
BAB 1 PENDAHULUAN 1.1 Latar Belakang Setiap organisasi memiliki budaya yang berbeda dalam mencapai setiap misi dan tujuannya. Budaya organisasi merupakan kumpulan nilai-nilai yang membantu anggota organisasi
Lebih terperinciBAB II LANDASAN TEORI. pengertian. Secara garis besar ada dua kelompok pendekatan, yaitu:
BAB II LANDASAN TEORI 2.1 Sistem Menurut Kusrini dan Koniyo (2007), Sistem mempunyai beberapa pengertian. Secara garis besar ada dua kelompok pendekatan, yaitu: 1. Pendekatan sistem yang menekankan pada
Lebih terperinciPEMODELAN ANALISIS PL
PEMODELAN ANALISIS PL Aprilia Sulistyohati, S.Kom Jurusan Teknik Informatika Universitas Islam Indonesia Your Logo REKAYASA SISTEM VS REKAYASA PERANGKAT LUNAK Rekayasa sistem berkaitan dengan semua aspek
Lebih terperinciRekayasa Perangkat Lunak (Software Engineering)
Rekayasa Perangkat Lunak (Software Engineering) Graha Prakarsa, ST. MT. Sekolah Tinggi Teknologi Bandung Memahami arti pengembangan perangkat lunak. Mengetahui aktivitas pengembangan perangkat lunak. Memahami
Lebih terperinciBab 3. Metode Perancangan
Bab 3 Metode Perancangan Pada bab ini akan dibahas mengenai metode perancangan yang digunakan dalam membuat perancangan sistem aplikasi penterjemah kata beserta rancangan design interface yang terdapat
Lebih terperinciBAB II LANDASAN TEORI
BAB II LANDASAN TEORI 2.1 Sistem Sistem adalah kumpulan dari elemen-elemen yang berinteraksi untuk mencapai suatu tujuan tertentu. Sistem ini menggambarkan suatu kejadian-kejadian dan kesatuan yang nyata,
Lebih terperinciPEMBANGUNAN PERANGKAT LUNAK PENYIRAMAN TANAMAN SECARA OTOMATIS BERBASIS ANDROID
PEMBANGUNAN PERANGKAT LUNAK PENYIRAMAN TANAMAN SECARA OTOMATIS BERBASIS ANDROID (STUDI KASUS PENYIRAMAN TAMAN RUMAH ) TUGAS AKHIR Disusun Sebagai Salah Satu Syarat Untuk Kelulusan Program Studi Strata
Lebih terperinciBAB III METODOLOGI PENELITIAN. dalam pengumpulan data atau informasi guna memecahkan permasalahan dan
BAB III METODOLOGI PENELITIAN 3.1 Metodologi Penelitian Metodologi penelitian adalah langkah dan prosedur yang akan dilakukan dalam pengumpulan data atau informasi guna memecahkan permasalahan dan menguji
Lebih terperinciMAKALAH REKAYASA PERANGKAT LUNAK ( SIKLUS HIDUP PERANGKAT LUNAK )
MAKALAH REKAYASA PERANGKAT LUNAK ( SIKLUS HIDUP PERANGKAT LUNAK ) Disusun Oleh : MUKHAMAT JAFAR 41813120014 MATA KULIAH : REKAYASA PERANGKAT LUNAK UNIVERSITAS MERCUBUANA 2015 Latar Belakang 1 BAB I PENDAHULUAN
Lebih terperinciBAB I PENDAHULUAN 1.1 Latar Belakang
BAB I PENDAHULUAN 1.1 Latar Belakang Perkembangan teknologi pada masa sekarang ini diperlukan pada semua aspek kehidupan. Teknologi mempermudah manusia untuk memaksimalkan suatu kinerja. Dalam kehidupan
Lebih terperinciSoftware Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC) Budi Irawan facebook.com/deerawan @masbugan blog.budiirawan.com Kenapa butuh SDLC? 1 2 Software pun harus punya dan butuh siklus hidup SDLC 3 Apa itu SDLC? Siklus
Lebih terperinciBAB II TINJAUAN PUSTAKA DAN LANDASAN TEORI
BAB II TINJAUAN PUSTAKA DAN LANDASAN TEORI 2.1 Tinjauan Pustaka Dalam pembuatan tugas akhir Sistem Informasi Administrasi Salon SN berbasis desktop ini dilakukan beberapa tinjauan sumber pustaka, dan berikut
Lebih terperinciBAB II LANDASAN TEORI. terpadu untuk mengembangkan rencana rencana strategis yang diarahkan pada
BAB II LANDASAN TEORI 2.1 Penjualan Menurut Ridwan Iskandar Sudayat, penjualan adalah suatu usaha yang terpadu untuk mengembangkan rencana rencana strategis yang diarahkan pada usaha pemuasan kebutuhan
Lebih terperinciBAB 1 PENDAHULUAN 1.1 Latar Belakang
BAB 1 PENDAHULUAN 1.1 Latar Belakang Perkembangan teknologi informasi sangat cepat seiring dengan kebutuhan akan informasi dan pertumbuhan tingkat kecerdasan manusia. Saat ini telah banyak aplikasi yang
Lebih terperinciBAB II LANDASAN TEORI. Dalam pembangunan suatu sistem informasi, terdapat dua kelompok
10 BAB II LANDASAN TEORI 2.1 Konsep Dasar Sistem Dalam pembangunan suatu sistem informasi, terdapat dua kelompok dalam pendekatan mendefinisikan system, yaitu yang menekankan pada prosedurnya dan yang
Lebih terperinciDisain System Berorientasi Objek (Unified Modeling Language) ( Studi Kasus : Sistem Informasi Manajemen Perpustakaan )
Disain System Berorientasi Objek (Unified Modeling Language) ( Studi Kasus : Sistem Informasi Manajemen Perpustakaan ) BEDA DFD DAN UML DFD ORIENTASI DATA UML INTERAKSI AKTOR O Kotak/Entitas O, Aktor Entitas
Lebih terperinci( Word to PDF Converter - Unregistered ) BAB II LANDASAN TEORI
( Word to PDF Converter - Unregistered ) http://www.word-to-pdf-converter.net BAB II LANDASAN TEORI 2.1 Pengertian Sistem Menurut Jog [2] Suatu sistem adalah suatu jaringan kerja dari prosedur-prosedur
Lebih terperinciMODUL 4 Unified Software Development Process (USDP)
MODUL 4 Unified Software Development Process (USDP) Daftar Isi 4.1 Pengantar USDP... 2 4.2 Fase USDP... 2 4.2.1 Fase, Workflow dan Iterasi... 3 4.2.2 Perbedaan USDP dan Siklus Hidup Waterfall... 3 4.2.3
Lebih terperinciREKAYASA PERANGKAT LUNAK. 3 sks Sri Rezeki Candra Nursari reezeki2011.wordpress.com
REKAYASA PERANGKAT LUNAK 3 sks Sri Rezeki Candra Nursari reezeki2011.wordpress.com Referensi Rekayasa Perangkat Lunak Pendekatan Praktisi, Roger S. Pressman, Ph.D, Andi Jogyakarta, 2012 Buku 1 Rekayasa
Lebih terperinciDAFTAR ISI... LEMBAR JUDUL LEMBAR PENGESAHAN... SURAT PERNYATAAN... ABSTRAK... ABSTRACT... KATA PENGANTAR... DAFTAR TABEL... DAFTAR GAMBAR...
DAFTAR ISI LEMBAR JUDUL LEMBAR PENGESAHAN... SURAT PERNYATAAN... ABSTRAK... ABSTRACT... KATA PENGANTAR... DAFTAR ISI... DAFTAR TABEL... DAFTAR GAMBAR... i ii iii iv v vii xi xiii BAB I PENDAHULUAN... I-1
Lebih terperinciBAB 1 ASUMSI PERANAN PENGANALISIS SISTEM
BAB 1 ASUMSI PERANAN PENGANALISIS SISTEM Informasi adalah sebuah sumber organisasi dimana harus diatur secara baik seperti sumber daya lainnya. Biaya dihubungkan dengan proses informasi. Proses Informasi
Lebih terperinciBAB I PENDAHULUAN 1.1 Latar Belakang
1 BAB I PENDAHULUAN 1.1 Latar Belakang Pada masa kini, khususnya di Indonesia perkembangan teknologi informasi, telekomunikasi dan komputer di era globalisasi semakin pesat, sesuai kebutuhan seiring dengan
Lebih terperinciPertemuan 3. Manajemen Proyek Perangkat Lunak. Proses Dalam Manajemen PL
Pertemuan 3 Manajemen Proyek Perangkat Lunak Proses Dalam Manajemen PL Manajemen proyek merupakan lapisan pertama dalam proses rekayasa perangkat lunak skala besar. Untuk menuju pada proyek yang berhasil,
Lebih terperinciPerencanaan Proyek Perancangan Perangkat Lunak
Perencanaan Proyek Perangkat Lunak Perancangan Perangkat Lunak Software Engineering Bertalya,, 2009 Perencanaan Proyek Objektivitas perencanaan proyek adalah menyediakan framework yang dapat memungkinkan
Lebih terperinciPertemuan 2 SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
Pertemuan 2 SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) POKOK BAHASAN Biaya PL Software Quality Attribute Standar kualitas Takaran Jaminan Kualitas CASE TOOLS Siklus Hidup Perangkat Lunak (SWDLC/Software Development
Lebih terperinciTujuan Perkuliahan. PENGANTAR RPL (Pert. 2 chapter 1 Pressman) Agenda. Definisi Software (Perangkat Lunak) Lunak) 23/09/2010
Tujuan Perkuliahan PENGANTAR RPL (Pert. 2 chapter 1 Pressman) Oleh : Sarwosri, S.Kom, M.T. Umi Laili Yuhana, S.Kom, M.Sc. Memberikan gambaran tentang perangkat lunak, rekayasa perangkat lunak. Memberikan
Lebih terperinciBAB III OBJEK DAN METODE PENELITIAN
BAB III OBJEK DAN METODE PENELITIAN 3.1. Objek Penelitian Objek penelitian adalah variabel penelitian, yaitu sesuatu yang merupakan inti dari problematika penelitian. Penulis mengadakan objek penelitian
Lebih terperinciLEMBAR JUDUL LEMBAR PENGESAHAN
DAFTAR ISI LEMBAR JUDUL LEMBAR PENGESAHAN... SURAT PERNYATAAN... ABSTRAK... ABSTRACT... KATA PENGANTAR... DAFTAR ISI... DAFTAR TABEL... DAFTAR GAMBAR... i iii iv v vi ix xv xvi BAB I BAB II PENDAHULUAN
Lebih terperinci