Category Archives: Lanjut
tingkat lanjut
Pengetahuan Dasar dan contoh Diagram Kelas (class diagram)
Artikel ini adalah bagian dari tulisan pengetahuan dasar UML
Class diagram adalah model statis yang menggambarkan struktur dan deskripsi class serta hubungannya antara class. Class diagram mirip ER-Diagram pada perancangan database, bedanya pada ER-diagram tdk terdapat operasi/methode tapi hanya atribut. Class terdiri dari nama kelas, atribut dan operasi/methode.
Atribut dan operation (metoda) dapat memiliki salah satu sifat berikut :
1. Private, hanya bisa dipanggil dari dlm kelas itu sendiri. methode/atribut diawali “-“.
2. Protected, hanya dapat dipanggil oleh class yang bersangkutan dan class turunannya. methode diawali dg tanda “#”.
3. Public, dapat dipanggil dari semua objek. methode/atribut diawali tanda “+”
Tabel berikut ini penjelasan symbol relationships antar class yg digunakan pada diagram class
Relasi Generalisasi digunakan dalam hubungan antara kelas induk dengan kelas turunan ( inherited) .
Relasi agregasi digunakan ketika satu kelas dibentuk (terdiri dari ) dari kelas kelas lain.
Relationship Multiplicity
Mutiplicity atau multiplisitas menunjukkan jumlah suatu objek yang bisa berhubungan dengan objek lain.
Contoh class diagram
sumber:
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/
http://www.uml-diagrams.org/class-diagrams.html
http://en.wikipedia.org/wiki/Class_diagram
Pengetahuan Dasar dan Contoh Diagram Aktivitas
Artikel ini lanjutan dari : Pengetahuan Dasar UML
Model fungsional sebuah system menggambarkan proses bisnis dan interaksi dari sebuah sistim informasi dengan lingkungannya. Di dalam pengembangan sistim berorientasi object ada dua tipe model yg digunakan untuk meggambarkan fungsi sistim informasi yaitu diagram aktifitas dan diagram use case.
Diagram aktivitas digunakan untuk menggambarkan proses bisnis (alur kerja) suatu sistem informasi.
Sebuah Diagram aktivitas menunjukkan suatu alur kegiatan secara berurutan. Diagram aktivitas digunakan untuk mendiskripsikan kegiatan-kegiatan dalam sebuah operasi meskipun juga dapat digunakan untuk mendeskripsikan alur kegiatan yang lainnya seperti use case atau suatu interaksi.
Semua projek pengembangan berorientasi object saat ini menerapkan diagram aktifitas dan diagram use cases untuk mendokumentasikan dan mengorganisaikan kebutuhan selama phase analysis sebuah systim.
Berikut adalah simbol-simbol yang ada pada diagram aktivitas:
Diagram aktivitas mendeskripsikan aliran kerja dari perilaku sistem. Diagram ini hampir sama dengan diagram status karena kegiatan-kegiatannya merupakan status suatu pekerjaan dengan menunjukkan kegiatan yang dilakukan secara berurutan. Sebaiknya diagram aktivitas digunakan untuk melengkapi diagram lain seperti diagram interaksi dan diagram status, karena diagram aktivitas dapat mengetahui aliran sistem yang akan dirancang. Selain itu diagram aktivitas bermanfaat untuk menganalisis use case melalui penggambaran aksi-aksi yang dibutuhkan, penggambaran algoritma berurutan yang kompleks, dan pemodelan aplikasi dengan proses paralel. Tetapi diagram aktivitas tidak menunjukkan bagaimana objek berperilaku atau objek berkolaborari secara detil.
contoh diagram aktivitas login sebuah sistem:
Sumber :
– system and analisys design with UML. Denis
– Analisa perancangan sistim informasi. Poltek telkom
Pengetahuan Dasar Diagram Use Case
Article ini merupakan lanjutan dari : Pengetahuan dasar UML
- Diagram use case merupakan pemodelan untuk menggambarkan kelakuan (behavior) sistem yang akan dibuat.
- Diagram use case mendeskripsikan sebuah interaksi antara satu atau lebih aktor dengan sistem yang akan dibuat.
- Diagram use case digunakan untuk mengetahui fungsi apa saja yang ada di dalam sebuah sistem dan siapa saja yang berhak menggunakan fungsi-fungsi tersebut. Yang ditekankan pada diagram ini adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”.
- Sebuah use case merepresentasikan sebuah interaksi antara aktor (user atau sistem lainya) dengan sistem.
- Use case menjelaskan secara sederhana fungsi sistem dari sudut pandang user.
Penjelasan bagian bagian use case diagram
1. System
Menyatakan batasan sistem dalam relasi dengan actor-actor yang menggunakannya (di luar sistem) dan fitur-fitur yang harus disediakan (dalam sistem). Digambarkan dengan segi empat yang membatasi semua use case dalam sistem terhadap pihak mana sistem akan berinteraksi. Sistem disertai label yang menyebutkan nama dari sistem, tapi umumnya tidak digambarkan karena tidak terlalu memberi arti tambahan pada diagram.
2. Actor
Aktor adalah segala hal diluar sistem yang akan menggunakan sistem tersebut
untuk melakukan sesuatu. Bisa merupakan manusia, sistem, atau device yang memiliki peranan dalam keberhasilan operasi dari sistem. Cara mudah untuk menemukan aktor adalah dengan bertanya hal-hal berikut: SIAPA yang akan menggunakan sistem? APAKAH sistem tersebut akan memberikan NILAI bagi aktor?
3. Use case
Mengidentifikasi fitur kunci dari sistem. Tanpa fitur ini, sistem tidak akan memenuhi permintaan user/actor. Setiap use case mengekspresikan goal dari sistem yang harus dicapai. Diberi nama sesuai dengan goal-nya dan digambarkan dengan elips dengan nama di dalamnya. Fokus tetap pada goal bukan bagaimana mengimplementasikannya walaupun use case berimplikasi pada prosesnya nanti. Setiap use case biasanya memiliki trigger/pemicu yang menyebabkan use case memulai (misalnya,Pasien mendaftar dan membuat janji baru atau meminta untuk membatalkan atau mengubah janji yang sudah ada ).ada 2 triger pertama triger eksternal, seperti pelanggan memesan atau alarm kebakaran berbunyi, kedua triger temporal, seperti tanggal pengembalian buku terlewati di perpustakaan atau keterlambatan bayar sewa.
4. Assosiation
Mengidentifikasikan interaksi antara setiap actor tertentu dengan setiap use case tertentu. Digambarkan sebagai garis antara actor terhadap use case yang bersangkutan. Asosiasi bisa berarah (garis dengan anak panah) jika komunikasi satu arah, namun umumnya terjadi kedua arah (tanpa anak panah) karena selalu diperlukan demikian.
5 Dependency
Dependensi <<include>>
- o Mengidentifikasi hubungan antar dua use case di mana yang satu memanggil yang lain.
- o Jika pada beberapa use case terdapat bagian yang memiliki aktivitas yang sama maka bagian aktivitas tersebut biasanya dijadikan use case tersendiri dengan relasi dependensi setiap use case semula ke use case yang baru ini sehingga memudahkan pemeliharaan.
- Digambarkan dengan garis putus-putus bermata panah dengan notasi <<include>> pada garis.
- o Arah mata panah sesuai dengan arah pemanggilan.
Dependensi <<extend>>
o Jika pemanggilan memerlukan adanya kondisi tertentu maka berlaku dependensi <<extend>>.
o Note: konsep “extend” ini berbeda dengan “extend” dalam Java!
o Digambarkan serupa dengan dependensi <<include>> kecuali arah panah berlawanan.
6. Generalization
Mendefinisikan relasi antara dua actor atau dua use case yang mana salah satunya meng-inherit dan menambahkan atau override sifat dari yang lainnya. Penggambaran menggunakan garis bermata panah kosong dari yang meng-inherit mengarah ke yang di-inherit.
Menyusun Diagram Use case
Langkah-langkah yang dibutuhkan untuk menyusun diagram use case adalah:
- Mengidentifikasi pelaku bisnis
- Mengidentifikasi use case persyaratan bisnis
- Membuat diagram model use case
- Mendokumentasikan naratif use case persyaratan bisnis
Practical guidance dalam membangun diagram use case:
- Set konteks dari target sistem.
- Identifikasi semua actor.
- Identifikasi semua use case.
- Definisikan asosiasi antara setiap actor dan setiap use case.
- Evaluasi setiap actor dan setiap use case untuk mendapatkan kemungkinan perbaikan.
- Evaluasi setiap use case untuk dependensi <<include>>.
- Evaluasi setiap use case untuk dependensi <<extend>>.
- Evaluasi setiap actor dan setiap use case untuk generalisasi.
Use case Description
Setiap use case harus dijelaskan alur prosesnya melalui sebuah deskripsi use case (use case description) atau scenario use case.
Deskripsi use case berisi:
- Nama use case yaitu penamaan use case yang menggunakan kata kerja
- Deskripsi yaitu penjelasan mengenai tujuan use case dan nilai yang akan didapatkan oleh aktor
- Kondisi sebelum (pre-condition) yaitu kondisi-kondisi yang perlu ada sebelum use case dilakukan.
- Kondisi sesudah (post-condition) yaitu kondisi-kondisi yang sudah dipenuhi ketika uses case sudah dilaksanakan
- Alur dasar (basic flow) yaitu alur yang menceritakan jika semua aksi yang dilakukan adalah benar atau proses yang harusnya terjadi
- Alur alternatif (alternatif flow) yaitu alur yang menceritakan aksi alternatif, yang berbeda dari alur dasar.
Mana yg lebih dahulu dibuat use case description atau use case diagram ? sebaiknya use case description lebih dahulu. tapi kalau anda ingin membuat use case digram lebih dahulu juga tdk apa-apa. Yang penting kedua duanya anda buat untuk menggambarkan/menjelaskan kebutuhan sistem.
contoh diagram use case
Pengetahuan Dasar UML (dasar membuat diagram class, Use case diagram, digram activity, diagram sequence dll )
Tulisan ini adalah lanjutan dari teori Dasar analisis dan desain sistem.
Pemodelan
Pemodelan adalah gambaran dari realita yang simpel dan dituangkan dalam bentuk pemetaan dengan aturan tertentu. Pemodelan digunakan untuk menggambarkan desain sistem.
Pada perkembangan teknik pemrograman berorientasi objek, muncullah sebuah standarisasi bahasa pemodelan untuk pembangunan perangkat lunak yang dibangun dengan menggunakan teknik pemrograman berorientasi objek, yaitu Unified Modeling Language (UML). UML muncul karena adanya kebutuhan pemodelan visual untuk menspesifikasikan, menggambarkan, membangun, dan dokumentasi dari sistem perangkat lunak. UML merupakan bahasa visual untuk pemodelan dan komunikasi mengenai sebuah sistem dengan menggunakan diagram.
UML terdiri dari bermacam-macam diagram yg digunakan untuk permodelan pada saat pengembangan sistem mulai dari tahap analisi sampai implementasi. Pada saat melakukan desain sistem, tidak harus semua diagram pada UML diimplementasikan akan tetapi UML merupakan diagram yang saling terkait oleh karena itu perlu adanya kekonsistenan rancangan diagram yang satu dengan lainnya.
Diagram dlm UML dikelompokan menjadi 2 :
1. Diagram Struktur /statis diagram .
2. Diagram prilaku system/behaviour diagram.
Penjelesan singkat diagram tsb antara lain
Nama Diagram | Digunakan untuk | Digunakan pd tahapan: |
Diagram Class | Menggambarkan hubungan antara model class dlm system. | Analysis, Design |
Diagram status | Diagram status menjelaskan aliran kontrol dari satu status ke status lain. Status didefenisikan sebagai suatu kondisi dari suatu obyek yang ada dan perubahan yang terjadi sekiranya ada event yang terpicu.. | Analysis, Design |
Diagram Aktivitas | Menggambarkan hubungan aliran kerja business terlepas dari classes, aliran activitas dlm sebuah use case, atau detail design dari method. | Analysis, Design |
Diagram Use Case | Mendapatkan persyaratan/kebutuhan system dan menggambarkan hubungan antara system dgn lingkungan. | Analysis |
Diagram sequence | Memodelkan prilaku objects dlm sebuah use case. Focus pd urutan berdasar waktu dari sebuah activity. |
Analysis, Design |
Diagram yang akan dibahas pada blog ini hanya 4 diagram UML yg efektif biasa dipakai antara lain diagram use case , diagram sekuen, diagram class dan diagram aktifitas
Gambar berikut dibawah ini menggambarkan diagram diagram tsb dan memperlihatkan bagaimana diagram yang satu membantu membentuk diagram yang lainnya.
Case (Computer-aided software engineering) Tools
Case tool adalah sejenis software untuk membuat secara otomatis/wizard sebagian atau keseluruan proses depelopment sistem.
Untuk membuat berbagai diagram UML baik pada tahap analisis maupun design digunakan Case To0ls diataranya adalah ArgoUML, StartUML dan Astah Comunity. Selain itu anda juga bisa menggunakan Ms Visio . Berikut ini gambar tampilan salah satu case tool yaitu Astah Comunity :
Diagram Use Case
Diagram use case merupakan pemodelan untuk menggambarkan kelakuan (behavior) sistem secara keseluran yang akan dibuat. Diagram use case mendeskripsikan sebuah interaksi antara satu atau lebih aktor dengan sistem yang akan dibuat. Dengan pengertian yang cepat, diagram use case digunakan untuk mengetahui fungsi apa saja yang ada di dalam sebuah sistem dan siapa saja yang berhak menggunakan fungsi-fungsi tersebut.
Diagram Kelas
Diagram kelas atau class diagram menggambarkan struktur sistem dari segi pendefinisian kelas-kelas yang akan dibuat untuk membangun sistem.
Diagram Sequence
Diagram sekuen menggambarkan kelakuan/perilaku objek pada use case
dengan mendeskripsikan waktu hidup objek dan message yang dikirimkan dan
diterima antar objek. Oleh karena itu untuk menggambar diagram sekuen
maka harus diketahui objek-objek yang terlibat dalam sebuah use case beserta
metode-metode yang dimiliki kelas yang diinstansiasi menjadi objek itu.
Diagram Aktivitas
Diagram aktivitas atau activity diagram menggambarkan workflow (aliran kerja) atau aktivitas dari sebuah sistem atau proses bisnis. Yang perlu diperhatikan disini adalah bahwa diagram aktivitas menggambarkan aktivitas sistem bukan apa yang dilakukan aktor, jadi aktivitas yang dapat dilakukan oleh sistem.
sumber
contoh lengkap analisis-design OOP :
– sistem AddressBook : http://www.cs.gordon.edu/courses/cs211/AddressBookExample/index.html
– sistem ATM:
Pengetahuan Dasar Analisis dan Desain Sistem (informasi)
APA yg dimaksud dgn system?
Siklus/fase/tahapan pengembangan sebuah system adalah : perencanaan, analisa, desain , implementasi . Siklus ini biasa juga disebut SDLC = system development life cycle.
Kalau anda yg pernah kuliah di fak teknik (khususnya) IT dan sudah atau sedang membuat skripsi pasti sudah tdk asing lagi dgn siklus ini dlm membuat sistem informasi, biasanya perencanaan di ditempatkan pd Bab 1, dasar teori bab 2 , analisis di bab 3 , desain di bab 4 , implementasi bab 5 … begitu kan? he 2x.. berikut ini contoh kongkritnya daftar isi dari sebuah skripsi :
TABLE OF CONTENTS
I. INTRODUCTION
II. LITERATURE REVIEW
III. SYSTEM ANALYSIS
IV. SYSTEM DESIGN
V. SYSTEM DEVELOPMENT
VI. SYSTEM TESTING AND EVALUATION
VII. CONCLUSIONS AND FUTURE WORK
Berikut table tahapan/fase pengembangan sistem/ SDLC :
Tahapan SDLC | Langkah langkah | Teknik yg digunakan | Hasil |
Perencanaan:
|
|
|
System request |
Analisis:
|
|
————————————-
————————————-
|
proposal sistemRequirements definitionUse casesProcess modelsData model |
Desain:
|
|
|
System specification |
Implementasi:
|
|
|
Test planProgramsDocumentationMigration planSupport planProblem report |
Secara garis besar tema tulisan ini hanya akan membahas dua hal yaitu analisis dan design sistem ( dalam hal ini sistem informasi), karena dalam Pengembangan sistem informasi ada dua fase utama: analisis dan Desain. Pengembangan sistem dilakukan apabila sistem yang lama sudah tidak memadai atau tdk bisa memenuhi kebutuhan atau pun perkembangan organisasi/perusahaan.
Selama fase analisis fungsi lengkap dari sistem dipahami dan kebutuhan persyaratan ditentukan yg digunakan untuk membuat desain sistem baru. Oleh karena itu proses pengembangan sistem juga dikenal sebagai proses Analisis dan Desain sistem.
Planning (Perencanaan)
Tahap perencanaan adalah proses dasar memahami mengapa sistem informasi
harus dibangun dan menentukan bagaimana tim proyek akan membangun sistim tsb. perencanaan memiliki dua langkah:
1. Selama inisiasi proyek, nilai bisnis sistem untuk organisasi diidentifikasi:
bagaimana hal itu menurunkan biaya atau meningkatkan pendapatan? Sebagian besar ide untuk sistem baru datang dari luar daerah sistim informasi (dari departemen pemasaran, departemen akuntansi,dll) dalam bentuk permintaan sistem. Permintaan sistem menyajikan ringkasan singkat kebutuhan bisnis , dan menjelaskan bagaimana sebuah sistem yang mendukung kebutuhan akan menciptakan nilai bisnis. departement sitem informasi bekerja sama dengan orang atau departemen lain
yang menghasilkan permintaan (disebut sponsor proyek) untuk melakukan analisis kelayakan.
Analisis kelayakan mengkaji aspek-aspek kunci dari proyek yang diusulkan:
■ kelayakan teknis (Bisakah ide itu diterapkan secara teknis?)
■ Kelayakan ekonomi (Apakah akan memberikan nilai bisnis?)
■ Kelayakan organisasi (Jika kita membangunnya, apakah sistem itu akan digunakan?)
Permintaan sistem dan analisis kelayakan disajikan ke sistem informasi
persetujuan komite (kadang-kadang disebut komite pengarah), yang memutuskan
apakah proyek tersebut harus dilakukan.
2. Setelah proyek disetujui, memasuki manajemen proyek. Selama manajemen proyek,
manajer proyek menciptakan sebuah rencana kerja, menentukan staf proyek, dan menggunakan teknik2 untuk membantu kontrol tim proyek dan mengarahkan proyek melalui seluruh tahapan SDLC. Hasil yg akan diserahkan untuk manajemen proyek adalah rencana proyek, yang menjelaskan bagaimana tim proyek akan mengembangkan sistem.
Analisis sistem
Analisis sistem adalah mendefinisikan kebutuhan atau persyaratan terkait sistem yang akan dikembangkan.
Pada fase ini menjawab pertanyaan siapa pengguna sistem, apa yg sistim akan lakukan, kapan dan dimana sistim akan diterapkan. Dengan cara menganalisis system yg sedang berjalan, mencari celah celah perbaikan,dan membangun konsep untuk sistim yg baru.
Ada 3 tahapan dalam phase Analisis ini antara lain:
1. Membuat strategi analisis untuk pendamping usaha2 yg akan dilakukan team project.
2. Mengumpulkan persyaratan/kebutuhan untuk membuat konsep sistem. Konsep sistem digunakan untuk dasar pembuatan analisis model bisnis.
Secara kategori, ada tiga buah jenis kebutuhan sistem :
- Kebutuhan Fungsional.
- kebutuhan non fungsional :
- Kebutuhan Antar muka (interface), spt interface ke database, menu interface dll.
- Kebutuhan performance (kinerja), spt kecepatan , delay, kapasitas dll.
Kemudian kebutuhan tersebut akan dimodelkan atau digambarkan dengan teknik analisis dan alat bantu tertentu. Sebagai contoh kebutuhan fungsional dapat dimodelkan dengan menggunakan
– Data flow diagram,kamus data,dan spesifikasi proses jika menggunakan anlisis tertsruktur.
– Use case diagram dan skenario sistem jika menggunkan analisis berorientasi objek.
3. Analisis, konsep sistem dan model bisnis dikombinasikan untuk membuat proposal sistem , proposal ini akan diajukan kepada fihak yg akan memutuskan apakah project di teruskan atau tdk.
Desain sistem
Tahap desain memutuskan bagaimana sistem akan beroperasi, dalam hal perangkat keras, perangkat lunak, dan jaringan infrastruktur; antarmuka pengguna, formulir dan laporan, dan program khusus, database, dan file yang akan dibutuhkan.
Tahap desain memiliki empat langkah:
1. Strategi desain pertama kali dibuat. Ini menjelaskan apakah sistem tersebut akan dibuat oleh programmer perusahaan sendiri, apakah sistem akan outsourcing ke perusahaan lain (biasanya perusahaan konsultan), atau apakah perusahaan akan membeli ada paket perangkat lunak.
2. Ini (langkah no 1) mengarah pada pengembangan desain arsitektur dasar untuk sistem, yang menggambarkan perangkat keras, perangkat lunak, dan infrastruktur jaringan yang akan digunakan. di banyak kasus, sistem akan menambah atau mengubah infrastruktur yang sudah ada dalam organisasi. Desain antarmuka menentukan bagaimana pengguna akan bergerak melalui sistem dan (misalnya, navigasi metode seperti menu dan tombol pada layar) form dan laporan yg digunakan sistem .
3. Spesifikasi database dan file yang dikembangkan, mendefinisikan dengan tepat data apa yg akan akan disimpan dan di mana mereka akan disimpan.
4. Tim analis mengembangkan rancangan/design program, yang mendefinisikan program yang harus ditulis dan apa yang akan tiap program lakukan.
Gabungan hasil2 dari tiap tahap (arsitektur desain, desain interface, database dan file
spesifikasi, dan desain program) adalah spesifikasi sistem yang diserahkan ke tim pemrograman untuk implementasi. Pada akhir tahap desain, analisis kelayakan
dan rencana proyek dikaji ulang dan direvisi, dan keputusan lain yang dibuat oleh proyek sponsor dan komite persetujuan tentang apakah untuk mengakhiri proyek atau melanjutkan.
Implementasi
Tahap terakhir dalam SDLC adalah tahap implementasi, di mana sistem ini benar-benar dibangun (atau dibeli, dalam hal desain paket perangkat lunak). Ini adalah fase yang biasanya mendapatkan perhatian yang besar, karena untuk kebanyakan sistem itu adalah bagian paling lama dan paling mahal dari proses pembangunan.
Fase ini memiliki tiga langkah:
1. Sistem konstruksi adalah langkah pertama. Sistem ini dibangun dan diuji untuk memastikan ia bekerja seperti yang telah dirancang. Karena biaya perbaikan bisa sangat besar, pengujian adalah salah satu langkah yang paling penting dalam implementasi . Banyak organisasi memberikan lebih banyak waktu dan
perhatian pada pengujian daripada menulis program.
2. Sistem ini diinstal. Instalasi adalah proses dimana sistem lama non aktifkan
dan yang baru dihidupkan. Ini mungkin termasuk pendekatan cutover langsung (dalam mana sistem baru segera menggantikan sistem lama), konversi paralel
pendekatan (di mana kedua sistem lama dan baru dioperasikan selama satu bulan atau dua bulan sampai jelas bahwa tidak ada bug di sistem baru), atau konversi bertahap
strategi (di mana sistem baru dipasang di salah satu bagian dari organisasi sebagai
awal percobaan dan kemudian secara bertahap dipasang di bagian lain). Salah satu yang paling penting aspek konversi adalah pengembangan rencana pelatihan untuk mengajar user bagaimana menggunakan sistem baru dan membantu mengelola perubahan yang disebabkan oleh sistem baru.
3. Tim analis menetapkan rencana support untuk sistem. Rencana ini biasanya
mencakup kajian pasca implementasi formal atau informal serta cara sistematis
untuk mengidentifikasi perubahan besar dan kecil diperlukan untuk sistem.
Beberapa Metodologi / Cara pendekatan formal penerapan SDLC
ada 3 kelompok/katagori penerapan SDLC antara lain :
1. Desain Terstruktur
Metodologi desain terstruktur menggunakan pendekatan langkah-demi-langkah formal SDLC yang bergerak secara logis dari satu tahap ke tahap berikutnya.
banyak Metodologi berpusat pd proses dan berpusat pada data mengikuti pendekatan dasar dua kategori desain terstruktur yaitu :.
- Waterfall development : analisa dan pengguna diproses secara berurutan dari satu tahap ke tahap berikutnya.
- Parallel development : membuat desain secara umum untuk seluruh sistem dan kemudian membagi proyek menjadi serangkaian sub-proyek yang berbeda yang dapat dirancang dan dilaksanakan secara paralel. Setelah semua sub-proyek selesai, integrasi akhir dari potongan-potongan terpisah, dan sistem ini di delivery. Metodologi pengembangan Paralel untuk mengatasi masalah
penundaan yang lama antara tahap analisis dan deliveri/pengiriman sistem.
2. Rapid aplication developmen (RAD)
Metodologi berbasis RAD berusaha untuk mengatasi kedua kelemahan metodologi desain terstruktur dengan menyesuaikan fase SDLC untuk mendapatkan beberapa bagian dari sistem dikembangkan dengan lebih cepat sampai tangan pengguna. Dengan cara ini, pengguna dapat lebih memahami sistem dan menyarankan revisi yang membawa sistem lebih dekat dengan apa yg dibutuhkan.
- Phased development : Sebuah metodologi berbasis pengembangan secara bertahap, memecah keseluruhan sistem menjadi serangkaian versi yg dikembangkan secara berurutan. Tahap analisis mengidentifikasi konsep sistem secara keseluruhan, tim proyek, pengguna, dan sistem sponsor kemudian mengkategorikan persyaratan menjadi serangkaian versi. Persyaratan yang paling penting dan mendasar digabung dalam versi pertama dari sistem. Tahap analisis kemudian mengarah ke desain dan implementasi-tapi hanya dengan set persyaratan yang diidentifikasi untuk versi 1
- Prototyping : Metodologi berbasis prototyp melakukan analisis, desain, dan implementasi secara bersamaan, dan ketiga fase tsb dilakukan berulang-ulang dalam sebuah siklus sampai sistem ini lengkap.
- Trowaway prototyping
3. Agile development.
– Extrem programming
to be continue
sumber:
http://www.freetutes.com/systemanalysis/
http://repository.binus.ac.id/content/H0062/H006272981.pdf
Systems Analysis and Design by Denis
Systems Analysis and Design by Kendal
System Analysis, Design,and Development by Charles S. Wasson
Systems Analysis A Beginner’s Guide by Kevin.B