Interaksi Manusia dan Komputer Proses Desain

Rekayasa Perangkat Lunak Rekayasa perangkat lunak merupakan disiplin ilmu yang digunakan untuk memahami proses desain atau siklus desain. Desain perangkat lunak merupakan proses interaksi melalui “Cetak Biru” yang menggambarkan suatu pandangan menyeluruh dari perangkat lunak yang akan dikembangkan/bangun, meliputi : proses desain pada tingkat abstraksi yang tinggi, yang dapat ditelusuri sampai data spesifik, fungsional dan lainya

Siklus Hidup Perangkat Lunak

Roles Played by the Manager and by the Information Specialist Phase Manager Information Specialist Planning Define problem Support Analysis Control System Study Design Control Design system Implementation Control Implement system Use Control Make available 1-4

Phases in the SDLC 1) Planning 2) Analysis 3) Design 4) Implementation 5) Use 7-5

Planning Phase Benefits Define scope of the project Spot potential problems Arrange tasks in sequence Provide basis for control 7-6 7

Steps 1. Recognize problem (the trigger) 2. Define problem 3. Set objectives 4. Identify constraints Recall that objectives, standards, and constraints are problem-solving elements. 7-7 8

Steps (cont.) 5. Conduct feasibility study (TENLOS) Technical Economic return Noneconomic return Legal and ethical Operational Schedule 7-8 9

Steps (cont.) 6. Prepare study project proposal Goes to MIS steering committee 7. Approve or disapprove (go/no go) Key questions? 1. Will the system accomplish its goals? 2. Is this the best way to go about it? 7-9 10

Steps (cont.) 8. Establish a control mechanism Think in terms of: 1. What 2. Who 3. When (Person-months versus calendar months) PERT and CPM network diagrams PERT (Program evaluation and review technique) CPM (Critical Peth Methode) 7-10 11

The Planning Phase 1. 2. Consult 3. 4. 5. 6. 7. 8. MIS Steering Comm Manager Systems Analyst Recognize the problem 1. Define the problem 2. Set system objectives 3. Consult 4. Identify system constraints Conduct a feasibility study 5. Prepare a system study proposal 6. 7. Approve or disapprove the study project Establish a control mechanism 8. 7-11 12

The Analysis Phase Prepare design proposal MIS Steering Committee Manager Systems Analyst Announce the system study Organize the project team Define information needs Define system performance criteria Prepare design proposal Approve or disapprove the design project 1. 2. 3. 4. 5. 6. 7-12 20

The Design Phase MIS Steering Committee Manager Systems Analyst 1. 2. Prepare the detailed design system The Design Phase 2. Identify alternate system configurations 3. Evaluate system configurations 4. Select the best configuration 5. Prepare the implementation proposal Approve or disapprove the system implementation 6. 7-13 22

The Implementation Phase MIS Steering Committee Manager Information Specialists Plan the implementation 1. 2. Announce the implementation 3 Obtain the hardware resources Control Control 4 Obtain the software resources 5 Prepare the database 6 Prepare the physical facilities 7 Educate the participants and users 8. Cutover the new system 7-14 35

The Use Phase MIS Steering Committee Manager Information Specialists 2 Audit the system 1 Use the system Control 3 Maintain the system 4 Prepare re- engineering proposal Approve or disapprove the reengineering proposal 5 7-15

Siklus Hidup Perangkat Lunak

Siklus Hidup Perangkat Lunak Model air terjun (waterfall)

Siklus Hidup Perangkat Lunak Requirements analysis and spesification Mengumpulkan apa yang dibutuhkan secara lengkap untuk kemudian dinalisis guna mendefinisikan kebutuhan yang harus dipenuhi oleh program yang akan dibangun (fase yang harus dikerjakan untuk menghasilkan desain lengkap). System and software desain setelah apa yang dibutuhkan selesai dikumpulkan dan sudah lengkap maka desain kemudian dikerjakan. Implementation and unit testing desain program diterjemahkan kedalam kode-kode dengan menggunakan bahasa pemrograman yang sudah ditentukan. Program yang dibangun langsung diuji secara unit. Bekerja dengan baik atau tidak

Siklus Hidup Perangkat Lunak Integration and system testing penyatuan unit-unit program untuk kemudian diuji secara keseluruhan (system testing) Operation and maintenance mengoperasikan program dilingkungannya dengan melakukan pemeliharaan, seperti penyesuaian atau perubahan untuk adaptasi dengan situasi yang sebenarnya.

KEKURANGAN MODEL WATERFALL KAKU  Fase berikutnya dapat dikerjakan apabila fase sebelumnya sudah lengkap Perubahan-Perubahan sulit diakomodasi Pada kenyataanya jarang sekali mitra/pengguna dapat menyusun kebutuhanya secara lengkap Proyek besar sebaiknya dipecah menjadi sub-proyek sehingga dapat dikerjakan di beberapa tempat

Aktifitas Dalam Siklus Hidup Spesifikasi Kebutuhan Desainer dan pengguna (customer) mencoba untuk menangkap apa yang di harapkan pada suatu sistem untuk ada/tersedia Dapat dinyatakan dalam bahasa alami/sehari-hari atau bahasa yang labih presisi seperti halnya analisis tugas yang akan di sediakan Desain Arsitektur Deskripsi tingkat tinggi tentang bagaimana suatu sistem akan menyediakan pelayanan yang dibutuhkan Memilah sistem kedalam komponen-komponen utama sistem dan bagaimana mereka saling berhubungan Perlu untuk memenuhi baik kebutuhan fungsional maupun yang non fungsional Desain Detail Penghalusan komponen-komponen arsitektur dan hubungannya untuk mengidentifikasi modul-modul yang akan diimplementasikan secara terpisah Penghalusan ditentukan oleh kebutuhan-kebutuhan non fungsional

Aktifitas Dalam Siklus Hidup Pengkodean dan Test Unit Implementasi dan Pengetesan modul-modul individu dalam suatu bahasa pemrograman yang dapat dieksekusi Integrasi dan Pengetesan Mengkombinasikan modul-modul untuk menghasilkan komponen-komponen dari deskripsi arsitektur Operasi dan Pemeliharaan Produk diantarkan kepada pengguna (customer) dan semua masalah / perbaikan disediakan oleh desainer saat produk tersebut masih dipakai Bagian terbesar dari siklus hidup

Verifikasi dan Vasilidasi Pendesainan produk secara benar Validasi Pendesainan produk yang benar Jurang formalitas Validasi akan selalu bergantung pada beberapa perluasan arti subjektif dari bukti yang ada Manajemen dan Masalah Kontrak Desain dalam konteks komersial dan legal

Model Evaluasi Proses Software

Model Evaluasi Proses Software Model evaluasi proses software bersifat iteratif atau mengandung perulangan. Hasil proses berupa produk yang semakin lama semakin lengkap hingga versi terlengkap dihasilkan sebagai produk akhir. Dua model dalam evolutionary software process model. <!>Perbaikan dari Model Waterfall yang kaku dan linear. Waterfall cocok dipakai pada Sistem Besar dan dibagi menjadi beberapa sub-proyek.

Incremental Model (evolusionary)

Incremental Model Kombinasikan elemen-elemen dari waterfall dengan sifat iterasi/perulangan. Elemen-elemen dalam wateerfall dikerjakan dengan hasil yang berupa produk dengan spesifikasi tertentu dan fase berulang hingga menghasilkan produk Final. Produk hasil inkrementasi pertama biasanya adalah produk inti (core product) yaitu produk yang memenuhi kebutuhan dasar. Hasil review akan menjadi bekal untuk pembangunan pada inkrementasi berikutnya. Model ini cocok jika jumlah anggota tim pengembang/pengembang PL tidak cukup. Mampu mengakomodasi perubahan secara fleksibel. Produk yang dihasilkan pada inkrementasi pertama adalah produk yang sudah bisa berfungsi dengan spesifikasi dasar. Mungkin terjadi kesulitan memetakan kebutuhan pengguna.

2. Spiral Model

Spiral Model Proses digambarkan sebagai spiral. Setiap loop mewakili suatu fase dari proses software. Loop paling dalam berfokus pada kelayakan sistem, loop selanjutnya tentang definisis kebutuhan, loop berikutnya lagi berkaitan dengan desain sistem dan seterusnya. Setiap loop dibagi menjadi beberapa sektor : a. Objective settings (menentukan tujuan) Menentukan tujuan dari fase yang ditentukan. Perencanaan sudah disiapkan. b. Risk assesment and reduction (penanganan dan pengurangan resiko). setiap risiko dianalisis secara detail pada sektor ini. Langkah penanganan dilakukan, misalnya membuat prototipe.

Spiral Model c. Development and Validation (Pembangunan dan pengujian) setelah evaluasi risiko maka model pengembangan sistem dipilih. Misalnya jika resiko user interface dominan maka dibuatkan prototipe user interface. d. Planning proyek dievaluasi atau ditinjau ulang dan diputuskan untuk terus ke fase selanjutnya atai tidak. Pada model spiral, risiko sangat dipertimbangkan. Risiko adalah sesuatu yang mungkin akan mengakibatkan terjadinya kesalahan. Model spiral merupakan pendekatan yang realistis untuk PL berskala besar.

RAD (Rapid Aplication Development) RAD adalah model proses pembangunan PL yang inkremental. RAD menekankan pada siklus pembangunan yang pendek/singkat. RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction. Waktu yang singkat adalah batasan yang penting untuk model ini. Jika kebutuhan lengkap dan jelas maka waktu yang dibutuhkan untuk menyelesaikan secara komplet software yang dibuat adalah misalnya 60 sampai 90 hari.

Fase-Fase RAD (Rapid Aplication Development) Business Modelling : Menjawab pertanyaan: Informasi apa yang mengendalikan proses bisnis? Informasi apa yang dihasilkan? Siapa yang menghasilkan informasi? Kemana informasi itu diberikan? Siapa yang mengolah informasi? – (Kebutuhan dari Sistem) Data Modelling : Aliran informasi yang sudah didefinisikan disusun menjadi sekumpulan objek data – (Analisis Kebutuhan dan Data) Pocess Modelling: Objek data yang sudah didefinisikan diubah menjadi aliran informasi yang diperlukan untuk menjalankan fungsi-fungsi bisnis. Application Generation: RAD menggunakan komponen program yang sudah ada atau membuat komponen yang bisa digunakan lagi Testing dan Turnover: Komponen yang sudah ada sudah melalui pengujian. Namun demikian komponen baru dan interface harus tetap diuji.

Menggunakan Aturan Desain Aturan desain menyarankan bagaimana meningkatkan tingkat kegunaan

Menggunakan aturan desain Standar Diatur oleh organisasi nasional atau internasional seperti ISO atau BSI untuk memastikan kepastian pemenuhan syarat-syarat tertentu oleh komunitas besar para desainer Standar memerlukan teori mendasar dan secara pelan mengubah teknologi Standar perangkat keras berdasarkan faktor fisiologi atau ergonomi Standar perangkat lunak pada faktor psikologi dan teori kognitif Standar perangkat keras lebih umum digunakan dibandingkan dengan standar perangkat lunak Perangkat keras harga cenderung mahal dan sulit untuk diubah Otoritas tinggi dan level rendah detil ISO 9241 mendefinisikan tingkat kegunaan/daya guna sebagi keefektifan, efisiensi dan kepuasan dengan mana pengguna menyelesaikan suatu tugas

Refresh..... Daya Guna/ Usability ATRIBUT daya guna terdiri dari: EFEKTIVITAS : Seberapa tepat, lengkap dan akurat seorang user dapat mencapai tujuan EFISIENSI : Resource yang dikeluarkan oleh seorang user untuk melakukan dan mencapai tujuan dengan cepat dan tepat tanpa ada pemborosan KEPUASAN : Respons dari user berupa kenyamanan penggunaan dan sikap positif dalam menggunakan produk. Efektif dan efisien mempunyai tujuan yang sama yaitu meningkatkan kinerja organisasi. Efisien adalah bekerja dengan menggunakan sumber daya dan energi yang sesuai tanpa pemborosan. Efektif adalah melakukan sesuatu yang sesuai dengan apa yang diinginkan dengan tepat.

Menggunakan aturan desain Garis Pedoman (guidelines) Lebih bersifat saran dan umum Banyak buku teks dan laporan penuh berisikan garis pedoman Abstrak dari garis pedoman (prinsip) dapat digunakan selama aktifitas awal siklus hidup Garis pedoman detil (petunjuk gaya – style guides) dapat digunakan selama aktifitas siklus hidup lebih lanjut Pemahaman pembeneran untuk garis pedoman ini akan membantu dalam hal penyelesaian konflik yang terjadi

Rekayasa Tingkat Kegunaan Tes akhir tingkat kegunaan berdasarkan pada pengukuran pengalaman pengguna Rekayasa tingkat kegunaan meminta pengukuran tingkat kegunaan spesifik harus dibuat secara eksplisit/jelas sebagai suatu kebutuhan Spesifikasi tingkat kegunaan : Atribut / prinsip tingkat kegunaan Konsep pengukuran Metode pengukuran Level kekinian/kasus terburuk/level perencanaan/kasus terbaik Permasalahan Spesifikasi tingkat kegunaan membutuhkan level detil yang mungkin tidak bisa didapat di awal desain Pemenuhan spesifikasi tingkat kegunaan tidak berarti harus memenuhi tingkat kegunaan itu sendiri

Dasar Pemikiran Desain

Dasar Pemikiran Desain Dasar pemikiran desain adalah informasi yang menjelaskan mengapa suatu sistem komputer seperti itu adanya. 1. Keuntungan-keuntungan dari dasar pemikiran desain: a. Komunikasi melalui siklus hidup b. Penggunaan kembali pengetahuan desain melintasi produk-produk c. Pelaksanaan disiplin desain d. Merepresentasikan argumen untuk nilai yang harus dibayar untuk desain 2. Orientasi proses, menjaga urutan pertimbangan dan pembuatan keputusan 3. Orientasi struktur, penekanan pada struktur post hoc alternatif desain

Teknik-teknik dasar pemikiran desain Sistem informasi berbasis Issue (Issue-based Inf. Sys) Berdasar hasil banyak riset Berorientasi proses Struktur hierarki issue-issue Posisi adalah pemecahan potensial issue Argumen memodifikasi hubungan diantara issue Analisis ruang desain Berorientasi struktur Dasar pemikiran psikologis Skenario diobservasi pada sistem Klaim psikologis sistem dibuat secara ekplisit Aspek negatif desain digunakan iterasi desain selanjutnya

Prototipe

Desain Berulang dan Prototype Desain berulang (iteratif) mengatasi permasalahan yang melekat pada kebutuhan yang tidak lengkap dan sebagai bentuk evaluasi daya guna untuk mendapatkan umpan balik dengan membangun dan mengevaluasi Prototype Prototipe Simulasi atau animasi dari beberapa fitur dari bakal sistem Berbagai jenis prototipe Throw-away (sekali pakai, buang) Incrementasi (bertingkat) Evolutionary (evolusi) Masalah Manajemen Waktu Perencanaan Fitur non – fungsional kontrak

Teknik Prototipe Storyboard (papan cerita) Tidak perlu harus berbasis komputer Dapat dianimasikan Simulasi fungsional terbatas Beberapa bagian dari fungsionalitas sistem disediakan oleh desainer Perkakas seperti HyperCard banyak dijumpai sekarang ini Teknik dari Wizard of Oz Peringatan mengenai desain berulang Kelembaman desain – keputusan yang mulanya buruk akan tetap jadi buruk Pendiagnosisan permasalahan derajat kegunaan nyata dalam prototipe dan bukan hanya sekedar gejala-gejalanya

Prototype design prototipe evaluate done Re design OK? design prototipe evaluate done Re design Gambar. Prototipe dan evaluasi

Kertas Mock Ups Kertas mock ups merupakan suatu desain prototipe yang dirancang diatas kertas yang meliputi elemen-elemennya. Yang pertama dilakukan adalah membuat sketsa diatas kertas desaindan mengimplementasikannya dikomputer dan memberikan print out yang lebih terperinci. Proses ini penting untuk dilakukan sebelum menggunakan komputer, untuk mengurangi waktu yang digunakan mendesain sistem.

Kertas Mock-Up – Sketsa interaktif

Mengerjakan Prototipe Dalam kasus tertentu working prototipe hanya dibuat dengan menggunakan algoritma yang sederhana. Menggunakan data fake, seperti gambar bukan video atau lainnya. Teknik wizard of oz untuk menampilkan suatu simulasi interface dan responnya. Working prototipe bertujuan memberikan suatu gambaran tentag sistem yang akan dibangun. Skenario dari suatu prototipe adalah sepertiga dari keseluruhan sistem yang alan dibangun.

Proses Prototype

Vertical prototype Horizontal Prototype Skenario Prototype Kemampuan sistem hanya ditampilkan sebagian Horizontal Prototype Semua interface ditampilkan tetapi kemampuanya tidak ditampilkan Skenario Prototype Hanya menampilkan sebagian fitur dan fungsi <!> Skenario adalah uraian interaksi manusia dengan komputer dan membantu proses desain yang berfokus pada keperluan user.

Merencanakan Suatu Proyek Aplikasi

Merencanakan suatu Proyek Aplikasi Bila berbicara tentang proyek pemrograman, orang sering membayangkan bahwa semua kerja harus dilakukan dibelakang keyboard, mengetik kode-kode. Bayangan itu memang benar untuk proyek yang berukuran kecil . Namun untuk proyek yang lebih besar, pemrograman tidak mungkin dapat melakukannya dengan langsung duduk mengetikkan kode. Diperlukan suatu perencanaan agar proyek itu dapat sukses. Apa jadinya jika suatu proyek tidak direncanakan terlebih dahulu? Maka kemungkinan yang terjadi antara lain : banyak kode sedikit fitur, banyak bug, banyak waktu yang akan dihabiskan atau kehilangan fitur.

Perencanaan Ada beberapa tipe ide guna memulai suatu proyek : Memperbaiki atau membuat sesuatu lebih baik, meniru atau memperbaiki sesuatu yang telah dibuat. Dengan berbekal ide ini maka pembuatan proyek akan memerlukan lebih sedikit langkah dan lebih sedikit waktu Ide baru dimana pemrograman akan membuat sesuatu yang benar-benar baru. Kebutuhan pasar yang bisa menjadi hasil dari kombinasi ke dua ide sebelumnya

Dasar Pemrograman Proyek pemrograman selalu dimulai dengan aplikasi dasar guna meletakkan struktur-struktur tambahan. Area dasar ini sangat menetukan bentuk interface yang akan dibuat sehingga perlu mendapat perhatian khusus. Alasannya : kode-kode program berasosiasi dengan kejadian ketika aplikasi digunakan. Beberapa informasi atau instruksi diberikan end user waktu memulai penggunaan aplikasi. Kode program yang baik harus bisa dikembangkan pada suatu saat.

Terima Kasih ….