RPL – part.9

Rabu, 11 November 2009

Pertemuan kesembilan ini agak berat topik bahasannya karena ada 2 bab yang dibahas dari bukunya pak Pressman yaitu bab 13 tentang Software Testing Strategies dan bab 14 tentang Software Testing techniques. Banyak temen-temen yang lupa tiket masuknya (fotokopi buku pressman) ayng terpasa hanya mendengarkan tanpa menyimak modul masing-masing.

Semua detail ada di buku pressman jadi tidak perlu didetailkan disini kaena yang dibuku lebih detil. Untuk bahasan minggu depan adalah membahas bab 15 (Product Metrics For Software). Pak Budsus akan menjelaskan bagaimana cara mengukur software yang kita bangun.

Pertemuan minggu depan (pertemuan ke sembilan) da tes kecil tentang Basic Path Testingnya Tom McCabe (pressman halaman 393-394). Tesnya nanti seputar Flow graph notation yang kemudian dibuat menjadi Independent Program Path.

RPL – part.8

Rabu, 4 November 2009

pertemuan kedelapan ini bahas slide ma buku yang di pressman…lupa topik bahasan utamanya…cek milis and bukunya bapak pressman ^^

 

RPL – part.7

Rabu, 28 Oktober 2009

 

di pertemuan ke tujuh ini tumben tidak muncul sepasang dosen yang mengajar di mata kuliah ini. Pak Budsus datang sendiri tanpa ditemani Bu Umi. Dan ternyata gantian, ada Bu Umi tapi tidak ada Pak Budsus. What’s wrong??? ^^

 

topik bahasan pertemuan kemaren adalah tentang design. (detail all in slide…here…the detail of meeting)…

 

sebagai designer ada 4 produk yang harus kita hasilkan antara lain adalah

• komponen
• interface
• arsitektur
• data class diagram

 

ada banyak tahap analisis, tapi tidak semua analisis digunakan pada design. Design :

• harus bisa diimplementasikan
• harus bisa dibaca
• bisa menyediakan gambaran software yang dibangun

 

dalam proses design perlu requriement, ada yang namanya faktor implisit dan eksplisit…apa bedanya? Misalnya:

• explicit adalah yang tertulis. Ex: sistem bisa mempunyai fitur find mata kuliah
• impisit adalah yang tidak bisa diungkapkan. Ex: profil pemakai sistem tidak semua bisa menggunakan komputer dengan lancar, jadi nanti dalam pembuatan sistem bagaimana GUI bisa dirancang dengan bagus, dilengkapi tutorial penggunaan dan lain-lain.

 

Sebenarnya bias menagkap materi yagn disampaikan, tapi terus kalau dituliskan agak belibet juga, so untuk detail bisa didownload di milis RPL dan jika ada kesulitan bisa ditanyakan disana (create new thread)…Minggu depan (part.8) akan dipimpin oleh bu Umi dan untuk pertemuan 2 minggu kemudian (part.9) akan kembali ada pak Budsus lagi. Dan buat temen-temen biharapkan baca bukunya pressman yang bab 10,11,12 agar nanti waktu pembahasan bisa lebih cepat.

 

RPL – part.6

Rabu, 7 oktober 2009

Pertemuan keenam membahas tentang UID. Setelah itu dibagi sesuai dengan kelompok dengan project masing-masing yang sebelumnya sudah didesain.

UID (User Interface Design)

aturan penting dalam design adalah

kurangi penggunaan ingatan manusia — jadi sebisa mungkin membuat desain yang gampang diingat oleh user yang pernah menggunakannya

konsistensi warna dan simbol — warna dan simbol bisa jadi menjadi citra atau brand image aplikasi yang kita bangun. Oleh karena itu, penggunaan warna dan simbol harus konsisten

kontrol pada pengguna — jika ada suatu aksi. Userlah yang mengendalikan aksinya

dan dalam pemodelan atau design suatu aplikasi objek adalah fokus utamanya. Bagaimana pbjek yang kita buat bisa semudah dan semenarik mungkin untuk digunakan.

Kisi

More detail in slides…

Rabu, 7 oktober 2009

Pertemuan keenam membahas tentang UID (User Interface Design). Setelah itu dibagi sesuai dengan kelompok dengan project masing-masing yang sebelumnya sudah didesain.

aturan penting dalam design adalah

• kurangi penggunaan ingatan manusia — jadi sebisa mungkin membuat desain yang gampang diingat oleh user yang pernah menggunakannya
• konsistensi warna dan simbol — warna dan simbol bisa jadi menjadi citra atau brand image aplikasi yang kita bangun. Oleh karena itu, penggunaan warna dan simbol harus konsisten
• kontrol pada pengguna — jika ada suatu aksi. Userlah yang mengendalikan aksinya

dan dalam pemodelan atau design suatu aplikasi objek adalah fokus utamanya. Bagaimana pbjek yang kita buat bisa semudah dan semenarik mungkin untuk digunakan.

More detail in slides…

RPL – part.5

Rabu, 30 September 2009

Pertemuan kelima membahas Use Case. Use case adalah salah satu metode untuk memodelkan objek dalam UML (Unified Modelling Language). Kita akan mempelajari bahasa simbol (pemodelan).

Apa itu UML? UML adalah bahasa yang digunakan untuk membuat model. Tidak hanya menggambarkan atau memodelkan tapi juga membahasakan dari apa yang kita modelkan. Memang sebelum UML tercipta, banyak persepsi tentang UML karena setiap orang mempunyai pendapat dan pemikiran yang berbeda-beda. Dan sekarang simbol-simbol dan penggunaan UML sudah distandarkan . Di UML ada 14 diagram atau metode dalam memodelkan objek. Nah, yang dipelajari hari ini adalah diagram use case.

Simbol-simbol di use case

Use Case

Fungsi use case adalah untuk menangkap requirement (spesifikasi kebutuhan). Use case untuk memodelkan fungsi atau layanan yang harus disediakan oleh sistem. Bisa membatasi sistem, batasan sistem untuk menyatakan bahwa use case ada pada sistem tertentu, dinyatakan dengan simbol segi empat. Use case adalah interaksi antara actor dan sistem. Elips mencerminkan sistem dengan actor. Use case bisa berdiri sendiri tanpa interaksi yang fungsi internal sistem yang akan dijalankan. Use case bisa jadi perluasan dari use case yang lain. Di simbol di use case untuk interaksi hanya garis tanpa tanda panah dan use case selalu di dalam suatu batasan

Karakteristik use case:

• Interaksi sistem
• Fungsi internal
• Perluasan

Include

Tujuan dari include adalah jika ada langkah-langkah yang sama dalam beberapa use case lebih baik dijadikan dalam satu use case. Untuk menghemat dan agar sistem lebih efektif dan efisien.

Extends

Extends bersifat optional

Kondisi awal

Suatu kondisi agar use case bisa berjalan. Ex: kasir di supermarket. Sebelum transaksi kasir harus log in dulu. Kondisi awalnya adalah kasir harus log in dahulu.

Kondisi akhir

Kondisi dimana use case selesai dengan normal. Ex: transaksi tersimpan di database dan pelanggan menerima bukti pembayaran adalah kondisi akhirnya.

Skenario alternatif

Bisa disebut juga dengan pengecualian. Ex: jika berbelanja dengan kartu kredit dan waktu pembayaran ternyata kartu tidak bisa dipakai karena sudah limit atau over limit.

Untuk lebih detail tentang UML bisa membaca buku “applyinh UML and patterns” oleh Craig Larman

RPL – part.4

Rabu, 16 September 2009

Pertemuan keempat ini membahas DFD (Data Flow Diagram). Pembahasan ini juga pernah dibahas lebih dalam saat mata kuliah Analisis dan Perancangan Sistem Informasi.

DFD yang akan dijelaskan adalah mulai dari context diagram dan DFD level-0 dan level-1. Jadi tidak akan terlalu complex.

• Context diagram —– Seperti rangkuman, ada nama proses dan nama sistemnya. Sumber atau tujuan data sistem mempunyai aktivitas yang dijabarkan di level-0, labelnya 0 tapi bukan DFD level-0
• DFD level-0 —– Dilengkapi data store. Menuliskan aktivitas utama sistem. Fungsional utama
• DFD level-1 —– Milik setiap aktivitas utama. Milik level-1. Berisi aktivitas detail dari aktivitas utama.

More detail on hand book.

RPL – part.3

Rabu, 9 September 2009

Requirement…proses mengumpulkan kebutuhan sebelum modelling dan seterusnya. Ada banyak cara untuk proses requirement ini. Pada pertemuan kali ini akan dibahas dua cara terlebih dahulu. Antara lain adalah inception dan Elicitation. Elaboration dijelaskan minggu ke depan atau pertemuan keempat.

Inception

Semua pertanyaan dan pendapat dikumpulkan.

• Identification the stakeholder —– Membuat daftar siapa yang akan diundang dalam diskusi. Ada dua stakeholder yang mendapatkan manfaat langsung ataupun tidak langsung.
• Pengumpulan pendapat dari berbagai sumber
• Identifikasi hasil diskusi
• Asking the first question

Elicitation

Proses mulai mengumpulkan kebutuhan bersama-sama, bentuknya seperti gathering atau meeting (detail on hand book). Kumpulan spesifikasi yang telah disepakati saat meeting yang akan digunakan dalam acuan saat proses pembangunan produk nantinya

Detail on hand book….setelah menerangkan tentang dua cara dalam requirement, pak Budsus menjelaskan tentang template dokumentasi produk yang akan dibangun sesuai dengan kelompok dan kasus yang sudah dibuat sebelumnya.

RPL – part.2

Rabu, 2 September 2009

Pertemuan kedua kemaren membahas tentang buku Software Engineering a Practitioner’s Approach (sixth edition). Yang dibahas chapter 3 dan 4.  Chapter 3 membahas tentang Prescriptive Process Model. Chapter 4 membahas tentang Agile Development.

Langsung menuju ke topic. Masuk ke chapter 3 dulu yang membahas tentang Prescriptive Process Model. Prescriptive artinya ketentuan, Process adalah proses dan Model ya model. Jadi kalo digabung ya jadi ketentuan model proses. Jadi Prescriptive Process Model itu membantu developer untuk membangun suatu project melalui pendekatan yagn teratur dan nantinya akan menghasilkan sebuah produk. Prescriptive Process Model lebih banyak di disiplin dan dokumentasi. Artinya apa? Jadi ketika developer, baik PSP (Personal Software Project) ataupun TSP (Team Software Project) di setiap langkah-langkah perjalanannya membangun project perlu ditanamkan kedisiplinan tingga dan dokumentasi tahap-tahap yang sudah ditempuh dalam membangun project untuk arsip dan untuk mempermudah kerja developer. Prescriptive Process Model juga mempunyai model-model yang bisa digunakan (penjelasan singkat).

Semua model proses menggunakan urutan proses development: Coomunication – Planning – Modeling –  Construction – Deployment

Waterfall model

Alur kerjanya adalah dari yang paling atas dulu baru ke bawah. Jika yang atas belum selesai maka tidak boleh ke bawah atau proses selanjutnya, harus diselesaikan dulu. Dan jeda waktu antara proses bisa lama dan menjadi pemborosan. Model ini menjadi pedoman untuk model yang lain

Increment model

Proses kerjanya adalah satu set pekerjaan dikerjakan dahulu (communication – deployment) baru diberi penambahan lagi. Produk pertamanya adalah core product. Setelah itu, increment dengan menambah fitur-fitur lainnya sehingga lama-lama program menjadi bagus. Jadi prinsipnya bisa digambarkan seperti pengulangan waterfall model

RAD model

Proses ini memang cepat. Sesuai dengan namanya yaitu Rapid Application Development tool. High speed, kurun waktunya cepat. Pada fase model, construction seperti waterfall dan increment. Aksi di deployment hasil atau produk dari team. Setelah waktu yang ditentukan selesai baru masuk deployment.

Developer (team) yang menggunakan model ini mempunyai template atau standar sendir dalam jangka waktu pembuatan software. Jadi, tidak harus 60 – 90 hari. Jadi, jika gambling, tidak tahu berapa lama selesai, lebih baik jangan menggunakan model ini.

Prototyping model

Membuat software dengan memanfaatkan teknik prototyping. Ada prototypenya, karena requirement tidak selalu diabarkan dengan jelas. Jadi, prosesnya adalah membuat prototyipe dulu, lalu ditujukan pada customer karena customer belum tentu bisa menjelaskan rewuirement.

Spiral model

Spiral dalam satu putaran tidak selalu menghasilkan produk. Menggunakan milestone yaitu 1 target selesai atau titik tujuan atau target yang akan dicapai.

Concurrent model

Model ini sekarang mulai ditinggalkan, jadi tidak usah terlalu panjang membahas ini.

Topic selanjutnya. Masuk ke chapter 4 yaitu membaas tentang Agile Development. Manifesto agile Development adalah

1. interaksi antar individu
2. software disertai dokumentasi
3. customer harus dilibatkan dalam semua kegiatan proses model
4. iterative dan inermental model

Sebenarnya ada 12 prinsip, namun disebutkan yang penting ada 4 aspek di atas. Inti dari agile adalah individu, team, komunikasi. Jadi tiap-tiap orang bekerja dalam satu kantor atau ruangan agar bisa berkomunikasi dengan baik.

RPL – part.1

Rabu, 26 Agustus 2009

First Day…begitu masuk ruangan. Ternyata aku menemui dua dosen pengajar mata kuliah ini yang mukanya tidak asing lagi dimataku. Mereka adalah Bu Umi dan Pak Budi Susanto a.k.a Pak Budsus. Aku sudah bertemu dengan Bu Umi sejak semester 1 dan baru bertemu di dalam kelas dengan Pak Budi Susanto di kelas ini, karena memang Pak Budsus adlaah dosen prodi TI. Dan mereka itu adalah pasutri alias pasangan suami istri. Jadi mereka mengajar berdua gitu.

Pertemuan pertama perkenalan pengajar dan silabus singkat untuk kontrak perkuliahan selama satu semester. Kemudian langsung masuk ke dalam pembahasan materi, karena memang materinya (kalo diliat di silabus) memang banyak.

Software Engineering atau biasa disebut dengan Rekayasa perangkat lunak. Mata kuliah ini memberikan gambaran tentang pembangunan perangkat lunak yang menyangkut aspek yang teknis maupun non teknis.

Dalam proses perkuliahan ini, temen-temen mahasiswa tidak akan membuat aplikasi atau software atau meng-coding, tapi mahasiswa akan lebih berinteraksi dengan software.

Dalam pembuatan software ada urutan-urutan prosesnya, yaitu:

• Quality…..Bagaimana software itu bisa bertahan, karena software juga ada masa kadaluarsanya, karena perkembangan IT berkembang sangat cepat dan pesat
• Process

Di dalam sebuah process ada:

• Kerangka
  • Aktivitas
    • Aksi >> Task
      • Analisis

Dan di dalam process ada yang namanya umbrella, yaitu yang menentukan standard. Setiap aksi menghasilkan produk yang sudah terstandarisasi

Tipe Proses : Test – Stage – Phase

Ada 2 jenis process :

• Personal Software Process (PSP)
• Team Software Process (TSP)
• Method
• Tools

Konsep pembuatan skema:

• Conceptual schema…Tidak dapat diimplementasikan dengan DBMS

• Logical schema…Dapat diimplementasikan dengan DBMS

Pemodelan dengan Use Case Driven

Memikirkan bagaimana suatu mdel itu berjalan , yang harus diperhatikan adalah formatnya bagaimana, panjangnya (field yang dibutuhkan) berapa, dan lain-lain

Contoh Use Case Driven (UCD)

Program registrasi kuliah

• Text box untuk log in…User memasukkan NIM dan password

• Tampil apakah sudah lulus ice atau belum
• Pemilihan mata kuliah

Identifikasi bagaimana interaksi antara user dengan sistem. Jadi, dengan UCD kita bisa membuat sistem dan bisa untuk memodelkan sistem informasi

Tugas Rekayasa Perangkat Lunak (untuk pertemuan kedua):

• Membentuk kelompok (4 orang)
• Membuat studi kasus dan deskripsi studi kasus

Jadi tugasnya berupa print out, jadi diketik. Cukup satu halaman berisi daftar kelompok, nama studi kasus dan deskripsi singkat studi kasus.

Syarat kasusnya :

• Sistem untuk multi user
• Sistem online
• Menggunakan table (4-5 tables)

Untuk mengambil file materi dan diskusi tentang mata kuliah ini, pak Budsus membuat milis khusus untuk anak-anak kelas ini. Milisnya adalah lewat google groups. Jadi mahasiswa harus punya email dengan domain gmail terlebih dahulu, kemudian kirim email ke budsus@gmail.com dengan subjek RPL-SI. Nanti pak Budsus akan menginvite dan kita bisa langsung masuk dan menggunakan milis Rekayasa Perangkat Lunak.