Analisis Terstruktur

1.1       PEMODELAN DATA

            Pemodelan data menjawab serangkaian pertanyaan spesifik yang relevan dengan aplikasi pemrosesan data. Apakah objek data utama yang akan diproses oleh system ? Bagaimana komposisi dari masing-masing objek data dan atribut apa yang menggambarkan objek tersebut? Dimana objek saat ini berada? Bagaimana hubungan antara masing-masing objek data dan objek yang lainnya? Bagaimana hubungan objek dengan proses yang mentransformasikannya?

Untuk menjawab pertanyaan-pertanyaan tersebut, metode pemodelan data menggunakan ERD. ERD hanya berfokus pada data (sehingga memuaskan prinsip pertama analisis operasional).

2.1       Objek Data, Atribut Dan Hubungan

            Model data terdiri dari tiga informasi yang saling bergantungan :

1.      Objek Data adalah representasi dari hampir semua informasi gabungan yang harus dipahami oleh perangkat lunak. Maksudnya dengan informasi gabungan kita mengartikan sesuatu yang memiliki sejumlah sifat atau atribut yang berbeda. Contohnya orang atau mobil dapat dipandang sebagai objek data bila salah satu dari mereka dapat didefinisikan dalam bentuk atribut.

1.      Atribut  menentukan properti suatu objek data dan mengambil salah satu dari tiga karakter hyang berbeda. Atribut dapat digunakan untuk :

1.      Menamai sebuah contoh dari objek data

2.      Menggambar Contoh

3.      Membuat referensi kecontoh ke contoh yang lain pada table yang lain.

Sebagai tambahan, satu atribut atau lebih harus didefinisikan sebagai sebuah pengidentifikasi dimana atribut pengidentifikasi akan menjadi sebuah “kunci”. Dalam banyak kasus harga untuk mengidentifikasi adalah unik, meskipun hal itu bukan merupakan persyaratan. Dengan mengacu pada objek data mobil, pengidentifikasi yang bertanggung jawab dapat menjadi ID #.

1.      Hubungan objek data disambungkan satu dengan yang lainnya dengan berbagai macam cara. Andaikan ada dua objek data BUKU dan TOKO BUKU, objek tersebut dapat diwakilkan dengan menggunakan notasi sederhana . misalnya :

·        Toko buku memesan buku

·        Toko buku menampilkan buku

·        Took buku menstok buku

·        Toko buku menjual buku

·        Toko buku mengembalikan buku

Dapat dilihat dengan gambar sebagai berikut  : 

Penting untuk dicatat bahwa objek relationship pairs mempunyai dua arah, dimana mereka dapat dibaca dari dua arah. Toko buku memesan buku atau buku dipesan oleh toko buku.

2.2     Kardinalitas dan Modalitas

           

            Kardinalitas  Model data harus dapat merepresentasikan jumlah peristiwa dari objek didalam hubungan yang diberikan. Tiilmann (TIL. 93)  mendefinisikan kardinalitas dari objek – relationship pair dengan cara sebagai berikut :

Kardinalitas merupakan spesifikasi dari sejumlah peristiwa dari suatu (objek) yang dapat dihubungkan kesejumlah peristiwa dari (objek) yang lain. Kardinalitas biasanya diexpresikan secara sederhana ‘satu’ atau ‘banyak’. Dengan mempertimbangkan semua kombinasi dari ‘satu’ dan ‘banyak’ dua objek dapat dihubungkan sebagai :

·        Satu ke satu (1:1)                suatu peristiwa dari objek A dapat berhubungan dengan satu dan hanya kejadian dari objek B, dan sebuah peristiwa dari B hanya dapat berhubungan dari satu kejadian A, misalnya : seorang suami hanay dapat memiliki satu orang istri dan seorang istri hanya dapat memiliki satu orang suami (di New Jersey).

·        Satu ke banyak (1:N)                      suatu kejadian A dapat berhubungan dengan satu  atau lebih kejadian dari objek B, tetapi sebuah kejadian B dapat berhubungan dengan satu kejadian A, misalnya : seorang ibu  dapat memiliki banyak anak, tetapi seorang anak hanya dapat memiliki satu orang ibu saja.

·        Banyak ke banyak (N:N)               sebuah kejadian A dapat berhubungan dengan satu atau lebih kejadian dari B, sementara itu sebuah kejadian dari B dapat berhubungan dengan satu atau lebih kejadian dari A, misalnya : seorang paman dapat memiliki banyak keponakan sementara itu seorang keponakan dapat memiliki banyak paman.

Modalitas  dari suatu hubungan adalah nol bila tidak ada kebutuhan eksplisit untuk hubungan yang terjadi atau hubungan itu bersifat optional.modalitas bernilai satu apabila suatu kejadian dari hubungan merupakan perintah.

2.3       Entity – Relationship Diagram

Objec-Relationship Pair merupakan batu pertama dari model data. Pasangan ini dapat diwakili secara grafis dengan menggunakan ERD. ERD pada mulanya diusulkan oleh Peter Chen (CHE77) untuk desain system database relasional dan telah dikembangkan. Tujuan utama dari ERD adalah untuk mewakili objek data dan hubungan mereka.

Objek data diwakili oleh sebuah persegi panjang yang diberi label. Hubungan ditunjukkan dengan garis yang diberi label yang menghubungkan objek dalam variasi ERD, garis yang menghubungkan berisi sebuah label permata yang diberi label dengan hubungan tersebut. Sambungan antara data dan objek dan hubungan dibangun dengan menggunakan berbagai macam simbol khusus yang menunjukkan kardinalitas dan modalitas.

Hubungan antara mobil dan pabrik akan dipresentasikan seperti diperlihatkan didalam Gambar : 5.0  satu pabrik membangun satu atau banyak mobil. Diberikan konteks yang diimplikasikan oleh ERD, spesifikasi dari objek data mobil  (lihat pada gambar table 5.0 akan menjadi sangat berbeda dengan spesifikasi sebelumnya  (gambar 2.0) . Dengan mengamati symbol pada akhir garis sambungan antara objek dapat dilihat bahwa modalitas dari kedua peristiwa merupakan keharusan (garis vertical).

            Dengan memperluas model, kita mewakili ERD yang sangat disederhanakan  (gambar 6.0) dari elemen distribusi  bisnis aotomotif.

Notasi ERD juga memberikan suatu mekanisme yang mewakili asosiativitas antar objek, sebuah objek data asosiatif di representasikan seperti diperlihatkan didalam gambar 7.0. didalam gambar tersebut objek data yang memodelkan subsistem individual masing-masing  diasosiasikan dengan objek data mobil.

Pemodelan data dan ERD memberi notasi yang singkat untuk mengamati data didalam konteks aplikasi pemrosesan data kepada analis. Dalam sebbagian besar kasus, pendekatan pemodelan data digunakan untuk menciptakan satu potong analisis, tetapi dia juga dapat digunakan untuk perancangan database dan untuk mendukung metode analisis persyaratan yang lain.

1.2         PEMODELAN FUNGSIONAL DAN ALIRAN INFORMASI

Analisis terstruktur dimulai sebagai sebuah teknik pemodelan aliran informasi. Sebuah sistem berbasis komputer direpresentasikan sebagai sebuah transformasi informasi. Sebagai contoh terlihat pada gambar 4.0 keseluruhan fungsi dari sistem tersebut diwakilkan sebagai transformasi informasi tunggal, yang ditulis sebagai gelembung didalam gambar. Satu input atau lebih diperlihatkan oleh anak panah yang diberi label , berasal dari entitas eksternal. Yang direpresentasikan sebagai sebuah kotak. Input mengendalikan transformasi tersebut untuk memproduksi informasi Output yang dilewatkan ke entitas eksternal.

2.1 Diagram Aliran Data

            Pada saat informasi mengalir melalui pernagkat lunak, dia dia dimodifikasi oleh suatu deretan transformasi. Diagram aliran data / data flow diagram (DFD) adalah sebuah teknik grafis yang menggambarkan aliran informasi dan transformasi yang diaplikasikan pada saat data bergerak dari input menjadi output. Bentuk dasar  dari suatu aliran data diilustrasikan didalam gambar 4.0. DFD juga dikenali sebagai grafik aliran aliran data atau bubble chart.

DFD tingkat 0 yang disebut juga dengan model system fundamentasi atau model konteks, merepresentasi seluruh elemen system sebagai sebuah bubble tunggal dengan data input dan output yang ditunjukkan oleh anak panah yang masuk dan keluar secara berurutan. Proses tambahan (bubble) dan jalur aliran informasi direpresentasikan pada saat DFD tingkat 0 dipartisi untuk megungkap detail yang lebih. Contohnya, sebuah DFD tingkat 1 dapat berisi lima atau enam bubble dengan anak panah yang saling menghubungkan.

Notasi dasar yang digunakan untuk menciptakan suatu DFD diilustrasikan didalam gambar 5.0

Read more »

Metode Spiral Boehm

Spiral Boehm

Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum oleh banyak agen pemerintah dan pembuat perangkat lunak. Jadi, tidak mudah melupakan model tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Kita membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua model umum seperti yang telah kita bicarakan sebelumnya. Model perbaikan tersebut juga harus memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Pendekatan alternatif diusulkan oleh Boehm (1988). Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum.

Model Boehm bebrbentuk spiral. Setiap loop mewakili sebuah tahap dari proses perangkat lunak.

Tidak ada tahap yang tetap dalam model ini. Manajemen harus memutuskan bagaimana membentuk proyek kedalam tahap-tahap. Perusahaan biasanya bekerja dengan beberapa model umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan selama pembuatan proyek.

Setiap loop dibagi dalam 4 sektor

1. Pembuatan tujuan
Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan. Rencan rinci manajemen juga ditulis lengkap. Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada.
2. Perkiraan dan pengurangan resiko
Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian diambil langkah-langkah untuk mengurangi resiko. contohnya, jika ada resiko bahwa persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat dikembangkan.
3. Pengembangan dan validasi
Setelah evaluasi resiko, sebuah model pengembangan untuk sistem dipilih. Misalnya, jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evolusioner dengan menggunakan model contoh (prototipe) Jika resiko keselamatan yang diutamakan, model pengembangan yang sesuai adalah transformasi formal dan seterusnya. Model waterfall mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem.
4. Perencanaan

Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan kembali dan rencana dibuat untuk tahap selanjutnya.Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sisten perangkat lunak. Model spiral encompasses model lainnya. Pemodelan digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Kemudian dapat diikuti oleh model konvensional, waterfall. Transformasi formal digunakan untuk mengembangkan bagian-bagian sistem yang memiliki persyaratan keselamatan yang tinggi dan pendekatan reuse digunakan untuk pengimplementasian bagian-bagian lain dari sistem data manajemen.

Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasikan dengan model yang lain. Pemodelan waterfall, yang sangat bagus dalam menentukan millestones dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.

Manajemen Resiko

Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral dengan eksplisit menyadari resiko-resiko yang ada. Resiko adalah konsep yang sulit didefinisikan secara tepat. Secara informal resiko adalah sesuatu yang sederhana yang dapat menyebabkan kesalahan. Contohnya, jika bertujuan menggunakan pemprograman bahasa baru (new programming language), resiko yang mungkin adalah alat pengumpul yang digunakan tidak reliabel dan tidak menghasilkan code objek yang efesien.

Resiko adalah sebagai hasil ketidakcukupan informasi. Resiko tersebut dapat dipecahkan dengan pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. Dalam contoh diatas, resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Jika sistem ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah.

Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance, kegunaan, dan seterusnya. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaik-baiknya kemudian diperhitungkan. Setiap alternatif diperhitungan bertentangan dengan tujuan. Ini biasanya menghasilkan identifikasi sumber resiko proyek. Langkah selanjutnya adalah mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail, pembuatan model/contoh, simulasi dan seterusnya. Untuk menggunakan model spiral, Boehm menyarankan sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Bentuk ini mungkin dilengkapi pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk.

Read more »

Metode RAD

Rapid Aplication Development (RAD) adalah sebuah proses perkembangan perangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase-fase sbb :

Bussiness modeling. Aliran informasi diantara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan-pertanyaan berikut :

Informasi apa yang mengendalikan proses bisnis? Informasi apa yang dimunculkan? Siapa yang memunculkannya?  Ke mana informasi itu pergi? Siapa yang memprosesnya?

Data modeling. Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modeling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut.

Proses modeling. Aliran informasi yang didefinisikan di dalam fase data modeling ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus atau mendapatkan kembali  objek data.

Aplication generation. RAD mengasumsikan pemakaian teknik generasi keempat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD telah banyak memproses

kerja untuk memakai lagi komponen program yang ada atau menciptakan komponen yang bisa dipakai lagi.

Testing and turnover. Karena proses RAD menekankan pada pemakaian kembali, banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tetapi komponen baru harus diuji dan semua interface harus dilatih secara penuh.

Seperti semua proses model yang lain, pendekatan RAD memiliki kekurangan :

-          Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik

-          RAD menuntut pengembang dab pelanggan memiliki komitmen di dalam aktivitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada dari tiap konstituen, proyek RAD akan gagal. 



Keunggulan :

·         Setiap fungsi mayor dapat dimodulkan dalam waktu tertentu kurang dari 3 bulan dan dapat dibicarakan oleh tim RAD yang terpisah dan kemudian diintegrasikan sehingga waktunya lebih efisien

·         RAD mengikuti tahap pengembangan sistem seperti umumnya, tetapi mempunyai kemampuan untuk menggunakan kembali komponen yang ada sehingga pengembang tidak perlu membuat dari awal lagi dan waktu yang lebih singkat

Kelemahan :



·         Model yang besar (skala proyek), membutuhkan resources yg baik dan solid

·         Membutuhkan komitmen pengembang dan user yang sama agar cepat selesai sesuai dengan rencana

Read more »

Metode Incremental

REKAYASA PERANGKAT LUNAK (THE INCREMENTAL MODEL)

THE INCREMENTAL MODEL

Pengertian

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.

Contoh Penggunaan Incremental Model

Misalnya, perangkat lunak pengolah kata yang dikembangkan dengan menggunakan paradigma penambahan akan menyampaikan manajemen file dasar, editing serta fungsi penghasilan dokumen pada penambahan pertama; kemudian editing dan kemampuan penghasilan dokumen yang lebih canggih pada pertambahan kedua; pengecekan spelling dan tata bahasa pada pertambahan ketiga; serta kemampuan pengaturan halaman tingkat lanjut pada tahap pertambahan keempat. Harus dicatat bahwa aliran proses untuk berbagai pertambahan tersebut dapat menggabungkan paradigma prototype.

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

Read more »

Metode Waterfall

Metode-metode pada RPL yaitu meliputi :

1.Waterfall.

2.Incremental.

3.RAD.

Masing –masing memiliki penjelasan yang berbeda-beda,berikut adalah penjelasan dari setipa metode-metode tersebut.

A.      Waterfall

Apa itu waterfall ? , waterfall : mengambil kegiatan dasar seperti spesifikasi , pengembangan validasi, evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak , implementasi , pengujian dan seterusnya.

Kelebihan dari metode waterfall adalah sebagai berikut:

1.       Setiap tahap dikerjakan dengan lengkap dan jelas.

2.       Dokumentasi sangat baik.

3.       Model proses waterfall menngusulkan sebuah pendekatan kepada perkembangan perangkat lunak yang sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian, dan pemeliharaan. Dan dimodelkan setelah siklus rekayasa konvensiaonal, dimana model sekuensial linier ataupun waterfall proses melingkupi aktivitas-aktivitas sebagai berikut:

a.       Rekayasa dan pemodelan sistem/informasi.

b.      Analisis kebutuhan perangkat lunak.

c.       Desain

d.      Generasi kode

e.      Pengujian

f.        Pemeliharaan

4.       Ketika semua kebutuhan sistem dapat didefinisikan secara utuh , eksplisit, dan benar di awal project, maka software engineering dapat berjalan dengan baik dan tanpa masalah.Meskipun seering klai kebutuhan system tidak dapat didefinisikan seeksplisit yang diinginkan, tetapi paling tidak, problen pada kebutuhan system diawal project lebih ekonomis dalam hal uang (lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan problem yang muncul pada tahap-tahap selanjutnya.

5.       Efisiensi waktu dan teknis kerja.

B.      Apa kelemahan waterfall?

Kelemahan dari pada metode/model adalah perlu adanya informasi yang lengkap pada setiap tahapnya, dan bukan sesuatu hal yang mudah untuk mendapatkan informasi tersebut. Pada prakteknya, sering tidak mungkin untuk menulis dokumentasi kebutuhan yang lengkap sebelum dibangun prototipe. Sehingga yang terjadi adalah “kerja dua kali”, membuat prototipe, kemudian dari prototipe diperoleh informasi kebutuhan dan barulah dibangun sistem final.

Read more »