Rekayasa Perangkat Lunak Prodi Sistem Informasi Gasal 2011/2012

Silabus Rekayasa Perangkat Lunak Program Studi Sistem Informasi
Semester Gasal 2011/2012

Dosen: Umi Proboyekti, S.Kom, MLIS
Selasa 07.30- 10.00 dan 10.30-13.00 (3 SKS)

Presentasi Tugas Akhir



Selasa 6 Desember 2011 10.00-16.00 (Kelas A)
10.00-11.00 Dimas Aryo, Lucky, Rendy, Jeffry, Besar, Menick
11.00-12.00 Niko Ardanisatya, Sti Fandy, Apui Jalung, Krisna, Tino, Edwin
12.00-13.00 Christian, Yustinus, Charisma, Henry, Joko, Vory, Angga
13.00-14.00 Alvin, Felix, Riecho, Albertu, Trisna, Joseph Jojo
14.00-15.00 Olla, Ayu, Phams, Hari, Stephanie, Femmy Herlika
15.00-16.00 Bhimasta, Radita, Eska/Aditya, Digi/Rima

*yang belum terjadwal, pilih jadwal yang belum 7 orang

Rabu 7 Desember 2011 10.00-16.00 (kelas B)
10.00-11.00 Wibowo, Eden Omega, Jessica, Noniek, Ivan, Nathan, Fendrik
11.00-12.00 Ade putra, Happy, Desmond, Yusdianto, Okki, Hana, Franky
12.00-13.00 Daniel, Wahyu, Andri S, George, Gerardus, Martinus
13.00-14.00 Hendra DP, Budi P, Lefran DR, PAkiding, Arman, Daulat
14.00-15.00 Hanung, Yohanes Riswa, Rudi Setiawan, Daniel P, Rio J,, Elfira
15.00-16.00 Lucky Limowa, HEndry S, Jonas, Andri Ratuain, Sion, Francois, David S

*yang belum terjadwal, pilih jadwal yang belum 7 orang


TUGAS AKHIR
Tugas Akhir RPL Gasal 2010-2011
Jogjalib adalah aplikasi web catalog perpustakaan bersama berbagai perpustakaan di DIY : perpustakaan umum, akademik, komunitas dan sekolah. Fungsi aplikasi ini berkembang dengan memberikan sumber informasi lain dalam bentuk full text seperti berita terbaru, artikel dan karya ilmiah. Katalog ini menjangkau masyarakat DIY yang akan mengakses koleksi buku di berbagai perpustakaan. Untuk mengakses buku di suatu perpustakaan, biasanya ada prosedur yang harus dipenuhi seperti membuat kartu anggota. Jogjalib menjembatani pengadaan kartu anggota dengan pendaftaran anggota secara online, mencetak kartu secara mandiri dan pemeriksaan kebenaran identitas secara otonomi pada perpustakaan di mana individu tersebut terdaftar sebagai anggota (mahasiswa) atau lokasi perpustakaannya dekat dengan tempat tinggal (masyarakat umum). Kartu anggota tersebut dapat digunakan untuk mengakses buku yang diperlukan secara local di perpustakaan yang dituju sehingga memotong prosedur yang biasanya harus dilalui.
Semua kebutuhan tersebut diwujudkan di dalam aplikasi jogjalib berbasis web di www.jogjalib.com , namun demikian ada banyak hal yang perlu disempurnakan. Tugas mahasiswa RPL adalah memperhatikan prosedur pendaftaran anggota: cara pendaftaran, data yang dibutuhkan, informasi yang diberikan dan desain dari bagian pendaftaran pada aplikasi tersebut. Ubahlah bagian pendaftaran tersebut menjadi desain yang lebih informatif, singkat dan bermanfaat bagi pengguna. Produk yang dihasilkan dari tugas ini adalah PRESENTASI PRODUK yang dijabarkan dalam :
1. Requirement yang jelas
2. Use case diagram
3. Arsitektur konten
4. Desain halaman web
5. Test case untuk menguji
Bentuk presentasi ke klien berupa PPT, PDF atau ANIMASI atau apapun. Tidak ada program dan tidak ada demo program. Desain dapat dibuat dari tools apapun dan tidak perlu dijalankan. Presentasi berdurasi 5-8 menit kepada klien.

JADWAL PRESENTASI INDIVIDU TUGAS AKHIR RPL
KELAS A tgl 6 Desember 2011 jam 10.00-16.00
KELAS B tgl 7 Desember 2011 Jam 10.00-16.00

Bahan Kuliah
Pertemuan 1: Perangkat Lunak : Definisi Rekayasanya, karakteristik
Pertemuan 2: Process Model
Pertemuan 3: Model Proses Prescriptive
Pertemuan 4: Model proses agile
Pertemuan 5: Prinsip RPL (Bab 4)
Pertemuan 6: Kebutuhan : memahami kebutuhan: FILE JPG, FILE XMIND

TTS : Jumat 7 Oktober 201113.00-14.30 sifat Buku Terbuka

Pertemuan 7: Wawancara untuk kebutuhan sistem informasi
Pertemuan 8: Design Concept
Pertemuan 9: Architectural Design
Pertemuan 10: Quality Concept
Pertemuan 11: SQA
Pertemuan 12: Software Testing Strategy
Pertemuan 13: Software Testing
Pertemuan 14: Presentasi Tugas Akhir (Individu)

Distribusi Nilai :
TTS: 15
Produk Tugas Akhir : 20
Model Proses (Handout dan Presentasi ): 15
Tugas-tugas : 50

Penilaian dan peraturan mengikuti standar universitas.

Buku pegangan :
Pressman, R.S.(2010). Software engineering: A practioner's approach ,7ed. NY: New York: McGraw-Hill.

Tugas Baca Bab 4 Software Engineering: a Practioner's Approach edisi 7
Setiap mahasiswa wajijb membaca chap 4 sebagai bekal utk kegiatan dan assesment di kelas selasa 20 september 2011

Tugas Model Proses :
Deskripsi Tugas : Masing-masing kelompok mempelajari model proses yang didapatkan untuk mengenali dan memahami:
1. urutan aktifitas dalam model proses : penjelasan tiap aktifitas, aksi dan tugas-tugas dalam aktifitas tersebut
2. ciri proyek pengembangan perangkat lunak yang cocok untuk model tersebut
3. ciri khas dari model proses
4. kekurangan dan kelebihan dari model
5. latar belakang model proses tersebut dikembangkan dan siapa yang mengembangkan serta kapan.
Bahan utama dari buku Software Engineering oleh Roger S Pressman edisi 7, dan bahan lain yang relevan dan dapat dipertanggung jawabkan.
Buatlah presentasi yang kreatif untuk menjelaskan proses model tersebut di kelas. Setiap kelompok mendapat waktu 25 menit untuk presentasi dan 5 menit tanya jawab jika ada.
Buatlah paper tentang model proses tersebut yang mencakup 5 hal di atas berbentuk resume dan tidak lebih dari 3 halaman A4. File presentasi dalam format apapun (image, slide, video) dan paper dikumpulkan.
Penilaian mencakup kelengkapan dari ke 5 hal di atas, kerja sama kelompok, kreatifitas dan presentasi.

Jadwal Presentasi
Tgl 6 September 2011 : V Model, Incremental, Prototype, Spiral
Tgl 13 September 2011 : Concurrent, XP, ASD dan Scrum

Kelompok Tugas Model Proses Kelas A (Selasa Pagi)
V Model
23090451 Besar Wibowo. S
23090468 Trisna Ayuningtyas
23090469 Diminis Nora
23090475 Stefanes Lucky Sabastian
23090478 Rendy Prayogo

SPIRAL
23090463 Ayu rahmawati
23090472 Theresia digi p
23090471Dimas aryo
23090459 Jefri prasetyo
23090444 Noel Dyaztian (ditambahkan)

ASD
23090470Yosef Koko Kurniawan
23090479Raden Agoeng Bhimasta
23090482Aditya Satrio Kumolo
23090484Andra Solala Zebua
23090526Radita Liem Tapaninghesti

XP
23090449 - STEPHANIE MULYONO
23090455 - TRI CAHYANI
23090501 - FEMMY FEBRIYANTI KUMENIT
23090506 - HERLIKA SIGALINGGING
23090521 - OLLA DOROTHEA BARTHO

CONCURRENT
23090498Apui Jalung -
23090495Edwin Yakub -
23090517Stifanddy Cavendish -
23090503Tino -
23090518Vincentius Krisna Adi Surnano -

SCRUM
23090442Albertus Satria Yudha
23090446Alvin Setiawan
23090456Niko Ardanisatya
23090458Riecho Antonius
23090461Felix Fredana Erlangga

PROTOTYPE
23080304Charisma Frans
23080322Henry Lande
23080333Yuliarta A.D
.......... Vory
........... Joko

INCREMENTAL
Christian Candra S 23060107
Adi Purnomo 23080309
Yustinus Hermawanto 23080332
Yohanes Pambudi 23080344
Harry Van Basten 23080380

Kelompok Tugas Model Proses Kelas B (Selasa Siang)
V-Model
Oktavianus Pakiding 23050034
Jonas Henriki Gomes 23050051
Levran Destian R 23060132
Hilarius DA Maradona 23060160
Daulat Liberty 23050136

CONCURRENT
Andri Setiawan - 23050080
Elfira Laurens - 23070221
Martinus - 23080400
Happy C. Lidiporu 23090450
Desmond Alfarez 23090525

INCREMENTAL
Rio Julesius G - 23050059
Hanung Naung H - 23060142
Rudy Setiawan - 23060147
Yohanes Riswadhipa 23070233
( +1 Anggota )

PROTOTYPE
Sion gamaliel leonalle (23070210)
Protasius Andri Ratuain (23070271)
Francois R.H Simanjuntak (23070242)
Franky Sirait (23070219)
Hana Duwi Hari Yanti (23080327)

SPIRAL
Rangga Kristanto - 23060114
Yusdianto Hartono - 23070298
Wibowo Santoso - 23070300
Nathanael C.K - 23070301
Ivan Septian 2308

ASD
23090443 / David Saputro Sugianto
23090441 / Fendrik Prayogo Sugianto
23090505 / Eden Omega Vesty
23090485 / Jessica Belinda
23090462 / Noniek Drajat Wijaya

XP
Hendry Santoso 23090486
Hendra Dwi Putra 23080317
Budi Prasetyo 23080318
Lucky Limowa 23080417
Okki Endah Sayekti 23080430

SCRUM
Wahyu Christian Raditya ( 23080439)
Gerardus Mardani (23080395)
George Arnoldus Hans Louk (23080429)
Daniel Y. Marthin (23080419)
FX. Ade Putra Fajar (23080432)

05 Dec, 2011 | othie |

Rekayasa Kebutuhan

Pembahasan rekayasa kebutuhan diadaptasi dari : Pressman, Roger S . Software Engineering: A Practitioner's Approach. 6th Edition. McGraw-Hill. 2005.

What is it ?
Requirement engineering helps software engineers to better understand the problem they will work to solve. It encompasses the set of tasks that lead to an understanding of what the business impact of the software will be, what the customer wants, and how end-users will interact with the software
Why is it important ?
Designing and building an elegant computer program that solves the wrong problem serves no one's needs. That's why it is important to understand what the customer wants before you begin to design and build a computer-based system.
What is the work product ?
The intent of the requirements engineering process is to provide all parties with a written understanding of the problem. This can be achieved though a number of work products: user scenario's, functions, and features lists, analysis models, or a specification.

Latar belakang mengapa perlu adanya rekayasa kebutuhan adalah kenyataan bahwa menemukan kebutuhan klien secara lengkap adalah tidak mudah dan mahal. Tidak mudah karena :
1. klien tidak selalu mengetahui dengan pasti dan jelas apa yang diperlukan
2. kebutuhan yang diutarakan oleh klien tidak selalu sesuai dengan apa yang dimaksud
3. kebutuhan klien berubah-ubah di sepanjang kegiatan pembangunan perangkat lunak
Hal-hal di atas menyebabkan biaya pembangunan perangkat lunak menjadi mahal karena ada tambahan biaya lagi untuk perubahan yang dilakukan dan waktu yang dibutuhkan lebih dari seharusnya.

Rekayasa kebutuhan membangun jembatan menuju desain dan pembangunan perangkat lunak dengan menyediakan mekanisme yang tepat untuk memahami apa yang diinginkan klien, menganalisis kebutuha, menguji kelayakan, bernegosiasi untuk solusi yang masuk akal, menetapkan solusi yang dapat dipahami dua belah pihak, uji spesifikasi dan mengelola kebutuhan yang akan diwujudkan ke sistem operasional. Rekayasa kebutuh terdiri dari 7 fungsi:
1. inception [permulaan]
Inception atau permulaan, merupakan awal dari terjadinya pembicaraan tentang kebutuhan akan software. Permulaan ini dapat terjadi karena dari pembicaraan biasa,kebutuhan bisnis yang dirasakan, adanya pasar potensial, atau munculnya layanan potensial yang dapat dilakukan oleh software.
Aktifitas diawali dengan penetapan siapa stakeholder/pihak-pihak terkait dengan perangkat lunak yang akan dibangun. Misal :
- business operation manager
- product managers
- marketing people
- internal + external customer
- end-users
- consultants
- product engineers
- software engineers
- support and maintenance engineers
- others.
Kebutuhan dieksplorasi dari berbagai pandangan dari masing-masing stakeholders. Kebutuhan yang sama dan berbeda dari masing-masing dicatat, perbedaan persepsi diluruskan. Pertanyaan-pertanyaan awal/dasar dilontarkan kepada setiap stakeholder.

2. elicitation [Pengungkapan]
Klien mengungkapkan kebutuhan. Proses ini tidak mudah karena: batasan sistem sering tidak jelas, klien tidak cukup paham apa yang dibutuhkan dan kebutuhan sering berubah.
Aktifitas dilakukan dalam bentuk pertemuan, dimana setiap stakeholder yang diundang diminta untuk membuat daftar kebutuhan software yang disertai penjelasan tentang karakteristik atau detil dari kemampuan tersebut.

3. elaboration [Penjelasan]
Apa yang diungkapkan pada proses permulaan dan pengungkapan kebutuhan, dijelaskan panjang lebar. Fokus pada pemodelan fungsi, fitur dan batasan dari perangkat lunak. Dalam kasus OOP, maka class, atribute dan hubungan antar class diidentifikasi pada aktifitas ini.

4. negotiation [Konflik Resolusi]
Jika terjadi konflik kepentingan karena perbedaan kebutuhan antara bagian pada klien, atau antar end-user, maka aktifitas negosiasi diperlukan untuk membuat prioritas kebutuhan, mengevaluasi tiap kebutuhan untuk mengurangi atau mengubah sesuai dengan yang dimaksud pihak-pihak yang berkonflik.
5. specification
Spesifikasi dapat berubap dokumen, model grafik, model matematika, skenario atau prototype yang merupakan produk akhir dari rekayasa kebutuhan. Apa yang disajikan sebagai spesifikasi merupakan hasil identifikasi kebutuhan melalui aktifitas-aktifitas sebelumnya.Spesifikasi menggambarkan fungsi dan keinerja dari perangkat lunak dan batasan-batasan yang ditentukan.
6. validation
Menguji kualitas dari spesifikasi untuk memastikan kebutuhan yang dinyatakan dapat diterima/sepaham, konsisten, lengkap dan bebas kesalahan. Mekanisme yang dapat dilakukan adalah formal technical review atau pertemuan evaluasi teknis.
7. management
mengelola kebutuhan dengan identifikasi, kontrol dan mengikuti perkembangan kebutuhan software yang dikerjakan selama proyek dan perubahan-perubahan yang terjadi.

13 Sep, 2008 | othie |

Pengantar Rekayasa Perangkat Lunak

Berbicara tentang rekayasa perangkat lunak, bukanlah berbicara tentang pemrograman untuk membangun sebuah perangkat lunak. Apa yang dibahas di dalam rekayasa perangkat lunak adalah kegiatan-kegiatan yang dilakukan untuk membangun perangkat lunak dan kegiatan yang menaunginya sehingga perangkat lunak yang dihasilkan sesuai dengan standar mutu yang ditentukan.
Mengajarkan dan mengikuti kuliah rekayasa perangkat lunak (RPL) sama-sama tidak mudahnya. Mengajarkan suatu konsep memerlukan kreatifitas sehingga konsep tersebut tidak hanya dapat dibayangkan dan masuk akal, tapi juga menarik. Memahami suatu konsep yang tidak terpikirkan saat melakukan pemrograman memerlukan imajinasi dan analogi yang membantu diterima secara logis.

Pada umumnya mahasiswa Teknik Informatika dan Sistem Informasi lebih mengutamakan pemrograman, karena menurut mereka itu adalah kemampuan inti yang harus dikuasai. Pada kenyataannya, banyak kemampuan lain yang mungkin selama ini dianggap sebelah mata, justru menjadi penopang dan penentuk proses membangun perangkat lunak: kerja sama dalam tim, kemampuan berkomunikasi, kemampuan membuat dokumentasi, kemampuan wawancara, kemampuan belajar cepat bidang lain di luar pemrograman dan sebagainya.

Dalam rekayasa perangkat lunak umumnya ada beberapa kegiatan yang senantiasa ada pada model proses apapun : identifikasi kebutuhan, desain, pengkodean, penerapan dan pemeliharaan. Dari kegiatan-kegiatan yang berurutan tersebut, pengkodean baru dapat dilakukan jika kebutuhan sudah dikumpulkan dan diketahui lalu didesain. Pengkodean yang sering menjadi fokus mahasiswa ini tidak berhenti ketika selesai, tapi ada pemeliharaan yang pasti terkait juga dengan kebutuhan. Kegiatan lain yang menaungi rekayasa perangkat lunak adalah jaminan mutu perangkat lunak [SQA- Software Quality Assurance]. Pada dasarnya, setiap kegiatan memilik standar bagaimana kegiatan tersebut seharusnya dilakukan untuk menghasilkan produk yang diinginkan.

Matakuliah RPL semester ini banyak mengadopsi bab-bab di buku Pak Roger S Pressman, Software Engineering: A Practioner's Approach. Selain itu informasi yang dikelola lokal dan tidak kalah menarik untuk dibaca dan didiskusikan adalah dari Pak Romi Satria Wahono, secara khusus di kumpulan tulisan tentang Software Engineering. Sumber pengetahuan lokal lain adalah ilmukomputer.com pada katagori Rekayasa Perangkat Lunak.

13 Sep, 2008 | othie |

Rekayasa Perangkat Lunak

Pengantar
Rekayasa Perangkat Lunak adalah kegiatan yang sistematis dalam membangun sebuah perangkat lunak untuk menjawab kebutuhan-kebutuhan satu pihak. Skala perangkat lunak yang dibangun beragam berdasarkan luas dan detil kebutuhan klien yang memerlukannya. Perangkat lunak yang memiliki 300.000 baris perintah dikatagorikan perangkat lunak berukuran kecil. Ukuran ini tentu besar untuk kapasitas seorang mahasiswa bidang Teknologi Informasi/Informatika. Karena itu kegiatan ini umumnya dilakukan oleh suatu tim bukan perorangan.

Kegiatan dilakukan secara sistematis. Ini tidak hanya berarti berencana, tetapi juga mengacu pada suatu model tertentu yang sesuai dan menjalani prosedur wajib. Model tertentu ini adalah model proses dan prosedur wajib adalah pengelolaan proyek dan penjaminan mutu.

Model Proses
Model proses menjabarkan urutan kegiatan dalam merekayasa perangkat lunak. Dari berbagai macam model proses yang dibuat oleh banyak ahli dan praktisi, ada 4 kegiatan inti yang selalu ada yaitu:
1. pengumpulan kebutuhan
2. perancangan sistem
3. pengujian sistem
4. penerapan sistem
Beberapa model proses yang sudah dikenal adalah Waterfall, Increment, Spiral, Rapid Application Development, Prototying, Component -Based Development, dan Extreme Programming. Beragam model proses ini berusaha untuk menjawab atau memandu pengembangan perangkat lunak dalam berbagai kasus. Dengan demikian tidak ada model proses paling cocok untuk semua kasus rekayasa perangkat lunak.
Rekayasa perangkat lunak pada umumnya dilakukan secara tim. Tim pembangun dibentuk dan dikelola dalam suatu manajemen proyek perangkat lunak.

Manajemen Proyek Perangkat Lunak
Mengatur dan mengkoordinasi anggota-anggota tim, sesumber yang digunakan, waktu yang tersedia untuk tiap proyek, dan komunikasi antar tim atau anggota bukanlah suatu yang mudah untuk dilakukan.
Tim pembangun perangkat lunak penting memiliki kemampuan manajemen untuk mendukung ketrampilan teknis yang dimiliki. Dalam pengerjaan suatu proyek perangkat lunak, kemampuan berkomunikasi, penggalian informasi, analisis, presentasi dan pengaturan waktu sangat penting. Ini sering tidak disadari oleh mahasiswa-mahasiswa di jurusan Teknik Informatika, Sistem Informasi atau Ilmu komputer. Banyak dari mereka berpikiran bahwa kemampuan pengkodean atau programming menjadi kemampuan yang paling mendapat prioritas.
Mengelola suatu proyek perangkat lunak juga adalah proses memastikan kualitas dari suatu proyek yang dikerjakan. Kualitas suatu software menjadi prioritas tinggi dalam pembangunanya. Karena itu ada bagian khusus dalam tim pembangun yang disebut tim penjamin mutu yang menerapkan prinsip-prinsip dalam software quality assurance.

Proses Pembangunan Software
Langkah penting dalam pembangunan software adalah pengamatan dan pengumpulan kebutuhan software atau yang disebut software requirement.
Setelah kebutuhan didapatkan dari klien secara lengkap, maka analisis dan desain sistemdilakukan oleh tim pembangun. Desain yang juga perlu mendapat perhatian adalah User Interface Desain yaitu bagian yang berinteraksi langsung dengan pengguna software.
Setelah desain, maka tahap pengkodean dilakukan. Hasil pada tahap ini dilakukan pengujian, dan setelah lolos pengujian perangkat lunak diterapkan di lokasi klien sambil terus dilakukan pengujian menggunakan kasus-kasus yang terjadi di kondisi sebenarnya.
Pelatihan kepada pengguna perangkat lunak wajib dilakukan untuk mensukseskan penerapan. Pelatihan ini juga diharapkan dapat membantu tim pembangun dalam tahap pemeliharaan perngkat lunak.
Ada kalanya perangkat lunak yang dibangun adalah suatu website, untuk itu hal-hal yang berkenaan dengan pembangunan suatu website perlu diperhatikan seperti struktur web dan keamanan terhadap integritas data.

08 Jan, 2008 | othie |

© 2007 yoursite.com | Designed by DesignsByDarren
Ported to Nucleus CMS: Suvoroff