tugas bab.3 gambaran manajemen umum

3.1. Spektrum Manajemen

Manajemen proyek perangkat lunak yang efektif berfokus pada tiga P : People (manusia), problem (masalah), process (proses). Urutan ini tidak dapat berubah.

3.1.1. Manusia

Faktor manusia sangat penting sehingga Software Engineering Institute telah mengembangkan sebuah model kematangan kemampuan manajemen manusia (PM-CMM) ”untuk mempertinggi kesiapan organisasi perangkat lunak untuk mengerjakan aplikasi yang semakin kompleks dengan membantu menarik, menumbuhkan, memotivasi, menyebarkan, dan memelihara bakat yang dibutuhkan untuk mengembangan kemampuan perkembangan perangkat lunak mereka”

Model kematangan manajemen manusia membatasi area praktikj berikut kunci bagi masyarakat perangkat lunak : rekruitmen, seleksi, manajemen unjuk kerja, pelatihan, kompensasi, perkembangan karir, desain kerja dan organisasi, dan perkembangan tim/kultur.

3.1.2. Masalah

Sebelum proyek direncanakan, obyektivitas dan ruang lingkupnya harus ditetapkan, pemecahan alternatifnya harus dipertimbangkan, teknik dan bataspun harus didefinisikan. Tanpa informasi ini tidak mungkin melakukan estimasi biaya yang dapat dipertanggungjawabkan (akurat); penilaian yang efektif terhadap resiko; merinci secara realistis tugas-tugas proyek; atau jadwal proyek yang dapat dikelola yang memberikan indikasi kemajuan yang berarti.

Pengembang dan pemakai perangkat lunak harus bertemu untuk menentukan tujuan dan ruang lingkup proyek. Di dalam banyak kasus, aktivitas ini dimulai sebagai bagian dari proses rekayasa sistem dan berlanjut sebagai langkah pertama dalam analisis kebutuhan perangkat lunak.

3.1.3. Proses

Proses perangkat lunak memberikan suatu kerangka kerja di mana rencana komprehensif bagi pengembangan perangkat lunak dapat dibangun. Sejumlah kumpulan tugas yang berbeda – tugas-tugas milestone, kemampuan penyampaian, dan jaminan kualitas – memungkinkan aktivitas kerangka kerja disesuaikan dengan karakteristik proyek perangkat lunak serta kebutuhan tim proyek. Akhirnya aktivitas pelindung seperti jaminan kualitas perangkat lunak, manajemen konfigurasi perangkat lunak, dan pengukurannya – melapisi model proses yang ada.

3.2. Manusia

Hasil dari wawancara dengan beberapa wakil president direktur menandakan pentingnya manusia dalam proses rekayasa perangkat lunak.

3.2.1. Para Pemain

Proses perangkat lunak diisi oleh para pemain yang dapat dikategorikan ke dalam salah satu dalam lima konstituen berikut ini :

1. Manajer Senior, yang menentukan isu-isu bisnis yang sering memiliki pengaruh penting di dalam proyek.

2. Manajer (teknik) Proyek, yang harus merencanakan, memotivasi, mengorganisir, dan mengontrol sebuah produk atau aplikasi.

3. Pelaksana, yang menaympaikan ketrampilan teknik yang diperlukan untuk merekayasa sebuah produk atau aplikasi.

4. Pelanggan, yang menentukan jenis kebutuhan bagi perangkat lunak yang akan direkayasa.

5. Pemakai Akhir, yang berinteraksi dengan perangkat lunak bila perangkat lunak telah dikeluarkan untuk digunakan.

3.2.2. Pimpinan Tim

Jerry Weinberg cenderung mengusulkan model kepemimpinan MOI :

Motivasi. Kemampuan untuk memberi dorongan orang teknik untuk menghasilkan sesuatu dengan kemampuan terbaiknya.

Organisasi. Kemampuan untuk membentuk proses yang sedang berlangsung yang memungkinkan konsep dasar diterjemahkan ke dalam suatu hasil akhir.

Gagasan dan inovasi. Kemampuan untuk mendorong manusia untuk menciptakan dan bertindak kreatif meskipun mereka bekerja di dalam suatu ikatan yang dibangun untuk suatu produk atau aplikasi perangkat lunak yang spesifik.

Pandangan lain tentang karakteristik seorang manajer proyek yang efektif memberikan tekanan pada empat kata kunci :

Pemecahan masalah. Seorang manajer proyek yang efektif dapat mendiagnosis isu-isu organisasi dan teknis yang paling relevan, yang secara sistematis membentuk sebuah pemecahan atau dengan tepat memotivasi para pelaksana yang lain untuk membuat pemecahan.

Identitas manajerial. Seorang manajer proyek yang baik harus bersentuhan secara langsung dengan proyeknya. Dia harus memilki rasa percaya diri untuk melakukan kontrol bila perlu dan membolehkan orang-orang teknik yang baik untuk mengikuti insting mereka.

Prestasi. Untuk mengoptimasi produktivitas sebuah tim proyek, seorang manajer harus memiliki inisiatif dan prestasi, serta dengan caranya sendiri memperlihatkan bahwa pengambilan risiko yang terkontrol tidak akan dikenai hukuman.

Pengaruh dan pembentukan tim. Seorang manajer proyek yang efektif harus mampu “membaca” manusia; dia harus mampu memahami sinyal verbal dan nonverbal serta bereaksi terhadap kebutuhan-kebutuhan orang-orang yang mengirimkan sinyal tersebut. Manajer harus dapat menguasai diri meskipun berada pada situasi tekanan yang sangat tinggi.

3.2.3. Tim Perangkat Lunak

Mantei mengusulkan tiga organisasi tim yang umum :

Demokratis terdesentralisasi (DD). Tim rekayasa perangkat lunak ini tidak memiliki pemimpin yang permanen. Tetapi “koordinator” dipilih untuk bertugas di dalam durasi waktu yang pendek, yang kemudian diganti oleh yang lain yang mungkin bertugas untuk mengkoordinasi tugas-tugas yang berbeda. Keputusan terhadap masalah dan pendekatan yang dilakukan dibuat oleh konsensus kelompok. Komunikasi di antara anggota tim bersifat horisontal.

Terkontrol terdesentralisasi (CD). Tim rekayasa perangkat lunak memiliki pemimpin tertentu yang mengkoordinasi tugas-tugas khusus serta memiliki pemimpin-pemimpin sekunder yang bertanggung jawab atas masalah sub-sub tugas. Pemecahan masalah merupakan aktivitas dari kelompok, tetapi implementasi dari pemecahan masalah dipecah di antara sub-sub kelompok oleh pimpinan tim. Komunikasi antar kelompok dan orang bersifat horisontal, tetapi komunikasi vertikal sepanjang hirarki kontrol juga terjadi di sini.

Terkontrol terdesentralisasi (CC). Koordinasi pemecahan masalah tingkat puncak dan internal tim diatur oleh pimpinan tim. Komunikasi antara pimpinan dan anggota tim bersifat vertikal.

Tabel 3.1. merangkum pengaruh karakteristik proyek terhadap organisasi tim. Karena struktur tersentralisasi dapat menyelesaikan tugas dengan lebih cepat, struktur tsb paling banyak digunakan pada penanganan masalah-masalah yang sederhana. Tim terdesentralisasi memberikan solusi yang lebih banyak dan lebih baik daripada individual sehingga tim semacam itu memiliki kemungkinan keberhasilan lebih banyak pada saat bekerja pada masalah yang sulit. Karena tim CD tersentralisasi untuk penyelesaian masalah, baik struktur tim CD ataupun CC dapat diterapkan dengan baik pada masalah-masalah yang sederhana. Struktur DD merupakan yang terbaik untuk masalah-masalah yang sulit.

Tabel 3.1 Pengaruh karakteristik Proyek Pada Struktur Tim

Tipe tim :	DD	CD	CC
Tingkat kesulitan
Tinggi	X
Rendah		X	X
Ukuran
Besar		X	X
Kecil	X
Umur tim
Singkat		X	X
Panjang	X
Modularitas
Tinggi		X	X
Rendah	X
Keandalan
Tinggi	X	X
Rendah			X
Tanggal pengiriman
Ketat/pasti			X
Longgar	X	X
Sosiabilitas
Tinggi	X
Rendah		X	X

Karena unjuk kerja dari sebuah tim berbanding terbalik dengan jumlah komunikasi yang harus dilakukan, proyek-proyek yang sangat besar paling baik bila diserahkan kepada tim dengan struktur CC atau CD bila kelompok-kelompok sub dapat diakomodasi dengan baik.

Telah dibuktika bahwa struktur tim DD menghasilkan kepuasan kerja dan moral yang tinggi sehingga baik untuk tim dengan jangka waktu hidup yang lama.

Struktur tim DD paling baik diaplikasikan pada masalah-masalah dengan modularitas relatif rendah karena di sini dibutuhkan volume komunikasi yang lebih tinggi. Bila modularitas tinggi dimungkinkan (dan manusia dapat melakukan tugas-tugas mereka sendiri), struktur CC dan DD akan bekerja dengan baik.

Tim CC dan CD terbukti menghasilkan cacat yang lebih sedikit dibanding struktur tim DD, tetapi berhubungan erat dengan aktivitas jaminan kualitas khusus yang diaplikasikan oleh tim tersebut. Tim yang terdesentralisasi biasanya membutuhkan lebih banyak waktu untuk menyelesaikan sebuah proyek daripada struktur yang tersentralisasi, dan pada saat yang sama merupakan pilihan yang terbaik bila sosiabilitas yang tinggi diperlukan.

Constantine mengusulkan empat “paradigma organisasional” bagi tim rekayasa perangkat lunak :

1. Paradigma tertutup membentuk sebuah tim di sepanjang hirarki otoritas tradisional (sama dengan tim CC). Tim semacam ini dapat bekerja dengan baik pada saat memproduksi perangkat lunak yang sangat mirip dengan apa yang dilakukan sebelumnya; tetapi tim ini kurang inovatif ketika bekerja dalam paradigma tertutup.
2. Paradigma random membentuk sebuah tim secara longgar dan tergantung pada inisiatif individual anggota tim. Pada saat terobosan inovasi atau teknologi dibutuhkan, tim yang mengikuti paradigma random akan unggul. Tetapi tim semacam ini dapat berjuang keras bila “unjuk kerja yang teratur” diperlukan.
3. Paradigma terbuka cenderung membentuk tim dengan cara tertentu sehingga tercapai banyak kontrol yang berhubungan dengan paradigma tertutup, tetapi sekaligus juga banyak inovasi pada saat menggunakan paradigma random. Kerja dilakukan secara kolaboratif dengan komunikasi yang sarat serta konsensus yang didasarkan pada pengambilan keputusan. Struktur tim paradigma terbuka sesuai bagi pemecahan masalah-masalah yang kompleks, tetapi tidak akan bekerja seefisien tim yang lain.
4. Paradigma sinkron bertumpu pada pemggolongan alami dari suatu masalah serta mengorganisasi anggota tim untuk bekerja pada bagian-bagian kecil masalah dengan komunikasi aktif di antara mereka sendiri.

3.2.4. Masalah Koordinasi dan Komunikasi

Kraul dan Streeter menguji sekumpulan teknik koordinasi proyek yang dikategorikan dalam kelompok berikut :

Pendekatan impersonal, formal. Mencakup penyampaian dan dokumen rekayasa perangkat lunak (seperti kode sumber), memo-memo teknis, kejadian penting pada proyek, jadwal dan piranti kontrol proyek, kebutuhan akan perubahan dan dokumentasi yang berhubungan, laporan pelacakan kesalahan dan data cadangan.

Prosedur interpersonal, formal. Berfokus pada aktivitas jaminan kualitas yang diterapkan kepada produk kerja rekayasa perangkat lunak. Hal ini menyangkut pertemuan status pengkajianserta perancangan dan inspeksi kode.

Prosedur interpersonal, informal. Menyangkut pertemuan kelompok untuk penyebaran informasi dan pemecahan masalah serta “alokasi kebutuhan dan pengembangan staf”.

Komunikasi elektronik. Mencakup surat elektronik, papan buletin elektronik, web sites, serta sistem konferensi berbasis video.

Jaringan interpersonal. Diskusi informal dengan orang-orang di luar proyek yang mungkin memiliki pengalaman atau pengetahuan yang dalam yang dapat mendukung anggota tim.

3.3. Masalah

Seorang manajer proyek perangkat lunak dihadapkan pada sebuah dilema pada awal proyek rekayasa perangkat lunak. Kebutuhan terkadang berubah-ubah, berubah secara reguler pada saat proyek berjalan. Tetapi walau bagaimanapun diperlukan suatu rencana, “sekarang!”

3.3.1. Ruang lingkup

Aktivitas manajemen proyek perangkat lunak yang pertama adalah menentukan ruang lingkup perangkat lunak. Ruang lingkup dibatasi dengan menjawab pertanyaan-pertanyaan berikut :

Konteks. Bagaimana perangkat lunak yang akan dibangun dapat memenuhi sebuah sistem, produk, atau konteks bisnis yang lebih besar, serta batasan apa yang ditentukan sebagai hasil dari kontek tersebut?

Tujuan informasi. Objek data pelanggan apa yang dihasilkan sebagai output dari perangkat lunak? Objek data apa yang diperlukan sebagai input?

Fungsi dan unjuk kerja. Fungsi apa yang dilakukan oleg perangkat lunak untuk mentransformasi input data menjadi output? Adakah ciri kerja khusus yang akan ditekankan?

Ruang lingkup proyek perangkat lunak harus tidak ambigu dan dapat dipahami pada tingkat teknis maupun manajemen.

3.3.2 Dekomposisi Masalah

Dekomposisi masalah sering disebut juga partitioning (pembagian), merupakan sebuah aktivitas yang mendudukan inti dari analisis kebutuhan perangkat lunak.

Dekomposisi diterapkan pada dua area utama :

(1). Fungsionalitas yang harus disampaikan, dan

(2). Proses yang akan dipakai untuk menyampaikannya.

Secara sederhana, masalah yang kompleks dibagi ke dalam sejumlah masalah yang lebih kecil yang dapat lebih dikendalikan.

3.4. Proses

Fase-fase generik yang menandai proses perangkat lunak – definisi, pengembangan dan pemeliharaan – dapat diaplikasikan pada semua perangkat lunak. Masalahnya adalah bagaimana memilih model proses yang sesuai bagi perangkat lunak yang akan direkayasa oleh sebuah tim proyek. Berikut ini beberapa jenis paradigma yang dapat dipergunakan dalam rekayasa perangkat lunak :

· Model sekuensial linier

· Model prototipe

· Model RAD

· Model inkremental

· Model spiral

· Model asembli komponen

· Model pengembangan kongkuren

· Model metode formal

· Model teknik generasi keempat

Manajer proyek harus memutuskan model proses mana yang paling sesuai untuk proyek tertentu.

Perencanaan proyek dimulai dengan menggabungkan masalah dan proses. Setiap fungsi yang akan direkayasa oleh tim perangkat lunak harus melampaui sejumlah aktivitas kerangka kerja yang sudah ditentukan bagi sebuah organisasi perangkat lunak. Misal organisasi sudah mengadopsi serangkaian aktivitas kerangka kerja sebagai berikut :

· Komunikasi pelanggan – tugas-tugas yang diperlukan untuk membangun komunikasi yang efektif diantara pengembang dan pelanggan.

· Perencanaan – tugas-tugas yang diperlukan untuk menentukan sumber-sumber daya, ketepatan waktu, dan informasi proyek yang lain.

· Analisis resiko – tugas-tugas yang diperlukan untuk memperkirakan resiko-resiko manajemen dan teknis.

· Rekayasa – tugas-tugas yang diperlukan untuk membangun satu perwakilan aplikasi atau lebih.

· Konstruksi dan rilis – tugas-tugas yang diperlukan untuk membangun, menguji, memasang, dan memberikan dukungan kepada pemakai (seperti dokumentasi dan pelatihan)

· Evaluasi pelanggan – tugas-tugas yang diperlukan untuk memperoleh umpan balik dari pelanggan.

Anggota-anggota tim yang bekerja pada masing-masing fungsi akan menerapkan setiap aktivitas kerangka kerja pada fungsi.

Sumber: openstorage.gunadarma.ac.id/handouts/S1.../RPL/BAB%203.doc