Rangkuman Rekayasa Perangkat Lunak

 

Rangkuman RPL

Pertemuan 1

“Beragam Alasan  Penggunaan Rekayasa Perangkat Lunak Dan Perangkat Lunak” 

1. Semua negara maju ekonominya bergantung pada perangkat lunak (pl)
2. Makin banyak sistem yang dikendalikan oleh pl
3. Rpl berkaitan dengan teori, metode dan alat untuk pembangunan pl secara profesional.
4. Pengeluaran dana untuk pl di negara maju sangat besar.
5. Harga pl sering lebih mendominasi harga sistem komputer. Harga pl pada pc sering lebih mahal dari pada harga perangkat kerasnya.
6. Biaya pemeliharaan pl lebih mahal dibanding biaya pembuatannya.
7. Rpl berkaitan dengan biaya efektif pembuatan pl.

Perangkat Lunak :

1. Program komputer dan dokumentasi yang berkaitan seperti dokumen kebutuhan, rancangan, dan user manual.
2. Produk pl bisa dibangun untuk pengguna khusus atau umum:

• Generic – dibangun untuk dijual ke pengguna yang berbeda-beda – misalnya pl untuk pc seperti excel atau word.
• Bespoke (custom) – untuk pengguna khusus/pemesan sesuai kebutuhannya.

1. Pl baru bisa dibuat dengan membangun program baru, konfigurasi sistem pl atau gunakan lagi (reuse) program yang sudah ada.

Rekayasa Perangkat Lunak

1. Disiplin ilmu rekayasa atau teknik yang berkaitan dengan semua aspek dalam membuat pl
2. Rpl harus mengikuti pendekatan yang sistematis dan teratur dan menggunakan alat dan teknik yang cocok sesuai dengan masalah yang akan dipecahkan, batasan pembangunan dan sesumber yang tersedia

Software Process :

1. Serangkaian aktifitas yang tujuannya adalah pembangunan atau evolusi pl
2. Aktifitas umum dalam semua proses pl :

• Spesifikasi – apa yang dilakukan sistem dan batasan pembangunan
• Pembangunan- produksi dari sistem pl
• Validasi – pemeriksaan apakah pl sesuai dengan permintaan pemesan
• Evolusi – mengubah pl untuk menyesuaikan perubahan permintaan.

Software Process Model :

Gambaran sederhana dari proses pl, berdasarkan pandangan tertentu.

Contoh :

• Workflow – aktivitas yang berurutan;
• Data-flow – arus informasi;
• Role/action – siapa melakukan apa.
• Model process, contohnya
  • Waterfall;
  • Iterative development;
  • Component-based software engineering.

Biaya rpl :

1. Secara kasar 60% dari biaya untuk pembangunan dan 40% untuk pengujian. Untuk pl custom, biaya evolusi sering melebihi biaya pembangunan..
2. Biaya bervariasi tergantung pada tipe sistem yang dibangun dan kebutuhan sistem seperti kinerja dan kehandalan sistem.
3. Distribusi biaya bergantung pada model pembangunan yang digunakan.

Penyebab permasalahan etika dalam sistem informasi :

1. Pengaruh ti yang mendalam à kehidupan manusia yang terkait dengan etika;
2. Manajer yang menentukan penerapan ti ke organisasi à bertanggungjawab permasalahan etika.

Permasalahan etika dalam lingkungan sistem informasi :

1. Privacy
2. Intelectual property right;
3. Penghentian kerja;
4. Security;
5. Accuracy and health

Privacy :

1. Tuntutan seseorang untuk tidak dicampuri, diawasi/diganggu oleh orang-lain / organisasi maupun negara.
2. Tuntutan privacy seseorang dilindungi oleh beberapa undang-undang di beberapa negara.

 

Pertemuan 2

“Software Process Model”

 

Linear sequential model / waterfall model :

Model klasik yang bersifat sistematis, berurutan dalam membangun software.

Requirements analysis and definition :

–     Mengumpulkan kebutuhan secara lengkap;

–     Dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh program yang akan dibangun.

–     Fase ini dilaksanakan secara lengkap à menghasilkan desain yang lengkap.

System and software design :

Desain dikerjakan setelah kebutuhan selesai dikumpulkan secara lengkap.

Implementation and unit testing :

–     Desain program diterjemahkan ke dalam kode-kode dengan menggunakan bahasa pemrograman yang sudah ditentukan.

–     Program yang dibangun langsung diuji secara unit.

Integration and system testing :

Penyatuan unit-unit program kemudian diuji secara keseluruhan (system testing).

Operation and maintenance :

Mengoperasikan program dilingkungannya dan melakukan pemeliharaan, seperti penyesuaian atau perubahan karena adaptasi dengan situasi sebenarnya.

Evolutionary software process models :

–     Bersifat iteratif / mengandung perulangan.

–     Hasil proses berupa produk yang makin lama makin lengkap sampai versi terlengkap à produk akhir dari proses.

Model proses software:

–     Incremental model (original: mills)

–     Spiral model (original: boehm)

Rad (Rapid Application Development) :

1. Model proses pembangunan pl yang incremental.
2. Menekankan pada siklus pembangunan yang pendek/singkat.
3. Mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction.
4. Waktu yang singkat adalah batasan yang penting untuk model ini.

 

Pertemuan 3

“PERENCANAAN PROYEK PERANGKAT LUNAK” 

Prototyping Model

Kadang-kadang klien hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output. Di lain waktu mungkin dimana tim pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form user interface. Ketika situasi seperti ini terjadi model prototyping sangat membantu proses pembangunan software.

Proses pada model prototyping yang digambarkan pada gambar 1, bisa dijelaskan sebagai berikut:

• pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan
• perancangan : perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype.
• Evaluasi prototype: klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.

Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan terpenuhi. Prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk memahami kebutuhan klien lebih baik.

Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa dimanfaatkan.

Sekalipun prototype memudahkan komunikasi antar developer dan klien, membuat klien mendapat gambaran awal dari prototype , membantu mendapatkan kebutuhan detil lebih baik namun demikian prototype juga menimbulkan masalah:

• Dalam membuat prototype banyak hal yang diabaikan seperti efisiensi, kualitas, kemudahan dipelihara/dikembangkan, dan kecocokan dengan lingkungan yang sebenarnya. Jika klien merasa cocok dengan prototype yang disajikan dan berkeras terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya.
• Developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak sesuai, bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana.

Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software.

Pertemuan 4

“KONSEP DAN PRINSIP ANALISIS”

Manajemen Proyek Perangkat Lunak

Pengantar

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:

• manajer senior : yang menentukan usaha yang dikerjakan, dan pemegang keputusan dalam proyek.
• manajer proyek (teknis)– pemimpin tim: yang membuat rencana, memotivasi, mengatur dan mengendalikan praktisi yang mengerjakan PL
• praktisi : yang mengerjakan PL
• klien : yang menentukan kebutuhan PL dan pihak lain yang berkaitan dengan hasil produk
• 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.

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 m < 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:

• 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,
• 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
• 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

 

Pertemuan 5

“PEMODELAN ANALISIS”

Software Quality Assurance

Pengantar

Software Quality Assurance (SQA) meliputi pendekatan manajemen kualitas, teknologi software engineering yang efektif, pertemuan peninjauan teknis selama proses software berlangsung, strategi pengujian bertingkat, mengendalikan dokumentasi software dan perubahan yang terjadi, prosedur untuk memastikan kesesuaian dengan standar pembangunan software (jika ada standar yang digunakan) mekanisme pelaporan dan mengukuran.

Pembahasan kita berfokus pada masalah manajemen dan aktifitas proses khusus yang memastikan bahwa pembangunan software dilakukan secara benar, memenuhi kriteria yang sebenarnya, dan pada waktu yang tepat.

Definisi-definisi

Software Quality didefinisikan sebagai : kesesuaian yang diharapkan pada semua software yang dibangun dalam hal fungsi software yang diutarakan dan unjuk kerja software, standar pembangunan software yang terdokumentasi dan karakteristik yang ditunjukkan oleh software. Definisi ini menekankan pada 3 hal yaitu:

1. kebutuhan software adalah fondasi ukuran kualitas software, jika software tidak sesuai dengan kebutuhan yang ditentukan maka kualitaspun kurang

2. jika menggunakan suatu standar untuk pembangunan software maka jika software tidak memenuhi standar tersebut maka dianggap kurang berkualitas

3. sering kali ada kualitas yang secara langsung diutarakan (tersirat) seperti kemudahan penggunaan dan pemeliharaan yang baik. Kualitas software dipertanyakan jika tidak memenuhi kebutuhan ini.

SQA merupakan perluasan dari definisi di atas. SQA adalah serangkaian aktifitas yang sistematik dan terencana dalam rangka memastikan kualitas dari software.

Grup SQA adalah sekumpulan orang-orang yang menjalankan aktifitas-aktifitas SQA. Mereka bertindak selaku wakil dari klien, yaitu dengan melihat dan memeriksa software dari sudut pandang klien.

SQA terdiri dari berbagai macam aktifitas yang berhubungan dengan dua kelompok kepentingan yaitu:

1. praktisi pembangun software yang mengerjakan pekerjaan teknik à menerapkan metode dan pengukuran yang tepat, melakukan rapat teknis, dan menguji software

2. grup SQA yang bertanggung jawab terhadap perencanaan jaminan kualitas, pencatatan, analysis dan pelaporan.

Aktifitas SQA

Grup SQA melakukan serangkaian aktifitas untuk membantu tim praktisi pembangun software dalam menghasilkan produk yang berkualitas tinggi. Aktifitas-aktifitas tersebut adalah :

1. Rencana SQA untuk suatu proyek. Dibuat selama merencanakan proyek dan diperiksa oleh semua pihak. Rencana menentukan cara evaluasi, cara audit dan review, standar yang akan digunakan, proses untuk error tracking dan pelaporannya, dokumen yang akan dibuat grup SQA.

2. Ikut membuat gambaran software proses yang akan digunakan untuk membangun software.

3. review aktifitas software engineering untuk memastikan kesesuaian dengan software proses yang ditentukan

4. melakukan audit hasil kerja software

5. memastikan penyimpangan yang terjadi dalam kerja software dan hasil kerja terdokumentasi dan diatasi sesuai dengan prosedure

6. mencatat ketidak-sesuaian dan melaporkannya ke manajer senior

 

Pertemuan 6

“SOFTWARE REQUIREMENT”

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.

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 layanan-layanan dan batasan tersebut disebut Requirement Engineering.

Pengumpulan requirement

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

Beberapa macam requirement :

• 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.

• 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.

• A software design specification (spesifikasi rancangan PL)

Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil.

 

Pertemuan 7

Konsep Desain Software

Analisis dan desain model

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 masingmasing.

DFD memberi gambaran bagaimana data berubah sejalan dengan alirannya dalam sistem dan menggambarkan fungsi-fungsi yang mengubah datadata 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 4 sebelah kanan menjadi bekal pada proses desain pada piramida model desain pada sebelah kiri gambar 4.

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 structural utama, pola desain yang digunakan untuk mencapai kebutuhan yang ditentukan untuk sistem dan batasan-batasan yang mempengaruhi bagaimana desain arsitektural ini diterapkan.

Konsep desain

1. abstraction

Abstraction adalah gambaran dari fungsi suatu program. Gambaran ini bias 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.

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 5.

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.

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

Repository Model

Pada model ini data disimpan secara terpusat untuk semua sub-sistem. Contoh : CASE Toolset, sistem informasi perpustakaan UKDW.

Contoh : sistem informasi perpustakaan UKDW, sistem registrasi akademik UKDW

 

Client-Server Model

Model ini terdiri dari sekumpulan server yang berdiri sendiri dan masing-masing menyediakan layanan untuk sub-sistem. Ada client-client (sub-system) yang menggunakan layanan server dan tersedia network yang mengijinkan client untuk akses layanan dari server.

 

Pertemuan 8

METODE DESAIN

(User Interface Design–UID)

USER INTERFACE DESIGN /UID

Tujuan :

Merancang interface yang efektif untuk sistem perangkat lunakàsiap digunakan, dan hasilnya sesuai dg kebutuhan.

Graphical user interface :

Interface yang banyak digunakan dalam software.

Keuntungannya :

1.    Gampang dipelajari oleh pengguna yang kurang pengalaman;

2.    Berpindah dari satu layar ke layar yang lain tanpa kehilangan informasi;

3.    Akses penuh pada layarà beberapa macam tugas/keperluan.

Proses perulangan :

Proses dilakukan hingga menghasilkan desain yang diinginkan oleh pengguna.

Desain bersifat user-centered :

Pengguna sangat terlibat dalam proses desain.

Proses evaluasi dilakukan oleh pengguna à hasil desain.

Prinsip –prinsip dalam merancang user interface :

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. Contoh : jenis document open office;

1. consistency/ “selalu begitu” :

Konsisten dalam operasi dan istilah di seluruh sistem sehingga tidak membingungkan.

Contoh : layout menu di open office mirip dgn layout menu di ms office.

1. minimal surprise / tidak buat kaget user :

Operasi bisa diduga prosesnya berdasarkan perintah yang disediakan.

1. recoverability/pemulihan :

Recoverability ada dua macam:

– confirmation of destructive action

– ketersediaan fasilitas pembatalan (undo);

1. user guidance/ bantuan :

Sistem manual online, menu help, caption pada icon khusus tersedia;

1. user diversity/keberagaman :

Fasilitas interaksi untuk tipe user yang berbeda disediakan. Misalnya ukuran huruf bisa diperbesar.

Permasalahan perancang sistem (user interaction) :

1. Bagaimana informasi dari user bisa disediakan untuk sistem komputer?

Misalnya pada saat input data

1. Bagaimana informasi dari sistem komputer ditampilkan untuk user?

Hasil dari pemrosesan data

User interface yang baik :

Menyatukan interaksi pengguna (user interaction) dan penyajian informasi (information presentation).

 

 

Pertemuan 9

Manajemen data terdistribusi

Konsep ddtms (distributed data transaction managemen system) :

• Sekumpulan modul-modul software dimana pengaturan semua distribusi data (file dan database) ;
• Menggabungkan beberapa transaksi  yang berhubungan dan tersebar pada banyak komputer.

Faktor-faktor yang mempengaruhi desain ddtms :

• Bagaimana cara mengakses datasecara langsung dlm jaringan?
• Bagaimana cara mengupdate dan menangani data di jaringan?
• Bagaimana cara menjaga kebersamaan dan ketetapan data?
• Bagaimana menyusun transaksi dan meningkatkan respon?

Sistem sentralisasi  :

Data base management system (dbms) :

Paket software yang menangani akses data dan memanipulasi database oleh banyak pengguna.

Kemampuan dbms :

1. Menangani representasi logis dari data.
2. Menangani akses kedata oleh banyak pengguna.
3. Menerapkan pengamanan dan kontrol database.

Sistem terdistribusi :

1. Data terdistribusi dan ddtms :

Bertanggung jawab untuk mengolah semua data (file dan database) dan operasi pada data dalam lingkup distribusi komputasi.

1. Kumpulan dari modul-modul client server yang menyediakan manajemen berikut:

• Distribusi file
• Distribusi database
• Distribusi transaksi

 

Dfm (distribusi file manajemen) :

Menyediakan akses yang transparan, manipulasi dan administrasi data pada komputer yang berbeda dalam jaringan.

Ddbm (distributed database manager) :

Menyediakan akses yang transparan,  memanipulasi dan administrasi jarak jauh dari database   sebuah jaringan.

Dtm (distributed transaction manager ) :

Mengatur pelaksanaan atas sebuah  transaksi melalui banyak sistem.

Keuntungan ddtms:

1. Mengurangi biaya komunikasi dengan menempatkan data di tempat yang sering diakses.
2. Meningkatkan kehandalan dan juga keberadaan dari sistem.
3. Meningkatkan kapasitas sebuah sistem.
4. Meningkatkan kinerja sistem.
5. Memperbolehkan pengguna untuk mengontrol.

Kerugian ddtms :

1. Menaikan kompleksitas dari sistem.
2. Membuat pengendalian terpusat lebih sulit.
3. Penjagaan (security) terhadap terhadap data item.
4. Membuat hasil kinerja lebih sulit.
5. Menurunkan kinerja secara menyeluruh.

 

Manajemen file terdistribusi (dfm) :

Memperbolehkan akses secara transparan dan manipulasi file secara jarak jauh.

Fungsi :

Membuka, membaca, menulis, menutup lokasi file yang diakses jarak jauh dari program aplikasi dan atau pengguna.

Layanan dfm meliputi:

1. Seleksi dan deseleksi file jarak jauh untuk diakses.
2. Pembuatan dan penghapusan file jarak jauh.
3. Membaca dan merubah file data jarak jauh.
4. Mengontrol fungsi-fungsi melalui penguncian / pembukaan.
5. Keamanan dari akses yang tidak berhak.

Manajemen database terdistribusi (ddbm) :

Fungsi spesifik yang disediakan ddbm adalah:

1. Schema integration.
2. Location transparency and distributed query processing.
3. Concurrency control and failure handling.
4. Administration.

 

Database dalam lingkungan jaringan

Heterogen :

1. Database dapat mendukung perbedaan model data (hirarki, jaringan, relasional atau object oriented).
2. Perbedaan bahasa query dapat digunakan dalam database yang berbeda.
3. Dbms dapat disediakan oleh vendor yang berbeda.
4. Platform komputer dapat berbeda (micro, mini, mainframe).
5. Jaringan juga berbeda (lans,  wans, tcp/ip, sna, decnet,  osi) istilah lain dari database  heterogen :

• Mdbs (multi database system).
• Fdbs (federated database system).
• Fdbms (federated database management system).
• Ddbm (distributed data base management).
• Real time operating system
• Real time language

 

 

Pertemuan 10

Rekayasa software client/server

(c/s)

Struktur sistem c/s :

• Server

Struktur c/s dimana komputer yang berada di atas.

• Komputer-client

Struktur c/s dimana komputer pada level bawah.

Ada beberapa jenis implementasi struktur c/s:

1. File server :

Client minta record tertentu dari file, dan server mengirimkan record-record ini ke client lewat jaringan

1. Database server :

• Client mengirim sql (structured query language) ke server lewat jaringan.
• Server melakukan proses, mendapatkan informasi, dan kemudian mengirimkan hasi ke client.

1. Transaction server:

• Client kirim request yang meminta remote procedure di server.
• Remote procedure ini berupa satu set sql statement (atau bisa juga suatu fungsi).
• Transaksi terjadi saat hasil permintaan dikerjakan oleh remote procedure dan kemudian hasilnya dikirimkan kembali ke client.

1. Groupware server :

Server menyediakan berbagai aplikasi yang memungkinkan komunikasi antar client (dan pengguna yang memakainya) dengan menggunakan teks, image, bulletin boards, video, dan cara lain.

Komponen software pada sistem c/s :

1. User interaction subsystem :

• Subsistem yang terdiri dari semua fungsi yang berhubungan dengan user interface.
• Subsistem yang berfungsi sebagai data presentation bagi pengguna.

1. Application subsystem :

• Subsistem ini mengimplementasikan requirement yang telah ditetapkan sesuai dengan konteks domainnya.
• Aplikasi bisnis menghasilkan laporan berdasarkan input numerik, kalkulasi dan informasi database.
• Aplikasi groupware menyediakan fasilitas bulletin boards, email atau calendar.
• Software aplikasi bisa dibagi sehingga beberapa komponen berada di client dan yang lain di server.
• Application subsystem juga disebut business logic.

1. Database management subsystem :

• Subsistem yang melakukan manipulasi dan manajemen data yang dibutuhkan oleh aplikasi.
• Manipulasi data berarti seperti kirim record, atau proses transaksi sql yang rumit.

1. Middleware:

Elemen software yang ada di client maupun di server seperti :

• Elements of network operating systems
• Software that supports database specific applications
• Object-request broker (orb) standards
• Groupware technologies
• Communication management.
• Other features that facilitate the client-server connection.

Didefinisikan middleware (webopedia):

• Software that connects two otherwise separate applications. For example, there are a number of middleware products that link a database system to a web server.
• This allows users to request data from the database using forms displayed on a web browser, and it enables the web server to return dynamic web pages based on the user’s requests and profile.
• Describe separate products that serve as the glue between two applications.
• Middleware is sometimes called plumbing because it connects two sides of an application and passes data between them.

Cara pendistribusian komponen software c/s :

1. Fat client :

• User interaction/presentation, dan application pada client.
• Server menyediakan manajemen data.
• Model ini digunakan pada file server dan database server.

1. Thin client :

• User interaction /presentation pada client.
• Server menyediakan aplikasi/layanan dan data manajemen.
• Model ini untuk transaction dan groupware server.
• Fat / thin didasarkan pada seberapa banyak business logic yang ada pada client–semakin sedikit, hanya untuk user interaction, maka makin thin.
• Makin banyak business logic pada client, maka makin fat.
• Browser tidak melakukan apa-apa kecuali menampilkan informasi atau bertindak sebagai user interaction.

 

Pertemuan 11

Analisis Web

Analisis Web adalah pengukuran, pengumpulan, analisis dan pelaporan data internet untuk tujuan memahami dan mengoptimalkan penggunaan 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.

1. Interaction Analysis. Cara interaksi antara user dan WebApp dijelaskan.
2. 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.

1. Configuration Analysis. Lingkungan dan infrastruktur dimana WebApp akan

diberada digambarkan secara detil.

 

 

Desain Web

1. A.     Architectural design: menggambarkan struktur WebApp

Gambar 1: Struktur linier

 

Struktur linier:

1. urutan interaksi sudah bisa dipastikan
2. misal untuk presentasi tutorial, pemesana produk yang harus mengikuti urutan tertentu.

Gambar 2 : Struktur Grid

 

Struktur Grid

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

 

Gambar 3 : Struktur jaringan atau “pure web”

 

Struktur jaringan:

1. komponen pada struktur ini terhubung satu sama lain
2. sekalipun bersifat fleksibel, struktur ini membingungkan user

 

Gambar 4 : Struktur Hirarki

 

Struktur Hirarki:

1. struktur paling umum digunakan
2. memungkinkan aliran secara horizontal selain jalur vertikal yang umum
3. aliran secara horizontal juga bisa mengakibatkan kebingungan user

 

1. B.  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

 

1. C.  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

Kriteria yang ada pada gambar di bawah ini menjadi bagian menarik untuk Web engineers siapa yang harus mendesain, membangun, dan merawat WebApps melewati jangka waktu yang lama :

 

 

 

 

 

 

 

 

 

 

 

Gambar 2 Quality Requirement Tree (Pressman: 561)

 

Memperluas lima kualitas utama atribut yang dicatat pada gambar di atas dengan  menambah atribut yang mengikutinya, yaitu:

1. Security,
2. Availability,
3. Scalability,
4. Time-to-market.

 

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.

1. Uji WebApp secara keseluruhan setelah disatukan semua komponennya secara lengkap.
2. WebApp yang diimplementasikan pada konfigurasi yang berbeda diuji kompatibilitasnya.Misalnya jika membuat di IE, coba di Netscape, dan Firefox
3. WebApp diuji oleh sekelompok pengguna dengan kemampuan yang berbeda.Bagian yang diuji adalah isi, navigation, kemudahan penggunaan, kehandalan dan unjuk kerja.

 

Pertemuan 12

Software engineering  

Review rancangan detil

1. Internal walkthrough
2. Structured walkthrough
3. Inspeksi rancangan

Klasifikasi bahasa

1. Generasi bahasa program

Klasifikasi bahasa

1. Generasi bahasa program

• generasi 1
• generasi 2
• generasi 3
• generasi 4

 

1. Karakteristik  bahasa program

• segi psikologi
• segi teknis

 

1. Evaluasi pemilihan bahasa program
2. Struktur program

• tipe data

Tipe data pada dasarnya tipe data pada bahasa c ada 5, dan ditambah 4 tipe modifier yaitu :

 

Basic data types	Keyword
Character Integer Floating point Double floating point Void Char Int Float Double Void

 

Empat tipe modifier adalah sbb:

1. Signed
2. Unsigned
3. Long
4. Short

 

tipe data dalam bahasa c merupakan kombinasi antara basic data types dengan modifier.

contoh : signed char, unsigned int,long int,dll.

Elementary data

• Integer
• Real
• Character
• boolean

 

Structure data

• record
• file
• array
• string

 

Type data pointer (penunjuk)

Data ini digunakan untuk membuat data terstrukur type dinamiki.

• Subprogram
• struktur kontrol

 

Pertemuan 13

 

Analisa dan desain (lanjutan)

 

1. Outline system design( osd)

Sasaran yang ingin dibahas           :

1. Membedakan antara “cara dan “apa” yang harus dikerjakan.
2. Apa yang dimaksud dengan osd.

Isi osd  :

B.1.     Taxonomy perangkat keras

B.2.     Alat taxonomy.

B.3.     Taxonomy perangkat lunak.

 

Ad.b.1.  è sebuah katalog komputer mengenai jenis, perangkat tambahan berikut perangkat lunaknya.

 

Ad.b.2.  è sebuah katalog mengenai lingkungan pengembangan yang dibutuhkan untuk mengembangkan perangkat lunak yang tepat (programming support environment/pse).

 

Ad.b.3. è sebuah katalog mengenai persyaratan kebutuhan yang tercerminpada spesifikasi fungsional.

 

1. Desain perangkat lunak.

Þ    Sasaran

1. Sebagai alat transformasi informasidari spesifikasi menjadi blue-print implementasi yang menyediakan tampilan yang dibutuhkan.

 

1. Memberi fasilitas pencapaian maupun demo dari suatu kwalitas hasil akhir.

 

1. Untuk mencapai 2 langkah diatas dalam batasan kemampuan komputer untuk mengembangkan dan mengoperasikan.

 

Þ    Tahapan.

1. Arsitektur.

Spesifikasi tingkat tertinggi dari perangkat lunak yang harus dikembangkan.

 

1. Dekomposisi menjadi rinci.

Langkah lanjut dari definisi arsitektural.

 

1. Desain tingkat terendah.

Spesifikasi program yang harus diimplementasikan.

 

 

Pertemuan 14

 

Software management (lanjutan)

 

1. Usaha estimasi dan skala waktu.

 

• Sasaran yang ingin dicapai    :

–      kualitas ekonomis keberhasilan penyelesaiaan tugas se.

–      menyusun target yang mungkin harus dicapai.

–      mengurangi kesalahan yang terjadi pada saat proses pembuatan se.

–      membuat perencanaan kegiatan yang lebih baik.

• Definisi

Tahap definisi estimasi meliputi 3 bagian siklus hidup   :

1. Tahap spesifikasi dan feasibility

–      spesifikasi fungsional dan outline system design (osd).

–      disebut sebagai ‘tahap 1’ siklus hidup.

1. Aktivitas pengembangan software.

–      termasuk validitas dan sertifikasi software.

–      disebut sebagai ‘tahap 2’ siklus hidup

1. Tahap perawatan software.

–      dimulai sejak sistem dioperasikan dan berakhir saat sistem dicabut dari pengoperasian.

–      disebut sebagai ‘tahap 3’ siklus hidup

Kesalahan khusus dalam estimasi software

Ringkasan

1. Usaha terlalu dini untuk menyusun suatu perumusan yang cepat dan matang nilai usaha dan skala waktu yangdibutuhkan atau kedua-duanya, demikian pula estimasi kegiatan perawatan tahap 3 terlalu dini dilakukan.
2. Penggunaan faktor rata-rata produktivitas yang berlebihan untuk menghitung usaha estimasi dari beberapa evaluasi ukuran kode(code size).

Kesalahan khusus yang prematur yang sering ditemukan

1. Analogi.

Berdasarkan penilaian para pakar atau pendapat nonpakar.

1. Parkinson.

• Pekerjaan bertambah memenuhi waktu yang tersedia untuk itu.
• Perkiraan waktu (man year) yang disediakan untuk pembuatan software selalu tidak pernah tepat.
• Pendekatan ini harus dihindari dan lebih mengarah secara proporsional daripada software engineering pada usaha tahap 1 & 2.

1. Price to win.

• Lebih banyak ditujukan untuk usaha memenangkan tender.
• Sering kurang memperhatikan penilaian volume/bobot pekerjaan secara real.
• Sering terjadi penyebab estimasi prematur.

1. Top down estimating system analysis.

• Bukan suatu pendekatan yang tepat untuk subtansi estimasi.
• Bukan suatu pendekatn yang tepat untuk keperluan memperoleh kontrak.

1. Productivity factors.

• Pemakaian faktor produktivitas yang salah dalam melakukan estimasi ukuran kode untuk mendapatkan nilai usaha yang dibutuhkan.
• Estimasi ukuran kode berdasarkan hasil tebakan bukan pakar akan mempengaruhi hasil estimasi.
• Productivity harus dimasukkan sebagai faktor contigency.

Saran mengurangi kesalahan

• Gunakan metoda network planning/cpm untuk mengurangi kesalahan estimasi.
• Gunakan standar waktu, kwalifikasi tenaga, alat bantu dalam pembuatan estimasi.
• Gunakan alat bantu bar-chart, s-curve untuk cost control.

 

Pengelolaan pengembangan software

Beberapa hal yang perlu diperhatikan

• Penggunaan perencanaan dengan bar-chart dan status matriks.
• Penyerahan dokumentasi harus memenuhi syarat a.l :

–      kepada siapa diserahkan.

–      apa isi dokumentasi

–      kapan harus dilaksanakan yang tercantum dalam dokumentasi.

–      apakah perlu alat penunjang elektronis.

• Komponen penyerahan dokumentasi dilengkapi

–      users manual

–      the software maintenance manual.

–      the operators manual

• Pengaturan untuk perubahan berkaitan dengan

–      perubahan spesifikasi.

–      perubahan program pengendalian versi dan pengelolaan konfigurasi.

• Kesalahan umum dalam estimasi awal berkaitan dengan

–      estimasi anggaran tahap i

–      ketidakjelasan dalam mengestimasikan ketentuan nilai usaha dan skala waktu

Hubungan antara estimasi kesalahan sebagai fungsi tahapan siklus hidup

Verification dan testing

1. Umum

Verification & testing è bagian kegiatan dari sistem daur hidup (life cycle) pengembangan “se” sebelum dilakukan tahapan implementasi.

Tahapan daur hidup :

Requirement analysis. Design. Module specification Module coding Module unit test. System test Maintenance Testing

• Metode testing.

–     input data & check “bug” (metode i).

–     gunakan semua input & check hasilnya (metode ii).

–     test program dengan mengenal structure internal atau lebih dikenal dengan metode “white box” (metode iii).

• Cara terbaik testing se è seleksi test data yang sanggup.

–      dicoba pada seluruh jalur program.

–      aksi test yang digunakan pada kasus khusus.

B.1. Staff yang cukup.

B.2. Fasilitas penunjang yang cukup

B.3. Waktu tersedia yang cukup

1. Testing penyusunan program (author & advesary testing).

• Secara harfiah berarti pengarang/penyusun program wajib melakukan testing atas hasil karyanya.
• Melibatkan beberapa pengarang bila program disusun secara bersama-sama
• Advisory testing berarti testing yang dilakukan oleh orang lain melalui fungsi quality control sebagai “code reading”, sementara penyusunan program melaksanakan inspeksi program code.

1. Testing static & dynamic
2. Static testing (bagian dari kegiatan quality control).

–      inspeksi kode program.

–      pendekatan melalui uji coba program

–      dilakukan oleh penyusun program atau tim penyusun

–      bila testing merupakan bagian quality control harus dilaksanakan oleh seorang agen independent di bidang quality assurance.

1. Dynamic testing.

–      testing melalui ‘operate’ atau ‘run’

–      dilaksanakan oleh penyusunan program atau tim penyusun selama masa integrasi.dibutuhkan 2 aspek dalam dynamic testing :

A)   perencanaan test yang matang.

B)   strategi test yang berkaitan dengan lingkungan persediaan data untuk melaksanakan testing dynamic.

 

1. Integrasi testing pendekatan top-down dan bottom up.

Top down testing dimaksud antara lain    :

1) mengarahkan masukan dari luar dan menjalankannya ke bagian yang tepat dari kerangka program keseluruhan.

2) menyediakan “dummy” routine dalam kerangka kerja program yang dapat menjadi refleksi sederhana dalam pembentukan program.

Penilaian dalam pengembangan cara top-down

Pernyataan yang sering timbul dalam implementasi top-down adalah :

1)   deteksi awal dari kesalahan utama

–      kumpulan utama dan interface selalu di test lebih dahulu.

2)   kepercayaan (reliability)

–      pengulangan testing yang sering akan memberi kesempatan mendeteksi kesalahan.

3)   program debugging

–      kesalahan mudah dialokasikan dalamtahap implementasi top-down

–      top-down secara sistematis menciptakan situasi dimana penambahan testing secara langsung dilaksanakan.

4)   penggunaan komputer time

–      penggunaan komputer time untuk komplikasi, linking dan sering waktu testing disebar selama project life-time.

5)   tampilan implementasi top-down adalah sesuatu yang tangible.

6)   programmer time.

–      implementasi top-down akan melibatkan sedikit programmer time, yang ditujukan oleh deteksi kesalahan utama (mengurangi pengulangan kerja) dan mengalokasikan dengan cepat daripada bugs.