INDEKS KINERJA

Level Evaluasi kinerja :

Ketiga level di atas memiliki tujuan yang sama, yaitu membuat operasional sistem menjadi efisien, namun problem yang dihadapi di masing-masing level akan dilihat dari sudut yang berbeda.

1. Desainer Sistem (perangkat keras/ Perangkat lunak), tugas :
a. Harus selalu menjaga/memikirkan jangkauan sistem aplikasi yang mungkin digunakan.
b. Memperhatikan penggunan/pemanfaatan sistem komputer yang mempengaruhi kerja beberapa variabel seperti : waktu akses memori, kecepatan CPU, pengorganisasian program dan basis data, algoritma lokasi memori.
c. Obyek bagi indeks internal

2. Manajer Instalasi, tugas :
a. Lebih memperhatikan keseimbangan (balance)
b. Cost effective yang digunakan komponen sistem.
c. Memilih banyak layanan yang memuaskan untuk banyak user.
d. Mengatur penggantian fasilitas yang digunakan.
e. Obyek bagi indeks internal

3. Analis dan programmer, tugas :
a. Lebih berkonsentrasi pada lingkup pekerjaan pemrograman secara operasional.
b. Dapat mempempengaruhi secara langsung terhadap bermacam-macam sumber beban (seperti CPU, periferal, memori dan lain-lain)
c. Mengevaluasi proses agar efisien dalam waktu dan efisien dalam harga.
d. Obyek bagi indeks eksternal
Skema dari suatu studi evaluasi kinerja :

DELTA ( Diesel Electric Locomotive Troubleshooting Aid)

DELTA ( Diesel Electric Locomotive Troubleshooting Aid) Dibuat oleh perusahaan General Electric (GE) membantu karyawan bagian pemeliharaan mesin lokomotif diesel dalam memantau mesin-mesin yang tidak berfungsi dengan baik dan membimbing ke arah prosedur perbaikan. Delta juga berfungsi untuk meminimalkan biaya dan waktu korektif pemeliharaan. Awalnya. sebuah sistem prototipe kelayakan dikembangkan di LISP. Selanjutnya sistem prototipe telah diterapkan di FORTH dan berjalan pada Digital Equipment PDP II 23 di bawah RSX-II M. (Sistem ini juga berjalan pada PDP II 70 dibawah RSX-II M-PLUS dan dalam model emulasi pada VAX II 780 di bawah VMS). Sistem ini berisi sekitar 530 aturan. Sekitar 330 aturan yang dikhususkan untuk diagnosis kesalahan dan prosedur perbaikan, yaitu. Sistem Pemecahan Masalah sementara sekitar 200 aturan membentuk Sistem Bantuan. Sistem Pemecahan Masalah menggunakan mesin inferensi campuran-konfigurasi berdasarkan chainer mundur dan chainer maju. Seperti yang terlihat pada Gambar l. 

Bantuan Sistem, menggunakan chainer maju dari mesin inferensi yang sama untuk merespon permintaan informasi dari sistem pakar. Ketika pengguna menekan kunci "H ELP" maka sistem akan menyediakan informasi tambahan seperti lokasi dan identifikasi komponen lokomotif, penggantian bagian klasifikasi, dan deskripsi perbaikan prosedur. Untuk menyelesaikan tugas ini, sistem ini menggunakan CAD file yang tersimpan dalam format garis grafis TEKTRONIX dan gambar VIDEO disimpan pada disk video laser. Deskripsi tentang masalah arsitektur system pakar terlihat pada gambar 2. Sebuah urutan tetap pertanyaan yang digunakan untuk mengumpulkan fakta-fakta awal tentang masalah lokomotif, seperti nomor unit, model tahun, melaporkan gejala, dll. Sebuah tabel informasi asosiatif memberikan fakta tambahan. seperti unit fitur standar, Unit sejarah kegagalan,  Kegagalan Model kecenderungan, dll Semua fakta ini merupakan titik awal untuk proses pemecahan masalah.

Himpunan aturan (heuristik) pengetahuan empiris tentang fungsional mesin listrik diesel dibagi menjadi ruang pengetahuan seperti sistem mekanik, sistem kelistrikan, dll Dalam setiap ruang pengetahuan, aturan dibagi sesuai dengan hipotesis (daerah fault), seperti Operator Kesalahan, Mesin Tidak dapat Membuat Daya, dan lain-lain Satu set meta-aturan (indeks pintar dari partisi pengetahuan) mengambil dari berbagai pengetahuan spasi subset dari aturan yang terkait dengan semua hipotesis yang bisa relevan dengan awal gejala. Hipotesis-hipotesis ini merupakan diagnosis awal. Bekerja di belakang sebuah modus, penafsir mencoba untuk membuktikan atau menyangkal setiap hipotesis. berdasarkan kedua fakta awal dan tambahan
fakta disimpulkan oleh sistem atau meminta pengguna. Proses ofthis Hasilnya adalah diagnosis akhir yang menunjukkan hipotesis sukses (kesalahan) dan tindakan korektif yang sesuai (perbaikan). Sistem pakar ini didasarkan pada campuran strategi pengendalian, karena mekanisme inferensi dapat bekerja baik dalam modus maju atau mundur (Gambar I).

Kesimpulan
Prototipe pertama bidang ini sistem pakar telah dilaksanakan di unit kasar, dikemas oleh Comark, mengandung PDP II! 23 (menjalankan RSX-II M dan versi yang disempurnakan
ara FORTH). 10 meta-byte Winchester disk yang. terminal VT100 dan papan grafis SELANAR. A SONY pemutar laser video disk dan monitor tambahan warna menyelesaikan konfigurasi bidang sistem prototipe. Sistem ini telah menunjukkan hasil yang menjanjikan sejak pengiriman baru-baru ini kepada General Lokomotif Operasi Perusahaan listrik pada bulan Juli 1983. Konfigurasi campuran-mode inferensi  mesin melakukan dengan sangat baik. Pelaksanaan FORTH terbukti untuk mudah diadaptasi ke system kecil berbasis mikroprosesor untuk tetap menjaga kecepatan eksekusi cepat. Antarmuka manusia-mesin sangat user-friendly dan memungkinkan pengguna untuk berinteraksi dengan sistem melalui pilihan menu atau sederhana (single keystroke) menjawab seperti: YN? WH (Ya. No? Unknown. Why? Help).
Selama enam bulan ke depan. sistem pemecahan masalah lokomotif akan diuji di lapangan untuk memverifikasi keakuratan basis pengetahuan dan keandalan konfigurasi hardware. Dalam fase berikut proyek  basis pengetahuan ini akan diperluas menjadi sekitar 1200 aturan dengan meningkatkan kedalaman  porsi yang lebih besar dari ruang masalah.

Contoh tiga aturan dalam Sistem Pakar terkait dengan kesalahan dalam sistem bahan bakar.

Peraturan 760 : ada kesalahan dalam sistem bahan bakar pada kecepatan yang tidak berjalan dan pembacaan diambil dari tekanan pengukuran bahan bakar lokomotif.
IF:
EO [ENGINE SET IDLE ]
Is the engine at idle?
EO [FUEL PRESSURE BELOW NORMAL]
Is the fuel pressure below normal? (Less than 38 psi?)
EO [FUEL-PRESSURE-GAGE USED IN TEST]
Did you use the locomotive gage?
EO [FUEL-PRESSURE-GAGE STATUS OK ]
Is locomotive gage known to be accurate?
THEN:
WRITE [FUEL SYSTEM FAULTY] 1.00
Establishes that there is a fuel system fault.
End of rule 760

Peraturan 1270 : pengukur tekanan bahan bakar  lokomotif OK
IF:
UDO [FUEL-PRESSURE-TEST-GAGE STATUS ATTACHED]
Attach a known good pressure gage.
ASK-Y [FUEL-PRESSURE-TEST-GAGE READING SAME-AS FUEL-GAGE]
Is test-gage reading the same as locomotive-gage reading?
THEN:
DISPLAY [FUEL-PRESSURE-GAGE STATUS OK
The locomotive-pressure-gage is OK.
WRITE [FUEL-PRESSURE-GAGE STATUS OK] 1.00
Establishes that the locomotive-pressure-gage is OK.
WRITE [FUEL-PRESSURE-GAGE STATUS ALREADY TESTED 1 1.00
Establishes that the locomotive-gage has been tested.
End of rule 1270.

Peraturan 1460 : setidaknya ada satu komponen sistem bahan bakar rusak
WHEN:
EO [FUEL SYSTEM FAULTY]
The fuel-system is faulty
THEN:
DISPLA Y [FUEL SYSTEM FAULTY
There is a fuel system fault.
WRITE [FUEL PROBLEM SOLVED] -1.00
Establishes that the fuel problem is not solved.
EVAL-ALL [FUEL SYSTEM-COMPONENT FAULTY
Tests for a faulty fuel system component.
End of rule J460

Referensi :
http://www.forth.com/archive/jfar/vol1/no1/article1.pdf

Scrum Development

Pengertian
Scrum adalah iteratif dan incremental kerangka pengembangan perangkat lunak tangkas untuk proyek-proyek perangkat lunak dan mengelola produk atau pengembangan aplikasi. Fokusnya adalah pada " fleksibel, holistik strategi pengembangan produk di mana tim pengembangan bekerja sebagai sebuah unit untuk mencapai tujuan bersama " sebagai lawan dari " tradisional, sekuensial pendekatan " . Scrum memungkinkan pembentukan tim mengorganisir diri dengan mendorong co - lokasi dari semua anggota ti , dan komunikasi verbal antara semua anggota tim dan disiplin dalam proyek .

Sejarah
Scrum pertama kali didefinisikan sebagai "strategi, pengembangan produk fleksibel holistik di mana tim pengembangan bekerja sebagai sebuah unit untuk mencapai tujuan bersama" sebagai lawan dari "pendekatan tradisional, sekuensial" pada tahun 1986 oleh Hirotaka Takeuchi dan Ikujiro Nonaka dalam "New New Produk Game Development ".

Hirotaka Takeuchi dan Ikujiro Nonaka kemudian berpendapat dalam "Perusahaan Pengetahuan Menciptakan" baik oleh Ikujiro Nonaka dan Hirotaka Takeuchi bahwa itu adalah bentuk "penciptaan pengetahuan organisasi, terutama baik di membawa tentang inovasi terus menerus, bertahap dan spiral".
Para penulis menggambarkan pendekatan baru untuk pengembangan produk komersial yang akan meningkatkan kecepatan dan fleksibilitas, berdasarkan studi kasus dari perusahaan-perusahaan manufaktur di industri otomotif, mesin fotokopi dan printer. Mereka menyebut holistik atau pendekatan rugby, karena seluruh proses dilakukan oleh satu tim lintas-fungsional di fase tumpang tindih beberapa, di mana tim "mencoba untuk pergi jarak sebagai satu unit, melewati bola bolak-balik".

Dalam rugby, sebuah scrum mengacu pada cara restart permainan setelah pelanggaran kecil. Pada awal 1990-an, Ken Schwaber digunakan apa yang akan menjadi Scrum di perusahaan itu, Metode Pengembangan Lanjutan, dan Jeff Sutherland, dengan John Scumniotales dan Jeff McKenna, mengembangkan pendekatan yang serupa di Perusahaan Easel, dan adalah yang pertama untuk menyebutnya menggunakan single Kata Scrum.

Pada tahun 1995, Sutherland dan Schwaber bersama-sama mempresentasikan sebuah makalah yang menjelaskan metodologi Scrum di Desain Obyek Bisnis dan Lokakarya Implementasi diselenggarakan sebagai bagian dari Berorientasi Objek Sistem Pemrograman,, Bahasa & Aplikasi '95 (OOPSLA '95) di Austin, Texas, pertama publik presentasi. Schwaber dan Sutherland berkolaborasi selama tahun berikutnya untuk menggabungkan tulisan-tulisan di atas, pengalaman mereka, dan industri praktek terbaik ke dalam apa yang sekarang dikenal sebagai Scrum.

Pada tahun 2001, Schwaber bekerja dengan Mike Beedle untuk menggambarkan metode dalam buku Pengembangan Perangkat Lunak Agile dengan Scrum. Pendekatan untuk perencanaan dan pengelolaan proyek adalah dengan membawa pengambilan keputusan wewenang kepada tingkat sifat operasi dan kepastian. Meskipun kata tersebut tidak akronim, beberapa perusahaan melaksanakan proses telah dikenal untuk mengejanya dengan huruf kapital sebagai scrum. Hal ini mungkin karena salah satu dari awal tulisan Ken Schwaber, yang dikapitalisasi scrum dalam judul.

Peran-peran dalam Scrum
Tim Scrum terdiri dari peran-peran yang bekerja sebagai satu kesatuan selama proses pengembangan produk. Peran-peran ini tidak ada hubungannya dengan jabatan di dalam struktur organisasi. Peran-peran dalam Scrum hanya terdiri dari:

 Product Owner, Product Owner adalah satu orang yang bertanggung-jawab terhadap suksesnya pengembangan produk. Product Owner yang bertanggung-jawab untuk memaksimalkan nilai dari produk yang dikembangkan. Product Owner memastikan Product Backlog selalu tersedia, terurut dan transparan untuk semua pihak.

 Scrum Master, Scrum Master adalah seorang servant leader dalam Tim Scrum yang melayani Tim Scrum agar mereka dapat bekerja secara optimal menghasilkan produk yang bernilai tinggi.

 Tim Pengembang, Tim Pengembang adalah semua pihak yang mengembangkan produk yang diminta oleh Product Owner. Tim Pengembang memiliki semua keahlian yang dibutuhkan untuk mengembangkan produk utuh, yang tidak terbatas dari business analyst, software engineer, tester, technical writer, dsb.
Pihak-pihak yang ingin terlibat di dalam proses pengembangan produk terdistribusi di dalam peran-peran ini.

Kelebihan dan Kekurangan
Kelebihan dari Scrum :
1. Keperluan berubah dengan cepat
2. Tim berukuran kecil sehingga melancarkan komunikasi, mengurangi biaya dan memberdayakan satu sama lain 
3. Pekerjaan terbagi-bagi sehingga dapat diselesaikan dengan cepat 
4. Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun 
5. Proses Scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan 

Kelemahan dari Scrum :
1. Waktu proyek tidak jelas 
2. Cost yang tidak akurat 
3. Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima. 

Contoh Penerapan dalam Kehidupan
Setiap hari hingga Sprint berakhir, Tim Pengembang akan bertemu di tempat dan waktu yang sama untuk membahas strategi mereka untuk mencapai obyektif yang telah disepakati di dalam Sprint Planning. Daily Scrum Meeting adalah sebuah kesempatan bagi Tim Pengembang untuk dapat menginspeksi dan mengadaptasikan hasil pekerjaan mereka hingga hari ini. Tim Pengembang yang baru menggunakan Scrum biasanya akan menjawab ketiga pertanyaan berikut:
 Apa yang telah saya kontribusikan kemarin.
 Apa yang akan saya kontribusikan hari ini.
 Apa yang menghambat saya untuk menyelesaikan pekerjaan saya hingga hari ini.

Rapid Application Development (RAD)

 Pengertian

Rapid application development  (RAD) atau rapid prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem dimana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan. Working model digunakan kadang-kadang saja sebagai basis desain dan implementasi sistem final.

 Sejarah

Rapid Application Development ( RAD ) adalah istilah awalnya digunakan untuk menggambarkan proses pengembangan perangkat lunak pertama kali dikembangkan dan berhasil digunakan selama pertengahan 1970-an oleh Sistem Pusat Pengembangan New York Telephone Co di bawah arahan Dan Gielan. Setelah serangkaian implementasi sangat berhasil dari proses ini, Gielan kuliah secara ekstensif di berbagai forum pada metodologi , praktek, dan manfaat dari proses ini.

RAD melibatkan pengembangan dan pembangunan prototipe iteratif . Pada tahun 1990 , dalam buku RAD, Rapid Application Development, James Martin didokumentasikan penafsirannya tentang metodologi. Baru-baru ini, istilah dan singkatan yang telah datang untuk digunakan dalam lebih luas, pengertian umum yang mencakup berbagai metode yang bertujuan untuk mempercepat pengembangan aplikasi, seperti penggunaan kerangka perangkat lunak dari berbagai jenis, seperti kerangka kerja aplikasi web.

Pengembangan aplikasi yang cepat merupakan respon terhadap proses yang dikembangkan pada 1970-an dan 1980-an, seperti Structured Sistem Metode Analisis dan Desain dan model Waterfall lainnya. Satu masalah dengan metodologi sebelumnya adalah bahwa aplikasi begitu lama untuk membangun bahwa persyaratan telah berubah sebelum sistem itu selesai, sehingga sistem tidak memadai atau bahkan tidak dapat digunakan. Masalah lain adalah asumsi bahwa persyaratan metodis tahap analisis saja akan mengidentifikasi semua persyaratan penting. Membuktikan fakta bahwa ini adalah jarang terjadi, bahkan untuk proyek-proyek dengan profesional yang sangat berpengalaman di semua tingkatan.

Dimulai dengan ide-ide dari Brian Gallagher, Alex Balchin, Barry Boehm dan Scott Shultz, James Martin mengembangkan pendekatan pengembangan aplikasi yang cepat selama tahun 1980 di IBM dan akhirnya diresmikan itu dengan menerbitkan sebuah buku pada tahun 1991, Rapid Application Development.

Kelebihan dan Kekurangan

§  Kelebihan dari RAD :

1.    Membeli sistem yang baru memungkinkan untuk lebih menghemat biaya ketimbang mengembangkan sendiri.

2.    Proses pengiriman menjadi lebih mudah, hal ini dikarenakan proses pembuatan lebih banyak menggunakan potongan-potongan script.

3.    Mudah untuk diamati karena menggunakan model prototype, sehingga user lebih mengerti akan sistem yang dikembangkan.

4.    Lebih fleksibel karena pengembang dapat melakukan proses desain ulang pada saat yang bersamaan.

5.    Bisa mengurangi penulisan kode yang kompleks karena menggunakan wizard.

6.    Keterlibatan user semakin meningkat karena merupakan bagian dari tim secara keseluruhan.

7.    Mampu meminimalkan kesalahan-kesalahan dengan menggunakan alat-alat bantuan (CASE tools).

8.    Mempercepat waktu pengembangan sistem secara keseluruhan karena cenderung mengabaikan kualitas.

9.    Tampilan yang lebih standar dan nyaman dengan bantuan software-software pendukung.

§  Kelemahan dari RAD :

1.    Dengan melakukan pembelian belum tentu bisa menghemat biaya dibandingkan dengan mengembangkan sendiri.

2.    Membutuhkan biaya tersendiri untuk membeli peralatan-peralatan penunjang seperti misalnya software dan hardware.

3.    Kesulitan melakukan pengukuran mengenai kemajuan proses.

4.    Kurang efisien karena apabila melakukan pengkodean dengan menggunakan tangan bisa lebih efisien.

5.    Ketelitian menjadi berkurang karena tidak menggunakan metode yang formal dalam melakukan pengkodean.

6.    Lebih banyak terjadi kesalahan apabila hanya mengutamakan kecepatan dibandingkan dengan biaya dan kualitas.

7.    Fasilitas-fasilitas banyak yang dikurangi karena terbatasnya waktu yang tersedia.

8.    Sistem sulit diaplikasikan di tempat yang lain.

9.    Fasilitas yang tidak perlu terkadang harus disertakan, karena menggunakan komponen yang sudah jadi, sehingga hal ini membuat biaya semakin meningkat.

Contoh Penerapan dalam Kehidupan

Model RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat yang dicapai dengan menerapkan :

1.     Component based construction (pemrograman berbasis komponen bukan prosedural).

2.     Penekanan pada penggunaan ulang (reuse) komponen perangkat lunak yang telah ada.

3.     Pembangkitan kode program otomatis/semi otomatis.

4.     Multiple team (banyak tim), tiap tim menyelesaikan satu tugas yang selevel tapi tidak sama. Banyaknya tim tergantung dari area dan kompleksitasnya sistem yang dibangun.

Jika keutuhan yang diinginkan pada tahap analisis kebutuhan telah lengkap dan jelas, maka waktu yang dibutuhkan untuk menyelesaikan secara lengkap perangkat lunak yang dibuat adalah berkisar 60 sampai 90 hari. Model RAD hampir sama dengan model waterfall, bedanya siklus pengembangan yang ditempuh model ini sangat pendek dengan penerapan teknik yang cepat.

Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan beberapa tim dalam waktu yang hampir bersamaan dalam waktu yang sudah ditentukan. Model ini melibatkan banyak tim, dan setiap tim mengerjakan tugas yang selevel, namun berbeda. Sesuai dengan pembagian modul sistem.

Agile Software Development

    Pengertian

      Agile pengembangan software adalah sekelompok metodologi pengembangan software yang didasarkan pada prinsip-prinsip yang sama. Agile metodologi umumnya mempromosikan proyek yang mendorong proses pengelolaan sering inspeksi dan adaptasi, sebuah filosofi yang mendorong kepemimpinan tim, mandiri dan akuntabilitas organisasi, satu set teknik praktek terbaik yang memungkinkan untuk pengiriman cepat dari perangkat lunak yang berkualitas tinggi, dan usaha pendekatan yang aligns pembangunan dengan kebutuhan pelanggan dan tujuan perusahaan. Konseptual kerangka dasar-dasar ini akan ditemukan di modern pendekatan manajemen operasional dan analisis seperti bersandar manufaktur, lunak sistem metodologi, pidato bertindak teori (pendekatan percakapan jaringan), dan Six Sigma.

     Sejarah

      Modern definisi Agile pengembangan software berkembang pada pertengahan tahun 1990-an sebagai bagian dari reaksi terhadap "berat" metode, dikatakan oleh seorang typified berat diatur, regimented, Mikro dikelola menggunakan waterfall model pembangunan. Proses ini berasal dari air terjun menggunakan model yang dianggap sebagai birokrasi, lambat, demeaning, dan tidak konsisten dengan cara yang sebenarnya pengembang perangkat lunak melakukan kerja efektif. Kasus dapat dibuat yang Agile dan pengembangan metode yg berulang adalah pembangunan kembali ke praktek mulai awal dalam sejarah pengembangan piranti lunak. Pada mulanya, Agile metode yang disebut "metode ringan." Pada tahun 2001, anggota tokoh masyarakat bertemu di Snowbird, Utah, dan mengadopsi nama "metode Agile." Nantinya, sebagian dari orang-orang yang membentuk Aliansi Agile, sebuah organisasi nirlaba yang mempromosikan pembangunan Agile.

      Suatu proses pengembangan software adaptif diperkenalkan dalam karya oleh Edmonds (1974). terkemuka awal Agile metode mencakup banyak (1995), Crystal Clear, Extreme Programming (1996), adaptive Software Development, Fitur Terutama Pembangunan dan Pengembangan Sistem Dinamis Metode (DSDM) (1995). Ini biasanya disebut sebagai metodologi Agile sejak Agile Manifesto telah diterbitkan pada tahun 2001.

Metodologi

§  Analisis Proyek : Menganalisis proyek sistem yang ingin dikembangakan

§  Pengembangan Proyek : Proses pengembangan sistem dilakukan 

§  Testing Proyek : Mencoba sistem yang sudah selesai sebelum diberikan kepada client Apabila sistem lulus test dan tidak ada perubahan-perubahan, maka sistem tersebut sudah bisa digunakan oleh client. Sementara apabila masih terjadi perubahan-perubahan maka kembali lagi ke proses awal.

Kelebihan dan Kekurangan

§  Kelebihan dari Agile Modeling:

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.

§  Kelemahan dari Agile Modeling:

Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.

Contoh Penerapan dalam Kehidupan

      Metode Agile telah banyak digunakan untuk pengembangan produk perangkat lunak dan beberapa dari mereka menggunakan karakteristik tertentu dari perangkat lunak, seperti teknologi objek. Namun, teknik ini dapat diterapkan untuk pengembangan produk non-software, seperti komputer, motorik kendaraan, peralatan medis, makanan, dan pakaian, lihat pengembangan produk Fleksibel .

Siklus Hidup

      Metode tangkas difokuskan pada aspek yang berbeda dari siklus hidup pengembangan perangkat lunak. Beberapa fokus pada praktek (pemrograman ekstrim, pemrograman pragmatis, pemodelan tangkas), sementara yang lain fokus pada pengelolaan proyek perangkat lunak (pendekatan scrum). Namun, ada pendekatan menyediakan cakupan penuh atas siklus hidup pengembangan (metode pengembangan sistem dinamis, atau DSDM, dan IBM Rational Unified Process, atau RUP), sementara sebagian besar dari mereka yang cocok dari persyaratan spesifikasi fasa pada (pengembangan fitur -driven, atau FDD, misalnya). Dengan demikian, ada perbedaan yang jelas antara berbagai metode pengembangan perangkat lunak tangkas dalam hal ini. Sedangkan DSDM dan RUP tidak perlu melengkapi pendekatan untuk mendukung pengembangan perangkat lunak , yang lain lakukan untuk tingkat tertentu. DSDM dapat digunakan oleh siapa saja (meskipun hanya anggota DSDM dapat menawarkan produk atau jasa DSDM). RUP, maka, merupakan lingkungan pengembangan dijual secara komersial (Abrahamsson, Salo, Rankainen, & Warsta, 2002).