Manajemen Proyek Perangkat Lunak

Manajemen Proyek Perangkat Lunak 39 a. Sebagai variable estimasi yang akan dipakai untuk “ mengukur” masing-masing elemen perangkat lunak b. Sebagai metrik dasar yang dikumpulkan dari proyek yang lalu dan di[akai dalam hubungannya dengan variable estimasi untuk proyeksi kerja dan biaya. 3. Estimasi Berbasis Proses Teknik yang paling umum yang digunakan untuk memperkirakan sebuah proyek berdasarkan perkiraan yang akan digunakan, yaitu proses yang didekomposisikan dalam serangkaian aktivitas atau tugas yang relatif sangat kecil dan usaha yang dibutuhkan untuk menyelesaikan masing-masing tugas yang diperkirakan. Perkiraan berbasis proses dapat dimulai dengan gambaran fungsi perangkat lunak yang diperoleh dari ruang lingkup proyek. Untuk masing-masing fungsi dilakukan aktivitas proses perangkat lunak yang berhubugan dan dapat disajikan sebagai bagian dari suatu table. Sekali fungsi masalah dan aktivitas proses disatukan perencana akan memperkirakan usaha (seperti person-mont) yang dibutuhkan untuk dapat menyelesaikan setiap aktivitas proyek perangat lunak. F. Menyusun Rencana Manajemen Proyek Kegiatan ini akan mendokumentasikan Tindakan yang diperlukan untuk mendefinisikan, menyiapkan, mengintegrasikan, mengkoordinaksikan semua rencana

40 Manajemen Proyek Perangkat Lunak parsial ke dalam satu rencana manajemen proyek ( contoh rencana prasial adalah: rencana cakupan, rencana anggaran dsb). Proses penyusunan rencana manajemen proyek berlangsung iterative 1. Masukan Dalam Menyusun Rencana Manajemen Proyek a. Project charter, antara memuat sasaran proyek, sasaran produk, kriteria penerimaan produk, kebutuhan, deskripsi proyek, resiko, jadwal, anggaran dll b. Hasil dari Proses-proses perencanaan c. Faktor lingkungan proyek,baik dari Perusahaan maupun di luar Perusahaan. d. Aset proses organisasai, seperti prosedur dan aturan Perusahaan.

Manajemen Proyek Perangkat Lunak 41 Estimasi Proyek Perangkat Lunak Rudi Budi Agung, S.Si.,MMSI BAB 4

42 Manajemen Proyek Perangkat Lunak alam setiap proyek pasti membutuhkan estimasi, apapun bentuk proyek tersebut, baik itu jasa maupun produk. Salah satunya estimasi biaya menjadi suatu hal yang sangat krusial dan penting ketika kita membuat suatu proposal, perencanaan, pelaksanaan hingga evaluasi suatu proyek. Tidak terlepas untuk proyek perangkat lunak sekalipun, kita tetap membutuhkan perencanaan biaya atau estimasi biaya yang akan menjadi pedoman dalam melaksanakan proyek hingga selesai. Pada buku bab 4 ini kami membahas secara umum dimana proyek yang diselenggarakan untuk lingkup pemerintahan dengan linkup swasta berbeda dari sisi anggaran biayanya. Hal ini karena dalam pengadaan proyek pemerintahan sistem pembayaran memerlukan waktu yang cukup lama sehingga pihak pengembang atau yang menjalankan proyek akan memberikan tambahan biaya berupa konversi dari bunga bank atau ada juga menggunakan indeks factor pengali terutama untuk instansi pemerintahan yang mungkin jauh dari perkotaan yang mempengaruhi biaya mobilitas tim ataupun perangkat. Bagi pengadaan proyek dibawah pemerintahan saat ini kita dapat Menyusun anggaran proyek melalui portal eKatalog (https://e-katalog.lkpp.go.id/ ). Sekarang mari kita focus kepada estimasi proyek secara umum. Ketika kita menginginkan suatu proyek sistem/perangkat lunak yang dibuat oleh tim internal perusahaan serta menggunakan aplikasi open souce atau freeware sekalipun, kita tetap harus menghitung biaya secara professional. Biaya tersebut dapat berupa biaya pelaksanaan rapat, ATK, pembuatan manual book hingga training. Bahkan mungkin biaya lembur bagi tim pengembang (IT developer) tetap harus dihitung. Selain itu pengadaan hardware untuk server, biaya langganan link internet/WAN/LAN juga harus tetap D

Manajemen Proyek Perangkat Lunak 43 dianggarkan. Kalaupun kita memilih menggunakan jasa collocation atau cloud tetap perlu dianggarkan biaya sewa dan maintenance dalam estimasi biaya tersebut. Mengapa kita perlu membuat estimasi biaya proyek? Berikut ini kegunaan ketika kita membuat estimasi biaya proyek, diantaranya adalah: 1. Pihak manajemen dapat menganggarkan total kebutuhan biaya dari masing-masing tahapan sehingga memudahkan bagian keuangan dalam mengatur cash flow. 2. Membantu manajer proyek dalam melakukan pengawasan akan target terhadap biaya yang telah dikeluarkan dengan capaian secara fisik dari masingmasing tahapan proyek. 3. Membantu manajer proyek dalam menentukan keputusan ketika suatu jenis pekerjaan mengalami masalah. Misal; Ketika proyek sedang berjalan, tiba-tiba seorang programmer mengundurkan diri/berpindah tugas. Maka disini peranan informasi biaya dari manprower (SDM) harus menjadi perhatian khusus dari seorang manajer proyek, apakah akan mencari pengganti atau tetap melanjutkan dengan resource yang ada? Bagaimana kriteria penggantinya? Dan berapa lama masa kontrak kerjanya? dst. 4. Memberikan gambaran pihak manajemen secara jelas apakah proyek akan menguntungkan atau akan merugikan. Pada buku ini kami tidak menjelaskan biaya dari masingmasing kebutuhan karena harga ataupun biaya sangat

44 Manajemen Proyek Perangkat Lunak bervariatif tergantung jenis proyek, lingkup pekerjaan dan skala prioritas. Namun dalam buku ini kami menjelaskan estimasi pekerjaan dalam suatu proyek perangkat lunak. Untuk itu sebelum memulai suatu proyek perangkat lunak kita perlu menghitung estimasi kebutuhan yang akan digunakan. Langkah pertama yang harus kita kerjakan adalah; 1. Persiapan kebutuhan infrastruktur (Fisik) 2. Persiapan kebutuhan software pendukung 3. Persiapan kebutuhan sumber daya manusia 4. Persiapan kebutuhan lain-lain A. Persiapan kebutuhan infrastruktur Pada kegiatan ini kita harus memastikan perangkat fisik yang akan digunakan dalam proyek. Tabel berikut ini adalah contoh kebutuhan tersebut. Tabel 1. Kebutuhan infrastruktur No. Kebutuhan 1 Server dapat berupa fisik atau berlangganan collocation/hosting ataupun cloud. 2 Koneksi internet/LAN (dapat berupa pengadaan line jaringan seperti kabel UTP/LAN) atau perangkat access point utk wifi, switch port manageable/unmanageable, hub dan sejenisnya. 3 Perangkat keamanan server (seperti langganan SLL, firewall, modem,

Manajemen Proyek Perangkat Lunak 45 4 PC atau laptop jika dibutuhkan untuk tim pengembang & admin proyek. 5 Printer. Biasanya dalam pekerjaan proyek inhouse kita sering mengabaikan perangkat tersebut dengan asumsi selama ini bahwa semua sudah tersedia atau dapat menggunakan perangkat yang ada, sehingga kita lupa menganggarkan. Hal ini boleh saja sebagai bentuk menekan biaya anggaran namun jika suatu saat perangkat tersebut rusak maka harus dipikirkan anggaran mengambil dari post yang mana?. Jadi meskipun dalam kegiatan proyek dilakukan oleh tim internal atau inhouse team IT, perangkat infrastruktur sebaiknya tetap harus dianggarkan. B. Persiapan kebutuhan software pendukung Pada tahapan persiapan kebutuhan software/perangkat lunak pendukung juga kita perlu adakan. Kebutuhan tersebut harus dihitung dikarena adanya lisensi dari suatu software berbayar yang dapat dilihat pada tabel 2. Tabel 2. Kebutuhan software pendukung No. Kebutuhan Software pendukung keterangan 1 Lisensi Sistem operasi Server Misal: Windows Server dan atau client.

46 Manajemen Proyek Perangkat Lunak 2 Lisensi database Misal: SQL, oracle, dsb. 3 Lisensi perangkat lunak pengembangan Misal: Matlab, power BI, MS Share point dsb. Kebutuhan Software pendukung diatas bervariasi tergantung jenis proyek yang akan dikerjakan dan tentunya memiliki harga yang berbeda pula. C. Persiapan kebutuhan sumber daya manusia Sebelum memulai proyek hal yang terpenting adalah dibentuknya steering committee yang bertugas membentuk tim Manajemen Proyek dan mengawasi semua tahapan proyek. Kebutuhan sumber daya manusia dalam sebuah proyek perangkat lunak dapat dikatakan menjadi kebutuhan primer/wajib untuk diutamakan. Karena salah satu kunci sukses proyek perangkat lunak adalah bagaimana kualitas sumber daya manusia dan pengelolaannya. Berikut ini estimasi kebutuhan sumber daya manusia untuk proyek perangkat lunak. No SDM Tugas Pokok Spesifikasi 1 Manager Proyek Memimpin jalannya proyek dari mulai perencanaan, pelaksanaan, monitoring, evaluasi Memiliki kemampuan leadership, pengalaman dan menguasai

Manajemen Proyek Perangkat Lunak 47 hingga serah terima. bisnis proses secara baik, kemampuan administrasi, komunikatif dan tahan terhadap tekanan. Sistem Analis Bertugas menterjemahkan antara kebutuhan user dengan tim pengembang (baik programmer, database administrator maupun IT security). -memiliki kemampuan komunikasi yang baik, memahami bisnis proses, memahami latar belakang database dan pemrograman. 3 IT security Mengatur keamanan sistem. Menguasai tools sistem keamanan 4 Programm er Membangun sistem/aplikasi. Menguasai Bahasa pemrogramman sesuai kebutuhan aplikasi yang dibangun. 5 Database Membangun database. Menguasai

48 Manajemen Proyek Perangkat Lunak Administr ator sistem database sesuai kebutuhan aplikasi. 6 QC/QA Bertanggungjawab menjaga kualitas aplikasi yang dibangun dan melakukan uji kelayakan sistem. Menguasai kebutuhan bisnis sesuai dokumen Perencanaan dan tools pengujian sistem. 7 IT Support Bertanggungjawab menyiapkan infrastruktur tim, installlasi jaringan, aplikasi pendukung dan maintenance. Menguasai dasar-dasar IT infrastruktur, installasi dan komunikatif. 8 Implemen tor atau Integrator Bertanggungjawab menerapkan/impleme ntasi aplikasi sesuai kebutuhan yang tertuang dalam dokumen proyek. Menguasai aplikasi yang sudah ada. 9 Admin proyek Bertanggungjawab mendokumentasikan berkas, mengadakan rapat, mengatur administrasi dan Menguasai administrasi dengan baik dan komunikatif

Manajemen Proyek Perangkat Lunak 49 sejenisnya. dengan semua Tim. Selain kebutuhan SDM diatas, ada juga proyek perangkat lunak melibatkan tim Implementor atau Integrator. Dimana tugas tim Implementor dibutuhkan jika proyek berbentuk implementasi dari suatu aplikasi yang sudah jadi, misal; Penerapan aplikasi SAP, Oracle ERP, Odoo ERP dan sejenisnya. Tim IT Support juga biasanya dibutuhkan mulai dari awal proyek hingga maintenance/masa garansi. Dimana salah satu tugas pentingnya adalah mendampingi tim yang akan menggunakan aplikasi tersebut hingga benar-benar menguasai (serah terima). D. Persiapan kebutuhan lain-lain Selain tiga persiapan tersebut diatas yang terakhir adalah persiapan kebutuhan lain-lain seperti ; No Kebutuhan Keterangan 1 ATK (seperti kertas, toner/ink printer, amplop, spidol, white board dsb) Biasanya digunakan untuk surat-menyurat, rapat, briefing dsb. 2 Konsumsi Untuk kebutuhan rapat atau tim selama proses pengembangan sistem. 3 Perjalanan dinas/studi banding Berapa kali dilakukan perjalanan dinas, rapat?

50 Manajemen Proyek Perangkat Lunak (harus ditentukan baik rapat kecil maupun rapat dengan manajemen maupun vendor) 4 Foto copy Duplikasi manual book atau dokumen penting lainnya. 5 Transportasi Untuk mobilisasi tim 6 Training Untuk pelatihan kepada user setelah sistem selesai.Biasanya disiapkan juga honor untuk instruktur/narasumber/un dangan dan peserta. Dari semua kegiatan persiapan diatas masing-masing memiliki time line/waktu yang mungkin dapat bersamaan ataupun beriringan. Semua tergantung bagaimana kita mengatur ketersediaan keuangan maupun target yang ingin dicapai. Semakin singkat pelaksanaan proyek maka semakin besar dana yang dibutuhkan karena pasti biaya akan meningkat.

Manajemen Proyek Perangkat Lunak 51 Penyusunan Rencana Manajemen Proyek Perangkat Lunak Tati Ernawati, M.T BAB 5

52 Manajemen Proyek Perangkat Lunak A. Knowledge Areas Manajemen Proyek Tahapan penyusunan rencana manajemen proyek perangkat lunak tidak akan terlepas dari kerangka kerja (framework) manajemen proyek, isinya menjelaskan kompetensi utama manajer proyek (Schwalbe 2011). Rencana proyek adalah tanggung jawab manajer proyek, merumuskan strategi dan memastikan keberhasilan proyek. Kerangka kerja manajemen proyek mencakup 9 (Sembilan) Kowledge Area (KA) seperti pada Gambar 1. Empat bidang pengetahuan (KA) inti manajemen proyek meliputi project scope, time, cost, dan quality management. 1. Project scope management, pendefinisian dan pengelolaan seluruh pekerjaan diperlukan untuk menyelesaikan proyek supaya tercapai dengan sukses. 2. Project time management, memperkirakan waktu yang diperlukan untuk menyelesaikan pekerjaan, mengembangkan jadwal proyek, dan memastikan proyek diselesaikan tepat waktu. 3. Project cost management, penyusunan dan pengelolaan anggaran proyek 4. Project quality management, memastikan proyek memenuhi tujuan atau kebutuhan. Sedangkan 4 (Empat) KA memfasilitasi manajemen proyek dikarenakan merupakan proses yang digunakan untuk mencapai tujuan proyek, mencakup human resource, communications, risk, dan procurement management.

Manajemen Proyek Perangkat Lunak 53 1. Project human resource management berkaitan dengan cara mengoptimalkan sumber daya manusia yang terlibat dalam proyek. 2. Project communications management, menghasilkan, mengumpulkan, menyebarkan, dan menyimpan data proyek 3. Project risk management termasuk mengidentifikasi, menganalisis, dan merespons risiko yang berhubungan dengan proyek. 4. Project procurement management melibatkan membeli atau mendapatkan barang dan jasa dari pihak lain yang berada di luar organisasi pelaksana untuk proyek tersebut. Project integration management, bidang pengetahuan ke-9 merupakan fungsi menyeluruh yang mempengaruhi dan dipengaruhi oleh semua KA lainnya. Gambar 1. Kerangka Kerja Manajemen Proyek (Schwalbe 2011)

54 Manajemen Proyek Perangkat Lunak B. Tahapan Penyusunan Rencana Proyek Menurut Jack dalam bukunya berjudul The State of IT Project Management menjelaskan bahwa terapat 4 faktor penyebab kegagalan proyek yaitu manusia, proses, teknologi dan organisasi. Faktor proses dipengaruhi oleh beberapa parameter salah satunya yaitu perencanaan yang buruk (poor planning) (Marchewka 2016). Perencanaan proyek sangat penting. Proyek mungkin tertunda atau bahkan gagal jika tidak ada rencana yang kuat. Perencanaan yang baik membantu dalam menentukan setiap langkah yang perlu dilakukan untuk mencapai tujuan proyek, membantu mengelola sumber daya dengan lebih baik dan mengurangi risiko selama proyek (Windiarti 2023). Gambar 2. Proses Perencanaan-PMBOK (Schwalbe 2011) Panduan PMBOK hanyalah garis besar, sehingga berbagai organisasi dapat menggunakannya untuk

Manajemen Proyek Perangkat Lunak 55 menghasilkan berbagai hasil perencanaan yang disesuaikan dengan kebutuhan unik masing-masing organisasi. Tahapan penyusunan perencanaan proyek mengacu kepada A Guide to the Project Management Body of Knowledge (PMBOK) edisi 4 mencakup 20 proses yang merupakan bagian dari 9 Knowlegde Area (KA), masingmasing tahapan memiliki keluarannya masing-masing (output) (Schwalbe 2011). 1. Project Integration Management Proses pertama mengembangkan rencana manajemen proyek termasuk kedalam KA ini. Keluaran dari proses pertama ini berupa dokumen project management plan. 2. Project Scope Management Tahap ke 2, 3 dan 4 merupakan bagian dari KA Project Scope Management. Keluaran (outputs) dari masing-masing tahap yaitu: a. Tahap 2 mengumpulkan kebutuhan, keluaran berupa requirements documents, requirements management plan dan requirements traceability matrix. Menentukan dan mencatat kebutuhan stakeholders memberikan kontribusi besar dalam menyediakan prosedur dan pendekatan yang digunakan selama proses pengumpulan kebutuhan (Khairani 2023). b. Tahap 3 mendefinisikan cakupan, keluaran berupa project scope statement dan project document updates. Contoh format dari Project scope statement. Cakupan proyek harus didefinisikan secara menyeluruh, menentukan apa dan tidak

56 Manajemen Proyek Perangkat Lunak yang termasuk dalam proyek (dalam cakupan). Menentukan cakupan yang jelas membantu mencegah perubahan yang tidak terkendali selama proyek berlangsung (Windiarti 2023). c. Tahap 4 membuat Work Break Structure (WBS), keluaran terdiri dari WBS, WBS dictionary, scope baseline dan project document update. 3. Project Time Management KA Project Time Management mencakup tahapan ke 5 sampai dengan 9. a. Tahap 5 mendefinisikan aktivitas, dokumen keluaran berupa activity list, activity attributes dan milestone list. Menentukan proses apa yang harus dilakukan selama proyek untuk memastikan bahwa proyek dapat berjalan dengan cepat sambil mempertahankan biaya yang rendah dan menjaga kualitas jasa, produk, dan hasil yang unik. b. Tahap 6 urutan kegiatan, dokumen keluaran seperti project schedule network diagrams dan project document updates. Membuat urutan aktivitas merupakan detil dari WBS, detil deskripsi produk, asumsi dan batasan-batasan untuk menentukan hubungan antar aktivitas. c. Tahap 7 perkirakan aktivitas sumber daya, keluarannya adalah dokumen activity resource requirements, resource breakdown structure dan project document updates. Sumber daya yang diperlukan, seperti tenaga kerja, peralatan, dan teknologi, harus didistribusikan secara efisien dan sesuai dengan kebutuhan proyek (Windiarti 2023).

Manajemen Proyek Perangkat Lunak 57 d. Tahap 8 perkirakan durasi aktivitas, keluaran berupa dokumen activity duration estimates dan project document updates. e. Tahap 9 mengembangkan jadwal, keluaran berupa project schedule, schedule baseline, schedule data dan project document updates. Membuat jadwal proyek yang realistis dan membagi pekerjaan menjadi bagian yang dapat dikelola. Pengelolaan waktu yang efektif membantu proyek berjalan sesuai jadwal (Windiarti 2023). Perencanaan proyek menjadi lebih mudah menggunakan Gantt Chart, plot setiap tugas proyek secara visual, menambahkan tugas utama, dan menemukan konflik atau hubungan yang belum diperhitungkan (Khairani 2023). 4. Project Cost Management Proses perencanaan 10 dan 11 termasuk kedalam kelompok KA ini. a. Tahap 10 estimasi biaya, keluaran terdiri dari activity cost estimates, basis of estimates dan project document updates. Menentukan biaya proyek keseluruhan mencakup perkiraan biaya untuk pengembangan perangkat lunak, infrastruktur, dan biaya tenaga kerja (Windiarti 2023). b. Tahap 11 tentukan anggaran, keluarannya cost performance baseline, project funding requirements dan project document updates. 5. Project Quality Management Tahap ke 12 termasuk ke dalam KA Project Quality Management. Keluaran seperti quality management

58 Manajemen Proyek Perangkat Lunak plan, quality metrics, quality checklists, process improvement plan dan project document updates 6. Project Human Management Tahap ke 13 mengembangkan rencana Sumber Daya Manusia (SDM) termasuk ke dalam KA Project Quality Management. Keluarannya berupa dokumen human resource plan. Identifikasi dan dokumentasi tanggungjawab masing-masing tim, rencana renumerasi, reward dan cara penilaian kinerja beserta kriteria memberhentikan seseorang dalam tim proyek. 7. Project Communications Management KA ini mencakup tahapan ke 14. Keluarannya adalah communications management plan dan project document updates. Merencanakan cara komunikasi dengan stakeholder dan tim proyek akan berjalan selama proyek, memulai rapat awal dan menyertakan laporan-laporan status proyek dalam rencana komunikasi (Khairani 2023). 8. Project Risk Management Tahapan ke 15 sampai 19 merupakan bagian dari KA Project Risk Management a. Tahap 15 plan risk management, keluaran yaitu risk management plan. Proses ini menentukan metode apa yang akan digunakan dan bagaimana menjalankan prosedur manajemen risiko proyek. b. Tahap 16 identify risks, keluarannya yaitu risk register. Semua risiko yang dapat mempengaruhi proyek harus diidentifikasi, termasuk risiko teknis, risiko manajemen, risiko perubahan kebutuhan, dan lain-lain. Setiap risiko harus dianalisis secara

Manajemen Proyek Perangkat Lunak 59 menyeluruh untuk menentukan kemungkinan dan dampaknya (Windiarti 2023). c. Tahap 17 perform qualitative risk analysis, keluarannya yaitu risk register updates. Memberi prioritas pada risiko proyek digunakan sebagai dasar untuk analisis dan tindakan selanjutnya dengan melakukan evaluasi dan menggabungkan peluang munculnya risiko beserta dampaknya. d. Tahap 18 perform quantitative risk analysis, keluarannya yaitu risk register updates. Register risiko adalah dokumen yang mengumpulkan hasil dari berbagai proses manajemen risiko, biasanya dalam bentuk tabel atau spreadsheet, dan digunakan sebagai alat untuk mendokumentasikan potensi kejadian risiko dan informasi yang berkaitan dengannya e. Tahap 19 plan risk responses, keluarannya yaitu risk register updates, project management plan updates, risk related contract decisions dan project document updates. Tim proyek dapat menggunakan hasil dari proses manajemen risiko sebelumnya untuk membuat strategi reaksi terhadap risiko. Hal ini sering memerlukan pembaharuan daftar risiko dan rencana manajemen proyek seperti persetujuan perjanjian yang berkaitan dengan risiko. 9. Project Procurement Management Proses perencanaan terakhir yaitu rencana pengadaan termasuk ke dalam KA Project Procurement Management. Keluarannya berupa procurement management plan, procurement statement of work,

60 Manajemen Proyek Perangkat Lunak make-or-buy decisions, procurement documents, source selection criteria dan change requests. C. Isi Dokumen Perencanaan Proyek Isi dokumen perencanaan proyek mengacu kepada PMBOK, IEEE1058.1:1987 dan Schwalbe (Schwalbe 2011). 1. PMBOK, terdiri dari cakupan proyek, jadwal, biaya, mutu, proses, SDM, komunikasi, risiko dan pembelian. Termasuk didalamnya adalah daftar milestones, kalender sumber daya, baseline jadwal, baseline biaya, baseline mutu dan register risiko 2. IEEE1058.1:1987, terdiri dari halaman sampul, halaman revisi, kata pengantar, daftar isi, daftar gambar daftar tabel, pendahuluan, organisasi proyek, proses manajerial, proses teknis, paket pekerjaan, jadwal, dan anggaran. Tambahan berupa lampiran dan indeks (apabila diperlukan) 3. Schwalbe, mencakup project charter, rencana cakupan, rencana biaya, jadwal kegiatan, rencana manajemen mutu, rencana manajemen risiko, rencana keterlibatan stakeholders, rencana komunikasi, baseline biaya dan waktu, proses manajemen komunikasi proses pengendalian perubahan, rencana manajemen perubahan organisasional, proses manajemen penerimaan produk, isu kenaikan dan manajemennya, rencana pelatihan, rencana implementasi dan transisi produk proyek.

Manajemen Proyek Perangkat Lunak 61 D. Tools Perencanaan Alat bantu yang digunakan untuk merencanakan manajemen proyek perangkat lunak (Schwalbe 2011). 1. Work Breakdown Structure (WBS) WBS memberikan dasar melakukan manajemen nilai yang diperoleh untuk mengukur dan memprediksi kinerja proyek, serta untuk membuat jadwal proyek. WBS adalah daftar pekerjaan atau tugas, yang juga disebut sebagai tugas yang akan dilakukan dalam sebuah proyek (Fadhli et al. 2021) Gambar 3. Contoh WBS Intranet Berdasarkan Produk (Schwalbe 2011) 1.0 Inisialisasi 1.1 Identifikasi pemangku kepentingan utama 1.2 Mempersiapkan project charter 1.3 Mengadakan pertemuan awal proyek 2.0 Perencanaan 2.1 Mengadakan rapat tim perencanaan 2.2 Menyiapkan kontrak tim 2.3 Mempersiapkan statemen ruang lingkup 2.4 Mempersiapkan WBS 2.5 Menyiapkan jadwal dan biaya dasar 2.5.1 Menentukan sumber daya tugas

62 Manajemen Proyek Perangkat Lunak 2.5.2 Menentukan durasi tugas 2.5.3 Menentukan ketergantungan tugas 2.5.4 Membuat draf diagram Gantt 2.5.5 Meninjau dan menyelesaikan bagan Gantt 2.6 Identifikasi, diskusikan, dan prioritaskan risiko 3.0 Eksekusi 3.1 Survei 3.2 Masukan dari pengguna 3.3 Konten situs intranet 3.3.1 Template dan alat 3.3.2 Artikel 3.3.3 Tautan (Links) 3.3.4 Tanyakan pada ahlinya 3.3.5 Permintaan fitur dari pengguna 3.4 Desain situs intranet 3.5 Pembangunan situs intranet 3.6 Pengujian situs intranet 3.7 Promosi situs intranet 3.8 Peluncuran situs intranet 3.9 Pengukuran manfaat proyek 4.0 Monitoring dan kontrol 4.1 Laporan kemajuan 5.0 Penutupan 5.1 Menyiapkan laporan tugas akhir 5.2 Mempersiapkan presentasi tugas akhir 5.3 Pelajaran yang didapat (Lessons learned)

Manajemen Proyek Perangkat Lunak 63 2. Responsibility Assignment Matrix/RAM Memetakan pekerjaan proyek sebagaimana dijelaskan dalam WBS kepada Person In Charge (PIC) untuk bekerja seperti yang dijelaskan dalam Organizational Breakdown Structure (OBS). Gambar 4. Contoh RAM (Schwalbe 2011) 3. Gantt Charts Format standar menampilkan informasi jadwal proyek berdasarkan daftar kegiatan proyek dan tanggal mulai dan selesai (format kalender). Gambar 5. Intranet Gantt chart pada Microsoft Project (Marchewka 2016)

64 Manajemen Proyek Perangkat Lunak 4. Jaringan kerja Digunakan untuk mengingat urutan pekerjaan, tanggal dimulai dan selesai, serta waktu proyek secara keseluruhan selesai. Gambar 6. Tampilan Network Diagram (Schwalbe 2011)

Manajemen Proyek Perangkat Lunak 65 Manajemen Kualitas Perangkat Lunak Novita Lestari Anggreini, M.Kom. BAB 6

66 Manajemen Proyek Perangkat Lunak A. Manajemen Kualitas Perangkat Lunak Adalah proses manajemen yang bertujuan untuk mengembangkan dan mengelola kualitas perangkat lunak sedemikian rupa sehingga dapat memastikan bahwa produk memenuhi standar kualitas yang diharapkan oleh pelanggan sekaligus memenuhi persyaratan peraturan dan pengembang yang diperlukan, jika ada. Manajer kualitas perangkat lunak mengharuskan perangkat lunak diuji sebelum dirilis ke pasar, dan mereka melakukan ini menggunakan penilaian kualitas berbasis proses siklus untuk mengungkap dan memperbaiki bug sebelum dirilis. Tugas mereka bukan hanya memastikan perangkat lunak mereka dalam kondisi baik bagi konsumen namun juga mendorong budaya kualitas di seluruh perusahaan (Sommerville, 2011). B. Kegiatan Manajemen Mutu Aktivitas manajemen kualitas perangkat lunak umumnya dibagi menjadi tiga komponen inti: jaminan kualitas, perencanaan kualitas, dan pengendalian kualitas (Maxim, 2014). Beberapa orang seperti insinyur perangkat lunak dan penulis Ian Sommerville tidak menggunakan istilah "pengendalian kualitas" (karena pengendalian kualitas sering kali dipandang lebih sebagai istilah manufaktur daripada istilah pengembangan perangkat lunak), melainkan menghubungkan konsep-konsep terkait dengan konsep jaminan kualitas (Sommerville, 2011). Namun, ketiga komponen inti tersebut tetap sama.

Manajemen Proyek Perangkat Lunak 67 1. Jaminan Kualitas Penjaminan kualitas perangkat lunak menetapkan serangkaian proses organisasi yang terorganisir dan logis dan memutuskan bahwa standar pengembangan perangkat lunak berdasarkan praktik terbaik industry yang harus dipadukan dengan proses organisasi tersebut, pengembang perangkat lunak memiliki peluang lebih besar untuk menghasilkan perangkat lunak berkualitas lebih tinggi. Namun, menghubungkan atribut kualitas seperti "pemeliharaan" dan "keandalan" dengan proses lebih sulit dalam pengembangan perangkat lunak karena elemen desain kreatifnya dibandingkan proses mekanis manufaktur. Selain itu, "standardisasi proses terkadang dapat menghambat kreativitas, sehingga menghasilkan kualitas perangkat lunak yang lebih buruk daripada kualitas yang lebih baik" (Sommerville, 2011). Tahap ini dapat mencakup: a. Mendorong standar proses dokumentasi, seperti pembuatan dokumen teknik yang terdefinisi dengan baik menggunakan templat standar. b. Membimbing bagaimana melakukan proses standar, seperti tinjauan kualitas. c. Melakukan prosedur pencatatan data uji dalam proses. d. Mengidentifikasi standar, jika ada, yang harus digunakan dalam proses pengembangan perangkat lunak.

68 Manajemen Proyek Perangkat Lunak 2. Perencanaan Mutu Perencanaan kualitas bekerja pada tingkat yang lebih terperinci dan berbasis proyek, mendefinisikan atribut-atribut kualitas yang akan dikaitkan dengan keluaran proyek dan bagaimana atribut-atribut tersebut harus dinilai. Selain itu, standar organisasi apa pun yang ada juga dapat ditetapkan ke proyek pada tahap ini. Atribut seperti "kekokohan", "aksesibilitas", dan "modularitas" dapat diberikan pada proyek pengembangan perangkat lunak (Zsolt, 2014). Meskipun ini mungkin merupakan proses yang lebih formal dan integral, mereka yang menggunakan metode manajemen mutu yang lebih tangkas mungkin kurang menekankan struktur perencanaan yang ketat (Sommerville, 2011). Rencana mutu juga dapat mencakup pasar yang dituju, tanggal rilis penting, sasaran mutu, risiko yang diperkirakan, dan kebijakan manajemen risiko (Maxim, 2014). 3. Kontrol Kualitas Tim kendali mutu menguji dan meninjau perangkat lunak pada berbagai tahap untuk memastikan proses dan standar jaminan mutu di tingkat organisasi dan proyek diikuti (Zsolt, 2014). Beberapa orang seperti Sommerville menghubungkan tanggung jawab ini dengan jaminan kualitas daripada menyebutnya kendali mutu (Sommerville, 2011). Pemeriksaan ini secara optimal dipisahkan dari tim pengembangan sehingga memberikan pandangan yang lebih obyektif tentang produk yang akan dibuat. Diuji (Maxim, 2014). Namun, manajer proyek di sisi pengembangan

Manajemen Proyek Perangkat Lunak 69 juga harus membantu, membantu mempromosikan "budaya yang memberikan dukungan tanpa menyalahkan ketika kesalahan ditemukan" sebagai bagian dari fase ini. Di perusahaan pengembangan perangkat lunak yang menerapkan pendekatan kualitas yang lebih tangkas, aktivitas ini mungkin kurang formal; namun, peralihan ke metode tangkas dari struktur manajemen mutu yang lebih formal dapat menimbulkan masalah jika prosedur manajemen tidak disesuaikan dengan tepat (Sommerville, 2011). Kegiatannya meliputi: a. Pengujian rilis perangkat lunak, termasuk dokumentasi yang tepat dari proses pengujian. b. Pemeriksaan perangkat lunak dan dokumentasi terkait untuk ketidaksesuaian dengan standar. c. Tinjauan tindak lanjut perangkat lunak untuk memastikan setiap perubahan yang diperlukan yang dirinci dalam pengujian sebelumnya telah diatasi. d. Penerapan pengukuran perangkat lunak dan metrik untuk penilaian. C. Kualitas Perangkat Lunak dan Siklus Hidup Perangkat Lunak Pengukuran kualitas perangkat lunak berbeda dengan pengukuran manufaktur; toleransi tidak dapat diterapkan (setidaknya dengan cara yang sama), dan kesimpulan obyektif mengenai apakah perangkat lunak memenuhi spesifikasi sulit atau bahkan tidak mungkin dicapai

70 Manajemen Proyek Perangkat Lunak (Sommerville, 2011). Namun, kualitas perangkat lunak dan status kesesuaian untuk tujuan masih dapat diwujudkan dengan berbagai cara tergantung pada organisasi dan jenis proyek yang direalisasikan (Kelemen, 2013). Hal ini dilakukan melalui dukungan seluruh siklus hidup pengembangan perangkat lunak , artinya: 1. Mengumpulkan persyaratan dan menentukan ruang lingkup proyek TI, berfokus pada verifikasi apakah persyaratan yang ditentukan dapat diuji; 2. Merancang solusi, berfokus pada perencanaan proses pengujian, misalnya, jenis pengujian apa yang akan dilakukan dan bagaimana pengujian tersebut akan dilakukan dalam konteks lingkungan pengujian dan data pengujian?; 3. Menerapkan solusi yang didukung oleh kasus uji dan skenario, melaksanakannya, dan mencatat kerusakan, termasuk koordinasi penyelesaian kerusakan; 4. Menerapkan manajemen perubahan, didukung oleh verifikasi tentang bagaimana perubahan yang direncanakan dapat mempengaruhi kualitas solusi yang dibuat dan pada akhirnya mengubah rencana pengujian; Dan 5. Penutupan proyek, didukung oleh realisasi pengujian yang berfokus pada verifikasi kompleks terhadap kualitas keseluruhan solusi yang dibuat.

Manajemen Proyek Perangkat Lunak 71 D. Tautan Metode TI Manajemen kualitas perangkat lunak adalah topik yang sangat terkait dengan berbagai metode manajemen proyek, pengembangan, dan operasi TI, termasuk: 1. Metode manajemen Proyek (Kantor Perdagangan Pemerintah, 2009) mendefinisikan: a. Komponen "Kualitas dalam lingkungan proyek", yang menjelaskan perlunya pemeriksaan ulang dan pengendalian obyektif terhadap produk yang dibuat. Ini mengusulkan menggunakan 4 elemen: sistem manajemen mutu, fungsi kendali mutu, perencanaan mutu dan kendali mutu. b. "Teknik Tinjauan Kualitas" yang berfokus pada verifikasi apakah produk yang dibuat memenuhi kriteria kualitas yang ditentukan. 2. Metode manajemen proyek PMBOK edisi ke-4 (PMI, 2008) mendefinisikan bidang pengetahuan Manajemen Kualitas Proyek dan proses berikut: a. Kualitas Rencana, b. Melakukan Penjaminan Mutu, c. Lakukan Kontrol Kualitas 3. Metode pengembangan RUP mendefinisikan pengujian disiplin, yang dilakukan di semua fase mulai dari Inception, hingga Transisi. 4. Metode pengembangan MSF mendefinisikan peran penguji dan fase stabilisasi, yang berfokus terutama pada pengujian solusi (Framework, 2005).

72 Manajemen Proyek Perangkat Lunak 5. Metode tangkas tidak secara tepat mendefinisikan peran atau mekanisme penguji terkait dengan manajemen kualitas perangkat lunak. Metode tersebut hanya mendefinisikan teknik seperti integrasi berkelanjutan dan pengembangan berbasis pengujian. Namun demikian, yang terakhir muncul adalah publikasi tentang pengujian tangkas . Gambar 1. Contoh Implementasi Software Quality Management Untuk Proyek Menggunakan RUP dan VModel 6. Metode operasional COBIT antara lain mendefinisikan proses P08 Manage Quality. 7. Metode operasional CMMI mendefinisikan antara lain area proses PPQA "Jaminan Kualitas Proses dan Produk", yang sudah diwajibkan pada CMMI level 2. 8. Metode operasional ITIL didefinisikan antara lain dengan publikasi Peningkatan layanan berkelanjutan.

Manajemen Proyek Perangkat Lunak 73 9. V-Model, yang mendefinisikan siklus hidup pengembangan perangkat lunak dan proses pengujian. 10. ISO 9000, rangkaian standar terkait dengan sistem manajemen mutu dan dirancang untuk membantu organisasi memastikan bahwa mereka memenuhi kebutuhan pelanggan dan pemangku kepentingan lainnya sekaligus memenuhi persyaratan undangundang dan peraturan terkait produk. E. Asosiasi dan Organisasi 1. American Society for Quality (ASQ) adalah organisasi profesional yang memberikan sertifikasi, pelatihan, publikasi, konferensi, dan layanan lain kepada anggotanya terkait dengan manajemen mutu, peningkatan berkelanjutan, dan keamanan produk. 2. Dewan Kualifikasi Pengujian Perangkat Lunak Internasional (ISTQBP) adalah asosiasi internasional nirlaba yang terdaftar di Belgia. Badan ini mengelola proses sertifikasi untuk penguji perangkat lunak dan menawarkan lebih dari 535.000 penerbitan sertifikat di lebih dari 120 negara.

74 Manajemen Proyek Perangkat Lunak

Manajemen Proyek Perangkat Lunak 75 Analisis dan Dokumentasi Persyaratan Perangkat Lunak Rachmat Iskandar, M.Kom. BAB 7

76 Manajemen Proyek Perangkat Lunak A. Ringkasan Eksekutif Metodologi Proyek pengendalian NLC akan memakan waktu bertahun-tahun, melibatkan kolaborasi banyak insinyur, namun tingkat kepegawaian tidak akan konstan. Tujuan jangka pendek penulis adalah memperkirakan biaya secara akurat, menguraikannya masalahnya, dan untuk menunjukkan dengan jelas di mana kita berada. Dalam jangka panjang, tujuan penulis adalah bergerak dengan lancer dari persyaratan fungsional hingga persyaratan sub-sistem atau komponen tertentu untuk individu, pemrogram yang tersebar secara geografis. Metodologi ini mencakup kedua ujung siklus hidup tersebut. Dia mencakup alat analitis dan dokumenter untuk insinyur perangkat lunak, dan manajemen proyek. Pernyataan yang jelas tentang hasil yang dicapai akan memperjelas harapan seluruh pemangku kepentingan, demikian pula tabel hasil hasil disajikan secara eksplisit di sini (lihat Tabel 1, Tabel 2, Tabel 4 dan Tabel 6). Jika ini Dokumen rekomendasi disetujui ini akan diperluas sehingga jelas apa yang dilakukan masing-masing individu fungsi pekerjaan yang menjadi tanggung jawabnya; dan alur kerja akan disusun untuk setiap fungsi kerja. Metodologi ini membedakan antara persyaratan yang sangat umum seperti “tujuan” dan “kebutuhan” fungsional secara keseluruhan, dan hal-hal yang lebih spesifik, barangbarang yang mungkin dapat diuji, yang penulis sebut “fitur” dan “persyaratan sistem”. Dengan demikian, persyaratan dapat dilihat secara hierarki, dari tujuan untuk persyaratan

Manajemen Proyek Perangkat Lunak 77 sistem (lihat Gambar:1) Metodologi mencakup kerangka kerja untuk menganalisis semua persyaratan tingkat. Persyaratan dipandang memiliki “atribut” yang melekat seperti manfaat, usaha, biaya, waktu, prioritas dll. Metodologi ini mewujudkan gagasan tersebut, dan menyajikan cara untuk mendokumentasikan semua atribut tersebut untuk setiap kebutuhan individu (lihat 5.3). Ini menunjukkan bagaimana atribut tersebut digunakan untuk proyek perencanaan. Dalam sebuah proyek besar akan ada sejumlah besar persyaratan dan solusi alternatif yang diusulkan, masingmasing berdampak pada persyaratan sistem terkait dan mengubah perkiraan biaya dan waktu. Metodologi ini mengelola “kumpulan persyaratan alternatif” (lihat 5.3.3 dan 5.3.4) dan dapat mengelola titik perjanjian antar sistem untuk meminimalkan gesekan dan scope creep (lihat 5.4). Sebuah alat pengembangan perangkat lunak, Rational RequisitePro disajikan, yang dapat membantu memvisualisasikan ketergantungan persyaratan, persyarat-an alternatif, dan atributnya, untuk membantu kedua proyek manajemen dan pengembang (lihat 3.1.3). “Kasus penggunaan” digunakan untuk menggambarkan persyaratan pada tingkat Fitur dan Persyaratan (lihat 4.2.5). Siklus pengembangan yang diusulkan bersifat berulang dan “didorong oleh fitur”, yang berupaya untuk diformalkan pendekatan prototipe cepat sehingga merupakan prosedur yang dapat dikelola secara efektif di seluruh sejumlah pusat pengembangan. Kasus penggunaan, dan pengembangan

78 Manajemen Proyek Perangkat Lunak berbasis fitur berulang, akan membantu pengembangan kolaboratif. Diakui bahwa dalam sistem kontrol yang terdekomposisi secara fungsional, infrastruktur perangkat lunak, dan arsitektur jaringan, juga akan menimbulkan persyaratan dan kendala penting tidak akan menjadi persyaratan fungsional seperti itu. Persyaratan tersebut juga perlu dianalisis dan dikelola dalam metodologi (lihat 4.3). Utilitas dan komponen perangkat lunak tujuan umum akan melakukannya dibangun untuk memenuhi persyaratan tersebut, yang akan mempercepat pengembangan perangkat lunak yangmemenuhi persyaratan fungsional. Metodologi ini tidak menerapkan desain Berorientasi Objek tetapi ia mendukungnya dan mendorong kerangka perangkat lunak berbasis komponen. Rekomendasi yang disebut “analisis sistem sistem” juga dipromosikan dalam metodologi ini. Hal ini mengatasi permasalahan sistem secara keseluruhan, dan “faktor manusia” di dalamnya. B. Metodology Secara Garis Besar Fitur utama metodologi ini dijelaskan di bagian ini. Khususnya sifat hierarki persyaratan jika dilihat dari siklus hidup suatu proyek, bahwa persyaratan tersebut saling terhubung dan bagaimana kita dapat mengelola hubungan tersebut, dan mengajukan proposal untuk pendekatan pengembangan berulang yang diformalkan.

Manajemen Proyek Perangkat Lunak 79 1. Hierarki Persyaratan Secara keseluruhan tujuan penulis adalah memberikan perangkat lunak yang baik tepat waktu dan sesuai anggaran, yang memecahkan akar permasalahan pengguna, dengan memenuhi kebutuhan nyata mereka. Oleh karena itu, “kebutuhan” ini harus diperoleh secara eksplisit, sehingga meminimalkan scope creep, dan juga cost creep, daripada hanya tersirat dalam persyaratan yang diperinci. Oleh karena itu, hierarki persyaratan berbunyi: a. Tujuan (Purpose). Pernyataan masalah. b. Kebutuhan (Needs). Ini adalah gambaran keseluruhan dari tujuan sistem perangkat lunak. Misalnya perangkat lunak tampilan BPM harus membantu pengguna “menelusuri data BPM waktu nyata”. Dari sana, proses persyaratan juga harus mencakup penerjemahan kebutuhan tersebut ke dalam beberapa rangkaian c. Fitur (Features) yang memuaskan kebutuhan, mirip dengan fitur yang mungkin diiklankan untuk perangkat lunak komersial d. Persyaratan (Requirements). Terakhir, fungsi perangkat lunak individual yang memenuhi kebutuhan dan fitur tersebut dirinci. Ini bersifat atomik dan dapat diuji. Proses persyaratan terintegrasi dengan proses desain sampai batas tertentu, dan terdapat penyempurnaan berulang di antara keduanya.

80 Manajemen Proyek Perangkat Lunak Gambar 1. Hierarki Persyaratan Kebutuhan nyata pengguna mungkin tersembunyi oleh keinginan penulis untuk menggunakan pengalaman sebelumnya dan teknologi yang sudah dikenal. Misalnya, penulis tidak memiliki persyaratan untuk memproduksi BPM Sampler, penulis memilikinya perlu menyediakan data per pulsa dari BPM. 2. Di Mana Kebutuhan, Fitur Dan Persyaratan Ditentukan Kebutuhan, Fitur dan Persyaratan konsekuensi dari setiap subsistem perangkat lunak dirinci dalam dokumen inti dari proses persyaratan untuk pengembangan (lihat di bawah). Dokumen inti tersebut adalah : a. Dokumen Visi: Ini akan mencakup Kebutuhan dan Fitur b. Spesifikasi Persyaratan 1) Model Domain: ini termasuk model Use Case, yang berisi Persyaratan Fungsional dalam deskripsi tekstual Use Case

Manajemen Proyek Perangkat Lunak 81 2) Model antarmuka pengguna, dan mungkin prototipe c. Spesifikasi tambahan: Ini mencakup Persyaratan Non-fungsional, seperti batasan sistem, batasan kinerja, batasan kolaborasi sub-sistem, dll. 3. Kemampuan Penelusuran (Traceability) Hubungan hierarkis antara kebutuhan, fitur, dan persyaratan, serta implikasi timbal baliknya, disebut “Kemampuan Penelusuran” dalam Proses Terpadu Rasional. Produk RequisitePro Rational dapat digunakan untuk mengelola dan melaporkan hubungan ketertelusuran. (lihat Gambar 2). Dengan cara ini setiap persyaratan dapat ditelusuri ke kebutuhan yang memotivasinya, dan dapat ditelusuri ke bawah hingga ke kasus uji yang dapat memverifikasi bahwa persyaratan tersebut telah dipenuhi.

82 Manajemen Proyek Perangkat Lunak Gambar 2. Matriks Ketertelusuran RequistePro yang menunjukkan hubungan, dalam hal ini, antara Fitur dan Kasus Penggunaan. Persyaratan yang ditandai dengan bilah diagonal menunjukkan persyaratan yang telah berubah, dan karena itu keterkaitannya harus diperiksa ulang oleh pembuatnya 4. Jenis dan Atribut Persyaratan RequisitePro dari Rational Software adalah alat untuk mengelola persyaratan. Ini mendefinisikan "persyaratan" dalam databasenya dengan cara yang sangat umum - sebagai pasangan nama/nilai. Misalnya, dua jenis persyaratan yang ditetapkan oleh RequisitePro diberi nama “FEAT” untuk Fitur, dan UC untuk Kasus Penggunaan. Gambar 2 menunjukkan contoh ketertelusuran antara dua atribut ini, “FEAT” dan “UC”, untuk proyek hipotetis. Nilai dari persyaratan ini adalah teks dalam dokumen yang mendefinisikannya.

Manajemen Proyek Perangkat Lunak 83 Tipe fitur lainnya dapat ditemukan oleh analis. Misalnya seseorang dapat menambahkan tipe bernama DBENTITY untuk persyaratan entitas database. Beberapa contoh nyata penggunaan kemampuan untuk melacak dan mereferensikan objek sesuai persyaratan diberikan di bawah ini. Masing-masing akan diimplementasikan sebagai jenis persyaratan RequisitePro. a. Entitas Basis Data dan perangkat Kontrol. Kami dapat melacak Fitur mana yang memerlukan entitas db mana b. Jaringan (jaringan mana yang membawa kebutuhan proyek mana misalnya) c. Panel, atau objek GUI (panel mana yang mengimplementasikan persyaratan tertentu) d. Glosarium. RequisitePro hadir dengan jenis persyaratan GLOSS untuk mengaitkan definisi glosarium dengan persyaratan lainnya Setiap jenis menjelaskan persyaratan berdasarkan atributnya, seperti Biaya, Prioritas, Status, AssignedTo, dll. RequisitePro juga memungkinkan kita dengan mudah menambahkan atribut ke daftar yang dapat dikelola. Jadi RequistePro dapat digunakan untuk melacak berbagai informasi yang relevan dengan suatu proyek. Selain itu, dukungan untuk desain, dokumentasi pengguna, dan komunikasi kolaboratif didukung oleh fungsi ketertelusuran dan atribut (lihat bagian 5). Tentu saja tidak semua persyaratan “menelusuri” suatu kebutuhan. Misalnya, poin perjanjian dan batas

84 Manajemen Proyek Perangkat Lunak sistem merupakan persyaratan mutlak. Itu juga dapat dikelola oleh RequisitePro. 5. Pendekatan Iteratif Metodologi yang kami usulkan bersifat iteratif dan berbasis fitur. Berbeda dengan pendekatan Tradisional, atau “Waterfall” di mana persyaratan ditentukan secara hati-hati sebelum melanjutkan ke desain, dan desain diselesaikan sebelum pengkodean, implementasi, dan pengujian, pendekatan kami akan memungkinkan perangkat lunak dikembangkan secara bertahap. Namun, berbeda dengan pendekatan Rapid Prototyping serupa, yang mana fitur-fitur seharusnya ditemukan dan dikodekan dengan cara yang kreatif, pendekatan ini menggunakan pedoman yang cukup ketat untuk penyampaian, alur kerja, dan pengawasan. Untuk tujuan ini, pendekatan berulang terstruktur ini dimaksudkan untuk: a. Menyelesaikan masalah sulit dan masalah kritis kolaborasi sistem sejak awal b. Memperbaiki risiko kelebihan proyek yang melekat pada waktu tunggu yang sangat lama, dengan menetapkan tujuan jangka pendek c. Bantuan dalam integrasi sistem, karena titik di mana satu subsistem siap melayani subsistem lainnya dapat dimajukan, daripada menunggu sampai keduanya selesai d. Izinkan dan manfaatkan umpan balik pengguna sejak awal e. Meningkatkan pengukuran kemajuan f. Izinkan penerapan sistem sebagian

Manajemen Proyek Perangkat Lunak 85 Model berulang ini didasarkan pada Proses Terpadu Rasional: Gambar 3. Siklus Hidup Iteratif. Beberapa bagian dari semua tahap pengembangan sistem yang biasa dilakukan di setiap tahap 6. Didukung Fitur Sebagai modifikasi terhadap pendekatan ini, pendekatan kami akan membuat iterasi dalam setiap fase, dengan durasi tetap. Selain itu, fitur yang dimaksudkan untuk dikirimkan pada akhir setiap iterasi adalah tetap. Jadi, daripada membuat jumlah fitur dan tenggat waktu keseluruhan tetap, seperti dalam pendekatan pengembangan sistem tradisional, dalam pendekatan ini jumlah fitur yang harus dikerjakan dalam setiap iterasi bervariasi, namun waktu untuk mencapai setiap pencapaian tetap. Hal ini untuk membantu pengelolaan kolaborasi terdistribusi (sehingga semua orang mengetahui titik jalan berikutnya, yang mungkin mencakup integrasi sistem)

86 Manajemen Proyek Perangkat Lunak dan untuk mendapatkan tujuan dan pencapaian dari setiap rangkaian fitur yang dikirimkan. Kumpulan fitur dapat dikelompokkan ke dalam “kumpulan fitur” yang diinginkan untuk setiap siklus rilis. Kemajuan setiap rangkaian fitur dapat dilacak, bukan setiap kebutuhan individu, sementara pada saat yang sama kita dapat duduk santai dan mengevaluasi kembali pendekatan kita tanpa menunggu hingga keseluruhan sistem selesai sebelum kita memutuskan untuk membuangnya dan beralih ke sistem. pub. Alat “ketertelusuran” yang dibahas di atas membantu kita memilih rangkaian fitur yang konsisten untuk diterapkan pada setiap iterasi karena saling ketergantungannya terdokumentasi. Estimasi biaya juga mendapat manfaat dari pengelolaan setiap siklus pengembangan sebagai serangkaian fitur, lihat 5.3 Estimasi Biaya dan Manfaat C. Persyaratan dan Analisis Pengembangan Bagian ini menjelaskan hasil utama analisis persyaratan yang merupakan tanggung jawab tim pengembangan. Tabel 4 mencantumkan kiriman tersebut. Di sini kami menjelaskan Dokumen Visi, Persyaratan Fungsional (termasuk pemodelan Use Case dan pemodelan Antarmuka Pengguna), dan spesifikasi Tambahan. Juga diberikan beberapa alat dan teknik khusus untuk melakukan analisis. Item berwarna abuabu tidak dibahas lebih lanjut. Hal ini akan diuraikan dalam pedoman desain.

Manajemen Proyek Perangkat Lunak 87 Tabel 4. kiriman untuk Setiap Subsistem Kategori : Visi ; Sub Kategori : Dokumen Deskripsi : Ringkasan keseluruhan fitur yang diinginkan Penulis Pelaksanaan Isi Pengguna Engineer and Physicist users, Analyst Inception Kebutuhan dan Fitur yang diinginkan. Garis besar sistem alternatif. Kesulitan teknis yang dicatat Uses, Management, Architects, Analysts, UC specifiers, Designers, Testers Kategori : Persyaratan Fungsional ; Sub Kategori : Model Domain Deskripsi : Use Case; Model: Antarmuka ; Entity-relationship diagrams; Algorithms Analisi Fase Awal dan Elaborasi Aktor,Scenarios, Preconditions, Postconditions, Constraints, And nonfunctionalSpec Tinjauan desain, untuk memvalidasi pemahaman. Penulis Dokumentasi Penguji Sub Kategori : Model Pengguna Interface

88 Manajemen Proyek Perangkat Lunak Deskripsi : Maket Pengguna Interface Pengembang Awal dan Elaborasi Prototype GUI Designer & Pengguna Sub Kategori : Paket Use Case, ERD, dan Subsystem Deskripsi : Analis, Penentuan Kasus, Arsitek Fase Awal & Elaborasi Nama paket, Kumpulan UC, termasuk Aktor, objek, hubungan, misalnya : <<uses>>, <<extends>> Arsitek, untuk memvalidasi kesesuaian subsistem bersama. Desainer, Pengembang, Manajemen