DRAFT REPORT & DELIVERABLES

DRAFT REPORT & DELIVERABLES 1006665946 - Ahmad Fanani 1006665952 - AnangFerdi K. 1006671204 - ArdhianPrabantoro 1006665971 - ArgiantoRahartomo 1006665990 - Dimas Agung S. 1006671375 - ErryanSazany 1006666293 - FebrianaMisdianti 1006671690 - M. FajarrizkyAbidin 1006671740 - Muhammad Iqbal 1006671766 - Muhammad MufidAfif 1006770753 - NikenParamita

Table of Contents A.

Brief Description of Application ...................................................................................................... 3

B.

Testing ....................................................................................................................................................... 4

C.

Change Management .......................................................................................................................... 11

D. Process Area & Maturity Evaluation ............................................................................................ 16 E.

Work Contribution .............................................................................................................................. 26

F.

Appendices............................................................................................................................................. 30

BerKuliah - Developer

2

A. Brief Description of Application BerKuliah.com adalah aplikasi layanan berbagi berkas catatan kuliah dan arsip soal berbasis web. Proyek ini dilatarbelakangi oleh beberapa hal, antara lain: 

Kebiasaan buruk mahasiswa yang sering memfotokopi atau menyalin berkas catatan teman dan arsip soal ujian beberapa hari sebelum ujian, terutama pada H-1 ujian. Seringkali berkas catatan dan arsip soal tersebut hanya dipakai sesaat kemudian menumpuk dan tak digunakan lagi.



Pada umumnya, mahasiswa lebih mudah mengerti materi kuliah apabila dijelaskan oleh temannya dan membaca ringkasan.



Terdapat beberapa mata kuliah yang baik arsip soal maupun bahan ringkasannya sulit dicari.

Tujuan dari proyek BerKuliah.com, antara lain: 

Mengurangi jumlah kertas yang terbuang sia-sia karena penyalinan dan pemfotokopian berkas catatan atau arsip soal.



Memudahkan mahasiswa dalam belajar dengan menyediakan sarana untuk berbagi berkas catatan kuliah dan arsip soal.

 Memudahkan mahasiswa untuk mencari berkas catatan atau arsip soal yang dibutuhkan.


3

B. Testing 1. Methodology

Proyek BerKuliah menggunakan tiga metode dalam melakukan testing aplikasi demi menjamin kualitas proyek yang dihasilkan. Ketiga metode tersebut adalah unit testing, code coverage testing, dan user acceptance testing. Berikut ini penjelasan dari metode testing yang digunakan dalam proyek BerKuliah. 

Unit Testing Kami melakukan metode unit testing untuk memastikan bahwa semua fungsi yang ada dalam aplikasi mempunyai jaminan corectness. Proyek Berkuliah menggunakan framework Yii dengan menggunakan PHP 5. Yii sudah menyediakan konfigurasi aplikasi untuk melakukan unit testing dengan menggunakan PHP Unit, karena itu kami menggunakan PHP Unit untuk melakukan unit testing dalam aplikasi Berkuliah. Kelas Unit Testing yang akan dibuat harus extends kelas CTestCase atau CDbTestCase. Kelas CTestCase digunakan untuk melakukan unit testing secara umum sedangkan kelas CDbTestCase digunakan untuk melakukan unit testing terhadap model yang menggunakan active records.



Code Coverage Test Metode Code Coverage Testing dilakukan untuk meminimalisir adanya bugs pada software. Metode ini menghitung berapa persen jumlah method dan statement yang dipanggil dari keseluruhan method dan statement yang terdapat pada source code. Semakin tinggi code coverage sebuah program maka semakin kecil kemungkinan terdapatnya software bugs. Terdapat beberapa tools yang dapat digunakan untuk menghitung code coverage, salah satunya adalah XDebug pada ekstensi PHP. Kami memilih menggunakan XDebug karena kami juga menggunakan PHPUnit untuk melakukan Unit testing.



User Acceptance Test Metode User Acceptance Test adalah metode testing dengan melibatkan user dari luar/ selain developer. Tujuannya adalah untuk mengetahui sebaik apa kualitas software yang dikembangkan dari sudut pandang pengguna. Metode ini sering


4

digunakan oleh para software developer untuk menganalisis error yang masih ada pada software dan sekaligus mengetahui tingkat kepuasan pengguna atas software yang telah dikembangkan. Dalam hal ini, kami ingin mengetahui tingkat kepuasan mahasiswa Universitas Indonesia khususnya Fakultas Ilmu Komputer sebagai pengguna utama software kami dan mengetahui tingkat keberhasilan kami mengembangkan software ini. Catatan penting lain adalah Berkuliah menggunakkan Travis untuk memastikan setiap commit tidak ada masalah. Mekanisme Travis adalah sebagai berikut: 

Pengembang melakukan commit dan push ke server



Travis secara otomatis melakukan keseluruhan testing pada commit tersebut

Setiap hasil pengujian Travis dari commit berkuliah dapat dilihat di https://travis-ci.org/misdianti/berkuliah 2. Summary and Analysis

Pada laporan ini, kami akan memberikan hasil untuk unit testing menggunakan PHP Unit. Code coverage testing dan user acceptance testing belum dilakukan dikarenakan proyek ini belum selesai. Pada sprint selanjutnya, kami masih akan melakukan improvement terhadap fitur yang sudah ada dan menambahkan beberapa fitur baru. Project BerKuliah mempunyai sembilan class model, yaitu Badge, Course, DownloadInfo, Faculty, Note, Review, Student, Testimonial, dan LoginForm. Setiap unit test dibuat untuk setiap kelas model tersebut kecuali kelas LoginForm. Selain itu,

kami

juga

menambahkan

empat

kelas

unit

testing

lain

yaitu

CounterEventHandlerTest, DownloadEventTest, UploadEventTest, dan UserIdentity. Aplikasi berkuliah saat ini sudah lolos tahap unit testing. Hal tersebut menjelaskan bahwa semua fungsi dalam system BerKuliah sudah dapat berjalan dengan baik. Berikut ini adalah penjelasan masing - masing kelas unit testing yang dibuat untuk proyek BerKuliah. 1. Badge Test Kelas ini melakukan uji coba terhadap fungsi - fungsi yang ada pada kelas model


5

Badge. Kelas BadgeTest extends terhadap kelas CDbTestCase. Kelas ini memeriksa apakah badge yang disimpan di database ada dalam direktori proyek. Berikut ini adalah potongan kode untuk kelas BadgeTest.php

2. NoteTest Kelas NoteTest melakukan uji coba fungsi - fungsi pada kelas model Note. Sama seperti kelas BadgeTest, kelas NoteTest extends terhadap kelas CDbTestCase karena kelas model Note melibatkan active records. Kelas NoteTest memeriksa apakah note yang dimasukkan memiliki format pdf, jpg, atau htm. Selain itu kelas ini juga memeriksa semua fungsi yang terkait dengan note, yaitu fungsi untuk upload note, upload note dengan raw text, upload note dengan invalid input, update note, update note dengan invalid input, delete note, download note, pencarian note, rating note, serta report note. 3. ReviewTest Kelas ReviewTest melakukan uji coba terhadap fungsi - fungsi pada kelas model Review. Kelas ini extends terhadap CDbTestCase. Kelas ReviewTest memeriksa fungsi untuk membuat review dan melakukan uji coba terhadap review yang dibuat dengan input yang salah. Berikut ini merupakan potongan kode ReviewTest.php


6

4. StudentTest Kelas StudentTest melakukan uji coba fungsi - fungsi yang ada dalam model Student. Kelas ini extends CDbTestCase karena melibatkan active records. Kelas StudentTest menguji fungsi update student, update tanpa photo, update student dengan input yang salah, dan fungsi untuk menambahkan badge. 5. TestimonialTest Kelas TestimonialTest melakukan uji coba fungsi - fungsi yang ada dalam model testimonial. Kelas ini extends CDbTestCase karena melibatkan active records. Kelas TestimonialTest menguji fungsi untuk mengecek apakah sistem berhasil untuk “memberi hak” menulis testimonial pada user, apakah seluruh status


7

memiliki representasi string, mengecek apakah status memiliki representasi string yang benar, apakah sistem berhasil menerima testimonial, apakah sistem berhasil menyetujui testimonial atau menolaknya, dan mengecek juga apakah sistem berhasil mengambil testimonial bulan ini. 6. UserIdentityTest Kelas UserIdentityTest melakukan uji coba fungsi - fungsi yang ada dalam model UserIdentity. Kelas ini extends CDbTestCase karena melibatkan active records. Kelas UserIdentityTest menguji fungsi untuk mengecek apakah sistem berhasil login, dan apakah sistem berhasil menjalankan fungsi humanize() dengan baik. 7. CourseTest Kelas CourseTest melakukan uji coba fungsi - fungsi yang ada dalam model Course. Kelas ini extends CDbTestCase karena melibatkan active records. Kelas CourseTest hanya melakukan pengujian apakah data relasi dan fixtures tersedia. Pengujian hanya berkisar pada kemampuan kevalidan active records dalam mengelola relasi. 8. CounterEventHandlerTest Kelas CounterEventHandlerTest melakukan uji coba fungsi - fungsi yang ada dalam komponen CounterEventHandler. Kelas ini extends CDbTestCase karena melibatkan active records. Kelas CounterEventHandlerTest menguji fungsi untuk mengecek apakah sistem berhasil melakukan upload dan download badge dengan benar. Berikut ini potongan source code CounterEventHandler.php


8

9. DownloadEventTest Kelas DownloadEventTest melakukan uji coba fungsi - fungsi yang ada dalam komponen DownloadEvent. Kelas ini extends CTestCase yang berarti bahwa DownloadEventTest

melakukan

unit

testing

secara

general.

Kelas

DownloadEventTest menguji fungsi untuk mengecek apakah sistem berhasil menjalankan fungsi yang berjalan setelah terjadi download dengan benar. Berikut ini source code DownloadEventTest.php

10. UploadEventTest Kelas UploadEventTest melakukan uji coba fungsi - fungsi yang ada dalam komponen UploadEvent. Sama seperti kelas DownloadEventTest, Kelas UploadEventTest extends CTestCase. Kelas UploadEventTest menguji fungsi untuk mengecek apakah sistem berhasil menjalankan fungsi yang berjalan setelah terjadi upload dengan benar. Berikut ini source code kelas UploadEventTest.php


9


10

C. Change Management Tim pengembang sebelumnya telah melakukan alur pengerjaan dengan baik. Tim pengembang sebelumnya menggunakkan issue di Github secara intensif dan branching yang baik. Tim maintenance (kelompok PMPL) akan sedikit menyempurnakan proses dari tim pengembang sebelumnya. Perubahan dalam kode akan dilakukan dalam mekanisme sebagai berikut:

1. Setiap usulan pekerjaan baru, fitur baru, atau laporan bug (selanjutnya disebut issue) harus ditulis di dalam issue tracker. Hal ini untuk memberikan notifikasi kepada seluruh tim dan stackholdernya. Dengan demikian diharapkan seluruh tim dan stackholder dapat bekerja sama dan saling berkolaborasi apa yang sebetulnya terjadi. Contoh kasus hal ini menjadi penting: a. B melaporkan bug Y. Sebetulnya A mengetahui telah ada bug Y, tetapi lupa dilaporkan. Akan tetapi, proses bug reproduction antara A dan B berbeda. Dengan pelaporan ke issue tracker, tim dapat berkolaborasi mengapa reproduction ini berbeda dan apa kira-kira dampaknya. b. C mengusulkan fitur Z. Sebetulnya fitur yang mirip Z sudah pernah dikembangkan, yaitu fitur X. Akan tetapi, berhubung C adalah intern, C tidak


11

menyadari bahwa ternyata sudah ada fitur yang mirip Z, yaitu fitur X. Di sini tim dapat berkolaborasi mengapa C mengusulkan fitur yang sedikit berbeda dari X dan apa dampaknya terhadap proses pengembangan selanjutnya. 2. Tim dipimpin oleh Person-in-charge masing-masing akan mengecek apakah issue tracker tersebut harus dilakukan. Issue dalam kategori berikut tidak akan dikerjakan kecuali dengan pertimbangan lain dari tim: a. Invalid, karena issue tidak sesuai dengan visi dan/atau requirement dari Berkuliah. Jika issue itu bertipe bug, bisa juga berarti bug tersebut tidak dapat direproduksi dengan baik. b. Duplicate, karena issue tersebut sudah pernah dilaporkan c. Wontfix, issue tersebut tidak akan dikerjakan namun dicatat dalam issue tracker. Issue tersebut penting ada dalam issue tracker untuk tim di masa depan. d. Hold, issue tersebut penting namun tidak dipertimbangkan untuk dikerjakan saat ini. Hal ini bisa karena: [1] ada perubahan yang sedang dikerjakan terkait dengan issue tersebut sehingga issue tersebut tidak boleh dilakukan terlebih dahulu, atau [2] ada faktor eksternal yang membuat issue ini terlantar 3. Setelah dipastikan issue tersebut harus dikerjakan saat itu, maka akan ada penugasan ke salah seorang anggota tim untuk mengerjakan issue tersebut. 4. Setelah issue selesai dikerjakan, issue harus dipastikan selesai. Jika itu bug, maka saat melakukan reproduksi, bug tidak terjadi lagi. Jika itu fitur, harus dipastikan bahwa fitur ini berjalan dengan semestinya. Jika ternyata tidak, maka pekerjaan akan diulangi. Dipertimbangkan pula apabila harus dilakukan assignment ke orang yang berbeda. Catatan penting yang lain: 

Jika perubahan ini mengubah alur sistem, maka perlu ada Wiki baru di Collaboration Tools Project2. Setelah itu, harus ada notifikasi dengan mengirimkan surel ke seluruh tim


12



Setiap perubahan terkait kode harus dalam branch yang baru. Tim dari Configuration Management kemudian akan memastikan branch tersebut tidak bermasalah apabila digabungkan dengan branch yang asli.



Perubahan kode terkait dengan konstan rahasia tidak boleh dimasukkan dalam kode. Contoh yang termasuk dalam konstan rahasia adalah kunci API di Facebook dan ID aplikasi di Facebook.

Per tanggal 22 November 2013, perubahan telah dilakukan pada branch features/setup dan features/facebookauth. Perubahan yang dilakukan adalah: 

Pada features/setup dilakukan perubahan untuk menjalankan unit testing dengan PHPUnit tetapi dengan repository Composer. Pengubahan repository ke Compose dilakukan karena pada beberapa komputer pengembang, pemasangan PHPUnit dengan konfigurasi awal (melalui PEAR) cukup bermasalah.



Pada

features/facebookauth

dilakukan

pengubahan

untuk

melakukan

ototentikasi hanya dengan Facebook tanpa SSO UI. Hal ini karena: o

Tim maintenance (kelompok PMPL) tidak mendapatkan akses ke Majapahit untuk deployment sehingga membutuhkan VM baru

o

VM baru ini tidak dapat melakukan ototentikasi dengan SSO UI sehingga membutuhkan metode ototentikasi baru.

Perubahan source code sebelum dan sesudah perubahan oleh tim maintenance terlalu besar sehingga tidak bisa ditampilkan dalam laporan ini. Berikut ini adalah beberapa informasi status dari perubahan source code proyek BerKuliah :


13


14


15

D. Process Area & Maturity Evaluation Berikut process area yang kami pilih beserta langkah kerja dan evaluasinya. 1) Project Monitoring Control Hal-hal yang dilakukan terkait process area ini antara lain: 

Mengawasi kemajuan proyek: Hal-hal yang dikerjakan terkait proyek, testing, bug fixing



Mengawasi kinerja anggota tim



Mengawasi rapat tim



Memastikan kemajuan proyek sesuai dengan perencanaan

2) Measurement and Analysis Hal-hal yang dilakukan terkait process area ini antara lain: 

Memperkirakan cost waktu, biaya, dan manusia dalam membenahi error pada proyek, mengidentifikasi proses perkembangan apa saja yang tim tidak rencanakan (misal mengubah metode login), memperkirakan efek dari pembenahan error pada pengembangan aplikasi.



Menentukan tolak ukur kualitas: Keuntungan yang diperoleh, jumlah error pada keseluruhan code, tren dari kebutuhan pengguna.



Untuk jumlah error, analisis yang dilakukan adalah dengan menimbangnimbang apakah suatu error dapat ditoleransi. Jika ya, dapat diabaikan, selebihnya harus diperbaiki (error foto, error badge)



Mengadakan brain-storming anggota tim yang terkait process area ini, lalu memvalidasi apakah hasil yang didapat dari brain-storming betul-betul perlu dipertimbangkan dan perlu untuk dikomunikasikan pada tim



Mencatat data yang dianggap penting dan yang kurang begitu penting hanya diingat saja oleh anggota tim, untuk menghemat waktu pengerjaan proyek

Evaluasi terkait pelaksanaan process area ini:  Analisis yang seharusnya dilakukan di awal proyek, agak tersendat karena keterbatasan tim dalam faktor waktu, dengan jadwal yang padat. 

Tidak terlalu banyak analisis yang dilakukan, karena proyek ini hanya memperbaiki kualitas sistem Berkuliah.com, sehingga hanya jumlah error saja yang dipertimbangkan, seberapa banyak yang mash bisa ditoleransi dan yang


16

tidak. Anggota tim terkait process area ini hanya satu orang, sehingga sulit menganalisis segala hal-hal yang penting terkait proyek. Namun sebagai gantinya, analisis dilakukan setiap kali diadakan kumpul tim. Segala hasil analisis dicatat. 3) Process and Product Quality Assurance Hal-hal yang dilakukan terkait process area ini antara lain: 

Mengadakan evaluasi secara objektif mengenai proses reporting yang ada



Mengadakan evaluasi work product dari proses yang ada.



Mengkomunikasikan isu-isu yang terjadi terkait kualitas dari aplikasi Berkuliah.com dan mengambil tindakan korektif.



Menyimpan log perkembangan kualitas dari aplikasi Berkuliah.com

4) Configuration Management Process area ini berkaitan dengan integrity dari work product itu sendiri, dengan dilakukannya kegiatan seperti configuration identification, control, status accounting dan audit. Work product yang dihasilkan dari kelompok kami adalah: 

Installation logs



Product data files



Plans



User Stories



Iteration backlogs



Process descriptions

Dalam proses pengerjaan, konfigurasi dan petunjuk harus dijelaskan dalam dokumen. Acuannya adalah sebagai berikut: 

Setiap memasang komponen baru, pastikan dia dapat digunakan tanpa memerlukan konfigurasi tambahan. Jika memerlukan konfigurasi tambahan maka cantumkan dalam format markdown di folder komponen tersebut. Contoh: Lihat pada branch features/setup.



Setiap membuat modul baru, pastikan modul tersebut bisa terintegrasi dengan modul lain tanpa pengubahan basis kode di modul lain. Jika tidak, mohon diskusikan masalah modularitas dengan tim di issue.


17

Satu orang bertanggung jawab atas satu branch di kode. Jika terjadi konflik,



maka tim dari Configuration Management akan mencoba melakukan resolve. Untuk feature request dan pelaporan bug, mohon merujuk pada bagian “Change Management”. 5) Requirement Development Hal-hal yang dilakukan terkait process area ini antara lain: 

Penyusunan requirement produk dan komponen produk, bisa dilakukan pendataan seperti apakah requirement dari produk untuk dianalisa beserta komponen yang dibutuhkan.



Identifikasi UI, dilakukan dengan meninjau bagaimana kondisi UI yang sekarang dan dilakukan identifikasi apa yang harus ditingkatkan atau diperbaiki (bila diperlukan).



Penyusunan fungsionalitas dan quality attributes yang dibutuhkan. Adapun yang disusun disini berupa penyusunan parameter apa saja yang dibutuhkan bagi proyek kami agar dapat dikatakan memilki kualitas yang baik. Tentunya juga dapat memiliki fungsionalitas yang baik.



Analisa Requirement, pada tahapan ini requirement yang sudah dikembangkan perlu dianalisa.

6) Product Integration Berikut adalah hal-hal yang dilakukan terkait process area ini: 

Mempersiapkan integrasi dari komponen produk, meliputi specific practice sebagai berikut : o

Establish an Integration Strategy. Work products : Strategi integrasi komponen-komponen produk.

o

Establish the Product Integration Environment. Work products : Suatu environment untuk integrasi produk, meliputi juga environment terkait proses testing yang akan dilakukan, dokumentasi terkait setting environment untuk integration/testing.

o

Establish Product Integration Procedures and Criteria. Work products : Prosedur dalam pelaksanaan integrasi produk/testing.



Dari komponen-komponen produk yang ada, nantinya akan digabungkan


18

menjadi suatu komponen produk yang lebih besar. Jika dalam melakukan proses ini teridentifikasi suatu masalah, maka masalah tersebut akan dicatat dan akan segera disusun langkah untuk mengatasi masalah tersebut. Berikut adalah specific practice-nya: o

Confirm Readiness of Product Components for Integration. Work products : Acceptance documents terkait komponen produk yang diterima.

o

Assemble Product Components. Work products : Komponen produk kecil yang telah tergabung menjadi satu produk yang lebih besar.

o

Evaluate Assembled Product Components. Work products : Laporan yang berisi summary hasil integrasi produk.

o

Deliver the Product. Work products : Delivery documentation.

7) Verification Pada proses area ini kelompok kami memastikan bahwa work product yang ada sesuai dengan requirement sesuai definisi verification pada CMMI Dev. Hal yang terkait dengan process area ini adalah sebagai berikut: 

Melakukan peer review, pada tahap ini, adapun kegiatannya berupa inspeksi/walktrough (bersumber dari slide PMPL). Sebelumnya dihasilkan schedule untuk mempermudah kegiatan review, setelah dilakukan peer review maka dihasilkan peer review results, issues dan data.



Hasil data peer review sebelumnya bisa dilakukan analisis lebih mendalam untuk memastikan bahwa work product sesuai dengan requirement. Keluarannya berupa hasil analisis dari verification itu sendiri.

8) Validation Berikut hal-hal dilakukan terkait process area ini: 

Selecting Product Component and Selecting Validation Method. Adapun komponen yang akan divalidasi adalah: 1.

Operational Sistem (Fitur)

2.

User Manual

3.

Sistem Requirements

Adapun metode validasi yang dilakukan:


19



1.

Mendemokan operasional sistem

2.

Berdiskusi dengan end-user

3.

Test product component by end user

Establish the Validation Environment. Proses Validasi yang akan dilakukan dirasakan tidak perlu menggunakan suatu establish validation environtment. Karena sistem Berkuliah adalah berbasis web, maka untuk proses validasi yang bagian fungsionalitas operasional membutuhkan koneksi internet yang stabil dan PC yang memenuhi spesifikasi dari sistem Berkuliah.



Establish Validation Procedures and Criteria 1. Mereview dokumen UAT 2 dan melakukan penyesuaian isi dokumen agar sesuai dengan perubahan-perubahan requirement yang dilakukan. Dokumen ini yang akan menjadi validation criteria untuk operational validation. 2. Mereview dokumen Software Requirements Specification. 3. Mereview dokumen Software Architecture Design

2.1 Perform Validation 1. Mengidentifikasi requirements yang akan divalidasi. 2. Mereview requirements untuk memastikan perencanaan validasi yang akan dilakukan telah memenuhi. 3. Operational demonstration 4. User Manual Review 5. Membandingkan hasil review dengan hasil yang diharapkan. 2.2 Analyze Validation Results 1. Membandingkan hasil review dengan hasil yang diharapkan. 2. Identifikasi hasil validasi. 3. Membuat laporan hasil validasi 4. Identifikasi kegagalan validasi dan mengumpulkan informasi untuk penyelesaian. 9) Risk Management Berikut hal-hal yang dilakukan terkait process area ini.


20



Risk Assessment Mengidentifikasi kemungkinan resiko yang muncul dan apa akibat yang akan ditimbulkan serta menentukan probabilitas kemunculan resiko tersebut.



Risk Mitigation Plan Menentukan response atau pencegahan terhadap resiko yang telah diidentifikasi pada Risk Assesment.

10)Organizational Process Devinition Process area ini secara umum bertujuan untuk memastikan proses kerja dalam tim berjalan dengan baik, teratur, dan terorganisir. Beberapa hal yang dilakukan untuk memenuhi tujuan tersebut adalah: 

Menetukan rules dan guidelines untuk setiap pekerjaan dalam tim Menentukan suatu pekerjaan akan di-assign ke siapa, kapan pekerjaan tersebut harus selesai, bagaimana pekerjaan seharusnya dilakukan, dan sebagainya, pada setiap rapat tim. Semua hal ini didokumentasikan dalam notulensi.



Mengorganisir aset-aset proyek Memastikan aset-aset proyek seperti dokumen atau kumpulan code proyek available saat diperlukan. Hal ini termasuk juga mengatur dan mengorganisir semua aset tersebut agar lebih mudah dicari. Hal lain yang juga dilakukan adalah merapikan dan merevisi dokumen-dokumen yang ada agar lebih teratur dan lebih mudah dipahami.

Beberapa evaluasi terkait process area ini adalah: 

Rules dan guidelines pada notulensi tidak dibuat terlalu mendetail, hanya dibuat secara umum saja.



Belum dapat benar-benar memastikan setiap pekerjaan yang dilakukan dalam proyek selesai tepat waktu, hal ini terjadi karena penetapan deadline yang kurang tegas, akibatnya beberapa pekerjaan tidak selesai sesuai timeline yang telah ditentukan.

11)Organizational Process Performance Dalam tim kami, untuk menentukan dan menjaga pemahaman kuantitatif dari kinerja tim, aktivitas yang dilakukan organisasi dalam meningkatkan mutu


21

perangkat lunak berkuliah.com adalah: 1.

Menentukan tujuan umum dari peningkatan mutu berkuliah.com. Pada proses menentukan tujuan umum ini, yang dilakukan kelompok adalah melakukan rapat dan diskusi bersama. Pada akhirnya disepakati bahwa tujuan dalam meningkatkan mutu perangkat lunak terdapat dua tujuan, yaitu pertama melakukan bug fixing pada saat mengunggah foto, dan badge download, dan kedua melakukan improvement dengan melakukan preview document secara langsung, selanjutnya untuk link suatu document dibuat juga di icon document dan tidak hanya di judul document, dan yang terakhir pada saat mengakses berkuliah.com akan langsung teralih ke SSO, tanpa perlu ada coming soon message. Selanjutnya tim kami berencana untuk menambahkan fitur-fitur baru seperti sorting tampilan document, dan pemberian privillege pada admin.

2.

Memilih 11 process area masing-masing anggota. Process area yang dipilih terdiri dari a. Project Monitoring and Control b. Measurement and Analysis c. Process and Product Quality Assurance d. Configuration Management e. Requirements Development f. Product Integration g. Verification h. Validation i. Risk Management j. Organizational Process Definition i. Organizational Process Performance

3.

Menentukan perhitungan parameter keberhasilan terkait kinerja dari proses yg dipilih. Setelah melakukan analisis, maka untuk keberhasilan aktivitas peningkatan mutu ini sebagai perhitungan parameter keberhasilannya adalah para anggota tim melakukan unit testing pada setiap kelas yang ada pada berkuliah.com dan juga melakukan bug fixing pada masalah yang sudah


22

disepakati sebelumnya. Dalam menentukan parameter keberhasilan, process area yang berkaitan dengan proses ini adalah pada measurement and analysis. Analisis yang dilakukan adalah hal-hal yang terkait error, value yang didapatkan, dan cost. Silahkan menuju bagian process area measurement and analysis untuk penjelasan lebih lanjut. 4.

Baseline adalah data tentang proses saat ini yang menyediakan metrik patokan untuk mengukur perbaikan dan untuk digunakan dalam pembandingan.

Matriks

perhitungan

yang

dilakukan

tim

adalah

perbandingan kualitas berkuliah.com setelah bug fixing dan juga unit testing. Hasilnya akan dibandingkan dengan perhitungan sebelum bug fixing dan unit testing dilakukan. 5.

Saat ini terdapat dua bidang minat yang dicakup oleh model CMMI: development (pengembangan) dan acquisition (akuisisi). Aktivitas ini akan melakukan pengembangan dalam peningkatan mutu perangkat lunak sehingga ,ode yang digunakan adalah CMMI-DEV (CMMI for Development)

Pada akhirnya, tim kami berfokus pada permasalahan penyelesaian bug fixing dan unit testing. Hal ini dilakukan dengan pertimbangan dari prioritas yang paling mendesak untuk meningkatkan kualitas berkuliah.com. Adapun alasan process area tersebut relevan dengan proyek kami tertulis sebagai berikut. 1. Project Monitoring and Control Setiap proyek hendaknya di-manage dengan sebaik mungkin. Dengan memperhatikan process area ini, diharapkan jalannya proyek dapat dimonitor dan dikontrol sehingga sesuai dengan perencanaan yang ditetapkan sebelum proyek dimulai. Anggota tim yang bertanggungjawab atas process area ini diharapkan mengetahui dan memahami bagaimana perkembangan jalannya proyek, sehingga dapat menentukan CAPA yang sesuai dengan kondisi dan situasi yang dihadapi oleh tim. 2. Measurement and Analysis


23

Kegiatan Measurement and analysis ini memiliki cakupan pembahasan seperti dalam bidang organisasi, kebutuhan, business objectives dan lain sebagainya. Kegiatan utamanya adalah menyediakan informasi yang dibutuhkan oleh bisnis, organisasi dan pengerjaan proyek. Adapun hal ini dipergunakan dalam rencana development selanjutnya dan direalisasikan. 3. Process and Product Quality Assurance Proses area ini sangat diperlukan dengan alasannya adalah perlunya dilakukan quality assurance dari software agar software yang di deliver memiliki kualitas yang baik. Adapun kegiatan yang tercakup dalam process area ini adalah sebagai berikut: formal audit, peer reviews dan lain sebagainya. Kegiatan ini akan sangat baik jika telah dilakukan planning dengan baik. 4. Configuration Management Configuration Management memiliki peranan dalam melakukan integrasi pada setiap work product yang dihasilkan seperti: compiler, test tools, plans, user story, requirements dan lain-lainnya. Tanpa adanya CM ini, kegiatan intergrasi dan manajemen tidak dapat berjalan dengan lancar. 5. Requirements Development Dalam mendapatkan software yang berkualitas, terkadang perlu dilakukan pengembangan requierement. Hal ini dilakukan karena tidak semua user bisa menyatakan requirement software dengan baik dan dirasa perlu dilakukan development pada requirement tersebut, agar software yang dihasilkan memilki kualitas yang baik. Oleh karenanya, process area Requirements Development ini sangat diperlukan dalam pengembangan dan kegiatan testing proyek yang dilakukan kelompok kami. 6. Product Integration Proyek ini dibangun dalam beberapa modul, dimana masing-masing modul memiliki fungsinya sendiri-sendiri. Process area ini kami perhatikan karena perlu adanya integrasi yang baik agar modul-modul yang ada dapat bekerja membentuk satu fungsionalitas yang utuh. Selain itu, integrasi fungsi-fungsi tambahan juga harus aman, dengan kata lain tidak mengganggu performa dari modul-modul yang telah ada sebelumnya.


24

Diperlukan seseorang yang memperhatikan komunikasi antar modul, seperti apa kondisinya setiap kali penambahan fungsi. Dengan begitu, ketika terjadi suatu hal yang diinginkan, dapat diambil suatu Corrective Action yang sesuai. 7. Verification Suatu sistem harus dipastikan apakah pengembangannya masih sesuai dengan requirement yang disusun pada sebelum proyek dimulai. Berbagai aktivitas perlu dilakukan untuk mencapai hal tersebut, misalkan peer review dan path coverage testing. 8. Validation Dalam melakukan pembuatan software, validasi perlu dilakukan dalam rangka menjamin kita melakukan kegiatan yang didasari kata “we build the right thing”. Kegiatan validasi bisa dilakukan dengan testing, analisis, inspeksi, demo dan simulasi. 9. Risk Management Risk Management penting dilakukan dalam mengerjakan sebuah proyek, mengingat resiko dalam pengerjaan proyek pasti terjadi. Untuk menghindari terjadinya imbas resiko berlebih, maka dari itu perlu dilakukan manajemen terhadapnya. 10. Organizational Process Definition Process area ini diperlukan untuk memastikan kerja tim berjalan teratur dan terorganisir. Hal-hal yang dapat dilakukan untuk mencapai tujuan tersebut antara lain membuat rules dan guidelines terkait pekerjaan yang harus dilakukan dan mengorganisir aset-aset proyek. 11. Organizational Process Performance Process area ini diperlukan untuk menentukan dan menjaga pemahaman kuantitatif dari kinerja process area yg dipilih oleh organisasi dalam meningkatkan mutu perangkat lunak berkuliah. Hal-hal yang dilakukan untuk memenuhi tujuan tersebut seperti menentukan tujuan umum dari peningkatan mutu Berkuliah, memilih 11 process area untuk masing-masing anggota, dan menentukan perhitungan parameter keberhasilan terkait kinerja dari proses yg dipilih.


25

E. Work Contribution Sebelum memulai pengembangan proyek BerKuliah, kami melakukan risk assesment dan menyusun risk mitigation plan terlebih dahulu. Sejauh ini proyek Berkuliah yang dikerjakan oleh kelompok kami sudah hampir menyelesaikan sprint pertama. Adapun sprint pertama yang kami lakukan adalah melakukan bugs fixing. Langkah awal yang dilakukan adalah melakukan validasi terhadap sistem yang ada sebelum dilakukan improvement. Adapun proses validasi dilakuakan fokus pada opersional atau fungsionalitas sistem terkait denga requirement sistem sebelumnya. Hal tersebut dilakukan untuk mengantisipasi error-error atau bug yang mungkin ada dan belum ditemukan sebelumnya. Adapun error/bug yang ada adalah sebagai berikut: 1. Error ketika share on Facebook 2. Error badge 3. Error Tambah Mata Kuliah. 4. Error Foto Profil Adapun permasalahan yang ada juga terkait dengan hak akses ke sistem deployment Berkuliah yang sebelumnya di server UI, sedangkan kelompok kami tidak memiliki hak akses ke server tersebut sehingga kami memutuskan untuk melakukan deployment ke server sendiri. Permasalahan lain muncul terkait dengan use case login yang menggunakan SSO yang tidak dapat dilakukan karena pemindahan deployment server tersebut. Akhirnya kami memutuskan untuk melakukan perubahan terhadap use case login yakni dengan menggunakan login Facebook. Oleh karena itu kami telah melakukan revisi terhadap dokumen software requirement specification (SRS) dan dokumen software architecture design (SAD). Sampai pada tahap ini, beberapa error sudah berhasil diidentifikasi dan diperbaiki. Untuk fitur tambah mata kuliah ternyata hanya dijumpai di sistem yang ada di http://majapahit.cs.ui.ac.id/berkuliah. Ternyata ada perbedaan versi kode antara yang ada di http://majapahit.cs.ui.ac.id/berkuliah dengan kode program yang ada di github. Akhirnya kelompok kami memutuskan untuk menggunakan


26

kode yang ada di github. Begitu juga untuk error melihat foto profil orang lain, hanya dijumpai pada sistem yang ada di http://majapahit.cs.ui.ac.id/berkuliah. Untuk development, sebagaimana kami telah jelaskan di “Changes Management”: Kami menggunakkan VM yang dapat diakses di http://162.243.144.83/ karena kami tidak dapat melakukan deployment ke Majapahit. Karena server ini adalah server deployment, bug akan banyak ditemui di sini. (Untuk versi stable awal, lihat versi di Majapahit) Kami juga telah melakukan dua buah metode testing terhadap program Berkuliah, yaitu Unit Testing dan Code Coverage Testing. Unit testing dilakukan dengan menggunakan PHPUnit sedangkan Code Coverage Testing dilakukan menggunakan XDebug. Dua buah metode testing tersebut dilakukan untuk menjamin correctness dan mencegah adanya error/bugs pada program. Berikut summary log dari kelompok kami, summary log ini diambil dari http://projects2.ui.ac.id/


27


28


29

F. Appendices 1. Perubahan SRS (Software Requirement Specification) 2. Perubahan UCS (Use Case Specification) 3. Perubahan SAD (Software Architecture Document) 4. Risk Assessment 5. Risk Mitigation Plan 6. Hasil Unit Testing 7. User Story untuk Sprint 2


30

Perubahan Software Requirements Specification Berkuliah

Anggota Kelompok: 1006665946 - Ahmad Fanani 1006665952 - Anang Ferdi Kusuma 1006671204 - Ardhian Prabantoro 1006665971 - Argianto Rahartomo 1006665990 - Dimas Agung Saputra 1006671375 - Erryan Sazany 1006666293 - Febriana Misdianti 1006671690 - Mohammad. Fajarrizky A 1006671740 - Muhammad Iqbal 1006671766 - Muhammad Mufid Afif 1006770753 - Niken Paramita

DOCUMENT HISTORY

Version 1.0

Revision Notes Create Document

Author Berkuliah Group

Approved By Ahmad Fanani

Date 15 Nov 2013

Perubahan Software Requirements Specification 1.

Introduction Dokumen Perubahan Software Requirements Spesification (SRS) merupakan dokumen yang menjelaskan perubahan requirement yang dilakukan. Adapun dokumen ini nantinya akan digabungkan dengan dokumen SRS yang lengkap. Dokumen ini dibuat dengan tujuan sebagai laporan perkembangan pengerjaan proyek.

2.

Perubahan dan /atau Penambahan Use-case: 1. Login adalah kegiatan autentikasi menggunakan CAS JUITA agar aktor pengguna umum dapat masuk ke dalam sistem dan berubah peran menjadi aktor pengguna. diubah menjadi: adalah kegiatan autentikasi menggunakan akun Facebook agar aktor pengguna umum dapat masuk ke dalam sistem dan berubah peran menjadi aktor pengguna. Alasan: Berkuliah awalnya dideploy di server UI. Namun, karena kelompok kami mengalami keterbatasan hak ases untuk dapat melakukan pengembangan di server UI, Maka kami memutuskan untuk menggunakan server sendiri selama proses pengembangan agar lebih mudah. Sehingga alternatif informasi login yang digunakan adalah akun Facebook dengan pertimbangan Facebook sudah sangat popular dikalangan mahasiswa. 2. Melihat isi berkas adalah kegiatan pengguna untuk dapat menampilkan isi suatu dokumen secara langsung di browser.

3.

Perubahan Use Case Diagram:

Perubahan Use Case Specification Berkuliah


DOCUMENT HISTORY Version 1.0

Revision Notes Create Document

Author Berkuliah Group

Approved By Ahmad Fanani

Date 16 Nov 2013

Use Case Specification: Login 1. Login 1.1 Brief Description

Use case ini menjelaskan kegiatan pengguna untuk dapat masuk ke dalam sistem Berkuliah. Aktor yang dapat melakukan use case ini adalah pengguna umum. Pengguna dikatakan berhasil melakukan login apabila pengguna mendapatkan hak akses untuk masuk ke dalam sistem.

2. Flow of Events 2.1 Basic Flow

Actor Action

System Response

Social Media API

1. Pengguna memilih pilihan ‘Login dengan Facebook’ 2. Mengarahkan request login ke API Facebook 3. Mengecek apakah pengguna sudah memberikan permission terhadap aplikasi berkuliah 4. Memberikan otorisasi akses 5. Memberikan pesan bahwa login berhasil dilakukan

2.2 Alternative Flows

2.2.1 Pengguna belum memberikan permission terhadap apikasi berkuliah (Alternative Flow langkah 3) Jika pengguna belum memberikan permission terhadap aplikasi Berkuliah maka sistem akan menampilkan window baru untuk memberikan permission terhadap aplikasi Berkuliah. 2.2.2 Pengguna tidak memiliki login session Facebook (Alternative Flow Langkah 3) Pada langkah 3, apabila pengguna tidak memiliki login session Facebook, maka akan muncul window yang berisi form isian untuk login ke Facebook.

3. Special Requirements Tidak ada.

4. Pre-Conditions 4.1 Aktor memiliki login session di Facebook Aktor sudah login ke Facebook.

5. Post-Conditions 5.1 Masuk ke Sistem Apabila use case ini berhasil, maka pengguna dapat memiliki hak akses ke sistem Berkuliah.

6. Extension Points Tidak ada.

Use Case Specification: Melihat Isi Berkas 1. Melihat Isi Berkas 1.1 Brief Description

Use case ini menjelaskan tentang kegiatan pengguna dalam melihat isi (preview) berkas yang ada di sistem Berkuliah secara langsung di browser tanpa perlu mendownload terlebih dahulu. Aktor yang dapat melakukan use case ini adalah pengguna dan administrator.

2. Flow of Events 2.1 Basic Flow Actor Action

System Response

1. Pengguna memilih tautan berkas dari daftar berkas milik pengguna atau dari daftar hasil pencarian berkas. 2. Sistem menampilkan isi berkas

2.2 Alternative Flows Tidak ada.

3. Special Requirements Browser pengguna harus mendukung untuk dapat mem-preview file PDF.

4. Pre-Conditions 4.1 Sign in Pengguna harus terlebih dahulu sign in ke sistem Berkuliah

5. Post-Conditions Tidak ada.

6. Extension Points 6.1 Mendownload Berkas Pengguna dapat menyimpan berkas yang sedang dilihat.

Perubahan Software Architecture Document Berkuliah


DOCUMENT HISTORY

Version

Revision Notes

Author

Approved By

Date

1.0

Create Document

Berkuliah Group

Ahmad Fanani

17 Nov 2013

Software Architecture Document 1. Introduction Software Architecture Document (SAD) merupakan dokumen yang memberikan penjelasan mengenai arsitektur dari sistem Berkuliah. Dokumen ini berisi penjelasan mengenai beberapa hal yang berhubungan dengan perubahan arsitektur dari sistem Berkuliah. Adapun dokumen ini nantinya akan digabungkan dengan dokumen SRS yang lengkap. Dokumen ini dibuat dengan tujuan sebagai laporan perkembangan pengerjaan proyek.

2. Use-Case View 2.1 Use-Case Realizations (Design Use Case) No

Nama Use Case

1

Melihat Isi Berkas

Hasil Use Case Realization

3. Logical View 3.1 Sequence Diagram (for each design use case

3.1.1 Login

3.1.2 Melihat Isi Berkas

6. Process View 6.1 Activity Diagram 6.1.1 Login

6.1.2 Melihat Isi Berkas

RISK ASSESSMENT Risk Identification and Qualification Rank

Potential Risk

Probability

1.

Setiap anggota proyek BerKuliah kesulitan dalam menentukan waktu untuk meeting dikarenakan jadwal

70%

yang berbeda – beda. 2.

Adanya kemungkinan deadline tugas mata kuliah lain yang mengganggu jadwal pengerjaan proyek BerKuliah.

3.

Pengembangan proyek BerKuliah mengalami kesulitan teknis sehingga keluar dari jadwal.

4.

60% 40%

Adanya kemungkinan metode pengembangan proyek BerKuliah

tidak

dijalankan

dengan

benar

karena

kurangnya pemahaman anggota tim proyek terhadap

25%

metode yang digunakan. 5.

Deliverables yang dihasilkan tidak sesuai dengan rencana awal. Rencana awal dari proyek BerKuliah adalah menghilangkan software fault dan software failure serta melakukan improvement terhadap fitur yang sudah ada.

15%

Improvement fitur didiskusikan oleh tim BerKuliah pada awal penyusunan story. 6.

Adanya

kemungkinan

anggota

tim

yang

tidak

bertanggung jawab atau meninggalkan tim sehingga

10%

mengganggu jalannya proyek. 7.

Adanya kemungkinan pembagian pekerjaan yang tidak tepat sasaran sehingga menyebabkan pekerjaan tersebut tidak memiliki hasil optimal.

10%

RISK MITIGATION PLAN Risk Response and Development Rank 1.

Risk Response ( Preventive / Responsive) Membentuk forum online di Facebook dan Whatsapp Mobile untuk menjaga kualitas komunikasi anggota. Selain itu, tim BerKuliah juga memanfaatkan teknologi cloud untuk menyimpan dan melaporkan hasil pekerjaan, yaitu dengan Google Docs, Google Presentation, Dropbox, GitHub, serta Redmine.

2.

Menyusun prioritas atas tugas yang memiliki deadline yang bersamaan. Setiap anggota tim pasti memiliki prioritas masing – masing. Mulai mengerjakan proyek BerKuliah sejak awal sedemikian hingga dapat dipastikan tugas yang berkaitan dengan proyek BerKuliah selesai tepat waktu.

3.

Adanya monitoring terhadap perkembangan proyek BerKuliah sehingga dapat mendeteksi resiko 3 lebih dini. Kemudian memfasilitasi training kepada seluruh anggota tim atau anggota tim yang bersangkutan terkait dengan pengetahuan teknis yang diperlukan.

4.

Melakukan sosialisasi tentang metode pengembangan proyek BerKuliah yang dikerjakan dan memastikan semua anggota kelompok memahaminya. Proses sosialisasi ini juga dibantu dengan dosen dan asisten dosen.

5.

Adanya monitoring terhadap perkembangan proyek BerKuliah. Selain itu, tim berkuliah juga melakukan verifikasi dan validasi dari setiap tugas yang telah selesai dikerjakan.

6.

Memberikan peringatan kepada anggota tim yang bersangkutan serta tidak memberikan pekerjaan yang mempunyai dependensi tinggi terhadap anggota tersebut. Proyek BerKuliah harus tetap berjalan lancar.

7.

Adanya monitoring, validasi, dan verifikasi terhadap perkembangan proyek BerKuliah.

HASIL UNIT TESTING

Sebelum

Sesudah

USER STORY FOR SPRINT 2 No

User Story

Estimation

1

Sistem dapat memberikan fitur set privilege terhadap 5 catatan yang akan di publikasikan.

2

Sistem dapat membuat taksonomi (hirarki tag, misal: 8 username, tanggal pembuatan, judul, kategori mata kuliah, etc) dari satu dokumen

3

Sistem dapat membuat weighting untuk taksonomi suatu 8 dokumen

4

Sistem dapat memetakan taksonomi keterkaitannya dengan suatu taksonomi

5

Sistem dapat melihat keterkaitan suatu taksonomi dengan 8 kategori lainnya

6

Sistem dapat merekomendasikan catatan mata kuliah dari 8 keterkaitan taksonomi dari mata kuliah tersebut

7

Melakukan setup environment secara otomatis (Sistem 5 harus dapat dengan mudah disetup oleh para developer).

8

Membuat automatic deployer ke server (Sistem harus 5 dapat dengan mudah di-deploy ke server oleh para developer).

9

Sistem dapat menampilkan jumlah user unik yang telah 2 mengunduh catatan.

dan

melihat 8

DRAFT REPORT & DELIVERABLES

Recommend Documents