Konsep Manajemen Proyek Perangkat Lunak

Perangkat Lunak, sekarang ini dikembangkan dengan pendekatan manajemen proyek. Apa artinya? Dalam hal ini, kita, sebagai pengembang perangkat lunak, memahami bahwa perangkat lunak itu adalah sebuah produk. Dan sebagaimana halnya sebuah produk, maka untuk menghasilkan produk yang berkualitas, perangkat lunak perlu dibuat dengan mengikuti alur proses tertentu yang terukur. Pengelolaan perangkat lunak merupakan hal penting dalam menjamin kualitas produk perangkat lunak itu sendiri.

Pressman mengemukakan beberapa pokok pikiran terkait konsep manajemen proyek perangkat lunak, diantaranya adalah:

1) Project management involves the planning, monitoring, and control of people, process, and events that occur during software development.

2) Everyone manages, but the scope of each person's management activities varies according his or her role in the project.

3) Software needs to be managed because it is a complex undertaking with a long duration time.

4) Managers must focus on the fours P's to be successful (people, product, process, and project).

5) A project plan is a document that defines the four P's in such a way as to ensure a cost effective, high quality software product.

6) The only way to be sure that a project plan worked correctly is by observing that a high quality product was delivered on time and under budget.

Pokok pikiran yang dikemukakan Pressman dapat menjadi dasar kerangka acuan berpikir dari pengembang perangkat lunak. Lihat pokok pikiran 3) misalnya, disitu disebutkan bahwa perangkat lunak, perlu dikelola karena merupakan produk yang kompleks, yang harus dikerjakan dalam kurun waktu tertentu yang relatif cukup lama. Hal ini sangat tepat, dalam konteks perangkat lunak dewasa ini. Sebuah aplikasi stand-alone saja sudah terdiri dari puluhan halaman kode (diukur dengan satun LOC atau Lines of Code); belum lagi ditambah dengan banyaknya "konektivitas" (misalnya koneksi antar-muka, koneksi basis data, jaringan dan sebagainya). Sesungguhnya isu kompleksitas perangkat lunak, merupakan isu yang tidak terbantahkan di era Web 2.0 sekarang ini. Rancang bangun perangkat lunak yang sederhana merupakan tantangan tersendiri bagi tim pengembang.

Mari kita lihat, pokok pikiran Pressman yang ke 4). Disini Pressman menekankan mengenai spektrum manajemen perangkat lunak, yakni:

1) People (recruiting, selection, performance management, training, compensation, career development, organization, work design, team/culture development) 

2) Product (product objectives, scope, alternative solutions, constraint tradeoffs)

3) Process (framework activities populated with tasks, milestones, work products, and QA points)

4) Project  (planning, monitoring, controlling)

Fokus manajemen perangkat lunak, tidak melulu pada "product" atau working-software itu sendiri. Selain itu, diperlukan fokus untuk mengelola People (yakni semua yang terlibat dalam pengembangan perangkat lunak); Process (atau bisa disebut sebagai kerangka kerja, metodologi yang digunakan dalam mengembangkan perangkat lunak) serta Project (yang dapat dipahami sebagai aktivitas perencanaan, pengawasan dan pengendalian).

Terkait fokus manajemen PEOPLE; maka isu yang harus diperhatikan adalah bagaimana berkomunikasi. Pengalaman saya dalam mengembangkan perangkat lunak, maka semakin banyak stakeholders (dan tim pengembang) maka semakin besar juga bias dalam saluran komunikasi standar antar stakeholders (dan tim pengembang). Dalam berkomunikasi standar, kita menggunakan bahasa, namun demikian kadang ditemui, arti dan makna bahasa tertentu, sering dipahami berbeda. Isu ini akan mencuat jika tim pengembang terdiri dari anggota tim lintas generasi (perbedaan umur yang signifikan), kultur budaya yang berbeda serta lintas organisasi (atau lintas departemen). Diperlukan sebuah mekanisme komunikasi yang handal untuk menjamin saling pengertian antar tim pengembang. Tentu saja, secara pribadi, saya sangat menyarankan untuk menggunakan mekanisme: "tatap muka".

Terkait fokus manajemen PRODUCT, maka isu yang muncul biasanya adalah "scope creep", atau bertambahnya (berubahnya) fitur aplikasi. Scope creep muncul dari stakeholders, user dan tim pengembang sendiri. Mengatasi hal ini, bisa dengan sebuah kesepakatan formal mengenai fitur-fitur aplikasi yang dikembangkan. Atau jika terjadi perubahan, dikompensasi dengan besarnya cost pengembangan aplikasi. Isu lainnya yang penting juga adalah masalah kualitas perangkat lunak yang dihasilkan. Aktivitas pengujian perangkat lunak harus benar-benar dilakukan dan terdokumentasi dengan baik. Tidak bisa hanya sekedar melakukan Uji Acceptance; tapi juga HARUS melakukan uji teknis (dalam beberapa tipe uji perangkat lunak). Stakeholders harus memahami bahwa satu-satunya cara menjamin kualitas perangkat lunak adalah dengan melakukan uji perangkat lunak.

Terkait fokus manajemen PROCESS, maka isu yang harus diperhatikan adalah dokumentasi perangkat lunak. Pada dasarnya perangkat lunak itu adalah algoritma program yang menjalan proses bisnis tertentu, mengolah data dan DOKUMENTASI. Dokumentasi perangkat lunak, bukanlah sekedar Panduan Instalasi atau Panduan Menggunakan Aplikasi, tapi juga menyangkut setiap proses pengembangan perangkat lunak yang dilakukan. Hal ini penting untuk kepentingan manajemen proyek dan terlebih untuk kepentingan pemeliharaan perangkat lunak itu sendiri.

Model Proses Perangkat Lunak AGILE

Roger Pressman mengemukakan beberapa hal terkait model proses perangkat lunak agile (lunak); yakni:

Agile software engineering represents a reasonable compromise between to conventional software. 

Agile development processes can deliver successful systems quickly

Agile development stresses continuous communication and collaboration among developers and customers

Agile software engineering embraces a philosophy that encourages customer satisfaction, incremental software delivery, small project teams (composed of software engineers and stakeholders), informal methods, and minimal software engineering work products 

Agile software engineering development guidelines stress on-time delivery of an operational software increment over analysis and design (the only really important work product is an operational software increment)

Yang dapat dipahami dari pendapat Roger Pressman tersebut adalah model proses agile merupakan suatu model proses perangkat lunak yang menitikberatkan pada membangun perangkat lunak yang cepat, dan di-delivered kepada pengguna dengan cepat.

Apakah paradigma agile berarti "mengabaikan" disiplin software engineering? Tentu saja tidak! Karena yang namanya "process model" tentu saja, masih ber-proses. Dan proses memiliki pentahapan dengan sejumlah aktivitas tertentu yang harus dikerjakan. Pendapat saya, model proses agile, harus dipahami dalam konteks melibatkan user (dan stakeholders lainnya) secara penuh dalam pengembangan perangkat lunak; dengan terus-menerus mengadopsi kebutuhan user (yang akan cenderung berubah-ubah); dengan demikian harus memiliki tim pengembang yang siap dengan perubahan.

Silahkan melihat juga tulisan saya tentang Paradigma Web 2.0: Agile Process disini:

http://stanlysk.blogspot.com/2012/05/paradigma-web-20-agile-process.html

Pressman mengemukakan beberapa prinsip terkait model proses agile, diantaranya adalah:

1. Highest priority is to satisfy customer through early and continuous delivery of valuable software

2. Welcome changing requirements even late in development, accommodating change is viewed as increasing the customer’s competitive advantage

3. Delivering working software frequently with a preference for shorter delivery schedules (e.g. every 2 or 3 weeks)

4. Business people and developers must work together daily during the project

5. Build projects around motivated individuals, given them the environment and support they need, trust them to get the job done

6. Face-to-face communication is the most effective method of conveying information within the development team

7. Working software is the primary measure of progress

8. Agile processes support sustainable development, developers and customers should be able to continue development indefinitely

9. Continuous attention to technical excellence and good design enhances agility

10. Simplicity (defined as maximizing the work not done) is essential

11. The best architectures, requirements, and design emerge from self-organizing teams 

12. At regular intervals teams reflects how to become more effective and adjusts its behavior accordingly

Dari pengalaman saya, dalam mengembangkan perangkat lunak dengan pendekatan agile, maka prinsip utama yang harus dimiliki adalah KOMITMEN. Yakni komitmen tim pengembang dan komitmen stakeholders untuk terlibat dalam pengembangan perangkat lunak sepenuhnya. Tidak ada prinsip kunci lain yang dibutuhkan dalam pengembangan agile.

Silahkan lihat disini, sebuah contoh model proses pengembangan perangkat lunak dengan pendekatan agile:

Bagian Pertama: http://stanlysk.blogspot.com/2012/06/research-paper-web-portal-ans.html

Bagian Kedua: http://stanlysk.blogspot.com/2012/06/research-paper-web-portal-ans-part-ii.html

Pressman mengemukakan beberapa varian dari model proses agile yakni:

Extreme Programming (XP)

Adaptive Software Development (ASD)

Scrum

Dynamic Systems Development Method (DSDM)

Crystal

Feature Driven Development (FDD)

Lean Software Development (LSD)

Agile Modeling (AM)

Agile Unified Process (AUP)

Universitas Indonesia (dalam ini Pusat Ilmu Komputer UI) mengemukakan sebuah model proses agile yang disebut PAUS (Pusilkom Agile Unified Process). Selengkapnya dapat dilihat pada link ini: http://ecl.cs.ui.ac.id/PAUS/index.htm

Rapid Prototyping Methodology

Prototyping merupakan salah satu Model Proses Perangkat Lunak. Pendekatan ini sering digunakan dalam pembuatan tugas proyek perangkat lunak ataupun dalam Laporan Kerja Praktek dan Tugas Akhir mahasiswa. Salah satu varian dari Model Proses Prototyping ini adalah Rapid Prototyping.

Langkah dari Rapid Prototyping adalah sebagai berikut:
1. Requirement Gathering and Analysis
Pengembang aplikasi mengumpulkan dan menganalisa kebutuhan lebih detail dari sistem yang akan dibangun. Deliverable: kebutuhan sistem rinci (detailed system requirements).
2. Quick Design and Rapid Prototyping
Pengembang aplikasi menggunakan pendekatan prototipe cepat untuk membangun rancangan sistem, termasuk tata letak menu dan basis data. Dalam fase ini pengguna akan diminta pendapat terhadap rancangan yang dibuat. Kemudian bila ada perubahan, rancangan akan disesuaikan hingga memenuhi kebutuhan pengguna. Rancangan ini harus menggarisbawahi fitur yang paling penting dari sistem. Deliverable: prototipe sistem (system prototype).
3. Implementation
Keterlibatan pengguna dalam fase implementasi merupakan keharusan. Hasil sementara akan selalu dikonfirmasikan ke pengguna untuk mendapatkan masukan. Deliverable: sistem yang sudah jadi.
4. Test and Release 
Fase ini juga dikenal sebagai konversi ke sistem operasional. Karena pengguna telah berperan aktif dalam Fase Perancangan dan Implementasi, seharusnya pada fase ini hanya sangat sedikit perubahan bila masih ada. Bila masih ada perubahan, maka kembali ke fase sebelumnya. Deliverable: dokumentasi dan hasil uji coba

Beberapa acuan dalam menggunakan metode ini dapat dilihat disini:
https://docs.google.com/file/d/0BxSxy7HfW5oJMGNjMTc0NDAtYmViOC00OTY3LWFkYmYtNDA5MzMwNmFhZTg1/edit


Dibawah ini adalah sebuah Gambar dari langkah-langkah model proses Rapid Prototyping Methodology:

Model Proses Perangkat Lunak

Hingga kini, kita mengenal beberapa Model Proses Perangkat Lunak, sebagai berikut:

• Waterfall Model (classic life cycle - old fashioned but reasonable approach when requirements are well understood)

• Incremental Models (deliver software in small but usable pieces, each piece builds on pieces already delivered)

• Evolutionary Models

o Prototyping Model (good first step when customer has a legitimate need, but is clueless about the details, developer needs to resist pressure to extend a rough prototype into a production product)

o Spiral Model (couples iterative nature of prototyping with the controlled and systematic aspects of the Waterfall Model)

• Concurrent Development Model (concurrent engineering - allows software teams to represent the iterative and concurrent element of any process model)

Selain itu, juga terdapat beberapa Model Proses Khusus, yaitu:

• Component-Based Development (spiral model variation in which applications are built from prepackaged software components called classes)

• Formal Methods Model (rigorous mathematical notation used to specify, design, and verify computer-based systems)

• Aspect-Oriented Software Development (aspect-oriented programming - provides a process for defining, specifying, designing, and constructing software aspects like user interfaces, security, and memory management that impact many parts of the system being developed)

Memasuki tahun 2000-an, seiring dengan makin berkembangnya paradigma pemrograman berorientasi obyek, maka berkembang juga model proses perangkat lunak yang disebut Unified Proces, dengan ciri-ciri sebagai berikut:

• Use-case driven, architecture centric, iterative, and incremental software process

• Attempts to draw on best features of traditional software process models and implements many features of agile software development

• Phases

1) Inception phase (customer communication and planning)

2) Elaboration phase (communication and modeling)

3) Construction phase

4) Transition phase (customer delivery and feedback)

5) Production phase (software monitoring and support)

Beberapa Pemikiran dalam Rekayasa Perangkat Lunak

Rekayasa Perangkat Lunak

Apa yang dimaksud dengan Rekayasa Perangkat Lunak itu? 

Software engineering is the establishment of sound engineering principles in order to obtain reliable and efficient software in an economical manner.

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

Software engineering encompasses a process, management techniques, technical methods, and the use of tools.

Kerangkat Kerja Umum Proses Perangkat Lunak
1. Komunikasi/Communication (customer collaboration and requirement gathering)

2. Perencanaan/Planning (establishes engineering work plan, describes technical risks, lists resources required, work products produced, and defines work schedule).

3. Pemodelan/Modeling (creation of models to help developers and customers understand the requires and software design)

4. Konstruksi atau Rancang Bangun/Construction (code generation and testing)

5. Deployment (software delivered for customer evaluation and feedback)


Software Engineering Umbrella Activities

1. Software project tracking and control (allows team to assess progress and take corrective action to maintain schedule)
2. Risk management (assess risks that may affect project outcomes or quality)
3. Software quality assurance (activities required to maintain software quality)
4. Technical reviews (assess engineering work products to uncover and remove errors before they propagate to next activity)
5. Measurement (define and collect process, project, and product measures to assist team in delivering software meeting customer needs)
6. Software configuration management (manage effects of change)
7. Reusability management (defines criteria for work product reuse and establish mechanisms to achieve component reuse)
8. Work product preparation and production (activities to create models, documents, logs, forms, lists, etc.)

Esensi Dasar dalam Praktek Pengembangan Perangkat Lunak
1. Memahami Konteks Permasalahan (dengan melakukan komunikasi dan analisis)

2. Merencanakan Solusi (perancangan perangkat lunak)

3. Mengeksekusi Rencana Solusi (kodifikasi dan debugging) 

4. Review Hasil untuk Akurasi (dengan melakukan testing dan jaminan kualitas)

Berikut adalah penjelasan masing-masing
(1) Understand the Problem
•    Who are the stakeholders?
•    What functions and features are required to solve the problem?
•    Is it possible to create smaller problems that are easier to understand?
•    Can a graphic analysis model be created?
(2) Plan the Solution
•    Have you seen similar problems before?
•    Has a similar problem been solved?
•    Can readily solvable subproblems be defined?
•    Can a design model be created?
(3) Carry Out the Plan
•    Does solution conform to the plan?
•    Is each solution component provably correct?
(4) Examine the Result
•    Is it possible to test each component part of the solution?
•    Does the solution produce results that conform to the data, functions, and features required?