Manajemen Proyek Perangkat Lunak

Manajemen Proyek Perangkat Lunak 89 1. Dokumen Visi Gambar 4. Posisi Dokumen Visi dalam hierarki Seperti namanya, dokumen visi akan fokus pada tujuan sistem. Hal ini juga harus mencakup penjelasan mengapa sistem tersebut diperlukan, sehingga pemangku kepentingan dapat meninjaunya secara memadai. Perannya adalah untuk mengkomunikasikan keinginan antara manajemen, pengguna dan pengembang baik di SLAC maupun dalam kolaborasi perangkat lunak. Templat untuk Dokumen Visi akan ditentukan. Secara garis besar memuat: a. Tujuan-pernyataan dasar dari maksud sistem. Jika memungkinkan, hal ini tidak boleh diungkapkan dalam kaitannya dengan kebutuhan sistem lain, melainkan dalam kaitannya dengan kebutuhan

90 Manajemen Proyek Perangkat Lunak nyata pengguna. Teori Sistem Umum menyebutnya sebagai “Definisi Root”, dan menekankan bahwa hal ini harus diungkapkan secara independen dari tradisi atau sistem yang ada, bias sejarah, atau tekanan buatan dari persyaratan sistem lain [Bertalanaffy, 1968]. Misalnya, pertimbangan harus diberikan apakah suatu sistem diminta hanya karena SLC atau PEPII menjadikan sistem ini sebagai komponen dalam sistem kendali mereka, dan bukan sebagai persyaratan inti kendali NLC. RUP menyertakan frase template untuk ini sebagai “Position Statement”. b. Tujuan dan sasaran c. Referensi ke dokumen persyaratan Fungsional dan Non-fungsional, pernyataan visi subsistem terkait, RequisitePro db, dokumen Ukuran dan Kinerja, Analisis Batas Sistem, dan Analisis Domain. d. Kebutuhan Pengguna. Ini harus dirinci, dengan kasus penggunaan pendukung e. Garis besar Sistem Alternatif f. Target Peserta dari sistem. Deskripsi pengguna atau daftar subsistem klien dan server yang akan berinteraksi dengan subsistem ini. Hal ini akan menjadi dasar bagi para aktor dalam Use Case Model g. Lingkungan, platform, dan batasan lainnya, seperti kesesuaian sistem ini dengan sistem lain, infrastruktur data, dan arsitektur. h. Kesulitan teknis yang dicatat i. Catatan fitur dan ide masa depan

Manajemen Proyek Perangkat Lunak 91 j. Persyaratan lain, seperti standar yang berlaku, persyaratan portabilitas dan ekstensibilitas, dll. Batasan kinerja dicantumkan secara terpisah dalam Spesifikasi Tambahan dan Spesifikasi Ukuran dan Kinerja (lihat dan Tabel 1). 2. Persyaratan Fungsional Persyaratan fungsional terdiri dari Model Domain (Kasus Penggunaan dan deskripsi domain masalah) dan Model Antarmuka Pengguna. Gambar 5. Dimana Persyaratan Fungsional sesuai dengan hierarki inti penyampaian

92 Manajemen Proyek Perangkat Lunak 3. Pemodelan Domain Dengan Kasus Penggunaan Sebuah “Use Case” secara harfiah menggambarkan satu kasus penggunaan sistem. Artinya, ini membuat satu contoh interaksi antara sistem dan pengguna menjadi eksplisit (atau interaksi tersebut mungkin melibatkan lebih dari satu pengguna). Use case adalah aliran kejadian antara sistem dan pengguna. Secara agak sombong, literatur mengatakan bahwa biasanya Use Case diartikan sebagai “interaksi yang mengarah pada hasil nilai yang dapat diamati oleh pengguna”. Unified Modeling Language (UML), dimana Use Case diambil, menyebut pengguna sebagai aktor. Aktornya belum tentu seorang individu, mungkin merupakan sub-sistem lain. Selain itu, seorang aktor dibedakan dari sekedar pengguna atau sub-sistem di mana seorang aktor menentukan satu peran. Setiap proses yang harus dilalui seorang aktor untuk memenuhi satu peran mendefinisikan satu Use Case dari sistem. Jadi misalnya Kasus Penggunaan bukanlah sebuah contoh dari menekan satu tombol, melainkan satu Kasus Penggunaan mungkin menjelaskan pengaturan dan melihat plot orbit BPM. Setiap kasus penggunaan adalah serangkaian tindakan dan tindakan tersebut harus bersifat atomik (baik dilakukan secara keseluruhan atau tidak dilakukan). Kasus Penggunaan mungkin digunakan untuk menentukan persyaratan dan proses pada tingkat yang sangat tinggi, seperti dalam Pemodelan Bisnis (yang tidak dibahas di sini), pada tahap mendeskripsikan

Manajemen Proyek Perangkat Lunak 93 Kebutuhan dan Fitur, pada tahap spesifikasi Persyaratan, dan pada tahap Desain . Di setiap level, diperlukan tingkat detail yang berbeda, dan akan lebih banyak aktor yang ikut bermain. Dalam contoh plot orbit BPM, jika ini adalah Kasus Penggunaan pada tahap perolehan Persyaratan, hanya akan ada satu aktor - “Pengguna Sistem Kontrol”. Pada tahap Desain Use Case ini akan melibatkan satu atau lebih aktor untuk pengambilan datanya juga. Di sini kami berkonsentrasi pada Kasus Penggunaan untuk Persyaratan. Tabel 5. Dimana penggunaan use case digunakan, dan pada tingkat detail apa Jenis Persyaratan Detail Use Case Tujuan (Purpose) penggunaan use case tidak digunakan pada tahap ini Kebutuhan (Needs) penggunaan use case pada “model bisnis” tingkat tinggi. Penerapan penggunaan use case ini bersifat opsional Fitur (Features) Penggunaan use case diberi nama dan diuraikan (deskripsi paragraf singkat); skenario tertulis (lihat Gambar 7); aktor utama diidentifikasi Persyaratan Deskripsi penggunaan

94 Manajemen Proyek Perangkat Lunak (Requirements) use case dirinci (lihat Gambar 8). Setiap penggunaan use case diberikan dalam konteks yang lain, dengan <<uses>> dan <<extends>> jika diperlukan. Penggunaan Use Case biasanya tidak disusun secara hierarkis! Hal ini terutama berlaku pada Kasus Penggunaan yang digunakan untuk menentukan persyaratan, bukan desain. Sebuah Use Case mungkin merupakan deskripsi yang cukup panjang dari sebuah interaksi, dan melibatkan dialog bolak-balik dengan aktor. Ini memberi tahu Anda bagaimana aktor berinteraksi dengan sistem dan mencakup bagaimana sistem merespons. Model Use Case dari suatu sistem adalah seluruh aktor dan berbagai use case. Pada prinsipnya kumpulan kasus penggunaan yang lengkap untuk suatu sistem membentuk deskripsi lengkap tentang kebutuhan fungsional sistem. Namun, hal itu mungkin terlalu ideal bagi kami. Penggunaan Use Case dijelaskan secara menyeluruh dalam literatur. Di sini akan dijelaskan beberapa rekomendasi umum.

Manajemen Proyek Perangkat Lunak 95 4. Identifikasi Use Case Secara umum, mengembangkan use case tidaklah sulit, tetapi memastikan Anda memiliki semua use case itu sulit. Literatur memperingatkan bahwa penggunaan use case terkadang begitu jelas sehingga diabaikan. Sumber untuk mengembangkan penggunaan use case adalah: a. Pakar domain. b. Perangkat lunak PEPII dan SLC yang ada (tentunya berhati-hati agar tidak mereproduksi perilaku yang tidak optimal untuk NLC). c. Pengguna, operator d. Analisis partisipatif. Untuk perangkat lunak tingkat pengguna, sangat berguna untuk duduk di ruang kontrol untuk melihat secara langsung apa yang telah dilakukan, apa yang memerlukan waktu, apa yang dapat diotomatisasi, dll 5. Identifikasi Actor Tentu saja langkah dasar untuk menemukan aktornya adalah dengan mempertimbangkan bagaimana sistem tersebut akan digunakan. Tips lain dari literatur adalah: a. Minta pakar domain untuk menentukan siapa yang melakukan tugas utama sistem, dan tugas apa yang mereka lakukan. b. Siapa yang akan melaksanakan tugas sekunder dan tugas pemeliharaan?

96 Manajemen Proyek Perangkat Lunak c. Sistem lain mana yang memerlukan informasi dari sistem ini. Ke sistem lain mana sistem ini mengirimkan informasi? d. Bagaimana sistem diinisialisasi. Bagaimana cara menghentikannya? e. Apakah ada urutan log on atau log off? Dokumentasikan nama para aktor dan hati-hati dalam membedakan aktor-aktor yang memiliki nama atau peran serupa. Misalnya kita akan memiliki sejumlah jenis pengguna ruang kendali: “operator”, “EOIC”, “commissioning physicist”, “machine development physicist”, “Deputi Program”, dll. Kita harus membuat daftar ini dan menggunakannya secara konsisten . 6. Membangun Penggunaan Use Case Membangun use case adalah proses berulang. Literatur memperingatkan pengembang use case untuk tidak mencoba membuat use case terlalu tepat terlalu dini – cukup jelaskan use case tersebut secara garis besar, terutama pada tahap persyaratan. Selain itu, pada awalnya jangan khawatir tentang kasus penggunaan yang tumpang tindih di antara subsistem yang berbeda setelah dijelaskan, kami dapat menormalkannya nanti. Ingat juga pada tahap persyaratan, jangan berusaha keras menjadikannya hierarkis. Setiap kasus penggunaan adalah untuk menetapkan nilai yang berguna. Saat mencoba memutuskan apakah suatu proses melibatkan dua kasus penggunaan atau satu, lihatlah apakah satu atau

Manajemen Proyek Perangkat Lunak 97 dua item informasi berguna diinginkan oleh aktor sebagai hasil akhir. Pertimbangan ini muncul di mana-mana dalam literatur: a. Tugas apa yang aktor ingin sistem lakukan? a. Informasi apa yang harus disediakan oleh aktor ke dalam sistem? b. Informasi apa yang harus disediakan oleh sistem kepada aktor? c. Apakah ada kejadian yang harus diinformasikan oleh aktor ke sistem? d. Apakah ada peristiwa yang harus diberitahukan oleh sistem kepada aktor? e. Bagaimana aktor memulai transaksi, atau mematikan sistem? f. Pikirkan tentang objek dunia nyata dan atributnya: Apakah ingin menyediakan cara untuk “Menampilkan semua BPM horizontal?”; apakah ingin "Meminimalkan eksitasi semua korektor?"

98 Manajemen Proyek Perangkat Lunak

Manajemen Proyek Perangkat Lunak 99 Manajemen Konfigurasi Perangkat Lunak Evi Yulianti, S.Kom.,M.S.I BAB 8

100 Manajemen Proyek Perangkat Lunak onfigurasi adalah proses mengatur dan mengelola berbagai aspek dari perangkat lunak yang dikembangkan oleh tim pemrograman. Tujuannya adalah untuk memaksimalkan produktivitas tim dengan meminimalkan kesalahan. Ini melibatkan mengidentifikasi, mengorganisir, dan mengendalikan modifikasi perangkat lunak agar sesuai dengan kebutuhan dan tujuan proyek. A. Manajemen Konfigurasi Perangkat Lunak Manajemen Konfigurasi Perangkat Lunak (Software Configuration Management [SCM]) adalah cara untuk mengatur dan mengelola perangkat lunak sehingga tim pengembangan dapat bekerja dengan lebih efisien dan menghindari kesalahan yang tidak diinginkan. SCM sebagai panduan atau sistem yang membantu tim agar tetap terorganisir dan selaras saat membuat, menguji, dan merilis perangkat lunak. Kegiatan-kegiatan dalam SCM dikembangkan dengan tujuan: 1. Mengenali setiap perubahan; 2. Menjalankan pengendalian perubahan dengan cermat; 3. Menjamin implementasi perubahan secara akurat; 4. Menyampaikan laporan perubahan kepada pihak terkait. Ouput dari proses perangkat lunak merujuk pada hasil atau hasil akhir dari seluruh proses pengembangan perangkat lunak. Ouput ini dapat dibagi menjadi tiga kategori : K

Manajemen Proyek Perangkat Lunak 101 1. Program Komputer: Ini mencakup kode sumber dan berbagai bentuk program yang dapat dieksekusi, seperti aplikasi desktop, aplikasi seluler, perangkat lunak server, dan sebagainya. 2. Produk Kerja yang Menggambarkan Program Komputer: Ini mencakup semua dokumen, diagram, dan artefak lainnya yang digunakan untuk menjelaskan program komputer. 3. Data atau Isi: Ini mencakup semua data atau informasi yang terkandung dalam program atau digunakan oleh program. B. Konfigurasi perangkat lunak Konfigurasi perangkat lunak adalah item dari semua informasi yang dihasilkan selama proses pengembangan perangkat lunak secara keseluruhan. Ketika proses pengembangan perangkat lunak (software configuration item [SCI]) berlangsung, sebuah struktur hierarki konfigurasi perangkat lunak dibentuk. Empat sumber utama perubahan yang dapat memengaruhi proyek pengembangan perangkat lunak: 1. Bisnis baru atau kondisi pasar: Perubahan dalam kebutuhan produk atau perubahan aturan bisnis yang diakibatkan oleh perubahan di pasar atau dalam strategi bisnis perusahaan. 2. Pemangku kepentingan baru: Permintaan perubahan yang berasal dari pihak-pihak yang terlibat dalam proyek.

102 Manajemen Proyek Perangkat Lunak 3. Reorganisasi atau perampingan bisnis: Perubahan dalam prioritas proyek atau struktur tim pengembangan perangkat lunak yang terjadi sebagai hasil dari restrukturisasi atau perampingan bisnis. 4. Kendala anggaran atau penjadwalan: Perubahan dalam anggaran atau jadwal yang dapat mempengaruhi definisi ulang sistem atau produk. C. Skenario SCM Dalam skenario operasional manajemen perubahan (Change Management [CM]) ini, perusahaan software "TechSolutions" berada dalam proses pengembangan dan pemeliharaan produk perangkat lunak mereka. Ada beberapa pihak yang terlibat dalam manajemen perubahan ini, termasuk manajer proyek, manajer konfigurasi, para rekayasawan perangkat lunak, dan konsumen produk. Manajer proyek bertanggung jawab atas koordinasi tim pengembangan perangkat lunak. Tugasnya mencakup perencanaan, pengawasan, dan pengelolaan sumber daya untuk memastikan proyek berjalan sesuai jadwal dan anggaran. Manajer proyek juga berperan penting dalam memfasilitasi komunikasi antara tim internal dan eksternal, termasuk konsumen. Manajer konfigurasi memiliki tanggung jawab utama terkait prosedur CM dan kebijakan perusahaan. Mereka bertugas untuk memastikan bahwa prosedur dan kebijakan yang berkaitan dengan pembuatan, perubahan, dan pengujian kode dipatuhi oleh seluruh tim pengembangan. Hal ini termasuk mengelola versi kode, dokumentasi

Manajemen Proyek Perangkat Lunak 103 perubahan, dan mengelola akses terhadap informasi proyek. Para rekayasawan perangkat lunak adalah individu atau tim yang bertanggung jawab atas pengembangan dan pemeliharaan produk perangkat lunak. Tugas mereka termasuk menulis kode, menguji produk, dan melakukan perbaikan atau perubahan yang diperlukan sesuai dengan kebijakan dan prosedur yang ditetapkan oleh manajer konfigurasi. Konsumen adalah pihak yang menggunakan produk perangkat lunak yang dikembangkan oleh perusahaan. Mereka dapat memberikan umpan balik, permintaan fitur, atau melaporkan bug kepada tim pengembangan. Konsumen memainkan peran penting dalam siklus pengembangan produk dengan memberikan wawasan yang berharga untuk memperbaiki dan meningkatkan produk. Tujuan manajer konfigurasi dalam skenario ini adalah memastikan kepatuhan terhadap prosedur dan kebijakan yang ditetapkan dalam manajemen perubahan. Mereka bertanggung jawab untuk memastikan bahwa seluruh tim pengembangan mengikuti proses yang ditetapkan dalam membuat, mengubah, dan menguji kode. Selain itu, mereka juga bertugas untuk memastikan bahwa informasi terkait proyek tersedia dan dapat diakses oleh seluruh tim yang terlibat. Dengan menjaga disiplin dan konsistensi dalam manajemen perubahan, manajer konfigurasi membuka peluang bagi peningkatan efisiensi dan kualitas dalam pengembangan produk perangkat lunak.

104 Manajemen Proyek Perangkat Lunak D. Elemen Sistem Manajemen Konfigurasi Dalam makalahnya tentang manajemen konfigurasi perangkat lunak, Susan Dart menetapkan empat unsur kunci yang harus ada dalam pengembangan sistem manajemen konfigurasi. setiap elemen berdasarkan deskripsi yang diberikan dalam pertanyaan: 1. Elemen-elemen Komponen: Ini adalah alat-alat atau komponen-komponen dalam sistem manajemen berkas yang memungkinkan akses dan manajemen perangkat lunak masing-masing item konfigurasi. 2. Elemen-elemen Proses: Ini adalah serangkaian tindakan dan tugas yang menentukan pendekatan efektif untuk mengubah manajemen untuk semua konstituen yang terlibat dalam manajemen, teknik, dan penggunaan perangkat lunak komputer. 3. Elemen-elemen Konstruksi: Ini adalah alat-alat atau komponen-komponen yang mengotomatisasi pengembangan perangkat lunak untuk memastikan bahwa kumpulan komponen-komponen yang telah divalidasi telah dirakit. 4. Elemen-elemen Manusia: Ini adalah alat-alat dan fitur proses yang digunakan oleh tim perangkat lunak untuk menerapkan SMK yang efektif. E. Baseline Menurut IEEE Std 610.12-1990, Baseline dalam manajemen konfigurasi perangkat lunak adalah suatu konsep yang membantu dalam mengatur perubahan agar

Manajemen Proyek Perangkat Lunak 105 tidak mengganggu perubahan yang sesuai. Baseline SCI (Software Configuration Item) adalah versi dari perangkat lunak atau item konfigurasi lainnya yang telah disetujui secara resmi dan digunakan sebagai dasar untuk pengembangan selanjutnya. Baseline SCI mencakup spesifikasi atau produk yang telah ditinjau dan disetujui, serta hanya dapat diubah melalui prosedur pengendalian perubahan yang telah ditetapkan. Tujuan dari Baseline SCI adalah untuk memastikan konsistensi, kestabilan, dan dokumentasi yang tepat dalam pengelolaan konfigurasi perangkat lunak. Gambar 1. Baseline SCI dan Basis Data Proyek Basis Data Proyek adalah koleksi data yang digunakan dalam proyek untuk menyimpan informasi terkait dengan manajemen proyek, seperti jadwal, anggaran, sumber daya, dan dokumentasi proyek lainnya. Basis Data Proyek menyediakan akses terpusat dan terkontrol terhadap informasi proyek, memungkinkan berbagi data antara

106 Manajemen Proyek Perangkat Lunak anggota tim proyek dan memfasilitasi pengambilan keputusan yang lebih baik. F. Pokok-Pokok Konfigurasi Perangkat Lunak Konfigurasi Objek-Objek adalah pendekatan dalam pengelolaan konfigurasi perangkat lunak yang memusatkan perhatian pada objek-objek individu yang terlibat dalam pengembangan perangkat lunak. Setiap objek dalam perangkat lunak, seperti kelas, modul, atau komponen, diidentifikasi, didokumentasikan, dan dikelola secara terpisah. Pendekatan ini memungkinkan kontrol yang lebih baik terhadap evolusi dan interaksi antar objek dalam perangkat lunak, serta memfasilitasi pengembangan iteratif dan penggunaan kembali yang efisien. Dengan pendekatan Konfigurasi Objek-Objek, setiap objek memiliki atributnya sendiri, termasuk versi, status, dan riwayat perubahan. Perubahan pada objek tertentu dapat dilacak secara terpisah, memungkinkan tim pengembangan untuk memahami dampak perubahan tersebut pada sistem secara keseluruhan.

Manajemen Proyek Perangkat Lunak 107 Gambar 2. Konfigurasi Objek-Objek Di bawah ini adalah penjelasan dari gambar 2. Konfigurasi objek-objek, mengenai masing-masing objek: 1 DesignSpecification: Objek ini berisi spesifikasi desain perangkat lunak yang mencakup arsitektur sistem, struktur komponen, dan hubungan antara komponenkomponen tersebut. 2 DataModel: Objek ini merupakan representasi formal dari struktur data yang digunakan oleh perangkat lunak. DataModel menggambarkan entitas-entitas, atribut-atribut, dan hubungan antar entitas dalam sistem.

108 Manajemen Proyek Perangkat Lunak 3 ComponentN: Objek ini mewakili komponenkomponen perangkat lunak yang dapat berupa kelas, modul, atau bagian-bagian lain dari sistem. 4 SourceCode: Objek ini berisi kode sumber perangkat lunak yang ditulis dalam bahasa pemrograman tertentu. 5 TestSpecification: Objek ini memuat spesifikasi pengujian yang harus dilakukan terhadap perangkat lunak. G. Repositori SCM Repositori SCM (Software Configuration Management) adalah sebuah sistem yang berfungsi sebagai tempat penyimpanan sentral untuk mengelola dan melacak semua versi dari item konfigurasi perangkat lunak (SCI), seperti kode sumber, dokumen spesifikasi, dan konfigurasi lainnya. SCI disimpan dalam basis data proyek yang juga dikenal sebagai repositori SCM. H. Fitur-Fitur dan Isi Umum Cara terbaik untuk memahami fitur dan isi sebuah repositori adalah dengan pendekatan yang sistematis dan terarah. Langkah-langkah yang dapat diambil termasuk menelusuri dokumentasi resmi untuk mendapatkan gambaran umum tentang fitur-fitur utama, cara penggunaan, dan konfigurasi repositori. Selanjutnya, pelajari model data yang disimpan dalam repositori, termasuk struktur data, hubungan antar data, dan representasi objek-objek yang disimpan. izin akses.

Manajemen Proyek Perangkat Lunak 109 Fitur-fitur dan isi umum dari sebuah repositori yang tangguh dapat mencakup hal-hal berikut: 1. Layanan dari Sistem Manajemen Basis Data: Repositori ini dapat memanfaatkan layanan dari sistem manajemen basis data canggih, seperti penyimpanan data yang aman, pemulihan bencana, dan kinerja tinggi. 2. Layanan Spesifik bagi Lingkungan Rekayasa Perangkat Lunak: Repositori harus menyediakan layanan yang khusus bagi lingkungan rekayasa perangkat lunak, seperti manajemen versi, kontrol konfigurasi, dan pelacakan perubahan. 3. Integrasi dengan Fungsi Proses Manajemen: Repositori harus terintegrasi dengan fungsi proses manajemen proyek, seperti perencanaan, pelacakan tugas, dan pelaporan. 4. Dukungan Aturan Khusus SCM: Repositori harus mendukung aturan-aturan khusus yang mengatur fungsi SCM, seperti pembuatan dan persetujuan cabang kode, penjadwalan pengiriman, dan pengendalian versi. 5. Antarmuka dengan Perkakas Rekayasa Perangkat Lunak Lainnya: Repositori harus menyediakan antarmuka untuk berbagai perkakas rekayasa perangkat lunak lainnya, seperti IDE (Integrated Development Environment), sistem manajemen tugas, dan alat pengujian.

110 Manajemen Proyek Perangkat Lunak 6. Penyimpanan Objek Data Canggih: Repositori harus mampu menyimpan objek data canggih, seperti kode sumber, dokumen, gambar, dan biner lainnya, dengan dukungan untuk manajemen versi dan kontrol konfigurasi. I. Fitur-Fitur SCM Fitur-fitur SCM (Software Configuration Management) adalah sejumlah fungsi yang diperlukan untuk mendukung manajemen konfigurasi perangkat lunak secara efektif. Gambar 3. Isi Repositori

Manajemen Proyek Perangkat Lunak 111 Berikut adalah penjelasan mengenai beberapa fitur utama SCM: 1. Pembuatan Versi: Repositori harus mampu menyimpan semua versi dari kode sumber atau elemen-elemen konfigurasi lainnya. 2. Pelacakan Ketergantungan dan Manajemen Perubahan: Repositori SCM mengelola hubungan antara elemenelemen data yang tersimpan di dalamnya, seperti kode sumber, dokumen spesifikasi, dan artefak lainnya. 3. Pelacakan Kebutuhan: SCM juga dapat menyediakan fitur untuk melacak kebutuhan dari awal hingga akhir siklus pengembangan. 4. Manajemen Konfigurasi: SCM mengawasi serangkaian konfigurasi yang merupakan tonggak penting proyek atau rilis-rilis produksi 5. Audit Trails: Repositori SCM menetapkan informasi tambahan tentang kapan, mengapa, dan oleh siapa perubahan berlangsung. J. Proses SCM Proses SCM (Software Configuration Management) merupakan serangkaian langkah dan praktik yang dirancang untuk mencapai tujuan-tujuan manajemen konfigurasi perangkat lunak dengan efektif. Berikut adalah penjelasan mengenai beberapa tujuan utama SCM : 1. Mengidentifikasi Semua Item Konfigurasi: Tujuan ini mencakup pengidentifikasian dan dokumentasi semua elemen atau item yang secara kolektif mendefinisikan konfigurasi perangkat lunak.

112 Manajemen Proyek Perangkat Lunak 2. Mengelola Perubahan: Proses SCM bertujuan untuk mengelola perubahan pada satu atau beberapa item konfigurasi secara terkontrol. 3. Memfasilitasi Pembangunan Berbagai Versi Aplikasi: SCM memungkinkan pembangunan dan penyebaran berbagai versi dari aplikasi dengan cara yang terstruktur dan terkendali. 4. Menjaga Kualitas Perangkat Lunak: Salah satu tujuan utama SCM adalah memastikan bahwa kualitas perangkat lunak tetap dipertahankan sepanjang waktu, bahkan saat konfigurasi dikembangkan atau berubah. Gambar 4. Lapisan-Lapisan Proses SCM

Manajemen Proyek Perangkat Lunak 113 K. Identifikasi objek dalam konfigurasi perangkat lunak Identifikasi objek dalam konfigurasi perangkat lunak adalah proses memberi nama dan mengorganisasi unit informasi yang terlibat dalam analisis, perancangan, penulisan kode, atau pengujian. Terdapat dua jenis objek dalam identifikasi ini: 1. Objek Dasar: Objek dasar merupakan unit informasi yang dibuat selama proses pengembangan perangkat lunak, seperti analisis kebutuhan, perancangan sistem, penulisan kode, atau pengujian 2. Objek Agregat: Objek agregat adalah kumpulan dari objek dasar dan/atau objek agregat lainnya. Objek agregat dapat mencakup berbagai jenis informasi yang terkait dalam konteks tertentu, seperti kelompok dokumen spesifikasi untuk suatu modul atau subsistem. Identifikasi objek konfigurasi juga dapat dilihat sebagai hubungan yang ada antara objek-objek yang memiliki nama. Misalnya, hubungan antara model kelas dan spesifikasi kebutuhan dapat direpresentasikan dengan notasi sederhana, seperti yang terlihat dalam contoh berikut: Class diagram <part-of> requirements model; Requirements model <part-of> requirements specification;

114 Manajemen Proyek Perangkat Lunak Selain itu, hubungan lintas struktural antara objekobjek juga dapat dijelaskan dengan notasi, seperti yang terlihat dalam contoh berikut: L. Kontrol Versi Kontrol versi adalah proses manajemen yang bertujuan untuk mengatur dan melacak evolusi dari suatu perangkat lunak atau proyek pengembangan perangkat lunak. Suatu sistem kontrol versi umumnya memiliki empat kemampuan utama: Contoh penerapan kontrol versi dengan menggunakan sistem kontrol versi (VCS - Version Control System) seperti Git: 1. Basis Data Proyek (Repositori): Tim pengembang perangkat lunak menggunakan repositori Git untuk menyimpan semua objek konfigurasi yang relevan, seperti kode sumber (file-file .java, .html, .css), dokumen spesifikasi (file-file .docx, .pdf), dan file-file lain yang terlibat dalam pengembangan aplikasi. 2. Manajemen Versi: Ketika pengembang membuat perubahan pada kode sumber, Git menyimpan semua versi dari file-file tersebut. 3. Pembangunan Versi: Setelah pengembang merasa cukup dengan perubahan yang telah dilakukan, mereka dapat menggunakan Git untuk membangun versi spesifik dari perangkat lunak. DataModel <interrelated> DataFlowModel DataModel <interrelated> TestCaseClassM

Manajemen Proyek Perangkat Lunak 115 4. Contoh penerapan pendekatan pemodelan sistem kontrol versi: a. Pola Baku (Template): Tim pengembang mengadopsi pola baku dalam struktur aplikasi. b. Aturan Konstruksi: Tim pengembang menerapkan aturan konstruksi yang mengatur cara penulisan kode sumber. c. Aturan Verifikasi: Tim pengembang menetapkan aturan verifikasi yang mencakup proses dan kriteria verifikasi yang harus dipatuhi dalam pengembangan perangkat lunak. M. Pengendalian Perubahan Pengendalian perubahan adalah proses manajemen yang bertujuan untuk mengontrol dan mengatur perubahan dalam proyek perangkat lunak, khususnya proyek-proyek besar di mana perubahan yang tidak terkendali dapat menyebabkan kekacauan. Proses ini menggabungkan prosedur manusia dan perkakas otomatis untuk memberikan mekanisme dalam mengontrol perubahan. Dalam pengendalian perubahan, permintaan perubahan disampaikan dan dievaluasi untuk menilai aspek teknis, potensi efek samping, dampak keseluruhan pada objek konfigurasi lainnya, fungsi-fungsi sistem, dan biaya proyeksi perubahan. Hasil evaluasi disajikan sebagai laporan perubahan yang digunakan oleh badan pengawas perubahan (change control authority - CCA), yang merupakan individu atau kelompok yang membuat keputusan akhir tentang status dan prioritas perubahan.

116 Manajemen Proyek Perangkat Lunak Setiap perubahan yang disetujui dihasilkan dalam bentuk urutan perubahan teknis (engineering change order - ECO). ECO menjelaskan perubahan yang harus dilakukan, batasan yang harus diperhatikan, dan kriteria untuk ditinjau dan diaudit. N. Audit konfigurasi Audit konfigurasi perangkat lunak merupakan proses evaluasi yang melengkapi tinjauan teknis dengan menilai suatu objek konfigurasi untuk karakteristik-karakteristik yang umumnya tidak dipertimbangkan selama pemeriksaan teknis biasa. Audit ini bertujuan untuk memastikan bahwa konfigurasi perangkat lunak telah diatur dan dikelola dengan benar sesuai dengan standar dan prosedur yang ditetapkan. Beberapa pertanyaan yang diajukan dalam audit konfigurasi meliputi: 1. Perubahan ECO: Apakah perubahan yang ditetapkan untuk ECO telah dibuat? Apakah modifikasi tambahan sudah dipertimbangkan dan akan digabungkan? 2. Tinjauan Teknis: Sudahkah dilakukan tinjauan teknis untuk mengevaluasi ketepatan teknis dari perubahan yang diusulkan atau dilakukan? 3. Penerapan Proses dan Standar: Apakah proses pengembangan perangkat lunak telah diikuti dengan benar? Sudahkah standar rekayasa perangkat lunak diterapkan sesuai dengan kebijakan yang telah ditetapkan?

Manajemen Proyek Perangkat Lunak 117 4. Pencatatan Perubahan: Apakah perubahan telah ditandai dengan benar dalam Sistem Konfigurasi Item (SCI)? Apakah tanggal perubahan dan penulis perubahan telah ditetapkan dengan jelas? Apakah atribut objek konfigurasi mencerminkan perubahan dengan akurat? 5. Penerapan Prosedur SCM: Sudahkah prosedur manajemen konfigurasi perangkat lunak untuk mencatat, merekam, dan melaporkan perubahan diikuti dengan benar? 6. Pembaruan SCI: Apakah semua SCI terkait telah diperbarui dengan benar sesuai dengan perubahan yang telah dilakukan? O. Pelaporan status Pelaporan status konfigurasi adalah proses dalam manajemen konfigurasi perangkat lunak yang bertujuan untuk memberikan informasi terkini tentang kondisi dan perkembangan dari konfigurasi perangkat lunak. Melalui pelaporan status, tim pengembangan dan pemangku kepentingan dapat memahami secara jelas apa yang terjadi dalam proyek, siapa yang bertanggung jawab, kapan peristiwa itu terjadi, dan dampaknya pada proyek secara keseluruhan. Contoh pertanyaan yang dijawab melalui pelaporan status konfigurasi termasuk: 1. Apakah yang terjadi?. 2. Siapa yang melakukannya? 3. Bilamana hal itu terjadi?

118 Manajemen Proyek Perangkat Lunak 4. Apa saja yang akan dipengaruhi P. Manajemen Konfigurasi Untuk Aplikasi Web Manajemen konfigurasi untuk aplikasi web merupakan disiplin yang bertujuan untuk mengatur dan mengelola evolusi aplikasi web serta aset-aset yang terkait dengan pengembangan, pengujian, dan pengoperasian aplikasi tersebut. Beberapa isu penting yang harus diperhatikan dalam manajemen konfigurasi untuk aplikasi web meliputi: 1. Isi: Aplikasi web umumnya terdiri dari beragam jenis konten, termasuk teks, grafik, skrip, file audio/video, dan lainnya. 2. Manusia: Keterlibatan banyak orang dalam pengembangan aplikasi web dapat menyebabkan masalah jika tidak diatur dengan baik. 3. Skalabilitas: Teknik dan kontrol yang diterapkan pada aplikasi web kecil mungkin tidak cocok untuk aplikasi yang lebih besar dan kompleks. 4. Politik: Manajemen konfigurasi untuk aplikasi web terus berkembang seiring dengan perkembangan teknologi dan praktik rekayasa perangkat lunak. Q. Objek Konfigurasi Aplikasi Web Objek Konfigurasi Aplikasi Web merupakan kerangka kerja yang menyelaraskan berbagai komponen dalam sebuah aplikasi web untuk memastikan bahwa isi web

Manajemen Proyek Perangkat Lunak 119 disusun, disimpan, dan disampaikan dengan efisien dan sesuai dengan kebutuhan pengguna. Ini melibatkan tiga subsistem utama: subsistem koleksi, subsistem manajemen, dan subsistem penerbitan. Berikut ini adalah penjelasan tentang subsistem : 1. Subsistem Koleksi: Subsistem koleksi mencakup tindakan yang diperlukan untuk membuat dan memperoleh isi serta mengatur isi tersebut ke dalam format yang dapat dirender oleh bahasa markup. Contoh dari subsistem koleksi termasuk: a. Mengonversi konten teks, gambar, atau media lainnya ke dalam format yang dapat dipahami oleh browser web. b. Mengorganisir konten ke dalam paket-paket c. bsistem Penerbitan: Subsistem penerbitan yang sesuai untuk ditampilkan kepada pengguna akhir. 2. Subsistem Manajemen: Subsistem manajemen bertanggung jawab untuk menyimpan isi dalam repositori, mengkatalogkan isi untuk penggunaan berikutnya, dan memberikan label untuk mengatur versi dan status isi. Contoh dari subsistem manajemen termasuk: a. Penyimpanan konten dalam database yang terstruktur untuk memfasilitasi pencarian dan pengambilan konten. b. Penetapan metadata dan aturan untuk mengontrol struktur dan perilaku isi. 3. Subsistem penerbitan: Susistem penerbitan bertanggung jawab untuk membangun dan menyampaikan isi kepada pengguna akhir. Contoh dari subsistem penerbitan termasuk:

120 Manajemen Proyek Perangkat Lunak a. Menyampaikan teks dan gambar langsung kepada pengguna tanpa pengolahan tambahan. b. Memanggil layanan publikasi untuk menghasilkan konten yang disesuaikan dengan preferensi pengguna. c. Mengintegrasikan data dari sistem back-end perusahaan ke dalam halaman web. Gambar 5. Sistem Manajemen Isi

Manajemen Proyek Perangkat Lunak 121 R. Manajemen Perubahan Manajemen Perubahan adalah proses yang terstruktur dan terencana untuk mengelola perubahan dalam suatu organisasi atau sistem dengan tujuan untuk mencapai hasil yang diinginkan dengan efisien dan efektif. Perubahan dalam konteks manajemen perubahan dapat dikelompokkan ke dalam empat kelas berikut: 1. Kelas 1: Perubahan kelas 1 adalah perubahan yang berkaitan dengan isi atau fungsi yang dapat mengoreksi kesalahan atau meningkatkan isi atau fungsionalitas lokal. Contoh dari perubahan kelas 1 bisa termasuk: a. Memperbaiki kesalahan tata letak halaman dalam sebuah situs web. b. Meningkatkan fungsionalitas tombol "Submit" dalam formulir pendaftaran online. 2. Kelas 2: Perubahan kelas 2 adalah perubahan yang berdampak pada objek-objek isi lain atau komponenkomponen fungsional. Contoh perubahan kelas 2 mencakup: a. Mengubah struktur database yang mempengaruhi cara data disimpan dan diakses oleh aplikasi web. b. Memperbarui modul pembayaran yang berdampak pada proses checkout secara keseluruhan. 3. Kelas 3: Perubahan kelas 3 adalah perubahan yang memiliki dampak luas di sebuah aplikasi web. Contoh perubahan kelas 3 meliputi: a. Migrasi dari satu platform hosting ke platform hosting yang berbeda.

122 Manajemen Proyek Perangkat Lunak b. Pembaruan besar pada desain antarmuka pengguna yang melibatkan perubahan signifikan dalam navigasi dan tata letak. Gambar 6. Manajemen Perubahan

Manajemen Proyek Perangkat Lunak 123 S. Kontrol Versi Proses kontrol versi diperlukan untuk menghindari situs yang tidak terkontrol. Untuk menghindari hal itu, proses kontrol versi diperlukan. 1. Sebuah repositori pusat untuk proyek aplikasi web harus ditetapkan. 2. Setiap rekayasawan web menciptakan arsip (folder) kerja mereka sendiri. 3. Jam pada semua workstation pengembang harus disinkronkan. 4. Ketika objek konfigurasi baru dikembangkan atau objek yang sudah ada diubah, objek-objek tersebut diimpor ke dalam repositori pusat. 5. Ketika objek diimpor atau diekspor dari repositori, log pesan yang otomatis dan menerapkan waktu yang dibuat T. Audit dan Pelaporan Audit dan pelaporan adalah proses yang penting dalam pengelolaan proyek perangkat lunak, meskipun dalam konteks agilitas, mungkin tidak mendapat penekanan yang sama seperti dalam metodologi pengembangan tradisional. Skenario: Misalkan sebuah tim pengembangan perangkat lunak menggunakan metodologi pengembangan yang berbasis Agile untuk mengembangkan aplikasi web. Tim terdiri dari beberapa anggota yang bekerja secara terdistribusi dan terdiri dari pengembang, tester, dan manajer proyek.

124 Manajemen Proyek Perangkat Lunak 1. Audit Proses: Selama proses pengembangan, tim secara teratur melakukan pertemuan sprint untuk meninjau kemajuan proyek dan memperbarui tujuan sprint berikutnya. 2. Pelaporan Perubahan: Setiap kali ada perubahan pada kode sumber atau fitur aplikasi web, anggota tim harus melakukan pelaporan perubahan agar semua anggota tim memiliki pemahaman yang jelas tentang evolusi proyek.

Manajemen Proyek Perangkat Lunak 125 Komunikasi Internal dan Eksternal dalam Proyek Perangkat Lunak Anis Yusrotun Nadhiroh, S.Kom., M.MT BAB 9

126 Manajemen Proyek Perangkat Lunak A. Komunikasi dalam Pelaksanaan Proyek Komunikasi merupakan proses dimana terjadi pertukaran informasi. Dalam proyek konstruksi, komunikasi sangat penting untuk kontak, kerja sama, dan kolaborasi anggota tim serta untuk meyakinkan manajer proyek dan pemimpin proyek lainnya. (project leader) bahwa aktifitas proyek dari hari kehari sesuai dengan rencana yang ada (on the right tract). Dalam proyek konstruksi, komunikasi dilakukan antara pihak internal, seperti pelaku proyek dan perusahaan, dan pihak eksternal, seperti konsultan dan pemilik proyek, untuk memfasilitasi dan memperjelas struktur organisasi. Proses manajemen komunikasi proyek adalah didalamnya sebagai berikut: 1. Perencanaan komunikasi, yang melibatkan pencarian informasi dan komunikasi apa yang dibutuhkan oleh pemangku kepentingan. 2. Distribusi informasi (Information Distribution), menjadikan informasi yang dibutuhkan tersedia bagi para stakeholder secara berkala 3. Pelaporan kinerja (Performance reporting), pengumpulan dan penyebaran data kinerja. Termasuk didalamnya pelaporanstatus, pengukuran prestasi, dan prediksi. 4. Berkoordinasi dengan pemangku kepentingan, mengelola komunikasi untuk memenuhi kewajiban, dan menyelesaikan masalah dengan mereka.

Manajemen Proyek Perangkat Lunak 127 B. Komunikasi Manusia berinteraksi satu sama lain melalui komunikasi, baik secara individu maupun kelompok. Eduard Depari, Ph.D. menyatakan bahwa komunikasi adalah tindakan mengungkapkan pikiran, aspirasi, dan pesan dengan menggunakan simbol-simbol yang bermakna. dilakukan dengan tujuan tercapainya kebersamaan (kesamaan) dan ditujukan kepada penerima pesan (penerima, komunikator, pendengar) oleh pengirim komunikasi (sumber, komunikator, pengirim). Komunikasi merupakan pentransferan dan pemahaman kata. Ide dan informasi hanya dapat disampaikan dari satu orang ke orang lain melalui transmisi makna. Seni komunikasi adalah suatu subyek yang luas dan melibatkan pokok kumpulan ilmu pengetahuan (Body of Knowledge) diantaranya: 1. Model pengiriman-penerimaan. Loop umpan balik dan hambatan- hambatan komunikasi. 2. Pilihan media. Saat berkomunikasi dengan tulisan dibandingkan dengan ucapan, saat menulis dengan memo tidak resmi dibandingkan dengan laporan resmi, dan saat berkomunikasi dengan bertatap muka dibandingkan dengan surat elektronik, pemilihan media untuk aktifitaskomunikasi akan tergantung pada situasi. 3. Gaya menulis. Ide dan informasi hanya dapat disampaikan dari satu orang ke orang lain melalui transmisi makna.

128 Manajemen Proyek Perangkat Lunak C. Fungsi Komunikasi Dalam suatu kelompok atau organisasi komunikasi mempunyai fungsi sebagai alat: 1. Proses komunikasi lebih dari penyampaian pesan yang benar, juga merupakan sumber untuk mengontrol. Komunikasi yang tepat untuk pekerjaan dalam bekerja, karena pekerja membutuhkan pengetahuan dan pengertian. 2. Motivasi Komunikasi membantu perkembangan motivasi dengan menjelaskankepada orang lain apa yang harus dilakukan, seberapa baik mereka bekerja, dan apa yang dapat dikerjakan untuk memperbaiki kinerja yang dibawah standard. Komunikasi harus membawa informasi dan motivasi. 3. Ekspresi emosional Anggota suatu kelompok berkomunikasi satu sama lain sebagai sarana dasar untuk mengekspresikan kebahagiaan dan ketidakpuasan mereka. Oleh karena itu, komunikasi menunjukkan ungkapan emosional dari perasaan dan pemenuhan kebutuhan sosial. 4. Informasi Komunikasi berhubungan dengan perannya dalam mempermudah pengambilan keputusan. Komunikasi memberikan informasi yng diperlukan individu dan kelompok untuk mengambil keputusan dengan meneruskan data guna mengenali dan menilai pilihanpilihan alternatif.

Manajemen Proyek Perangkat Lunak 129 Sumber terjadinya konflik dalam suatu organisasi adalah manusia dengan perilakunya, struktur organisasi, dan komunikasi. Sistem komunikasi dapat menjadi sumber konflik jika terdapat arahan yang tidak jelas, kebijakan yang tidak konsisten, atau hambatan terhadap fasilitas komunikasi. Konflik yang muncul dari komunikasi juga dapat disebabkan oleh faktorfaktor tersebut. berbagai hambatan masalah komunikasi, sistem komunikasi yang tidak baik, lingkungan komunikasi yang tidak mendukung. Lima faktor yang paling signifikan yang menyebabkan kinerja proyek yang buruk, salah satunya adalah konflik dan kebingungan (confusion). D. Manajemen komunikasi proyek Prosedur yang diperlukan untuk menjamin pembuatan, pengumpulan, distribusi, penyimpanan, dan pembuangan akhir informasi proyek secara cepat termasuk dalam manajemen komunikasi proyek. Setiap peserta proyek harus mengetahui cara berkomunikasi baik secara individu maupun kelompok, serta siap mengirim dan menerima pesan di dalam proyek. Memastikan pembuatan, pengumpulan, penyebaran, penyimpanan, dan jenis informasi proyek yang tepat waktu dan tepat adalah tujuan manajemen komunikasi proyek. Proses manajemen komunikasi proyek meliputi: 1. Perencanaan komunikasi adalah mencari tahu informasi apa yang dapat diakses, kapan dibutuhkan, dan bagaimana informasi tersebut akan disampaikan

130 Manajemen Proyek Perangkat Lunak untuk memenuhi kebutuhan informasi dan komunikasi para pemangku kepentingan. 2. Distribusi Informasi: Hal ini mengacu pada penyediaan informasi yang diperlukan kepada pemangku kepentingan proyek dengan segera. 3. Pelaporan Kinerja: Hal ini berkaitan dengan pengumpulan dan berbagi data kinerja, seperti perkiraan, pengukuran kemajuan, dan laporan status. 4. Penutupan Administratif: membuat, mengumpulkan, dan berbagi data untuk memasuki fase resmi atau penyelesaian proyek. E. Perencanaan Komunikasi Setiap proyek memerlukan rencana manajemen komunikasi, yaitu dokumen yang memandu komunikasi di dalam proyek, karena komunikasi sangat penting dalam proyek. Proses perencanaan proyek secara keseluruhan harus mencakup perencanaan komunikasi ini. Tergantung pada kebutuhan proyek, beberapa rencana komunikasi proyek mungkin diperlukan, namun rencana harus selalu dibuat. Komponen utama perencanaan manajemen komunikasi meliputi : 1. Pendeskripsian dari struktur pengkoleksian dan pengajuan untuk mengumpulkan dan menyimpan berbagai tipe informasi. 2. Sistem penyebaran informasi tentang siapa, apa, dan kapan. 3. Format untuk berkomunikasi tentang informasi kunci proyek. Apakah ada templat yang dapat digunakan oleh

Manajemen Proyek Perangkat Lunak 131 peserta proyek untuk menyampaikan laporan tertulis dan lisan? Apakah akronim dan maknanya perlu diulangi dalam berbagai dokumen proyek, atau adakah daftar utamanya? Dengan menyediakan templat dan contoh laporan proyek penting, banyak waktu dapat dihemat. 4. Penjadwalan produksi untuk memproduksi informasi. Apakah alat yang diperlukan telah disiapkan untuk menghasilkan, mengumpulkan, dan mendistribusikan informasi proyek? Bagaimana pihak yang berkepentingan mengetahui kapan harus mendapatkan dokumen tertentu, kapan harus hadir pada pertemuan penting, dan rincian lainnya? Saat hendak mencatat persalinan, banyak orang yang menunda-nunda. Menyisihkan waktu untuk menghasilkan informasi proyek dan menjamin kualitasnya sangatlah penting. 5. Metode akses untuk mengambil informasi. Siapa yang dapat melihat draft dokumen? Dapatkah semua orang mengakses semua dokumentasi proyek? Materi mana yang termasuk dalam internet, dan mana yang harus dipublikasikan dalam bentuk cetak atau format lain? Bisakah seseorang memverifikasi dokumen dalam salinan fisik? Siapa yang dapat menghadiri rapat? 6. Metode untuk mengupdate perencanaan manajemen komunikasi sebagai progres proyek dan mengembangkannya. Setelah modifikasi dilakukan, siapa yang akan memperbarui rencana pengelolaan komunikasi? Bagaimana rencana baru akan didistribusikan?

132 Manajemen Proyek Perangkat Lunak 7. Analisis komunikasi stakeholder. Sangat penting untuk tahu apa jenis dari informasi yang akan didistribusikan ke stakeholder yang mana. Dengan menganalisis komunikasi stakeholder, dapat menghindari waktu atau uang yang terbuang dalam pembuatan atau menyebarkan informasi yang tidak perlu. Chart organisasi proyek merupakan poin awal untuk mengidentifikasi stakeholder internal. Harus memasukkan stakeholder kunci diluar organisasi proyek seperti pelanggan, customer senior management, dan subcontractors. F. Distribusi Informasi Penyebaran informasi melibatkan membuat informasi yang dibutuhkan dan tersedia untuk proyek stakeholder secara tepat waktu. Ini termasuk menerapkan rencana pengelolaan komunikasi serta menanggapi permintaan tak terduga untuk informasi. 1. Input ke Distribusi Informasi a. Hasil kerja b. Komunikasi rencana pengelolaan c. Rencana Proyek 2. Alat dan Teknik untuk Distribusi Informasi a. Komunikasi keterampilan. Keterampilan komunikasi yang digunakan untuk bertukar informasi. b. Pengirim bertanggung jawab untuk membuat informasi yang jelas, tidak ambigu, dan lengkap sehingga penerima dapat menerima dengan benar dan untuk

Manajemen Proyek Perangkat Lunak 133 mengkonfirmasikan bahwa itu dipahami dengan benar. Penerima bertanggung jawab untuk memastikan bahwa informasi yang diterima secara keseluruhan dan dipahami dengan benar. Berkomunikasi memiliki banyak dimensi: 1) Ditulis dan lisan, mendengar dan berbicara. 2) Internal (dalam proyek) dan eksternal (kepada pelanggan, media, masyarakat, dll). 3) Formal (laporan, briefing, dll) dan informal (memo, percakapan ad hoc, dll). 4) Vertikal (atas dan bawah organisasi) dan horisontal (dengan rekan-rekan). c. Sistem pencarian informasi. Informasi dapat dibagi oleh anggota tim melalui berbagai metode termasuk sistem pengarsipan manual, database teks elektronik, perangkat lunak manajemen proyek, dan sistem yang memungkinkan akses ke dokumentasi teknis seperti gambar teknik. d. Sistem distribusi informasi. Informasi proyek dapat didistribusikan dengan menggunakan berbagai metode termasuk pertemuan-pertemuan proyek, distribusi dokumen hard copy, akses bersama untuk database jaringan elektronik, faks, surat elektronik, pesan suara, dan video conferencing. G. Output dari Distribusi Informasi Catatan proyek mungkin termasuk korespondensi, memo, laporan, dan dokumen-dokumen yang menjelaskan

134 Manajemen Proyek Perangkat Lunak proyek. Informasi ini harus sedapat mungkin dan sesuai, dipertahankan dalam cara yang terorganisir. Anggota tim proyek mungkin sering memelihara catatan pribadi dalam buku catatan proyek. Mengambil informasi dari orang yang tepat dalam waktu yang tepat dan dalam format yang berguna sama pentingnya dengan mengutamakan mengembangkan informasi. Stakeholder analisis untuk komunikasi menyediakan awal yang baik untuk distribusi informasi. Manajer proyek dan timnya harus menentukan siapa yang menerima informasi apa, tetapi mereka harus juga menentukan jalan terbaik untuk mendistribusikan informasi. Apakah cukup untuk mengirim laporan tertulis untuk informasi proyek? Apakah meeting efektif dalam pendistribusian informasi? Apakah meeting dan komunikasi tertulis dibutuhkan dalam informasi proyek? Setelah menjawab pertanyaan tersebut, manajer proyek dan timnya harus memutuskan jalan terbaik untuk mendistribusikan informasi. H. Saran Untuk Meningkatkan Komunikasi Proyek Kita telah melihat bahwa komunikasi yang baik sangat penting untuk pengelolaan dan keberhasilan proyek teknologi informasi; juga telah belajar 52 bahwa manajemen komunikasi proyek dapat memastikan bahwa informasi penting mencapai orang yang tepat pada waktu yang tepat, umpan balik itu dan laporan yang tepat dan berguna, dan bahwa ada proses formal penutupan administrasi. Bagian ini menyoroti beberapa daerah yang harus mempertimbangkan semua manajer proyek dan anggota tim dalam

Manajemen Proyek Perangkat Lunak 135 pencarian mereka untuk meningkatkan komunikasi proyek. Kiat disediakan untuk mengelola konflik, mengembangkan keterampilan komunikasi yang lebih baik, menjalankan pertemuan yang efektif, dengan menggunakan template untuk komunikasi proyek, dan mengembangkan infrastruktur komunikasi. I. Menggunakan Kemampuan Komunikasi untuk Mengelola Konflik Sebagian besar proyek teknologi informasi yang besar usaha tinggi-saham yang sangat terlihat dalam organisasi, mereka membutuhkan usaha yang luar biasa dari anggota tim, mahal, menyita sumber daya yang signifikan, dan dapat memiliki dampak yang luas pada cara pekerjaan dilakukan dalam sebuah organisasi. Ketika taruhannya tinggi, konflik tidak pernah jauh; ketika potensi konflik tinggi, komunikasi yang baik adalah suatu keharusan. Sangat penting bagi manajer proyek untuk mengembangkan dan menggunakan sumber daya manusia dan keterampilan komunikasi untuk membantu mengidentifikasi dan mengelola konflik pada manajer proyek. Manajer proyek harus memimpin tim mereka dalam mengembangkan norma-norma untuk menangani berbagai jenis konflik yang mungkin timbul pada proyekproyek mereka, misalnya, anggota tim harus tahu bahwa perilaku tidak sopan terhadap setiap pemangku kepentingan proyek yang tidak pantas, dan bahwa anggota tim diharapkan untuk mencoba untuk bekerja di luar konflik kecil sebelum mengangkat mereka ke tingkat yang lebih tinggi.

136 Manajemen Proyek Perangkat Lunak Blake dan Mouton (1964) menggambarkan 5 mode dasar untuk mengendalikan konflik: konfrontasi, kompromi, smoothing, pemaksaan, dan penarikan. 1. Konfrontasi. Proyek manajer secara langsung menghadapi konflik dengan cara pendekatan pemecahan masalah yang membuat pihak dapat bekerja walaupun tidak setuju. Pendekatan ini biasa juga disebut pemecahan masalah. 2. Kompromi. Dengan modus kompromi, manajer proyek menggunakan pendekatan memberi dan mengambil untuk menyelesaikan konflik. Mereka tawar-menawar dan mencari solusi yang membawa beberapa tingkat kepuasan kepada semua pihak dalam sengketa. 3. Smoothing. Manajer proyek menghindari area perbedaan dan menekankan area persetujuan. 4. Pemaksaan. Pendekatan win-lose untuk solusi konflik. Manajer mendesak cara pandangnya dibanding cara pendang orang lain. Manajer yang kompetitif dan autocratic dalam gaya manajemennya mungkin menggunakan pendekatan ini. 5. Penarikan. Manajer proyek mundur dari ketidaksetujuan nyata atau yang potensial. Pendekatan ini yang paling sedikit diinginkan dalam pengendalian konflik. Penelitian mengindikasi bahwa manajer proyek lebih senang menggunakan konfrontasi mode untuk menyelesaikan konflik dibandingkan keempat mode lainnya. Kata konfrontasi mungkin dapat salah paham arti. Mode ini sangat berfokus pada pengalaman konflik menggunakan problem-solving. Dengan paradigma Stephen

Manajemen Proyek Perangkat Lunak 137 Covey tentang interdependence, mode ini berfokus pada pendekatan win/win. Semua pihak bekerja sama untuk mencari jalan terbaik menyelesaikan konflik. Pendekatan yang paling disenangi selanjutnya adalah kompromi. Manajer proyek yang telah sukses jarang menggunakan smoothing, pemaksaan, atau penarikan dibanding menggunakan mode konfrontasi atau kompromi. Manajer proyek juga harus menyadari bahwa tidak semua konflik buruk, pada kenyataannya, konflik sering bisa baik. Konflik sering menghasilkan hasil yang penting, seperti ide-ide baru, alternatif yang lebih baik, dan motivasi untuk bekerja lebih keras dan lebih kolaboratif. Anggota tim proyek dapat menjadi stagnan atau dikembangkan groupthink -kesesuaian dengan nilai-nilai atau standar etika group- jika tidak ada sudut pandang yang bertentangan tentang berbagai aspek proyek. Penelitian oleh Karen Jehn, profesor manajemen di Wharton, menunjukkan bahwa konflik-tugas yang berhubungan, yang berasal dari perbedaan atas tujuan tim dan bagaimana mencapainya, sering meningkatkan kinerja tim. Konflik emosional, namun yang berasal dari bentrokan kepribadian dan kesalahpahaman, sering menekan kinerja tim. Manajer proyek harus menciptakan lingkungan yang mendorong dan mempertahankan aspek positif dan produktif konflik. J. Mengembangkan Kemampuan Komunikasi yang Lebih Baik Beberapa orang tampaknya dilahirkan dengan kemampuan komunikasi yang besar, yang lain tampaknya memiliki bakat untuk mengambil keterampilan teknis.

138 Manajemen Proyek Perangkat Lunak Sangat jarang untuk menemukan seseorang dengan kemampuan alami untuk keduanya. Baik komunikasi dan keterampilan teknis, bagaimanapun, dapat dikembangkan. Sebagian besar profesional teknologi informasi memasuki lapangan adalah kunci untuk maju dalam karir mereka, terutama jika mereka ingin menjadi manajer proyek yang baik. Kebanyakan perusahaan menghabiskan banyak uang untuk pelatihan teknis bagi karyawan mereka, bahkan ketika karyawan mungkin mendapatkan manfaat lebih dari pelatihan komunikasi. Individu karyawan juga lebih mungkin untuk mendaftar secara sukarela di kelas pada teknologi terbaru dibandingkan pada pengembangan soft skill mereka. Pelatihan keterampilan komunikasi biasanya mencakup kegiatan role-playing di mana peserta belajar konsep-konsep seperti membangun hubungan. Sesi pelatihan yang berfokus pada kemampuan presentasi biasanya rekaman video para peserta. Kebanyakan orang terkejut melihat beberapa tingkah laku mereka pada video dan menikmati tantangan untuk meningkatkan keterampilan mereka. Investasi minimal dalam komunikasi dan presentasi pelatihan dapat memiliki pengembalian yang luar biasa bagi individu, proyek-proyek mereka, dan organisasi mereka. Keterampilan ini juga memiliki umur simpan lebih lama daripada banyak keterampilan yang dipelajari dalam kursus pelatihan teknis. Sebagai organisasi yang menjadi lebih global, mereka menyadari harus berinvestasi dalam cara-cara untuk meningkatkan komunikasi dengan orangorang dari berbagai negara dan budaya. Misalnya, banyak orang Amerika yang dibesarkan untuk berbicara terus terang sesuai dengan pikiran mereka, sementara dalam beberapa