Tugas resume TDA Part 3,4

Waterfall vs Agile : Mana yang Tepat untuk Pengembangan Metodologi Proyek Anda ?

Salah satu keputusan pertama yang kita hadapi untuk setiap implementasi proyek kami di Segue adalah " Yang metodologi pengembangan harus kita gunakan? " Ini adalah topik yang mendapat banyak diskusi ( dan sering debat panas ) . Jika hal ini tidak sesuatu yang Anda telah bekerja dengan sebelumnya, definisi metodologi pengembangan adalah dalam rangka , menempatkan sangat sederhana , itu adalah cara mengatur pekerjaan pengembangan perangkat lunak . Untuk menjelaskan lebih lanjut , itu TIDAK gaya manajemen proyek atau pendekatan teknis tertentu , meskipun Anda akan sering mendengar istilah ini semua dilemparkan bersama-sama atau digunakan secara bergantian .

Dua dasar, metodologi yang paling populer adalah :

    waterfall Yang mungkin lebih tepat disebut pendekatan " tradisional " , dan
    Agile ( lebih baru daripada Waterfall , tapi tidak yang baru ) .

Kedua hal ini dapat digunakan , metodologi matang . Setelah terlibat dalam proyek pengembangan perangkat lunak untuk waktu yang lama , di sini adalah pikiran saya pada kekuatan dan kelemahan masing-masing .

Metodologi Waterfall

waterfall adalah pendekatan linier untuk pengembangan perangkat lunak . Dalam metodologi ini , urutan kejadian adalah sesuatu seperti :

    Mengumpulkan dan persyaratan dokumen disain

    Kode dan uji unit

    Melakukan pengujian sistem

    Melakukan pengujian penerimaan pengguna ( UAT )

    Perbaiki masalah apapun

    Memberikan produk jadi

Dalam sebuah proyek pengembangan Waterfall benar, masing-masing mewakili tahap yang berbeda dari pengembangan perangkat lunak , dan setiap tahap umumnya selesai sebelum yang berikutnya dapat dimulai. Ada juga biasanya gerbang tahap antara masing-masing , misalnya , persyaratan harus ditinjau dan disetujui oleh pelanggan sebelum desain dapat dimulai.

Ada hal-hal baik dan buruk tentang pendekatan Waterfall . Di sisi positif :

    Pengembang dan pelanggan setuju pada apa yang akan disampaikan awal dalam siklus pengembangan . Hal ini membuat perencanaan dan perancangan lebih mudah .

    Kemajuan lebih mudah diukur , sebagai lingkup penuh pekerjaan dikenal di muka.
    Sepanjang upaya pengembangan , mungkin untuk berbagai anggota tim yang akan terlibat atau melanjutkan dengan pekerjaan lain , tergantung pada fase aktif proyek. Sebagai contoh , analis bisnis dapat mempelajari dan mendokumentasikan apa yang perlu dilakukan , sedangkan pengembang bekerja pada proyek-proyek lainnya . Penguji dapat mempersiapkan skrip uji dari persyaratan dokumentasi sementara coding sedang berlangsung .

    Kecuali ulasan , persetujuan , status pertemuan , dll , kehadiran pelanggan tidak sepenuhnya diperlukan setelah fase persyaratan .

    Karena desain selesai di awal siklus pengembangan , pendekatan ini cocok untuk proyek-proyek di mana beberapa komponen perangkat lunak harus dirancang (kadang-kadang secara paralel ) untuk integrasi dengan sistem eksternal .

    Akhirnya , perangkat lunak dapat dirancang sepenuhnya dan lebih hati-hati , berdasarkan pemahaman yang lebih lengkap dari semua kiriman perangkat lunak. Ini memberikan desain software yang lebih baik dengan kemungkinan kurang dari " sedikit demi sedikit efek , " sebuah fenomena pembangunan yang dapat terjadi sebagai potongan kode didefinisikan dan kemudian ditambahkan ke aplikasi di mana mereka mungkin atau mungkin tidak cocok dengan baik .

Berikut adalah beberapa masalah yang saya temui menggunakan pendekatan Waterfall murni :

    Salah satu daerah yang hampir selalu jatuh pendek adalah efektivitas persyaratan . Mengumpulkan dan mendokumentasikan persyaratan dalam cara yang berarti bagi pelanggan adalah bagian yang paling sulit dari pengembangan perangkat lunak , menurut pendapat saya . Pelanggan kadang-kadang terintimidasi oleh detail , dan rincian spesifik , yang disediakan di awal proyek , yang diperlukan dengan pendekatan ini . Selain itu, pelanggan tidak selalu mampu memvisualisasikan sebuah aplikasi dari dokumen persyaratan . Wireframes dan maket dapat membantu, tetapi tidak ada pertanyaan bahwa sebagian besar pengguna akhir memiliki beberapa kesulitan menempatkan elemen bersama-sama dengan persyaratan tertulis untuk sampai pada gambaran yang baik tentang apa yang akan mereka dapatkan.
    Kelemahan lain potensi pengembangan Waterfall murni adalah kemungkinan bahwa pelanggan akan puas dengan produk perangkat lunak mereka disampaikan. Karena semua kiriman didasarkan pada persyaratan terdokumentasi , pelanggan mungkin tidak melihat apa yang akan dikirimkan sampai itu hampir selesai . Pada saat itu , perubahan bisa sulit ( dan mahal ) untuk melaksanakan .

Agile Metodologi

Agile adalah iteratif , pendekatan berbasis tim untuk pembangunan. Pendekatan ini menekankan pengiriman cepat aplikasi dalam komponen fungsional yang lengkap . Daripada membuat tugas dan jadwal , sepanjang masa adalah " waktu - kotak " menjadi fase yang disebut " sprint . " Setiap berlari memiliki durasi yang ditetapkan ( biasanya dalam minggu) dengan menjalankan daftar kiriman , direncanakan satu berlari di muka. Kiriman diprioritaskan oleh nilai bisnis yang ditentukan oleh pelanggan . Jika semua pekerjaan yang direncanakan untuk sprint tidak dapat diselesaikan , pekerjaan reprioritized dan informasi yang digunakan untuk perencanaan sprint di masa depan .

Sebagai pekerjaan selesai selama setiap sprint, hal ini terus dievaluasi dan dievaluasi oleh pelanggan , yang dapat dianggap sebagai anggota paling penting dari tim Agile . Akibatnya , Agile bergantung pada tingkat yang sangat tinggi keterlibatan pelanggan di seluruh proyek.

Beberapa keuntungan dari pendekatan Agile mudah untuk melihat :

    Pelanggan telah sering dan awal kesempatan untuk melihat pekerjaan yang sedang disampaikan , dan untuk membuat keputusan dan perubahan di seluruh proyek pembangunan.

    Pelanggan memperoleh rasa kepemilikan yang kuat dengan bekerja secara luas dan langsung dengan tim proyek sepanjang proyek .

    Jika waktu untuk memasarkan untuk aplikasi tertentu adalah kekhawatiran , Agile bisa lebih cepat menghasilkan versi dasar perangkat lunak bekerja .

    Pengembangan sering lebih berfokus pada pengguna , kemungkinan akibat dari lebih dan sering arah dari pelanggan .

    Untuk lebih Agile Pengembangan manfaat , silakan lihat 8 Manfaat Agile Software Development

Dan, tentu saja , ada beberapa kelemahan :

    Tingkat yang sangat tinggi keterlibatan pelanggan, sementara yang besar untuk proyek tersebut , dapat menimbulkan masalah bagi beberapa pelanggan yang hanya mungkin tidak memiliki waktu atau minat untuk jenis partisipasi.

    Agile bekerja paling baik bila anggota tim pembangunan benar-benar didedikasikan untuk proyek.
    Karena Agile berfokus pada waktu pengiriman - kotak dan sering reprioritization , mungkin bahwa beberapa item yang ditetapkan untuk pengiriman tidak akan selesai dalam jangka waktu yang ditentukan. Sprint tambahan ( di luar yang awalnya direncanakan ) mungkin diperlukan , menambah biaya proyek . Selain itu, keterlibatan pelanggan sering menyebabkan fitur tambahan yang diminta sepanjang proyek . Sekali lagi, ini dapat menambah waktu keseluruhan dan biaya pelaksanaan .

    Hubungan kerja yang erat dalam sebuah proyek Agile paling mudah untuk mengelola ketika anggota tim berada dalam ruang fisik yang sama , yang tidak selalu mungkin . Namun , ada berbagai cara untuk menangani masalah ini , seperti webcam , perangkat kolaborasi , dll

    Sifat iteratif pembangunan Agile dapat menyebabkan penurunan kualitas sistem secara keseluruhan , karena ada sedikit penekanan pada pemahaman sistem selesai secara keseluruhan di awal proyek . Hal ini menjadi lebih jelas dalam implementasi skala besar , atau dengan sistem yang mencakup tingkat tinggi integrasi .

Membuat Pilihan Antara Agile dan Waterfall

Jadi , bagaimana kita memilih ? Pertama , kita mengubah permainan sedikit (yang sebagian besar organisasi pengembangan perangkat lunak apa yang ) dengan mendefinisikan proses kita sendiri . Pada Segue , itu disebut Kerangka Proses kami , dan itu adalah variasi pada metodologi Waterfall tradisional. Modifikasi kami meliputi penggunaan prototyping bila memungkinkan untuk memberikan pelanggan pandangan yang lebih baik dari produk jadi mereka di awal siklus desain / pengembangan . Ini membantu untuk meningkatkan pemahaman tim persyaratan dan komunikasi dengan pelanggan . Setelah kerangka utama aplikasi selesai sesuai kebutuhan tingkat tinggi , kami terus mengembangkan dan juga untuk menjangkau pelanggan untuk perbaikan persyaratan . Dengan cara ini , kami berusaha untuk menjadi seperti berulang mungkin tanpa mengorbankan arsitektur sistem secara keseluruhan 

Sumber :

http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology

 

Resume TDA Part 2 :)

SDLC, Prototype dan Waterfall

SDLC
System Development Lyfe Cycle (SDLC) adalah keseluruhan proses dalam membangun sistem melalui beberapa langkah. Metode pengembangan perangkat lunak dikenal dengan istilah SDLC (Software Development Life Cycle). Metodologi ini menjadi perhatian sangat istimewa pada proses rekayasa perangkat lunak. Karena dengan metodologi SDLC yang digunakan akan sangat menentukan sukses tidaknya proyek software.
Perbandingan tentang kelebihan dan kekurangan model Waterfall dan Prototype pada Software Development Life Cycle (SDLC) ini dijelaskan berikut ini:

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

Metode SDLC Model Waterfall

Model rekayasa piranti lunak yang diuraikan oleh Roger S. Pressman (1992: 24) salah satunya adalah waterfall model. Model ini memberikan pendekatan-pendekatan sistematis dan berurutan bagi pengembangan piranti lunak.

Berikut adalah gambar pengembangan sistem perangkat lunak dengan proses SDLC (System Development Life Cycle) dengan model waterfall.

Penjelasan dari tahap-tahap waterfall model adalah sebagai berikut:

• Perancangan Sistem (System Enginering)

Perancangan sistem sangat diperlukan, karena piranti lunak biasanya merupakan bagian dari suatu sistem yang lebih besar. Pembuatan sebuah piranti lunak dapat dimulai dengan melihat dan mencari apa yang dibutuhkan oleh sistem. Dari kebutuhan sistem tersebut akan diterapkan kedalam piranti lunak yang dibuat.

• Analisa Kebutuhan Piranti Lunak (Software Requirement Analysis)

Merupakan proses pengumpulan kebutuhan piranti lunak. Untuk memahami dasar dari program yang akan dibuat, seorang analisis harus mengetahui ruang lingkup informasi, fungsi-fungsi yang dibutuhkan, kemampuan kinerja yang ingin dihasilkan dan perancangan antarmuka pemakai piranti lunak tersebut.

• Perancangan (Design)

Perancangan piranti lunak merupakan proses bertahap yang memfokuskan pada empat bagian penting, yaitu: Struktur data, arsitektur piranti lunak, detil prosedur, dan karakteristik antar muka pemakai.

• Pengkodean (Coding)

Pengkodean piranti lunak merupakan proses penulisan bahasa program agar piranti lunak tersebut dapat dijalankan oleh mesin.

• Pengujian (Testing)

Proses ini akan menguji kode program yang telah dibuat dengan memfokuskan pada bagian dalam piranti lunak. Tujuannya untuk memastikan bahwa semua pernyataan telah diuji dan memastikan juga bahwa input yang digunakan akan menghasilkan output yang sesuai.
Pada tahap ini pengujian ini dibagi menjadi dua bagian, pengujian internal dan pengujian eksternal. Pengujian internal bertujuan menggambarkan bahwa semua statement sudah dilakukan pengujian, sedangkan pengujian eksternal bertujuan untuk menemukan kesalahan serta memastikan output yang dihasilkan sesuai dengan yang diharapkan.

• Pemeliharaan (Maintenance)

Proses ini dilakukan setelah piranti lunak telah digunakan oleh pemakai atau konsumen. Perubahan akan dilakukan jika terdapat kesalahan, oleh karena itu piranti lunak harus disesuaikan lagi untuk menampung perubahan kebutuhan yang diinginkan konsumen.

Contoh Proyek menggunakan Metode Waterfall:

Sebagai contoh sebuah perusahaan yang ingin meramalkan dan mengelola pertumbuhan bisnisnya. Jika perusahaan memprediksi bahwa akanmengatasi sistem akuntansi internal dan memutuskan untuk mengembangkan program akuntansi baru, ini adalah beberapa tingkat yang berbeda dari banyak proyek yaitu :

1. Pada tahap analysis dan definisi kebutuhan, programmer mengumpulkan
   kebutuhan system secara lengkap, karena akan dibutuhkan pada tahap
   selanjutnya.
2. Pada tahap perancangan, programmer harus mendesain interface program
   dan juga database yang akan digunakan. Pada tahap ini seorang programmer
   haruslah teliti, karena hasil system secara umum akan terlihat dari hasil
   rancangan.
3. Pada tahap implementasi dan pengetesan, desain system akan dibuat
   menggunakan bahasa pemrograman yang telah ditentukan, kemudian diuji
   coba apakah telah berjalan atau masih ada kesalahan.
4. Integrasi dan Sistem Testing, program yang sudah jadi lalu di tes secara
   keseluruhan, apakah program yang di buat sudah sesuai dengan yang di
   inginkan perusahaan tersebut atau belum.
5. Pada tahap operasi dan perawatan, seorang programmer akan mengoperasikan
   hasil system kedalam perusahaan. Jika pada tahap pengoperasian system sudah
   berjalan tanpa ada kesalahan system, maka proyek bisa dikatakan berhasil,
   selanjutnya adalah tahap perawatan yang akan mengadaptasi system dengan
   situasi sebenarnya

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

 SDLC – Agile Development

Produk Sistem Informasi juga membutuhkan tahapan-tahapan terlebih dahulu dalam proses pembangunannya, dan dalam bahasa kerennya disebut SDLC – System Development Life Cycle. SDLC sendiri secara mendasar terdiri dari empat tahapan, yaitu perencanaan, analisis, desain, dan implementasi. Setiap tahapan akan mendapatkan input dan menghasilkan output yang juga akan menjadi input dalam tahapan selanjutnya. Sedikit penjelasan soal tahapan tersebut :

1. Perencanaan. Output : rencana product/project

• Inisialisasi dan analisa keuntungan (ROI)
• Management project, terkait sumber daya, sumber dana dan rencana-rencana kerja

2. Analisis. Output : blue print / FSD Dokumen

• Pengumpulan data
• Strategi pengerjaan
• Detail kebutuhan yang harus dipenuhi

3. Desain. Output : spesifikasi teknis sistem

• Desain architecture teknologi yang digunakan
• Desain User Interface
• Desain data storage
• Desain flow chart system
• dll

4. Implementasi. Output : produk sistem informasi

• Pembangunan System
• Data Conversion
• Data Migration
• System Convertion
• Maintenance & Support system

SDLC, secara umum dapat dikategorikan menjadi 3 jenis :

1. Terstrukur :   dalam jenis ini, sebuah tahapan akan dijalankan setelah tahapan sebelumnya selesai. Beberapa SDLC yang termasuk jenis ini adalah SDLC Waterfall dan Pararel ( Waterfall dengan membagi-bagi project menjadi sub-sub project yang lebih kecil)

2. Rapid Application Programming : bagian produk yang mampu dikerjakan dengan cepat akan dibangun terlebih dahulu untuk disampaikan ke pengguna/user. Phased Development (pengembangan bertahap) dan model Prototype adalah beberapa SDLC yang masuk dalam jenis ini

3. Agile : membuang beberapa tahapan yang tidak mempunyai nilai/value dan menekankan pada pengembangan sederhana dan iterative/berulang. Beberapa jenis Agile SDLC antara lain Extreme Programming, Kanban, Scrum, DSDM, FDD, OpenUP, dll.

Dari berbagai jenis SDLC tersebut tentunya tidak mudah untuk menentukan methode SDLC mana yang akan dipakai dalam sebuah pengembangan product system informasi. Banyak faktor yang akan mempengaruhi dalam penentuan tersebut, antara lain:

1. kejelasan kebutuhan pengguna

2. pengetahuan user terhadapa teknologi

3. kompleksitas system

4. waktu

5. kejelasan jadwal

6. sering nya perubahan terhadap product

Mengapa Agile ???

Karena Agile lebih menawarkan fleksibilitas dalam menangani perubahan, dan dalam era sekarang ini, dimana perubahan adalah sebuah keharusan maka mau tidak mau kita harus “agile” terhadap perubahan tersebut. Organisasi/team yang tanggap terhadap perubahan akan menjadi juara sedangkan yang tetap lambat (penuh procedural) menghadapinya akan tertindas dengan sendirinya.

Sumber ::

http://virtuemagz.com/pengantar-sdlc-agile-development.html

http://sitiumiati.wordpress.com/2011/04/28/penjelasan-antara-sdlc-prototype-dan-waterfall/

http://www.fakhrurozy.co.cc/2009/11/model-rekayasa-piranti-lunak-yang.html