Selasa, 31 Juli 2012

Manajemen Proyek Perangkat Lunak


Manajemen proyek perangkat lunak merupakan bagian yang penting dalam pembangunan perangkat lunak. Sekalipun tidak bersifat teknis seperti pengkodean, hal-hal dalam manajemen proyek PL ini mampu menentukan apakah proyek akan berjalan dengan baik sehingga menghasilkan produk yang
baik. Hal-hal yang berkaitan dengan manajemen adalah pengelolaan personel dan koordinasi tim, proses, pengukuran proyek-termasuk menentukan harga dari PL, penjadwalan dan sebagainya. Dalam pembahasan berikut, hanya sebagian kecil dari manajemen yang akan dibahas untuk memberi gambaran tentang hal-hal
manajemen yang berlaku dan diterapkan dalam pembangunan PL. 

Manajemen Personel, Produk dan Proses

Manajemen proyek perangkat lunak mengatur 4 hal penting: personel, produk, proses dan proyek. Empat hal ini berurutan mulai dari yang paling penting. Personel merupakan mendapat tempat paling penting karena tanpa personel yang baik dan tepat maka 3 hal lain tidak bisa berjalan dengan baik.

Katagori Personel

Proses pembangunan PL melibatkan banyak personel. Personel-personel ini digambarkan seperti pemain, dan dikatagorikan dalam 5 katagori pemain:

  1. Manajer senior : yang menentukan usaha yang dikerjakan, dan pemegang keputusan dalam proyek.
  2. Manajer proyek (teknis)– pemimpin tim: yang membuat rencana, memotivasi, mengatur dan mengendalikan praktisi yang mengerjakan PL
  3. Praktisi : yang mengerjakan PL
  4. Klien : yang menentukan kebutuhan PL dan pihak lain yang berkaitan dengan hasil produk
  5. Pengguna PL : yang berinteraksi langsung dengan PL yang dibangun.

Efektifitas kerja masing-masing personel di atas harus diusahakan oleh pemimpin tim. Pemimpin tim ini yang mengatur tim proyek agar dapat memberikan yang terbaik dari masing-masing personel.

Pemimpin Tim

Pemimpin Tim PL disini adalah manager proyek. Seorang pemimpin tim diharuskan mempunyai ketrampilan memimpin yang cukup. Seseorang tidak menjadi pemimpin tim secara kebetulan tapi sungguh-sungguh karena punya kemampuan. Kemampuan yang dibutuhkan dalam kepemimpinan seperti:

  • Mampu memotivasi.
  • Mampu berorganisasi : mengatur proses yang ada atau membuat yang baru dalam rangka mewujudkan ide/konsep menjadi produk.
  • Mampu mendorong keluarnya ide-ide baru: memberi dorongan, menciptakan situasi yang kondusif untuk lahirnya ide baru.
  • Mencari penyelesaian masalah (problem solving): mampu menganalisa masalah-masalah teknis ataupun manajemen/organisasi kemudian mendapatkan jalan keluar atau memotivasi anggota untuk mampu menyelesaikan masalah. Akomodatif terhadap perubahan yang mungkin terjadi.
  • Mampu menjadi manajer: menggunakan wewenangnya pada saat yang tepat, atau memberikan kebebasan pada anggota timnya jika diperlukan.
  • Mampu menghargai kerja: menghargai hasil yang dicapai, ide yang dilontarkan dan pendapat yang diajukan oleh anggota timnya.
  • Mampu mengenali tim: mampu “membaca” dan memahami anggota timnya. Mampu memenuhi kebutuhan tim dan bertahan dalam tekanan yang tinggi.
Tim Perangkat Lunak (Software Team)
Struktur organisasi dalam tim ini bisa mengadaptasi dari banyak struktur organisasi yang sudah ada. Berikut beberapa pilihan pembagian tugas/penugasan yang bisa diterapkan untuk tim perangkat lunak yang terdiri dari n personel yang bekerja selama k tahun:
  • n personel ditugaskan untuk sejumlah m tugas yang berbeda dengan sedikit tugas gabungan   =>  koordinasi adalah tugas dari manajer yang mungkin saja punya 6 proyek lainnya.
  • n personel di tugaskan untuk sejumlah m tugas yang berbeda dengan < n sehingga terbentuk tim informal. Pemimpin tim khusus perlu ada koordinasi antar tim adalah tanggung jawab manajer
  • n personel dibagi menjadi sejumlah t tim. Tiap tim ditugaskan mengerjakan satu atau lebih tugas. Tiap tugas mempunyai struktur yang ditentukan sebelumnya bagi semua tim =>  koordinasi dikendalikan oleh tim dan manager
Sekalipun masing-masing pilihan punya argumentasi sendiri-sendiri, namun dari pengamatan yang dilakukan, pilihan no 3 dianggap lebih produktif. Cara atau gaya manajemen, jumlah personel, tingkat kemampuan para personel dan masalah-masalah yang dihadapi tim menentukan bentuk struktur organisasi
yang bisa diterapkan. Contoh struktur organisasi tim adalah:
  1. Democratic Decentralized (DD) : Tidak ada pemimpin yang permanen, koordinator ditunjuk untuk jangka waktu yang pendek, keputusan diambil berdasarkan konsensus bersama, komunikasi horizontal antar anggota tim (posisi sejajar semua) cocok untuk masalah yang sulit/rumit, cocok untuk proyek besar, tim cenderung awet dan bertahan lama, pekerjaan memuaskan, cocok untuk masalah yang modularitasnya rendah, perlu banyak waktu untuk menyelesaikan proyek,
  2. Controlled decentralized (CD) : Pemimpin tim ditentukan, ada wakil pemimpin dan mereka berbagi tugas, penyelesaian masalah adalah tugas tim dan implementasinya dibagi di antara beberapa sub-tim oleh pemimpin, komunikasi horisontal di antara sub-tim dan di antara personel, komunikasi vertikal berdasarkan struktur hirarki, sentralisasi untuk penyelesaian masalah, cocok untuk masalah yang sederhana, cukup cocok untuk proyek besar, masalah dengan modularitas tinggi, menghasilkan sedikit kesalahan
  3. Controlled Centralized (CC): penyelesaian masalah dikerjakan oleh pemimpin, pemimpin melakukan koordinasi internal tim, komunikasi lebih banyak vertikal antara pemimpin dan anggota tim , cocok untuk masalah yang sederhana, melakukan penyelesaian, masalah lebih cepat, masalah dengan modularitas tinggi, menghasilkan sedikit kesalahan.

Pengukuran PL

Metric dalam software engineering didefinisikan oleh IEEE Glossary of SE sebagai a quantitative mesaure of the degree to which a system, component, or process possesses a given attribute” atau artinya pengukuran secara kuantitatif pada tingkat sistem, komponen atau proses berdasarkan katagori yang ditetapkan.

A. Pengukuran berdasarkan ukuran

Pengukuran berdasarkan PL-PL yang sudah diproduksi/dibuat sebelumnya, lengkap dengan karakteristik lain seperti line of code (LOC), harga, waktu yang diperlukan pada tiap fungsi atau proyek yang dibangun, kesalahan (error) yang ditemukan. Dari total LOC, harga dan lama waktu dapat diperoleh misalnya :
  • Harga per KLOC (seribu baris kode)
  • Kesalahan per KLOC
Cara ini kurang diterima secara universal karena pengunaan LOC untuk kunci ukuran bergantung pada bahasa pemrograman yang digunakan.

B. Pengukuran berdasarkan fungsi (Function Point – FP)

Function point ditentukan berdasarkan bagian-bagian software yang bisa dihitung seperti :
  • jumlah input dari pengguna
  • jumlah output untuk pengguna
  • jumlah user inquiry: inquiry didefinisikan sebagai online input yang menghasilkan respon langsung dari software dalam bentuk online output
  • jumlah file: baik file yang terpisah dari database, atau bagian dari file
  • jumlah external interface: misalnya data file pada storage media yang digunakan untuk mengirimkan informasi ke sistem lain.
Gambar dibawah menggambarkan proses penghitungan Function Point. Yang Kurang jelas dalam proses ini dan kurand detil adalah bagaimana menentukan berat (weight).

Gambar dibawah menjelaskan contoh penghitungan Function point berdasarkan parameter yang sudah ditentukan.

C. Ukuran untuk organisasi kecil (DRE = Defect Removal efficiency)

Untuk organisasi yang kecil mungkin bisa menggunakan ukuran seperti :
  • Waktu (hari atau jam) mulai dari permintaan/request samai evaluasi lengkap tqueue.
  • Usaha (personel-waktu) untuk melakukan evaluasi => Weval.
  • Waktu (jam atau hari) dari selesainya evaluasi sampai penugasan lain ke personel =>  teval.
  • Usaha (personel – jam) yang dibutuhkan untuk membuat perubahan   =>  Wchange.
  • Waktu (jam atau hari ) untuk melakukan perubahan =>  tchange.
  • Kesalahan yang terjadi selama pengerjaan untuk melakukan perubahan => Echange.
  • Cacat yang terjadi setelah perubahan diserahkan ke klien Dchange.
Setelah ukuran-ukuran tersebut dikumpulkan bisa beberapa hal bisa dihitung seperti total waktu dari permintaan perubahan sampai implementasi dari perubahan. Persentase usaha yang dibutuhkan untuk evvaluasi dan implementasi bisa ditetapkan. Defect Removal Effiency (DRE) bisa dihitung dengan: 

DRE = Echange / (Echange+ Dchange).

Minggu, 29 Juli 2012

Rekayasa Web


Rekayasa web adalah proses yang diunakan untuk menciptakan aplikasi web yang berkualitas tinggi. Rekayasa web mengadaptasi rekayasa perangkat lunak dalam hal konsep dasar yang menekankan pada aktifitas teknis dan manajemen. Namun demikian adaptasi tidak secara utuh, tapi dengan perubahan dan penyesuaian. Rekayasa web gabungan antara web publishing (suatu konsep yang berasal dari printed publishing) dan aktifitas rekayasa perangkat lunak. Dikatakan demikian karena desain sebuah aplikasi web menekankan pada desain grafis, desain informasi, teori hypertext, desain sistem dan pemrograman.

Ciri dan sifat WebApp (Web Application)

Aplikasi web berbeda dari software lain karena hal-hal dibawah ini:
  1. Network intensive. Sifat dasar dari WebApp (aplikasi web) adalah aplikasi ini ditujukan untuk berada di jaringan dan memenuhi kebutuhan komunitas yang berbeda.
  2. Content-Driven. Sebagian besar fungsi dari WebApp adalah untuk menyajikan informasi dalam bentuk teks, grafik, audio dan video ke end user.
  3. Continuous evolution. Selalu berkembang secara terus menerus.
  4. Document-oriented. Halaman-halaman situs yang statis akan tetap ada sekalipun sudah ada pemrograman web dengan java atau yang lain.
Selain itu WebApp memiliki karakteristik seperti berikut ini :
  1. Immediacy. Diperlukan segera untuk memenuhi ditayangkan, dipasarkan dalam waktu singkat.
  2. Security. Untuk melindungi isi yang sensitif dan menyediakan pengiriman data yang aman, keamanan suatu WebApp harus diterapkan pada seluruh infrastruktur yang mendukung WebApp dan termasuk dalam WebApp sendiri.
  3. Aesthetics. Daya tarik utama WebApp adalah tampilan dan keindahan. Jika WebApp digunakan untuk memasarkan suatu produk maka sisi aestetika harus diperhatikan sebagaimana sisi teknis.
Faktor-faktor yang menentukan kualitas suatu web digambarkan pada gambar dibawah.
Faktor-faktor kualitas pada gambar 1 adalah faktor-faktor yang membantu web developer dalam merancang dan membangun webapp yang dapat diterima dan memenuhi kebutuhan end user yang begitu beragam. Untuk memenuhi faktor-faktor kualitas tersebut, perancangan dan implementasi webapp terkait dengan 3 teknologi yang sangat penting yaitu: component-based development, security dan standart Internet. Seorang web developer harus mengenal 3 teknologi ini untuk membangun webapp yang berkualitas:
  • Component-based development : CORBA,DCOM/COM dan JavaBeans merupakan standar yang memungkinkan web developer menggunakan komponenkomponen yang sudah ada untuk berkomunikasi dengan sistem pada level lain.   
  • Keamanan: enkripsi, dan firewall 
  • Standard Internet: HTML, XML

Proses Rekayasa Web

Model yang dianggap cocok dan baik untuk rekayasa web adalah model modified waterfall dan spiral.

Modified waterfall

Tahapan dalam modified waterfall adalah :
  1. Problem definition dan concept exploration.
  2. Requirement analysis specification.
  3. Design prototyping.
  4. Implementation and unit testing
  5. Integration and system testing
  6. Operation and maintenance
pada modified waterfall, perbedaan berada pada 2 proses pertama yang dilakukan secara berulang-ulang sehingga disebut whirlpool. Tujuannya adalah dapat melengkapi requirement dan analisis secara lengkap.

Spiral

Pada spiral terbagi beberapa sektor yaitu :
  1. Determine site objectives and constraints.
  2. Identify and resolve risks.
  3. Develop the deliverables for the interation and verify that they are correct.
  4. Plan the next iteration.
Spiral model sangat masuk akal untuk rekayasa web tapi rumit dan sulit dalam pengaturan. Dibandingkan dengan waterfall, tahapan-tahapan pada spiral tidak jelas dimana mulai dan dimana akhir. Pada prakteknya spiral berguna selama perencanaan karena mengurangi resiko dan mendorong tim developer untuk memikirkan apa yang paling penting.

Formulasi dan Analisis sistem berbasis web

Formulasi dan analisis sistem dan aplikasi berbasis web adalah serangkaian aktifitas rekayasa web yang dimulai dengan identifikasi tujuan dan diakhiri dengan pembangunan analisis model atau spesifikasi requirement sistem.

Formulasi

Formulasi memungkinkan klien dan pembangun untuk menetapkan tujuan-tujuan pembangunan web. Beberapa pertanyaan berikut dapat membantu menentukan tujuan :
  • Apa motivasi utama pembangunan WebApp?
  • Mengapa WebApp diperlukan?
  • Siapa yang akan menggunakan WebApp?
Ada dua macam tujuan:
  • Informational goals—tujuan dari penyajian isi atau informasi kepada end
  • Applicative goals—berkaitan dengan kemampuan yang dimiliki WebApp

Analisis rekayasa web

Ada 4 tipe analisis dalam rekayasa web:
  1. Content Analysis. Isi yang akan disajikan oleh WebApp dalam ditentukan formatnya baik itu berupa text, grafik dan image, video, dan audio.
  2. Interaction Analysis. Cara interaksi antara user dan WebApp dijelaskan.
  3. Functional Analysis. Menentukan operasi yang akan diaplikasikan pada WebApp dan termasuk di dalamnya fungsi-fungsi yang melakukan proses. Semua operasi dan fungsi dideskripsikan secara detil.
  4. Configuration Analysis. Lingkungan dan infrastruktur dimana WebApp akan diberada digambarkan secara detil.

Desain Web

1. Architectural design: Menggambarkan struktur WebApp

a. Struktur linier
  • Urutan interaksi sudah bisa dipastikan.
  • Misal untuk presentasi tutorial, pemesana produk yang harus mengikuti urutan tertentu.

b. Struktur Grid

  • Isi dapat dikatagorikan dalam 2 atau lebih dimensi
  • Mmisal: e-commerce menjual handphone. Horizontal adalah katagori berdasarkan feature hp, sedang vertikal adalah merek HP

c. Struktur jaringan / Pure Web

  • Komponen pada struktur ini terhubung satu sama lain
  • Sekalipun bersifat fleksibel, struktur ini membingungkan user

d. Struktur Hirarki

  • Struktur paling umum digunakan.
  • Memungkinkan aliran secara horizontal selain jalur vertikal yang umum.
  • Aliran secara horizontal juga bisa mengakibatkan kebingungan user.

2. Navigation design: menentukan navigasi halaman-halaman web.

Setelah arsitektur WebApp sudah terbentuk dan komponen-komponen seperti halaman, scripts, applet dan fungsi lain sudah ada, developer menentukan navigasi yang memungkinkan user mengakses isi WebApp dan layananlayanannya. Jika user tidak bisa berpindah ke halaman lain dalam web dengan mudah dan cepat maka mungkin karena grafik, dan isi tidak relevant, ini masalah navigasi. Dalam desain navigasi beberapa hal perlu dilakukan :
  • Menentukan semantik (arti ) dari navigasi untuk user yang berbeda.
  • Menentukan cara yang tepat: pilihannya adalah text-based links, icons, buttons and switches, and graphical metaphors

3. Interface design: membangun interaksi dengan user yang konsisten dan efektif.

User interface pada WebApp adalah kesan pertama. Sekalipun nilai isinya baik, kemampuan prosesnya canggih, layanannya lengkap namun jika user interfacenya buruk maka hal lain tidak berguna, karena akan membuat user berpindah ke web lain.

Beberapa petunjuk dalam merancang interface design :

  • Server errors, menyebabkan user pindah ke website.
  • Membaca di layar monitor lebih lambat 25% dari pada di kertas, karena itu teks jangan terlalu banyak.
  • Hindari tanda “under construction”.
  • User tidak suka scroll. Pastikan informasi cukup dalam satu layar.
  • Navigasi menu dan headbar harus konsisten.
  • Keindahan tidak seharusnya lebih penting dari pada fungsinya
  • Opsi navigasi harus jelas sehingga tahu bagaimana berpindah atau mencari hal lain pada halaman aktif.

Pengujian pada Rekayasa web

  1. Check isi/informasi untuk kesalahan yang mungkin terjadi, misalnya salah ketik.
  2. Design model WebApp di- review untuk menemukan navigation errors.
  3. Processing components an Web pages diuji.
  4. Integration test untuk arsitektur web :
    • Struktur linier, grid, atau hirarki sederhana—seperti pada software dengan pemrograman terstruktur (modular).
    • Struktur hirarki campuran atau network (Web) — seperti pada Object oriented software.
  5. Uji WebApp secara keseluruhan setelah disatukan semua komponennya secara lengkap.
  6. WebApp yang diimplementasikan pada konfigurasi yang berbeda diuji kompatibilitasnya.Misalnya jika membuat di IE, coba di Netscape, dan Firefox
  7. WebApp diuji oleh sekelompok pengguna dengan kemampuan yang berbeda.Bagian yang diuji adalah isi, navigation, kemudahan penggunaan, kehandalan dan unjuk kerja.

Jumat, 27 Juli 2012

Perancangan Antarmuka Pengguna


Tujuan dari Perancangan Antarmuka Pengguna adalah merancang interface yang efektif untuk sistem perangkat lunak. Efektif artinya siap digunakan, dan hasilnya sesuai dg kebutuhan. Kebutuhan disini adalah kebutuhan penggunanya. Pengguna sering menilai sistem dari interface, bukan dari fungsinya melainkan dari user interfacenya. Jika desain user interfacenya yang buruk, maka itu sering jadi alasan untuk tidak menggunakan software. Selain itu interface yang buruk sebabkan pengguna membuat kesalahan fatal. Saat ini interface yang banyak digunakan dalam software adalah GUI (Graphical User Interface). GUI memberikan keuntungan seperti:


  1. Gampang dipelajari oleh pengguna yang pengalaman dalam menggunakan komputer cukup minim.
  2. Berpindah dari satu layar ke layar yang lain tanpa kehilangan informasi dimungkinkan.
  3. Akses penuh pada layar dengan segera untuk beberapa macam tugas/keperluan.

Beberapa karakteristik dari GUI dan penjelasannya dapat dilihat pada Tabel dibawah.

Gambar dibawah menggambarkan proses yang dilakukan dalam melakukan desain user interface. Prosse perulangan yang terjadi menjelaskan bahwa proses-proses tersebut dilakukan hingga menghasilkan desain yang diinginkan oleh pengguna. Desain harus bersifat user-centered, artinya pengguna sangat terlibat dalam
proses desain. Karena itu ada proses evaluasi yang dilakukan oleh pengguna terhadap hasil desain.

Prinsip –prinsip dalam merancang user interface

Berikut ini prinsip-prinsip UID:
  1. User familiarity / Mudah dikenali : gunakan istilah, konsep dan kebiasaan user bukan computer (misal: sistem perkantoran gunakan istilah letters, documents, folders bukan directories, file, identifiers. -- jenis document open office.
  2. Consistency / “selalu begitu” : Konsisten dalam operasi dan istilah di seluruh sistem sehingga tidak membingungkan. -- layout menu di open office mirip dgn layout menu di MS office.
  3. Minimal surprise / Tidak buat kaget user : Operasi bisa diduga prosesnya berdasarkan perintah yang disediakan.
  4. Recoverability/pemulihan : Recoverability ada dua macam: Confirmation of destructive action (konfirmasi terhadap aksi yang merusak) dan ketersediaan fasilitas pembatalan (undo).
  5. User guidance / bantuan : Sistem manual online, menu help, caption pada icon khusus tersedia.
  6. User diversity /keberagaman : Fasilitas interaksi untuk tipe user yang berbeda disediakan. Misalnya ukuran huruf bisa diperbesar.



User Interaction (Interaksi pengguna)

Perancang sistem menghadapi dua masalah penting yaitu bagaimana informasi dari user bisa disediakan untuk sistem komputer – misalnya pada saat input data dan bagaimana informasi dari sistem komputer ditampilkan untuk user – hasil dari pemrosesan data. User interface yang baik harus menyatukan interaksi pengguna (user interaction) dan penyajian informasi (information presentation).

Ada 5 tipe utama interaksi untuk user interaction:

1. Direct manipulation

Pengoperasian secara langsung: interaksi langsung dengan objek pada layar. Misalnya delete file dengan memasukkannya ke trash. Contoh: Video games.

  • Kelebihan: Waktu pembelajaran user sangat singkat, feedback langsung diberikan pada tiap aksi sehingga kesalahan terdeteksi dan diperbaiki dengan cepat.
  • Kekurangan : Interface tipe ini rumit dan memerlukan banyak fasilitas pada sistem komputer, cocok untuk penggambaran secara visual untuk satu operasi atau objek

2. Menu selection 

Pilihan berbentuk menu: Memilih perintah dari daftar yang disediakan. Misalnyasaat click kanan dan memilih aksi yang dikehendaki.

  • Kelebihan : User tidak perlu ingat nama perintah. Pengetikan minimal. Kesalahan rendah.
  • Kekurangan :Tidak ada logika AND atau OR. Perlu ada struktur menu jika banyak pilihan. Menu dianggap lambat oleh expert user dibanding command language.

3. Form fill-in 

Pengisian form : Mengisi area-area pada form. Contoh: Stock control.

  • Kelebihan : Masukan data yang sederhana. Mudah dipelajari
  • Kekurangan : Memerlukan banyak tempat di layar. Harus menyesuaikan dengan form manual dan kebiasaan user.

4. Command language

Perintah tertulis: Menuliskan perintah yang sudah ditentukan pada program. Contoh: operating system.

  • Kelebihan : Perintah diketikan langsung pada system. Misal UNIX, DOS command. Bisa diterapkan pada terminal yang murah.Kombinasi perintah bisa dilakukan. Misal copy file dan rename nama file.
  • Kekurangan : Perintah harus dipelajari dan diingat cara penggunaannya – tidak cocok untuk user biasa.Kesalahan pakai perintah sering terjadi. Perlu ada sistem pemulihan kesalahan.Kemampuan mengetik perlu.

5. Natural language 

Perintah dengan bahasa alami: Gunakan bahasa alami untuk mendapatkan hasil. Contoh: search engine di Internet.

  • Kelebihan: Perintah dalam bentuk bahasa alami, dengan kosa kata yang terbatas (singkat) – misalnya kata kunci yang kita tentukan untuk dicari oleh search engine. Ada kebebasan menggunakan kata-kata.
  • Kekurangan: Tidak semua sistem cocok gunakan ini. Jika digunakan maka akan memerlukan banyak pengetikan.




Penyajian Informasi (Information Presentation)

Sistem yang interaktif pasti menyediakan cara untuk menyajikan informasi untuk pengguna. Penyajian informasi bisa berupa penyajian langsung dari input yang diberikan (seperti teks pada word processing) atau disajikan dengan grafik. Beberapa faktor berikut adalah hal yang perlu diperhatikan sebelum menentukan
bentuk penyajian informasi:


  • Apakah pengguna perlu informasi dengan ketepatan tinggi atau data yang saling berhubungan?
  • Seberapa cepat nilai informasi berubah? Harus ada indikasi perubahan seketika?
  • Apakah pengguna harus memberi respon pada perubahan?
  • Apakah pengguna perlu melakukan perubahan pada informasi yang disajikan?
  • Apakah informasi berupa teks atau numerik? Nilai relatif perlu atau tidak?

Informasi bisa bersifat statis atau dinamis ketika disajikan, masing-masing baik dengan karakteristik yang berbeda dan kebutuhan yang berbeda pula:



1. Static information:


  •  Ditentukan saat awal sesi. Tidak berubah selama sesi berjalan.
  • Bisa berupa informasi numeris atau teks Chart di MS-Excel
  • Disajikan dengan jenis huruf khusus yang mudah dibaca atau diberi highlight dengan warna tertentu seperti pada Gambar 4 atau menggunakan icon yang mewakili

2. Dynamic information:


  • Perubahan terjadi selama sesi berlangsung dan perubahan harus dikomunikasikan/ditunjukkan ke user
  • Bisa berupa informasi numeris atau teks. Contoh : Defragmentation, scanning virus, download



Informasi dalam bentuk teks bersifat tepat dan berubah secara lambat sedangkan informasi dengan gambar/grafik mampu menjelaskan hubungan antar gambar, data bisa berubah dengan cepat. Seperti pada Gambar dibawah, informasi yang sama disajikan dengan dua cara yang berbeda. Jika yang dibutuhkan adalah hubungan antar data pada bulan-bulan tersebut, maka informasi dengan grafik memberikan informasi tentang hubungan tersebut lebih cepat dari pada informasi yang disajikan dengan teks dan numerik. Informasi dengan numerik dapat juga disajikan dengan cara digital atau analog dengan karakteristik sebagai berikut:


1. Digital presentation


  • Singkat – hanya perlu sedikit tempat pada layar
  • Ketepatan nilai ditunjukkan

2. Analogue presentation


  • Nilai terlihat sambil lalu
  • Untuk menunjukkan nilai relatif
  • Mudah melihat data nilai yang berbeda
Nilai-nilai relatif misalnya seperti pada Gambar berikutnya. Selain nilai yang disajikan relatif, informasinya bersifat dinamis, karena berubah saat sesi berjalan. Untuk nilai digital kita biasanya gunakan untuk menunjukkan jam pada jam sistem di komputer. Selain ketepatan diperlukan, perubahannya tidak terjadi secara cepat.

Penggunaan Warna pada desain Interface

  • Warna menambah dimensi ekstra pada suatu interface dan membantu user memahami struktur yang kompleks.
  • Bisa dipakai untuk mewarnai-terang (higlight) hal-hal khusus.
  • Kesalahan umum dalam penggunaan warna pada desain UI:
    • Menggunakan warna untuk mengkomunikasikan arti-- merah bisa jadi peringatan atau ada kesalahan.
    • Terlalu banyak gunakan macam warna.
Dalam menggunakan warna pada desain interface ada beberapa petunjuk yang dapat diikuti seperti berikut ini:
  1. Hindari penggunaan terlalu banyak warna.
  2. Gunakan kode warna untuk mendukung operasi.
  3.  Pengguna bisa kendalikan warna untuk kode.
  4. Desain monochrome kemudian tambahkan warna.
  5. Gunakan warna kode secara konsisten.
  6. Hindari pasangan warna yang tidak cocok/norak.
  7. Gunakan warna untuk menunjukkan perubahan status.

User Support

User guidance meliputi semua fasilitas sistem untuk mendukung user termasuk on-line help, error messages, user manual. User guidance perlu disatukan dengan UI untuk bantu user saat membutuhkan informasi tentang sistem atau saat ada kesalahan. Help System dan sistem message (pesan kesalahan) adalah bentuk dari user guidance. Error Messages sangat penting, karena error message yang buruk cenderung ditolak oleh user dan error message sebaiknya berpedoman pada faktor-faktor pada Tabel dibawah.


Pesan kesalahan pada Gambardibawah, ada dua macam: berorientasi pada sistem dan berorientasi pada pengguna. Pada pesan yang berorientasi pada sistem, pesan membuat pengguna merasa tidak berdaya karena tidak ada jalan keluar yang jelas, bahasa yang digunakan adalah bahasa teknis yang tidak berarti apa-apa. Pada pesan yang berorientasi pada pengguna, pesan lebih jelas dan memberikan alternatif jalan keluar. Sekalipun informasi yang diberikan lebih banyak dan terkesan penuh, tapi pengguna merasa tertolong.












Rabu, 25 Juli 2012

Desain Perangkat Lunak


Setelah kebutuhan dikumpulkan, analisis terhadap kebutuhan dilakukan dengan menggunakan beberapa alat (tools) seperti DFD (Data Flow Diagram), ERD (Entity Relationship Diagram) dan STD (State Transition Diagram). Data Dictionary menjadi bekal dasar untuk menganalisis kebutuhan. Data Dictionary berisi gambaran dari semua objek data yang diperlukan dan dihasilkan oleh software nantinya. Diagram-diagram tadi mempunyai karakteristik masing-masing. DFD memberi gambaran bagaimana data berubah sejalan dengan alirannya dalam sistem dan menggambarkan fungsi-fungsi yang mengubah data-data tadi. ERD menggambarkan relasi antara objek data. STD menggambarkan bagaimana kerja sistem melalui kondisi (state) dan kejadian yang menyebabkan kondisi berubah. STD juga menggambarkan aksi yang dilakukan karena kejadian tertentu.


Hasil yang diperoleh dari analisis kebutuhan adalah model analisis yang kemudian menjadi bekal untuk melakukan desain. Setiap bagian dari analisis model pada gambar dibawah sebelah kanan menjadi bekal pada proses desain pada piramida model desain pada sebelah kiri gambar dibawah.

Model Desain

Data design mengubah informasi menjadi struktur data untuk mengimplementasikan software. Data design dibuat berdasarkan data dictionary dan ERD. Architectural design mendefinisikan relasi antara elemen-elemen struktural utama, pola desain yang digunakan untuk mencapai kebutuhan yang ditentukan untuk sistem dan batasan-batasan yang mempengaruhi bagaimana desain arsitektural ini diterapkan. Desain ini berdasarkan spesifikasi sistem, model analisis (bagian DFD) dan interaksi antara subsistem. Interface design menjelaskan bagaimana software berkomunikasi dalam dirinya, dengan sistem yang bertukar informasi dengannya, dan dengan manusia yang menggunakannya. DFD diperlukan untuk desain ini. Component-level design menghasilkan deskripsi prosedur software.

Konsep desain

1. Abstraction

Abstraction adalah gambaran dari fungsi suatu program. Gambaran ini bisa bertingkat-tingkat. Tingkat yang paling atas adalah gambaran suatu fungsi program dengan menggunakan bahasa alami. Pada tingkat terendah, menghasilkan abstraksi yang bersifat prosedural/ langkah perlangkah dengan menggunakan istilah yang teknis dan bisa diimplementasikan menjadi fungsi program.

Pada saat beralih dari tingkat ke tingkat, kita menggunakan procedural dan data abstraction. Procedural abstraction adalah urutan instrasi yang mempunyai tujuan khusus,dan data abstraction adalah koleksi data yang digunakan pada fungsi tersebut.

Contoh:
Program : Iklan Part-time Job
Fungsi: Pendaftaran calon part-timer
Abstraction 1 (highest level):
Calon part-timer dalam melakukan upload syarat-syarat yang diperlukan untuk melamar: surat lamaran, CV, foto, transkrip, data diri.
Abstraction 2 (lower level):
Procedural abstraction : 
  • tampilkan pilihan part-time job   
  • input data   
  • verifikasi format 
  • kirim data
Data abstraction 
  • nama is STRING 
  • nim is STRING 
  • foto is IMAGE FILE 
  • surat_lamaran is PDF FILE

2. Refinement — Penjelasan detil dari abstraction

Refinement membantu designer untuk memperlihatkan detil dari lowest level dari abstraction. Abstraction dan refinement merupakan konsep yang saling melengkapi. Contoh dari refinement tentang fungsi sebuah pintu ada pada gambar dibawah.

3. modularity — Membagi software menjadi modul

Software dibagi-bagi menjadi beberapa component yang disebut modul-modul. Modul-modul ini nantinya disatukan/diintegrasikan untuk memenuhi kebutuhan sistem. Dalam pembentukan modul-modul berlaku pernyataan-pernyataan berikut:
Jika C(p1) > C(p2) dimana C adalah complexity dari suatu modul, maka E(p1) > E(p2) dimana E adalah waktu yang diperlukan. Artinya semakin rumit sebuah modul, maka waktu yang digunakan untuk menyelesaikan modul tersebut makin banyak.
C(p1+p2) > C(p1) + C(p2)
Dan
E(p1+p2) > E (p1) + E(p2)

Untuk itu, modul yang rumit dipecah lagi menjadi beberapa modul untuk memudahkan penyelesaian masalah. Namun semakin banyak modul, maka waktu/biaya untuk integrasikan modul-modul tersebut juga makin tinggi. Seperti pada grafik pada gambar dibawah.

4. Software Architecture — Struktur software secara keseluruhan

Struktur hirarki/berjenjang dari modul-modul program. Untuk menggambarkan struktur modul-modul tersebut beberapa model yang ada adalah :

  • Framework model : identifikasi pola yang berulang-ulang.
  • Dynamic model : identifikasi bagaimana konfigurasi sistem berubah karena kejadian-kejadian tertentu.
  • Process model: fokus pada proses teknis yang harus dikerjakan sistem.
  • Functional model : menggambarkan hirarki sistem berdasarkan fungsinya.

5. Software Procedure

Fokus pada detil proses pada tiap modul. Prosedur menjelaskan proses, urutan kejadian, proses perulangan, penentuan keputusan/arah. Ini bisa digambarkan dengan menggunakan Flow Chart yang bertingkat.

6. Information Hiding

Ide dari information hiding (menyembunyikan informasi) adalah modul dirancang sedemikian rupa sehinga inforamsi (prosedur dan data) yang di dalamnya tidak dapat di akses oleh modul lain yang tidak memerlukannya. Modul yang efektif adalah modul yang berdiri sendiri dan berkomunikasi dengan modul lain yang memang diperlukan.


Desain Arsitektur Software

Suatu sistem, entah itu besar atau tidak, dibangun dari sub-sub sistem yang lebih kecil. Sub-sub sistem ini memiliki fungsi sendiri-sendiri. Proses merancang untuk menentukan sub-sub sistem dan membangun kerangka kerja untuk kendali dan komunikasi antar sub sistem disebut design arsitektural. Proses merancang ini menghasilkan arsitektur software atau arsitektur sistem. Desain arsitektur adalah aktifitas desain yang pertama dalam pembangunan software seperti yang digambarkan pada gambar dibawah.

Desain arsitektur memberikan 3 keuntungan yaitu:
  1. Arsitektur software menjadi media komunikasi dan diskusi karena mudah dipahami.
  2. Memberi kemudahan dalam melakukan analisis terhadap software yang akan dibangun.
  3. Arsitektur-nya bisa digunakan lagi untuk sistem selanjutnya (reusable).
Tiap perancang sistem memiliki kemampuan dan pengetahuan yang berbeda dalam merancang arsitektural. Aktifitas-aktifitas berikut adalah aktifitas dalam merancang dan aktifitas ini tidak dikerjakan satu persatu berurutan, tapi bisa dilakukan bersamaan.

  1. Menyusun sistem (system structuring) : sistem disusun menjadi beberapa subsistem utama, dimana subsistem adalah unit bagian software yang berdiri sendiri.
  2. Membuat model kendali (Control modelling) : berkaitan dengan hubungan antara bagian dalam sistem.
  3. Membuat pembagian sistem menjadi modul-modul (modular decomposition) : membagi sub-sub sistem menjadi modul-modul.
Untuk menghindari kesalahan dalam pemahaman terhadap istilah modul dan sub sistem, perlu diketahui bahwa sub sistem adalah bagian dari sistem yang bisa berdiri sendiri dan tidak bergantung pada layanan sub sistem lain. Sub sistem terdiri dari beberapa modul dan dilengkapi interface untuk berkomunikasi / bertukar data dengan sub sistem lain.

System Structuring (struktur sistem)

Struktur sistem menggambarkan sub-sub sistem dan interaksi antara sub-sub sistem. Desain dengan menggunakan diagram-diagram untuk menggambarkan sub sistem dan interaksinya agar mudah dipahami.
Beberapa model dari struktur sistem yang menjelaskan bagaimana sub sistem berbagi data, bagaimana sub sistem terdistribusi dan bagaimana sub-sub sistem saling berinteraksi adalah:

1.Repository Model

Pada model ini data disimpan secara terpusat. Ada dua cara terpusat pada model ini:
  1. Database terpusat dan dapat diakses oleh semua sub sistem dalam sistem tersebut. Contoh : sistem informasi perpustakaan UGM.
  2. setiap sub sistem menyimpan database sendiri dan bisa bertukar data dengan sub sistem lain melalui pengiriman pesan (message).
Diagram menggambarkan model ini seperti pada Gambar 2. Sub-sub sistem pada Gambar dibawah mendapatkan data dari repository (kumpulan data). Data tersimpan secara terpusat pada satu tempat.

Keuntungan
  • Efisien untuk share jumlah data yang besar. Tidak perlu kirim data secara langsung dari satu sub sistem ke sub sistem yang lain.
  • Sub-sistem tidak perlu memikirkan bagaimana data digunakan oleh sub sistem lain.
  • Manajeman data seperti backup, keamanan, re-index, dan kontrol akses dilakukan secara terpusat. Itu merupakan tanggung jawab manager repository
Kerugian
  • Sub-system harus mengikuti model yang sudah ditetapkan.Jadi jika ada sub sistem baru, maka yang baru harus menyesuaikan dengan model yang ada.
  • Evolusi data sulit dan mahal karena volume informasi yang besar dihasilkan dengan model tertentu. Mengubahnya ke model yang lain pun tidak mudah
  • Sulit untuk distribusi layanan secara efisien, karena yang melayani hanya satu.
Contoh untuk model repository dengan database terpusat adalah : sistem informasi perpustakaan UGM, sistem registrasi akademik UGM.

2. Client-Server Model

Model ini terdiri dari server yang berdiri sendiri dan menyediakan layanan untuk client-client. Ada client-client (sub-sistem) yang menggunakan layanan server dan tersedia network yang mengijinkan client untuk akses layanan dari server. Komponen utama pada model ini :
  1. Ada stand-alone server yang menyediakan layanan ke sub-sub sistem.
  2. Ada sub sistem yang disebut juga client yang memanggil/mengakses layanan di server-server.
  3. Ada jaringan memungkinkan sub-sub sistem mengakses layanan-layanan pada server.
Untuk mengakses suatu server maka sub sistem atau client harus mengetahui alamat atau nama server yang diakses dan juga layanan yang diberikan. Sebaliknya, server tidak perlu tahu berapa client/sub sistem yang mengaksesnya dan sub sistem mana yang menggunakan layanannya. Arsitektur client server memiliki struktur yang terdiri dari 3 lapisan yang harus ada yaitu:
  1. Business logic/ application.
  2. Data management.
  3. Presentation layer.
Gambar dibawah adalah contoh-contoh dari model client-server, dimana ada beberapa server dan client. Masing-masing server menyimpan datanya sendiri dan setiap client bisa mengakses/menggunakan layanan pada tiap server.

Keuntungan
  • Distribusi data secara langsung melalui jaringan
  • Penggunaan sistem jaringan secara efektif –hardware jadi murah
  • Mudah untuk tambahkan server baru atau up-grade server yang sudah ada
Kekurangan
  • Tidak ada data model, jadi organisasi data macam-macam, sehingga integrasi data sulit
  • Redundant management
  • Tidak ada pusat register nama dan service, sehingga kalau tidak tahu nama server dan service-nya sulit ditemukan
  • Manajemen data dilakukan pada tiap server, tidak terpusat karena masing-masing server memiliki karakteristiknya sendiri.
Client server merupakan arsitektur terdistribusi. Bisa digunakan secara efektif pada jaringan dengan prosesor yang terdistribusi.

Tiga lapisan pada client-server arsitektur menentukan model dari client-server. Perbedaan model-model tersebut adalah pada distribusi 3 lapisan tersebut. Model distribusi 3 lapisan client-server adalah : two-tier, three-tier dan n-tier (multitier).

2.1 Two-tier architecture:

Thin-Client model
Menempatkan business logic/application process dan data management pada server dan presentation pada client. Server mengerjakan pekerjaan berat yaitu menjalankan application process dan data management Contoh : website.


Fat Client model
Menempatkan business logic/application process dan presentation pada client dan server hanya mengurusi data management. Contoh : suatu aplikasi dibangun dengan VFP dan mengakses database Oracle. Semua application process dan presentation di client yang menggunakan VFP.

2.2 Three-tier

Memisahkan secara logic, presentation yang ada di client dengan application process yang berada terpisah secara logic dengan data management. Contoh: Internet Banking system.

2.3 Distributed object arsitektur

Pada model ini komponen yang terpenting adalah objek yang menyediakan antarmuka untuk layanan-layanannya guna dipanggil oleh objek lain. Masing-masing objek dapat dipanggil oleh objek lain dalam sistem tersebut. Tidak ada lagi pembagian client-server, karena tiap objek dapat berperan menjadi client dan server bergantung pada operasi yang dilakukan. Jika objek tersebut memberikan layanan pada objek lain, berarti objek yang memberi layanan berperan sebagai server, dan objek yang menggunakan layanan berperan sebagai client.

3. Abstract Machine Model

Model ini juga disebut dengan layered model. Pada model ini sistem terdiri dari serangkaian lapisan (layer) yang masing-masing menyediakan layanan-layanan khusus. Setiap lapisan (layer) merupakan satu abstract machine yang layanannya digunakan pada abstract machine pada tingkat berikutnya.


Keuntungan
  • Mudah diubah
  • Perubahan yang terjadi pada satu lapisan hanya berpengaruh pada lapisan yang terdekat
Kerugian
  • Akses terhadap satu layanan pada lapisan yang dalam tidak bisa langsung karena harus melewati lapisan-lapisan sebelumnya
  • Kinerja sistem bisa jadi lambat karena harus melwati lapisan-lapisan sebelumnya

Control Models (Model kendali)

Sub-sub sistem perlu kendali agar bisa bekerja sebagai suatu sistem. Model struktur di atas tidak menggambarkan kendali, tapi model kendali yang menjelaskan aliran kendali antar sub-sub sistem.
Dua pendekatan model kendali dan variannya yang umum adalah :

1. Centralised control

Satu sub-system bertanggung jawab untuk mengatur eksekusi sub-system lain
  • The call-return model : Top-down subroutine model.Control mulai dari paling atas dari hirarki subroutine dan mengalir ke bawah.


  • The manager model : Satu komponen sistem jadi manager dan mengendalikan start-stop dan koordinasi proses sistem. Satu proses adalah satu sub-sistem yang bisa dieksekusi secara paralel dengan sub-sistem lain.

2. Event-based control

3.2.1 broadcast model :
  • Event di broadcast ke semua sub-system.
  • Sub-system register ke specific event, saat ini terjadi control ditransfer ke sub-system yang handle event tersebut.
  • Sub-system tentukan event yang dibutuhkan.
3.2.2. interrupt-driven models
  • Digunakan secara khusus pada real-time system yang mendeteksi interupsi luar.
  • Memberikan respon yang cepat pada suatu kejadian.
  • Membutuhkan pemrograman yang rumit dan testing yang sulit.
  • Contoh: Real-time system pada air safety bag di mobil

Modular Decomposition

Membagi sub-sistem menjadi beberapa modul. Ada 2 model dalam desain arsitektur jenis ini:

1. Object-oriented Models

  • Sistem dibagi-bagi menjadi objek-objek yang saling berkomunikasi.
  • Berkaitan dengan class yang terdiri dari atribut-atribut dan operasioperasinya.
  • Perubahan pada object tidak mempengaruhi object lain.
  • Cenderung mudah dipahami karena mewakili keadaan objek yang sebenarnya di dunia nyata.
  • Penggunaan layanan/service objek lain harus mengacu pada nama atau antarmuka dari objek tersebut.

2. Data Flow models

  • Sistem dibagi-bagi menjadi fungsi-fungsi yang menerima input dan mengubahnya menjadi output. Model ini juga disebut pendekatan pipeline.
  • Aliran data mengalir dari satu proses ke proses lain secara sekuensial dan setiap proses merupakan transformasi data.
  • Proses ada yang dilakukan secara sekuensial, tadi ada juga yang paralel.








Senin, 23 Juli 2012

Requirement Engineering


Requirement tidak hanya ditulis oleh pembangun, tapi sebelumnya justru ditulis oleh klien yang memesan software. Klien menuliskan requirement dalam bentuk yang masih abstrak tentang kebutuhannya. Kemudian requirement tersebut diserahkan kepada tim pembangun. Saat sudah ada persetujuan pembangun pun kemudian menuliskan kemampuan sistem yang bisa dipahami oleh klien, inipun disebut requirement.

Definisi

Requirement adalah gambaran dari layanan (services) dan batasan bagi sistem yang akan dibangun. Atau requirement adalah pernyataan/gambaran pelayanan yang disediakan oleh sistem, batasan-batasan dari sistem dan bisa juga berupa definisi matematis fungsi-fungsi sistem. Requirement berfungsi ganda yaitu:
  • Menjadi dasar penawaran suatu kontrak --> harus terbuka untuk masukan
  • Menjadi dasar kontrak --> harus didefinisikan secara detil

Proses menemukan, menganalisis, mendokumentasikan dan pengujian layananlayanan dan batasan tersebut disebut Requirement Engineering.

Pengumpulan requirement

  1. Interviews : Memberi informasi yang terbaik,mahal
  2. Questionnaires: Bagus jika banyak orang terlibat dan tersebar, respon cenderung kurang baik
  3. Observation: Akurat jika dilakukan dengan baik, mahal
  4.  Searching :Informasi terbatas, cenderung tidak menampilkan hal-hal yang mungkin jadi masalah

Beberapa Macam Requirement

  1. User requirement (kebutuhan pengguna)
    • Pernyataan tentang layanan yang disediakan sistem dan tentang batasan-batasan operasionalnya. Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah
  2. System requirement (kebutuhan sistem)
    • Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. System requirement document sering disebut functional specification (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun
  3. A software design specification (spesifikasi rancangan PL)
    • Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil.
Ketiga jenis requirement tersebut diperlukan dalam pembangunan software karena masing-masing memberi pengertian ke pihak yang berbeda kepentingan. Pembaca dari ketiga requirement tersebut bisa dijelaskan dengan gambar dibawah.
Masalah yang mungkin terjadi dalam pendefinisian requirement adalah:
  • Sulit mengantisipasi efek dari sistem baru terhadap organisasi.
  • Beda user, beda pula requirement dan prioritasnya – terpengaruh cara atau gaya kerja
  • End-user sistem, dan organisasi yang membiayai sistem berbeda requirement.
  • Prototype sering dibutuhkan untuk menjelaskan requirement.
  • Masalah perbedaan bahasa alami.
Software system requirement sering dibedakan dalam 2 katagori yaitu Functional requirement, Non Functional requirement dan domain requirement dengan masing-masing penjelasannya sebagai berikut:

1. Functional Requirement :


Merupakan penjelasan tentang layanan yang perlu disediakan oleh sistem, bagaimana sistem menerima dan mengolah masukan, dan bagaimana sistem mengatasi situasi-situasi tertentu. Selain itu kadang-kadang juga secara jelas menentukan apa yang tidak dikerjakan oleh sistem. Functional requirement menggambarkan system requirement secara detil seperti input, output dan pengecualian yang berlaku. Contoh dalam kasus peminjaman buku di perpustakaan:

  1. Pengguna bisa mencari semua informasi tentang buku atau bisa memilih salah satu dari informasi tentang buku.
  2. Semua peminjam memiliki pengenal yang unik.
  3. Sistem mampu catat transaksi peminjaman, pengembalian dan denda secara lengkap.
  4. Hari libur bisa di-set sejak awal, dan bisa menerima perubahan dengan otoritas khusus.
  5. Harus komplit ( kebutuhan layanan jelas dan lengkap) dan konsisten (tidak kontradiksi dengan yang didefinisikan).
Masalah yang mungkin terjadi dalam menyusun functional requirement adalah:
  1. Diintepretasikan/diartikan berbeda oleh user atau developer.
  2. Hasil intepretasi sering tidak menjawab kebutuhan klien.
  3. Untuk sistem yang besar, kelengkapan kebutuhan dan konsisten sulit dicapai karena kerumitan sistem.
  4. Perlu analisis yang dalam dan menyeluruh untuk mengurangi kesalahan.

2. Non-functional Requirement:


Secara umum berisi batasan-batasan pada pelayanan atau fungsi yang disediakan oleh sistem. Termasuk di dalamnya adalah batasan waktu, batasan proses pembangunan, standar-standar tertentu.


Karena berkaitan dengan kebutuhan sistem secara keseluruhan,maka kegagalan memenuhi kebutuhan jenis ini berakibat pada sistem secara keseluruhan. Contoh kebutuhan jenis ini adalah kecepatan akses, keamanan data, besarnya kapasitas penyimpanan yang diperlukan, privasi masing-masing profil /account, bahasa pemrograman yang digunakan, sistem operasi yang digunakan. Sesuai dengan gambar di atas, non functional requirement dibagi menjadi 3 tipe
yaitu:
  1. Product req. berkaitan dengan kehandalan, kecepatan, kemudahan digunakan, kapasitas memori yang dibutuhkan dan efisiensi sistem.
  2. Organisational req. berkaitan dengan standar, bahasa pemrograman dan metode rancangan yang digunakan.
  3. External req. berkaitan dengan masalah etika penggunaan, interoperabilitas dengan sistem lain, legalitas, dan privasi.

3. Domain requirement:

Berasal dari domain aplikasi sistem. Misalnya karena masalah hak cipta maka beberapa dokumen dalam perpustakaan tidak boleh diakses oleh orang lain yang tidak berhak.

User Requirement


Menggambarkan functional dan non-functional req yang dapat dipahami oleh pengguna (user) yang tidak memiliki latar belakang teknis yang cukup. User requirement menjelaskan perilaku luar dari sistem, tidak secara teknis, karena itu perlu menggunakan bahasa alami, atau bahasa yang sederhana.

Masalah dalam menyiapkan user requirement adalah:

  1. Bahasa alami kadang tidak cukup untuk menjelaskan, atau membuat dokumen jadi sulit dibaca.
  2. Jenis-jenis req, kadang jadi sulit dibedakan.
  3. Sering digabungkan menjadi satu kumpulan requirement saja.
Contoh penggunaan bahasa alami: pengguna perpustakaan dapat mencari informasi tentang pustaka melalui form pencarian dengan mengetikkan kata kunci yang merupakan kata kunci dari judul buku, nama pengarang atau nama penerbit. Untuk mengurangi kesalahpahaman ketika menulis user req. berikut ini beberapa petunjuk yang bisa diikuti:
  1. Buatlah format yang standar untuk penulisan. Format ini untuk mengurangi hal-hal yang tidak perlu dan mudah untuk diperiksa kembali.
  2. Menggunakan bahasa yang konsisten, istilah-istilah yang konsisten sehinga mudah dikuti.
  3. Gunakan style seperti cetak miring, cetak tebal untuk memberi kesan penting untuk beberapa istilah atau penjelasan.
  4. Hindari istilah-istilah teknis komputer yang tidak dimengerti oleh user. Jika terpaksa menggunakan, buatlah daftar istilah dan artinya sehingga mudah diikuti oleh user.

System Requirement

Merupakan deskripsi sistem yang lebih detil dari user requirement (jadi masih berisi functional dan non functional requirement). Requirement ini bisa berlaku sebagai kontrak pembangunan sistem dan isa terdiri dari macam model sistem seperti model object atau model data-flow. Sistem requirement menyatakan apa yang harus dikerjakan sistem, dan bukan bagaimana sistem diimplementasikan. Untuk itu bahasa yang lebih spesifik dan bersifat teknis dapat digunakan, seperti misalnya PDL (Program Description Language) seperti
contoh pada gambar diatas. PDL digunakan untuk menggambarkan kebutuhan secara operasional dan sifatnya sangat dekat dengan implementasi program. Gambar dibawah adalah contoh PDL menjelaskan salah satu fungsi ATM:


Dokumen kebutuhan (requirement document)


Dokumen kebutuhan merupakan pernyataan resmi dari apa yang dibutuhkan dari pembangun sistem, berisi definisi dan spesifikasi requirement dan bukan dokumen desain. Sebisa mungkin berupa kumpulan dari APA yang harus dikerjakan sistem, BUKAN BAGAIMANA sistem mengerjakannya. Pengguna dari dokumen kebutuhan adalah pihak-pihak yang dijelaskan pada gambar dibawah yang menjelaskan pihak pengguna dokumen dan kepentingannya dengan dokumen tersebut.



Dokumen kebutuhan sebaiknya memenuhi 6 hal berikut :

  1. Menjelaskan perilaku eksternal sistem
  2. Menjelaskan batasan pada implementasi
  3. Mudah diubah
  4. Sebagai alat referensi untuk pemelihara sistem
  5. Mencatat peringatan awal tentang siklus dari sistem
  6. Menjelaskan bagaimana sistem merespon hal-hal yang tidak biasa/normal

IEEE menyarankan standar struktur dari dokumen kebutuhan sebagai berikut :
1. introduction
  1.1 purpose of the requirement document
  1.2 scope of the product
  1.3 definitions, acronyms and abbreviations
  1.4 references
  1.5 overview of the remainder of the document
2. General description
  2.1 product perspective
  2.2 product functions
  2.3 user characteristics
  2.4 general constrains
  2.5 assumptions and depedencies
3. Specific requirement covering functional, non-functional and interface requirements. This is obviously the most substantial part of the document but because of the wide variability in organisationa practice, it is not appropriate to define standard structure for this section. The requirements may document external interfaces, describe syste functionality and performancce, specify logical database requirements, dsign constraints, emergent system properties and quality characteristics.
4. appendices
5. index
Sekalipun standar IEEE belumlah ideal tetapi telah memberikan masukan format dokumen yang cukup lengkap. Informasi yang dimasukkan ke dalam dokumen tergantung pada tipe software yang dibangun dan pendekatan yang digunakan untuk membangun software tersebut.
Struktur lain yang bisa digunakan adalah sebagai berikut :

  1. Preface
  2. Introduction
  3. Glossary
  4. User requirements definition
  5. System architecture
  6. System requirements specification
  7. System models
  8. System evolution
  9. Appendices
  10. Index
Kedua struktur sama baiknya dan salah satu dapat digunakan untuk menyusun dokumen kebutuhan.