Sabtu, 24 Maret 2012

"AUDIT INFORMATION SYSTEM ..."


Introduction

An information system (IS) audit or information technology(IT) audit is an examination of the controls within an entity's Information technology infrastructure. These reviews may be performed in conjunction with a financial statement audit, internal audit, or other form of attestation engagement. It is the process of collecting and evaluating evidence of an organization's information systems, practices, and operations. Obtained evidence evaluation can ensure whether the organization's information systems safeguard assets, maintains data integrity, and are operating effectively and efficiently to achieve the organization's goals or objectives.
An IS audit is not entirely s

PHASE 1: Audit Planning

In this phase we plan the information system coverage to comply with the audit objectives specified by the Client and ensure compliance to all Laws and Professional Standards. The first thing is to obtain an Audit Charter from the Client detailing the purpose of the audit, the management responsibility, authority and accountability of the Information Systems Audit function as follows:
  1. Responsibility: The Audit Charter should define the mission, aims, goals and objectives of the Information System Audit. At this stage we also define the Key Performance Indicators and an Audit Evaluation process;
  2. Authority: The Audit Charter should clearly specify the Authority assigned to the Information Systems Auditors with relation to the Risk Assessment work that will be carried out, right to access the Client’s information, the scope and/or limitations to the scope, the Client’s functions to be audited and the auditee expectations; and
  3. Accountability: The Audit Charter should clearly define reporting lines, appraisals, assessment of compliance and agreed actions.
The Audit Charter should be approved and agreed upon by an appropriate level within the Client’s Organization.
See Template for an Audit Charter/ Engagement Letter here.
In addition to the Audit Charter, we should be able to obtain a written representation (“Letter of Representation”) from the Client’s Management acknowledging:
  1. Their responsibility for the design and implementation of the Internal Control Systems affecting the IT Systems and processes
  2. Their willingness to disclose to the Information Systems Auditor their knowledge of irregularities and/or illegal acts affecting their organisation pertaining to management and employees with significant roles within the internal audit department.
  3. Their willingness to disclose to the IS Auditor the results of any risk assessment that a material misstatement may have occurred
See a Template for a Letter of Representation here.

PHASE 2 – Risk Assessment and Business Process Analysis

Risk is the possibility of an act or event occurring that would have an adverse effect on the organisation and its information systems. Risk can also be the potential that a given threat will exploit vulnerabilities of an asset or group of assets to cause loss of, or damage to, the assets. It is ordinarily measured by a combination of effect and likelihood of occurrence.
More and more organisations are moving to a risk-based audit approach that can be adapted to develop and improve the continuous audit process. This approach is used to assess risk and to assist an IS auditor’s decision to do either compliance testing or substantive testing. In a risk based audit approach, IS auditors are not just relying on risk. They are also relying on internal and operational controls as well as knowledge of the organisation. This type of risk assessment decision can help relate the cost/benefit analysis of the control to the known risk, allowing practical choices.
The process of quantifying risk is called Risk Assessment. Risk Assessment is useful in making decisions such as:
  1. The area/business function to be audited
  2. The nature, extent and timing of audit procedures
  3. The amount of resources to be allocated to an audit
The following types of risks should be considered:
Inherent Risk: Inherent risk is the susceptibility of an audit area to error which could be material, individually or in combination with other errors, assuming that there were no related internal controls. In assessing the inherent risk, the IS auditor should consider both pervasive and detailed IS controls. This does not apply to circumstances where the IS auditor’s assignment is related to pervasive IS controls only. A pervasive IS Control are general controls which are designed to manage and monitor the IS environment and which therefore affect all IS-related activities. Some of the pervasive IS Controls that an auditor may consider include:
  • The integrity of IS management and IS management experience and knowledge
  • Changes in IS management
  • Pressures on IS management which may predispose them to conceal or misstate information (e.g. large business-critical project over-runs, and hacker activity)
  • The nature of the organisation’s business and systems (e.g., the plans for electronic commerce, the complexity of the systems, and the lack of integrated systems)
  • Factors affecting the organisation’s industry as a whole (e.g., changes in technology, and IS staff availability)
  • The level of third party influence on the control of the systems being audited (e.g., because of supply chain integration, outsourced IS processes, joint business ventures, and direct access by customers)
  • Findings from and date of previous audits
A detailed IS control is a control over acquisition, implementation, delivery and support of IS systems and services. The IS auditor should consider, to the level appropriate for the audit area in question:
  • The findings from and date of previous audits in this area
  • The complexity of the systems involved
  • The level of manual intervention required
  • The susceptibility to loss or misappropriation of the assets controlled by the system (e.g., inventory, and payroll)
  • The likelihood of activity peaks at certain times in the audit period
  • Activities outside the day-to-day routine of IS processing (e.g., the use of operating system utilities to amend data)
  • The integrity, experience and skills of the management and staff involved in applying the IS controls
Control Risk: Control risk is the risk that an error which could occur in an audit area, and which could be material, individually or in combination with other errors, will not be prevented or detected and corrected on a timely basis by the internal control system. For example, the control risk associated with manual reviews of computer logs can be high because activities requiring investigation are often easily missed owing to the volume of logged information. The control risk associated with computerised data validation procedures is ordinarily low because the processes are consistently applied. The IS auditor should assess the control risk as high unless relevant internal controls are:
  • Identified
  • Evaluated as effective
  • Tested and proved to be operating appropriately
Detection Risk: Detection risk is the risk that the IS auditor’s substantive procedures will not detect an error which could be material, individually or in combination with other errors. In determining the level of substantive testing required, the IS auditor should consider both:
  • The assessment of inherent risk
  • The conclusion reached on control risk following compliance testing
The higher the assessment of inherent and control risk the more audit evidence the IS auditor should normally obtain from the performance of substantive audit procedures.imilar to a financial statement audit. An evaluation of internal controls may or may not take place in an IS audit. Reliance on internal controls is a unique characteristic of a financial audit. An evaluation of internal controls is necessary in a financial audit, in order to allow the auditor to place reliance on the internal controls, and therefore, substantially reduce the amount of testing necessary to form an opinion regarding the financial statements of the company. An IS audit, on the other hand, tends to focus on determining risks that are relevant to information assets, and in assessing controls in order to reduce or mitigate these risks. An IT audit may take the form of a "general control review" or an "specific control review". Regarding the protection of information assets, one purpose of an IS audit is to review and evaluate an organization's information system's availability, confidentiality, and integrity by answering the following questions:
  1. Will the organization's computerized systems be available for the business at all times when required? (Availability)
  2. Will the information in the systems be disclosed only to authorized users? (Confidentiality)
  3. Will the information provided by the system always be accurate, reliable, and timely? (Integrity).
The performance of an IS Audit covers several facets of the financial and organizational functions of our Clients. The diagram to the right gives you an overview of the Information Systems Audit flow: From Financial Statements to the Control Environment and Information Systems Platforms.

Information Systems Audit Methodology

Our methodology has been developed in accordance with International Information Systems Audit Standards e.g ISACA Information Systems Audit Standards and Guidelines and the Sabarne Oxley COSO Standard. The beginning point of this methodology is to carry out planning activities that are geared towards integrating a Risk Based Audit Approach to the IS Audit.


Our Risk Based Information Systems Audit Approach


A risk based approach to an Information Systems Audit will enable us to develop an overall and effective IS Audit plan which will consider all the potential weaknesses and /or absence of Controls and determine whether this could lead to a significant deficiency or material weakness.
In order to perform an effective Risk Assessment, we will need to understand the Client’s Business Environment and Operations. Usually the first phase in carrying out a Risk Based IS Audit is to obtain an understanding of the Audit Universe. In understanding the Audit Universe we perform the following:
  • Identify areas where the risk is unacceptably high
  • Identify critical control systems that address high inherent risks
  • Assess the uncertainty that exists in relation to the critical control systems
In carrying out the Business Process Analysis we:
  • Obtain an understanding of the Client Business Processes
  • Map the Internal Control Environment
  • Identify areas of Control Weaknesses
The Chat to the right summarises the business process analysis phase.
The template xxx will provide you with a guideline to document an Organisations Business Sub Processes identified during the risk analysis phase.For each of the sub-processes, we identify a list of What Could Go Wrong (WCGW). This WCGW represent the threat existing on a particular process. A single process would have multiple WCGW’s. For each of the WCGW’s identified in the prior phase we will determine the Key Activities within that process.For each Key Activity:
  1. We will identify the Information Systems Controls
  2. For each of the Controls Identified, we would rate the impact/effect of the lack of that control (on a rating of 1 - 5, with 5 indicating the highest impact),we will then determine the likelyhood of the threat occuring( also on a rating of 1 - 5 with 5 representing the highest likelyhood).
<< Outline specific risk assessment methodology here>>

PHASE 3 – Performance of Audit Work

In the performance of Audit Work the Information Systems Audit Standards require us t o provide supervision, gather audit evidence and document our audit work. We achieve this objective through:
  • Establishing an Internal Review Process where the work of one person is reviewed by another, preferably a more senior person.
  • We obtain sufficient, reliable and relevant evidence to be obtained through Inspection, Observation, Inquiry, Confirmation and recomputation of calculations
  • We document our work by describing audit work done and audit evidence gathered to support the auditors’ findings.
Based on our risk assessment and upon the identification of the risky areas, we move ahead to develop an Audit Plan and Audit Program. The Audit Plan will detail the nature, objectives, timing and the extent of the resources required in the audit.
See Template for a Sample Audit Plan.
Based on the compliance testing carried out in the prior phase, we develop an audit program detailing the nature, timing and extent of the audit procedures. In the Audit Plan various Control Tests and Reviews can be done. They are sub-divided into:
  1. General/ Pervasive Controls
  2. Specific Controls
The Chat below to the left shows the Control Review Tests that can be performed in the two Control Tests above.

Control Objectives for Information and related Technology (COBIT)

The Control Objectives for Information and related Technology (COBIT) is a set of best practices (framework) for information (IT) management created by the Information Systems Audit and Control Association (ISACA), and the IT Governance Institute (ITGI) in 1992.
COBIT provides managers, auditors, and IT users with a set of generally accepted measures, indicators, processes and best practices to assist them in maximizing the benefits derived through the use of information technology and developing appropriate IT governance and control in a company.
COBIT helps meet the multiple needs of management by bridging the gaps between business risks, control needs and technical issues. It provides a best practices framework for managing IT resources and presents management control activities in a manageable and logical structure. This framework will help optimise technology information investments and will provide a suitable benchmark measure.
The Framework comprises a set of 34 high-level Control Objectives, one for each of the IT processes listed in the framework. These are then grouped into four domains: planning and organisation, acquisition and implementation, delivery and support, and monitoring. This structure covers all aspects of information processing and storage and the technology that supports it. By addressing these 34 high-level control objectives, we will ensure that an adequate control system is provided for the IT environment. A diagrammatic representation of the framework is shown below.
We shall apply the COBIT framework in planning, executing and reporting the results of the audit. This will enable us to review the General Controls Associated with IT Governance Issues. Our review shall cover the following domains;
  • Planning and organisation of information resources;
  • The planning and acquisition of systems and path in stage growth model of information systems;
  • The delivery and support of the IS/IT including facilities, operations, utilisation and access;
  • Monitoring of the processes surrounding the information systems;
  • The level of effectiveness, efficiency, confidentiality, integrity, availability, compliance and reliability associated with the information held in; and
  • The level of utilisation of IT resources available within the environment of the IS including people, the application systems of interface, technology, facilities and data.
The above control objectives will be matched with the business control objectives to apply specific audit procedures that will provide information on the controls built in the application, indicating areas of improvement that we need to focus on achieving.

Application Control Review

An Application Control Review will provide management with reasonable assurance that transactions are processed as intended and the information from the system is accurate, complete and timely. An Application Controls review will check whether:
  • Controls effectiveness and efficiency
  • Applications Security
  • Whether the application performs as expected
A Review of the Application Controls will cover an evaluation of a transaction life cycle from Data origination, preparation, input, transmission, processing and output as follows:
  1. Data Origination controls are controls established to prepare and authorize data to be entered into an application. The evaluation will involve a review of source document design and storage, User procedures and manuals, Special purpose forms, Transaction ID codes, Cross reference indices and Alternate documents where applicable. It will also involve a review of the authorization procedures and separation of duties in the data capture process.
  2. Input preparation controls are controls relating to Transaction numbering, Batch serial numbering, Processing, Logs analysis and a review of transmittal and turnaround documents
  3. Transmission controls involve batch proofing and balancing, Processing schedules, Review of Error messages, corrections monitoring and transaction security
  4. Processing controls ensure the integrity of the data as it undergoes the processing phase including Relational Database Controls, Data Storage and Retrieval
  5. Output controls procedures involve procedures relating to report distribution, reconciliation, output error processing, records retention.

The use of Computer Aided Audit Techniques (CAATS) in the performance of an IS Audit

The Information Systems Audit Standards require us that during the course of an audit, the IS auditor should obtain sufficient, reliable and relevant evidence to achieve the audit objectives. The audit findings and conclusions are to be supported by the appropriate analysis and interpretation of this evidence. CAATs are useful in achieving this objective.
Computer Assisted Audit Techniques (CAATs) are important tools for the IS auditor in performing audits.They include many types of tools and techniques, such as generalized audit software, utility software, test data, application software tracing and mapping, and audit expert systems.For us, our CAATs include ACL Data Analysis Software and the Information Systems Audit Toolkit(ISAT).
CAATs may be used in performing various audit procedures including:
  • Tests of details of transactions and balances(Substantive Tests)
  • Analytical review procedures
  • Compliance tests of IS general controls
  • Compliance tests of IS application controls
CAATs may produce a large proportion of the audit evidence developed on IS audits and, as a result, the IS auditor should carefully plan for and exhibit due professional care in the use of CAATs.The major steps to be undertaken by the IS auditor in preparing for the application of the selected CAATs are:
  • Set the audit objectives of the CAATs
  • Determine the accessibility and availability of the organisation’s IS facilities, programs/system and data
  • Define the procedures to be undertaken (e.g., statistical sampling, recalculation, confirmation, etc.)
  • Define output requirements
  • Determine resource requirements, i.e., personnel, CAATs, processing environment (organisation’s IS facilities or audit IS facilities)
  • Obtain access to the clients’s IS facilities, programs/system, and data, including file definitions
  • Document CAATs to be used, including objectives, high-level flowcharts, and run instructions
  • Make appropriate arrangements with the Auditee and ensure that:
  1. Data files, such as detailed transaction files are retained and made available before the onset of the audit.
  2. You have obtained sufficient rights to the client’s IS facilities, programs/system, and data
  3. Tests have been properly scheduled to minimise the effect on the organisation’s production environment.
  4. The effect that changes to the production programs/system have been properly consideered.
See Template here for example tests that you can perform with ACL

PHASE 4: Reporting

Upon the performance of the audit test, the Information Systems Auditor is required to produce and appropriate report communicating the results of the IS Audit. An IS Audit report should:
  1. Identify an organization, intended recipients and any restrictions on circulation
  2. State the scope, objectives, period of coverage, nature, timing and the extend of the audit work
  3. State findings, conclusions, recommendations and any reservations, qualifications and limitations
  4. Provide audit evidence


ERP..!!!


Pemodelan dan Arsitektur Agile


A.       Sekilas Agility
Istilah Agile sendiri terdiri dari dua pengertian, yaitu: pertama pengertian dari segi filosofi, dan kedua pengertian dari segi pedoman pengembangan perangkat lunak. Dari segi filosofi, agile mempunyai arti antara lain:  mendorong demi terciptanya kepuasan pelanggan; mempercepat delivery perangkat lunak secara bertahap (incremental); tim proyek yang ramping dan mempunyai motifasi yang sangat tinggi; minimasi pekerjaan; serta menyederhanakan (birokrasi) keseluruhan proses pembangunan perangkat lunak. Sedangkan dari segi pedoman pengambangan perangkat lunak, agile mempunyai pengertian, bahwa secara aktif dan berkesinambungan, antara pengembang dengan pelanggan harus senantiasa menjalin kerjasama dan komunikasi dengan baik.
Menurut Ivar Jacobson, agility mengandung pengertian bahwa perubahan (change) merupakan "hati" dan "jiwa" dari perangkat lunak. Maksudnya adalah, bahwa perubahan terhadap requirements pelanggan, silih bergantinya anggota tim, dan perubahan kebutuhan teknologi yang berimplikasi terhadap produk yang dihasilkan merupakan suatu hal yang sangat wajar terjadi. Hampir semua proyek pengambangan perangkat lunak pasti mengalami hal tersebut. Sedangkan menurut Goldman et al, agility merupakan sesuatu yang dinamis, mempunyai kontent yang spesifik, menaggapi perubahan secara agresif, dan beroriantasi pada pertumbuhan.
Dari definisi menurut Ivar Jacobson dan Goldman et al, di atas dapat ditarik kesimpulan bahwa Agility merupakan suatu kemampuan atau "jiwa" yang harus dimiliki oleh tim pengambangan perangkat lunak. Kemampuan tersebut antara lain berupa: kemampuan segera menindaklanjuti terjadinya perubahan secara efektif; kemampuan berkomunikasi antar stakeholders secara efektif; menganggap bahwa pelanggan merupakan pihak yang berada di dalam tim yang sama; kemampuan mengorganisasikan tim (memberikan motivasi) agar mampu meningkatkan performa kinerja tim; secara tepat waktu dan berkesinambungan dapat men-deliver perangkat lunak yang telah dijadwalkan.

Agile Process
Agile Process merupakan sekelompok aktifitas pembangunan perangkat lunak secara iteratif yang menekankan pada aktifitas konstruksi (desain dan koding). Agile Process mengeliminasi sebagian besar waktu untuk melakukan perencanaan sistem dan berusaha sebisa mungkin mematuhi jadwal deliver sistem yang telah dijanjikan. Requirements yang dibutuhkan secara langsung di-drive oleh pelanggan itu sendiri, dan apabila terjadi perubahan terhadap requirements tersebut, pengembang dituntut mampu beradaptasi dengan perubahan yang terjadi.



B.       Masalah-masalah Potensial dari Pendekatan Tradisional:

Masalah dengan model waterfall :
1.      Perubahan sulit dilakukan karena sifatnya yang kaku.
2.      Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajarterjadi.
3.      Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek.

Masalah dengan model Incremental:
1.      Cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding)
2.      Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment

Masalah dalam model RAD (Rapid Application Development):
1.      Tidak cocok untuk proyek skala besar
2.      Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi
3.      Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini
4.      Resiko teknis yang tinggi juga kurang cocok untuk model ini

Masalah model Prototyping adalah :
  1. Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangja waktu lama.
  2. penegmbang biasanya ingin cepat menyelesaikan proyek. Sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan cetak biru sistem .
  3. Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik.

C.       Pengertian Agile Method
Agile methods merupakan salah satu dari beberapa metode yang digunakan dalam pengembangan sooftware. Agile method adalah jenis pegembangan sistem jangka pendek yang memerlukan adaptasi cepat dan pengembang terhadap perubahan dalam bentuk apapun.
Dalam Agile Software Development interaksi dan personel lebih penting dari pada proses dan alat, software yang berfungsi lebih penting daripada dokumentasi yang lengkap, kolaborasi dengan klien lebih penting dari pada negosiasi kontrak, dan sikap tanggap terhadap perubahan lebih penting daripada mengikuti rencana.
Agile Method juga dapat diartikan sekelompok metodologi pengembangan software yang didasarkan pada prinsip-prinsip yang sama atau pengembangan system jangka pendek yang memerlukan adaptasi cepat dari pengembang terhadap perubahan dalam bentuk apapun

D.       Prinsip/Tujuan Agile Software Development
Agile Software Development juga melihat pentingnya komunikasi antara anggota tim, antara orang-orang teknis dan businessmen, antara developer dan managernya. Ciri lain adalah klien menjadi bagian dari tim pembangun software. Ciri-ciri ini didukung oleh 12 prinsip yang ditetapkan oleh Agile Alliance. Menurut Agile Alliance, 12 prinsip ini adalah bagi mereka yang ingin berhasil dalam penerapan Agile Software Development:
1.             Kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus menerus.
2.             Menerima perubahan kebutuhan, sekalipun diakhir pengembangan.
3.             Penyerahan hasil/software dalam hitungan waktu beberapa minggu sampai beberapa bulan.
4.             Pihak bisnis dan pengembang harus bekerja sama setiap hari selama pengembangan berjalan.
5.             Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja dalam lingkungan yang mendukun dan yang dipercaya untuk dapat menyelesaikan proyek.
6.             Komunikasi dengan berhadapan langsung adalah komunikasi yang efektif dan efisien
7.             Software yang berfungsi adalah ukuran utama dari kemajuan proyek
8.             Dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk menjaga perkembangan yang berkesinambungan
9.             Perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile
10.         Kesederhanaan penting
11.         Arsitektur, kebutuhan dan desain yang bagus muncuk dari tim yang mengatur dirinya sendiri
12.         Secara periodik tim evaluasi diri dan mencari cara untuk lebih efektif dan segera melakukannya.

Dua belas prinsip tersebut menjadi suatu dasar bagi model-model proses yang punya sifat agile. Dengan prinsip-prinsip tersebur Agile Process Model berusaha untuk menyiasati 3 asumsi penting tentang proyek software pada umumnya:
·           Kebutuhan software sulit diprediksi dari awal dan selalu akan berubah. Selain itu, prioritas klien juga sering berubah seiring berjalannya proyek.
·           Desain dan pembangunan sering tumpang tindih. Sulit diperkirakan seberapa jauh desain yang diperlukan sebelum pembangunan.
·           Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan.

Kelebihan dari Agile Method
1.         Meningkatkan kepuasan kepada klien
2.         Pembangunan system dibuat lebih cepat
3.         Mengurangi resiko kegagalan implementasi software dari segi non-teknis
4.         Jika pada saat pembangunan system terjadi kegagalan,kerugian dar segi materi relative kecil.
Faktor Manusia Dalam Agile Process Model
Kunci faktor manusia pada model ini adalah proses didasari pada kebutuhan orang dan tim bukan sebaliknya, Untuk dapat sukses menerapkan model proses ini, pada faktor manusia ada beberapa kunci penting:
  1. Kompetensi: ketrampilan dalam membangun dan pengetahuan tentang proses membangun
  2. Fokus: memiliki fokus yang sama sekalipun peran dalam tim berbeda
  3. Kolaborasi : kerja sama dengan klien, anggota tim dan manajer.
  4. Kemampuan ambil keputusan : tim pembangun memiliki otonomi dalam pengambilan keputusan terkait teknis dan proyek
  5. Kemampuan fuzzy problem-solving: mampu menyelesaikan memilah masalah yang penting untuk dipecahkan segera atau nanti.
  6. Saling percaya dan hormat: kekompakan tim yang didukung oleh rasa percaya dan saling menghargai satu sama lain.
  7. Manajemen diri: tim mengatur diri untuk selesaikan proyek, mengatur proses untuk disesuaikan dengan lingkungannya, tim menjadwal dirinya untuk menyerahkan hasil.

E.       Model-model Agile method
1.         Extreme Programmning (XP)
2.         Adaptive Software Development (ASD)
3.         Dynamic Systems Development Method (DSDM)
4.         Scrum Methodology
5.         Crystal
6.         Feature Driven Development (FDD)
7.         Agile Modeling (AM)
8.         Rational Unified Process

1.        Extreme Programmning (XP)
Proyek Pemrograman Extreme pertama dimulai 6 Maret 1996. Extreme Programming adalah salah satu dari beberapa Proses Agile populer. Sudah terbukti sangat sukses di banyak perusahaan dari berbagai ukuran dan industri di seluruh dunia.
Extreme Pemrograman berhasil karena menekankan kepuasan pelanggan. Alih-alih memberikan semua yang anda mungkin inginkan pada tanggal beberapa jauh di masa depan proses ini memberikan perangkat lunak yang Anda butuhkan saat Anda membutuhkannya. Extreme Pemrograman memberdayakan pengembang Anda untuk percaya diri menanggapi perubahan kebutuhan pelanggan, bahkan terlambat dalam siklus hidup.
Extreme Pemrograman menekankan kerja sama tim. Pengelola, pelanggan, dan pengembang semua mitra setara dalam sebuah tim kolaboratif. Extreme Pemrograman menerapkan, sederhana namun efektif yang memungkinkan tim lingkungan menjadi sangat produktif. Tim mengorganisir diri mengatasi masalah untuk menyelesaikannya seefisien mungkin.
Extreme Pemrograman meningkatkan proyek perangkat lunak dalam lima cara penting; komunikasi, kesederhanaan, umpan balik, rasa hormat, dan keberanian. Extreme Programmer selalu berkomunikasi dengan pelanggan mereka dan programer sesama. Mereka terus desain mereka yang sederhana dan bersih. Mereka mendapatkan umpan balik dengan menguji perangkat lunak mereka dimulai pada hari pertama. Mereka memberikan sistem ke pelanggan sebagai perubahan sedini mungkin dan melaksanakan seperti yang disarankan. Setiap keberhasilan kecil memperdalam rasa hormat mereka atas kontribusi yang unik dari masing-masing dan setiap anggota tim. Dengan dasar Extreme pemrogram dapat berani merespon perubahan kebutuhan dan teknologi.
Aspek yang paling mengejutkan dari Extreme Programming adalah aturan sederhana. Extreme Pemrograman sangat mirip jig gergaji teka-teki. Ada banyak potongan-potongan kecil. Individual potongan
Extreme Programming adalah metode pengembangan perangkat lunak yang ringan dan termasuk salah satu agile methods yang dipelopori oleh Kent Beck, Ron Jeffries, dan Ward Cunningham. Extreme Programming merupakan agile methods yang paling banyak digunakan dan menjadi sebuah pendekatan yang sangat terkenal. Sasaran Extreme Programming adalah tim yang dibentuk berukuran antara kecil sampai medium saja, tidak perlu menggunakan sebuah tim yang besar. Hal ini dimaksudkan untuk menghadapi requirements yang tidak jelas maupun terjadinya perubahan-perubahan requirements yang sangat cepat.
Extreme Programming sebagai sebuah metode yang dinamis diperlihatkan dalam empat values yang dimilikinya dan keempatnya merupakan dasar-dasar yang diperlukan dalam Extreme Programming. Kent Beck menyatakan bahwa tujuan jangka pendek individu sering berbenturan dengan tujuan sosial jangka panjang. Karena itu dibuatlah values yang menjadi aturan, hukuman, dan juga penghargaan. Keempat values tersebut adalah :
1.         Komunikasi (Communication)
Tugas utama developer dalam membangun suatu sistem perangkat lunak adalah mengkomunikasikan kebutuhan sistem kepada pengembang perangkat lunak. Komunikasi dalam Extreme Programmning dibangun dengan melakukan pemrograman berpasangan (pair programming). Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer. Tujuannya untuk memberikan pandangan pengembang sesuai dengan pandangan pengguna sistem.
2.         Kesederhanaan (Simplicity)
XP mencoba untuk mencari solusi paling sederhana dan praktis. Perbedaan metode ini dengan metodologi pengembangan sistem konvensional lainnya terletak pada proses desain dan coding yang terfokus pada kebutuhan saat ini daripada kebutuhan besok, seminggu lagi atau sebulan lagi. Lebih baik melakukan hal yang sederhana dan mengembangkannya besok jika diperlukan.
3.         Umpan Balik (Feedback)
Hal ini diperlukan untuk mengetahui kemajuan dari proses dan kualitas dari aplikasi yang dibangun. Informasi ini harus dikumpulkan setiap interval waktu yang singkat secara konsisten. Ini dimaksudkan agar hal-hal yang menjadi masalah dalam proses pengembangan dapat diketahui sedini mungkin. Setiap feed back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).
4.         Keberanian (Courage)
Berani mencoba ide baru. Berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki. Contoh dari courage adalah komitmen untuk selalu melakukan design dan coding untuk saat ini dan bukan untuk esok. Ketika ada kode yang terlalu rumit, sulit dibaca dan dipahami, tidak sesuai dengan kemauan pelanggan, dll maka seharusnya kode program seperti itu di refactor (kalau perlu dibangun ulang). Hal ini menjadikan pengembang merasa nyaman dengan refactoring program ketika diperlukan.
Extreme Programming menggunakan pendekatan berorientasi objek. Pada aktifitas Perencanaan terjadi pengumpulan user stories dari klien yang klien tetapkan prioritasnya. Setiap story ditetapkan harga dan lama pembangunan, jika terlalu besar, story dapat dipecah menjadi beberapa story yang lebih kecil. Terjadi pemeriksaan dan pertimbangkan resiko dan aktifitas Desain kegiatannya sederhana yaitu memanfaatkan kartu CRC (Class-Responsibility-Collaborator) untuk identifikasi dan mengatur class-class di konsep OO. Jika temuikan kesulitan, prototype dibangun [ini namanya spike solution].
Dilakukannya refactoring, yaitu mengembangkan desain dari program setelah ditulis. Pada aktifitas Pengkodean adalah penyiapan unit test sebelum pengkodean dipakai sebagai focus pemrogram untuk membuat program. Pair programming dilakukan untuk real time program solving dan real time quality assurance. Proses pengujiannya menggunakan unit test yang dipersiapkan sebelum pengkodean Menggunakan pendekatan berorientasi objek

Sebagai sebuah metodologi untuk mengembangkan peragkat lunak Extreme Programming tentu memiliki siklus hidup. Siklus hidup pada Extreme Programming ini terdapat lima fase yaitu :
1.         Exploration Phase
2.         Planning Phase
3.         Iteration to Release Phase
4.         Productionizing Phase
5.         Maintenance Phase
6.         Death Phase


Planning Game
Berikut ini adalah tabel setelah dilakukan perubahan pada siklus:
NO
PHASE
BUSINESS
DEVELOPMENT
I
Exploration phase
Write story
-
-
Estimate story
Split story
-
-
Summarize stories (simple documenting)
II
Commitment phase
Sort by value
-
-
Sort by risk
-
Sort by velocity
Choose scope
-
III
Steering phase
Iteration
-
-
Recovery
New story
Re-estimate
-
Summarize stories (update simple document)
Tabel 1: Fase pada planning game (setelah modifikasi)

Sebelum modifikasi, pada exploration phase terdapat tiga kegiatan yaitu write story, estimate story, dan split story. Setelah dilakukan modifikasi satu kegiatan lagi yang dikerjakan oleh pihak development adalah summarize stories into simple document.
Demikian juga pada steering phase yang pada awalnya hanya terdiri atas kegiatan-kegiatan iteration, recovery, new story, dan re-estimate, setelah modifikasi ditambah satu lagi yaitu update simple document. Proses ini sebenarnya sama dengan summarize stories pada exploration phase, perbedaannya pada steering phase adalah untuk mengantisipasi adanya new story yang dikerjakan oleh pihak bisnis.
1.    Metaphor
Metaphor merupakan panduan (guidance) dalam melakukan pengembangan secara keseluruhan. Metaphor di sini memerlukan penjelasan rinci. Requirements yang diperoleh melalui proses summarize stories tersebut berperan sebagai metaphor, sedangkan penjelasan rincinya ada pada story awal.
2.    40-hour week
Story yang telah selesai ditulis oleh customer langsung dirangkum ke dalam simple document pada fase requirements management. Terjadi penambahan waktu secara signifikan.
3.    On-site Customer
Komunikasi dengan on-site customer tetap dilakukan terus, termasuk dalam melakukan summarize stories. Sifatnya hanya merangkum story ke dalam requirements yang akan menjadi feature pada sistem yang dibuat.

Penerapan Extreme Programmning
Beberapa hal yang harus dipertimbangkan sebelum seseorang masuk dalam dunia Extreme Programmning  adalah sebagai berikut:
1.    User harus memahami konteks bisnis yang akan dikembangkan sistemnya, sehingga developer dapat menangkap sistem secara aplikatif dan dapat mengusulkan teknologi apa yang dapat dikembangkan dalam sistem barunya.
2.    Akan lebih efektif apabila developer pernah menangani proyek pengembangan sistem yang sejenis sehingga dapat memberikan usulan model sistem baru, di samping alasan bahwa developer telah memiliki template aplikasi sistem tersebut untuk dijadikan prototype sistem baru. Hal ini akan berimplikasi kepada kemudahan dalam konstruksi sistem karena dikembangkan berdasarkan template yang sudah ada.
3.    Extreme programming menuntut komunikasi antar developer dan user secara intensif dan komunikasi internal antar developer secara komprehensif, sehingga akan lebih representatif apabila tahap pengembangan sistem dilakukan di lokal yang mendukung proses komunikasi tersebut.

Extreme Programmning  adalah suatu bentuk pembangunan perangkat lunak yang berbasis nilai kemudahan, komunikasi, umpan balik, dan keberanian. Bekerja dalam whole team bersama-sama dengan praktek yang mudah. Dalam Extreme Programming terdapat 12 practices utama yaitu :
1.      Planning Game
Hubungan antara Customer dengan Programer untuk memperkirakan kenbutuhan –kebutuhan dari Custumer dalam implementasinya.
2.      Small, frequent releases
Memproduksi dengan cepat.
3.      System metaphors
System metaphors antara Customer dengan Programeruntuk menunjukkan semua perkembangan dengan menjelaskan bagaimana cara kerja system.
2.      Simple design
Perhatiannya pada pendisainnan atau perancngan solusi yang sederhana
3.      Testing (unit testing & TDD)
Pelaksanaan pengujian atau testing keseluruhan
4.      Frequent refactoring
Penyusunan system kembali dengan cara duplikat atau salinan,memperbaiki komunikasi, menambahkan kelenturan
5.      Pair programming
Dua orang menulis kode pada 1 komputer
6.      Collective code ownership
Siapapun dapat merubah bagian pada pengkodean setiap saat.
7.      Continuous integration
Bagian baru code di gabungkan ke dalam kode dasar
8.      40-hour weak
Max 40 jam kerja seminggu,
9.      On-site customer
Customer harus hadir dan ada setiap saat untuk teamnya.
10.  Coding standards
Terdapat aturan pengkodean dan di ikuti oleh programmer.

Keuntungan dan Kerugian XP
Keuntungan Extreme Programmning:
Menjalin komunikasi yang baik dengan client. Meningkatkan komunikasi dan sifat saling menghargai antar developer.
Kerugian Extreme Programmning:
Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima. Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga).

1.        Adaptive Software Development (ASD)
Adaptive Software Development (ASD) diajukan oleh Jim Highsmith sebagai teknik untuk membangun software dan sistem yang kompleks. Filosofi yang mendasari Adaptive Software Development (ASD) adalah kolaborasi manusia dan tim yang mengatur diri sendiri.
System kerja adaptive software development : Collaboration dan Learning
Adaptive cycle planning yaitu menggunakan informasi awal seperti misi dari klien, batasan proyek dan kebutuhan dasar untuk definisikan rangkaian software increment (produk software yang secara berkala diserahkan)
a.       Collaboration : orang-orang yang bermotivasi tinggi bekerja sama: saling melengkapi, rela membantu, kerja keras, trampil di bidangnya, dan komunikasikan masalah untuk hasilkan penyelesaian yang efektif.
b.      Learning: tim pembangun sering merasa sudah tahu semua hal tentang proyek, padahal tidak selamanya begitu. Karena itu proses ini membuat mereka belajar lebih tentang proyek melalui 3 cara:
·         Focus group: klien dan pengguna memberi masukan terhadap software
·         Formal Technique Reviews: Tim ASD lengkap melakukan review
·         Postmortems: Tim ASD lakukan instrospeksi pada kinerja dan proses.

2.        Dynamic Systems Development Method (DSDM)
Pada Dynamic System Development Method menyajikan kerangka kerja (framework) untuk membangun dan memelihara sistem dalam waktu yang terbatas melalui penggunaan prototyping yang incremental dalam lingkungan yang terkondisikan. Metode ini akan membangun software dengan cepat: 80% dari proyek diserahkan dalam 20% dari waktu total untuk menyerahkan proyek secara utuh.
Dynamic System Development Method dapat dikombinasikan dengan Extreme Programmning menghasilkan kombinasi model proses yang mengikuti Dynamic System Development Method dan praktek yang sejalan dengan Extreme Programmning.
Dynamic System Development Method memiliki beberapa aaktifitas seperti :
§  Feasibility study : siapkan requirement, dan batasan, lalu uji apakah sesuai gunakan proses DSDM
§  Business Study: susun kebutuhan fungsional dan informasi, tentukan arsitektur aplikasi dan identifikasi kebutuhan pemeliharaan untuk aplikasi
§  Functional model iteration : hasilkan incremental prototype yang perlihatkan fungsi software ke klien untuk dapatkan kebutuhan lebih jelas dan konfirmasi
§  Design and Build Iteration : cek ulang prototype yang dibangun untuk pastikan bahwa prototype dibangun dengan cara yang memungkinkan fungsi tersebut benar-benar bekerja
§  Implementation: menempatkan software pada lingkungan sebenar sekalipun belum lengkap, atau masih ada perubahan.

3.        Scrum Methodology
Pertama kali diperkenalkan oleh Jeff Sutherland tahun awal tahun 1990an, dan dikembangkan selanjutnya dilakukan oleh Schwaber dan Beedle. Pada dasarnya Scrum merupakan salah satu komponen dari metodologi pengembangan Agile mengenai pertemuan harian untuk membahas kemajuan dan XP adalah menekankan metodologi yang berbeda sepasang ujian dulu pemrograman dan pembangunan.
Scrum menguraikan proses untuk mengidentifikasi dan katalogisasi pekerjaan yang perlu dilakukan, memprioritaskan yang bekerja dengan berkomunikasi dengan pelanggan atau wakil pelanggan, dan pelaksanaan yang bekerja menggunakan rilis iterative dan memiliki tujuan utama untuk mendapatkan perkiraan berapa lama akan pembangunan. XP lebih lanjut tentang pengembang membantu menyelesaikan pekerjaan secepat dan maintainably mungkin

Scrum memiliki prinsip yaitu:
§  Ukuran tim yang kecil melancarkan komunikasi, mengurangi biaya, dan memberdayakan satu sama lain
§  Proses dapat beradaptasi terhadap perubahan teknis dan bisnis
§  Proses menghasilkan beberapa software increment
§  Pembangunan dan orang yang membangun dibagi dalam tim yang kecil
§  Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun
§  Proses scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan

Scrum memiliki aktifitas yang meliputi :
Ø  Backlog
Backlog adalah daftar kebutuhan yang jadi prioritas klien, dan daftar yang dibuat  dapat bertambah
Ø  Sprints
Aktifitas Sprints merupakanunit pekerjaan yang diperlukan untuk memenuhi kebutuhan yang ditetapkan dalam backlog sesuai dengan waktu yang ditetapkan dalam time-box (biasanya 30hari). Selama proses ini berlangsung backlog tidak ada penambahan.
Ø  Scrum Meetings
Aktifitas Scrum Meeting merupakan pertemuan yang rutin dilakukan perhari untuk evaluasi apa yang dikerjakan, hambatan yang ada, dan target penyelesaian untuk bahan meeting selanjutnya.
Ø  Demo
Aktifitas Demo adalah penyerahan software increment ke klien didemonstrasikan dan dievaluasi oleh klien.

Perbedaan Scrum dan XP
1.      Scrum adalah sebuah proses manajemen proyek, XP adalah sebuah praktek pemrograman. Keduanya adalah "gesit" teknik dan sering digunakan bersama-sama.
2.       Scrum menguraikan proses untuk mengidentifikasi dan katalogisasi pekerjaan yang perlu dilakukan, memprioritaskan yang bekerja dengan berkomunikasi dengan pelanggan atau wakil pelanggan, dan pelaksanaan yang bekerja menggunakan rilis iteratif.
3.      Scrum tujuan utama adalah untuk mendapatkan perkiraan berapa lama akan pembangunan. XP lebih lanjut tentang pengembang membantu menyelesaikan pekerjaan secepat dan maintainably mungkin.
4.      Beberapa perbedaan utama adalah bahwa scrum berfokus pada sprint pendek lebih terstruktur, dan log kembali memprioritaskan item. Beberapa XP fokus lebih pada pemrograman dipasangkan, memprioritaskan tugas, dan lebih pembangunan berbasis tes. Keduanya bekerja di iterasi dan keduanya cukup fleksibel untuk menangani proyek yang mudah menguap berubah.
5.       Scrum merupakan salah satu komponen dari metodologi pengembangan Agile mengenai pertemuan harian untuk membahas kemajuan dan XP adalah menekankan metodologi yang berbeda sepasang ujian dulu pemrograman dan pembangunan.

4.        Crystal
Crystal diperkenalkan oleh Cockburn dan Highsmith, Development yang tidak pada jalur kritis, dapat menghabikan waktu lebih, mereka yang memperbaiki produk atau membantu oaring yang ada di jalur proyek kritis.
Karakteristik Crystal :
1.         Secara aktual sebuah model proses keluarga yang memungkinkan manuver berdasar karakteristik permasalahan
2.         Menyarankan penggunaan workshop refleksi untuk review kebiasaan kerja tim
3.         Selalu murah dan cepat berkomunikasi secara langsung.
4.         Proyek berkembang sesuai ukuran team menjadi lebih atau luas dan metologi akan menjadi lebih tinggi.



5.        Feature Driven Development
Feature Driven Development merupakan model proses praktis untuk keahlian proses software engineering, Feature merupakan sebuah fungsi  yang berharga dimana dapat dilaksanakan.
Keuntungan dari metode feature :
  • User dapat menggambarkan dengan mudah bentuk system.
  • Dapat di organisasikan atau diatur ke dallamkelompok bisnis yang hirarki.
  • Desain dank ode lebih mudah diperiksa secara efektif.
  • Merancang proyek, penjadwalan dan jalur diarahkan oleh feature.

6.        Agile Modeling
Dalam situasi pembangunan software harus membangun sistem bisnis yang besar dan penting. Jangkauan dan kompleksitas sistem harus dimodelkan sehingga dapat dimengerti, masalah dapat dibagi menjadi lebih kecil dan kualitas dapat dijaga pada tiap langkah pembangunan
software. Agile Modeling adalah suatu metodologi yang praktis untuk dokumentasi dan pemodelan system software. Agile Modeling adalah kumpulan nilai-nilai, prinsip dan praktek-praktek untuk memodelkan software agar dapat diaplikasian pada software development proyek secara efektif.

7.        Rational Unified Process
Rational Unified Process, adalah suatu kerangka kerja proses pengembangan perangkat lunak iteratif yang dibuat oleh Rational Software, suatu divisi dari IBM sejak 2003. RUP bukanlah suatu proses tunggal dengan aturan yang konkrit, melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk disesuaikan oleh organisasi pengembang dan tim proyek perangkat lunak yang akan memilih elemen proses sesuai dengan kebutuhan mereka.
Model ini membagi suatu sistem aplikasi menjadi beberapa komponen sistem dan memungkinkan para developer aplikasi untuk menerapkan metoda iterative (analisis, disain, implementasi dan pengujian) pada tiap komponen. Dengan menggunakan model ini, RUP membagi tahapan pengembangan perangkat lunaknya ke dalam 4 fase sebagai berikut.
§  Inception, merupakan tahap untuk mengidentifikasi sistem yang akan dikembangkan. Aktivitas yang dilakukan pada tahap ini antara lain mencakup analisis sistem eksisting, perumusan sistem target, penentuan arsitektur global target, identifikasi kebutuhan, perumusan persyaratan perumusan kebutuhan pengujian, pemodelan diagram UML, dan pembuatan dokumentasi.
§  Elaboration, merupakan tahap untuk melakukan disain secara lengkap berdasarkan hasil analisis di tahap inception. Aktivitas yang dilakukan pada tahap ini antara lain mencakup pembuatan disain arsitektur subsistem), disain komponen sistem, disain format data disain database, disain antarmuka/tampilan, disain peta aliran tampilan, penentuan design pattern yang digunakan, pemodelan diagram UML, dan pembuatan dokumentasi.
§  Construction, merupakan tahap untuk mengimplementasikan hasil disain dan melakukan pengujian hasil implementasi. Pada tahap awal construction, ada baiknya dilakukan pemeriksaan ulang hasil analisis dan disain, terutama disain pada domain perilaku (diagram sequence) dan domain struktural (diagram class, component, deployment). Apabila disain yang dibuat telah sesuai dengan analisis sistem, maka implementasi dengan bahasa pemrogramanan tertentu dapat dilakukan. Aktivitas yang dilakukan pada tahap ini antara lain mencakup pengujian hasil analisis dan disain (misal menggunakan Class Responsibility Collaborator untuk kasus pemrograman berorientasi obyek), pendataan kebutuhan implementasi lengkap (berpedoman pada identifikasi kebutuhan di tahap analisis), penentuan coding pattern yang digunakan, pembuatan program, pengujian, optimasi program, pendataan berbagai kemungkinan pengembangan / perbaikan lebih lanjut, dan pembuatan dokumentasi.
§  Transition, merupakan tahap untuk menyerahkan sistem aplikasi ke konsumen (roll-out), yang umumnya mencakup pelaksanaan pelatihan kepada pengguna dan testing beta aplikasi terhadap ekspetasi pengguna.

Prinsip dalam Agile Modeling :
Ø  Membuat model dengan tujuan: tentukan tujuan sebelum membuat model
Ø  Mengunakan multiple models: tiap model mewakili aspek yang berbeda dari model lain.
Ø  Travel light: simpan model-model yang bersifat jangka panjang saja
Ø  Isi lebih penting dari pada penampilan: modeling menyajikan informasi kepada audiens yang tepat.
Ø  Memahami model dan alat yang yang digunakan untuk membuat software
Ø  Adaptasi secara local

A.       Dokumentasi Agile
Eelco Gravendeel menyatakan bahwa hanya ada dua jenis dokumentasi dalam Agile:
·         Dokumen yang diperlukan untuk semua anggota tim untuk bekerja pada proyek - Dalam dunia yang ideal, tim ini merelokasi dan semua pengetahuan akan dibagi dan diserahkan dengan komunikasi langsung. Namun,  jika tim didistribusikan dan pengetahuan harus ditransfer kemudian menulis dokumen dan melengkapi dengan panggilan audio visual akan sangat berguna. Satu set dokumen minimal yang umum juga dibutuhkan oleh tim untuk berbicara bahasa macam-macam dan berada di level yang sama pemahaman.
Eelco menyatakan bahwa banyak dokumen, yang dibuat untuk mendukung penciptaan produk, panggilan untuk perhatian lebih karena mereka dibuang segera setelah proyek selesai.
·         Dokumentasi untuk dikirim dengan produk akhir - Adalah dokumen yang merupakan bagian dari pengiriman produk dan kelanjutan hubungan dengan klien yang baik. Contoh umum termasuk:
Ø  User manual
Ø  Deployment manual
Ø  Pemeliharaan manual (ditujukan untuk mengoperasikan perangkat lunak)
Ø  Teknis dokumentasi (ditujukan untuk menjaga basis kode), dll

Kelebihan dan Kekurangan Agile
Kelebihan agile:
a.       Meningkatkan rasio kepuasan pelanggan
b.      Bisa melakukan review pelanggan mengenai software yang di buat lebih awal.

Kekurangan agile:
1.      Total lama pengembangan menjadi lebih lama
2.      Meningkatkan resiko kesalahan teknis
3.      Proses pengembangan menjadi agak kurang terorganisir.

Implementasi
Metodologi agile project management dalam beberapa tahun terakhir telah banyak digunakan untuk mengembangkan, mengimplementasikan sistem teknologi informasi, seiring dengan mulai banyak diadopsinya konsep agile pada proses manufaktur dan produksi. Konsep agile project management itu sendiri mengikuti life cycle diatas dengan menggabungkan konsep agility dalam prosesnya. Agility itu sendiri adalah kemampuan untuk membuat dan merespon perubahan (Highsmith, 2009). Dengan kata lain agility adalah kemampuan untuk mengkombinasikan flexibilitas dan stabilitas (Highsmith,2002). Dari pengertian diatas bisa diambil titik temu bahwa agile project management adalah metodologi manajemen proyek yang mempunyai adaptabilitas yang tinggi terhadap perubahan yang terjadi di setiap elemen-elemennya. Salah satu ciri dari sebuah agility adalah adanya proses iterasi yang terus menerus dan evaluasi yang terus berjalan pada setiap proses yang dilewatinya.

Berikut contoh kasus Agile:
Pelaku industri mulai sadar bahwa untuk menyediakan produk yang murah, berkualitas dan cepat, perbaikan di internal perusahaan manufaktur adalah tidak cukup. Peran serta supplier, perusahaan transportasi dan jaringan distributor adalah dibutuhkan. Pada bagian produksi
·         Bagian ini bertugas secara fisik melakukan transformasi dari bahan baku, bahan setengan jadi atau komponen menjadi produk jadi.
·         Kegiatan produksi dalam konteks SCM tidak harus dilakukan dalam perusahaan.
·         Banyak perusahaan melakukan outsourcing yaitu memindahkan kegiatan produksi ke pihak subkontraktor, sementara perusahaan konsentrasi ke kegiatan yang menjadi core competency mereka. Contoh perusahaan sepatu Nike.
·         Dalam kegiatan produksi, konsep lean manufakturing yang mementingkan efisiensi dan agile manufacturing yang menekankan pada fleksibilitas dan ketangkasan merespon perubahan adalah dua hal yang penting.

B.       Kesimpulan
Dari model-model proses di atas dapat diambil beberapa poin penting:
1.      komunikasi mempunyai peran penting dalam pembanguna software
2.      kebutuhan software tidak mudah untuk diidentifikasikan secara lengkap
3.      kerja sama dalam tim menentukan kelancaran pembangunan software

Aktifitas yang terjadi di dalam Agile Model Process tetap mengandung aktifitas-aktifitas yang ada pada model proses generasi sebelumnya seperti waterfall, incremental, spiral dan RAD. Selain itu, model-model proses di atas tetaplah bukan model proses yang cocok untuk setiap jenis software. Dengan menerapkan metode agile ini diharapkan pembangunan atau pengembangan perangkat lunak bisa terkontrol dengan baik dan selesai tepat pada waktu yang telah ditetapkan.


Referensi
[1] Agile Software Development, http://en.wikipedia.org/wiki/Agile_software_development, Sabtu 12 maret 2011
[2] Umi Proboyekti, Agile Model, http://lecturer.ukdw.ac.id/othie/agile_model.pdf, Sabtu 5 maret 2011
[3] Metode Scrum, http://frenchfrieska.wordpress.com/2007/10/12/scrum/, 12 maret 16.05
[4] Agile Modeling, http://www.agilemodeling.com/