BAB V PERANCANGAN MOXIE
|
|
- Verawati Lie
- 7 tahun lalu
- Tontonan:
Transkripsi
1 BAB V PERANCANGAN MOXIE Bab ini berisi penjabaran dari hasil perancangan Moxie. Pembahasan pada bab ini mencakup perancangan arsitektur dan model skenario untuk Moxie. Model skenario merupakan produk dari fase perancangan untuk siklus 1, sedangkan arsitektur merupakan produk dari siklus 2. Secara umum, produk dari fase perancangan ini disebut sebagai blueprint atau solution model dari Moxie. 5.1 Perancangan Arsitektur Perancangan arsitektur sangat dipengaruhi oleh stakeholder. Stakeholder utama yang dinilai sangat terkait dengan pengembangan Moxie adalah pengguna dan pihak pengembang. Namun, dalam konteks pengembangan Moxie, perancangan arsitektur ditujukan terutama bagi pihak pengembang selanjutnya. Rancangan arsitektur yang dihasilkan diharapkan dapat menjadi panduan atau alat untuk memahami bagaimana komponen sistem dibangun dan atribut kualitas apa saja yang perlu diperhatikan. Hasil identifikasi atribut kualitas ini dijabarkan lebih lanjut dalam subbab Pemilihan Atribut Kualitas Pada dasarnya, pembangunan sebuah sistem yang ideal sebaiknya dapat mempertimbangkan seluruh atribut kualitas yang ada. Namun, Brosseau [BRO07] menyatakan bahwa tidak mungkin (atau sangat sulit) untuk memenuhi seluruh atribut yang ada sekaligus. Selain itu, tidak semua atribut memiliki relevansi terhadap sistem yang dirancang [BRO07]. Oleh sebab itu, dalam siklus pengembangan Moxie saat ini, akan dipilih dua atribut kualitas untuk ditelaah lebih lanjut, yaitu modifiability dan reusability Modifiability (Kemudahan Modifikasi) Moxie merupakan sebuah sistem yang kompleks karena dibangun atas sejumlah komponen yang berkoordinasi untuk menyediakan layanan bagi pengguna. Kompleksitas ini dapat menyebabkan sistem sulit untuk diubah. Padahal dalam pengembangannya, akan terdapat sejumlah kondisi yang menyebabkan Moxie harus mampu mengakomodasi perubahan, misalnya koreksi terhadap bug atau perubahan spesifikasi oleh pengguna. Selain itu, spesifikasi kebutuhan Moxie yang didefinisikan pada tahap pengembangan ini sendiri belum lengkap dan metodologi prototyping memungkinkan terdefinisinya sejumlah spesifikasi kebutuhan baru di masa mendatang. V-1
2 V-2 Adanya kebutuhan untuk menjadikan sistem adaptif terhadap perubahan atau penambahan komponen menyebabkan modifiability perlu dipertimbangkan sebagai atribut kualitas dalam perancangan blueprint sistem. Dalam proses menganalisis atribut ini ada tiga hal yang perlu didefinisikan lebih lanjut, yaitu: 1. Dari hasil perancangan arsitektur sistem perlu didefinisikan modifikasi pada level apa yang dapat diakomodasi oleh sistem. 2. Dari hasil perancangan arsitektur perlu didefinisikan jenis komponen apa yang akan terlibat dalam modifikasi apakah berupa komponen hardware atau software. 3. Dari hasil perancangan arsitektur perlu didefinisikan konteks modifikasi yang dapat dilakukan terhadap sistem apakah terjadi di masa pengembangan atau saat runtime sistem Reusability (Kemudahan untuk Digunakan Kembali) Sesuai dengan tahapan dalam metodologi prototyping, pengembangan Moxie dapat dilakukan secara berkelanjutan, artinya setelah sebuah produk dihasilkan, Moxie masih mungkin untuk terus dikembangkan sehingga menghasilkan produk versi berikutnya. Menggunakan kembali komponen dari produk sebelumnya dapat mereduksi waktu dan biaya. Berdasarkan pertimbangan tersebut, maka reusability menjadi atribut yang perlu dipertimbangkan dalam rancangan arsitektur Moxie. Reusability sendiri sesungguhnya merupakan kasus khusus dari modifiability, meskipun jarang disebutkan sedemikian rupa [BAS98]. Membangun sistem sehingga mudah dimodifikasi akan berakibat pada peningkatan reusability [BAS98]. Hal ini menjadi alasan lain mengapa reusability menjadi atribut lain yang perlu dipertimbangkan bersamaan dengan modifiability. Ada dua hal yang perlu dianalisis lebih lanjut dari atribut reusability, yaitu: 1. Dari hasil perancangan arsitektur perlu didefinisikan level komponen apa yang dapat digunakan kembali apakah berupa kelas, fungsi, proses, dan sebagainya. 2. Dari hasil perancangan arsitektur perlu diperhatikan batasan dari komponen yang dapat digunakan kembali apakah dapat digunakan kembali secara penuh (full reuse) atau sebagian (half reuse) Solusi Arsitektur Moxie Ada dua atribut kualitas yang menjadi spesifikasi dalam arsitrektur Moxie, yaitu modifiability dan reusability. Beberapa strategi yang digunakan agar Moxie dapat mencapai atribut tersebut dapat dijabarkan sebagai berikut:
3 V-3 1. Membagi sistem menjadi sejumlah modul. Modularitas sistem harus cukup sederhana dan jelas sehingga komponen sistem mudah dipahami, dan dengan demikian, mudah untuk dimodifikasi atau digunakan kembali. 2. Menyembunyikan detail informasi setiap komponen (information hiding) dengan cara enkapsulasi. Setiap modul menyediakan sekumpulan prosedur yang dapat dipanggil oleh modul lain. Prosedur ini memungkinkan terjadinya komunikasi intermodul. Selain prosedur ini, detil informasi dari setiap modul disembunyikan hanya untuk modul tersebut. Strategi semacam ini menjadikan sebuah modul independen terhadap modul lainnya baik dari segi modifikasi maupun kemampuan untuk digunakan kembali. Ringkasan dari penjabaran di atas dapat dilihat pada Tabel V-1. Tabel V-1 Strategi untuk Mencapai Atribut Kualitas Moxie Atribut kualitas Strategi untuk mencapai atribut kualitas Modifiability 1. Modularitas Reusability 2. Information hiding Agar sejalan dengan strategi yang telah ditetapkan, solusi arsitektur Moxie akan direpresentasikan dalam tiga struktur, yaitu module structure, uses structure, dan data flow. Module structure dipilih untuk memperlihatkan bagaimana sistem didekomposisi menjadi sejumlah modul. Struktur ini menjelaskan fungsi setiap modul dan bagaimana suatu modul dibagi menjadi sejumlah submodul. Module structure mendeskripsikan relasi antar komponen selama masa pengembangan sistem. Tujuan yang ingin dicapai dari struktur ini adalah membangun arsitektur sistem yang mendukung modularitas. Uses structure digunakan untuk mengilustrasikan bagaimana ketergantungan antar modul saat proses runtime. Unit dari struktur ini adalah modul. Modul A dikatakan menggunakan (use) modul B jika di dalam modul B terdapat prosedur ataupun data yang dapat menjamin modul A berjalan sesuai spesifikasi. Data flow dipilih untuk menunjukkan data apa saja yang ditransmisikan di antara modul. Unit dari struktur ini adalah modul yang berhubungan dengan modul lain melalui relasi aliran data. Bersamaan dengan use structure, struktur ini menunjukkan arsitektur sistem saat proses runtime, khususnya dalam aspek aliran data. Melalui uses structure dan data flow, dapat diperoleh gambaran apakah suatu modul mengakses modul yang lain, dan jika hal tersebut terjadi, maka informasi ini dapat menjadi modal bagi pengembang untuk menentukan detil apa saja yang dapat diakses dan perlu
4 V-4 disembunyikan dari sebuah modul. Hal ini terkait dengan information hiding yang menjadi strategi pencapaian atribut kualitas. Ringkasan dari uraian mengenai pemilihan struktur arsitektur dapat dilihat pada Tabel V-2. Tabel V-2 Pemilihan Struktur Arsitektural Moxie Struktur Unit Struktur Relasi Antar Unit Module Modul Merupakan structure submodul dari (is a submodule of); berbagi informasi dengan (share a secret with) Uses structure Modul Dapat menggunakan (is allowed to use) Data flow Modul Dapat mengirimkan data ke (may-send-datato) Module Structure Yang Dijelaskan oleh Struktur Ini 1. Dekomposisi sistem menjadi sejumlah modul 2. Menunjukkan relasi antara modul dengan submodul, relasi antar modul selama masa pengembangan sistem Menunjukkan relasi penggunaan antar modul saat runtime sistem Menunjukkan relasi data antar modul saat runtime sistem Berdasarkan fungsionalitas dan tanggung jawabnya, struktur Moxie dibagi menjadi lima modul, yaitu: modul antarmuka, akses dan autentikasi, aplikasi, middleware, dan repositori. Dalam subbab ini akan dijabarkan mengenai deskripsi dan tanggung jawab setiap modul. MODUL 1: ANTARMUKA Merupakan modul yang berhubungan langsung dengan pengguna. Tugas utama dari modul ini adalah menerima input dari pengguna dan memberikan output dalam representasi yang sesuai. Pembagian submodul pada modul antarmuka harus disesuaikan dengan modul aplikasi dan modul repositori. Mengenai hal ini akan dijelaskan lebih lanjut di dalam pembahasan mengenai modul aplikasi. MODUL 2: AKSES DAN AUTENTIKASI Merupakan modul yang terkait dengan pengaturan hak akses, session, dan autentikasi pengguna. Tugas utama dari modul ini adalah mengecek validitas pengguna dalam mengakses layanan yang disediakan oleh Moxie. Modul akses dan autentikasi berhubungan dengan keamanan sistem, khususnya masalah pengaksesan sistem oleh pengguna yang berhak. Pendekatan yang digunakan sebagai solusi dalam domain ini dapat dijabarkan sebagai berikut: 1. Setiap kelompok pengguna memiliki deskripsi hak akses masing-masing. Deskripsi hak akses setiap pengguna disimpan oleh sistem di dalam repositori.
5 V-5 2. Proses autentikasi dimaksudkan untuk mengecek apakah pengaksesan suatu layanan oleh pengguna sudah sesuai dengan haknya. Oleh sebab itu, sistem melakukan proses autentikasi setiap kali pengguna akan mengakses suatu layanan. Untuk kebutuhan proses autentikasi, sistem perlu mengakses deskripsi hak akses pengguna di repositori. Proses pengaksesan repositori sendiri harus dilakukan melalui API yang terdapat di modul middleware. MODUL 3: APLIKASI Merupakan modul yang terdiri atas mesin utama dari layanan yang membangun Moxie. Tugas utama dari modul aplikasi adalah menyediakan layanan yang tepat berdasarkan kebutuhan pengguna. Aplikasi yang disediakan oleh Moxie merupakan representasi teknologi dari spesifikasi yang disediakan oleh sistem. Spesifikasi ini sendiri telah dijabarkan sebagai use case dalam subbab Seperti yang telah dijelaskan pada subbab 4.3.4, use case pada Moxie dapat dikelompokkan ke dalam empat kategori utama, yaitu: use case yang mengakomodasi layanan untuk knowledge creation, knowledge retention, knowledge sharing, dan knowledge utlization. Sebuah use case juga dapat dikelompokkan ke lebih dari satu kategori. Berdasarkan uraian di atas, dapat dinyatakan bahwa pendefinisian aplikasi pada Moxie dilakukan berdasarkan use case. Dalam subbab ini tidak akan dijelaskan lebih rinci mengenai contoh aplikasi yang dapat digunakan untuk mengimplementasikan Moxie. Namun, akan dijabarkan mengenai alternatif bentuk aplikasinya saja. Hal ini dapat dilihat pada Tabel V-3. Sedangkan untuk contoh dari setiap bentuk aplikasi yang ada, terdapat sejumlah referensi yang dapat dibaca, salah satunya adalah [TIW00]. Modul aplikasi berperan sebagai mesin utama yang menyediakan layanan, sedangkan modul antarmuka adalah representasi layanan yang berinteraksi langsung dengan pengguna. Data-data yang terkait dengan suatu layanan perlu disimpan di dalam repositori. Berdasarkan hubungan antara ketiga modul tersebut, maka pendefinisian submodul pada modul aplikasi harus disesuaikan dengan modul antarmuka dan modul repositori. Sebagai contoh, jika pada Moxie telah ditetapkan untuk mengimplementasikan aplikasi berupa blog, maka pada masing-masing modul aplikasi, modul antarmuka, dan modul repositori perlu dibangun submodul blog.
6 V-6 Tabel V-3 Alternatif Bentuk Aplikasi untuk Layanan yang Disediakan Moxie Spesifikasi Moxie Proses Aliran Pengetahuan yang Alternatif Bentuk Aplikasi Berdasarkan Use Case Diakomodasi Mencari dokumen TA Knowledge creation Information retrieval Mencari sumber belajar di World Wide Web Melakukan korespondensi Mengkonsumsi sumber belajar secara aktif Mengelola catatan/ringkasan Mengarsipkan hasil belajar untuk publik Melakukan upload dokumen TA Knowledge creation Knowledge creation, knowledge utilization Knowledge creation Knowledge creation, knowledge retention Knowledge sharing Knowledge sharing Mesin pencari (search engine) , newsgroup (forum), text chat, audio / video conference, expertise yellow pages Document reader dengan perangkat tambahan untuk manipulasi isi dokumen Mapping tools, aplikasi content management Aplikasi content management, blog, personal website Aplikasi content management, file uploader Mengelola dokumen TA Knowledge sharing Aplikasi content management Mengelola anggota -- Personal management, user profiling Validasi pengguna -- (ditangani oleh layer akses dan autentikasi) MODUL 4: MIDDLEWARE Modul ini mendefinisikan middleware yang digunakan dalam Moxie. Middleware adalah teknologi yang menyediakan layanan yang memungkinkan beberapa proses, aplikasi atau program berjalan pada satu atau sejumlah mesin yang terhubung sehingga memungkinkan terjadinya pertukaran data atau pesan. Dalam arsitektur Moxie, middleware diharapkan dapat menjadi jembatan atau antarmuka untuk komunikasi antar submodul aplikasi, modul aplikasi dengan repositori, dan modul akses dan autentikasi dengan repositori. MODUL 5: REPOSITORI Merupakan modul yang terdiri atas sejumlah media penyimpanan, bisa berupa basis data relasional, file data, data warehouse, dan sebagainya. Pemilihan bentuk repositori dapat didefinisikan berdasarkan kebutuhan. Namun, perlu diingat bahwa keragaman bentuk repositori tentunya akan meningkatkan kompleksitas dalam penyimpanan dan pengaksesan data sehingga membutuhkan perancangan lebih lanjut untuk membangunnya.
7 V-7 Untuk memperjelas uraian mengenai struktur modul pada arsitektur Moxie, dibuat Gambar V-1. Melalui gambar ini dapat dilihat bahwa Moxie dibangun oleh lima modul utama. Setiap modul dapat dibangun oleh sejumlah submodul. Pada modul antarmuka, aplikasi, dan repositori, pendefinisian sebuah submodul harus dibuat sinkron, artinya jika pada modul aplikasi terdapat submodul X, maka pada modul antarmuka dan modul repositori juga perlu dibangun submodul X. Gambar V-1 Module Structure Moxie Berdasarkan uraian di atas, maka dapat dilihat bahwa setiap submodul memiliki spesifikasi pekerjaan yang jelas. Komunikasi antar submodul hanya dapat dilakukan melalui prosedur yang memang disediakan oleh sebuah submodul agar dapat diakses oleh submodul lainnya (prosedur ini disebut dengan call procedure [BAS98]). Sedangkan, detil informasi lainnya disembunyikan hanya untuk submodul tersebut. Dengan demikian, pengaruh dari modifikasi suatu submodul hanya perlu dilihat dari call procedure yang dimanfaatkan oleh submodul lain, dan jika tidak ada masalah dalam hal tersebut, maka perubahan pada submodul tersebut tidak akan mempengaruhi submodul lainnya Uses Structure dan Data Flow Uses structure menjelaskan relasi dapat menggunakan atau is-allowed-to-use dari sekumpulan modul yang membangun Moxie. Relasi ini dapat dijelaskan melalui Tabel V-4. Tabel V-4 Spesifikasi Relasi Use pada Arsitektur Moxie Nama Modul dapat menggunakan modul Antarmuka Akses dan Autentikasi, Aplikasi Akses dan Autentikasi Middleware Aplikasi Middleware Middleware Aplikasi, Repositori Repositori -- Aspek lain yang perlu diperlihatkan dari arsitektur sistem saat runtime adalah aliran data atau data flow. Jika relasi use dan aliran data diilustrasikan ke dalam sebuah gambar, maka
8 V-8 komponen sistem dapat ditunjukkan sebagai kumpulan layer. Setiap modul direpresentasikan sebagai sebuah layer dan dihubungkan dengan layer lainnya seperti yang tampak pada Gambar V-2. Garis solid menunjukkan relasi use sedangkan garis putus-putus berlabel menunjukkan aliran dan nama data yang ditransmisikan antar modul. Adapun penjelasan mengenai aliran data dari arsitektur pada Gambar V-2 dapat dijabarkan secara garis besar sebagai berikut: 1. Layer antarmuka menerima data berupa input dari pengguna dan memberikan output dalam representasi yang sesuai. Input dari pengguna diubah ke dalam format yang sesuai dan ditransmisikan ke layer akses dan autentikasi. 2. Input terformat dari layer antarmuka diproses oleh layer akses dan autentikasi sehingga menghasilkan data hasil autentikasi. Untuk memperoleh hasil ini, layer akses dan autentikasi harus mengakses deskripsi hak akses pengguna di repositori. Pengaksesan layer repositori sendiri hanya dapat dilakukan melalui layer middleware. Itu sebabnya terjadi aliran data dari layer akses dan autentikasi ke layer middleware, dan sebaliknya. 3. Input terformat dari layer antarmuka juga ada yang diteruskan ke layer aplikasi. Selama proses runtime, layer aplikasi sendiri akan membutuhkan data dari atau mengirim data ke repositori. Karena pengaksesan layer repositori hanya dapat dilakukan oleh layer middleware, maka akan terjadi aliran data dari layer aplikasi ke layer Middleware untuk selanjutnya diteruskan ke layer repositori, dan sebaliknya. 4. Layer middleware tidak hanya menghubungkan layer aplikasi dengan repositori, namun juga menyediakan antarmuka jika sebuah submodul di layer aplikasi perlu berkomunikasi dengan submodul lain di layer tersebut. Dengan demikian, layer middleware menjembatani aliran data dari dan ke layer aplikasi itu sendiri. Seluruh layer yang membangun arsitektur Moxie terintegrasi melalui Web. Dengan demikian, client dapat ditempatkan terpisah dengan server dan client yang satu dapat berkomunikasi dengan client yang lain melalui jaringan.
9 V-9 Gambar V-2 Arsitektur Layer yang Menggambarkan Uses Structure dan Data Flow Moxie Kesimpulan atas Solusi Arsitektural Moxie Berdasarkan solusi arsitektural Moxie yang dijabarkan dalam subbab dapat dijabarkan beberapa kesimpulan sebagai berikut: 1. Prinsip modularitas dan information hiding menjadikan sistem Moxie adaptif terhadap modifikasi di level submodul. Perubahan di suatu submodul setidaknya hanya perlu memperhatikan call procedure yang diakses oleh submodul lainnya, dan jika tidak ada masalah dalam hal tersebut, maka perubahan pada submodul yang bersangkutan seharusnya tidak mengganggu submodul lain. Hal ini menunjang tercapainya modifiability sistem. Argumen yang sama berlaku terhadap atribut reusability. Karena
10 V-10 submodul yang satu independen terhadap yang lain, maka pemanfaatan kembali submodul tersebut dalam pembangunan produk versi selanjutnya sangat dimungkinkan. 2. Sistem layer dalam arsitektur Moxie lebih berbicara kepada rancangan dari sisi perangkat lunak (software). Arsitektur ini belum memperlihatkan bagaimana keterlibatan komponen mekanis (hardware) di dalam sistem. 3. Aristektur Moxie menunjukkan struktur sistem baik dalam konteks pengembangan maupun saat runtime sistem. Module structure mendeskripsikan relasi antar modul yang membangun sistem dalam konteks pengembangan. Sedangkan, relasi antar komponen sistem saat proses runtime ditunjukkan melalui uses structure dan data flow. 4. Karena setiap komponen memiliki deskripsi fungsionalitas yang jelas, maka komponen dapat digunakan kembali pada sistem lain, baik Moxie atau bukan. Proses reuse dapat dilakukan terhadap sebuah submodul saja, misalnya Database Connection API dari modul middleware, atau rentetan submodul dari beberapa modul sekaligus, misalnya penggunaan kembali submodul blog dari modul aplikasi perlu mempertimbangkan penggunaan submodul blog dari modul antarmuka dan modul repositori. Hal ini dapat disesuaikan dengan kondisi sistem yang akan melakukan reuse Rekomendasi terhadap Solusi Arsitektural Moxie Terhadap solusi arsitektural Moxie yang telah dijabarkan dalam subbab 5.1.2, ada beberapa hal yang perlu dipertimbangkan sebagai rekomendasi. Rekomendasi ini dapat menjadi masukan jika rancangan arsitektur akan diterapkan atau disempurnakan lagi di masa mendatang. Penjabaran dari rekomendasi tersebut dapat diuraikan sebagai berikut: 1. Untuk mendukung modifiability sistem, rancangan arsitektur dan implementasi Moxie sebaiknya mempertimbangkan penggunaan bahasa pemrograman yang berorentasi objek. Dengan demikian, perubahan pada sebuah komponen yang mungkin berpengaruh terhadap komponen lain lebih mudah diakomodasi (misalnya dengan membuat antarmuka untuk komponen tersebut). 2. Sebuah sistem yang kompleks membutuhkan integritas agar komponen sistem dapat berkoordinasi dengan baik. Terkait dengan pengembangan Moxie di masa mendatang, integrability merupakan atribut yang perlu dipertimbangkan dalam perbaikan rancangan arsitektur Moxie. Konteks pembahasan yang dicakup dalam atribut ini berhubungan dengan mekanisme agar komponen sistem yang telah dimodifikasi atau akan digunakan kembali (reuse) dapat diintegrasikan ke dalam sistem yang ada. 3. Penambahan modul atau layer pada arsitektur Moxie perlu dipertimbangkan untuk memperluas layanan yang disediakan Moxie. Sebagai contoh, Moxie ingin dilengkapi dengan kemampuan untuk beradaptasi dengan kebutuhan personal pembelajar,
11 V-11 melakukan klasifikasi sumber belajar menurut ontologi tertentu, atau memberikan rekomendasi sumber belajar sesuai minat pembelajar. Dengan demikian, pada Moxie perlu dipertimbangkan adanya penambahan sebuah modul atau layer yang menangani masalah inteligensia sistem. Namun, penambahan modul atau layer ini perlu memperhatikan uses structure dan data flow dari arsitektur yang telah ada. 4. Pemilihan struktur arsitektural sangat tergantung pada sudut pandang yang ingin ditunjukkan oleh arsitektur. Dalam pengembangan selanjutnya, perancangan sistem telah mencapai tahap yang lebih detil sehingga perlu mempertimbangkan struktur lain untuk merepresentasikan sistem, misalnya: control flow, logical structure, atau class structure. 5.2 Perancangan Skenario Skenario digunakan untuk mengilustrasikan bentuk interaksi yang terjadi antara pengguna dan sistem. Dalam perancangan ini, skenario akan dirancang berdasarkan use case yang telah diidentifikasi pada subbab Tahapan yang dilakukan dalam perancangan skenario Moxie dapat dijabarkan sebagai berikut: 1. Memetakan metodologi proses belajar pada Gambar IV-3 menjadi sebuah model skenario utama proses belajar. 2. Mengidentifikasi use case prioritas dalam perancangan skenario. Hal ini dilakukan dengan melihat apakah use case yang bersangkutan terkait erat dengan proses belajar. Hasil identifikasi ini dapat dilihat pada Tabel V Memetakan use case prioritas ke dalam proses yang ada di model skenario utama proses belajar. Oleh sebab itu, pada setiap simbol proses di model skenario akan terdapat simbol yang menyatakan daftar use case yang tercakup dalam proses tersebut. Hasil perancangan model skenario belajar ini dapat dilihat pada Gambar V Membuat deskripsi skenario untuk masing-masing use case prioritas. Hasil deskripsi skenario ini dapat dilihat pada Lampiran D. Deskripsi skenario digunakan untuk menunjukkan bagaimana interaksi antara aktor dan sistem. Dalam pengembangan Moxie saat ini, deskripsi skenario Moxie dirancang dalam batasan tertentu, yaitu: a. Skenario yang dirancang adalah skenario normal. b. Skenario yang dirancang bersifat umum atau belum berbicara spesifik terhadap bentuk aplikasi yang akan digunakan, seperti: apakah teknologi untuk korespondensi akan berupa atau video conference, apakah pengguna dapat membuat catatan dalam bentuk tulisan saja atau juga simbol/gambar, dan sebagainya. Oleh sebab itu, di masa mendatang, skenario yang dihasilkan masih mungkin mengalami penyesuaian terhadap teknologi yang akhirnya dipilih untuk diimplementasikan pada Moxie.
12 V-12 Tabel V-5 Identifikasi Use Case Prioritas dalam Perancangan Skenario Kode Use Case Use Case Tergolong ke dalam Use Case Prioritas UC-01 Mencari Dokumen TA UC-02 Mencari Sumber Belajar di World Wide Web UC-03 Melakukan Korespondensi UC-04 Mengkonsumsi Sumber Belajar Secara Aktif UC-05 Mengelola Catatan/Ringkasan UC-06 Mengarsipkan Hasil Belajar untuk Publik UC-07 Melakukan Upload Dokumen TA UC-08 Mengelola Dokumen TA UC-09 Mengelola Anggota -- UC-10 Validasi Pengguna -- Catatan : Simbol () menyatakan use case yang menjadi prioritas dalam perancangan skenario, yaitu use case yang tergolong ke dalam model skenario utama proses belajar
13 V-13!"#!$! $ % "!%!!$#!&#!' # # "!$#!'#!( "!)#!*! " Gambar V-3 Model Skenario Utama Belajar Tugas Akhir (TA)
BAB IV PERENCANAAN DAN ANALISIS MOXIE
BAB IV PERENCANAAN DAN ANALISIS MOXIE Pada bab ini akan dibahas hasil dari perencanaan dan analisis pengembangan Moxie. Moxie merupakan sebuah knowledge library yang dikembangkan dengan studi kasus yang
Lebih terperinciBAB I PENDAHULUAN. 1.1 Latar Belakang I-1
BAB I PENDAHULUAN 1.1 Latar Belakang Knowledge management (KM) dapat dijelaskan sebagai langkah-langkah sistematik untuk mengelola pengetahuan dalam organisasi untuk menciptakan nilai dan meningkatkan
Lebih terperinciBAB III ANALISIS PROSES BELAJAR DAN KONSEP KNOWLEDGE LIBRARY
BAB III ANALISIS PROSES BELAJAR DAN KONSEP KNOWLEDGE LIBRARY Pada bagian ini akan dibahas hasil analisis dari konsep belajar sebagai proses knowledge management. Selain itu, akan dijabarkan pula konsep
Lebih terperinciBAB IV PERANCANGAN. 4.1 Proses Bisnis Pengadaan Barang
BAB IV PERANCANGAN Pada tahap perancangan ini akan dilakukan perancangan proses pengadaan barang yang sesuai dengan proses bisnis rumah sakit umum dan perancangan aplikasi yang dapat membantu proses pengadaan
Lebih terperinciBAB III ANALISIS DAN PERANCANGAN SISTEM. Pada bab ini akan dibahas tentang tahapan-tahapan analisis dan desain
BAB III ANALISIS DAN PERANCANGAN SISTEM Pada bab ini akan dibahas tentang tahapan-tahapan analisis dan desain perancangan sistem informasi sumber daya manusia pada PT. Jasamitra Propertindo. Tahap-tahap
Lebih terperinciTujuan 04/07/ :01
Sistem Basis Data : Perancangan Perangkat Lunak Tujuan Mahasiswa mampu memahami analisis dan desain model database Mahasiswa paham dan mengerti konsep desain database Mahasiswa mengerti desain arsitektur
Lebih terperinciDESKRIPSI PERANCANGAN PERANGKAT LUNAK. <Nama Perangkat Lunak>
DPPL-W-xx DESKRIPSI PERANCANGAN PERANGKAT LUNAK untuk: Dipersiapkan oleh: Program Studi Teknik Informatika FIK - UDINUS Jl. Imam Bonjol No. 207
Lebih terperinciBAB III ANALISIS. 3.1 Model Penerapan BPM pada SOA III-1
BAB III ANALISIS 3.1 Model Penerapan BPM pada SOA Penerapan proses BPM pada sebuah organisasi akan mengakibatkan sistem yang digunakan terus berubah untuk mencapai proses bisnis yang lebih efisien dan
Lebih terperinciBAB I PENDAHULUAN I-1
BAB I PENDAHULUAN Pada bagian ini akan dijelaskan tentang pendahuluan dalam penyusunan laporan tugas akhir, yang meliputi latar belakang masalah, identifikasi masalah, rumusan masalah, maksud dan tujuan
Lebih terperinciBAB III TAHAPAN ANALISIS DAN PERANCANGAN SISTEM. analisis dan perancangan sistem penerimaan mahasiswa baru di INKAFA.
BAB III TAHAPAN ANALISIS DAN PERANCANGAN SISTEM Analisis dan perancangan sistem merupakan langkah ketiga pada tahapan SHPS. Pada bab ini akan membahas tentang langkah-langkah dalam melakukan analisis dan
Lebih terperinciDESKRIPSI PERANCANGAN PERANGKAT LUNAK. <Nama Perangkat Lunak>
DPPL-W-xx DESKRIPSI PERANCANGAN PERANGKAT LUNAK untuk: Dipersiapkan oleh: Program Studi Teknik Informatika FIK - UDINUS Jl. Imam Bonjol No. 207
Lebih terperinciMODEL DESAIN & DOKUMENTASI DESAIN
MODEL DESAIN & DOKUMENTASI DESAIN Tugas ke 9 Rekayasa Perangkat Lunak Dibuat oleh : Dekha Sundhawati (41813120217) Dosen Pengampu : Wachyu Hari Haji, S.Kom,MM JURUSAN SISTEM INFORMASI FAKULTAS ILMU KOMPUTER
Lebih terperinciBAB I PENDAHULUAN 1.1 Latar Belakang Masalah
BAB I PENDAHULUAN 1.1 Latar Belakang Masalah Bagi perusahaan yang bergerak dalam industri manufaktur, sistem informasi produksi yang efektif merupakan suatu keharusan dan tidak lepas dari persoalan persediaan
Lebih terperinciBAB II LANDASAN TEORI. Institut merupakan Perguruan Tinggi yang menyelenggarakan pendidikan
BAB II LANDASAN TEORI 2.1 Informasi Umum Pendidikan Tinggi Berdasarkan undang-undang Republik Indonesia dijabarkan bahawa Institut merupakan Perguruan Tinggi yang menyelenggarakan pendidikan akademik dan
Lebih terperinciTESTING DAN IMPLEMENTASI SISTEM. WAHYU PRATAMA, S.Kom., MMSI.
TESTING DAN IMPLEMENTASI SISTEM WAHYU PRATAMA, S.Kom., MMSI. PERTEMUAN 6 TESTING DAN IMPLEMENTASI SISTEM Pengujian Berorientasi Objek Model Pengujian OOA dan OOD. Strategi Pengujian Berorientasi Objek.
Lebih terperinciBAB IV ANALISIS DAN PERANCANGAN SISTEM. mampu memperkirakan dan merincikan seluruh dokumen ataupun prosedur yang
BAB IV ANALISIS DAN PERANCANGAN SISTEM 4.1 Analisis Sistem Yang Berjalan Analisis terhadap sistem yang berjalan dimaksudkan untuk mempelajari terhadap suatu sistem yang sedang dijalanakan oleh suatu organisasi,
Lebih terperinciPERENCANAAN PROYEK PERANGKAT LUNAK
PERENCANAAN PROYEK PERANGKAT LUNAK 3 Langkah Perencanaan : I. Pendefinisian masalah, II. Pengembangan strategi solusi, III. Rencana proses pengembangan. 2 I. Pendefinisian Masalah 1. Nyatakan masalah yang
Lebih terperinciBAB III ANALISIS. 3.1 Analisis Umum Sistem
BAB III ANALISIS Sesuai dengan isi dari bab pertama, tujuan tugas akhir ini adalah pembangunan aplikasi pertukaran informasi pada suatu jaringan knowledge base untuk pembaharuan informasi anggota jaringan
Lebih terperinciBAB II LANDASAN TEORI
BAB II LANDASAN TEORI 2.1 Sistem Informasi 2.1.1 Pengertian Sistem Informasi 1 Sistem Informasi adalah kombinasi dari teknologi dan aktivitas orang yang menggunakan teknologi itu untuk mendukung operasi
Lebih terperinciMI2193 PEMROGRAMAN WEB LANJUT PHP FRAMEWORK. Created by MTA Revised by HPU
MI2193 PEMROGRAMAN WEB LANJUT PHP FRAMEWORK Created by MTA Revised by HPU SET THE FRAME, GET TO WORK Arsitektur MVC Programming-in-large Pengembangan Berbasis Komponen Framework MODEL-VIEW-CONTROLLER (MVC)
Lebih terperinciBAB V STUDI KASUS. V.1 Deskripsi Umum Studi Kasus yang Dipilih
BAB V STUDI KASUS Pada bab ini dipaparkan mengenai studi kasus yang ditujukan untuk melakukan uji coba sebagai validasi terhadap KMS framework fokus pada manusia pada organisasi pembelajar yang telah dihasilkan.
Lebih terperinci: ENDRO HASSRIE NIM : MATKUL : REKAYASA PERANGKAT LUNAK PEMODELAN DATA
NAMA : ENDRO HASSRIE NIM : 41813120047 MATKUL : REKAYASA PERANGKAT LUNAK PEMODELAN DATA Pemodelan data (ER Diagram) adalah proses yang digunakan untuk mendefinisikan dan menganalisis kebutuhan data yang
Lebih terperinciBAB II TINJAUAN PUSTAKA. 2.1 Komponen Sumber Daya Manusia dalam Ruang Lingkup Fakultas. Nuraeny (2010) mengemuckakan bahwa Sumber Daya Manusia
BAB II TINJAUAN PUSTAKA 2.1 Komponen Sumber Daya Manusia dalam Ruang Lingkup Fakultas Nuraeny (2010) mengemuckakan bahwa Sumber Daya Manusia yang ada dalam ruang lingkup Universitas khususnya pada tiap
Lebih terperinciBAB III METODE PENELITIAN DAN PERANCANGAN SISTEM
BAB III METODE PENELITIAN DAN PERANCANGAN SISTEM 3.1 Metode Penelitian Metode penelitian yang digunakan dalam pembuatan sistem informasi ini yaitu : 3.1.1 Pembuatan Model Pembuatan sistem aplikasi web
Lebih terperinciPrinsip dan Konsep Desain Perangkat Lunak
Prinsip dan Konsep Desain Perangkat Lunak Desain adalah salah satu langkah dalam fase pengembangan bagi setiap produk atau sistem yang direkayasa. Desain dapat didefinisikan berbagai proses aplikasi berbagai
Lebih terperinciBAB V STUDI KASUS. Pada bab ini dilakukan studi kasus untuk menerapkan model komunitas belajar learnercentered hasil perancangan pada bab IV.
BAB V STUDI KASUS Pada bab ini dilakukan studi kasus untuk menerapkan model komunitas belajar learnercentered hasil perancangan pada bab IV. V.1 Deskripsi Umum Studi Kasus Studi kasus dipilih adalah forum
Lebih terperinciBAB 1 Service Oriented Architecture 1.1 Evolusi SOA
BAB 1 Service Oriented Architecture 1.1 Evolusi SOA Dengan melakukan penelusuran evolusi pola-pola integrasi, maka dapat ditunjukkan bahwa SOA merupakan teknik integrasi yang dibangun berdasarkan teknologi
Lebih terperinciBAB IV PERANCANGAN. IV.2 Perancangan Model Komunitas Belajar Learner-Centered
BAB IV PERANCANGAN Pada bab ini dilakukan perancangan model komunitas belajar dengan prinsip psikologis learner-centered sesuai dengan analisis yang telah dilakukan sebelumnya, berikut penjelasannya. IV.1
Lebih terperinciBAB IV ANALISIS DAN PERANCANGAN SISTEM. Analisis sistem merupakan suatu kegiatan penguraian dari suatu sistem yang
BAB IV ANALISIS DAN PERANCANGAN SISTEM 4.1 Analisis Sistem yang Berjalan Analisis sistem merupakan suatu kegiatan penguraian dari suatu sistem yang utuh ke dalam bagian-bagian komponennya dengan maksud
Lebih terperinciAPLIKASI BERBASIS WEB PEMETAAN INFORMASI PADA GAMBAR BITMAP
Media Informatika, Vol. 4, No. 1, Juni 2006, 13-26 ISSN: 0854-4743 APLIKASI BERBASIS WEB PEMETAAN INFORMASI PADA GAMBAR BITMAP M. Irfan Ashshidiq, M. Andri Setiawan, Fathul Wahid Jurusan Teknik Informatika,
Lebih terperinciMinggu 6 Prinsip & Konsep Desain
Minggu 6 Prinsip & Konsep Desain Terjemahan model analisis menjadi desain software Entity- Relationship Diagram Data Dictionary Data Flow Diagram procedural design interface design architectural design
Lebih terperinciPengenalan Obyek. Arna Fariza. Materi
Pengenalan Obyek Arna Fariza Materi Obyek Siklus pengembangan berorientasi obyek Metodologi berorientasi obyek Kelebihan metodologi berorientasi obyek 1 Obyek Obyek adalah tipe data komposit Menyimpan
Lebih terperinciBAB I PERSYARATAN PRODUK
BAB I PERSYARATAN PRODUK Pada bab ini berisi pendahuluan, tujuan, ruang lingkup proyek, definisi, dan gambaran produk. 1.1 PENDAHULUAN Teknologi hadir untuk memberikan kemudahan-kemudahan terhadap suatu
Lebih terperinciBAB 1 PENDAHULUAN. Dalam komunikasi tersebut baik yang berisi informasi maupun pemberitahuan
BAB 1 PENDAHULUAN 1.1 Latar Belakang Kampus dan Mahasiswa adalah dua element yang saling terikat dimana ada kampus disana pun harus ada mahasiswa sebagai pelengkap elementnya. Antara mahasiswa dan kampus
Lebih terperinciMAKALAH REKAYASA PERANGKAT LUNAK ( PEMODELAN DATA )
MAKALAH REKAYASA PERANGKAT LUNAK ( PEMODELAN DATA ) Disusun Oleh : MUKHAMAT JAFAR 41813120014 MATA KULIAH : REKAYASA PERANGKAT LUNAK DOSEN : WACHYU HARI HAJI, S.KOM, MM UNIVERSITAS MERCUBUANA 2015 Mukhamat
Lebih terperinciBAB III METODOLOGI PENELITIAN. dalam pengumpulan data atau informasi guna memecahkan permasalahan dan
BAB III METODOLOGI PENELITIAN 3.1 Metodologi Penelitian Metodologi penelitian adalah langkah dan prosedur yang akan dilakukan dalam pengumpulan data atau informasi guna memecahkan permasalahan dan menguji
Lebih terperinciBAB III ANALISA DAN PERANCANGAN
BAB III ANALISA DAN PERANCANGAN 3.1 Deskripsi Umum Perangkat Lunak Sistem informasi kost di sekitar Universitas Sebelas Maret ini memberikan informasi tentang kost kepada mahasiswa Universitas Sebelas
Lebih terperinciBAB III ANALISIS DAN PERANCANGAN
BAB III ANALISIS DAN PERANCANGAN Dalam bab ini akan diuraikan tentang penerapan steganografi pada file AVI serta analisis dan perancangan perangkat lunak yang akan dibangun. 1 Penerapan Steganografi pada
Lebih terperinci3.1 Ganesha Digital Library
BAB III ANALISIS Dalam bab ini akan dibahas mengenai analisis perangkat lunak yang akan dibangun. Analisis dilakukan pada sistem lama dan sistem baru. Analisis pada sistem lama meliputi penerapan folksonomy,
Lebih terperinciBAB IV ANALISIS DAN PERANCANGAN SISTEM. hasil analisis ini digambarkan dan didokumentasiakan dengan metodologi
BAB IV ANALISIS DAN PERANCANGAN SISTEM 4.1. Analisis Sistem yang Sedang Berjalan Kegiatan analisis sistem yang berjalan dilakukan dengan analisis yang berorientasi pada objek-objek yang diperlukan oleh
Lebih terperinciBAB IV PERANCANGAN. IV.2 Komponen Knowledge Management System Framework
BAB IV PERANCANGAN Pada bab ini dipaparkan rancangan KMS framework dengan fokus pada manusia pada organisasi pembelajar beserta penjelasan mengenai komponen-komponen yang terdapat pada framework tersebut,
Lebih terperinciBAB III LANDASAN TEORI. dengan istilah web adalah sebuah sistem terhubung dari hypertext document yang
10 BAB III LANDASAN TEORI 3.1 World Wide Web World Wide Web yang biasanya disingkat dengan WWW dan lebih dikenal dengan istilah web adalah sebuah sistem terhubung dari hypertext document yang ada di Internet.
Lebih terperinciBab 6 PERANCANGAN PERANGKAT LUNAK
Bab 6 PERANCANGAN PERANGKAT LUNAK Perancangan adalah proses untuk mengaplikasikan berbagai macam teknik dan prinsip untuk tujuan pendefenisian secara rinci suatu perangkat,proses atau sistem agar dapat
Lebih terperinciBAB IV ANALISIS DAN PERANCANGAN SISTEM
BAB IV ANALISIS DAN PERANCANGAN SISTEM 4.1 Analisis Sistem Yang Sedang Berjalan Sebelum merancang suatu sistem, ada baiknya terlebih dahulu kita menganalisis sistem yang sedang berjalan di perusahaan yang
Lebih terperinci3.1 APLIKASI YANG DITANGANI OLEH CODE GENERATOR
BAB III ANALISIS Bab ini berisi analisis mengenai aplikasi web target code generator, analisis penggunaan framework CodeIgniter dan analisis perangkat lunak code generator. 3.1 APLIKASI YANG DITANGANI
Lebih terperinciBAB I PENDAHULUAN. pesat terutama perkembangan internet. Dengan adanya internet dapat
BAB I PENDAHULUAN 1.1 LATAR BELAKANG MASALAH Perkembangan teknologi informasi dan komunikasi saat ini berkembang pesat terutama perkembangan internet. Dengan adanya internet dapat memudahkan penyebaran
Lebih terperinciBAB II LANDASAN TEORI. bidang media komunikasi dan informasi. Internet adalah suatu jaringan komputer
BAB II LANDASAN TEORI 2.1 World Wide Web Dunia internet semakin berkembang, terutama penggunaanya dalam bidang media komunikasi dan informasi. Internet adalah suatu jaringan komputer global, sedangkan
Lebih terperinciBAB IV ANALISA DAN PERANCANGAN SISTEM. Adapun analisis sistem akan dilakukan pada bagian gudang ruang lingkup
BAB IV ANALISA DAN PERANCANGAN SISTEM 4.1. Analisis Sistem Yang Berjalan Adapun analisis sistem akan dilakukan pada bagian gudang ruang lingkup kegiatannya diantaranya adalah melakukan pemesanan barang,
Lebih terperinciLEMBAR PENGESAHAN ABSTRACT
DAFTAR ISI LEMBAR PENGESAHAN ABSTRACT... ABSTRAK... KATA PENGANTAR... DAFTAR ISI... DAFTAR TABEL... DAFTAR GAMBAR... DAFTAR SIMBOL... DAFTAR LAMPIRAN... BAB I PENDAHULUAN 1.1 Latar Belakang Masalah...
Lebih terperinciBAB I PENDAHULUAN. Kehidupan manusia tidak lepas dari penggunaan internet, dikarenakan akses internet era sekarang penggunaannya cukup mudah.
BAB I PENDAHULUAN A. Latar Belakang Kehidupan manusia tidak lepas dari penggunaan internet, dikarenakan akses internet era sekarang penggunaannya cukup mudah. Dalam penggunaan internet, manusia akan memperoleh
Lebih terperinciPERANGKAT LUNAK PENJUALAN BERBASIS WEB (E-COMMERCE) DI PETERNAKAN AYAM HIAS PARENGNA
PERANGKAT LUNAK PENJUALAN BERBASIS WEB (E-COMMERCE) DI PETERNAKAN AYAM HIAS PARENGNA 1 H Agus Salim, 2 Hermawan Julianto 1 Program Studi Manajemen Informatika PKN LPKIA 2 Program Studi Teknik Informatika
Lebih terperinciBAB II LANDASAN TEORI
BAB II LANDASAN TEORI II.1. Sistem Informasi Sistem informasi adalah sekumpulan elemen yang saling bekerja sama baik secara manual atau berbasis komputer yang didalamnya ada pengumpulan, pengolahan, pemprosesan
Lebih terperinciBAB II TINJAUAN PUSTAKA DAN LANDASAN TEORI
2.1 Tinjauan Teori BAB II TINJAUAN PUSTAKA DAN LANDASAN TEORI Penelitian yang berhubungan dengan topik yang penulis bahas adalah Sistem Lelang On-Line Perum Pegadaian Jatisrono.(Hidayah, 2013). Pada topik
Lebih terperinciBAB IV ANALISIS DAN PERANCANGAN SISTEM. permasalahan dari suatu sistem informasi. Hasil akhir dari analisis sistem
BAB IV ANALISIS DAN PERANCANGAN SISTEM 4.1. Analisis yang Berjalan Analisis sistem merupakan proses memilah-milah suatu permasalahan menjadi elemen-elemen yang lebih kecil untuk dipelajari guna mempermudah
Lebih terperinciBAB III ANALISIS DAN PERANCANGAN
BAB III ANALISIS DAN PERANCANGAN Bab ini akan membahas analisis dan perancangan perangkat lunak yang akan dikembangkan pada tugas akhir ini. Dalam bagian analisis akan diidentifikasi hal-hal yang diperlukan
Lebih terperinciBAB IV ANALISIS DAN PERANCANGAN SISTEM. dihadapi. Dan agar mempermudah dalam pembuatan perancangan sistem yang
BAB IV ANALISIS DAN PERANCANGAN SISTEM 4.1 Analisis Sistem Yang Berjalan Analisis Sistem yang berjalan bertujuan untuk mengetahui lebih jelas bagaimana kondisi sebuah sistem yang sedang berjalan saat ini
Lebih terperinciBAB IV ANALISIS DAN PERANCANGAN APLIKASI KMS KLUB SEPAKBOLA
BAB IV ANALISIS DAN PERANCANGAN APLIKASI KMS KLUB SEPAKBOLA 4.1 Analisis Aplikasi KMS untuk Klub Sepakbola Subbab ini bertujuan mendefiniskan spesifikasi aplikasi KMS Spesifikasi tersebut menjadi dasar
Lebih terperinciBAB III ANALISIS DAN PERANCANGAN SISTEM. informasi akademik pada SMP Al-Falah Assalam Tropodo 2 Sidoarjo. Tahaptahap
BAB III ANALISIS DAN PERANCANGAN SISTEM Pada bab ini akan dibahas tentang tahapan dan perencanaan desain sistem informasi akademik pada SMP Al-Falah Assalam Tropodo 2 Sidoarjo. Tahaptahap tersebut terdiri
Lebih terperinciArsitektur Sistem Informasi. Tantri Hidayati Sinaga, M.Kom.
Arsitektur Sistem Informasi Tantri Hidayati Sinaga, M.Kom. Desain Sistem "Desain sistem dapat didefinisikan sebagai penggambaran dan pembuatan sketsa atau pengaturan dari beberapa elemen yang terpisah
Lebih terperinciJenis Metode Pengembangan Perangkat Lunak
Jenis Metode Pengembangan Perangkat Lunak by webmaster - Tuesday, January 05, 2016 http://anisam.student.akademitelkom.ac.id/?p=123 Menurut IEEE, Pengembangan software (software engineering ) adalah :
Lebih terperinciBAB IV PERANCANGAN SISTEM 4.1 PERANCANGAN SISTEM Untuk memudahkan pembuatan aplikasi sistem pakar berbasis website, maka akan dibuat model menggunakan UML (Unified Modeling Language). Perlu diketahui metode
Lebih terperinciBAB II LANDASAN TEORI
BAB II LANDASAN TEORI 2.1 Sistem Menurut Herlambang dan Tanuwijaya (2005: 116) definisi sistem dapat dibagi menjadi dua pendekatan, yaitu pendekatan secara prosedur dan pendekatan secara komponen. Berdasarkan
Lebih terperinci1 BAB III OBJEK DAN METODE PENELITIAN
1 BAB III OBJEK DAN METODE PENELITIAN 3.1 Objek Penelitian Objek penelitian merupakan hal awal (suatu permasalahan) yang harus ditentukan dalam kegiatan penelitian sehingga penelitian dapat dilakukan secara
Lebih terperinciBAB III LANDASAN TEORI. Flippo (1984) mendefinisikan sebagai berikut: Penarikan calon pegawai
BAB III LANDASAN TEORI 1. 3.1 Rekrutmen Flippo (1984) mendefinisikan sebagai berikut: Penarikan calon pegawai atau tenaga kerja adalah proses pencarian tenaga kerja yang dilakukan secara seksama, sehingga
Lebih terperinciBAB I PERSYARATAN PRODUK
1 BAB I PERSYARATAN PRODUK 1.1 Pendahuluan Penelitian kali ini dilakukan pada perusahaan retail yang berada di kota Bandung. Pada perusahaan tersebut terdapat 2 main group yang berbeda di dalamnya yaitu
Lebih terperinciBAB III ANALISA DAN PERANCANGAN SISTEM. permasalahan yang ada sebagai dasar untuk membuat sebuah solusi yang
BAB III ANALISA DAN PERANCANGAN SISTEM 3.1 Analisis Masalah Langkah awal dalam pembuatan sistem adalah mengidentifikasi permasalahan yang ada sebagai dasar untuk membuat sebuah solusi yang disajikan dalam
Lebih terperinciBAB 1 PENDAHULUAN. 1.1 Latar Belakang
BAB 1 PENDAHULUAN 1.1 Latar Belakang Sistem operasi untuk aplikasi bergerak yang mengalami perkembangan yang cukup pesat yaitu Android. Android adalah sistem operasi berbasis Linux dan bersifat open source.
Lebih terperinciPENGUJIAN BERORIENTASI OBJEK
PENGUJIAN BERORIENTASI OBJEK Tujuan pengujian tetap yaitu untuk menemukan kesalahan dalam selang waktu yang realistik Mengubah strategi dan taktik pengujian Ada tiga hal yang harus diperhatikan : Definisi
Lebih terperinciAnalisis dan desain model
Rekayasa Perangkat Lunak Semester Gasal 2009/2010 Bahan Ajar Rekayasa Perangkat Lunak Konsep Desain Software Analisis dan desain model Setelah kebutuhan dikumpulkan, analisis terhadap kebutuhan dilakukan
Lebih terperinciPENGGUNAAN PARADIGMA SOA (SERVICE ORIENTED ARCHITECTURE) UNTUK MEREALISASIKAN INTEROPERABILITAS DAN INTEGRITAS SISTEM INFORMASI.
Media Informatika Vol. 11 No. 1 (2012) PENGGUNAAN PARADIGMA SOA (SERVICE ORIENTED ARCHITECTURE) UNTUK MEREALISASIKAN INTEROPERABILITAS DAN INTEGRITAS SISTEM INFORMASI Rini Astuti Sekolah Tinggi Manajemen
Lebih terperinciBAB 1 PENDAHULUAN 1.1. Latar Belakang Masalah
BAB 1 PENDAHULUAN 1.1. Latar Belakang Masalah PT United Tractors,Tbk perwakilan Bandung merupakan distributor peralatan berat terbesar dan terkemuka di Indonesia, menyediakan produk-produk dari merek ternama
Lebih terperinciBAB II TINJAUAN PUSTAKA DAN LANDASAN TEORI
BAB II TINJAUAN PUSTAKA DAN LANDASAN TEORI 2.1 Tinjauan Pustaka Dalam pembuatan tugas akhir Sistem Informasi Administrasi Salon SN berbasis desktop ini dilakukan beberapa tinjauan sumber pustaka, dan berikut
Lebih terperinciSOFTWARE TESTING. Ratna Wardani
SOFTWARE TESTING Ratna Wardani Capaian Memahami pentingnya Software Testing Memahami teknik dalam Software Testing Dasar-dasar Software Testing Teknik-teknik dalam Software Testing Here we go... Dasar-dasar
Lebih terperinciUKDW BAB 1 PENDAHULUAN. 1.1 Latar Belakang Masalah
BAB 1 PENDAHULUAN 1.1 Latar Belakang Masalah Gereja HKTY Ganjuran adalah salah satu gereja katolik yang terletak di dusun Ganjuran, Sumbermulyo Bambanglipuro, Bantul. Gereja ini dibangun pada tahun 1924
Lebih terperinciDASAR REKAYASA PERANGKAT LUNAK
DASAR REKAYASA PERANGKAT LUNAK PEMODELAN ANALISIS KEBUTUHAN Institut Teknologi Sumatera DEFINISI MODEL ANALISIS Menurut Ian Sommerville(2011) Model Analisis adalah suatu teknik untuk merepresentasikan
Lebih terperinci1BAB I PENDAHULUAN 1.1 Latar Belakang
BAB I 1 PENDAHULUAN 1.1 Latar Belakang Untuk mencapai hasil kerja yang baik dalam sebuah kelompok kerja, tentu dibutuhkan komunikasi yang baik pula diantara anggotanya. Komunikasi berkaitan erat dengan
Lebih terperinciBAB II LANDASAN TEORI. digunakan untuk memodelkan kebutuhan data dari suatu organisasi,
BAB II LANDASAN TEORI 2.1 Entity Relationship Diagram Entity Relationship Diagram (ERD) merupakan teknik yang digunakan untuk memodelkan kebutuhan data dari suatu organisasi, biasanya oleh System Analys
Lebih terperinciREKAYASA PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK PENDAHULUAN 1. Apakah Perangkat Lunak? 2. Apakah Rekayasa Perangkat Lunak (RPL)? 3. Apa perbedaan antara RPL dengan ilmu komputer (computer science)? 4. Apa perbedaan RPL dan rekayasa
Lebih terperinciBAB I PENDAHULUAN 1.1 Latar Belakang
BAB I PENDAHULUAN 1.1 Latar Belakang Menurut Pressman (2012) tujuan dari pengujian adalah untuk menemukan dan memperbaiki sebanyak mungkin kesalahan dalam program sebelum menyerahkan program kepada pelanggan.
Lebih terperinciBAB IV ANALISIS DAN PERANCANGAN SISTEM. yang manual, yaitu dengan melakukan pembukuan untuk seluruh data dan
BAB IV ANALISIS DAN PERANCANGAN SISTEM 4.1. Analisis Sistem Yang Sedang Berjalan Saat ini, sistem peminjaman dan pengembalian buku yang dilakukan di perpustakaan SMA Karya Pembangunan 2 Bangun masih menggunakan
Lebih terperinciBAB 1 PENDAHULUAN. Era teknologi informasi yang semakin pesat membawa dampak besar bagi
BAB 1 PENDAHULUAN 1.1 Latar Belakang Era teknologi informasi yang semakin pesat membawa dampak besar bagi berbagai aspek kehidupan. Berbagai usaha dilakukan seperti perbaikan terhadap materi perkuliahan,
Lebih terperinciBAB IV ANALISIS, PERANCANGAN, DAN IMPLEMENTASI PERANGKAT LUNAK
BAB IV ANALISIS, PERANCANGAN, DAN IMPLEMENTASI PERANGKAT LUNAK Pada bab ini akan dibahas berbagai hal yang terkait analisis dan perancangan perangkat lunak web mining yang diusulkan sebagai solusi permasalahan.
Lebih terperinciBAB I PERSYARATAN PRODUK
BAB I PERSYARATAN PRODUK I.1 Pendahuluan Teknologi informasi dalam segala bidang sangat dibutuhkan. Khususnya bidang pendidikan dalam pengembangan kemampuan berbahasa pemrograman. Media komunikasi yang
Lebih terperinciBAB III METODE PENELITIAN
BAB III METODE PENELITIAN 3.1. Analisis Sistem Analisa sistem digunakan untuk menguraikan sistem yang diidenfikasi dan dievaluasi permasalahannya. Sistem ini dianalisis untuk membuat rancangan spesifikasi
Lebih terperinciBAB 1 PENDAHULUAN Latar Belakang
BAB 1 PENDAHULUAN Pada bab ini, akan dijelaskan mengenai pendahuluan, rumusan masalah,tujuan, batasan yang dikerjakan, hipotesis, metodologi penyelesaian masalah, sistematika penulisan, dan jadwal pengerjaan
Lebih terperinciBAB IV ANALISIS DAN PERANCANGAN SISTEM. di PT. POS INDONESIA khususnya pada layanan POS Express sudah
BAB IV ANALISIS DAN PERANCANGAN SISTEM 4.1. Analisis Sistem yang Berjalan Dari hasil studi di lapangan menunjukan bahwa sistem yang sedang berjalan di PT. POS INDONESIA khususnya pada layanan POS Express
Lebih terperinciREKAYASA PERANGKAT LUNAK. 3 sks Sri Rezeki Candra Nursari reezeki2011.wordpress.com
REKAYASA PERANGKAT LUNAK 3 sks Sri Rezeki Candra Nursari reezeki2011.wordpress.com Referensi Rekayasa Perangkat Lunak Pendekatan Praktisi, Roger S. Pressman, Ph.D, Andi Jogyakarta, 2012 Buku 1 Rekayasa
Lebih terperinciBAB 2 LANDASAN TEORI
BAB 2 LANDASAN TEORI 2.1 Teori-teori Umum 2.1.1 Pengertian Sistem Menurut Mulyadi (2001,P2) : Sistem adalah sekelompok unsur yang erat berhubungan satu dengan lainnya, yang berfungsi bersama-sama untuk
Lebih terperinciPENGANTAR RUP & UML. Pertemuan 2
PENGANTAR RUP & UML Pertemuan 2 PENGANTAR RUP Rational Unified Process (RUP) atau dikenal juga dengan proses iteratif dan incremental merupakan sebuah pengembangan perangkat lunak yang dilakukan secara
Lebih terperinciBAB III OBJEK DAN METODE PENELITIAN. domain & Web Hosting. Untuk lebih jelas mengenai gambaran umum perusahaan,
BAB III OBJEK DAN METODE PENELITIAN 3.1. Objek Penelitian Penulis melakukan objek penelitian pada Qwords.com perusahaan penyedia jasa layanan Web Hosting (Web Hosting Provider) yang melayani registrasi
Lebih terperinciBAB III LANDASAN TEORI. Pembayaran dapat dilakukan secara tunai maupun kredit. Menjual atau penjualan
BAB III LANDASAN TEORI Landasan teori merupakan dasar-dasar yang digunakan dalam pembuatan kerja praktek. Sebagai langkah awal menyusun Laporan Kerja Praktek perlu dipahami terlebih dahulu mengenai manajemen
Lebih terperinciAnalisis dan Perancangan Sistem II T02 Use Case
Analisis dan Perancangan Sistem II T02 Use Case Disusun O L E H Elsita S.N 04.05.2569 Institut Sains & Teknologi Akprind Yogyakarta 2006/2007 Bagian-bagian utama dari UML adalah view, diagram, model element,
Lebih terperinciBAB III ANALISA DAN PERANCANGAN
28 BAB III ANALISA DAN PERANCANGAN 3.1 Perancangan Sistem 3.1.1 Tujuan Dan Ruang Lingkup Sistem Perangkat Lunak Perangkat Lunak (software) adalah komponen dalam data processing sistem yang berupa program-program
Lebih terperinciBAB IV ANALISA DAN PERANCANGAN SISTEM. diusulkan dari sistem yang ada di Dinas Kebudayaan dan Pariwisata Kota
BAB IV ANALISA DAN PERANCANGAN SISTEM 4.1. Analisis Sistem yang Sedang Berjalan Pada bab ini dijelaskan mengenai prosedur yang berjalan dan yang diusulkan dari sistem yang ada di Dinas Kebudayaan dan Pariwisata
Lebih terperinciRancang Bangun Sistem Informasi E-Learning Berbasis Web di SMK Negeri 1 Tangerang
Rancang Bangun Sistem Informasi E-Learning Berbasis Web di SMK Negeri 1 Tangerang Hilmi Fuad 1, Zainul Hakim 2, Pramana Anwas Panchadria 3 1,2 Dosen STMIK Bina Sarana Global, 3 Mahasiswa STMIK Bina Sarana
Lebih terperinciBAB IV ANALISIS SISTEM DAN PERANCANGAN
BAB IV ANALISIS SISTEM DAN PERANCANGAN 4.1 Analisa system Pada bagian ini akan dibahas mengenai system yang sedang berjalan ditinjau terutama dari segi proses. Pada pemodelan system antar muka (interface
Lebih terperinciBAB I PENDAHULUAN I-1
BAB I PENDAHULUAN Pada bagian ini akan dijelaskan tentang pendahuluan dalam penyusunan Laporan Penelitian. Pendahuluan meliputi latar belakang masalah, rumusan masalah, maksud dan tujuan penelitian, batasan
Lebih terperinciBAB 1 PENDAHULUAN. 1.1 Latar Belakang
BAB 1 PENDAHULUAN 1.1 Latar Belakang Dinas Pendidikan Kabupaten Majalengka Provinsi Jawa Barat memiliki sejumlah tugas, diantaranya melakukan pengelolaan aset atau barang milik daerah meliputi 6 ketegori
Lebih terperinciBAB 3 METODE PENELITIAN
BAB 3 METODE PENELITIAN Untuk mendapatkan hasil yang baik dalam sebuah penelitian, diperlukan perencanaan yang rapi, pengelolaan yang benar, pengolahan berbagai kebutuhan penelitian dan penggunaan metode
Lebih terperinciBAB 1 PENDAHULUAN.
BAB 1 PENDAHULUAN 1.1. Latar Belakang PT Telkom Sigma merupakan sebuah perusahaan yang bergerak telekomunikasi. Pada saat ini perusahaan menggunakan sebuah aplikasi yang berfungsi untuk melakukan proses
Lebih terperinci