SDLC (system development life cycle)

System Development Life Cycle atau yang biasa kita kenal dengan SDLC adalah proses yang digunakan oleh analis sistem untuk mengembangkan sistem informasi mulai dari perencanaan, pentuan kebutuhan, perancangan, validasi, sampai pelatihan, dan penyerahan kepada konsumen.

 
1. Waterfall

Waterfall, merupakan SDLC tertua karena sifatnya yang natural. Urutan SDLC waterfall ini bersifat serial dari proses perencanaan, analisa, desain, dan implementasi pada sistem. Model ini adalah model yang muncul pertama kali yaitu sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan.

Kelebihan :
-   Merupakan model pengembangan paling handal dan paling lama digunakan.
-   Cocok untuk system software berskala besar.
-   Cocok untuk system software yang bersifat generic.
-   Pengerjaan project system akan terjadwal dengan baik dan mudah dikontrol.

Kekurangan :
-   Persyaratan system harus digambarkan dengan jelas.
-   Rincian proses harus benar-benar jelas dan tidak boleh berubah-ubah.
-  Sulit untuk mengadaptasi jika terjadi perubahan spesifikasi pada suatu tahapan pengembangan
Merupakan model pengembangan system yang paling mudah dan paling sering digunakan. Model pengembangan ini bersifat linear dari tahap awal pengembangan system yaitu tahap perencanaan sampai tahap akhir pengembangan system yaitu tahap pemeliharaan. Tahapan berikutnya tidak akan dilaksanakan sebelum tahapan sebelumnya selesai dilaksanakan dan tidak bisa kembali atau mengulang ke tahap sebelumnya. 

2. Model prototyping
Prototype merupakan salah satu metode pengembangan perangat lunak yang banyak digunakan. Dengan metode prototyping ini pengembang dan pelanggan dapat saling berinteraksi selama proses pembuatan sistem. Prototyping, dimulai dengan pengumpulan kebutuhan, mendefinisikan objektif keseluruhan dari software, mengidentifikasikan segala kebutuhan, kemudian dilakukan “perangcangan kilat” yang difokuskan pada penyajian aspek yang diperlukan.

Kelebihan :
- Prototype melibatkan user dalam analisa dan desain.
- Punya kemampuan menangkap requirement secara konkret daripada secara abstrak.
- Untuk digunakan secara standalone.
- Digunakan untuk memperluas SDLC.
- Mempersingkat waktu pengembangan Sistem Informasi

Kekurangan :
- Proses analisis dan perancangan terlalu singkat.
- Mengesampingkan alternatif pemecahan masalah.
- Bisanya kurang fleksible dalam mengahdapi perubahan.
- Protitype yang dihasilkan tidak selamanya mudah dirubah
- Protype terlalu cepat selesai
Setelah model air terjun, mari kita membahas apa yang prototyping model dalam Pengembangan Software. Di sini, prototipe dibuat pertama dan berbasis di atasnya produk akhir dikembangkan. Sebuah prototipe adalah model atau program yang tidak didasarkan pada perencanaan yang ketat, tetapi perkiraan awal dari produk akhir atau sistem perangkat lunak. Sebuah prototipe bertindak sebagai sampel untuk menguji proses. Dari sampel ini kita belajar dan mencoba untuk membangun sebuah produk akhir yang lebih baik.Harap dicatat bahwa prototipe ini mungkin atau mungkin tidak benar-benar berbeda dari sistem final kita berusaha untuk berkembang. 

3. Perlu Model Prototyping

Jenis Metode Pengembangan Sistem yang digunakan saat itu adalah sangat sulit untuk mendapatkan persyaratan yang tepat dari pelanggan ( tidak seperti model air terjun, di mana persyaratan yang jelas ). Sementara membuat model, pengguna terus memberi masukan dari waktu ke waktu dan berbasis di atasnya, prototipe dibuat. Model sampel selesai dibangun yang akan ditampilkan dan berdasarkan umpan balik, SRS (Sistem Persyaratan Spesifikasi) dokumen disiapkan. Setelah ini selesai, SRS lebih akurat disiapkan, dan sekarang pekerjaan pembangunan dapat mulai menggunakan Model Waterfall. 
Sekarang mari kita membahas kelemahan dan kelebihan dari model Prototipe dalam Metode Software Development. 

Keuntungan dari Prototyping Model :

• Apabila prototipe ditunjukkan kepada pengguna, ia mendapat kejelasan yang tepat dan ‘merasa’ dari fungsiperangkat lunak dan ia dapat menyarankan perubahan dan modifikasi. 
• Jenis pendekatan pengembangan perangkat lunak yang digunakan untuk non-IT-melek orang. Mereka biasanya tidak pandai menentukan kebutuhan mereka, juga tidak bisa mengatakan dengan baik tentang apa yang mereka harapkan dari perangkat lunak. 
• Bila klien tidak yakin tentang kemampuan pengembang, ia meminta prototipe kecil yang akan dibangun.Berdasarkan model ini, ia menilai kemampuan pengembang. 
• Kadang-kadang membantu untuk menunjukkan konsep kepada calon investor untuk mendapatkan dana untuk proyek.
• Mengurangi resiko kegagalan, karena potensi risiko dapat diidentifikasi lebih awal dan langkah-langkah mitigasi dapat diambil.
• Iterasi antara tim pengembangan dan klien menyediakan lingkungan yang sangat baik dan konduktif selama proyek.
• Waktu yang dibutuhkan untuk menyelesaikan proyek setelah mendapatkan akhir mengurangi SRS, karena pengembang memiliki gagasan yang lebih baik tentang bagaimana ia harus mendekati proyek. 

Kekurangan Model Prototyping :

•  Prototyping biasanya dilakukan pada biaya pengembang. Jadi harus dilakukan dengan menggunakan sumber daya minimal. Hal ini dapat dilakukan dengan menggunakan Rapid Application Development (RAD) alat. Harap dicatat kadang-kadang biaya start-up membangun tim pengembangan, berfokus pada pembuatan prototipe, tinggi.
• Setelah kita mendapatkan kebutuhan yang tepat dari klien setelah menunjukkan model prototipe, mungkin ada gunanya. Itulah sebabnya, kadang-kadang kita lihat prototipe sebagai prototipe “Throw-away”.
• Ini adalah proses yang lambat.
• Keterlibatan Terlalu banyak klien, tidak selalu disukai oleh pengembang.
• Terlalu banyak perubahan dapat mengganggu ritme tim pengembangan. 

4. RAD
Rapid Application Development (RAD) adalah model dengan kegiatan dimulai pemodelan bisnis, pemodelan data, pemodelan proses, pembangkitan aplikasi dan pengujian
Model RAD

• User Design phase pada tahap ini, pengguna berinteraksi dengan analis sistem dan mengembangkan model dan prototipe yang mewakili proses semua sistem, input, dan output. Kelompok RAD atau subkelompok biasanya menggunakan kombinasi Joint Application Development (JAD) teknik dan alat-alat CASE untuk menerjemahkan kebutuhan pengguna ke dalam model kerja. Desain pengguna adalah proses interaktif yang berkesinambungan yang memungkinkan pengguna untuk memahami, memodifikasi, dan akhirnya menyetujui model kerja dari sistem yang memenuhi.
• Requirements Planning phase menggabungkan elemen dari sistem perencanaan dan tahap analisis sistem dari Siklus Hidup Pengembangan Sistem (SDLC). Pengguna, manajer, dan anggota staf TI membahas dan menyepakati kebutuhan bisnis, lingkup proyek, kendala, dan persyaratan sistem. Ini berakhir ketika tim setuju pada isu-isu kunci dan memperoleh otorisasi manajemen untuk melanjutkan.
• Cutover fase menyerupai tugas akhir dalam tahap implementasi SDLC, termasuk konversi data, pengujian, changeover ke sistem baru, dan pelatihan pengguna. Dibandingkan dengan metode tradisional, seluruh proses dikompresi. Akibatnya, sistem baru dibangun, disampaikan, dan ditempatkan dalam operasi lebih cepat. Tugasnya adalah data konversi, skala penuh pengujian, changeover sistem, pelatihan pengguna.
• Construction phase berfokus pada program dan aplikasi tugas perkembangan yang mirip dengan SDLC. Dalam RAD, bagaimanapun, pengguna terus berpartisipasi dan masih dapat menyarankan perubahan atau perbaikan sebagai layar yang sebenarnya atau laporan dikembangkan. Tugasnya adalah pemrograman dan pengembangan aplikasi, coding, unit-integrasi dan pengujian sistem.
• Pemodelan Data, Bagian dari pemodelan bisnis yang didefinisikan ke dalam sekumpulan objek data.
• Pemodelan Bisnis, aliran informasi dari fungsi dimodelkan dgn menjawab informasi apa yg mempengaruhi bisnis, yang dimunculkan ?, siapa yg memunculkan ?, Kenapa informasi diberikan ?, Siapa yang memprosesnya?
• Pembangkitan Aplikasi, Melakukan penggunaan kembali komponen yang ada (jika mungkin) Atau membuat kembali penggunaan kembali komponen jika dibutuhkan.
• Pemodelan Proses, objek data akan diimplementasikan pada fungsi bisnis. Deskripsi proses dibangun untuk penambahan modifikasi, penghapusan, atau pengambilan kembali objek data.
• Pengujian / pergantian, Proses RAD menekankan pada penggunaan kembali dan komponen program telah siap diuji.
• Lebih fleksibel karena pengembang dapat melakukan proses desain ulang pada saat yang bersamaan.
• Mudah untuk diamati karena menggunakan model prototype, sehingga user lebih mengerti akan sistem yang dikembangkan.
• Proses pengiriman menjadi lebih mudah, hal ini dikarenakan proses pembuatan lebih banyak menggunakan potongan-potongan script.
• Membeli sistem yang baru memungkinkan untuk lebih menghemat biaya ketimbang mengembangkan sendiri.

Keuntungan RAD :

• Tampilan yang lebih standar dan nyaman.
• Mempercepat waktu pengembangan sistem secara keseluruhan karena cenderung mengabaikan kualitas.
• Mampu meminimalkan kesalahan-kesalahan dengan menggunakan alat-alat bantuan (CASE tools).
• Keterlibatan user semakin meningkat karena merupakan bagian dari tim secara keseluruhan.
• Bisa mengurangi penulisan kode yang kompleks karena menggunakan wizard.
• Ketelitian menjadi berkurang karena tidak menggunakan metode yang formal dalam melakukan pengkodean.
• Kurang efisien karena apabila melakukan pengkodean dengan menggunakan tangan bisa lebih efisien.
• Kesulitan melakukan pengukuran mengenai kemajuan proses.
• Membutuhkan biaya tersendiri untuk membeli peralatan-peralatan penunjang seperti misalnya software dan hardware.
• Dengan melakukan pembelian belum tentu bisa menghemat biaya dibanding-kan dengan mengembangkan sendiri.

Kerugian RAD :

• Fasilitas yang tidak perlu terkadang harus disertakan, karena menggunakan komponen yang sudah jadi, sehingga hal ini membuat biaya semakin meningkat.
• Sistem sulit diaplikasikan di tempat yang lain.
• Fasilitas-fasilitas banyak yang dikurangi karena terbatasnya waktu yang tersedia.
• Lebih banyak terjadi kesalahan apabila hanya mengutamakan kecepatan diban-dingkan dengan biaya dan kualitas.

Tahapan RAD
Seperti kebanyakan SDLCs, RAD juga memiliki langkah demi langkah proses. Tapi tidak seperti SDLCs lain, proses pengembangan program yang sedang RAD lebih cepat. Mengandalkan set alat untuk pengembangan perangkat lunak, RAD akan tidak lagi harus memaksa kita untuk menggali lebih dalam teknik kami coding di mana kita membakar satu atau dua jam hanya untuk menyelesaikan satu perintah. Hanya ada tiga fase dalam Rapid Application Development: Perencanaan Persyaratan, Workshop Desain dan Implementasi.

1. Perencanaan Persyaratan
Dalam tahap ini, pengembang bertemu dengan koordinator proyek atau manajer untuk membuat tujuan khusus dari program yang diinginkan. Strategi untuk pengembangan dan alat untuk pengembangan juga tercantum dalam proyek tertentu. Untuk organisasi bisnis, tahap ini penting karena jawaban diproyeksikan untuk badan usaha akan ditata untuk pertama kalinya. Segala sesuatu di tahap ini bersifat teoritis tetapi akan bekerja sama dengan klien atau bisnis yang membutuhkan perangkat lunak untuk menjawab kebutuhan bisnis mereka.

2. RAD Desain Lokakarya
Ketika rencana telah ditata, sekarang saatnya untuk mulai membangun pada rencana. Menggunakan alat disepakati dan interface, pengembang akan mulai untuk membuat program yang berbeda berdasarkan pada kebutuhan bisnis. RAD membutuhkan banyak umpan balik karena juga membutuhkan banyak iterasi software. Karena RAD sudah memiliki seperangkat alat untuk membuat program, pengembang hanya akan perlu untuk menyempurnakan antarmuka pengguna. Sebagai alat membuat lebih mudah untuk membuat prototipe yang sebenarnya, pengguna akan dapat bekerja pada prototipe. Masukan dan saran disambut karena hal ini akan menjadi dasar dari proses perangkat lunak tambahan dan perintah. Perlahan pengembang dan pengguna dapat datang dengan satu prototipe yang hampir siap untuk penggunaan umum.

3. Implementasi Tahap

Setelah perbaikan lebih lanjut, software akhirnya akan diperkenalkan untuk bisnis atau pengguna mereka dimaksudkan. Meskipun telah melalui ratusan atau bahkan ribuan pengujian dan kritik, tahap dimana software tersebut diimplementasikan dalam skala yang lebih besar berbeda maka saran baru dan bug yang harus diharapkan dari pengguna yang berbeda. Pengembang harus ingat masukan ini dan menggunakannya untuk pembaruan perangkat lunak berikutnya. Pengembang harus memastikan bahwa pembaruan perangkat lunak akan benar sehingga pengguna akan meninggalkan versi lama. Hal ini akan mencegah sistem dari berfungsi karena hanya satu versi yang digunakan. Perbedaan Workshop Desain untuk Tahap Implementasi adalah tidak hanya di bug tetapi dalam implementasi perangkat lunak. Dalam Lokakarya Desain, pengembang harus mulai dari bawah untuk mengesankan pengguna. Pada fase kedua, pengembang hanya akan harus bekerja dalam pembaruan perangkat lunak untuk memastikan penerimaan pengguna yang lebih luas.

Ketika kita menggunakan RAD?

* Programmer berpengalaman adalah anggota tim
RAD adalah SDLC serba cepat. Pengembang akan menggunakan alat yang berbeda untuk mencapai tujuan membangun cepat lunak.Meskipun tidak perlu banyak coding karena himpunan alat, hanya programer yang berpengalaman bisa bekerja pada alat ini. Jika sesuatu terjadi pada perangkat lunak, hanya pengembang yang berpengalaman bisa menggali jauh ke dalam masalah meskipun mereka tidak mengkodekan program.

* Mempercepat pengembangan aplikasi
Untuk alasan apapun, pengembang sulit ditekan untuk membangun aplikasi yang cepat. Menggunakan set alat, perangkat lunak yang berbeda dapat dibuat dalam waktu singkat. Partisipasi pengguna akan lebih besar karena mereka akan bekerja dalam waktu ganda untuk memeriksa apakah perangkat lunak dengan standar.

* Cepat solusi untuk masalah bisnis
Alat-alat yang digunakan dalam pengembangan perangkat lunak memiliki langkah-langkah atau proses yang dapat memenuhi setiap kebutuhan bisnis. Jika bisnis membutuhkan jawaban atas pertanyaan yang mengganggu produktivitas dan pelaporan yang lebih baik, RAD bisa membuat perangkat lunak berbasis pada kebutuhan bisnis. Ada banyak perangkat lunak yang sudah memiliki fungsi yang dibutuhkan oleh bisnis.

* Berorientasi dan Sangat Kritis Pengguna Tujuan
Semuanya dimulai dan diakhiri dengan tujuan. Pengguna harus menggunakan perangkat lunak untuk mencapai tujuan yang diharapkan lebih cepat atau lebih mudah. Antarmuka pengguna yang berbeda dan alur kerja didasarkan pada realisasi tujuan. RAD membuat pengembang lebih fokus pada menjawab kebutuhan sebelum membuat sesuatu sendiri. The set alat dapat digunakan untuk menjawab masalah. Bahkan desain antarmuka pengguna dapat dipengaruhi oleh pengguna.

Kesimpulan:
Rapid Application Development atau RAD mengambil Model Prototipe SDLC lanjut. Alih-alih menggunakan kode, pengembang menggunakan alat yang berbeda dan kit pengembangan perangkat lunak dan membawa mereka semua bersama-sama untuk menciptakan perangkat lunak. Pengembang yang waktu ditantang bisa menggunakan pengembangan aplikasi. Bisnis juga akan menghargai software ini seperti itu bertujuan untuk menjawab masalah-masalah tertentu. Masukan pengguna adalah penting dalam siklus pembangunan karena mereka akan menunjukkan apakah program akan cocok dengan spesifikasi dan kebutuhan mereka.

Versi lain dari fase RAD :

1. Bisnis Modeling: 

Aliran informasi di antara fungsi bisnis yang didefinisikan dengan menjawab pertanyaan-pertanyaan seperti apa informasi yang mendorong proses bisnis, informasi apa yang dihasilkan, yang menghasilkan itu, di mana melakukan go informasi, yang memproses dan sebagainya.

2. Data Modeling: 

Informasi yang dikumpulkan dari pemodelan bisnis disempurnakan menjadi satu set objek data (entitas) yang dibutuhkan untuk mendukung bisnis. Atribut (karakter setiap entitas) diidentifikasi dan hubungan antara objek data (entitas) didefinisikan.

3. Proses Modeling:

objek data yang didefinisikan dalam fase pemodelan data ditransformasikan untuk mencapai aliran informasi yang diperlukan untuk melaksanakan fungsi bisnis.Deskripsi Pengolahan diciptakan untuk menambahkan, memodifikasi, menghapus atau mengambil objek data.

4. Generasi Aplikasi: 

Alat bantu otomatis digunakan untuk memfasilitasi konstruksi perangkat lunak, bahkan mereka menggunakan teknik GL 4.

5. Pengujian dan Balikkan:

Banyak komponen pemrograman telah diuji sejak RAD menekankan kembali. Hal ini mengurangi waktu pengujian secara keseluruhan. Tapi komponen baru harus diuji dan semua antarmuka harus sepenuhnya digunakan.

THE INCREMENTAL MODEL
Model incremental menggabungkan elemen-elemen model sekuensial linier (diimplementasikan secara berulang) dengan filosofi prototype interatif. Model ini memakai urutan-urutan linier di dalam model yang membingungkan, seiring dengan laju waktu kalender. Setiap urutan linier menghasilkan pertambahan perangkat lunak yang kemudian dapat disampaikan kepada pengguna.
Pada saat model incremental (pertambahan) ini digunakan, pertambahan pertama sering merupakan produk inti (core product), yaitu sebuah model pertambahan yang dipergunakan, tetapi beberapa muka tambahan (beberapa diketahui dan beberapa tidak) tetap tidak disampaikan. Produk inti tersebut dipergunakan oleh pelanggan (atau mengalami pengkajian detail). Sebagai hasil dari pemakaian dan/atau evaluasi maka dikembangkan rencana bagi pertambahan selanjutnya. Rencana tersebut menekankan modifikasi produk inti untuk secara lebih baik memenuhi kebutuhan para pelanggan dan penyampaian fitur serta fungsional tambahan. Proses ini mengikuti penyampaian setiap pertambahan sampai bisa menghasilkan produk yang lengkap.
Model proses incremental tersebut, seperti model prototype dan pendekatan-pendekatan evolusioner yang lain, bersifat iterative. Tetapi tidak seperti model prototype, model pertambahan berfokus pada penyampaian produk operasional dalam setiap pertambahannya. Pertambahan awal ada di versi stripped down dari produk akhir, tetapi memberikan kemampuan untuk melayani pemakai dan juga menyediakan platform untuk evaluasi oleh pemakai.
Perkembangan pertambahan, khususnya berguna pada saat staffing, tidak bisa dilakukan dengan menggunakan implementasi lengkap oleh batasan waktu bisnis yang sudah disepakati untuk proyek tersebut. Jika produk inti diterima dengan baik, maka staf tambahan (bila dibutuhkan) bisa ditambahkan untuk mengimplementasi pertambahan selanjutnya. Sebagai tambahan, system mayor yang sedang pada masa perkembangan serta waktu penyampaiannya belum pasti, mungkin membutuhkan keberadaan perangkat keras yang baru. Bisa juga rencana tertentu dibuat untuk menghindari pemakaian perangkat lunak ini, sehingga memungkinkan fungsionalitas partial disampaikan kepada pemakai tanpa harus banyak tertunda. 

Kelebihan Penggunaan Incremental Model :

• Merupakan model dengan manajemen yang sederhana.
• Pelanggan tidak perlu menunggu sampai seluruh system dikirim untuk mengambil keuntungan dari system tersebut. Inkremen yang pertama sudah memenuhi persyaratan mereka yang paling kritis, sehingga perangkat lunak dapat segera digunakan.
• Pelanggan dapat memakai inkremen yang pertama sebagai bentuk prototype dan mendapatkan pengalaman yang dapat menginformasikan persyaratan untuk inkremen system berikutnya.
• Resiko untuk kegagalan proyek secara keseluruhan lebih rendah. Walaupun masalah dapat ditemukan pada beberapa inkremen, bias saja beberapa inkremen diserahkan dengan sukses kepada pelanggan.
• Karena layanan dengan prioritas tertinggi diserahkan pertama dan inkremen berikutnya diintegrasikan dengannya, sangatlah penting bahwa layanan system yang paling penting mengalami pengujian yang paling ketat. Ini berarti bahwa pelanggan akan memiliki kemungkinan kecil untuk memenuhi kegagalan perangkat lunak pada inkremen system yang paling kecil.

Kekurangan Penggunaan Incremental Model :

• Inkremen harus relative lebih kecil (tidak lebih dari 20.000 baris kode) dan setiap inkremen harus menyediakan sebagian dari fungsional system
•  Adanya kesulitan untuk memetakan persyaratan pelanggan pada inkremen dengan ukuran yang benar.

Process modely yang digunakan adalah model incremental.
analysis –> design –> code –> test (Delivery of 1st incremental)
analysis –> design –> code –> test (Delivery of 2nd incremental)
analysis –> design –> code –> test (Delivery of 3rd incremental)
Sebelum dipecah – pecah kedalam delivery tersebut, lebih baik ada gambaran besar dulu apa yang diinginkan atau yang dibutuhkan di dalam aplikasi tesebut secara general.
Biasanya untuk 1 kali incremental, harus menunggu sampai test dulu baru lanjut ke incremental selanjutnya. Tetapi karena masalah SDM dan waktu, bisa saja setelah analysis dan design, langsung lanjut ke analysis level 2. Di dalam incremental, kita memilah – milah cakupannya menjadi modul – modul yang lebih kecil. Misalnya bagian home –> modul sendiri, bagian update & delete –> modul sendiri, dst. Intinya harus sama, jangan sampai berubah dalam hal struktur data. Kalau sampai mengubah, maka mulai dari awal lagi. Dan itu harus dipertanyakan ketika analysis dan design. Oleh karena itu, biasanya analysis dan design membutuhkan waktu lebih lama. Untuk menambah atau mengurangi, tidak apa-apa.
Dalam requirement gathering, yang merupakan poin penting adalah prosesnya seperti apa. Dan sesuai dengan disiplin ilmu kita yaitu IT, sedikit banyak kita mengetahui prosesnya.
Dan di dalam dokumen SRS berisi tentang apa yang customer butuhkan dan functionality apa yang bisa kita provide.

Spiral
Teknik spiral mencoba menggabungkan model prototyping dan waterfall. Biasa digunakan untuk proyek besar yang mahal dan rumit. Digunakan oleh militer Amerika untuk mengembangkan program Future Combat Systems

Keuntungan menggunakan teknik spiral:

• Pengguna dan developer bisa memahami dengan baik software yang dibangun karena progress dapat diamati dengan baik.
• Estimasi menjadi lebih realistik seiring berjalannya proyek karena masalah ditemukan sesegera mungkin.
• Lebih mampu menangani perubahan yang sering terjadi pada softwaredevelopment.
• Software engineers bisa bekerja lebih cepat pada proyek.

Kelemahan menggunakan teknik spiral :

• Membutuhkan waktu yang lama.
• Membutuhkan dana yang besar.
• Membutuhkan planning jangka panjang yang baik agar program bisa selesai dengan baik.

Model spiral dibagi menjadi sejumlah aktifitas kerangka kerja, disebut juga wilayah tugas, diantara tiga sampai enam wilayah tugas, yaitu :

1. Komunikasi Pelanggan (Customer Communication)

Tugas–tugas yang dibutuhkan untuk membangun komunikasi yang efektif di antarapengembangan dan pelanggan.

2. Perencanaan (Planning)

Tugas– tugas yang dibutuhkan untuk mendefinisikan sumber–sumber daya, ketepatanwaktu, dan proyek informasi lain yang berhubungan.

3. Analisis Risiko (Risk Analysis)

Tugas– tugas yang dibutuhkan untuk menaksir risiko– risiko, baik manajemen maupunteknis.

4. Perekayasaan (Engineering)

Tugas– tugas yang dibutuhkan untuk membangun satu atau lebih representasi dariaplikasi tersebu

5. Konstruksi dan peluncuran (Construction and Release)

Tugas– trugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang (instal) danmemberikan pelayanan kepada pemakai (contohnya pelatihan dan dokumentasi).

6. Evaluasi pelanggan (Customer Evaluation)

Tugas–tugas yang dibutuhkan untuk memperoleh umpan balik dari pelanggan dengandidasarkan pada evaluasi representasi software, yang dibuat selama masa perekayasaan,dan diimplementasikan selama masa pemasangan.
Sektor-sektor pada Spiral Model adalah:
1. Mengidentifikasi tujuan, alternatif, dan kendala setiap tahap secara spesifik 
2. Mengevaluasi alternatif, menilai resiko dan pengurangannya, aktifitas ditempatkan untuk mengurangi resiko kunci
3. Pengembangan dan validasi
4. Proyek ditinjau ulang dan tahap spiral berikutnya direncanakan

Keunggulan model ini adalah :

• Model ini sangat baik digunakan untuk sistem dan software yang besar.
• Menekankan pada pencarian okumative, dan pemaksaan penggunaan kembali software yang telah ada.
• Adanya analisa resiko pada mekanisme untuk memperkecil resiko.
• Adanya prototyping sehingga memudahkan komunikasi dengan konsumen

Kelemahan model ini adalah :

• Memerlukan waktu yang cukup lama untuk mengembangkan Software.
• Sistem pengendalian yang kurang baik
• Biasanya pihak developer dan perusahaan berada pada satu pihak yang sama sehinggapada tahap analisa resiko, mereka bisa sewaktu-waktu dapat membatalkan prosesrekayasa Jika pihak developer adalah pihak di luar perusahaan, maka akan timbul masalah okum.