Chapter 3 Konsep Manajemen RPL

  Rekayasa Perangkat Lunak

  Pertemuan IV

  :: Pendahuluan

  Manajemen proyek software yang efektif difokuskan pada 4 P yaitu:

   People

   Product

   Process

  The People 

  The people management maturity model defines the following key practice areas for software people:

   recruiting,

   selection,

   performance management,

   training,

   compensation,

   career development,

   organization and work design, and

   The Product 

  Before a project can be planned,

  

Product1 objectives and scope should be established,

   Alternative solutions should be considered, and

   Technical and management constraints should be identified.

  

  Without this information, it is impossible to define

   reasonable (and accurate) estimates of the cost,

   an effective assessment of risk,

   a realistic breakdown of project tasks, or

   a manageable project schedule that provides a meaningful The Process 

  A small number of framework activities are applicable to all software projects, regardless of their size or complexity.

  

  A number of different task sets—tasks, milestones, work products, and quality assurance points—enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team.

  

  Umbrella activities—such as software quality assurance, The Project 

  Industry data indicated that 26 percent of software projects failed outright and 46 percent experienced cost and schedule overruns.

  

  In order to avoid project failure, a software project manager and the software engineers who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management, and develop a commonsense approach for planning, monitoring and controlling the

  The People The Players: 1. Senior Managers 2. Project (Technical) managers 3. Practioners 4. Customers

SUMBER DAYA MANUSIA

   Senior Managers

  Mendefinisikan isu bisnis yang sangat berpengaruh pada proyek. Bisnis adalah kegiatan aktivfitas/project yang sedang dibuat.

SUMBER DAYA MANUSIA

   Project (Technical) managers

  Merencanakan, memodifikasi, mengorganisasi dan mengontrol para praktisi yang menjalankan pekerjaan software.

SUMBER DAYA MANUSIA

   Practioners

  Mempunyai skill teknis yang dibutuhkan untuk merekayasa sebuah produk atau aplikasi.

  Ex. Programmer, DBA, Analis, Tester, Documentator, etc.

SUMBER DAYA MANUSIA

   Customers Menyatakan kebutuhan rekayasa software.

SUMBER DAYA MANUSIA

   End user

  Yang berorientasi dengan software setelah software diproduksi.

  Team Leaders

  Model kepemimpinan:

   Motivation (membangkitkan semangat tim)

  Mampu untuk membangkitkan teknis anggota untuk menghasilkan yang terbaik.

   Organization

  Kemampuan untuk mengelola proses yang ada (atau menemukan sesuatu yang baru) untuk menterjemahkan suatu konsep menjadi produk akhir.

  

  Team Leaders 

  Problem Solving

  mendiagnosa masalah, menyusun solusi, belajar dari pengalaman, berani melawan arus.

   Managerial identity tanggung jawab, percaya diri, insting kuat.

   Achievement pengambilan resiko yang terkendali tidak akan dihukum.

   Influence & team building

  bisa membaca dan memahami orang, tahan dalam

ORGANISASI TIM SOFTWARE

  Secara umum ada 3 macam organisasi tim software, yaitu:

   Democratic Decentralized (DD)

   Controlled Decentralized (CD)

  

ORGANISASI TIM SOFTWARE

   Democratic Decentralized (DD) Tim rekayasa software ini tidak mempunyai permanen leader . Koordinasi ditunjuk untuk jangka pendek dan kemudian diganti lainnya yang mampu mengkoordinasi tugas yang berbeda. Pengambilan keputusan dilakukan melalui konsensus kelompok . Komunikasi antar

ORGANISASI TIM SOFTWARE

   Controlled Decentralized (CD) Tim rekayasa software telah menunjuk seorang leader yang mengkoordinir tugas-tugas tertentu

dan secondary leader yang bertanggung jawab

atas sub-sub pekerjaan. Solusi permasalahan

dilakukan secara kelompok , tetapi implementasi solusi dibagi-bagi ke sub-sub kelompok oleh tim leader. Komunikasi antar sub kelompok dan individu dilakukan secara horisontal . Komunikasi

ORGANISASI TIM SOFTWARE

   Controlled Centralized (CC) Solusi problem dan koordinasi tim internal diatur oleh team leader . Komunikasi antar leader dan anggota tim dilakukan secara vertikal .

ORGANISASI TIM SOFTWARE

  

Ada tujuh faktor yang perlu dipertimbangkan

pada saat merencanakan struktur tim rekayasa software yaitu: 1. Tingkat kesulitan problem yang harus diselesaikan.

  2. Ukuran program (line of code maupun function point).

  3. Tingkatan problem yang bisa dimodulkan (dipecahkan).

  4. Waktu tim bisa bekerja bersama-sama (team life time).

  5. Kualitas dan reliability sistem yang akan dibuat.

  6. Tanggal penyerahan software yang ketat.

ORGANISASI TIM SOFTWARE

   Tabel 3-1 Pengaruh karakteristik proyek pada struktur tim.

  KOORDINASI & KOMUNIKASI

Ada beberapa kategori teknik koordinasi proyek:



  Formal, Interpersonal Approaches 

  Formal, interpersonal procedures 

  Informal, interpersonal procedures 

  Electronic Communication

  Formal, Interpersonal Approaches Termasuk didalamnya: 

  Dokumentasi rekayasa software dan deliverable (misal: source code).

   Memo teknis

   Project milestone

   Jadwal

   Project control

   Permintaan perubahan

  Formal, interpersonal procedures

  Ditekankan pada kualitas , termasuk didalamnya:

  

  Status review meeting

  

  Desain

  

  Informal, interpersonal procedures

  Termasuk didalamnya:

   Pertemuan tim untuk tukar informasi dan solusi problem.

   Kebutuhan dan pengembangan staf.

  Electronic Communication 

  Dilakukan melalui E-mail, electronic Bulletin boards, web sites, video based conference system.

  Interpersonal Network 

  Diskusi informal dengan pihak luar yang mempunyai pengalaman/pandangan untuk membantu anggota tim.

  Komunikasi 

  Gambar 3-1 Batasan proyek

  The Product 

  A software project manager is confronted with a dilemma at the very beginning of a software engineering project.

  

  Quantitative estimates and an organized plan are required, but solid information is unavailable.

  

  A detailed analysis of software requirements would provide necessary information for estimates, but analysis often takes weeks or months to complete.

  

  Worse, requirements may be fluid, changing regularly as the project proceeds.

  Batasan software Aktifitas manajemen proyek yang pertama adalah menentukan batasan software. Batasan tersebut bisa diperoleh dengan menjawab pertanyaan sebagai berikut:

   Context

   Information objectives

  Context 

  Bagaimana software dibuat untuk memenuhi sistem yang lebih besar, produk atau business context dan kendala yang ditimbulkan akibat context tersebut ?

  Information objectives 

  Apa saja object data yang customer visible dihasilkan sebagai output dari software ?

  

  Apa saja object data yang diperlukan untuk input ?

  Function and performance 

  Fungsi apa saja yang harus dilakukan software untuk mentransformasikan data input menjadi output?

  

  Apakah terdapat karakter performance khusus yang diminta? The Process 

  

The generic phases that characterize the software process—

definition, development, and support—are applicable to all software. The problem is to select the process model that is appropriate for the software to be engineered by a project team.

   Software engineering paradigms were discussed:

   the linear sequential model

   the prototyping model

   the RAD model

   the incremental model

   the spiral model

   the component-based development model

  

  The project manager must decide which process model is most appropriate for

  

  (1) the customers who have requested the product and the people who will do the work, Once the process model is chosen, populate it with the minimum set of work tasks and work products that will result in a high-quality product—avoid process overkill!

  

  (2) the characteristics of the product itself, and

  

  (3) the project environment in which the software team

  

Melding the Product and the

Process 

  Customer communication 

  Planning 

  Risk analysis 

  Engineering 

  Construction and release

  customer communication activity:  1. Develop list of clarification issues. 

  2. Meet with customer to address clarification issues.

   3. Jointly develop a statement of scope. 

  4. Review the statement of scope with all concerned.

   5. Modify the statement of scope as required.

  The Project 

  In order to manage a successful software project, we must understand what can go wrong (so that problems can be avoided) and how to do it right. Project’s problems  1. Software people don’t understand their customer’s needs.  2. The product scope is poorly defined.  3. Changes are managed poorly.  4. The chosen technology changes.  5. Business needs change [or are ill-defined].  6. Deadlines are unrealistic.  7. Users are resistant.  8. Sponsorship is lost [or was never properly obtained].  9. The project team lacks people with appropriate skills.

THE W5HH PRINCIPLE

   Why is the system being developed?

  The answer to this question enables all parties to assess the validity of business reasons for the software work. Stated in another way, does the business purpose justify the expenditure of people, time, and

   What will be done, by when? The

  answers to these questions help the team to establish a project schedule by identifying key project tasks and the milestones that are required by the customer.

   Who is responsible for a function?

  Earlier in this chapter, we noted that the role and responsibility of each member of the software team must be defined. The answer to this question helps accomplish this.

   Where are they organizationally

located? Not all roles and responsibilities

  reside within the software team itself. The customer, users, and other stakeholders also have responsibilities.

   How will the job be done technically

and managerially? Once product scope

  is established, a management and technical strategy for the project must be defined.

  

How much of each resource is needed?

  The answer to this question is derived by developing estimates (Chapter 5) based on answers to earlier questions. Selesai  

  Pertemuan selanjutnya diawali dengan presentasi kelompok mahasiswa.