Project Management Oleh : Indrias Budi Utami Management proyek  aktivitas pelindung /umbrella activity dlm SE  tahapan ini dilakukan sebelum masuk pd kegiatan teknis, perkembangan dan pemeliharaan PL komputer

Project Management Management Spectrum People Players Team Leaders Software Team Coordination dan Communication Issues Problem cakupan software dekomposisi masalah Process Problem dan Process dekomposisi proses

The Management Spectrum - People Tiga P’s: software project management yang efektif terfokus pada tiga P yaitu (URUT): (1) people, (2) problem (3) process - People: MODEL KEMATANGAN KEMAMPUAN MANAJEMEN MANUSIA (PM-CMM)  Kunci bg pengembangan PL  include: - recruitment - training - desain kerja&organisasi - seleksi - kompensasi -budaya kerja / culture - manajemen job desk - pengembangan karir Kontributor yang paling penting agar software project berhasil -> memiliki orang yang SMART dengan kemampuan yang baik Organisasi dengan high levels maturity pada management people. -> mengimplementasikan effective software engineering

The Management Spectrum - The Problem langkah I dalam analisis kebutuhan PL perlunya indentifikasi (before project): - Objectives dan scope - Alternative solutions - Technical dan management constraints Faktor lain yang berhubungan: delivery deadlines, budgetary restrictions, personnel availability technical interfaces, dan lainnya Tanpa informasi ini , tidak mungkin untuk : - mendefinisikan estimasi biaya - menginginkan efektif assesssment dari resiko. - melakukan project task yang lebih realistis - menghasilkan project schedule yang teratur

The Management Spectrum - The Process Tiga P’s: software project management yang efektif terfokus pada tiga P’s:(1) people, (2) problem, dan (3) process - Process: Software process menyediakan framework berupa -> perencanaan yang komprehensif dari software development Framework dpt diterapkan utk ALL PROJECT SW tanpa mempedulikan UKURAN dan KOMPLEKSITAS - tasks (tugas-tugas) tiap Framework - milestones berbeda-beda - deliverables (kemampuan penyampaian) disesuaikan Karakteristik PL - quality assurance points (jaminan kualitas) dan kebutuhan TIM Project Aktifitas pelindung -> tdk tergantung pd Framework, melainkan melapisi model proses Framework - software quality assurance - software configuration management - measurement

People Pada software process, terdapat 5 tipe players: Senior managers, yang mendefinisikan dari masalah bisnis (berpengaruh kuat terhadap project) Project (technical) managers, seseorang yang harus merencanakan, memotivasi, mengorganisasikan, mengontrol sebuah produk / aplikasi Practitioners, yang akan mengantar pada kemampuan teknik untuk engineering software sebuah produk / aplikasi 4. Customers, seseorang yang akan menspesifikasikan requirements dari software 5. End users, seseorang yang berinteraksi software yang akan direleased

People - Team Leaders Project management merupakan aktivitas dari orang-orang yang bersifat intensif Bagaimana memilih team manager yang baik? Model MOI yang disarankan oleh Jerry Weinberg [WEi86]: KEMAMPUAN : Motivation - memberi dorongan orang teknik utk menghasilkan sesuatu dgn kemampuan terbaiknya Organization - menyediakan proses yg berlangsung sebagai initial konsep yang akan ditranslasikan menjadi final product Ideas or innovation - mendorong inovasi dan kreatifitas utk produk / aplikasi yang spesifik Software managers harus terkonsentrasi pada - pengertian masalah yang akan dipecahkan - pengaturan ide - membiarkan seseorang dalam team mengetahui jumlah kualitas

People - Team Leaders.....CONTD Empat kunci utama sebagai project management yang efektif [EDG95] : 1. Problem solving -membaca isu-isu bisnis -memcahkan masalah dan alternatif solusi -memotivasi orang teknik dlm solving problem dan create inovation dan creativity - mengadopsi project-project sebelumnya ke project baru -fleksibel dlm menghadapi masalah yg tdk membuahkan hasil 2. Managerial identity - terlibat langsung ke dalam Project - PD - controlling - memberikan kebebasan berinovasi 3. Achievement -memiliki inisiatif dan prestasi  meningkatkan produktivitas TIM - reward - insentif - career development -prestice 4. Influence dan team building - mampu membaca “manusia” baik verbal maupun non verbal - menguasai diri dalam tekanan yang tinggi

People - Software Team Mantei [MAN81] menyarankan tiga team organisasi yang kuat : - Democratic decentralized (DD): - software engineering tidak memiliki pemimpin yang tetap. - keputusan dibuat dari ketetapan group - komunikasi diantara team harus bersifat horisontal - Controlled decentralized (CD): - memiliki pemimpin -> koordinasi antara spesific task dan pemimpin kedua - pemimpin kedua harus memiliki tanggung jawab untuk masing- masing subtask - komunikasi horisontal terjadi diantara subgroups dan individual - komunikasi vertikal terjadi pada struktur kontrol - keputusan dibuat oleh pemimpin - Controlled centralized (CC): - pemimpin mengatur pemecahan masalah pada top level dan koordinasi team internal - komunikasi antara pemimpin dan anggota team adalah vertikal Struktur TIM PL “terbaik”, tergantung pada : GAYA MANAJEMEN dalam organisasi Jumlah orang yg terlibat Kemampuan personal Kompleksitas masalah yg dipecahkan

People - The Software Team group Team leader secondary team leader communication DD: CC: CD:

People - The Software Team Pn FTm X T1 Tm Project manager+ informal teams with coordinator Functional tasks team engineer Project manager + team leaders Project manager + n engineers + m tasks

People - The Software Team 7 faktor project yang terhubung dengan struktur team project : Kesulitan dalam pemecahan masalah Ukuran dari resultant program Modularity dari program Reliability dari software (keandalan sistem) Team life time (umur hidup tim) Rigidity dari delivery date (tanggal pengiriman) Tingkat dari sociability (communication overhead) Team Type DD CD CC Difficulty High Low Low Size Small Large Large Team Life Time Long Short Short Modularity Low High High Reliability High High Low Delivery date Lax Lax Strict Sociability High Low Low Strict = ketat Lax = longgar

Constantine [CON’93] menyarankan empat “organization paradigms” People - The Software Team Constantine [CON’93] menyarankan empat “organization paradigms” Untuk team software engneering: A closed paradigm: Tim dgn hirarki tradisional (sama dg CC) Dapat bekerja dg baik jika dgn studi kasus yg pernah ditangani sebelumnya Tim kurang inovatif Random paradigm: -Tim agak longgar dan tergantung pd inisiatif individu anggota tim - mengikuti perkembangn inovasi /teknologi Open paradigm: - heavy communication (dss) + control structure like CC - sesuai utk pemecahan masalah yg kompleks tetapi tidak bekerja seefisien tim yg lain Synchronous paradigm: - lebih fleksibel dalam Tim - manajemen job desk sesuai dgn kompleksitas masalah - komunikasi efektif antar tim

Chief programmer team (by Harlan Mills described in Baker’s [BAK72]) : (1) a senior engineer (pemrogram utama) - merencanakan, mengkoordinasi, mengkaji semua aktivitas teknik tim (2) technical staff (2-5) - analisis dan mengembangkan aktivitas (3) a backup engineer - mendukung senior engineer dlm aktivitsny - menggantikan utk masalah yg berkaitan dgn proyek (4) support staff - spesialis (pakar telekomunikasi, perancang Database, Jaringan) - staff pembantu (e.g. technical writers) (5) software librarian (1). - controll : dokumentasi, daftar sumber data, media magnetik - collect dan format data produktivitas PL, katalog dan indeks modul PL yg reuseable -support TIM utk penelitian, evaluasi dan penyiapan dokumen. Book “Peopleware” oleh DeMarco dan Lister discussed “jelled team”:. jelled team merupakan group dari people . Mereka tidak mengerti cara mengatur secara tradisional, mereka tidak memerlukan motivasi. -----analogi sperti jely....sifat nya membeku, lentur /kenyal tapi kokoh -tidk peRlu diatur dgn struktur tradisional dan tidak perlu dimoitivasi ANGGOTA TIM YG MEMBEKU- LEBIH PRODUKTIF DAN LEBIH TERMOTIVASI

People – Coordination dan Communication Issues Beberapa kegagalan disebabkan dari project software. Disini terdapat beberapa yang berhubungan dengan komunikasi dan koordinasi dari project : Skala yang lebih luas dari development efforts  kompleksitas, konfusion, dan kesulitan yang signifikan pada koordinasi team Ketidakpastian pada perubahan requirement dan status team Interoperability  interoperations diantara systems Mekanisme komunikasi formal dan informal yang baik dan efektif : Pendekatan formal impersonal documents, deliverables, memos, project milestones, schedules, project control tools, perubahan permintaan , dan related documents, error tracking reports dan data. Formal, interpersonal procedures aktivitas jaminan kualitas (code dan design inspection, review meeting) Informal, interpersonal procedures informal group meeting (seperti meeting dengan customers dan users) Electronic communication (email, web sites, video-based conference) Interpersonal network (komunikasi dgn orang-orang diluar project yg memiliki pengetahuan dan pengalaman yg mendukung anggota TIM)

Problem - Software Scope Project manager dari software harus terhubung dengan masalah awal pada project software engineering Software scope: (a) Context: Bagaimana software dibuat secara lengkap kedalam sistem yang luas, product atau bisnis? Apa yang menjadi constraint dalam hasil konteks? (b) Information objectives: Apakah customer sesuai dengan data objects yang dihasilkan sebagai output dari software? Apakah data object dibutuhkan untuk input? ( c) Function and performance: Apakah fungsi akan menunjukkan software untuk mentransform input data menjadi output? Apakah ada beberapa karakteristik special performance yang akan digunakan?

Problem Decomposition Problem decomposition --> problem partitioning. Problem decomposition --> dua area: functionality dari delivery software system process yang akan digunakan untuk mengantarkan system Functional decomposition: mengidentifikasi dan mendefinisikan cakupan fungsi dari sistem mengaplikasikan metode dekomposisi pada masing-masing feature Sebagai contoh pada function feature untuk word processing system : spell checking sentence grammar checking reference checking untuk large documents section dan chapter reference validation untuk large documents.

Process - Melding Problem dan Process Masing-masing fungsi akan menjadi engneered dari team software melalui aktivitas framework : Komunikasi customer – tugas untuk membangun komunikasi yang efektif diantara customer Planning – tugas untuk mendefinisikan resource, timelines dsb Analisis resiko – tugas untuk menerima resiko teknik dan management Engineering – tugas untuk membangun sistem aplikasi Construction dan release - installation, release control, dan customer support. Customer evaluation – tugas untuk mendapatkan feedback dari customer dan hasil evaluasi Process decomposition: Partition the software process based on the tasks and activities memilih model software process untuk project mendefinisikan preliminary project plan berdasarkan aktivitas proses framework common process framework (CPF)

Process - Process Decomposition Project yang kecil memerlukan beberapa tugas : mendevelop list dari masalah yang telah diklarifikasi bertemu dengan customer untuk mengklarifikasikan masalah menggabungkan cakupan dari beberapa statement mereview state dari scope memodifikasikan cakupan statement yang diperlukan Project yang komplit memerlukan beberapa tugas : Mereview permintaan customer Merencanakan dan menjadwalkan secara formal, fasilitas pertemuan dengan customer Mengharapkan penelitian untuk mendefinisikan solusi dan pendekatan yang ada Menyiapkan “dokumen pekerjaan” dan agenda untuk pertemuan formal Mengharapkan terjadinya pertemuan Mengembangkan mini-spec untuk perbaikan, konsistensi, dan kelemahan pada ambiguitas Memodifikasi cakupan dokumen yang diperlukan