1 / 46

Rekayasa Perangkat Lunak

Rekayasa Perangkat Lunak. Pertemuan IV Bab 3 – Konsep Manajemen Proyek. :: Pendahuluan. Manajemen proyek software yang efektif difokuskan pada 4 P yaitu: People Product Process Project. The People.

liam
Download Presentation

Rekayasa Perangkat Lunak

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Rekayasa Perangkat Lunak Pertemuan IV Bab 3 – Konsep Manajemen Proyek

  2. :: Pendahuluan Manajemen proyek software yang efektif difokuskan pada 4 P yaitu: • People • Product • Process • Project

  3. 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 • team/culture development.

  4. 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 indication of progress.

  5. 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, software configuration management, and measurement—overlay the process model.

  6. 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 project.

  7. The People The Players: • Senior Managers • Project (Technical) managers • Practioners • Customers • End user

  8. SUMBER DAYA MANUSIA • Senior Managers Mendefinisikan isu bisnis yang sangat berpengaruh pada proyek. Bisnis adalah kegiatan aktivfitas/project yang sedang dibuat.

  9. SUMBER DAYA MANUSIA • Project (Technical) managers Merencanakan, memodifikasi, mengorganisasi dan mengontrol para praktisi yang menjalankan pekerjaan software.

  10. SUMBER DAYA MANUSIA • Practioners Mempunyai skill teknis yang dibutuhkan untuk merekayasa sebuah produk atau aplikasi. Ex. Programmer, DBA, Analis, Tester, Documentator, etc.

  11. SUMBER DAYA MANUSIA • Customers Menyatakan kebutuhan rekayasa software.

  12. SUMBER DAYA MANUSIA • End user Yang berorientasi dengan software setelah software diproduksi.

  13. 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. • Ideas atau Innovations Kemampuan untuk membangkitkan kreasi para anggota.

  14. 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 tekanan tinggi.

  15. ORGANISASI TIM SOFTWARE Secara umum ada 3 macam organisasi tim software, yaitu: • Democratic Decentralized (DD) • Controlled Decentralized (CD) • Controlled Centralized (CC)

  16. 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 anggota tim dilakukan secara horisontal.

  17. 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 vertikal sesuai dengan hirarki kendali juga dilakukan.

  18. 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.

  19. 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. 7. Tingkatan komunikasi yang diperlukan untuk proyek.

  20. ORGANISASI TIM SOFTWARE • Tabel 3-1 Pengaruh karakteristik proyek pada struktur tim.

  21. KOORDINASI & KOMUNIKASI Ada beberapa kategori teknik koordinasi proyek: • Formal, Interpersonal Approaches • Formal, interpersonal procedures • Informal, interpersonal procedures • Electronic Communication • Interpersonal Network

  22. Formal, Interpersonal Approaches Termasuk didalamnya: • Dokumentasi rekayasa software dan deliverable (misal: source code). • Memo teknis • Project milestone • Jadwal • Project control • Permintaan perubahan • Error tracking report • Repository data

  23. Formal, interpersonal procedures Ditekankan pada kualitas, termasuk didalamnya: • Status review meeting • Desain • Inspeksi code

  24. Informal, interpersonal procedures Termasuk didalamnya: • Pertemuan tim untuk tukar informasi dan solusi problem. • Kebutuhan dan pengembangan staf.

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

  26. Interpersonal Network • Diskusi informal dengan pihak luar yang mempunyai pengalaman/pandangan untuk membantu anggota tim.

  27. Komunikasi • Gambar 3-1 Batasan proyek

  28. 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.

  29. Batasan software Aktifitas manajemen proyek yang pertama adalah menentukan batasan software. Batasan tersebut bisa diperoleh dengan menjawab pertanyaan sebagai berikut: • Context • Information objectives • Function and performance

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

  31. Information objectives • Apa saja object data yang customer visible dihasilkan sebagai output dari software ? • Apa saja object data yang diperlukan untuk input ?

  32. Function and performance • Fungsi apa saja yang harus dilakukan software untuk mentransformasikan data input menjadi output? • Apakah terdapat karakter performance khusus yang diminta?

  33. 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 • etc

  34. 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 works.

  35. Melding the Product and the Process • Customer communication • Planning • Risk analysis • Engineering • Construction and release • Customer evaluation

  36. customer communicationactivity: • 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.

  37. 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.

  38. 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. • 10. Managers [and practitioners] avoid best practices and lessons learned.

  39. 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 money?

  40. 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.

  41. 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.

  42. 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.

  43. 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.

  44. 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.

  45. Selesai  • Pertemuan selanjutnya diawali dengan presentasi kelompok mahasiswa.

More Related