Buku 2. Pendekatan Praktis - Edisi 1 IGNATUS JOKO DEWANTO. Program Studi Teknik Informatika Fakultas Ilmu Komputer Universitas Esa Unggul

156 Fasilkom – Universitas Esa Unggul

Pendekatan Praktis - Edisi 1

IGNATUS JOKO DEWANTO

Buku 2

Program Studi Teknik Informatika Fakultas Ilmu Komputer Universitas Esa Unggul


Pendekatan Praktis Untuk Mahasiswa

Penulis Perancang kulit

Joko

: I. Joko Dewanto : tim desain

Dewanto, Joko I Rekayasa Perangkat Lunak – Buku 2 Pendekatan Praktis (Edisi 1)/ I. Joko Dewanto Jakarta : Program Studi Teknik Informatika Fakultas Ilmu Komputer Universitas Esa Unggul, 2013.

I, 2013 Daftar Pustaka : Glosarium : ISBN :

Diterbitkan oleh : Universitas Esa Unggul Press Program Studi Teknik Informatika Fakultas Ilmu Komputer Universitas Esa Unggul Tahun – 2013


DAFTAR ISI Pengantar Petunjuk Penggunaan Buku A. Deskripsi Umum B. Peta Kompetensi C. Tujuan Instruksional Khusus Susunan Bab 1. Konsep dasar dan proses dari Rekayasa Perangkat Lunak ……........................ 2. Model Proses dan Proses Agile ……………………………………………….. 3. Perspektif Model Proses ………………………………………………………. 4. Pengembangan Agile …………………………………………………………... 5. Pandangan Umum Praktek ……………………………………………………. 6. Rekayasa Sistem ………………………………………………………………. 7. Rekayasa Kebutuhan …………………………………………………………… 8. Pemodelan Analisis …………………………………………………………….. 9. Rekayasa Desain ………………………………………………………………… 10. Desain Arsitektur ………………………………………………………………… 11. Desain Level Komponen………………………………………………………….. 12. Desain User Interface …………………………………………………………….. 13. Strategi Testing Perangkat Lunak dan Teknik-Teknik …………………………… 14. Strategi Testing Perangkat Lunak dan Teknik-Teknik……………………………. 15. Pengukuran Produk untuk Perangkat Lunak ……………………………………… 16. Rekayasa Web …………………………………………………………………….. 17. Formulasi dan Perencanaan Rekayasa Web ………………………………………. 18. Model Analisis Aplikasi Web …………………………………………………….. 19. Model Desain Aplikasi Web ……………………………………………………… 20. Testing Aplikasi Web …………………………………………………………….. 21. Konsep Manajemen Proyek ………………………………………………………. 22. Estimasi Proyek Perangkat Lunak ………………………………………………... 23. Penjadwalan Proyek dan Testing ………………………………………………… 24. Manajemen Proyek Resiko ………………………………………………………. 25. Manajemen Kualitas ……………………………………………………………... 26. Change Management ……………………………………………………………. 27. Perancangan Model User Interface ……………………………………………… 28. Pencangan Model Input ………………………………………………………….. 29. Perancangan Model Database ……………………………………………………. 30. Perancangan Model Output ………………………………………………………. 31. Mengaplikasikan Model Orientasi Objek, Agile dan n-Tier ………………………

10 25 32 48 57 61 70 78 101 112 127 139 143 147 151 166 171 176 183 194 202 217 226 233 239 246 257 265 273 285 292


Mengaplikasikan Kontruksi Perangkat Lunak Mengaplikasikan Implementasi Sistem Mengaplikasikan Proses Perangkat Lunak Mengaplikasikan Dukungan Sistem Mengevaluasi Perangkat Lunak Lampiran A. Daftar Pustaka Lampiran Glosarium, Daftar Website


PENGANTAR T REKAYASA PERANGKAT LUNAK Dalam buku ini dibicarakan penjelasan perangkat lunak, mendeskripsikan perangkat lunak praktis, mengidentifikasikan Aplikasi Rekayasa Web, Implementasi manajemen proyek perangkat lunak, Merancang Model yang terdiri atas (merancang antar muka pemakai, merancangan input, merancang output, merancang data base, mengaplikasikan pemodelan dan pengembangan system berbasis object, agile dan n-tier, mengaplikasikan fase konstruksi dan implementasi system, mengaplikasikan proses dan dukungan system. Setelah mempelajari modul mahasiswa akan mampu mengembangkan perangkat lunak dengan kemampuan menganalisis system dan menentukan kebutuhan system, merancang perangkat lunak dan mengimplementasikan rancangan tersebut dengan dukungan kemampuan manajemen proyek perangkat lunak sesuai dengan tuntutan pelanggan dan industry dengan hasil perangkat lunak yang berkualitas. MATERI PEMBELAJARAN 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

Rekayasa Web Formulasi dan Perencanaan Rekayasa Web Model Analisis Aplikasi Web Model Desain Aplikasi Web Testing Aplikasi Web Konsep Manajemen Proyek Estimasi Proyek Perangkat Lunak Penjadwalan Proyek dan Testing Manajemen Proyek Resiko Manajemen Kualitas Change Management Perancangan Model User Interface Pencangan Model Input Perancangan Model Database Perancangan Model Output Mengaplikasikan Model Orientasi Objek, Agile dan n-Tier Mengaplikasikan Kontruksi Perangkat Lunak Mengaplikasikan Implementasi Sistem Mengaplikasikan Proses Perangkat Lunak Mengaplikasikan Dukungan Sistem


36

Mengevaluasi Perangkat Lunak

Buku teks pelajaran ini telah melalui proses penilaian ahli materi, ahli desain pembelajaran, ahli media dan ahli teknologi informasi di dalam mencapai syarat kelayakan digunakan dalam proses pembelajaran standar perkuliahan di sebuah Unversitas dengan basis pembelajaran informatika. Kepada para mahasiswa kami ucapkan selamat belajar dan semoga dapat memanfaatkan buku ini sebaik-baiknya. Tidak ada gading yang tak retak, kami menyadari bahwa buku ini masih perlu ditingkatkan mutunya. Oleh karena itu, saran dan kritiksangat kami harapkan. Jakarta, 17 Agustus 2013

Penulis


PETUNJUK A. Deskripsi Umum Buku ini diberi judul ―Rekayasa Perangkat Lunak‖,merupakan salah satu program keahlian umum yang harus dimiliki Mahasiswa pada Fakultas Ilmu Komputer dan keahlian khusus pada program studi teknik informatika. Meskipun demikian, sebenarnya isi dari buku ini tidak secara khusus membahas tentang Rekayasa Perangkat Lunak. Dari sisi pandang Rekayasa Perangkat Lunak buku ini dibagi atas : proses perangkat lunak, memahami perangkat lunak praktis, memahami aplikasi web, memahami manajemen proyek perangkat lunak dan topik – topik terbaru

rekayasa perangkat lunak. Topik-topik ini

tentunya disesuaikan oleh iklim bisnis di Indonesia Pokok bahasan tentang Rekayasa Perangkat Lunak secara umum membahas : Perangkat Lunak dan Rekayasa Perangkat Lunak, Proses Perangkat Lunak, Model Proses, Proses Agile, Perangkat Lunak Praktis,Rekayasa Sistem, Desain, Arsitektur Desain,

Rekayasa Kebutuhan,

Model Analisis, Rekayasa

Model Komponen, User Interface Design, Rekayasa Web, Inisiasi

Aplikasi Web, Metrik Produk

& Rekayasa Perangkat Lunak, Perencanaan Formulasi untuk

Aplikasi Web Analisis Aplikasi Web, Desain Model Aplikasi Web, Testing Aplikasi Web, Pengaturan Proyek Perangkat Lunak, Penjadwalan Proyek dan Manajemen Resiko, Manajemen Kualitas dan Manajemen Perubahan,

Metode Formal dan Cleanroom SE, perancangan model

input, perancangan model database, perancangan model output, Mengembangkan aplikasi pemodelan

berorientasi objek,

komponen,

agile dan n-tier,

Mengaplikasikan konstruksi

perangkat lunak, Mengaplikasikan dan implementasi system, Mengaplikasikan proses perangkat lunak, Mengaplikasikan dukungan system, Mengevaluasi perangkat lunak

B. Peta Kompetensi

Secara umum, buku ini mengacu

pada Standar Kompetensi berdasarkan analisis

pembelajaran Rekayasa Perangkat Lunak bagi perguruan tinggi seperti berikut. 1. Menjelaskan perangkat lunak sebagai proses


2. Mendeskripsikan perangkat lunak praktis 3. Mengidentifikasikan Aplikasi Rekayasa Web 4. Mengimplementasikan manajemen proyek perangkat lunak 5. Merancang model 6. Merancang Antar Muka Pemakai 7. Merancang Input 8. Merancang Output 9. Merancang Data Base 10. Mengaplikasikan Pemodelan Pengembangan Sistem berbasis object, agile dan n-tier 11. Mengaplikasikan fase konstruksi dan implemensi sistem 12. Mengaplikasikan proses dan dukungan sistem Dalam penyajian buku disusun berdasarkan sub pokok bahasan. Sehingga mungkin saja ada bab yang berisikan gabungan dari beberapa standar kompetensi pada sub bab lainnya. Mi

Kompetensi Dasar/

Pokok Bahasan

ng gu

Tujuan Instruksional Khusus Menjelaskan perangkat lunak sebagai proses

1

Mampu Menjelaskan konsep dasar dan proses dari Rekay asa Perangkat Lunak

2

Mampu Menerangkan Model Proses dan Proses Agile

 Tinjauan PL  Proses PL  Model Proses  Agile sebuah proses Mendeskripsikan perangkat lunak praktis

3

Mampu Melakukan RPL Praktis dan Rekayasa Sistem

4

Mampu melakukan rekay asa kebutuhan dan membangun model analisis

5

Mampu melakukan rekay asa desain dan membuat desain arsitektur

6

Mampu melakukan Desain Model Komponen dan User Interface Desain

 RPL Praktis  Rekay asa Sistem  Rekay asa Kebutuhan  Membangun Model

 Rekay asa Desain  Membuat Arsitektur Desain  Komponen Model Desain  Menentukan User Interface Design Mengidentifikasi Aplikasi Rekay asa Web

7

Mampu membangun aplikasi Rekay asa Web

 Rekay asa Web Inisiasi Aplikasi Web

164 Fasilkom – Universitas Esa Unggul Mi

Kompetensi Dasar/

Pokok Bahasan

ng Tujuan Instruksional Khusus

gu

dan Menginisiasi Aplikasi Web 8

Mampu melakukan desain aplikasi w eb dan testing aplikasi w eb

 Desain Aplikasi Web  Testing Aplikasi Web

Mengimplementasikan Manajemen Proy ek Perangkat Lunak 9

Mampu melakukan Manajemen Proy ek Perangkat Lunak

10

Mampu melakukan manajemen proy ek

 Manajemen Proy ek  Metrik untuk Proses dan Proy ek Perangkat Lunak 

Estimasi

Estimasi 11

Mampu melakukan Manajemen Proy ek Penjadw alan, dan Resiko Perangkat Lunak

12

Mampu melakukan Manajemen Proy ek Kualitas dan Change Manajemen

 Manajemen Proy ek Penjadw alan  Manajemen Resiko  Manajemen Proy ek Kualitas  Change Management Merancang Model

13.

Mampu melakukan perancangan model user interface

 Perancangan UID  Perancangan Desain User Interface Merancang Model Input

14

Mampu melakukan perancangan model input

Perancangan Model Input (Desain Efektif Input) Merancang Model Database

15

Mampu melakukan perancangan model

Perancangan Model Database (Desain Database)

database Merancang Model Output 16

Mampu melakukan perancangan model output

Perancagan Model Output (Desain Efektif Output) Mengaplikasikan Model Orientasi Objek

17

Mampu melakukan pemodelan berorientasi

Mengaplikasikan Model Orientasi Objek, Agile dan n-Tier

objek Mengaplikasikan Konstruksi Perangkat Lunak dan Implementasi Sistem 18

Mampu mengaplikasikan konstruksi perangkat lunak

Aplikasi Konstruksi Perangkat Lunak

165 Fasilkom – Universitas Esa Unggul Mi

Kompetensi Dasar/

Pokok Bahasan

ng Tujuan Instruksional Khusus

gu 19

Mampu

mengaplikasikan

dan

mengimplementasikan sistem

 Implementasi Sistem Perangkat Lunak  Kesuksesan pada Implementasi Sistem Informasi Mengaplikasikan proses perangkat lunak

20

Mampu mengaplikasikan proses perangkat lunak

21

Mampu mengaplikasikan dukungan sy stem

22

Mampu mengev aluasi perangkat lunak

 Mengaplikasikan dan mempresentasikan proses PL  Menggambarkan Spesifikasi Proses  Menggunakan DFD  Mengaplikasi dan memptesentasikan dukungan sy stem  Rekay asa Desain  Membuat Arsitektur Desain Mengev aluasi perangkat lunak


Bab 16 Rekayasa Web

Tujuan Pembelajaran Umum Mengidentifikasikan Aplikasi Rekayasa Web Tujuan Pembelajaran Khusus/ Mampu menguraikan apa yang dimaksud dengan rekayasa web

Aplikasi Web meliputi :        

   

Kelengkapan situs web Simpel informasi situs web Kompleksitas. e-Commerce dengan situs lain melalui fungsi yang tertanam dan pengambilan data Kompleksitas. situs web yang dioperasikan dengan warisan perangkat lunak dan fungsi khusus Pengelolaan system dalam situs aplikasi Web yang berada di Internet atau intranet atau extranet. Intensitas jaringan. Aplikasi Web berada pada jaringan dan harus melayani kebutuhan masyarakat yang kliennya beragam Concurrency. Sejumlah pengguna besar dapat mengakses aplikasi web pada satu waktu, pola penggunaan di kalangan pengguna akhir akan sangat bervariasi. Beban tak terduga. Jumlah pengguna aplikasi web dapat bervariasi dan berlipat dari hari ke hari. Kinerja. Jika pengguna aplikasi web harus menunggu terlalu lama (untuk akses, untuk pemrosesan di sisi server, untuk format client-side dan tampilan), ia mungkin memutuskan untuk pergi ke tempat lain. Ketersediaan. Meskipun harapan ketersediaan 100 persen tidak masuk akal, pengguna aplikasi weba populer sering menuntut akses pada dasar "24/7/365". Data driven. Fungsi utama dari banyak aplikasi web adalah dengan menggunakan hypermedia untuk menyajikan teks, grafik, audio, dan konten video ke pengguna akhir. Konten sensitif. Kualitas dan sifat estetika konten tetap menjadi penentu penting dari kualitas sebuah aplikasi web. Evolusi yang berkelanjutan. Tidak seperti aplikasi perangkat lunak konvensional yang berkembang melalui serangkaian direncanakan, rilis kronologis spasi, aplikasi Web berevolusi terus menerus.


   

Kedekatan. Webapps sering menunjukkan waktu ke pasar yang dapat menjadi masalah beberapa hari atau minggu. Dengan alat-alat modern, halaman Web yang canggih dapat diproduksi hanya dalam beberapa jam. Keamanan. Untuk melindungi isi yang sensitif dan menyediakan mode aman transmisi data, langkah-langkah keamanan yang kuat harus dilaksanakan seluruh infrastruktur yang mendukung WebApp dan dalam aplikasi itu sendiri. Estetika. Bila aplikasi yang telah dirancang untuk memasarkan atau menjual produk atau ide, estetika mungkin memiliki banyak hubungannya dengan kesuksesan sebagai desain teknis

Kategori Aplikasi Web 

 

konten informasi-read-only disediakan dengan navigasi yang sederhana dan link mendownload informasi pengguna dari server yang tepat disesuaikan- kostumisasi konten pengguna untuk kebutuhan spesifik komunikasi interaksi antar komunitas pengguna terjadi melalui chatroom, papan buletin, atau instant messaging input pengguna inputbentuk berbasis mekanisme utama untuk mengkomunikasikan kebutuhan transaksi-berorientasi pengguna membuat permintaan (misalnya, tempat pesanan) yang dipenuhi oleh webapp yang berorientasi-layanan-aplikasi menyediakan layanan kepada pengguna, misalnya, membantu pengguna dalam menentukan pembayaran hipotek Portal-saluran aplikasi pengguna untuk konten atau layanan Web lain di luar domain dari aplikasi portal akses database pengguna query database yang besar dan ekstrak informasi pergudangan-data pengguna query kumpulan database besar dan informasi ekstrak

Pembangunan Web adalah seorang remaja ... Seperti kebanyakan remaja, ingin diterima sebagai orang dewasa seperti mencoba untuk menarik diri dari orang tuanya. Jika itu akan mencapai potensi penuh, ia harus mengambil beberapa pelajaran dari dunia lebih berpengalaman dari pengembangan perangkat lunak. " Doug Wallace et al Proses e-Web Harus   

mengakomodasi: pengiriman bertahap perubahan sering waktu pendek Oleh karena itu, o Sebuah model proses inkremental (Bab 3 dan 4) harus digunakan dalam hampir semua situasi o Sebuah model proses tangkas (Bab) yang tepat dalam banyak situasi

168 Fasilkom – Universitas Esa Unggul accept ance t est cust omer use cust omer evaluat ion

coding component t est

Release sof t war e incr ement

refact oring

design model analysis model business analysis formulat ion it erat ion plan

cont ent it erat ion f unct ion conf igurat ion

cont ent archit ect ure navigat ion int erf ace

Gambar 16.1. : Proses e-Web Kerangka kerja proses e-Web Komunikasi pelanggan Analisis Bisnis mendefinisikan konteks bisnis / organisasi untuk aplikasi web tersebut. Formulasi adalah pengumpulan persyaratan kegiatan melibatkan seluruh pemangku kepentingan. Tujuannya adalah untuk menjelaskan masalah aplikasi web adalah yang untuk memecahkan

Perencanaan "rencana" terdiri dari definisi tugas dan jadwal waktu untuk periode waktu (biasanya diukur dalam minggu) diproyeksikan untuk pengembangan kenaikan aplikasi web. Modeling 



Analisis menetapkan model dasar untuk desain o Analisis Isi. o Analisis interaksi. o Analisis fungsional. o Analisis konfigurasi. Desain model merupakan elemen kunci WebApp o desain konten o desain estetika o desain arsitektur o desain antarmuka o desain navigasi o desain komponen


Konstruksi o Alat WebE dan teknologi yang diterapkan untuk membangun webapp yang telah dimodelkan o Pengujian semua elemen desain Pengiriman dan Evaluasi (Deployment) o o o o

Mengkonfigurasi untuk lingkungan operasional Memberikan kepada pengguna akhir, dan Umpan balik evaluasi disajikan kepada tim WebE Kenaikan tersebut dimodifikasi sesuai kebutuhan (awal siklus berikutnya tambahan)

Pertanyaan-pertanyaan dasar eWeb o Seberapa penting adalah halaman muka situs web ? o Apa tata letak halaman yang paling efektif (misalnya, menu di atas, di sebelah kanan atau kiri?) o Dan apakah hal itu bervariasi tergantung pada jenis webapp sedang dikembangkan? Pilihian media yang memiliki yang paling berdampak? o Berapa banyak pekerjaan yang kita bisa mengharapkan pengguna harus dilakukan ketika ia sedang mencari informasi ? o Seberapa penting navigasi alat bantu ketika aplikasi web yang kompleks? o Bagaimana kompleks dapat menjadi bentuk masukan sebelum menjadi menjengkelkan bagi pengguna? Bagaimana bisa bentuk masukan dipercepat? o Seberapa penting adalah kemampuan pencarian? o Aplikasi web tersebut harus dirancang dengan cara yang membuatnya dapat diakses oleh mereka yang memiliki cacat fisik atau lainnya?


Tugas Anda pada saat ini dianggap sebagai Manajer Manajemen Proyek pada perusahaan Software House untuk proyek Pengembangan Web ERP pada PT. ABC. Kiat sebelum melaksanakan pengembangan web ERP adalah : 1. Baca konsep ERP untuk kebutuhan pengembangan perangkat lunak 2. Baca konsep Pengembangan Web untuk kebutuhan pengembangan web bab. 16,17,18,19,20,21 3. Studi banding melalui internet studi kasus implemenasi ERP pada perusahaan. Studi Kasus – Pengembangan Web ERP pada PT. ABC PT ABC adalah perusahaan dibidang produk dan operasi. Pada saat ini PT tersebut ingin mengembangkan perangkat lunak enterprise resources planning disingkat ERP berbasis Web. ERP sering disebut sebagai Back Office System yang mengindikasikan bahwa pelanggan dan publik secara umum tidak dilibatkan dalam sistem ini. Berbeda dengan Front Office System yang langsung berurusan dengan pelanggan seperti sistem untuk e-Commerce, Customer Relationship Management (CRM), e-Government dan lain-lain. Perusahaan berkeinginan mengembangkan model ERP tersebut dengan modul operasi sebagai berikut General Logistics, Sales and Distribution, Materials Management, Logistics Execution, Quality Management, Plant Maintenance, Customer Service, Production Planning and Control, Project System, Environment Management. Dalam sebuah perusahaan ERP untuk kebutuhan proses produsi PT. ABC mengalami kesulitan di dalam beberapa hal antara lain : 1. Buatlah formulasi perencanaan aplikasi ERP berbasis web inhouse atau outsorcing ? 2. Susunlah model analisis aplikasi web ERP ? 3. Bagaimana anda mengembangkan analisis aplikasi web ERP ? (analisis content, analisis interaksi, analisis fungsional dan analisis configurasi ?) 4. Bagaimana cara membuat model desain aplikasi web ERP ? 5. Apakah anda sudah menentukan dimensi aplikasi web ERP untuk kebutuhan end user? Bagaimana cara anda mengimplementasikannya ? 6. Jelaskan pandangan Desain Piramind WebE untuk kebutuhan apliaksi web ERP ? 7. Bagaimana cara anda melakukan test sebelum aplikasi web ERP di delivery ke pelanggan?


Bab 17 Formulasi dan Perencanaan Rekayasa Web

Tujuan Pembelajaran Umum Mengidentifikasikan Aplikasi Rekayasa Web Tujuan Pembelajaran Khusus Mampu membangun rekayasa web berdasarkan formulasi dan perencanaan rekayasa web Formulasi o o o o

dimulai perlu dengan identifikasi bisnis bergerak ke deskripsi tujuan Aplikasi Web mendefinisikan fitur dan fungsi utama menetapkan kegiatan persyaratan pengumpulan yang akan mengarah pada pengembangan dari model analisis o memungkinkan stakeholder dan tim rekayasa web untuk membangun seperangkat tujuan dan sasaran untuk pembangunan aplikasi web tersebut. o mengidentifikasi ruang lingkup dari upaya pembangunan o menyediakan sarana untuk menentukan kesuksesan hasilnya .. Pernyataan Formulasi o Apa motivasi utama (kebutuhan bisnis) untuk aplikasi web tersebut? o Apa tujuan yang harus memenuhi aplikasi web ? o Siapa yang akan menggunakan aplikasi web tersebut ? Jawaban menyediakan ... o Tujuan informational mengindikasikan niat untuk menyediakan konten yang spesifik dan / atau informasi bagi pengguna akhir o Tujuan aplikatif menunjukkan kemampuan untuk melakukan beberapa tugas dalam aplikasi web Persyaratan pengumpulan aplikasi web o Mintalah para pemangku kepentingan untuk menentukan kategori pengguna dan mengembangkan deskripsi untuk setiap kategori o Berkomunikasi dengan para pemangku kepentingan untuk menetapkan persyaratan dasar aplikasi web o Menganalisis informasi yang dikumpulkan dan menggunakan informasi untuk menindaklanjuti dengan stakeholder o Tentukan gunakan-kasus (Bab 8) yang menggambarkan skenario interaksi untuk masingmasing kelas pengguna


Kategori-kategori mendefinisikan user o Apa tujuan keseluruhan pengguna saat menggunakan aplikasi web tersebut? o Apa latar belakang pengguna dan kecanggihan relatif terhadap konten dan fungsionalitas dari aplikasi web tersebut? o Bagaimana penggunaan akan tiba di aplikasi web itu? o Apa karakteristik aplikasi web generik apakah pengguna suka / tidak suka? Komunikasi untuk stakeholder o Kelompok fokus moderator tradisional terlatih bertemu dengan sekelompok perwakilan kecil pengguna akhir (atau stakeholder internal memainkan peran end-user). o Kelompok fokus Elektronik diskusi moderator elektronik dilakukan dengan sekelompok perwakilan pengguna akhir dan stakeholder. o Iteratif survei-serangkaian survei singkat, ditujukan kepada pengguna perwakilan dan meminta jawaban atas pertanyaan spesifik tentang aplikasi web tersebut o Survei-survei yang eksploratif berbasis web yang terkait dengan satu atau lebih webapps yang memiliki pengguna yang sama dengan orang-orang yang akan menggunakan webapp yang akan dikembangkan. o Pengguna bangunan Skenario dipilih diminta untuk membuat informal, penggunaankasus yang menggambarkan interaksi spesifik dengan webapp yang

Analisis pendahuluan o Mengkategorikan informasi yang dikumpulkan oleh pengguna kelas dan jenis transaksi Mengembangkan daftar ... o konten objek o operasi yang diterapkan ke konten objek dalam transaksi pengguna tertentu o fungsi (misalnya, informasi, komputasi, logis, dan berorientasi bantuan) yang webapp menyediakan untuk end-user o kebutuhan non-fungsional lain yang dicatat selama kegiatan komunikasi. Use Case o Memberikan detail yang diperlukan untuk membuat model analisis yang efektif o Bantuan pengembang untuk memahami bagaimana pengguna memandang interaksi dengan aplikasi mereka o Gunakan-kasus membantu untuk kotakkan pekerjaan rekayasa Web o Gunakan-kasus memberikan panduan penting bagi mereka yang harus menguji aplikasi web Tim e-Web o peran tim WebE o Pengembang Konten / Penyedia o web Publisher o Insinyur web.


o Ahli domain bisnis o Dukungan Spesialis o Administrator (a.k.a. "Web Master") Outsourcing Vs In-House support specialist s

Web engineers

support specialist s

v endor liaison

Cont ent dev elopers administ rat or

Web engineers

Cont ent dev elopers

administ rat or out sourcing v endor Web publisher

business managers

Web publisher business managers

st akeholders

end-users

st akeholders

market ing & sales

(a) in-house development

end-users

market ing & sales

(a) out sourced development

Gambar 17.1. : Outsourcing vs In-House Perencanaan aplikasi web Outsourcing o Memulai proyek dengan melakukan tugas-tugas berikut secara internal o mengumpulkan persyaratan o Mengembangkan "desain kasar" o Mengembangkan jadwal kasar dengan tanggal pengiriman o pertimbangkan bertahap o Buatlah daftar tanggung jawab o Untuk di-rumah staf o Untuk vendor outsourcing o Tentukan mekanisme penghubung o Pilih Calon outsourcing Vendor o Menilai Validitas Quotes Harga dan Keandalan Estimasi o Apakah biaya dikutip dari aplikasi web memberikan pengembalian atas investasi langsung atau tidak langsung yang membenarkan proyek? o Apakah vendor yang telah memberikan kutipan menunjukkan profesionalisme dan pengalaman yang kita butuhkan? o Memahami Tingkat Manajemen Proyek Dapat Anda Harapkan / Lakukan o Menilai Jadwal Pembangunan o Lingkup Kelola Perencanaan Aplikasi Web – InHouse o Memahami ruang lingkup, dimensi perubahan, dan kendala proyek o Mendefinisikan strategi proyek tambahan o Lakukan analisis risiko o Mengembangkan perkiraan cepat


o o o o

Pilih satu set tugas (proses deskripsi) Menetapkan jadwal Menentukan mekanisme proyek pelacakan Menetapkan pendekatan manajemen perubahan

Praktek terburuk WebE o Kami punya ide bagus, jadi mari kita mulai membangun aplikasi web sekarang. o Kejadian akan berubah terus-menerus, sehingga tidak ada gunanya mencoba untuk memahami kebutuhan Aplikasi web. o Pengembang dominan pengalaman yang telah dalam pengembangan perangkat lunak tradisional dapat mengembangkan webapps segera. Tidak ada pelatihan baru yang diperlukan. o Jadilah birokrasi. o Pengujian? Mengapa repot-repot?


Tugas : Meneruskan tugas 16 Tugas Anda pada saat ini dianggap sebagai Manajer Manajemen Proyek pada perusahaan Software House untuk proyek Pengembangan Web ERP pada PT. ABC. Kiat sebelum melaksanakan pengembangan web ERP adalah : 1. Baca konsep ERP untuk kebutuhan pengembangan perangkat lunak 2. Baca konsep Pengembangan Web untuk kebutuhan pengembangan web bab. 16,17,18,19,20,21 3. Studi banding melalui internet studi kasus implemenasi ERP pada perusahaan.

Studi Kasus – Pengembangan Web ERP pada PT. ABC PT ABC adalah perusahaan dibidang produk dan operasi. Pada saat ini PT tersebut ingin mengembangkan perangkat lunak enterprise resources planning disingkat ERP berbasis Web. ERP sering disebut sebagai Back Office System yang mengindikasikan bahwa pelanggan dan publik secara umum tidak dilibatkan dalam sistem ini. Berbeda dengan Front Office System yang langsung berurusan dengan pelanggan seperti sistem untuk e-Commerce, Customer Relationship Management (CRM), e-Government dan lain-lain. Perusahaan berkeinginan mengembangkan model ERP tersebut dengan modul operasi sebagai berikut General Logistics, Sales and Distribution, Materials Management, Logistics Execution, Quality Management, Plant Maintenance, Customer Service, Production Planning and Control, Project System, Environment Management. Dalam sebuah perusahaan ERP untuk kebutuhan proses produsi PT. ABC mengalami kesulitan di dalam beberapa hal antara lain : 1. Buatlah formulasi perencanaan aplikasi ERP berbasis web inhouse atau outsorcing ? 2. Susunlah model analisis aplikasi web ERP ? 3. Bagaimana anda mengembangkan analisis aplikasi web ERP ? (analisis content, analisis interaksi, analisis fungsional dan analisis configurasi ?) 4. Bagaimana cara membuat model desain aplikasi web ERP ? 5. Apakah anda sudah menentukan dimensi aplikasi web ERP untuk kebutuhan end user? Bagaimana cara anda mengimplementasikannya ? 6. Jelaskan pandangan Desain Piramind WebE untuk kebutuhan apliaksi web ERP ? 7. Bagaimana cara anda melakukan test sebelum aplikasi web ERP di delivery ke pelanggan?


Bab 18 Model Analisis Aplikasi Web

Tujuan Pembelajaran Umum Mengidentifikasikan Aplikasi Rekayasa Web Tujuan Pembelajaran Khusus Mampu membangun rekayasa web berdasarkan model analisis aplikasi web Analisis Analisis Isi (content analysis) Spektrum konten penuh yang akan diberikan oleh aplikasi web ini diidentifikasi, termasuk teks, grafik dan gambar, video, dan data audio. Pemodelan data dapat digunakan untuk mengidentifikasi dan menggambarkan setiap objek data.

Analisis interaksi (interaction analysis) . Cara di mana pengguna berinteraksi dengan apliasi web yang dijelaskan secara rinci. Gunakankasus dapat dikembangkan untuk menyediakan deskripsi rinci dari interaksi ini. Analisis fungsional (functional analysis) . Skenario penggunaan (use-kasus) dibuat sebagai bagian dari analisis interaksi menentukan operasi yang akan diterapkan untuk konten WebApp dan menyiratkan fungsi pengolahan lainnya. Semua operasi dan fungsi dijelaskan secara rinci.

Analisis konfigurasi (configuration analysis) . Lingkungan dan infrastruktur dimana Aplikasi web yang berada dijelaskan secara rinci. Kapan kita melakukan analisis Dalam beberapa situasi WebE, analisis dan desain gabungan. Namun, kegiatan analisis eksplisit terjadi ketika ...yang aplikasi web yang akan dibangun besar dan / atau kompleks jumlah stakeholder besar jumlah insinyur Web dan kontributor lainnya tujuan dan sasaran besar


(ditentukan selama formulasi) untuk aplikasi web akan mempengaruhi bisnis 'bottom line keberhasilan webapp akan memiliki bantalan yang kuat terhadap keberhasilan bisnis The User Hierarkhi

SafeHomeAssured.com user

guest

regist ered user

new cust omer

cust omer serv ice st aff

exist ing cust omer

Figure 18.1 User hierarchy f or Saf eHomeAssured.com

Gambar 18.1. User Hierarchy for SafeHome.com Use Case Diagram


des cribe home lay out <>

peruse des cript iv e cont ent

cus t omize Saf eHome

select Saf eHome component s

<>

<>

s ave conf igurat ion cus t omizat ion f unct ionalit y

log-in t o Saf eHomeA s sured.com

view s hopping c art <>

purc has e conf igurat ion

new cus t omer

<>

provide purchase dat a recall saved conf igurat ion

<>

complet e Saf eHome order e-c ommerce f unct ionalit y

Figure 18.2 Use-case diagram f or new-cust omer

Gambar 18.2. : Use Case Diagram for New-Customer Menyempurnakan Model Use Case      

Use Case tersebut akan disusun dalam paket fungsional Masing-masing paket dinilai [CON00] untuk memastikan bahwa itu adalah: Dipahami-semua pemangku kepentingan memahami tujuan dari paket Kohesif-paket alamat fungsi yang terkait erat satu sama lain Longgar ditambah-fungsi atau kelas dalam paket berkolaborasi dengan satu sama lain, tetapi kolaborasi luar paket disimpan ke minimum. Hirarki hirarki fungsional dangkal sedalam sulit untuk menavigasi dan sulit bagi pengguna akhir untuk memahami, sehingga jumlah tingkat dalam hirarki use case harus diminimalkan bila memungkinkan.

Model Content  



Objek Content Yang diambil dari bahasa use case o Memeriksa gambaran skenario Referensi Langsung Dan tidak Langsung Ke isi Atribut dari bahasa setiap OBJEK konten diidentifikasi o Hubungan ANTARA OBJEK-OBJEK konten sampai / atau hirarki konten dikelola Oleh webapp sebuah o Diagram hubungan-entitas- hubungan atau UML Hirarki Pohon-Data atau UML


Data Tree Market ingDescript ion

Phot ograph part Number TechDescript ion

part Name

component

Schemat ic

part Type

Video

descript ion

price WholesalePrice

Ret ailPrice

Figure 1 8 .3 Dat a t ree for aSafeHom e c om ponent

Gambar 18.3. : Data Tree untuk aSafeHome Component Analisis Class Analisis class diturunkan dengan memeriksa setiap use-case Sebuah gramatikal pengurai digunakan untuk mengidentifikasi kelas calon Sebuah diagram kelas UML dikembangkan untuk setiap kelas analisis Contoh : Analisis Class BillOfMat erials Product Component

1

ident ifier priceTot al

part Number part Name part Ty pe descript ion price

addEnt ry( ) delet eEnt ry( ) edit Ent ry( ) name( ) sav e( ) comput ePrice( )

creat eNewIt em( ) get Descript ion( ) get TechSpec

1

* * Sensor

Camera

Cont rolPanel

Soft Feat ure

BoMIt em quant it y price addt oList( ) delet efromList( )

Figure 18.4 Analysis classes f or use-case: select Saf eHome component s

Gambar 18.4. Analysis Classes untuk Use Case SafeHome Component


Model Interaction 



Composed of four elements:  use-cases  sequence diagrams  state diagrams  a user interface prototype Each of these is an important UML notation

Sequence Diagram Validat ing user select “log-in”

Select ing user act ion userid v alidat ed

syst em st at us=“input ready ” display msg = “ent eruserid” display msg =“ent er pswd”

password validat ed n e w cu st o m e r

ent ry/ log-in request ed do: run user validat ion exit / set user access swit ch

select ot her f unct ions sy st em st at us=“link ready” display : navigat ion choices” ent ry/ validat ed user do: link as required exit / user act ion select ed

c ust omiz at ion complet e select e-c ommerc e (purc hase) f unct ionalit y

selec t cust omizat ion f unc t ionalit y next select ion Cust omizing

select descript ive cont ent

syst em st at us=“input ready” display: basic inst ruct ions

Def ining room room being def ined

ent ry / validat ed user do: process user select ion exit / cust omiz at ion t erminat ed

select descript iv e cont ent

Sav ing f loor plan syst em st at us=“input ready” display: st orage indicat or ent ry / f loor plan sav e select ed do: st ore f loor plan exit / save complet ed

syst em st at us=“input ready” display: roomdef . window

ent ry / roomdef . select ed all rooms do: run room queries def ined do: st ore room v ariables exit / room complet ed

select sav e f loor plan select ent er room in f loor plan

Building f loor plan

select descript iv e cont ent

sy st em st at us=“input ready” display : f loor plan window ent ry/ f loor plan select ed do: insert room in place do: st ore f loor plan variables exit / room insert ion complet ed

room insert ion complet ed

Figure 1 8 .6 Part ial st at e diagram f or n e w c u s t o m eint r eract ion

Gambar 18.5. Partial State Diagram untuk new costumer action Functional Model Model fungsional membahas dua elemen pengolahan aplikasi web yang fungsionalitas diamati pengguna yang disampaikan oleh aplikasi web untuk pengguna operasi akhir yang terkandung dalam kelas analisis yang menerapkan perilaku yang terkait dengan kelas. Sebuah diagram aktivitas dapat digunakan untuk mewakili aliran pengolahan


Activity Diagram

init ialize t ot alCost

no component s remain onBoMList

c omponent s remain on BoMList

invoke calcShipping Cost ret urns: shipping Cost

invoke det ermineDiscount ret urns: discount

disc ount >0

discount

g et price and quant it y

lineCost = price x quant it y

add lineCost t o t ot alCost

t ot alCost= t ot alCost - discount

<= 0

t axTot al= t ot alCost x t axrat e

priceTot al = t ot alCost + t axTot al + shipping Cost

Figure 1 8 .7 Act ivit y diagram f or c o m p u t e Pr i (c)e o p e r a t i o n

Gambar 18.6. : Diagram Aktifitas Configuration Model 

Server-side



o Server hardware and operating system environment must be specified o Interoperability considerations on the server-side must be considered o Appropriate interfaces, communication protocols and related collaborative information must be specified Client-side o Browser configuration issues must be identified o Testing requirements should be defined

Hubungan Analisis Navigasi Relationship Navigation Analysis (RNA) mengidentifikasi hubungan antara unsur-unsur ditemukan sebagai bagian dari penciptaan model analisis langkah-langkah:  Analisis Stakeholder - mengidentifikasi berbagai kategori pengguna dan menetapkan hirarki pemangku kepentingan yang sesuai


   

Analisis elemen-mengidentifikasi benda konten dan elemen fungsional yang menarik bagi pengguna akhir Analisis hubungan - hubungan analisis menggambarkan hubungan yang ada di antara elemen WebApp Analisis Navigasi - analisis meneliti bagaimana pengguna dapat mengakses elemen individu atau kelompok elemen Analisis Evaluasi - mempertimbangkan isu-isu pragmatis (misalnya, biaya / manfaat) berkaitan dengan penerapan hubungan ditetapkan sebelumnya Google Terjemahan untuk Bisnis:Perangkat PenerjemahPenerj

Analisis Navigasi 1          

Haruskah unsur-unsur tertentu lebih mudah untuk mencapai (memerlukan lebih sedikit langkah navigasi) dari yang lain? Apa prioritas untuk presentasi? Haruskah unsur-unsur tertentu ditekankan untuk memaksa pengguna untuk menavigasi arah mereka? Bagaimana seharusnya kesalahan navigasi ditangani? Haruskah navigasi untuk grup terkait elemen diberikan prioritas di atas navigasi untuk elemen tertentu. Haruskah navigasi dicapai melalui link, melalui akses berbasis pencarian, atau dengan cara lain? Haruskah peta navigasi lengkap atau menu (sebagai lawan dari "belakang" link tunggal atau pointer diarahkan) akan tersedia di setiap titik dalam interaksi pengguna? Haruskah desain navigasi didorong oleh perilaku pengguna yang paling sering diharapkan atau oleh pentingnya dirasakan elemen aplikasi web yang didefinisikan? Dapatkah pengguna "toko" navigasi sebelumnya lewat aplikasi web untuk mempercepat penggunaan masa depan? Untuk kategori mana pengguna harus navigasi optimal dirancang? Bagaimana seharusnya link eksternal untuk webapp yang ditangani? overlay jendela browser yang ada? sebagai jendela browser baru? sebagai frame yang terpusat.

Tugas : Teruskan tugas pertemuan 16,17


Bab 19 Model Desain Aplikasi Web

Tujuan Pembelajaran Umum Mengidentifikasikan Aplikasi Rekayasa Web Tujuan Pembelajaran Khusus Mampu membangun rekayasa web berdasarkan model desain aplikasi web Desain dan Aplikasi Web    

Ketika kita harus menetapkan desain aplikasi web ? bila konten dan fungsi yang kompleks ketika ukuran aplikasi web yang mencakup ratusan benda konten, fungsi, dan analisis class ketika keberhasilan aplikasi web akan memiliki dampak langsung terhadap keberhasilan bisnis

Desain dan Kualitas Aplikasi Web o Keamanan (Security) o Serangan eksternal penolakan o Pengecualian hak akses yang tidak sah o Pastikan privasi pengguna / pelanggan o Ketersediaan (Availabity) o Ukuran dari persentase waktu yang webapp yang tersedia untuk digunakan o Skalabilitas (scalability) o Dapatkah Aplikasi web dan sistem dengan yang variasi yang signifikan dalam menangani dihubungkan pengguna atau volume transaksi o Waktu ke Pasar Dimensi Kualitas untuk End User o Waktu o Berapa banyak memiliki situs web berubah sejak upgrade terakhir? o Bagaimana Anda menyorot bagian-bagian yang telah berubah? o Struktural o Seberapa baik semua bagian dari situs web terus bersama-sama. o Apakah semua link dalam dan di luar situs Web bekerja?


o Apakah semua gambar kerja? o Apakah ada bagian dari situs web yang tidak terhubung? o Konten o Apakah isi dari halaman penting sesuai dengan apa yang seharusnya ada? o Apakah frase kunci eksis terus di halaman yang sangat berubah? o Jangan halaman penting menjaga kualitas konten dari versi ke versi? o Bagaimana dihasilkan secara dinamis halaman HTML o Akurasi dan Konsistensi o Apakah salinan hari ini dari halaman download yang sama seperti kemarin? Cukup dekat? o Apakah data yang disajikan cukup akurat? Bagaimana Anda tahu? o Respon Waktu dan Latency o Apakah server situs web menanggapi permintaan peramban dalam batasan tertentu? o Dalam konteks e-commerce, bagaimana akhir untuk mengakhiri waktu respon setelah SUBMIT? o Apakah ada bagian dari situs yang sangat lambat pengguna menolak untuk terus bekerja di atasnya? o Prestasi o Apakah Browser Web-web-koneksi-situs Web-Browser cukup cepat? o Bagaimana kinerja bervariasi menurut waktu, oleh beban dan penggunaan? Apakah kinerja yang memadai untuk aplikasi e-commerce Tujuan Desain Aplikasi Web Consistency o Konten harus dibangun secara konsisten o Desain grafis (estetika) harus menyajikan tampilan yang konsisten di seluruh bagian aplikasi web o Desain arsitektur harus menetapkan template yang mengarah ke struktur hypermedia konsisten o Interface desain harus mendefinisikan mode konsisten interaksi, navigasi dan konten layar o Mekanisme navigasi harus digunakan secara konsisten di semua elemen Aplikasi web Identitas (Identity) o Membentuk "identitas" yang sesuai untuk tujuan bisnis Kesegaran (Robustness) o Pengguna mengharapkan konten kuat dan fungsi yang relevan dengan kebutuhan pengguna Navigation o dirancang dengan cara yang intuitif dan predictable


daya tarik visual (Visual appeal) o tampilan dan nuansa dari konten, tata letak antarmuka, koordinasi warna, keseimbangan teks, grafik dan media lainnya, mekanisme navigasi harus menarik bagi pengguna-akhir Kecocokan (compatibility) o Dengan semua lingkungan dan konfigurasi yang sesuai Desain Piramid Webe user

Interface design Aesthetic design Content design Navigation design Architecture design Component design technology

Gambar 19.1. : Desain Piramid Web-e

Desain interface web  Dimana aku? Antarmuka harus memberikan mengindikasikan dari aplikasi web yang telah diakses menginformasikan pengguna lokasi dalam hirarki konten.  Apa yang bisa saya lakukan sekarang? Antarmuka harus selalu membantu pengguna memahami pilihan saat ini o fungsi apa yang tersedia? o apa link yang hidup? o apa konten yang relevan?  Aku telah dimana, di mana aku akan pergi? Antarmuka harus memudahkan navigasi. Menyediakan "peta" (diimplementasikan dengan cara yang mudah dimengerti) di mana pengguna telah dan apa jalan dapat diambil untuk pindah ke tempat lain di dalam aplikasi web tersebut. Efektifitas Aplikasi Web Bruce Tognozzi [TOG01] menunjukkan ... Interface yang efektif secara visual jelas dan pemaaf, menamkan dalam kontrol pengguna mereka. Pengguna dengan cepat melihat luasnya pilihan mereka, memahami bagaimana untuk mencapai tujuan mereka, dan melakukan pekerjaan mereka.


Interface yang efektif tidak memperhatikan pengguna dengan inner dari sistem. Kerja secara hati-hati dan terus disimpan, dengan opsi penuh bagi pengguna untuk dapat membatalkan aktivitas setiap saat. Aplikasi dan layanan yang efektif melakukan kerja maksimum, sementara yang membutuhkan minimal informasi dari pengguna. Prinsip-prinsip desain interface  Antisipasi (anticipation) – Sebuah aplikasi Web harus dirancang sehingga dapat mengantisipasi langkah penggunaan selanjutnya penggunaan.  Komunikasi (communication) - Antarmuka harus mengkomunikasikan status setiap kegiatan yang diprakarsai oleh pengguna  Konsistensi (consistent) -Penggunaan kontrol navigasi, menu, ikon, dan estetika (misalnya, warna, bentuk, tata letak)  Otonomi (autonomy) –Kontrol-kontrol antarmuka harus memfasilitasi pergerakan pengguna di seluruh aplikasi web, tetapi harus melakukannya dengan cara yang memberlakukan konvensi navigasi yang telah ditetapkan untuk aplikasi.  Efisiensi (efficiency)-Desain dari WebApp dan antarmuka harus mengoptimalkan efisiensi kerja pengguna, bukan efisiensi insinyur Web yang merancang dan membangun atau lingkungan client-server yang mengeksekusinya.  Fokus (focus) - Antarmuka aplikasi web (dan konten yang disajikan) harus tetap fokus pada tugas ditangan pengguna-pengguna.  Hukum-Fitt (Fits Law‖ "Waktu untuk memperoleh target adalah fungsi dari jarak dan ukuran target)."  Human Interface Object - perpustakaan besar objek antarmuka manusia dapat digunakan kembali telah dikembangkan untuk aplikasi web.  Pengurangan kemampuan aplikasi web harus menggunakan kemampuan multi-tasking dengan cara yang memungkinkan pengguna melakukan pekerjaan sebagai jika pengoperasian telah selesai.  Kemudahan dipelajari (Learnability)- Sebuah antarmuka aplikasi web harus dirancang untuk meminimalkan waktu belajar, dan setelah dipelajari, untuk meminimalkan belajar diperlukan bila aplikasi web tersebut ditinjau kembali.  Memelihara integritas produk kerja (maintain work product integrity) -Sebuah produk kerja (misalnya, formulir yang sudah diisi oleh user, daftar user tertentu) harus disimpan secara otomatis sehingga tidak akan hilang jika terjadi kesalahan.  Keterbacaan (Readibility) -Semua informasi disajikan melalui antarmuka harus dibaca oleh muda dan tua.  Melacak negara (track state) -Bila diperlukan, keadaan interaksi pengguna harus dilacak dan disimpan sehingga pengguna dapat logoff dan kembali lagi nanti untuk mengambil mana ia tinggalkan.  Terlihat navigasi (Visible navigation) Sebuah antarmuka aplikasi web yang dirancang memberikan "ilusi bahwa pengguna berada di tempat yang sama, dengan pekerjaan yang dibawa kepada mereka." Kerangka kerja desain interface  Ulasan informasi terkandung dalam model analisis dan diperbaiki sesuai kebutuhan.


         

Mengembangkan sketsa kasar dari tata letak antarmuka aplikasi web . Peta tujuan pengguna ke tindakan interface tertentu. Tentukan satu set tugas pengguna yang terkait dengan setiap tindakan. Layar gambar storyboard untuk setiap tindakan antarmuka. Persempit tata letak antarmuka dan storyboard menggunakan input dari desain estetika. Mengidentifikasi objek user interface yang diperlukan untuk mengimplementasikan antarmuka. Mengembangkan representasi prosedural interaksi pengguna dengan antarmuka. Mengembangkan representasi perilaku antarmuka. Jelaskan tata letak antarmuka untuk setiap negara. Memperbaiki dan meninjau model desain antarmuka.

Mapping User Objectives Memetakan objek pengguna untuk kebutuha aplikasi web yang kita kembangkan, selanjutnya digamarkan model Mapping User Objective Menu bar major functions

List of user object ives

graphic, logo, and company name object ive #1 object ive #2 object ive #3 object ive #4 object ive #5

graphic object ive #n

Home page text copy Navigation menu

Gambar 19.2. : Mapping User Objective Sumber : Software Enggineering – Pressman Desain estetika  Jangan takut ruang putih.  Tekankan konten.  Mengatur elemen tata letak dari atas-kiri ke kanan bawah.  Grup Navigasi, konten, dan fungsi geografis dalam halaman.  Jangan memperpanjang ruang areal layar monitor anda dengan menggunakan scroll bar  Pertimbangkan resolusi dan ukuran jendela browser ketika merancang tata letak.

Desain Content




 

Mengembangkan representasi desain untuk objek konten Untuk Aplikasi web , objek konten lebih erat selaras dengan objek data untuk perangkat lunak konvensional Merupakan mekanisme yang diperlukan untuk hubungan instan mereka satu sama lain. Analog dengan hubungan antara kelas analisis dan desain komponen yang dijelaskan dalam Bab 11 Sebuah objek memiliki atribut konten yang mencakup informasi konten-spesifik dan implementasi atribut khusus yang ditentukan sebagai bagian dari desain

Contoh : Desain pada konten objek ProductComponent partNumber partName partType description price

is part of

1

1

createNewItem ( ) displayDescription ( ) display TechSpec

Sensor

Camera

ControlPanel

CompDescript ion

SoftFeature

1

1

1..*

Market ingDescript ion t ext color f ont st yle f ont size line spacing t ext image size background color

0..1

0..1

Phot ograph

Schemat ic

Video

horizont al dimension vert ical dimension border st yle

horizont al dimension vert ical dimension border st yle

horizont al dimension vert ical dimension border st yle audio volume

1 TechDescript ion t ext color f ont st yle f ont size line spacing t ext image size background color

Ganbar 19.3. : Desian Objek Content Arsitektur Desain 

 

Arsitektur Konten (Content Architecture) berfokus pada cara di mana objek konten (atau objek komposit seperti halaman Web) dirancang untuk presentasi dan navigasi. o Arsitektur Informasi Istilah ini juga digunakan untuk struktur berkonotasi yang mengarah pada organisasi yang lebih baik, label, navigasi, dan pencarian obyek konten. Arsitektur Aplikasi Web (WebApp Architecture) membahas cara di mana aplikasi disusun untuk mengelola interaksi pengguna, menangani tugas-tugas pemrosesan internal, efek navigasi, dan konten-konten baru yang hadir. Asitektur Desain (Desain Architecture) dilakukan secara paralel dengan desain antarmuka, desain estetika dan desain konten.

Contoh : Arsitektur Konten


Gambar 19.4. : Arsitektur Konten Arsitektur MVC (Model View Controller) Model (model) ini berisi semua aplikasi konten yang spesifik dan logika pengolahan, termasuk semua benda konten akses ke data eksternal / sumber informasi,semua fungsi pengolahan yang spesifik aplikasi. Tampilan (view) berisi semua fungsi spesifik antarmuka dan memungkinkan penyajian konten dan logika pengolahan akses ke data eksternal / sumber informasi, semua fungsi pemrosesan yang diperlukan oleh pengguna akhir. Kontroler (controller) mengatur akses ke model dan pandangan dan mengkoordinasi aliran data antara mereka Contoh : Arsitektur MVC co n t ro ller manages user request s select s model behav ior select s v iew response

behav ior request ( st at e change)

user request or dat a browser

v iew select ion

m o d el encapsulat es funct ionalit y encapsulat es cont ent object s incorporat es all webApp st at es client dat a from model

HTML dat a

view

updat e request

prepares dat a from model request updat es from model present s v iew select ed by cont roller

serv er

Gambar 19.5. Arsitektur MVC

ext ernal dat a


Desain Navigasi    

Dimulai dengan pertimbangan hirarki pengguna dan menggunakan kasus terkait Setiap aktor dapat menggunakan aplikasi web yang agak berbeda dan karenanya memiliki kebutuhan navigasi yang berbeda Karena setiap pengguna berinteraksi dengan aplikasi web, sehingga akan bertemu dengan serangkaian unit navigasi semantik (Navigation Semantic Unit’s - NSUs) NSU-"satu set informasi dan struktur navigasi terkait yang berkolaborasi dalam pemenuhan subset dari kebutuhan pengguna yang terkait

Navigation Semantic Unit Unit Navigasi semantik, cara navigasi yang baik -merupakan cara navigasi terbaik atau jalan untuk pengguna dengan profil tertentu untuk mencapai tujuan yang diinginkan atau sub-tujuan. Terdiri dari ..., Node Navigasi (NN) dihubungkan dengan Navigasi Link link12

NN2

link24

NN1

NN4

link13

NN3

NSU

link34

Gambar : 19.6. Navigasi Semantik Unit Membuat sebuah NSU <> request alt ernat ive

<> recommend component ( s) <> select Room

Product Component <> show Product Component

Room

<> ret urn t o Room <> view BillOf Mat erials

<> show descript ion <> purchase Product Component

BillOf Mat erials CompDescript ion <> purchase Product Component

Market ingDescript ion phot ograph t echDescript ion video schemat ic

Gambar 19.7. : Membuat NSU Syntax Navigasi  Navigasi individu (individual navigation) berbasis link-link teks, ikon, tombol dan switch, dan metafora grafis ..


   

Navigasi horisontal (horizontal navigation) daftar bar konten utama atau kategori fungsional di sebuah bar yang mengandung link yang sesuai. Secara umum, antara 4 dan7 kategori terdaftar. Navigasi kolom vertikal (vertical column navigation) o Daftar-daftar konten utama atau kategori-kategori fungsional o Semua daftar virtual objek konten utama dalam aplikasi web tersebut. Tabs - sebuah metafora yang tidak lebih dari sebuah variasi dari bar navigasi atau kolom, yang mewakili isi atau kategori fungsional sebagai lembar tab yang dipilih bila link diperlukan. Peta situs (Site Maps) -menyediakan tab inklusif isi keseluruhannya untuk navigasi, untuk semua obyek isi dan fungsi yang terkandung dalam aplikasi web

Desain Level Komponen (component level design) Komponen Aplikasi web melaksanakan fungsi sebagai berikut : o melakukan pengolahan lokal untuk menghasilkan konten dan navigasi kemampuan secara dinamis o menyediakan perhitungan atau kemampuan pemrosesan data yang tepat untuk domain web aplikasi bisnis ini o menyediakan query database yang canggih dan akses o membangun antarmuka data dengan sistem eksternal perusahaan. Desain Pola Hypermedia o Pola arsitektur. Membantu dalam desain konten dan arsitektur aplikasi web, saat ini banyak pola arsitektur yang tersedia (misalnya, Java Blueprints di java.sun.com / cetak biru /) o Pola konstruksi komponen. Merekomendasikan metode untuk menggabungkan komponen aplikasi web (misalnya, objek konten, fungsi) ke dalam komponen komposit. o Pola navigasi. Membantu dalam desain NSUs, navigasi link dan aliran navigasi keseluruhan webapp tersebut. _ o Pola presentasi o bagaimana mengatur fungsi kontrol antarmuka pengguna untuk kegunaan yang lebih baik o bagaimana untuk menunjukkan hubungan antara tindakan antarmuka dan objek konten itu mempengaruhi o bagaimana membangun hirarki konten yang efektif, dan banyak lagi yang lainnya. o Perilaku / pola interaksi pengguna o bagaimana antarmuka menginformasikan pengguna tentang konsekuensi dari tindakan tertentu o bagaimana pengguna memperluas konten berdasarkan konteks penggunaan dan keinginan pengguna o bagaimana cara terbaik untuk menggambarkan tujuan yang tersirat oleh link


o bagaimana untuk menginformasikan kepada user tentang status interaksi sedang dijalankan (on-going), dan lain-lain. Pola repository 1. Hypermedia Design Patterns Repository http://www.designpattern.lu.unisi.ch/ 2. InteractionPatterns oleh TomErickson http://www.pliant.org/personal/Tom_Erickson/InteractionPatterns.html 3. Web Design Patterns oleh Martijn vanWelie http://www.welie.com/patterns/ 4. Meningkatkan Sistem Informasi Web dengan Pola Navigational http://www8.org/w8-papers/5b-hypertext-media/improving/improving.html 5. HTML 2.0 Pola Bahasa http://www.anamorph.com/docs/patterns/default.html 6. Common Ground - Sebuah Pola Bahasa untuk HCI Desain http://www.mit.edu/ ~ jtidwell / interaction_patterns.html 7. Pola untuk Situs Web Pribadi http://www.rdrop.com/~setengah /Creations/Tulisan/Web.patterns/index.htm 8. Pengindeksan Pola Bahasa http://www.cs.brown.edu/~ rms/InformationStructures / Indexing / overview.htm Object Oriented Hypermedia Design Method

wo r k p r o d u ct s

concept ual design

nav igat ional design

abst ract int erface design

implement at ion

Classes, sub-systems, relationships, attributes

Nodes, links, access structures, navigational contexts, navigational transformations

Abstract interface objects, responses to external events, transformations

executable WebApp

Mapping between conceptual and navigation objects

Mapping between navigation and perceptible objects

Resource provided by target environment

Takes into account user profile and task. Emphasis on cognitive aspects.

Modeling perceptible objects, implementing chosen metaphors. Describe interface for navigational objects

Correctness; Application performance; completeness

Classification, composition, d e sig n m e ch an ism s aggregation, generalization specialization

d e sig n co n ce r n s

Modeling semantics of the application domain

Gambar 19.8. : Object Oriented Hypermedia Design Methods (OOHDM) Skema Konsepsual

193 Fasilkom – Universitas Esa Unggul cust omer select s component ProductComponent

component recommendat ion request ed

partNumber partName partType description price

BillOfMaterials identifier BoMList numberItems priceTotal

createNewItem ( ) getDescription ( ) getTechSpec

Room roomName dimensions exteriorWindows exteriorDoors

Sensor

Camera

ControlPanel

addEntry ( ) deleteEntry ( ) editEntry ( ) name( ) computePrice ( )

SoftFeature

BoMItem

cust omercont inues component select ion Order

cust omer request s purchase

orderNumber customerInfo billOfMaterials shippingInfo billingInfo

quantity partNumber partName partType price addtoList ( ) deletefromList ( ) getNextListEntry ( )

Gambar 19.9 : Skema Konsepsual

Design Metrics o Apakah user interface mempromosikan kemampuan usability ? o Apakah estetika aplikasi web yang sesuai untuk aplikasi domain dan menyenangkan bagi pengguna ? o Apakah konten yang dirancang dengan cara yang paling menanamkan informasi dengan usaha yang sedikit ? o Apakah navigasi yang efisien dan mudah ? o Apakah arsitektur aplikasi web telah dirancang untuk mengakomodasi tujuan khusus dan tujuan pengguna aplikasi web, struktur isi dan fungsi, dan aliran navigasi diperlukan untuk menggunakan sistem secara efektif ? o Apakah komponen dirancang dengan cara yang mengurangi kompleksitas prosedural dan meningkatkan ketepatan, keandalan dan kinerja ?

Tugas : Teruskan tugas pertemuan 16,17,18


Bab 20 Testing Aplikasi Web

Tujuan Pembelajaran Umum Mengidentifikasikan Aplikasi Rekayasa Web Tujuan Pembelajaran Khusus Mampu membangun rekayasa web berdasarkan testing aplikasi web

Dimensi Kualitas testing 

 



 





Konten dievaluasi baik di tingkat sintaksis dan semantik. o Tingkat sintaksis -ejaan, tanda baca dan tata bahasa yang dinilai untuk dokumen berbasis teks. o Tingkat semantik -kebenaran (informasi yang disajikan), dan (konsistensi seluruh isi objek-obyek terkait dan kurangnya ambiguitas semua dinilai. Fungsi diuji untuk kebenaran, ketidakstabilan, dan kesesuaian dengan standar pelaksanaan umum yang tepat (misalnya, Java atau standar bahasa XML). Struktur ini dinilai untuk memastikan bahwa itu benar o memberikan konten Aplikasi Web o fungsi extensible o dapat didukung sebagai konten baru atau fungsi ditambahkan. Usability diuji untuk memastikan bahwa setiap kategori pengguna : o Didukung dengan interface o Dapat belajar dan menerapkan semua sintaks navigasi dan semantik yang diperlukan Navigasi diuji untuk memastikan bahwa o semua sintaks dan semantik navigasi itu dilakukan untuk mengungkap kesalahan navigasi (misalnya, link mati, link yang tidak benar, link salah). Kinerja diuji di bawah berbagai kondisi operasi, konfigurasi, dan loading untuk memastikan bahwa o sistem ini responsif terhadap interaksi pengguna o sistem menangani beban ekstrim tanpa degradasi operasional dapat diterima Kompatibilitas diuji dengan mengeksekusi aplikasi web dalam berbagai konfigurasi host yang berbeda pada kedua klien dan sisi server. o Tujuannya adalah untuk menemukan kesalahan yang spesifik untuk konfigurasi host yang unik. Interoperabilitas diuji untuk memastikan bahwa aplikasi web dengan aplikasi interface lain yang benar dan / atau database.




Keamanan diuji dengan menilai potensi kerentanan dan mencoba untuk mengeksploitasi setiap-setiap usaha penetrasi yang sukses didalam menerapkan keamanan.

Strategi testing aplikasi web o Model konten untuk aplikasi web yang terakhir untuk mengungkap kesalahan. o Model interface terakhir untuk memastikan bahwa semua penggunaan-kasus dapat ditampung. o Desain model untuk aplikasi web yang terakhir untuk mengungkap kesalahan navigasi. o User interface yang diuji untuk mengungkap kesalahan dalam presentasi dan / atau mekanik navigasi. o Komponen fungsional yang dipilih adalah unit yang diuji. o Navigasi seluruh arsitektur diuji. o Aplikasi web diimplementasikan dalam berbagai konfigurasi lingkungan yang berbeda dan diuji untuk kompatibilitas dengan konfigurasi masing- masing. o Tes keamanan yang dilakukan dalam upaya untuk mengeksploitasi kerentanan dalam aplikasi web atau dalam lingkungannya. o Tes kinerja yang dilakukan. o Webapp ini diuji oleh populasi dikendalikan dan dipantau dari pengguna akhir o hasil interaksi mereka dengan sistem dievaluasi untuk kesalahan isi dan navigasi, kekhawatiran kegunaan, masalah kompatibilitas, dan kehandalan aplikasi web dan kinerja. Proses Testing Co nt ent T est ing Int er f ace T est ing

user Navig at io n T est ing Interface design Aesthetic design Content design

Co m p o nent T est ing

Navigation design Architecture design

Co nf ig ur at io n T est ing

Component design technology

Per f o r m ance T est ing

.Gambar 20.1. Proses Testing

Secur it y T est ing


Testing Konten o Konten pengujian memiliki tiga tujuan penting: o untuk mengungkap kesalahan sintaksis (misalnya, kesalahan ketik, kesalahan tata bahasa) dalam dokumen berbasis teks, representasi grafis, dan media lainnya o untuk mengungkap kesalahan semantik (yaitu, kesalahan dalam keakuratan atau kelengkapan informasi) di setiap objek konten disajikan sebagai terjadi navigasi, dan o untuk menemukan kesalahan dalam organisasi atau struktur konten yang disajikan kepada pengguna akhir Evaluasi Content Semantik o o o o o o o o o o

Apakah informasi faktual akurat? Apakah informasi singkat dan to the point? Apakah tata letak objek konten mudah bagi pengguna untuk mengerti? Dapatkah informasi tertanam dalam objek konten ditemukan dengan mudah? Apakah referensi yang tepat telah disediakan untuk semua informasi yang diperoleh dari sumber lain? Apakah informasi yang disajikan konsisten internal dan konsisten dengan informasi yang disajikan dalam objek konten lainnya? Apakah serangan konten, menyesatkan, atau tidak membuka pintu untuk litigasi ? Apakah konten yang melanggar hak cipta atau merek yang ada ? Apakah konten berisi link internal yang melengkapi konten yang ada ? Adalah link yang benar ? Apakah gaya estetika konflik konten dengan gaya estetika antarmuka ?

Testing Database c lient lay er - user int erfac e

HTML script s

serv er lay er - WebApp

Tests are defined for each layer

user dat a

serv er lay er - dat a t ransform at ion

user dat a

serv er lay er - dat a m anagem ent

raw dat a

SQL

dat abase lay er - dat a ac c ess

dat abase

Gambar 20.2. : testing database

SQL


Testing User Interface o Fitur antarmuka (interface feature) diuji untuk memastikan bahwa aturan desain, estetika, dan konten visual yang terkait tersedia bagi pengguna tanpa kesalahan. o Mekanisme individu antarmuka (individual interface mechanism) diuji dengan cara yang analog dengan unit testing. o Setiap mekanisme antarmuka (each interface mechanism) diuji dalam konteks use case atau NSU (Bab 19) untuk kategori pengguna tertentu. o Antarmuka lengkap (complete interface) diuji terhadap dipilih penggunaan-kasus dan NSUs untuk mengungkap kesalahan dalam semantik antarmuka. o Antarmuka (interface) diuji dalam berbagai lingkungan (misalnya, browser) untuk memastikan bahwa hal itu akan kompatibel.

Mekanisme testing interface o Hubungan-hubungan (links) - mekanisme navigasi yang menghubungkan pengguna ke beberapa objek konten lainnya atau fungsi. o Bentuk (objek) - dokumen terstruktur yang berisi bidang kosong yang diisi oleh pengguna. Data yang terkandung dalam bidang yang digunakan sebagai masukan untuk satu atau lebih fungsi Aplikasi Web. o Scripting client-side (client-side script) daftar perintah diprogram dalam bahasa scripting (misalnya, Javascript) yang menangani input informasi melalui bentuk atau interaksi pengguna lainnya o Dynamic HTML-mengarah ke konten objek yang dimanipulasi di sisi klien menggunakan script atau cascading style sheets (CSS).Jendela sisi klien jendela pop-up-kecil yang popup tanpa interaksi pengguna. Jendela ini dapat berorientasi konten dan mungkin memerlukan beberapa bentuk interaksi pengguna. o Script-CGI common gateway interface(CGI) skrip umum menerapkan metode standar yang memungkinkan server Web untuk berinteraksi secara dinamis dengan pengguna (misalnya, aplikasi web yang berisi bentuk dapat menggunakan script CGI untuk memproses data yang terdapat dalam formulir setelah itu disampaikan oleh pengguna). o Streaming konten (content streaming) - daripada menunggu permintaan dari sisi klien, objek konten-download secara otomatis dari sisi server. Pendekatan ini kadang-kadang disebut "push" teknologi karena server mendorong data ke klien. o Cookie-blok data yang dikirim oleh server dan disimpan oleh browser sebagai konsekuensi dari interaksi pengguna tertentu. Isi data aplikasi web tertentu (misalnya, data identifikasi pengguna atau daftar item yang telah dipilih untuk pembelian oleh pengguna). o Aplikasi spesifik mekanisme antarmuka mencakup satu atau lebih "makro" mekanisme antarmuka seperti keranjang belanja (shopping online) , pemrosesan kartu kredit (credit card processing), atau kalkulator biaya pengiriman (shipping cost calculator).


Testing Usability o Desain oleh tim WebE ... dieksekusi oleh pengguna akhir\ o Urutan Pengujian... o Mendefinisikan seperangkat kategori pengujian kegunaan dan mengidentifikasi untuk masing-masing tujuan. o Desain tes yang akan memungkinkan setiap tujuan untuk dievaluasi. o Pilih peserta yang akan melakukan tes. o Instrument Interaksi peserta dengan saat pengujian aplikasi web dilakukan. o Mengembangkan mekanisme untuk menilai kegunaan dari aplikasi web o Berbagai tingkat abstraksi: o Kegunaan dari mekanisme interface tertentu (misalnya, bentuk) dapat dinilai o Kegunaan dari suatu halaman web yang lengkap (mekanisme antarmuka meliputi, obyek data dan fungsi- fungsi terkait) dapat dievaluasi o kegunaan dari aplikasi web dapat dianggap lengkap

Testing Kompabilitas (Comp ability test) o Pengujian kompatibilitas adalah untuk mendefinisikan satu set "biasa ditemui" komputasi konfigurasi client side dan varian mereka o Buat struktur pohon mengidentifikasi  setiap platform komputasi  perangkat layar khas  sistem operasi yang didukung pada platform  browser yang tersedia  kemungkinan kecepatan koneksi internet  informasi serupa. o Turunkan serangkaian tes validasi kompatibilitas  berasal yang ada dari tes antarmuka, tes navigasi, tes kinerja, dan tes keamanan.  maksud dari tes ini adalah untuk mengungkap kesalahan atau masalah eksekusi yang dapat ditelusuri perbedaan konfigurasi.

Testing tingkat komponen o Fokus pada serangkaian tes yang mencoba untuk mengungkap kesalahan dalam fungsi aplikasi web o Uji Metode desain kasus konvensional baik black box dan white box dapat digunakan o Pengujian database sering merupakan bagian integral dari komponen-pengujian

Testing Navigasi Mekanisme navigasi berikut harus diuji:


o Navigasi (Navigation) - mekanisme link-link ini meliputi internal dalam webapp, link eksternal untuk webapps lainnya, dan jangkar dalam halaman Web tertentu. o Pengalihan (Redirect) -link ini ikut bermain ketika pengguna meminta non-ada URL atau memilih link yang tujuan telah dihapus atau yang namanya telah berubah. o Penanda-penanda (Bookmarks) meskipun adalah fungsi browser, webapp harus diuji untuk memastikan bahwa judul halaman yang berarti dapat diekstraksi sebagai penunjuk dibuat. o Bingkai (Frameset) – frame-frame diuji untuk konten yang benar, tata letak yang tepat dan ukuran, kinerja download, dan kompatibilitas browser o Peta-peta situs (SiteMap) - Setiap situs entri harus diuji untuk memastikan bahwa link tersebut akan membawa pengguna ke konten yang tepat atau fungsi. o Mesin Pencari Internal (Internal Search Engines) - Mesin pencari internal memvalidasi keakuratan dan kelengkapan dari pencarian, sifat-penanganan kesalahan dari mesin pencari, dan fitur pencarian lanjutan

Testing Navigation Semantic o Apakah NSU yang dicapai secara keseluruhan tanpa kesalahan? o Apakah setiap simpul navigasi (didefinisikan untuk NSU) dicapai dalam konteks jalur navigasi yang ditetapkan untuk NSU? o Jika NSU dapat dicapai dengan menggunakan lebih dari satu jalur navigasi, telah setiap jalan yang relevan telah diuji? o Jika petunjuk yang diberikan oleh antarmuka pengguna untuk membantu dalam navigasi, adalah arah yang benar dan dapat dipahami sebagai hasil navigasi? o Apakah ada mekanisme (selain panah browser 'back') untuk kembali ke node navigasi sebelumnya dan awal jalur navigasi. o Apakah mekanisme untuk navigasi dalam simpul navigasi besar (yaitu, halaman web yang panjang) bekerja dengan baik? o Jika fungsi yang akan dijalankan pada satu simpul dan pengguna memilih untuk tidak memberikan masukan, dapat sisa NSU akan selesai? o Jika fungsi dijalankan pada node dan kesalahan dalam fungsi pengolahan terjadi, dapat NSU diselesaikan? o Apakah ada cara untuk menghentikan navigasi sebelum semua node telah tercapai, tapi kemudian kembali ke tempat navigasi dihentikan dan lanjutkan dari sana? o Apakah setiap simpul dicapai dari peta situs? Apakah nama simpul berarti bagi pengguna akhir? o Jika node dalam sebuah NSU tercapai dari beberapa sumber eksternal, apakah mungkin untuk memproses ke node berikutnya pada jalur navigasi. Apakah mungkin untuk kembali ke node sebelumnya pada jalur navigasi? o Apakah pengguna mengerti lokasinya dalam arsitektur konten sebagai NSU dijalankan?

Testing Configuration o Server-side


o Apakah aplikasi web sepenuhnya kompatibel dengan server OS? o Apakah sistem file, direktori, dan data terkait sistem dibuat dengan benar ketika operasional aplikasi web ? o Apakah langkah-langkah keamanan sistem (misalnya, firewall atau enkripsi) memungkinkan aplikasi web untuk mengeksekusi dan tanpa gangguan layanan pengguna atau penurunan kinerja? o Apakah aplikasi web yang telah diuji dengan konfigurasi server terdistribusi (jika ada) yang telah dipilih? o Apakah aplikasi web dengan benar terintegrasi dengan perangkat lunak database? o Apakah aplikasi web yang sensitif terhadap versi yang berbeda dari perangkat lunak database? o Apakah server-side script aplikasi web mengeksekusi dengan baik? o Apakah kesalahan sistem administrator telah diperiksa untuk mempengaruhi mereka pada operasi aplikasi web ? o Jika server proxy yang digunakan, memiliki perbedaan dalam konfigurasi mereka telah ditangani dengan pengujian di tempat? o Client-side o Perangkat keras-CPU, memori, penyimpanan dan pencetakan o Sistem operasi Linux-, Macintosh OS, Microsoft Windows, OS mobile berbasis o Browser perangkat lunak Internet Explorer, Mozilla / Netscape, Opera, Safari, dan lainlain o User interface-komponen Active X, Java applet dan lain-lain o Plug-in-QuickTime, RealPlayer, dan banyak lainnya o Konektivitas-kabel, DSL, modem biasa, T1 o Jumlah variabel konfigurasi harus dikurangi ke nomor dikelola

Testing Security o Dirancang untuk menyelidiki kerentanan (vulnerabilities) lingkungan client-side, jaringan komunikasi yang terjadi sebagai data yang lulus dari klien ke server dan kembali lagi, dan lingkungan server-side o Di sisi klien, kerentanan sering dapat ditelusuri ke bug yang sudah ada di browser, program e-mail, atau perangkat lunak komunikasi. o Di sisi server, kerentanan termasuk serangan denial-of-service dan skrip berbahaya yang dapat diteruskan ke sisi klien atau digunakan untuk menonaktifkan operasi server yang

Testing Performa o Apakah waktu respon server menurunkan ke titik di mana ia terlihat dan tidak dapat diterima? o Pada titik (dalam hal pengguna, transaksi atau loading data) tidak kinerja menjadi tidak dapat diterima? o Apa komponen sistem bertanggung jawab untuk penurunan kinerja? o Apa waktu respon rata-rata bagi pengguna di bawah berbagai kondisi pembebanan? o Apakah penurunan kinerja berdampak pada sistem keamanan?


o Apakah keandalah Aplikasi web atau ketepatan terpengaruh beban pada sistem tumbuh? o Apa yang terjadi ketika beban yang lebih besar dari kapasitas server secara maksimum diterapkan?

Testing Load (load TESTING) o Tujuannya adalah untuk menentukan bagaimana webapp dan lingkungan sisi server akan merespon berbagai kondisi pembebanan N, jumlah pengguna secara bersamaan T, jumlah transaksi on-line per unit waktu D, beban data yang diproses oleh server per transaksi o Throughput keseluruhan, P, dihitung dengan cara sebagai berikut: P=N xTxD

Testing Stress        

Apakah sistem menurunkan 'lembut' atau apakah server menutup akibat kapasitas terlampaui? Apakah perangkat lunak server menghasilkan pesan "Server tidak tersedia"? Lebih umum, adalah pengguna menyadari bahwa mereka tidak dapat mencapai server? Apakah permintaan antrian server untuk sumber daya dan mengosongkan sekali antrian tuntutan kapasitas berkurang? Apakah transaksi hilang karena kapasitas terlampaui? Apakah integritas data terpengaruh kapasitas terlampaui? Apa nilai dari N, T, dan D memaksa lingkungan server gagal? Bagaimana kegagalan memanifestasikan dirinya? Adalah pemberitahuan otomatis dikirim ke staf dukungan teknis di server situs? Jika sistem gagal, berapa lama waktu yang dibutuhkan untuk kembali on-line? Apakah fungsi Aplikasi web tertentu (misalnya, menghitung fungsi intensif, streaming data kemampuan) dihentikan kapasitas mencapai level 80 atau 90 persen?

Tugas : Teruskan tugas pertemuan 16,17,18,19, 20


Bab 21 Konsep Manajemen Proyek

Tujuan Pembelajaran Umum Mengimplementasikan Manajemen Proyek Perangkat Lunak Tujuan Pembelajaran Khusus Mampu menjalankan Konsep Manajemen Proyek Perangkat Lunak

Komponen Manajemen Proyek 4 P People - Komponen yang paling penting dalam mengembangkan kesuksesan proyek Product - Perangkat Lunak yang akan dikembangkan Proses - Adalah serangkaian kerja aktifitas dan tugas-tugas rekayasa perangkat lunak untuk mendapatkan pekerjaan yang akan dilakukan Project -> Semua pekerjaan yang diperlukan untuk membuat produk menjadi kenyataan

Sumber daya Manajemen Proyek Perangkat Lunak     

Manajer senior yang menentukan isu-isu bisnis yang sering memiliki pengaruh yang signifikan pada proyek. Manajer teknis proyek yang harus merencanakan, memotivasi, mengatur, dan mengendalikan praktisi yang melakukan kerja perangkat lunak. Praktisi yang memberikan keterampilan teknis yang diperlukan untuk merancang sebuah produk atau aplikasi. Pelanggan yang menentukan persyaratan untuk perangkat lunak yang akan direkayasa dan pemangku kepentingan lainnya yang memiliki dukungan minat dalam hasilnya. Pengguna akhir -yang berinteraksi dengan perangkat lunak setelah dilepaskan untuk penggunaan produksi.


Tim Perangkat Lunak

How to lead?

How to organize?

How to collaborate?

How to motivate?

How to create good ideas?

Gambar 21.1. Tim Perangkat Lunak Ada beberapa pertanyaan dalam mengelola tim proyek : 1. 2. 3. 4. 5.

Bagaimana Bagaimana Bagaimana Bagaimana Bagaimana

memimpin ? / How to lead ?. mengorganisasi ? / How to organize ? bagaimana membuat ide-ide yang baik ? / How to create good ideas ? memotivasi ? / How to motivate ? untuk mengkolaborasikan ? / How to collaborate ?

Pemimpin Tim dalam proyek mengikuti standar MOI Model MOI MOI Model:  



Motivasi – (Motivate) Kemampuan untuk mendorong (dengan "mendorong atau menarik") orang-orang teknis untuk menghasilkan kemampuan terbaik mereka. Organisasi – (Organization) Kemampuan untuk membentuk proses yang ada (atau menciptakan yang baru) yang akan memungkinkan konsep awal yang akan diterjemahkan menjadi produk akhir. Ide-ide atau inovasi – (Ideas or Inovation) . Kemampuan untuk mendorong orang untuk membuat dan merasa kreatif bahkan ketika mereka harus bekerja dalam batas-batas yang ditetapkan untuk produk perangkat lunak tertentu atau aplikasi.

Tim Perangkat Lunak  

Sulitnya masalah yang harus dipecahkan Ukuran program yang dihasilkan (s) di baris kode (line of code) atau fungsi poin (function point).


    

Waktu bahwa tim akan tetap bersama (seumur hidup tim) Tingkat dimana masalah dapat termodulasi Yang diperlukan kualitas dan keandalan sistem yang akan dibangun Ketepatan dari tanggal pengiriman Tingkat sosialisasi (komunikasi) yang dibutuhkan untuk proyek

Faktor-faktor diatas harus dipertimbangkan ketika memilih? Struktur tim proyek perangkat lunak Paradigma Organisasi 

Closed paradigm— struktur sebuah tim di sepanjang hirarki otoritas tradisional



Random paradigm— struktur tim longgar dan tergantung pada inisiatif individual anggota tim



Open paradigm— upaya untuk menyusun tim dengan cara yang mencapai beberapa kontrol yang berhubungan dengan paradigma tertutup, tetapi juga banyak inovasi yang terjadi ketika menggunakan paradigma random



Synchronous paradigm— bergantung pada kompartementalisasi alami masalah dan mengatur anggota tim untuk bekerja pada bagian dari masalah dengan komunikasi aktif sedikit di antara mereka sendiri-sendiri.

Hindari Tim "Keracunan"     

Sebuah suasana kerja yang hiruk pikuk di mana anggota tim membuang energi dan kehilangan fokus pada tujuan dari pekerjaan yang harus dilakukan. Frustrasi yang tinggi disebabkan oleh pribadi, bisnis, atau faktor teknologi yang menyebabkan gesekan antara anggota tim. "Terfragmentasi atau kurang prosedur koordinasi " atau model proses buruk didefinisikan atau dipilih benar yang menjadi penghambat bagi prestasi. Ketidakjelasan definisi peran mengakibatkan kurangnya akuntabilitas dan menghasilkan jari-menunjuk. "Terus menerus dan paparan berulang terhadap kegagalan" yang mengarah ke hilangnya kepercayaan dan menurunkan moral.

Tim Agile  

Anggota tim harus memiliki kepercayaan satu sama lain. Distribusi keterampilan harus sesuai dengan masalah.




Tidak terencana (maverick) mungkin harus dikeluarkan dari tim, jika kekompakan tim harus dipertahankan. o Tim adalah "mengorganisir diri" o Sebuah struktur tim adaptif o Menggunakan unsur-unsur paradigm acak, terbuka, dan sinkron, disesuaikan signifikan otonomi

Kordinasi tim dan komunikasi 



  

Formal, pendekatan impersonal mencakup dokumen rekayasa perangkat lunak dan produk kerja (termasuk kode sumber), memo teknis, tonggak proyek, jadwal, dan alat pengendalian proyek (Bab 23), permintaan perubahan dan dokumentasi terkait, laporan pelacakan kesalahan, dan data repositori (lihat Bab 26). Formal, interpersonal prosedur fokus pada kegiatan jaminan kualitas (Bab 25) diterapkan untuk perangkat lunak produk kerja rekayasa. Ini termasuk pertemuan peninjauan status dan desain dan inspeksi kode. Informal, prosedur antarpribadi termasuk pertemuan kelompok untuk penyebaran informasi dan pemecahan masalah dan "kolokasi persyaratan dan pengembangan staf." Komunikasi elektronik meliputi surat elektronik, papan buletin elektronik, dan dengan perpanjangan, sistem konferensi berbasis video. Interpersonal jaringan termasuk diskusi informal dengan anggota tim dan orang-orang di luar proyek yang mungkin memiliki pengalaman atau wawasan yang dapat membantu anggota tim

Lingkup Produk Cakupan : 

 

Konteks. Bagaimana perangkat lunak yang akan dibangun sesuai dengan sistem yang lebih besar, produk, atau konteks bisnis dan apa kendala yang dikenakan sebagai akibat dari konteks? Tujuan informasi. Apa obyek data pelanggan terlihat (Bab 8) yang dihasilkan sebagai output dari perangkat lunak? Apa objek data yang dibutuhkan untuk input? Fungsi dan kinerja. Apa fungsi apakah perangkat lunak melakukan untuk mengubah data input menjadi output? Apakah ada karakteristik kinerja khusus yang akan ditangani?

Lingkup proyek perangkat lunak harus jelas dan dimengerti pada tingkat manajemen dan teknis


Dekomposisi Permasalahan  



Kadang-kadang disebut partisi atau masalah elaborasi Setelah lingkup didefinisikan ... o Hal ini diuraikan menjadi fungsi konstituen o Hal ini didekomposisi menjadi objek data dapat dilihat oleh pengguna o atau o Hal ini didekomposisi menjadi satu set kelas masalah Proses dekomposisi berlanjut sampai semua fungsi atau kelas masalah telah didefinisikan

Proses 



Setelah kerangka proses telah dibentuk o Pertimbangkan karakteristik proyek o Menentukan tingkat ketelitian yang diperlukan o Tentukan satu set tugas untuk setiap kegiatan rekayasa perangkat lunak Tugas set = o Tugas-tugas rekayasa perangkat lunak o produk kerja o Poin jaminan kualitas o Milestones

Penyatuan masalah dan Proses


Proyek Proyek mendapat kesulitan ketika ...          

Software orang tidak memahami kebutuhan pelanggan mereka. Ruang lingkup produk buruk didefinisikan. Perubahan dikelola buruk. Perubahan teknologi yang dipilih. Kebutuhan bisnis berubah [atau tidak jelas]. Tenggat waktu yang realistis. Pengguna tahan. Sponsorship hilang [atau tidak pernah diperoleh benar]. Tim proyek tidak memiliki orang-orang dengan keterampilan yang sesuai. Manajer [dan praktisi] menghindari praktek-praktek terbaik dan pelajaran.

Pendekatan Akal Sehat Proyek 





 

Mulai pada kaki kanan. Hal ini dicapai dengan bekerja keras (sangat sulit) untuk memahami masalah yang akan dipecahkan dan kemudian menetapkan tujuan realistis dan harapan. Mempertahankan momentum. Manajer proyek harus menyediakan insentif untuk menjaga pergantian personil ke absolut minimum, tim harus menekankan kualitas dalam melakukan setiap tugas itu, dan manajemen senior harus melakukan segala kemungkinan untuk tetap keluar dari jalan tim. Melacak kemajuan. Untuk proyek software, kemajuan dilacak sebagai produk kerja (misalnya, model, kode sumber, set kasus uji) diproduksi dan disetujui (menggunakan tinjauan teknis formal) sebagai bagian dari kegiatan jaminan kualitas. Membuat keputusan cerdas. Pada intinya, keputusan dari manajer proyek dan tim perangkat lunak harus untuk "tetap sederhana." Melakukan analisis postmortem. Membentuk mekanisme yang konsisten untuk mengekstraksi pelajaran untuk setiap proyek.

Menuju zat yang proyek ?      

Mengapa sistem yang dikembangkan? Apa yang akan dilakukan? Kapan akan dilakukan? Siapa yang bertanggung jawab? Di mana mereka organisatoris berada? Bagaimana tugas diselesaikan secara teknis maupun manajerial?




Berapa banyak dari setiap sumber daya (misalnya, orang-orang, perangkat lunak, peralatan, basis data) akan dibutuhkan?

Kritikal praktis      

Manajemen risiko formal ? Biaya empiris dan estimasi jadwal? Manajemen proyek berbasis metric ? Memperoleh nilai pelacakan ? Cacat pelacakan terhadap target kualitas ? Orang manajemen proyek menyadari

Tindakan Manajer yang baik process

process metrics project metrics

measurement

product metrics

product

What do we use as a basis? • size? • function? 21

Gambar 21.3.. : Tindakan Manajer yang baik

Mengapa kamu melakukan tindakan pengukuran     

menilai status proyek yang sedang berlangsung melacak potensi risiko mengungkap masalah daerah sebelum mereka pergi "kritis," menyesuaikan alur kerja atau tugas, mengevaluasi kemampuan tim proyek untuk mengontrol kualitas produk kerja perangkat lunak.

Proses pengukuran Kami mengukur efektivitas proses perangkat lunak secara tidak langsung.


 



Artinya, kita memperoleh satu set metrik berdasarkan hasil yang dapat diperoleh dari proses tersebut. hasil meliputi o tindakan kesalahan ditemukan sebelum rilis perangkat lunak o cacat yang disampaikan ke dan dilaporkan oleh pengguna-akhir o produk kerja yang disampaikan (produktivitas) o usaha manusia dikeluarkan o kalender waktu dikeluarkan o kesesuaian jadwal o langkah-langkah lain. Kami juga memperoleh metrik proses dengan mengukur karakteristik tugas rekayasa perangkat lunak tertentu.

Pedoman Proses Metrik       

Gunakan akal sehat dan sensitivitas organisasi ketika menginterpretasikan data metrik. Memberikan umpan balik reguler ke individu dan tim yang mengumpulkan langkah dan metrik. Jangan gunakan metrik untuk menilai individu. Bekerja dengan praktisi dan tim untuk menetapkan tujuan dan metrik yang akan digunakan untuk mencapai mereka jelas. Jangan gunakan metrik untuk mengancam individu atau tim. Data metrik yang menunjukkan masalah daerah tidak boleh dianggap "negatif." Data ini hanyalah indikator untuk perbaikan proses. Jangan terobsesi pada satu metrik dengan mengesampingkan metrik penting lainnya.

Peningkatan Proses Perangkat Lunak Process model Process improvement recommendations

Improvement goals Process metrics

SPI

Gambar 21.4. : Peningkatan Proses Perangkat Lunak


Proses Metrik     

Kualitas terkait o fokus pada kualitas produk kerja dan kiriman Produktivitas-terkait o Produksi karya-produk yang berkaitan dengan usaha yang dikeluarkan Statistik SQA Data o kesalahan kategorisasi & analisis Efisiensi penyisihan Cacat o propagasi kesalahan dari kegiatan proses kegiatan Reuse Data o Jumlah komponen yang diproduksi dan tingkat usabilitas

Proyek Metrik 

 

Digunakan untuk meminimalkan jadwal pengembangan dengan melakukan penyesuaian yang diperlukan untuk menghindari keterlambatan dan mengurangi potensi masalah dan risiko Digunakan untuk menilai kualitas produk secara berkelanjutan dan, bila perlu, memodifikasi pendekatan teknis untuk meningkatkan kualitas. setiap proyek harus mengukur: o input-ukuran sumber daya (misalnya, orang, alat) yang diperlukan untuk melakukan pekerjaan. o output-langkah dari deliverable atau produk kerja yang diciptakan selama proses rekayasa perangkat lunak. o Hasil-langkah yang menunjukkan efektivitas kiriman.

Tipe proyek metric     

Usaha / waktu per tugas rekayasa perangkat lunak Kesalahan ditemukan per review jam Dijadwalkan tanggal vs tonggak yang sebenarnya Perubahan (nomor) dan karakteristik mereka Penyebaran upaya pada tugas-tugas rekayasa perangkat lunak

Petunjuk Metrik   

Gunakan akal sehat dan sensitivitas organisasi ketika menginterpretasikan data metrik. Memberikan umpan balik reguler ke individu dan tim yang telah bekerja untuk mengumpulkan tindakan dan metrik. Jangan gunakan metrik untuk menilai individu.


   

Bekerja dengan praktisi dan tim untuk menetapkan tujuan dan metrik yang akan digunakan untuk mencapai mereka jelas. Jangan gunakan metrik untuk mengancam individu atau tim. Data metrik yang menunjukkan masalah daerah tidak boleh dianggap "negatif." Data ini hanyalah indikator untuk perbaikan proses. Jangan terobsesi pada satu metrik dengan mengesampingkan metrik penting lainnya.

Tipe-tipe pengukuran – Orientasi Metrik        

kesalahan per KLOC (ribu baris kode) cacat per KLOC $ Per LOC halaman dokumentasi per KLOC kesalahan orang per-bulan Kesalahan review per-jam LOC orang per-bulan $ Per halaman dokumentasi

Tipe fungsi – Orientasi Metrik     

kesalahan per FP (ribu baris kode) cacat per FP $ Per FP halaman dokumentasi per FP FP orang per –bulan

Membandingkan LOC dan FP Programming Language

Ada Assembler C C++ COBOL Java JavaSc ript Perl PL/1 Pow erbuilder SAS Sm alltalk SQL Visual Basic

avg.

LOC per Function point m edian low high

154 337 162 66

315 109 53

104 91 33 29

205 694 704 178

77 63 58 60 78 32 40 26 40 47

77 53 63 67 31 41 19 37 42

14 77 42 22 11 33 10 7 16

400 75 263 105 49 55 110 158

Gambar 21.5. Perbandingan LOC dan FP


Mengapa Memilih FP ?    

Bahasa pemrograman independen Digunakan karakteristik mudah dihitung yang ditentukan pada awal proses perangkat lunak Tidak "menghukum" inventif implementasi (pendek) yang menggunakan sedikit LOC bahwa versi yang lebih canggung lainnya Membuatnya lebih mudah untuk mengukur dampak dari komponen reusable

Pengukuran Orientasi Objek    

Jumlah skrip skenario (Use-Case) Jumlah dukungan Class (yang dibutuhkan untuk mengimplementasikan sistem tetapi tidak segera berhubungan dengan masalah domain) Jumlah rata-rata kelas dukungan per Class utama (analisis class) Jumlah subsistem (Class Agregate yang mendukung fungsi yang dapat dilihat oleh pengguna akhir dari suatu sistem)

Metrik projek WebE        

Jumlah halaman Web statis (pengguna akhir tidak memiliki kontrol atas konten yang ditampilkan pada halaman) Jumlah halaman Web dinamis (tindakan pengguna akhir hasil dalam konten yang disesuaikan ditampilkan pada halaman) Jumlah link internal halaman (link halaman internal pointer yang menyediakan hyperlink ke beberapa halaman web lain dalam webapp tersebut) Jumlah objek data persisten Jumlah sistem eksternal dihubungkan Jumlah benda konten statis Jumlah benda konten dinamis Jumlah fungsi dieksekusi

Kualitas pengukuran    

Correctness — sejauh mana program beroperasi sesuai dengan spesifikasi Maintainability— sejauh mana program ini bisa menerima perubahan Integrity— sejauh mana program adalah tahan terhadap serangan dari luar Usability— sejauh mana program ini mudah digunakan


Cacat Penghapusan Efesiensi

DRE = E /(E + D)

E adalah jumlah kesalahan yang ditemukan sebelum pengiriman perangkat lunak untuk pengguna akhir D adalah jumlah cacat yang ditemukan setelah melahirkan.

Metrik untuk ukuran organisasi kecil       

waktu (jam atau hari) berlalu dari waktu permintaan dibuat sampai evaluasi selesai, tqueue. Upaya (orang-jam) untuk melakukan evaluasi, Weval. waktu (jam atau hari) berlalu dari selesainya evaluasi terhadap penugasan perubahan untuk personil, teval. Upaya (orang-jam) yang diperlukan untuk membuat perubahan, Wchange. waktu yang dibutuhkan (jam atau hari) untuk membuat perubahan, tchange. kesalahan ditemukan selama bekerja untuk membuat perubahan, Echange. cacat ditemukan setelah perubahan dilepaskan ke basis pelanggan, Dchange.

Membangun Program Metrik          

Mengidentifikasi tujuan bisnis Anda. Mengidentifikasi apa yang Anda ingin tahu atau belajar. Identifikasi subgoals Anda. Identifikasi entitas dan atribut yang berhubungan dengan subgoals Anda. Meresmikan tujuan pengukuran Anda. Mengidentifikasi pertanyaan kuantitatif dan indikator terkait yang akan Anda gunakan untuk membantu Anda mencapai tujuan pengukuran Anda. Mengidentifikasi elemen-elemen data yang Anda akan mengumpulkan untuk membangun indikator yang membantu menjawab pertanyaan Anda. Tentukan langkah- langkah yang akan digunakan, dan membuat definisi ini operasional. Mengidentifikasi tindakan yang akan Anda ambil untuk menerapkan langkah-langkah. Siapkan rencana untuk melaksanakan langkah- langkah.


Tugas Pertemuan 22-23 Tugas Kelompok (1 grup : 5 orang) Anda pada saat ini dianggap sebagai Manajer Proyek XYZ .

Pengembangan Jaringan Komputer PT.

Kiat sebelum melaksanakan Pengembangan Proyek Jaringan Komputer PT XYZ adalah : 1. Baca konsep Jaringan Komputer untuk kebutuhan pengembangan jaringan computer 2. Baca konsep Manajemen Proyek Perangkat Lunak untuk kebutuhan pengembangan tersebut bab. 22, 23,24,25,26 3. Studi banding melalui internet studi kasus implemenasi manajemen proyek pengembangan jaringan komputerpada perusahaan. Studi Kasus Pengembangan Jaringan Komputer

Di bawah ini diberikan sebuah kasus tentang pengembangan dan pembangunan sebuah jaringan computer pada Universitas XYZ . Dari kasus tersebut akan dibuat sebuah project charter sebagai langkah awal pelaksanaan proyek. KASUS: Upgrade Jaringan Komputer o Jaringan komputer sebuah perusahaan (contoh: Universitas XYZ) terdiri dari 350 PC memakai OS win XP dan Windows 7 , server win/NT; dan 5 server Novell NetWare versi terbaru; o Manajemen perusahaan memutuskan untuk meng-upgrade OS semua PC menjadi Win 7, dan semua server, termasuk server NetWare, menggunakan Win NT Server. o Nama proyek: upgrade sistem operasi menuju Win 7 dan Win NT Server dalam lingkungan UKM. o Sponsor proyek: rektor UKM, CISCO Networking. o Manajer proyek: kepala NOC (network operation centre) . o Tim kerja proyek: network operation center. o Tujuan proyek: Semua OS PC akan di-upgrade ke Win XP pada akhir tahun (20 Des 2012) ini. Semua server akan di-upgrade ke Win 2000 server pada akhir tahun depan (20 Des 2013). o Kasus bisnis:  win XP telah digunakan selama 5 tahun terakhir ini dalam mengelola bisnis perusahaan.  Namun saat ini telah ada produk baru yang memiliki kemampuan jauh lebih baik: Win 7.  Pekerjaan akan lebih produktif, terkendali, aman, dan lebih user-friendly.  Berorientasi teknologi baru spt: jaringan infrared, dan teknologi web-based dalam menunjang informasi di perusahaan, dukungan system mobile.


 

Menggantikan server yang ada dengan multi-processors server yang ditunjang oleh teknologi win XP adv. server. Win XP Adv. Server membantu user dalam menemukan sumberdaya dalam jaringan komputer perusahaan, meningkatkan kinerja jaringan, dan pengamanan yang memadai.

o Hasil proyek yang akan dicapai:  Instalasi Win 07 pada setiap PC  Instalasi Win XP pada setiap server yang ada.  Seluruh instalasi akan selesai pada 20 Des 2013. o Penjadwalan kasar:  Jun:  Coba memulai metode pengembangan, menginventarisari applikasi setiap pemakai PC, menulis scripts untuk proses pemindahan applikasi nantinya.  Agust:  memulai penggantian (100 user). Mencoba, mendokumentasikan problem dan pemecahannya. Mulai desain Win XP Server.  Okt:  Mulai pelatihan Win 7 bagi calon user.  Sementara itu Win 7 mulai diinstalasi pada PC mereka.  Mengecek masalah-masalah yang mungkin ada, dan helpdesk (support) bagi user.  Pengetesan tiga server dengan Win XP.  Des:  Penyelesaian instalasi Win 7.  Mulai menginstalasi Win XP Server dan membangun infrastrukturnya (utk server-server yang baru) dan inventarisasi problem serta penyelesaian.  Instalasi untuk server lainnya dimulai.  Pembangunan infrastruktur diperkirakan memakan waktu satu tahun. 20 Des 2013 keseluruhan proyek selesai. o Sumberdaya proyek:  Perkiraan biaya: Rp. 800 juta. (termasuk biaya software baru, 07, win XP Server, lisensi, konsultan, pelatihan).  Laboratorium pengetesan akan dibooking penuh selama 5 bulan.  Konsultansi dari CISCO Networking Consultancy. Pertanyaan 1. Buatlah perencanaan proyek pengembangan jaringan PT. XYZ ? 2. Buatlah juga perencanaan biaya, waktu, tenaga kerja dan produksi untuk pengembangan jaringan tersebut ?


3. Bagaimana anda melakukan estimasi proyek jika perhitungan estimasi pengembangan jaringan PT. XYZ ? 4. Buatlah juga penjadwalan proyek untuk kebutuhan proyek tersebut ? 5. Dalam pengembangan nantinya dapatkah anda memprediksi resiko yang terjadi pada pengembangan jaringan PT XYZ ? 6. BAgaimana anda mengidentifikasi resiko teknologi, resiko tenaga / orang, resiko dampak bisnis pada pengembangan jaringan PT XYZ ? 7. BAgaimana anda melaksanakan Manajemen Kualitas pada pengembangan jaringan PT XYZ ?


Bab 22 Estimasi Proyek Perangkat Lunak

Tujuan Pembelajaran Umum Mengimplementasikan Manajemen Proyek Perangkat Lunak Tujuan Pembelajaran Khusus Mampu menjalankan estimasi proyek perangkat lunak Perencanaan Proyek Perangkat Lunak Tujuan keseluruhan dari perencanaan proyek ini adalah untuk menetapkan strategi pragmatis untuk mengendalikan, melacak, dan pemantauan proyek teknis yang rumit. Mengapa Untuk menghasilkan proyek perangkat lunak yang tepat waktu dan berkualitas Perencanaan Tugas Proyek Set-I    





menetapkan lingkup proyek menentukan kelayakan menganalisis risiko Mentukan sumber daya yang dibutuhkan o tentukan membutuhkan sumber daya manusia o menentukan sumber daya dapat digunakan kembali perangkat lunak o identifikasi sumber daya lingkungan Estimasi biaya dan usaha o Menguraikan masalah o Mengembangkan dua atau lebih perkiraan menggunakan ukuran, function-point, tugas proses atau use-cases o Rekonsiliasi perkiraan Mengembangkan jadwal proyek o Membangun satu set tugas yang bermakna o Tentukan jaringan tugas o Gunakan alat penjadwalan untuk mengembangkan grafik timeline o Tentukan jadwal mekanisme pelacakan

Estimasi






Estimasi sumber daya, biaya, dan jadwal untuk upaya rekayasa perangkat lunak memerlukan o pengalaman o akses ke informasi historis yang baik (metric) o keberanian untuk melakukan prediksi kuantitatif ketika informasi kualitatif adalah semua yang ada Estimasi membawa risiko yang melekat dan risiko ini menyebabkan ketidakpastian

Lingkup perencanan proyek perangkat lunak dapat digambarkan dengan melihat : estimasiestimasi , resiko-resiko, penjadwalan dan strategi pengawasan.

Project Scope Estimates Risks Schedule Control strategy

Software Project Plan

Gambar 22.1. : Perencanan Proyek Perangkat Lunak Untuk mengerti lingkup proyek seorang pengguna proyek harus mengetahui :      

Memahami Memahami Memahami Memahami Memahami memahami

kebutuhan pelanggan konteks bisnis batasan proyek motivasi pelanggan kemungkinan untuk melakukan perubahan jalan bahwa ...segalanya tidak ada jaminan

Apa itu lingkup proyek      

Menggambarkan Lingkup Software Fungsi dan fitur yang akan dikirimkan ke pengguna akhir Data yang input dan output "Isi" yang disajikan kepada pengguna sebagai konsekuensi dari menggunakan perangkat lunak Kinerja, kendala, antarmuka, dan kehandalan yang terikat sistem. Lingkup didefinisikan menggunakan salah satu dari dua teknik:


 

Sebuah deskripsi narasi lingkup perangkat lunak yang dikembangkan setelah komunikasi dengan semua stakeholder kepentingan. Satu set use case dikembangkan oleh end-user.

Sumber-sumber Sumber-sumber proyek digambarkan memiliki 3 bagian : People : jumlah, keahlian-keahlian dan lokasi pengerjaan proyek Environment : peralatan-peralatan perangkat lunak, perangkat keras, sumber jaringan Reusable software : komponen-komponen OTS, komponen-komponen full experience, komponan-komponen part-esperience, komponen-komponen baru

number

software tools

skills

hardware

people

environment

location

project

OTS components

reusable software

full-experience components

new components

part.-experience components

Gambar 22.2. : Sumber proyek Estimasi Proyek     

Lingkup proyek harus dipahami Elaborasi (penguraian) diperlukan Metrik-metrik masa lampau sangat membantu Setidaknya dua teknik yang berbeda harus digunakan Ketidakpastian yang melekat dalam proses

network resources


Teknik Estimasi      

Masa lampua (similar) pengalaman proyek Teknik estimasi konvensional Task breakdown and effort estimates Estimasi-estimasi ukuran (contoh ., FP) Model-model empiric Peralatan-peralatan otomatisas

Akurasi Estimasi Didasarkan pada ...  

 

sejauh mana perencana telah benar memperkirakan ukuran produk yang akan dibangun kemampuan untuk menerjemahkan ukuran estimasi ke dalam usaha manusia, waktu kalender, dan dolar (fungsi dari ketersediaan metrik perangkat lunak yang handal dari proyek-proyek masa lalu) sejauh mana rencana proyek mencerminkan kemampuan tim perangkat lunak stabilitas persyaratan produk dan lingkungan yang mendukung rekayasa perangkat lunak

Penguraian fungsi Statement of Scope

functional decomposition Perform a Grammatical “parse”

Gambar 22.3.: Functional Decomposition Metode Konvensional : LOC dan FP  

menghitung LOC / FP menggunakan perkiraan nilai domain informasi menggunakan data historis untuk membangun perkiraan untuk proyek

Proses Base Estimation


framework activities application functions

Effort required to accomplish each framework activity for each application function

Gambar 22.4. : Kerangka Kerja Proses Contoh Project Base Estimation Tabel : 22.1. Project Base Estimation Activity

CC

Planning

Risk Analysis

Task

Engineering

Construction Release

analysis

design

code

test

0.50 0.75 0.50 0.50 0.50 0.25 0.50

2.50 4.00 4.00 3.00 3.00 2.00 2.00

0.40 0.60 1.00 1.00 0.75 0.50 0.50

5.00 2.00 3.00 1.50 1.50 1.50 2.00

4.50

16.50

CE

Totals

n/a n/a n/a n/a n/a n/a n/a

8.40 7.35 8.50 6.00 5.75 4.25 5.00

Function UICF 2DGA 3DGA CGDF DSM PCF DAM

Totals

0.25

0.25

0.25

3.50

20.50

% effort

1%

1%

1%

8%

45%

10%

46.00

36%

CC = customer communication CE = customer evaluation

Berdasarkan tingkat tenaga kerja rata-rata terbebani $ 8.000 per bulan, total biaya proyek diperkirakan adalah $ 368.000 dan usaha diperkirakan adalah 46 orang-bulan.


Tool – Base Estimation project characteristics

calibration factors LOC/FP data

Gambar 22.5. : Tool – Base Estimation Estimation with – Use Case

e subsystem User interface subsystem Engineering subsystem group subsystem group Infrastructure subsystemgroup group e subsystem

use cases scenarios pages 6 10 6 10 20 8 5 6 5

Total LOC estimate stimate

Ź scenarios pages LOC LOC estimate Ź 12 5 560 3,366 Ź 16 8 3100 31,233 Ź 10 6 1650 7,970 Ź Ź Ź Ź Ź Ź Ź Ź 42,568

Gambar 22.6. Estimation – Use Case Menggunakan 620 LOC / pm sebagai rata-rata produktivitas untuk sistem jenis ini dan tingkat tenaga kerja dibebani dari $ 8.000 per bulan, biaya per baris kode adalah sekitar $ 13. Berdasarkan estimasi use-cases dan data produktivitas historis, total biaya proyek diperkirakan adalah $ 552.000 dan upaya diperkirakan adalah 68 orang-bulan. Emprical Estimation Model General form:

effort = tuning coefficient * size

exponent

usually derived as person-months of effort required

either a constant or a number derived based on complexity of project

empirically derived

usually LOC but may also be function point

Gambar 22.7. : Empirical Estimation Model


COCOMO II

COCOMO II sebenarnya adalah sebuah hirarki model estimasi yang membahas bidang-bidang berikut: 

 

Aplikasi Model komposisi. Digunakan selama tahap awal rekayasa perangkat lunak, ketika prototipe dari antarmuka pengguna, pertimbangan perangkat lunak dan interaksi sistem, penilaian kinerja, dan evaluasi kematangan teknologi adalah hal yang terpenting. Model tahap desain awal. Digunakan sekali persyaratan telah stabil dan arsitektur perangkat lunak dasar telah ditetapkan. Post model-arsitektur panggung. Digunakan selama pembangunan perangkat lunak.

Persamaan Perangkat Lunak A dynamic multivariable model E = [LOC x B0.333 /P] 3 x (1/t4 ) Dimana : E = dukungan dalam orang- bulan atau orang-tahun T = durasi proyek dalam bulan atau tahun B = factor keahlian-keahlian khusus P = parameter produktivitas Estimasi untuk proyek OO    



Mengembangkan perkiraan menggunakan upaya dekomposisi, analisis FP, dan metode lain yang dapat diterapkan untuk aplikasi konvensional. Menggunakan pemodelan analisis berorientasi objek (Bab 8), mengembangkan use-cases dan menentukan hitungan. Dari model analisis, menentukan jumlah kelas utama (disebut kelas analisis dalam Bab 8). Mengkategorikan jenis antarmuka untuk aplikasi dan mengembangkan suatu pengali untuk dukungan kelas: o Jenis antarmuka Multiplier o Tidak ada GUI 2.0 o Berbasis teks antarmuka pengguna 2,25 o GUI 2.5 o Kompleks GUI 3.0 Kalikan jumlah kelas utama (Langkah 3) dengan multiplier untuk mendapatkan perkiraan untuk jumlah dukungan kelas.


 

Kalikan jumlah kelas (+ support kunci) dengan jumlah rata-rata kerja unit per kelas. Lorenz dan Kidd menyarankan 15 sampai 20 orang per kelas-hari. Cross check perkiraan berbasis kelas dengan mengalikan jumlah rata-rata kerja unit per use case

Estimasi untuk proses Agile       

Setiap user skenario (mini-use case) dianggap terpisah untuk tujuan estimasi. Skenario ini didekomposisi menjadi serangkaian tugas rekayasa perangkat lunak yang akan diperlukan untuk mengembangkannya. Setiap tugas diperkirakan secara terpisah. Catatan: estimasi dapat didasarkan pada data historis, model empiris, atau "pengalaman." Atau, 'volume' skenario dapat diperkirakan di LOC, FP atau ukuran berorientasi volume lainnya (misalnya, jumlah use case). Perkiraan untuk setiap tugas dijumlahkan untuk membuat perkiraan skenario. Atau, estimasi volume untuk skenario diterjemahkan ke dalam upaya menggunakan data historis. Perkiraan Upaya untuk semua skenario yang akan dilaksanakan untuk peningkatan perangkat lunak yang diberikan dijumlahkan untuk mengembangkan usaha perkiraan untuk kenaikan tersebut.

To make by Decision

Gambar 22.8 : To Make by Decision Computing Expected cost


(path probability) x (estimated path cost) i i For example, the expected cost to build is: expected cost

= 0.30 ($380K) + 0.70 ($450K)

build

= $429 K similarly, reus expected cost e $382K buy expected cost expected cost cont $267K r $410K

= = =

Tugas Pertemuan 22 Tugas Kelompok (1 grup : 5 orang) - Pertermuan 22, 23,24,25, 26


Bab 23 Penjadwalan Proyek dan Tracking

Tujuan Pembelajaran Umum Mengimplementasikan Manajemen Proyek Perangkat Lunak Tujuan Pembelajaran Khusus Mampu menjalankan penjadwalan proyek dan Tracking

Mengapa proyek mengalami keterlambatan        

batas waktu yang tidak realistis yang dijanjikan oleh seseorang di luar kelompok pengembangan perangkat lunak perubahan kebutuhan pelanggan yang tidak tercermin dalam perubahan jadwal; meremehkan jujur dari jumlah usaha dan / atau jumlah sumber daya yang akan dibutuhkan untuk melakukan pekerjaan; prediksi risiko dan / atau tida mempertimbangkan ketika proyek dimulai; kesulitan teknis yang tidak bisa diramalkan diawal; kesulitan manusia yang tidak bisa diramalkan diawal; miskomunikasi antara staf proyek yang menghasilkan penundaan; kegagalan oleh manajemen proyek untuk mengakui bahwa proyek ini telah jauh di belakang jadwal dan kurangnya tindakan untuk memperbaiki masalah

Your respon for Napoleon "Setiap Panglima [software manager engineering] yang menyanggupi untuk melaksanakan rencana rusak yang dianggapnya bersalah, ia harus mengajukan alasannya, bersikeras pada rencana yang berubah, dan akhirnya mengajukan pengunduran diri nya daripada menjadi alat pasukannya [proyek tim] kejatuhan. " Bagaimana mengubah jadwal yang tidak realistic    

Lakukan perkiraan usaha dan waktu secara rinci dengan menggunakan data historis Menggunakan proses model bertahap, mengembangkan strategi untuk memberikan fungsionalitas kritis dengan tenggat waktu - dokumen rencana Bertemu dengan pelanggan dan menjelaskan mengapa ? Menawarkan strategi pembangunan tambahan sebagai alternative


Prinsip-prinsip penjadwalan      

Kompartementalisasi (compartmentalization)-mendefinisikan tugas yang berbeda Interdependensi (interdependency) -tugas menunjukkan keterkaitan Upaya validasi (effort validation) –pastikan menjadi sumber tersedia didefinisikan tanggung jawab (define responsibilities) -orang harus ditugaskan hasil-masing (define outcome) - didefinisikan tugas harus memiliki output didefinisikan tonggak (define milestone)s -review untuk kualitas

Dukungan dan Delivery Time

Effort Cost

Ea = m ( t d 4 / t a 4 ) Impossible region

Ea = effort in person-months t d = nominal delivery time for schedule t o = optimal development time (in terms of cost) t a = actual delivery time desired

Ed

Eo to

td

development time

Tmin = 0.75T d

Gambar 23.1. Effort and Delivery Time Hubungan Empirik : P vs E Mengingat Persamaan Putnam Software (5-3), E = L3 / (P3t4) Pertimbangkan sebuah proyek diperkirakan mencapai 33 KLOC, 12 orang-tahun usaha, dengan P 10K, waktu penyelesaian akan menjadi 1,3 tahun Jika batas waktu dapat diperpanjang sampai 1,75 tahun, E = L3 / (P3t4) ≈ 3,8 p-tahun vs 12 p-tahun


Effort Alocation

40-50%

15-20%

30-40%

          

Kegiatan "front end" komunikasi pelanggan analisa disain review dan modifikasi kegiatan konstruksi coding atau generasi kode pengujian dan instalasi Unit, integrasi white-box, Black-box regresi

Definisi Seting Tugas     

menentukan jenis proyek pengembangan konsep, pengembangan aplikasi baru, peningkatan aplikasi, pemeliharaan aplikasi, dan rekayasa ulang proyek menilai tingkat ketelitian yang diperlukan mengidentifikasi kriteria adaptasi memilih tugas rekayasa perangkat lunak yang sesuai

Mengatur ulang perintah (task set refinement) Konsep ruang lingkup menentukan keseluruhan lingkup proyek ? Definisi Tugas: Tugas 1.1 Konsep Penjajakan 1.1.1 Mengidentifikasi kebutuhan, manfaat dan pelanggan potensial; 1.1.2 Tentukan diinginkan keluaran / kontrol dan masukan peristiwa yang mendorong aplikasi; Mulai Tugas 1.1.2 1.1.2.1 FTR: Ulasan penjelasan tertulis tentang kebutuhan FTR menunjukkan bahwa kajian teknis formal (Bab 26) yang akan dilakukan.


1.1.2.2 Turunkan daftar pelanggan terlihat output / input 1.1.2.3 FTR: output Ulasan / input dengan pelanggan dan merevisi sesuai kebutuhan; EndTask Tugas 1.1.2 1.1.3 Menentukan fungsi / perilaku untuk setiap fungsi utama; Mulai Tugas 1.1.3 1.1.3.1 FTR: Output Review dan obyek input data yang diperoleh dalam tugas 1.1.2; 1.1.3.2 Turunkan model fungsi / perilaku; 1.1.3.3 FTR: fungsi / perilaku dengan pelanggan review dan revisi yang diperlukan; EndTask Tugas 1.1.3 1.1.4 Isolat unsur-unsur teknologi yang akan diimplementasikan dalam perangkat lunak; 1.1.5 Penelitian ketersediaan perangkat lunak yang ada; 1.1.6 Menentukan kelayakan teknis; 1.1.7 Membuat perkiraan cepat ukuran; 1.1.8 Membuat Definisi Lingkup; EndTask Definisi: Tugas 1.1 Mendefinisikan Task Network

Gambar 23.2. Task Network Timeline Chart Tasks

Week 1

Week 2

Week 3

Week 4

Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Task 9 Task 10 Task 11 Task 12

\Gambar 23.3. Timeline Charts

Week n


Menggunakan Tools otomatis untuk menentukan Time Line Chart

Gambar 23.4. Tools otomatis untuk menentukan timeline charts Penentuan Penjadwalan  melakukan status pertemuan kegiatan periodik di mana setiap anggota tim melaporkan kemajuan dan permasalahan.  mengevaluasi semua hasil ulasan yang dilakukan selama proses rekayasa perangkat lunak.  menentukan apakah formal toonggak (milestone) proyek (berlian dalam slide sebelumnya) telah dilakukan dengan tanggal yang dijadwalkan.  membandingkan tanggal mulai aktual untuk direncanakan tanggal mulai untuk setiap tugas proyek yang tercantum dalam tabel sumber daya  bertemu secara informal dengan para praktisi untuk memperoleh penilaian subyektif mereka terhadap kemajuan sampai saat dan masalah di cakrawala.  menggunakan analisis nilai yang diperoleh untuk menilai kemajuan kuantitatif Kemajuan OO pada Proyek-I 



Teknis o o o o o Teknis o o o o o o

tonggak: analisis OO selesai Semua kelas dan hirarki kelas telah ditetapkan dan ditinjau. Atribut kelas dan operasi yang terkait dengan kelas telah ditetapkan dan ditinjau. Kelas hubungan (Bab 8) telah dibentuk dan terakhir. Sebuah model perilaku (Bab 8) telah dibuat dan terakhir. Kelas Reusable telah dicatat. tonggak: desain OO selesai Himpunan subsistem (Bab 9) telah ditetapkan dan terakhir. Kelas dialokasikan untuk subsistem dan terakhir. Alokasi tugas telah ditetapkan dan terakhir. Tanggung jawab dan kolaborasi (Bab 9) telah diidentifikasi. Atribut dan operasi telah dirancang dan terakhir. Model komunikasi telah dibuat dan terakhir.\






Teknis o o o Teknis o o

tonggak: pemrograman OO selesai Setiap kelas baru telah diterapkan dalam kode dari model desain. Kelas diekstraksi (dari perpustakaan reuse) telah dilaksanakan. Prototipe atau kenaikan telah dibangun. tonggak: OO pengujian Kebenaran dan kelengkapan analisis OO dan model desain telah ditinjau. Sebuah jaringan kelas-tanggung-kolaborasi (Bab 8) telah dikembangkan dan ditinjau. o Uji kasus dirancang dan tes tingkat kelas (Bab 14) telah dilakukan untuk setiap kelas. o Uji kasus dirancang dan pengujian klaster (Bab 14) selesai dan kelas yang terintegrasi. o Tes tingkat sistem telah selesai.

Earned Value Analysis nilai yang diterima (Earned Value) o adalah ukuran kemajuan o memungkinkan kita untuk menilai "persen kelengkapan" dari proyek menggunakan analisis kuantitatif daripada mengandalkan firasat o "Memberikan pembacaan yang akurat dan dapat diandalkan kinerja dari sedini 15 persen ke dalam proyek." [FLE98]

Perhitungan Earned Value  Menganggarkan biaya pekerjaan dijadwalkan (BCWS) ditentukan untuk setiap tugas pekerjaan diwakili dalam jadwal.  BCWSi adalah usaha yang direncanakan untuk pekerjaan tugas i.  Untuk menentukan kemajuan pada suatu titik tertentu di sepanjang jadwal proyek, nilai BCWS adalah jumlah nilai BCWSi untuk semua tugas pekerjaan yang seharusnya diselesaikan oleh titik waktu pada jadwal proyek.  Nilai-nilai BCWS untuk semua tugas pekerjaan dijumlahkan untuk memperoleh anggaran di selesai, BAC. Oleh karena itu,  BAC = Σ (BCWSk) untuk semua tugas k  Selanjutnya, nilai untuk biaya proyek yang dianggarkan dari pekerjaan yang dilakukan (BCWP) dihitung. o Nilai untuk BCWP adalah jumlah nilai BCWS untuk semua tugas pekerjaan yang benar-benar telah diselesaikan oleh titik waktu pada jadwal proyek.  "Perbedaan antara BCWS dan BCWP adalah bahwa mantan merupakan anggaran kegiatan yang direncanakan akan selesai dan yang terakhir merupakan anggaran kegiatan yang benar-benar diselesaikan." [WIL99]  Mengingat nilai untuk BCWS, BAC, dan BCWP, indikator kemajuan penting dapat dihitung: o Indeks kinerja jadwal, SPI = BCWP / BCWS o Jadwal varians, SV = BCWP - BCWS


  

o SPI merupakan indikasi efisiensi proyek yang memanfaatkan sumber daya dijadwalkan. Persen dijadwalkan selesai = BCWS / BAC o memberikan indikasi persentase pekerjaan yang seharusnya selesai pada saat t. Persen selesai = BCWP / BAC o memberikan indikasi kuantitatif persen kelengkapan proyek pada suatu titik waktu tertentu, t. Biaya yang sebenarnya pekerjaan yang dilakukan, ACWP, adalah jumlah dari upaya sebenarnya dikeluarkan pada tugas-tugas pekerjaan yang telah diselesaikan oleh titik waktu pada jadwal proyek. Hal ini kemudian memungkinkan untuk menghitung o Indeks kinerja biaya, CPI = BCWP / ACWP o Biaya varians, CV = BCWP – ACWP

Permasalahan 23.2. Asumsikan Anda seorang manajer proyek perangkat lunak dan bahwa Anda telah diminta untuk komputer diperoleh nilai statistik untuk proyek software kecil. Proyek ini memiliki 56 tugas pekerjaan yang direncanakan yang diperkirakan membutuhkan 582 orang-hari untuk menyelesaikan. Pada saat Anda telah diminta untuk melakukan analisis nilai yang diperoleh, 12 tugas telah selesai. Namun, jadwal proyek menunjukkan bahwa 15 tugas harus sudah selesai. Data penjadwalan berikut (dalam orang-hari) yang tersedia:

Task 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Planned Effort Actual Effort 12 12.5 15 11 13 17 8 9.5 9.5 9.0 18 19 10 10 4 4.5 12 10 6 6.5 5 4 14 14.5 16 6 8



Bab 24 Manajemen Resiko Proyek

Tujuan Pembelajaran Umum Mengimplementasikan Manajemen Proyek Perangkat Lunak Tujuan Pembelajaran Khusus Mampu menjalankan Manajemen Resiko Proyek

Resiko Proyek Apa Apa Apa Apa

yang dapat salah? / What can go wrong? memungkinan? / What is the likelihood? yang akan merusak itu? / What will the damage be ? yang dapat kita lakukan tentang hal itu? / What can we do about it?

Reaktif Resiko  Tim proyek bereaksi terhadap risiko saat terjadi  Mitigasi-rencana sumber daya tambahan untuk mengantisipasi pemadaman kebakaran  kegagalan memperbaiki pada -sumber daya yang ditemukan dan diterapkan ketika risiko pemogokan  Kegagalan krisis manajemen tidak merespon sumber daya diterapkan dan proyek dalam bahaya Proaktif Resiko  Analisis formal risiko dilakukan  Mengoreksi organisasi akar penyebab risiko o Konsep TQM dan statistik SQA o memeriksa sumber risiko yang berada di luar batas-batas perangkat lunak o mengembangkan keterampilan untuk mengelola perubahan 7 Prinsip-prinsip  

Maintain a global perspective— global risiko perangkat lunak dalam konteks sistem dan masalah bisnis Take a forward-looking view—-berpikir tentang risiko yang mungkin timbul di masa depan, membangun rencana kontinjensi


    

Encourage open communication— jika seseorang menyatakan potensi risiko, jangan mengabaikannya. Integrate— pertimbangan risiko harus diintegrasikan ke dalam proses perangkat lunak Emphasize a continuous process—the team must be vigilant throughout the software process, modifying identified risks as more information is known and adding new ones as better insight is achieved. Develop a shared product vision— jika semua pemangku kepentingan berbagi visi yang sama dari perangkat lunak, kemungkinan bahwa identifikasi risiko yang lebih baik dan penilaian akan terjadi.. Encourage teamwork— keterampilan dan pengetahuan dari seluruh stakeholder harus dikumpulkan

Paradigma Manajemen Resiko

control track

RISK

identify

plan analyze Gambar 24.1. Risk Management Paradigm Identifikasi Resiko  Resiko Ukuran yang terkait dengan ukuran keseluruhan dari perangkat lunak yang akan dibangun atau diubah produk.  Resiko Dampak yang terkait dengan kendala yang diberlakukan oleh manajemen atau pasar bisnis.  Resiko Karakteristik Pelanggan yang terkait dengan kecanggihan pelanggan dan kemampuan pengembang untuk berkomunikasi dengan pelanggan secara tepat waktu.  Resiko Mendefinisikan Proses yang terkait dengan sejauh mana proses perangkat lunak telah didefinisikan dan diikuti oleh organisasi pembangunan.  Resiko Pengembang Perangakt Lunak yang terkait dengan ketersediaan dan kualitas alat yang akan digunakan untuk membangun produk.  Resiko menjadi bangunan teknologi yang terkait dengan kompleksitas sistem yang akan dibangun dan "kebaruan" dari teknologi yang dikemas oleh sistem.  Resiko ukuran dan pengalaman staf yang terkait dengan pengalaman teknis dan proyek secara keseluruhan dari insinyur perangkat lunak yang akan melakukan pekerjaan. Mengevaluasi Resiko Proyek


          

Memiliki atas perangkat lunak dan manajer pelanggan resmi berkomitmen untuk mendukung proyek tersebut? Apakah pengguna akhir antusias berkomitmen untuk proyek dan sistem / produk yang akan dibangun? Apakah persyaratan sepenuhnya dipahami oleh tim rekayasa perangkat lunak dan pelanggan mereka? Apakah pelanggan terlibat sepenuhnya dalam definisi persyaratan? Apakah pengguna akhir memiliki harapan yang realistis? Apakah lingkup proyek stabil? Apakah tim rekayasa perangkat lunak memiliki keterampilan campuran yang tepat? Apakah persyaratan proyek stabil? Apakah tim proyek memiliki pengalaman dengan teknologi yang akan diterapkan? Apakah jumlah orang di tim proyek yang memadai untuk melakukan pekerjaan itu? Apakah semua pelanggan / pengguna konstituen setuju tentang pentingnya proyek dan pada persyaratan sistem / produk yang akan dibangun?

Komponen Resiko  risiko kinerja (performance risk) tingkat ketidakpastian bahwa produk akan memenuhi persyaratan dan akan fit untuk digunakan.  biaya-risiko (cost risk) tingkat ketidakpastian bahwa anggaran proyek akan dipertahankan.  mendukung risiko (support risk) tingkat ketidakpastian bahwa perangkat lunak yang dihasilkan akan mudah untuk diperbaiki, beradaptasi, dan ditingkatkan.  jadwal-risiko (schedule risk) tingkat ketidakpastian bahwa jadwal proyek akan dipertahankan dan bahwa produk akan dikirimkan tepat waktu. Proyeksi Resiko  Proyeksi Risiko, juga disebut estimasi risiko, upaya untuk menilai setiap risiko dalam dua cara o kemungkinan atau probabilitas bahwa resiko itu nyata o konsekuensi dari masalah yang terkait dengan risiko, harus itu terjadi.  Ini ada empat langkah proyeksi risiko: o menetapkan skala yang mencerminkan kemungkinan resiko yang dirasakan o menggambarkan konsekuensi dari risiko o memperkirakan dampak risiko pada proyek dan produk, o perhatikan akurasi keseluruhan proyeksi risiko sehingga tidak akan ada kesalahpahaman. Membangun table resiko +


Tabel 24.1. Tabel Risk Mitigation Monitoring and Management Risk Propability Impact

    

RMMM Risk Mitigation Monitoring & Management

Memperkirakan probabilitas terjadinya Memperkirakan dampak pada proyek pada skala 1 sampai 5, di mana 1 = dampak yang rendah pada keberhasilan proyek 5 = dampak bencana pada keberhasilan proyek mengurutkan tabel dengan probabilitas dan dampaknya

Paparan Risiko (Impact) 

Eksposur risiko secara keseluruhan, RE, ditentukan dengan menggunakan hubungan berikut [HAL98]: RE = P x C dimana P adalah probabilitas terjadinya risiko untuk, dan C adalah biaya untuk proyek harus risiko yang terjadi

Contoh paparan resiko Identifikasi Risiko. Hanya 70 persen dari komponen perangkat lunak untuk digunakan kembali dijadwalkan akan, pada kenyataannya, diintegrasikan ke dalam aplikasi. Fungsionalitas yang tersisa akan harus custom dikembangkan. Probabilitas Risiko. Dari 80% (kemungkinan). Dampak risiko. 60 komponen perangkat lunak dapat digunakan kembali yang direncanakan. Jika hanya 70 persen dapat digunakan, 18 komponen itu harus dikembangkan dari awal (di samping perangkat lunak kustom lain yang telah dijadwalkan untuk pengembangan). Karena komponen rata-rata adalah 100 LOC Data dan lokal menunjukkan bahwa biaya rekayasa perangkat lunak untuk setiap LOC adalah $ 14,00, Biaya keseluruhan (dampak) untuk mengembangkan komponen akan menjadi 18 x 100 x 14 = $ 25.200. Eksposur risiko. RE = 0.80 x 25.200 ~ $ 20.200.. Mitigasi Resiko, Pengawasan dan Pengaturan (Risk Mitigation Monitoring dan Management)  mitigasi-bagaimana kita bisa menghindari risiko?  monitoring-faktor apa yang bisa kita melacak yang akan memungkinkan kita untuk menentukan apakah risiko menjadi lebih atau kurang mungkin?  manajemen-apa rencana darurat yang kita miliki jika risiko menjadi kenyataan? Resiko karena ukuran produk Atribut yang dapat memberikan efek resiko - estimasi ukuran produk berdasarkan LOC dan FP


-

estimasi ukuran produk berdasarkan banyaknya program-program, file-file, transaksitransaksi deviasi presentasi didalam ukuran produk pada rata-rata produk sebelumnya ukuran membuat database yang digunakan untuk produk banyaknya user menggunakan produk banyak perubahan proyek untuk kebutuhan produk ? sebelum didelivery ? dan setelah didelivery ? rata-rata perangkat lunak digunkan kembali ?

Resiko karena dampak bisnis Atribut -

yang dapat memberikan efek resiko produk yang dikembangkan mempengaruhi pendapatan perusahaan ? visibilitas produk terhadap senior manajemen ? kewajaran batas waktu delivery produk ? banyaknya pelanggan yang menggunakan produk kendala interoperabilitas kecanggihan pengguna akhir ? jumlah dan kualitas produk yang harus diproduksi dan didelivery ke pelanggan ? batasan-batasan pemerintah biaya yang terkait dengan pengiriman terlambat? biaya yang berkaitan dengan cacat produk ?

Risiko Karena Nasabah Pertanyaan-pertanyaan yang harus dijawab : - Apakah Anda bekerja dengan pelanggan di masa lalu? - Apakah pelanggan memiliki gagasan persyaratan yang solid? - Apakah pelanggan setuju untuk menghabiskan waktu dengan Anda? - Apakah pelanggan bersedia untuk berpartisipasi dalam mereview? - Apakah pelanggan secara teknis canggih? - Apakah pelanggan bersedia untuk membiarkan orang-orang Anda melakukan pekerjaan mereka-yaitu, pelanggan akan menolak melihat melewati bahu Anda selama bekerja teknis rinci ? - Apakah pelanggan memahami proses rekayasa perangkat lunak? Resiko karena proses jatuh tempo ? / Risks Due to Process Maturity Pertanyaan-pertanyaan yang harus dijawab : - Sudahkah Anda menetapkan kerangka proses kerja yang umum? - Apakah diikuti oleh tim proyek? - Apakah Anda memiliki dukungan manajemen rekayasa perangkat lunak - Apakah Anda memiliki pendekatan proaktif untuk SQA ? - Apakah Anda melakukan tinjauan teknis formal ? - Apakah CASE tools yang digunakan untuk analisis, desain dan pengujian ? - Apakah alat terintegrasi satu sama lain ? - Apakah format dokumen telah dibuat ? Resiko Teknologi


Pertanyaan-pertanyaan yang harus dijawab : - Apakah teknologi baru untuk organisasi Anda? - Apakah algoritma baru, teknologi I / O yang dibutuhkan? - Apakah perangkat keras baru atau belum terbukti terlibat? - Apakah antarmuka aplikasi dengan software baru? - Apakah user interface khusus yang dibutuhkan? - Apakah aplikasi berbeda secara radikal? - Apakah Anda menggunakan metode rekayasa perangkat lunak baru? - Apakah Anda menggunakan metode pengembangan perangkat lunak konvensional, seperti metode formal, pendekatan AI berbasis jaringan syaraf tiruan? - Apakah ada kendala kinerja yang signifikan? - Apakah ada meragukan fungsi yang diminta adalah "do-able?" Resiko Staf/Orang Pertanyaan-pertanyaan yang harus dijawab : - Apakah orang-orang terbaik yang tersedia? - Apakah staf memiliki keterampilan yang tepat? - Apakah cukup banyak orang yang tersedia? - Apakah staf berkomitmen untuk seluruh durasi? - Apakah beberapa orang bekerja part-time? - Apakah staf memiliki harapan yang benar? - Memiliki staf menerima pelatihan yang diperlukan? - Apakah pergantian di antara staf menjadi rendah? Contoh : Rekaman Informasi Resiko • Proyek: Embedded software untuk sistem XYZ • Jenis risiko: risiko jadwal • Prioritas (1 rendah ... 5 kritis): 4 • Faktor Risiko: penyelesaian proyek akan tergantung pada tes yang membutuhkan • komponen perangkat keras dalam pengembangan. komponen perangkat keras • pengiriman mungkin tertunda • Probabilitas: 60% • Dampak: penyelesaian proyek akan ditunda untuk setiap hari • hardware tidak tersedia untuk digunakan dalam pengujian perangkat lunak • Pemantauan pendekatan: • Ulasan tonggak dijadwalkan dengan grup hardware • Contingency plan: • Modifikasi strategi pengujian untuk mengakomodasi delay menggunakan • perangkat lunak simulasi • Perkiraan sumber: 6 orang bulan tambahan mulai 7-1-96 Tugas Pertemuan 24 Tugas Kelompok (1 grup : 5 orang) - Pertermuan 22, 23,24,25, 26


Bab 25 Manajemen Kualitas

Tujuan Pembelajaran Umum Mengimplementasikan Manajemen Proyek Perangkat Lunak Tujuan Pembelajaran Khusus Mampu menjalankan Manajemen Kualitas Kualitas The American Heritage Dictionary mendefinisikan kualitas sebagai"Karakteristik atau atribut dari sesuatu."    

Untuk perangkat lunak, dua jenis kualitas mungkin dihadapi: Kualitas desain meliputi persyaratan, spesifikasi, dan desain sistem. Kualitas kecocokan adalah masalah difokuskan terutama pada implementasi. kepuasan pengguna produk compliant = + kualitas bagus + pengiriman dalam anggaran dan jadwal

Kualitas Perangkat Lunak Kesesuaian dengan persyaratan eksplisit dinyatakan fungsional dan kinerja, standar pengembangan eksplisit didokumentasikan, dan karakteristik implisit yang diharapkan dari semua perangkat lunak yang dikembangkan secara profesional. Biaya Kualitas 





Prevention costs include  perencanaan mutu  Tinjauan ulang teknis formal  alat uji  pelatihan Internal failure costs include  mengolah lagi  memperbaiki  analisis modus kegagalan External failure costs are  penyelesaian keluhan  pengembalian produk dan penggantian  membantu mendukung baris  garansi pekerjaan


Jaminan Kualitas Perangkat Lunak Process Definition & Standards

Formal Technical Reviews

Analysis & Reporting Measurement

Test Planning & Review

Gambar 25.1. Jaminan Kualitas Peran SQA  Menyiapkan rencana SQA untuk sebuah proyek.  Rencana ini mengidentifikasi evaluasi yang akan dilakukan o audit dan review yang akan dilakukan o standar yang berlaku untuk proyek o prosedur untuk kesalahan pelaporan dan pelacakan o dokumen yang akan dihasilkan oleh kelompok SQA o Jumlah umpan balik yang diberikan kepada tim proyek perangkat lunak  Berpartisipasi dalam pengembangan perangkat lunak proses deskripsi proyek. o Kelompok SQA ulasan deskripsi proses sesuai dengan kebijakan organisasi, standar perangkat lunak internal, standar eksternal yang dipaksakan (misalnya, ISO-9001), dan bagian lain dari rencana proyek perangkat lunak  Ulasan aktivitas rekayasa perangkat lunak untuk memverifikasi sesuai dengan proses perangkat lunak yang didefinisikan. o mengidentifikasi, dokumen, dan trek deviasi dari proses dan memverifikasi bahwa koreksi telah dibuat.  Audit ditunjuk produk kerja perangkat lunak untuk memverifikasi sesuai dengan yang didefinisikan sebagai bagian dari proses perangkat lunak. o ulasan dipilih produk kerja, identifikasi, dokumen, dan trek deviasi, memverifikasi bahwa koreksi telah dibuat o laporan berkala hasil kerja kepada manajer proyek.  Memastikan bahwa penyimpangan dalam pekerjaan perangkat lunak dan produk kerja didokumentasikan dan ditangani sesuai dengan prosedur yang terdokumentasi.  Merekam setiap ketidakpatuhan dan melaporkannya kepada manajemen senior. o Item ketidakpatuhan dilacak sampai mereka diselesaikan.

Mengapa Aktifitas SQA mengalami pay off ?


cost to find and fix a defect 100

60.00-100.00

log scale 10

1

10.00

0.75

Req.

1.00

1.50

Design

3.00

test system code test

field use

Gambar 25.2. SQA Activities Pay Off Meninjau dan Pemeriksaan Tidak ada alasan yang umum mengapa teman anda dan rekan tidak juga bisa kritikus kritisi Anda Apa itu meninjau  Pertemuan yang dilakukan oleh orang-orang teknis untuk orang-orang teknis  Penilaian teknis dari produk kerja yang diciptakan selama proses rekayasa perangkat lunak  Mekanisme jaminan kualitas perangkat lunak  Tempat pelatihan Mengapa meninjau tidak jadi dilakukan  Sebuah ringkasan proyek atau penilaian kemajuan  Pertemuan dimaksudkan semata-mata untuk memberikan informasi  Sebuah mekanisme untuk pembalasan politik atau pribadi! Pemain dalam jaminan kualitas Perangkat Lunak


review leader

standards bearer (SQA)

producer

maintenance oracle

reviewer

recorder user rep

Gambar 25.3. Pemain dalam Jaminan Kualitas Perangkat Lunak Melakukan Peninjauan (Review)        

menjadi kesiapan evaluasi produk sebelum review meninjau produk, bukan produk menjaga nada ringan, mengajukan pertanyaan daripada membuat tuduhan menempel agenda ulasan mengangkat isu-isu, tidak menyelesaikannya menghindari diskusi tentang gaya-stick ke kebenaran teknis jadwal ulasan sebagai tugas proyek mencatat dan melaporkan semua hasil ulasan

Meninjau opsi matriks

trained leader agenda established reviewers prepare in advance producer presents product “reader” presents product recorder takes notes checklists used to find errors errors categorized as found issues list created team must sign-off on result

IPR *

WT

IN

no maybe maybe maybe no maybe no no no no

yes yes yes yes no yes no no yes yes

yes yes yes no yes yes yes yes yes yes

* IPR—informal peer review WT—Walkthrough IN—Inspection RRR—round robin review

Gambar 25.4. Tinjauan Opsi Matriks

RRR yes yes yes no no yes no no yes maybe


Sample-Driven Reviews (SDRs)  SDR mencoba untuk mengukur produk-produk kerja yang merupakan target utama untuk FTRs penuh.  Untuk mencapai hal ini ... o Menginspeksi ai sebagian kecil dari setiap produk kerja perangkat lunak, i. Catat jumlah kesalahan, fi ditemukan dalam ai. o Mengembangkan perkiraan kotor jumlah kesalahan dalam pekerjaan produk i dengan mengalikan fi oleh 1/ai. o Urutkan produk kerja dalam urutan menurut perkiraan kotor jumlah kesalahan di setiap. o Fokus sumber daya yang tersedia review pada produk-produk kerja yang memiliki tertinggi perkiraan jumlah kesalahan. Metrik-metrik berdasarkan dari ulasan  inspection time per page of documentation  inspection time per KLOC or FP  inspection effort per KLOC or FP  errors uncovered per reviewer hour  errors uncovered per preparation hour  errors uncovered per SE task (e.g., design)  number of minor errors (e.g., types  number of major errors o (e.g., nonconformance to req  number of errors found during preparation Statistik SQA

Product & Process

Collect information on all defects Find the causes of the defects Move to provide fixes for the process

measurement ... an understanding of how to improve quality ... Gambar 25.5. Statistik SQA


Six Sigma untuk Rekayasa Perangkat Lunak  Istilah "six sigma" berasal dari enam standar deviasi 3,4-contoh (cacat) per juta kejadianmenyiratkan standar kualitas yang sangat tinggi.  Metodologi Six Sigma mendefinisikan tiga langkah utama: o Tentukan kebutuhan pelanggan dan kiriman dan tujuan proyek melalui metode yang jelas komunikasi pelanggan o Mengukur proses yang ada dan outputnya menentukan kinerja kualitas saat ini (mengumpulkan metrik cacat) o Menganalisis metrik cacat dan menentukan beberapa penyebab penting.  Meningkatkan proses dengan menghilangkan akar penyebab cacat.  Mengendalikan proses untuk memastikan bahwa pekerjaan di masa depan tidak memperkenalkan penyebab cacat. Realibilitas Perangkat Lunak  Sebuah ukuran sederhana keandalan adalah mean-time-between failure rata-rata waktu antara kegagalan (MTBF), di mana MTBF = MTTF + MTTR  Singkatan MTTF, dan MTTR yang mean-time-to-failure /rata-rata waktu kegagalan dan mean-time-to-repair / rata-rata waktu perbaikan , berturut-turut.  Ketersediaan Software adalah probabilitas bahwa sebuah program beroperasi sesuai dengan kebutuhan pada suatu titik waktu dan didefinisikan sebagai o Ketersediaan (Availability) = [MTTF / (MTTF + MTTR)] x 100 Keamanan Perangkat Lunak  Keselamatan Software adalah kegiatan jaminan kualitas perangkat lunak yang berfokus pada identifikasi dan penilaian potensi bahaya yang dapat mempengaruhi secara negatif, dan menyebabkan perangkat lunak keseluruhan sistem untuk gagal.  Jika bencana dapat diidentifikasi di awal proses perangkat lunak, fitur desain perangkat lunak dapat ditentukan yang baik akan menghilangkan atau mengontrol potensi bahaya. Kesalahan-Proofing  Poka-yoke (pengoreksi kesalahan) perangkat-mekanisme yang menyebabkan o pencegahan masalah kualitas potensial sebelum terjadi atau o deteksi cepat masalah kualitas jika mereka diperkenalkan.  Sebuah perangkat poka-yoke efektif menunjukkan seperangkat karakteristik umum: o Hal ini sederhana dan murah. Jika perangkat terlalu rumit atau mahal, tidak akan efektif. o Ini adalah bagian dari proses. Artinya, perangkat poka-yoke ini diintegrasikan menjadi sebuah kegiatan rekayasa. o Kota ini terletak dekat tugas proses dimana kesalahan terjadi. Dengan demikian, ia menyediakan umpan balik yang cepat dan koreksi kesalahan. Standar ISO 9000-2001  ISO 9001:2000 adalah standar jaminan kualitas yang berlaku untuk rekayasa perangkat lunak.


 

Standar ini berisi 20 persyaratan yang harus hadir untuk sistem jaminan mutu yang efektif. Persyaratan digambarkan oleh ISO 9001:2000 alamat topik seperti o tanggung jawab manajemen, sistem mutu, review, desain kontrol, dokumen dan data kontrol kontrak, identifikasi produk dan mampu telusur, kontrol proses, inspeksi dan pengujian, tindakan korektif dan pencegahan, pengendalian catatan mutu, audit mutu internal, pelatihan, pelayanan, dan teknik statistik .



Bab 26 Change Management

Tujuan Pembelajaran Umum Mengimplementasikan Manajemen Proyek Perangkat Lunak Tujuan Pembelajaran Khusus Mampu menjalankan Change Management

No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle. Bersoff, et al, 1980 Dapat diterjemahkan sebagai berikut : Tidak peduli di mana Anda berada dalam siklus hidup sistem, sistem akan berubah (change), dan keinginan untuk mengubahnya akan bertahan sepanjang siklus hidup. Apakah ini perubahan : PAda perkembangan bisnis yang selalu mengikuti trend tentunya mengalami perubahan perubahan : 1. Perubahan-perubahan di dalam kebutuhan-kebutuhan bisnis 2. Perubahan-perubahan di dalam kebutuhan-kebutuhan teknikal 3. Perubahan-perubahan di dalam kebutuhan-kebutuhan user Mengakibatkan model perangkat lunak juga mengalami perubahan

247 Fasilkom – Universitas Esa Unggul changes in business requirements changes in technical requirements changes in user requirements

other documents

software models Project Plan

Test

code

Gambar 26.1. Perubahan-perubahan yang terjadi pada Bisnis Konfigurasi Perangkat Lunak : Merupakan bagian-bagian pada program-program, dokumen-dokumen dan data Base Line IEEE (. IEEE Std No 610,12-1990) mendefinisikan dasar (baseline) sebagai: Sebuah spesifikasi atau produk yang telah resmi terakhir dan disepakati, yang kemudian berfungsi sebagai dasar untuk pengembangan lebih lanjut, dan yang dapat diubah hanya melalui prosedur pengendalian perubahan formal. data baseline merupakan tonggak dalam pengembangan perangkat lunak yang ditandai dengan penyerahan satu atau lebih item konfigurasi perangkat lunak dan persetujuan SCIS tersebut yang diperoleh melalui review teknis formal modified SCIs Project database Software engineering tasks

SCIs

Formal technical reviews

approved SCIs stored SCIs

extracted SCM controls

SCIs BASELINES: System Specification Software Requirements Design Specification Source Code Test Plans/Procedures/Data Operational System

Gambar 26.2. Baseline


Objek-objek Konfigurasi Perangkat Lunak (Software Configuration Objects) Data model Design specification data design architectural design module design interface design Component N

Test specification

interface description algorithm description PDL

test plan test procedure test cases Source code

Gambar 26.3. Software Configuration Objects SCM Repository SCM repositori adalah seperangkat mekanisme dan struktur data yang memungkinkan tim software untuk mengelola perubahan secara efektif Repositori melakukan atau endapan fungsi- fungsi berikut [FOR89]:      

integritas data (data integrity) berbagi informasi (information sharing) integrasi alat (tool integration) integrasi data (data integration) penegakan metodologi (methodology enforcement) standardisasi dokumen (document standardization)

Konten Repositori

249 Fasilkom – Universitas Esa Unggul b u sin e ss ru le s b u sin e ss fu n ct io n s o rg an izat io n st ru ct u re in fo rm at io n arch it e ct u re

Business Cont ent

u se -case s an aly sis m o d e l sce n ario -b ase d d iag ram s flo w -o rie n t e d d iag ram s class-b ase d d iag ram s b e h av io ral d iag ram s d e sig n m o d e l arch it e ct u ral d iag ram s in t e rface d iag ram s co m p o n e n t -le v e l d iag ram s t e ch n ical m e t rics

so u rce co d e o b j e ct co d e sy st e m b u ild in st ru ct io n s

Const ruct ion Cont ent

t e st case s t e st scrip t s t e st re su lt s q u alit y m e t rics

Model Cont ent V&V Cont ent

p ro j e ct e st im at e s p ro j e ct sch e d u le

Project Management Cont ent

SCM re q u ire m e n t s ch an g e re q u e st s ch an g e re p o rt s SQA re q u ire m e n t s p ro j e ct re p o rt s/ au d it re p o rt s p ro j e ct m e t rics

Document s

Pro j e ct Plan SCM/ SQA Plan Sy st e m Sp e c Re q u ire m e n t s Sp e c De sig n Do cu m e n t Te st Plan an d Pro ce d u re Su p p o rt d o cu m e n t s Use r m an u al

Gambar 26.4. Repository Content Fitur Repository 









Versioning. o menyimpan semua versi untuk memungkinkan manajemen yang efektif dari rilis produk dan untuk mengizinkan pengembang untuk kembali ke versi sebelumnya Pelacakan ketergantungan dan manajemen perubahan.( Dependency tracking and change management) o Repositori mengelola berbagai hubungan antara elemen data yang tersimpan di dalamnya. Persyaratan tracing. (requirement tracing) o Menyediakan kemampuan untuk melacak semua komponen desain dan konstruksi dan kiriman yang dihasilkan dari spesifikasi kebutuhan spesifik Manajemen konfigurasi. (configuration management) o Melacak serangkaian konfigurasi yang mewakili tonggak proyek tertentu atau rilis produksi. Manajemen versi menyediakan versi yang diperlukan, dan manajemen link melacak saling ketergantungan. Audit trails. o menetapkan informasi tambahan tentang kapan, mengapa, dan oleh siapa perubahan yang dibuat.

Elemen-elemen SCM 

Elemen-komponen set alat digabungkan dalam sistem file manajemen (misalnya, database) yang memungkinkan akses ke dan pengelolaan setiap item konfigurasi perangkat lunak.








Proses unsur-koleksi prosedur dan tugas-tugas yang mendefinisikan pendekatan yang efektif untuk mengubah manajemen (dan kegiatan yang terkait) untuk semua konstituen yang terlibat dalam manajemen, teknik dan penggunaan perangkat lunak komputer. Elemen-konstruksi set alat yang mengotomatisasi pembangunan perangkat lunak dengan memastikan bahwa set yang tepat dari komponen divalidasi (yaitu, versi yang benar) telah dirakit. Elemen-Human menerapkan SCM yang efektif, tim perangkat lunak menggunakan satu set alat dan fitur proses (mencakup elemen CM lainnya)

Proses SCM, beberapa pertanyaan yang dilontarkan antara lain :  

   

Bagaimana sebuah tim software mengidentifikasi elemen-elemen diskrit dari konfigurasi perangkat lunak? Bagaimana sebuah organisasi mengelola banyak versi yang ada dari sebuah program (dan dokumentasi) dengan cara yang akan memungkinkan perubahan untuk ditampung secara efisien? Bagaimana sebuah perubahan pengendalian organisasi sebelum dan sesudah perangkat lunak dirilis ke pelanggan? Siapa yang memiliki tanggung jawab untuk menyetujui dan peringkat perubahan? Bagaimana kita dapat memastikan bahwa perubahan telah dilakukan dengan benar? Mekanisme apa yang digunakan untuk menilai orang lain dari perubahan yang dibuat? Software Vm.n

reporting

configuration auditing version control change control identification

SCIs

Gambar 26.5. Proses SCM


Pengawasan Versi  

Versi kontrol menggabungkan prosedur dan alat untuk mengelola versi yang berbeda dari objek konfigurasi yang dibuat selama proses perangkat lunak Sebuah sistem kontrol mengimplementasikan versi atau langsung terintegrasi dengan empat kemampuan utama: o database proyek (repositori) yang menyimpan semua benda konfigurasi yang relevan o kemampuan manajemen versi yang menyimpan semua versi dari objek konfigurasi (atau memungkinkan versi yang akan dibangun menggunakan perbedaan dari versi sebelumnya); o fasilitas make yang memungkinkan software engineer untuk mengumpulkan semua benda konfigurasi yang relevan dan membangun versi tertentu dari perangkat lunak. o sebuah pelacakan masalah (juga disebut pelacakan bug) kemampuan yang memungkinkan tim untuk merekam dan melacak status semua isu yang beredar terkait dengan setiap konfigurasi objek.

Change Control

STOP

GAmbar 26.6. Change Control Change Control Proses 1


need for change is recognized change request from user

developer evaluates change report is generated

change control authority decides request is queued for action change request is denied user is informed change control process—I

Gambar 26.7. Change Control Proces 1 assign people to SCIs check-out SCIs make the change review/audit the change

establish a “baseline” for testing change control process—II

Gambar 26.8. Change Control Proces 2 perform SQA and testing activities check-in the changed SCIs

promote SCI for inclusion in next release rebuild appropriate version review/audit the change include all changes in release change control process—III

Gambar 26.9 Change Control Proces 3 Auditing


Change Requests SCIs

SQA Plan

SCM Audit ’

Gambar 26.10 SCM Audit Status Akuntansi

Change Change Requests Reports

ECOs

SCIs

Status Accounting

Reporting Gambar 26.11. Status Akuntansi SCM untuk Rekayasa Web 





Konten. o Sebuah WebApp khas berisi array yang luas dari konten-teks, grafik, applet, script, file audio / video, bentuk, elemen halaman aktif, tabel, data streaming, dan banyak lainnya. o Tantangannya adalah untuk mengatur lautan konten ke dalam satu set rasional konfigurasi objek (Bagian 27.1.4) dan kemudian membangun mekanisme kontrol konfigurasi yang sesuai untuk objek-objek. Orang. o Karena persentase yang signifikan dari pembangunan WebApp terus dilakukan secara ad hoc, setiap orang yang terlibat dalam webapp dapat (dan sering) membuat konten. Skalabilitas.




o Sebagai ukuran dan kompleksitas tumbuh, perubahan kecil dapat jauh memiliki dan tidak diinginkan permasalahan yang mempengaruhi. Oleh karena itu, ketegasan dari mekanisme kontrol konfigurasi harus berbanding lurus dengan skala aplikasi. Politik. o Siapa yang 'memiliki' webapp a? o Siapa yang bertanggung jawab untuk keakuratan informasi pada situs Web? o Siapa yang menjamin bahwa proses kontrol kualitas telah diikuti sebelum informasi dipublikasikan ke situs? o Siapa yang bertanggung jawab untuk membuat perubahan? o Siapa yang mengasumsikan biaya perubahan?

Content Management 







Koleksi subsistem meliputi semua tindakan yang diperlukan untuk membuat dan / atau memperoleh konten, dan fungsi-fungsi teknis yang diperlukan untuk o mengubah konten menjadi bentuk yang dapat diwakili oleh bahasa mark-up (misalnya, HTML, XML o mengatur konten ke dalam paket yang dapat ditampilkan secara efektif di sisi klien. Manajemen subsistem menerapkan repositori yang meliputi unsur-unsur berikut: o Konten Database - struktur informasi yang telah ditetapkan untuk menyimpan semua objek konten o Kemampuan Database - fungsi yang memungkinkan CMS untuk mencari objekobjek konten tertentu (atau kategori objek), menyimpan dan mengambil objek, dan mengelola struktur file yang telah ditetapkan untuk konten o Konfigurasi fungsi manajemen - elemen fungsional dan alur kerja terkait yang mendukung identifikasi objek konten, kontrol versi, manajemen perubahan, perubahan audit, dan pelaporan. Penerbitan ekstrak subsistem dari repositori, mengkonversi ke bentuk untuk publikasi yang disetujui, dan format itu sehingga dapat ditularkan ke sisi klien browser. Penerbitan subsistem menyelesaikan tugas-tugas menggunakan serangkaian template. Setiap template adalah fungsi yang membangun sebuah publikasi menggunakan salah satu dari tiga komponen yang berbeda [BOI02]: o Static elements - teks, grafik, media, dan skrip yang tidak memerlukan proses lebih lanjut ditransmisikan langsung ke sisi klien o Publication services - fungsi untuk pengambilan tertentu dan layanan format yang mempersonalisasi konten (menggunakan aturan yang telah ditetapkan), melakukan konversi data, dan membangun link navigasi yang tepat. o External Services - akses ke infrastruktur informasi perusahaan eksternal seperti data perusahaan atau "back-room" aplikasi.


conf igurat ion object s

dat abase

Cont ent Management Syst em

t emplat es HTML code + script s

client -side browser

server-side

Gambar 26.12. Content Management Change Management untuk Aplikasi Web

classify t he request ed change

class 4 change

class 1 change

class 3 change

class 2 change acquire relat ed object s assess impact of change

dev elop brief writ t en descript ion of change

t ransmit t o all t eam members for rev iew

dev elop brief writ t en descript ion of change

t ransmit t o all st akeholders for rev iew

changes required in relat ed object s furt her ev aluat ion is required

OK t o make

furt her ev aluat ion is required

OK t o make

Gambar 26.13. Change Management untuk Aplikasi Web


check out object ( s) t o be changed

make changes design, const ruct , t est

check in object ( s) t hat were changed

publish t o WebA pp

Gambar 26.14 Change Management untuk Aplikasi Web 2


Bab 27 Perancangan Model User Interface

Tujuan Pembelajaran Umum Mengimplementasikan Desain Aplikasi Perangkat Lunak Tujuan Pembelajaran Khusus Mampu membuat rancangan desain model user interface Topik yang akan dibahas antara lain :       

User interface pedoman dialog (dialogs guidences) Tanggapan (feedback) Membantu (help) dialog E-commerce Data mining ergonomi

User Interface User interface adalah sistem yang membantu pengguna berkomunikasi dengan sistem komputer dan / atau sistem aplikasi Tujuan User Interface Design  Untuk merancang antarmuka pengguna yang lebih baik, dengan tujuan sebagai berikut:  Cocokkan antarmuka pengguna untuk tugas itu.  Membuat user interface yang efisien.  Memberikan umpan balik yang tepat untuk pengguna.  Menghasilkan query digunakan.  Meningkatkan produktivitas pekerja pengetahuan. Komponen User Interface  User interface memiliki dua komponen utama:  Bahasa presentasi, yang merupakan komputer-ke-manusia bagian dari transaksi.  Aksi bahasa yang mencirikan bagian manusia-ke-komputer. Tipe-tipe User Interface  Natural-language interfaces.  Question-and-answer interfaces.


   

A menu interface. Form-fill interfaces. Command-language interfaces. Graphical User Interfaces (GUIs).

Natural Language Interface Interface Natural-language memungkinkan sehari-hari atau "alami" bahasa mereka.

pengguna

untuk

berinteraksi dengan komputer

Pertanyaan dan Jawaban mengenai interface  Komputer menampilkan pertanyaan untuk pengguna pada layar.?  Pengguna memasukkan jawaban melalui keyboard atau klik mouse.?  Komputer bertindak atas informasi masukan secara terprogram. ?  Pengguna baru mungkin menemukan antarmuka tanya-jawaban yang paling nyaman.? Menu Interface  Sebuah Menu Antar Muka (a Menu Interface), yang menyediakan pengguna dengan daftar layar pilihan yang tersedia.  Sebuah Menu Bersarang (a Menu Nested) adalah menu yang dapat dicapai melalui menu lain. Kelebihan Menu Nested Keuntungan dari menu bersarang adalah:  Layar kurang berantakan.  Menghilangkan pilihan menu yang tidak menarik bagi pengguna.  Memungkinkan pengguna untuk bergerak cepat melalui program ini. Menu GUI Pedoman Menu GUI  Menu utama selalu di layar.  Menu utama menggunakan kata-kata tunggal.  Menu utama harus memiliki menu sekunder dikelompokkan menjadi fitur serupa.  Menu Drop / Sekunder -sering terdiri dari lebih dari satu kata.  Pilihan menu Sekunder melakukan tindakan atau menampilkan opsi menu tambahan.  Item menu berwarna abu-abu menandakan tidak tersedianya untuk layanan saat ini. Interface Formulir isian • Form bentuk interface isian adalah bentuk layar menampilkan field yang berisi item data atau parameter yang perlu dikomunikasikan kepada pengguna. • Form bentuk Interface isian - isi dapat diimplementasikan menggunakan Web. Kelebihan dan kekurangan Formulir pada Web  Keuntungan menggunakan bentuk berbasis web: o Pengguna memasukkan data. o Data dapat dimasukkan 24 jam sehari, secara global.




Kekurangan dari bentuk berbasis web: o Pengguna yang berpengalaman dapat menjadi tidak sabar dengan bentuk input / output.

Interface Perintah Bahasa (command language interface)  Memungkinkan pengguna untuk mengontrol aplikasi dengan serangkaian penekanan tombol, perintah, frasa, atau beberapa urutan ini.  Perlu menghafal aturan sintaks.  Mungkin menjadi kendala bagi pengguna berpengalaman. GUI   

Memungkinkan manipulasi langsung dari representasi grafis pada layar. Dapat dicapai dengan input keyboard, joystick, atau mouse. Membutuhkan lebih dari kecanggihan sistem antarmuka lainnya.

Voice Speech Recognition  Suara atau pidato sistem pengenalan berkembang pesat  Ada dua jenis pengenalan suara: o Sistem pidato terus menerus, memungkinkan untuk dikte. o Speaker kemerdekaan, sehingga orang dapat memasukkan perintah atau kata-kata pada workstation tertentu. Evaluasi User Interface Kelima standar yang berguna dalam mengevaluasi interface adalah: 1. Periode pelatihan bagi pengguna harus diterima pendek. 2. Pelatihan pengguna awal mereka harus bisa memasukkan perintah tanpa berpikir tentang mereka, atau mengacu pada menu bantuan atau manual. 3. Antarmuka harus mulus sehingga kesalahan sedikit, dan mereka yang terjadi tidak terjadi karena desain miskin. 4. Waktu yang diperlukan untuk pengguna dan sistem untuk bangkit kembali dari kesalahan harus pendek. 5. Jarang pengguna harus dapat mempelajari kembali sistem dengan cepat. Dialog  Dialog adalah komunikasi antara seseorang dan komputer  Tiga poin penting yang harus diperhatikan adalah: o Komunikasi yang berarti. o Tindakan pengguna minimal. o Standar operasi dan konsistensi Komunikasi  Komunikasi berarti bahwa pengguna memahami informasi yang sedang disajikan  Pengguna dengan keterampilan kurang memerlukan sejumlah besar komunikasi  Menyediakan mudah digunakan dengan layar bantuan  Seringkali ini berisi hyperlink ke topik bantuan terkait lainnya


Minimal user inteaksi Minimal Tindakan pengguna dicapai dengan:  Memasukkan kode bukan arti kode.  Masukkan hanya data yang tidak disimpan pada file.  Tidak mengharuskan pengguna untuk memasukkan karakter editing.  Menyediakan nilai default pada layar entri.  Memberikan penyelidikan, mengubah, atau menghapus program dengan kolom entri singkat.  Memberikan penekanan menggunakan tombol untuk memilih pilihan menu yang biasanya dipilih menggunakan mouse  Memilih kode dari menu pull-down pada layar GUI Standar Pengoperasian Standar Operasi dicapai dengan:  Menjaga header dan footer informasi di lokasi yang sama untuk semua layar.  Menggunakan penekanan tombol yang sama untuk keluar program.  Menggunakan keystroke yang sama untuk membatalkan transaksi.  Menggunakan kunci standar untuk memperoleh bantuan.  Menggunakan standar ikon saat menggunakan layar antarmuka pengguna grafis.  Konsistensi penggunaan istilah dalam satu layar atau situs Web.  Menyediakan cara yang konsisten untuk menavigasi melalui dialog.  Konsisten Keselarasan - font, ukuran, dan warna pada halaman Web. Tab Control Dialog Boxes  Tab Kontrol dialog boxes adalah tab adalah fitur desain GUI.  Mereka seharusnya secara logis dikelompokkan fungsi pada setiap tab.  Setiap kotak dialog tab harus OK, Batal atau Apply, dan mungkin tombol Bantuan. Feedback  Semua sistem memerlukan umpan balik untuk memantau dan mengubah perilaku dengan:  Membandingkan perilaku saat ini dengan tujuan yang telah ditentukan.  Memberikan kembali informasi yang menggambarkan kesenjangan antara kinerja aktual dan dimaksudkan Tipe-tipe umpan balik (feedback)  Komputer telah menerima input.  Input dalam bentuk yang benar.  Input tidak dalam bentuk yang benar.  Akan ada keterlambatan dalam pemrosesan.  Permintaan telah selesai.  Komputer tidak dapat menyelesaikan permintaan.  Umpan balik lebih rinci tersedia. Program Help  Menekan tombol fungsi, seperti F1.


     

Sebuah GUI menu pull-down. Konteks-sensitif bantuan, khusus untuk operasi sedang dilakukan. Bantuan Iconic, diperoleh ketika kursor yang tersisa ikon selama beberapa detik. Wizards, yang menyediakan serangkaian pertanyaan dan jawaban ketika mencoba untuk melakukan operasi Nomor Telepon : bantuan yang disediakan oleh pembuat perangkat lunak Software pada forum nasional papan buletin lebar

Dialog eCommerce  Pertimbangan tambahan diperlukan ketika mengembangkan situs web e-commerce.  Umpan balik harus diminta dari pelanggan, menggunakan salah satu dari dua metode: o Peluncuran program email pengguna. o Membuat template umpan balik kosong dengan tombol kirim berlabel "umpan balik". Navigasi intuitif untuk e commerce harus dirancang untuk:  Membuat menu rollover.  Membangun kumpulan link hirarkis.  Menempatkan peta situs di halaman home dan menekankan link dari setiap halaman di situs.  Menempatkan sebuah bar navigasi pada setiap halaman dalam yang mengulangi kategori yang digunakan pada layar entri. Tipe-tipe Query Keenam jenis query:  Mendapatkan data tertentu untuk entitas tertentu.  Menemukan sekelompok entitas yang memiliki karakteristik tertentu.  Cari atribut untuk entitas untuk karakteristik tertentu.  Menampilkan semua atribut untuk entitas tertentu.  Cari semua entitas dengan karakteristik tertentu.  Daftar atribut untuk semua entitas untuk karakteristik tertentu. Entitas, Atribut, Value


Gambar 27.1. : entitas, atribut, value Notasi Query V is value, E is entity, A is attributes, variables in parentheses are given: •

Query type 1: V <--- (E,A)

•

Query type 2: E <--- (V,A)

•

Query type 3: A <--- (V,E)

•

Query type 4: V <--- (E, all A)

•

Query type 5: E <--- (V, all A)

•

Query type 6: A <--- (V, all E)

Metode mengimplementasi Query 

Ada dua metode untuk melaksanakan query database:  Query by Example (QBE), yang memungkinkan pengguna untuk memilih bidang dan menetapkan kondisi menggunakan grid.  Structured Query Language (SQL), yang menggunakan serangkaian kata kunci dan perintah untuk memilih baris dan kolom yang harus ditampilkan.

Contoh SQL


Gambar 27.2. Contoh SQL Parameter Query Sebuah parameter query memungkinkan pengguna untuk memasukkan nilai untuk memilih catatan tanpa mengubah sintaks query. Web Search  

Pencarian web menggunakan mesin pencari untuk menjawab query. Pedoman untuk mencari di Web adalah: o Memutuskan apakah akan mencari atau surfing web. o Pikirkan istilah kunci sebelum mencari. o Buatlah pertanyaan pencarian logis, dengan memperhatikan penggunaan AND dan OR logika pencarian. o Gunakan mesin metasearch yang menyimpan pencarian Anda o Gunakan mesin pencari yang memberitahu Anda tentang perubahan dalam situs web yang Anda pilih o Carilah mesin pencari baru secara berkala

Data Mining Data mining adalah mengumpulkan sejumlah besar informasi tentang seseorang dan kebiasaan mereka dan menggunakan informasi tersebut sebagai prediktor perilaku masa depan.


Ini harus hati-hati dan etis digunakan untuk menghindari melanggar privasi individu.

Gambar 27.3. Data Mining


Bab 28 Perancangan Model Input

Tujuan Pembelajaran Umum Mengimplementasikan Desain Aplikasi Perangkat Lunak Tujuan Pembelajaran Khusus Mampu membuat rancangan desain model user interface Topik yang akan dibahas : • • • • • •

Desain Input (Input design) Desain formulir (Form design) Desain Tampilan (Display design) Desain Layar Graphical User Interface (GUI screen design) Pengontrolan GUI (GUI controls) Petunjuk-petunjuk mendesain web (Web design guidelines)

Tujuan merancang input :  Kualitas sistem input menentukan kualitas output sistem.  Dirancang dengan tujuan masukan yang baik: o Efektivitas. o Akurasi. o Kemudahan penggunaan. o Konsistensi. o Kesederhanaan. o Daya tarik. Desain formulir  Pedoman untuk desain bentuk yang baik: o Membuat bentuk mudah untuk mengisi. o Pastikan bahwa bentuk memenuhi tujuan yang dirancang mereka. o Desain bentuk untuk menjamin penyelesaian yang akurat. o Lakukan bentuk menarik. Penyelesaian formulir  Untuk membuat bentuk-bentuk yang mudah untuk diisi, beberapa teknik berikut digunakan : o Pertama, desain bentuk dengan aliran yang tepat, dari kiri ke kanan dan atas ke bawah. o Kedua, informasi grup logis menggunakan tujuh bagian dari formulir. o Ketiga, menyediakan orang-orang dengan keterangan yang jelas.


o Keterangan memberitahu orang yang mengisi formulir apa yang akan dimasukkan pada baris kosong, ruang, atau kotak.

Tujuh       

bagian formulir antara lain : Kepala Surat (Heading). Identifikasi dan akses (identification and access). Instruksi (instruction). Tubuh (body). Tanda tangan dan verifikasi (signature and verification). Total (totally). Komentar. (comment)

Contoh : 7 bagian formulir

Gambar : 28.1. 7 Bagian Formulir Sumber : Kendall Keterangan :  Keterangan mungkin salah satu hal berikut: o Baris keterangan (line caption), menempatkan judul pada baris yang sama atau di bawah garis. o Keterangan box (boxed caption), menyediakan kotak untuk data bukan saluran. o Vertikal cek , berbaris pilihan atau alternatif secara vertikal. o Horizontal cek, berbaris pilihan atau alternatif horizontal. Contoh : Tipe Caption


Gambar 28.2. Tipe-tipe Caption Memenuhi Tujuan Dimaksudkan  Analis sistem dapat menggunakan berbagai jenis bentuk khusus untuk tujuan yang berbeda.  Bentuk khusus juga bisa berarti bentuk disiapkan oleh stasioner. Memastikan Penyelesaian Akurat  Untuk mengurangi tingkat kesalahan yang terkait dengan pengumpulan data, bentuk harus dirancang untuk menjamin penyelesaian yang akurat.  Desain objek untuk membuat orang melakukan hal yang benar dengan formulir.  Untuk mendorong orang untuk mengisi formulir, analis sistem harus menjaga bentuk yang menarik. Formulir yang menarik  Agar lebih menarik, bentuk akan terlihat rapi, dan memperoleh informasi dalam urutan yang diharapkan.  Bentuk estetika atau penggunaan font yang berbeda dan ketebalan garis dalam bentuk yang sama dapat membantu membuatnya lebih menarik Desain Formulir Perangkat Lunak Komputer  Banyak software desain bentuk mikro tersedia.  Fitur perangkat lunak desain bentuk elektronik:  Kemampuan untuk merancang kertas, formulir elektronik, atau berbasis Web.


 Formulir desain menggunakan template.  Formulir desain dengan memotong dan menyisipkan bentuk akrab dan objek 

Fitur dari desain perangkat lunak bentuk elektronik o Memfasilitasi penyelesaian melalui penggunaan perangkat lunak. o Penentuan menu yang disesuaikan, toolbar, keyboard, dan macro. o Mendukung database populer. o Memungkinkan penyiaran bentuk elektronik. o Penentuan routing dengan form berurutan. o Bentuk assist pelacakan. o Mendorong pengiriman dan pengelolaan otomatis. o Menetapkan keamanan dalam bentuk elektronik.

Mengontrol Formulir Bisnis o Memastikan bahwa setiap bentuk yang digunakan memenuhi tujuan tertentu. o Memastikan bahwa tujuan yang ditetapkan merupakan bagian integral dari fungsi organisasi. o Mencegah duplikasi informasi yang dikumpulkan dan formulir yang mengumpulkan itu. o Merancang bentuk efektif. o Menentukan mereproduksi bentuk dengan cara paling ekonomis o Membangun stok kontrol dan prosedur persediaan yang membuat formulir yang tersedia bila diperlukan, dengan biaya serendah mungkin Display Design Guide o Pertama, menjaga tampilan sederhana. o Kedua, menjaga tampilan presentasi yang konsisten. o Ketiga, memfasilitasi pergerakan pengguna di antara layar tampilan. o Akhirnya, membuat tampilan yang menarik. Tiga bagian layar : Untuk menjaga layar sederhana, itu dibagi menjadi tiga bagian: o Kepala Surat (Heading) . o Tubuh (body). o Komentar dan instruksi (comment and instruction). Desain Display konsep simpel adalah : o Menampilkan beberapa perintah dasar yang diperlukan dengan menggunakan windows atau hyperlink adalah cara lain untuk menjaga kesederhanaan layar. o Untuk pengguna sesekali, hanya 50 persen dari layar harus berisi informasi yang berguna. o Desain sederhana termasuk memaksimalkan atau meminimalkan ukuran jendela yang diperlukan. o Menggunakan bantuan konteks-sensitif dan menu pop-up lainnya. o Konsistensi dicapai dengan menampilkan informasi di area yang sama atau dengan mengelompokkan informasi secara logis.


Memfasilitasi Gerakan o Pedoman untuk memfasilitasi perpindahan dari satu halaman ke halaman lain: o Mengklik - aturan tiga klik mengatakan bahwa pengguna harus bisa sampai ke layar yang mereka butuhkan dalam waktu tiga klik mouse atau keyboard. o Scrolling - menggunakan panah atau tombol PgDn. o Menggunakan konteks-sensitif jendela pop-up). o Menggunakan dialog layar. Desain Layar Menarik o Untuk membuat penggunaan layar tertarik terhadap desain layar tampilan kita : o Ketebalan yang berbeda dari garis pemisahan antara subkategori. o Video Inverse dan kursor berkedip. o Kombinasi yang berbeda warna. o Jenis font yang berbeda. Penggunaan Icons Screen Desain o Ikon yang digunakan dalam layar grafis untuk menjalankan program dan menjalankan perintah. o Graphical User Interface (GUI) yang digunakan dalam hubungannya dengan peralatanperalatan computer seperti : mouse, keyboard, lightpen, atau joystick untuk membuat pilihan dan memasukkan data. GUI kontrol atau fields • Kotak teks (Text boxes). • Kotak Periksa (Check boxes). • Option atau tombol radio (Option or radio buttons). • Daftar dan kotak daftar drop-down (list and drop-down list boxes). • Slider dan tombol spin (Sliders and spin buttons). • Gambar PEta (Image maps). • Area Teks (Text area). • Kotak pesan (Message boxes). : Contoh : GUI


Gambar 28.3. GUI Control •

Kotak teks (Text boxes). o o o o

•

Kotak teks harus cukup besar untuk menampung semua karakter field . Keterangan harus di sebelah kiri kotak teks. Data karakter harus dibiarkan selaras dalam kotak. Data Numeric kanan sejajar.

Kotak Periksa (Check boxes). o Kotak centang (check box) yang digunakan untuk pilihan eksklusif. o kotak centang teks atau label ditempatkan di sebelah kanan kotak centang. o Jika ada lebih dari 10 kotak centang, kelompok dalam pembatas kotak.

•

Option atau tombol radio (Option or radio buttons). o Tombol pilihan atau tombol radio yang digunakan untuk pilihan eksklusif. o Seringkali mereka ditempatkan dalam sebuah persegi panjang yang disebut kelompok pilihan.


o Daftar dan drop-down list box digunakan untuk memilih salah satu pilihan dari banyak pemilih. •

•

Daftar dan kotak daftar drop-down (list and drop-down list boxes). o Slider, tombol spin, dan Gambar Maps o Slider dan tombol berputar digunakan untuk mengubah data yang memiliki berbagai berkesinambungan nilai. o Peta gambar digunakan untuk memilih nilai-nilai dalam sebuah gambar. o X dan y koordinat dikirim ke program. Slider dan tombol spin (Sliders and spin buttons). Contoh :

Gambar 28.4. Slider dan Tombol Spin •

Area Teks (Text area). o Sebuah area teks digunakan untuk memasukkan jumlah yang lebih besar dari teks. o Daerah ini mungkin memiliki teks yang dikemas ketika teks mencapai akhir kotak. o Ada dua cara untuk menangani teks: • Kembali memaksa digunakan untuk memaksa baris baru. • Gunakan box kata dalam area teks.

•

Kotak pesan (Message boxes).


o Message box yang digunakan untuk menampilkan peringatan dan pesan lain dalam jendela persegi panjang. o Tombol Caption dogunakan untuk melakukan tindakan.

Tab Control Dialog Book o Kontrol kotak dialog tab membantu mengatur fitur GUI (kontrol) bagi pengguna. o Setiap kotak dialog tab harus memiliki tiga tombol dasar:  OK. (oc)  Batal. (cancel)  Bantuan. (help) Dialog Box pada Situs Web o Sebuah jenis baru dari kotak dialog memiliki tampilan dan nuansa halaman Web. o Tombol ini disebut tempat dan hyperlink ke item pengguna akan ingin mengakses. Pewarnaan Kelima foreground / latar belakang kombinasi warna yang paling mudah dibaca untuk layar monitor adalah: o Hitam pada kuning. o Kuning di putih. o Biru putih. o Putih pada biru. o Kuning pada hitam. Skins Skins adalah lapisan grafis yang memungkinkan pelanggan untuk mengubah tampilan situs web tergantung pada preferensi mereka untuk jenis tertentu dari gambar. Pedoman untuk membuat intranet dan halaman input Internet: o Memberikan petunjuk yang jelas. o Gunakan urutan entri logis untuk mengisi isian formulir. o Gunakan berbagai text box, push buttons, radio button, list drop-down, dan fitur GUI lainnya. o Menyediakan scrolling text box jika Anda tidak yakin berapa banyak teks yang akan dimasukkan. o Sertakan dua tombol dasar : Kirim (Submit) dan Bersihkan layar (Clear). o Jika bentuk yang panjang, membaginya ke dalam beberapa bentuk yang lebih sederhana pada halaman terpisah. o Buat layar umpan balik (feed back) yang berisi daftar pesan kesalahan jika formulir belum benar setelah diisi Aplikasi e-Commerce o Aplikasi e-commerce melibatkan lebih dari desain situs web yang baik. o Pelanggan harus percaya diri dari situs, termasuk privasi dan keamanan.


Bab 29 Perancangan Model Database

Tujuan Pembelajaran Umum Mengimplementasikan Desain Aplikasi Perangkat Lunak Tujuan Pembelajaran Khusus Mampu membuat rancangan desain model Database Topik yang akan dibahas :       

Files Basis Data (Databases) Normalization Desain Kunci (Key design) Using the database Data warehouses Data mining

Tujuan dalam desain organisasi penyimpanan data adalah:      

Data harus tersedia ketika pengguna ingin menggunakannya. Data harus memiliki integritas. Ini harus akurat dan konsisten. Penyimpanan data yang efisien serta memperbarui efisien dan pengambilan Pencarian informasi menjadi tujuan. Informasi yang diperoleh dari data yang disimpan harus dalam bentuk terpadu berguna untuk: o o o o

Mengelola. Perencanaan. Mengontrol. Pengambilan keputusan..

Pendekatan dalam penyimpanan data dalam system computer : Ada dua pendekatan untuk penyimpanan data dalam sistem komputer:  Menyimpan data dalam file individual masing-masing yang unik untuk aplikasi tertentu.  Penyimpanan data dalam sebuah sistem berbasis komputer melibatkan membangun database.


o Database adalah sesuatu yang formal didefinisikan dan dikendalikan secara terpusat dari data yang dimaksudkan untuk digunakan dalam berbagai aplikasi. Files  

Sebuah file dapat dirancang dan dibangun cukup cepat, dan kekhawatiran untuk ketersediaan data dan keamanan dapat diminimalkan. Analis dapat memilih struktur file yang tepat sesuai dengan kecepatan pemrosesan yang diperlukan dari sistem aplikasi tertentu.

Tujuan efektivitas database meliputi:  Memastikan bahwa data dapat dibagi di antara pengguna untuk berbagai aplikasi.  Pemeliharaan data yang akurat dan konsisten.  Memastikan semua data yang diperlukan untuk aplikasi saat ini dan masa mendatang akan tersedia.  Membiarkan database untuk berkembang dan kebutuhan pengguna tumbuh.  Memungkinkan pengguna untuk membangun pandangan pribadi mereka dari data tanpa memperhatikan cara data disimpan secara fisik. Metadata  Metadata adalah informasi yang menggambarkan data dalam file atau database.  Digunakan untuk membantu pengguna memahami bentuk dan struktur data Realita, Data dan Metadata

Gambar 29.1. Reality, Data dan Metadata Konsep Realitas Entitas 

Entitas adalah objek atau peristiwa yang datanya dikumpulkan dan disimpan.


 

Sebuah subtipe entitas merupakan data tentang suatu entitas yang tidak dapat ditemukan di setiap record Hubungan adalah asosiasi antara entitas.

Entitas Sebuah koleksi yang berbeda dari data untuk satu orang, tempat, benda, atau peristiwa.

Customer Gambar 29.2. Entitas Pelanggan Sub tipe entitas 

 

Sebuah subtipe entitas adalah khusus satu-ke-satu hubungan yang digunakan untuk mewakili atribut tambahan, yang mungkin tidak hadir pada setiap catatan dari entitas pertama. Ini menghilangkan fields null pada database utama. Sebagai contoh, sebuah perusahaan yang memiliki pelanggan disukai, atau magang mahasiswa mungkin memiliki bidang khusus.

Associative Entity Associative Entity - menghubungkan dua entitas Sebuah entitas asosiatif hanya dapat terjadi antara dua entitas

Order Item Gambar 29.3. Associative Entity


Atrributive Entity Entitas atributif - menggambarkan atribut, terutama unsur-unsur pengulangan.

Book Subject Gambar 29.4. Attributive Entity

ERD Symbols

Gambar 29.5. : Simbol-simbol ERD


Relationship o Hubungan mungkin: o Satu-ke-satu (one to one). o Satu-ke-banyak (one to many). o Banyak-ke-banyak (many to many). o Sebuah garis vertikal tunggal (vertical line) merupakan salah satu . o Sebuah lingkaran (circle) mewakili nol atau tidak ada. o Sebuah kaki gagak (crows foot) mewakili banyak.

Many

One

Many

NoneO

Gambar 29.6. Relationship Self Join Self Join adalah ketika sebuah record memiliki hubungan dengan catatan lain pada file yang sama. Contoh ERD

Gambar 29.7 : Sample ERD


Attribute - Atribut adalah karakteristik dari suatu entitas, kadang-kadang disebut item data. Record - Rekaman adalah koleksi item data yang memiliki kesamaan. Key - Kunci item data catatan digunakan untuk mengidentifikasi catatan.

Jenis kunci adalah: o Primary Key, unik untuk catatan. o Secondary Key, kunci yang mungkin tidak unik, digunakan untuk memilih sekelompok record. o Concatenated Key, kombinasi dari dua atau lebih item data untuk kunci. o Foreign Key, item data dalam satu record yang merupakan kunci dari catatan lain. Files o Sebuah file berisi kelompok catatan yang digunakan untuk memberikan informasi untuk operasi, perencanaan, manajemen, dan pengambilan keputusan. o File dapat digunakan untuk menyimpan data untuk jangka waktu yang tidak terbatas, atau mereka dapat digunakan untuk menyimpan data sementara untuk tujuan tertentu. Tipe File o Jenis file yang tersedia adalah: o Master File. o Transaction File. o Work File . o Report File. Master File o Memiliki catatan besar o Mengandung semua informasi yang bersangkutan mengenai suatu entitas Transaction File o Adalah catatan singkat o Berisi informasi yang digunakan untuk memperbarui file induk File Organisasi Struktur organisasi yang berbeda untuk desain berkas adalah: o Organisasi Sequential. o Linked lists o Hashed file organization. Desain Database Logical dan Fisik


Gambar 29.8. Desain logical dan fisik database Normalisasi Normalisasi adalah transformasi pandangan pengguna yang kompleks dan data untuk satu set yang lebih kecil, stabil, dan mudah struktur data dipertahankan.

o o o o

Normalisasi menciptakan data yang disimpan hanya sekali pada file. Pengecualian adalah fields key. Struktur data sederhana dan lebih stabil. Data tersebut lebih mudah dipelihara.

Langkah-langkah dalam menormalisasikan data : Tiga langkah normalisasi data adalah: o Hapus semua kelompok mengulang dan mengidentifikasi kunci utama. o Pastikan bahwa semua atribut nonkey sepenuhnya tergantung pada primary key. o Hapus semua dependensi transitif, atribut yang bergantung pada atribut nonkey lainnya.


Gambar 29.9 Tiga Langkah Normalisasi Data Diagram Data Model o Model diagram data tersebut digunakan untuk menunjukkan hubungan antara atribut. o Oval merupakan atribut. o Sebuah garis panah tunggal merupakan salah satu. o Sebuah garis panah ganda mewakili banyak o

Customer Number Gambar 29.10. Model Diagram Data

Salesperson Number


Contoh Model Data

Gambar 29.11. Model Data First Normal Form (1-NF) o o o o

Hapus semua kelompok mengulangi. Semua kelompok mengulangi dipindahkan ke tabel baru. Foreign key yang digunakan untuk menghubungkan tabel. Ketika relasi tidak mengandung kelompok berulang, itu adalah dalam bentuk normal pertama.

Second Normal Form (2-NF) o o o

Hapus semua dependensi parsial. Ketergantungan parsial adalah ketika data hanya tergantung pada bagian dari bidang kunci. Suatu relasi dibuat untuk data yang hanya tergantung pada bagian dari kunci dan satu lagi untuk data yang tergantung pada kedua bagian.

Third Normal Form (3-NF) o Hapus semua dependensi transitif. o Sebuah dependensi transitif adalah ketika relasi berisi data yang bukan merupakan bagian dari entitas. o Masalah dengan transitif dependensi memperbarui data. o Sebuah item data tunggal dapat hadir pada banyak record.


ERD dan Record Key o o o

Entitas-Relationship -Diagram dapat digunakan untuk menentukan kunci rekaman. Ketika hubungan one to many , primary key dari file pada salah satu ujung relasi harus terkandung sebagai foreign key pada file di ujung banyak dari relasi . Sebuah relasi many to many harus dibagi menjadi dua relasi one to many hubungan dengan entitas asosiatif di tengah.

Pedoman untuk membuat file induk atau relasi database: o Setiap entitas yang terpisah harus memiliki master file itu sendiri atau relasi basis data. o Sebuah spesifik, nonkey data fields harus ada pada satu master file atau relasi. o Setiap master file atau relasi harus memiliki program untuk membuat, membaca, memperbarui, dan menghapus record. Integrity Constrains Ada tiga kendala integritas yang membantu untuk memastikan bahwa database berisi data yang akurat: o Kendala integritas entitas, yang mengatur komposisi primary key. o Integritas referensial, yang mengatur denaturasi record dalam hubungan one to many. o Domain integrity. Entity Integrity Kendala integritas entitas aturan untuk kunci primer: o Primary key tidak dapat memiliki nilai null. o Jika primary key adalah komposit key, tidak ada bidang dalam key dapat berisi nilai nol. Referential Integrity o Integritas referensial mengatur denaturasi catatan dalam hubungan satu-ke-banyak. o Integritas referensial berarti bahwa semua foreign key dalam satu tabel (tabel child) harus memiliki catatan yang cocok di tabel induk.

o Anda tidak dapat menambahkan record tanpa record pencocokan foreign key. o Anda tidak dapat mengubah primary key yang telah pencocokan record tabel anak. o Sebuah tabel child memiliki foreign key untuk record yang berbeda. o Anda tidak dapat menghapus rekor yang memiliki record child. o Sebuah update database terbatas atau menghapus kunci hanya jika tidak ada yang cocok catatan anak. o Sebuah database mengalir akan menghapus atau memperbarui semua catatan anak o ketika catatan induk dihapus atau o parent pemicu dirubah.


Integritas Domain  Integritas Domain mendefinisikan aturan yang memastikan bahwa hanya data yang valid yang disimpan pada catatan database  Domain integritas memiliki dua bentuk:  Periksa kendala-kendala, yang didefinisikan di tingkat tabel.  Aturan, yang didefinisikan sebagai obyek yang terpisah dan dapat digunakan dalam field angka. Mengambil dan Menyajikan Database Data Pedoman untuk mengambil dan menyajikan data adalah:  Pilih relasi dari database.  Join dua relasi bersama-sama.  Kolom-kolom proyek dari relasi.  Pilih baris dari relasi.  Turunkan atribut baru.  Indeks atau mengurutkan baris.  Hitung total dan ukuran kinerja.  Menyajikan data. Denormalization adalah proses mengambil model data logis dan mengubahnya menjadi model fisik yang efisien Data warehouse digunakan untuk mengatur informasi untuk permintaan cepat dan query efektif Perbedaan database dan data warehous  Dalam data warehouse, data yang diorganisir disekitar subjek utama.  Data dalam warehouse yang disimpan sebagai dirangkum lebih daripada data mentah terperinci.  Data di dalam frame data warehouse meliputi waktu yang lebih lama daripada dalam database berorientasi transaksi tradisional.  Data warehouse diorganisir untuk permintaan cepat.  Data warehouse biasanya dioptimalkan untuk menjawab pertanyaan rumit, dikenal sebagai OLAP.  Data warehouse memungkinkan untuk memudahkan akses melalui perangkat lunak data mining yang disebut perangkat lunak.  Data warehouse termasuk beberapa database yang telah diolah sehingga data yang didefinisikan seragam, mengandung apa yang disebut sebagai data "clean".  Data warehouse biasanya berisi data dari sumber luar OLAP (Online Analytic Processing)  Online Analytic Processing (OLAP) dimaksudkan untuk menjawab pertanyaan pengambil keputusan 'kompleks dengan mendefinisikan multidimensi database.  Data mining, atau Knowledge Data Discovery(KDD), adalah proses mengidentifikasi pola bahwa manusia tidak mampu mendeteksi.


Data mining memiliki sejumlah alat bantu keputusan yang tersedia, termasuk:  Analisis statistik.(Statistical Analysis)  Pohon keputusan.(Decision Trees)  Jaringan saraf. (Neural Network)  Cerdas agen.(Intelegent Agent)  Logika fuzzy. (fuzzy logic)  Visualisasi data.(data visualization)

Data Mining Patern yang mencoba pengambil keputusan mengidentifikasi meliputi:  Asosiasi (Associations) , pola yang terjadi bersama-sama.  Urutan (sequences), pola tindakan yang berlangsung selama periode waktu.  Pengelompokan (clustering), pola yang berkembang di antara kelompok orang.  Tren (trends), pola yang diperhatikan selama periode waktu. Web Database dan XML  Database berbasis web digunakan untuk berbagi data.  Extensible markup language (XML) digunakan untuk mendefinisikan data yang digunakan terutama untuk pertukaran data bisnis melalui Web


Bab 30 Perancangan Model Output

Tujuan Pembelajaran Umum Mengimplementasikan Desain Aplikasi Perangkat Lunak Tujuan Pembelajaran Khusus Mampu membuat rancangan desain model Output Topik yang akan dibahas :   

Output Desain (Designing output) Teknologi keluaran (Output technologies) Faktor-faktor dalam memilih sebuah output teknologi o Desain laporan (Report design) o Desain layar (Screen design) o Desain situs web (Web site design)

Output harus dirancang untuk:      

Melayani tujuan yang telah ditetapkan. Jadilah berarti bagi pengguna. Memberikan jumlah yang tepat dari output. Mengirimkannya ke tempat yang tepat. Memberikan output tepat waktu. Pilih metode output yang benar.

Eksternal dan Internal Output    

Output internal yang akan digunakan dalam korporasi. Output eksternal digunakan di luar organisasi. Output eksternal berbeda dari output internal desain dan penampilan. Sebuah dokumen turnaround adalah salah satu yang akan dikirimkan dan kemudian kembali.


Output can be in the form of:      

Print. Display screen. Audio. CD-ROM or CD-RW. DVD. Electronic output.

Output technologies differ in their:     

Speed. Cost. Portability. Flexibility. Storage and retrieval possibilities.

Klip video yang berguna untuk:      

Melengkapi statis, output cetak. Jarak kolaborasi. Menunjukkan bagaimana untuk melakukan suatu tindakan. Memberikan pelatihan episode singkat. Pergeseran waktu dari suatu peristiwa aktual dengan merekamnya untuk output nantinya. Melestarikan kesempatan penting bagi Selain arsip organisasi.

Animasi Animasi terdiri dari empat elemen:    

Simbol-simbol Elemental. Orientasi spasial. Efek-efek transisi. Efek-efek Perubahan.

Output Elektronik meliputi:   

Fax. Electronic mail (email). World Wide Web.


Teknologi Pull dan Push  

Pull technology memungkinkan pengguna untuk mengambil data diformat dari Web. Push technology mengirimkan diminta atau tidak diminta informasi kepada pelanggan atau klien.

Faktor-faktor yang harus dipertimbangkan ketika memilih teknologi output:           

Siapa yang akan menggunakan output? Berapa banyak orang yang membutuhkan output? Dimana output yang dibutuhkan? Apa tujuan dari output? Berapa kecepatan dengan mana output yang dibutuhkan? Berapa kecepatan dengan mana output yang dibutuhkan? Seberapa sering output diakses? Berapa lama output disimpan? Berdasarkan apa peraturan khusus adalah output yang dihasilkan, disimpan, dan didistribusikan? Berapa biaya awal dan berkelanjutan pemeliharaan dan pasokan? Apa persyaratan lingkungan untuk teknologi output?

Output bias Analis harus menyadari sumber output bias dan menginformasikan pengguna dari kemungkinan bias dalam output. 

Bias diperkenalkan dalam tiga cara utama: o Bagaimana informasi diurutkan. o Setting batas yang dapat diterima. o Pilihan grafis.

Strategi untuk menghindari keluaran bias :    

Kesadaran akan sumber bias. Desain output yang mencakup pengguna. Bekerja dengan pengguna sehingga mereka diberitahu output bias output. Menciptakan output yang fleksibel dan memungkinkan pengguna untuk mengubah batas dan rentang.




Melatih pengguna untuk mengandalkan beberapa output untuk melakukan "tes realitas" pada output sistem.

Pertimbangan Desain laporan   

Informasi konstan tidak berubah ketika laporan sudah dicetak. Informasi variabel berubah setiap kali laporan dicetak. Kualitas kertas, jenis, dan ukuran harus ditentukan

Pencetakan Laporan  

Laporan desain menggunakan software. Pedoman desain untuk laporan dicetak adalah: o Sertakan atribut fungsional, seperti heading, nomor halaman, dan control break. o Memasukkan gaya dan estetis atribut, seperti ekstra ruang kosong dan pengelompokan data.

Desain Tampilan Layar 

Pedoman untuk desain tampilan adalah: o Jauhkan tampilan sederhana. o Jauhkan presentasi tampilan yang konsisten. o Memfasilitasi pergerakan pengguna di antara output yang ditampilkan. o Buat tampilan yang menarik.

Output grafis Pertimbangan utama untuk merancang output grafis: 

Output harus akurat, mudah dipahami dan digunakan.

Analis harus menentukan:    

Tujuan dari grafik. Jenis data yang akan ditampilkan. Audiens. Efek audiens pada berbagai jenis output grafis.


Desain Web Sites Prinsip-prinsip desain harus digunakan ketika merancang situs web.    

Menggunakan alat profesional. Mempelajari situs lain. Menggunakan sumber daya Web. Meneliti situs Web Site Profesional desainer

Prinsip selanjutnya:     

Menggunakan alat-alat yang anda kenal. Buku-buku konsultasi. Meneliti halaman yang dirancang buruk. Membuat template web. Style sheet memungkinkan Anda untuk memformat semua halaman web dalam sebuah situs secara konsisten. Menggunakan plug-in, audio, dan video hemat.

Perhatikan:       

Strukturnya. Konten. Teks. Graphics. Presentasi gaya. Navigasi. Promosi.

Grafik Web Pedoman untuk menggunakan grafis saat merancang situs web adalah:     

Gunakan format JPEG atau GIF. Jauhkan latar belakang sederhana dan mudah dibaca. Buat grafis yang tampak profesional sedikit untuk digunakan pada halaman Anda. Reuse bullet atau tombol navigasi. Periksa situs Web Anda pada berbagai monitor dan resolusi grafis.


Presentasi Style Pedoman untuk masuk menampilkan untuk situs web:       

Memberikan layar entri atau halaman rumah. Menjaga jumlah grafis untuk minimal yang wajar. Menggunakan font besar dan berwarna-warni untuk judul. Gunakan gambar menarik dan tombol untuk link. Gunakan tabel untuk meningkatkan tata letak. Gunakan gambar grafis sama pada beberapa halaman Web. Jangan gunakan terlalu banyak animasi, suara, dan lain-lain "sibuk" elemen.

Navigasi pedoman:   

Gunakan aturan tiga-klik. Promosikan situs Web. Mendorong pengunjung Anda untuk ke bookmark situs Anda.

Produksi Output XML Sebuah dokumen XML dapat diubah menjadi jenis media yang berbeda. Ada dua metode:  

Menggunakan gaya Cascading sheet (CSS). Menggunakan Extensible Style Language Transformations (XSLT).

Cascading Style Sheets   

CSS memungkinkan Anda untuk menentukan keluarga font, warna, ukuran, dan sebagainya. Gaya dapat diatur untuk media yang berbeda, seperti layar, cetak, atau perangkat genggam. Gaya tidak memungkinkan Anda untuk memilih atau memilah elemen XML.

Extensible Style Language Transformations memungkinkan Anda untuk:   

Memilih elemen XML. Sort. Pilih data yang akan output.


Gambar : 30.1. Extensible Style Language Transformations


Bab 31 Analisis dan Desain Orientasi Object menggunakan UML

Tujuan Pembelajaran Umum Mengimplementasikan Desain Aplikasi Perangkat Lunak Tujuan Pembelajaran Khusus Mampu membuat Analisis dan Desain Orientasi Object menggunakan UML

TOPIK YANG AKAN DIBAHAS     

Object-oriented concepts and terminology CRC Cards Unified Modeling Language Use case dan diagram UML lainnya Relationships

Object Oriented Overview  

Object-oriented (oo) teknik bekerja dengan baik dalam situasi di mana sistem rumit sedang menjalani perawatan berkelanjutan, adaptasi, dan desain. Unified Modeling Language (UML) adalah standar industri untuk pemodelan Sistem berorientasi objek

Tujuan Analisis OO  

Reusability adalah tujuan utama. Mempertahankan sistem merupakan tujuan penting. o Membuat perubahan dalam satu objek memiliki dampak minimal pada objek lain.

Konsep OO     

Sebuah object, merupakan hal yang nyata-dunia atau peristiwa. Object mungkin pelanggan, item, perintah dan sebagainya. Object mungkin menampilkan GUI atau area teks pada layar. Object yang diwakili oleh dan dikelompokkan ke dalam class. Sebuah class, atau kelompok object terkait memiliki seperangkat atribut dan perilaku bersama.


  

Instantiate adalah istilah yang digunakan ketika sebuah object dibuat dari sebuah class. Atribut adalah properti dari class yang dimiliki oleh semua object. Methods adalah suatu tindakan yang dapat diminta dari setiap object dalam class.

Gambar 31.1. Simbol Class

Inheritance ketika sebuah class baru dibuat dari class lain.   

Class yang asli adalah parent atau class dasar (base class). Class baru adalah child atau class turunan. Class anak menerima atribut dan metode dari class induk

CRC Cards Class, responsibility , dan collaboration (CRC) kartu yang digunakan untuk mewakili tanggung jawab kelas dan interaksi antara kelas. Analisis membuat kartu CRC Analis membuat kartu CRC oleh: 

Menemukan semua kata benda dan kata kerja dalam sebuah pernyataan masalah.


   

Membuat skenario yang sebenarnya penelusuran dari fungsi sistem. Mengidentifikasi dan memperbaiki tanggung jawab menjadi tugas yang lebih kecil dan lebih kecil, jika memungkinkan. Menentukan bagaimana tugas dipenuhi oleh benda atau berinteraksi dengan hal-hal lain. Mengidentifikasi tanggung jawab yang berkembang menjadi metode atau operasi.

Tiga kategori UML   

Hal, benda-benda. Hubungan, lem yang memegang sesuatu bersama-sama. Diagram, dikategorikan sebagai struktur atau perilaku.

Ada dua kelompok umum hal dalam UML:  

Hal struktural yang menentukan struktur konseptual dan fisik dari suatu sistem OO dan dijelaskan oleh kata benda. Hal perilaku, kata kerja sebuah model UML yang merepresentasikan perilaku sistem dan negara dari sistem sebelum, selama, dan setelah perilaku terjadi.

Structural things include   

Class. Use Case . Interfaces.

Behavioral things include:  

Interactions. State machines.

Tipe Relationship Ada dua jenis hubungan yang memegang sesuatu bersama-sama:  

Hubungan struktural mengikat sesuatu bersama-sama dalam diagram struktural. Hubungan Perilaku digunakan dalam diagram perilaku.


Structural relationships are:    

Dependencies. Aggregations. Associations. Generalizations.

Behavioral relationships are:    

Communicates. Includes. Extends. Generalizes.

Hal struktur (structural things) yang paling umum dan mencakup:    

Class and object diagrams. Use case diagrams. Component diagrams. Deployment diagrams.

Hal perilaku (Behavioral things) mencakup:     

Use case diagrams. Sequence diagrams. Collaboration diagrams. Statechart diagrams. Activity diagrams.

Yang paling umum digunakan diagram UML adalah:    

Use case diagram, menggambarkan bagaimana sistem yang digunakan. o Titik awal dengan menggunakan pemodelan UML. Use Case (bukan diagram). Activity diagram. o Setiap use case dapat membuat satu activity diagram . Sequence diagram, menampilkan unrutan aktifitas dan hubungan-hubungan class. o Setiap use case boleh membuat satu atau lebih sequence diagrams.


o Sebuah Collaboration diagram adalah merupakan alternative untuk menggunakan sebuah sequence diagram. 

Class Diagram, menunjukkan class dan relation. 



Sequences Diagram dan kartu CRC yang digunakan untuk menentukan Class .

Statechart Diagram. o Setiap class dapat membuat diagram statechart, berguna untuk menentukan metode class.

Gambaran Diagram UML

Gambar 31.2. Diagram UML


Use Case Diagram  

Sebuah Use (Yoos) Case menggambarkan apa sistem tidak, tidak bagaimana melakukan pekerjaan. Penggunaan use case mencerminkan pandangan dari sistem pengguna di luar sistem.

Simbol adalah:   

Aktor, sebuah tongkat. Use Case, oval. Ralationship garis.

Actor        

Merupakan yang memainkan peran oleh satu atau lebih pengguna Ada di luar sistem Mungkin seseorang, sistem lain, perangkat seperti keyboard atau koneksi Web Dapat memulai sebuah contoh kasus penggunaan Dapat berinteraksi dengan satu atau lebih kasus penggunaan dan kasus penggunaan mungkin melibatkan satu atau lebih pelaku Aktor dapat dibagi menjadi dua kelompok: Aktor utama memberikan data atau menerima informasi dari sistem Aktor sekunder membantu untuk menjaga system berjalan atau memberikan bantuan o Help desk, analis, programmer, dll

Use Case Terdiri dari tiga hal:       

Seorang aktor (pengguna) yang memulai acara. Suatu peristiwa yang memicu sebuah use case. Use case yang melakukan tindakan dipicu oleh acara tersebut. Lebih baik untuk membuat use case lebih sedikit 20 use case untuk sistem besar 50 use case akan menjadi maksimal untuk sistem besar Dapatkah nest use case , jika diperlukan

Relationship Berkomunikasi (communication)


Hubungkan aktor untuk sebuah use case Termasuk (includes)   

Use case mengandung perilaku yang umum untuk lebih dari satu use case. Use case umum termasuk dalam use case lainnya. Panah menunjuk Dotted terhadap use case umum.

Memperpanjang (Extend)  

Sebuah use case yang berbeda menangani variasi atau pengecualian dari use case dasar. Panah pergi dari diperluas untuk use case dasar.

generalizes  

Satu hal yang lebih umum daripada hal lain. Panah menunjuk ke hal yang umum.

Gambar Use Case

Gambar 31.3. Use Case membuat Use Case


Langkah-langkah yang diperlukan untuk membuat model use case adalah:    

Review spesifikasi bisnis dan mengidentifikasi pelaku dalam masalah domain. Mengidentifikasi peristiwa tingkat tinggi dan mengembangkan use case utama yang menggambarkan peristiwa dan bagaimana aktor menginisiasi mereka Meninjau setiap use case utama untuk menentukan kemungkinan variasi mengalir melalui use case. Mengembangkan dokumen kasus digunakan untuk semua use case primer dan semua skenario penting use case.

Scenario Use Case   

Skenario use case dapat dibuat untuk aliran standar melalui use case. Skenario lain dapat dibuat untuk variasi pada arus utama. Sebuah use case meliputi:  Gunakan pengidentifikasi kasus dan inisiator.  Langkah yang dilakukan.  Kondisi, asumsi, dan pertanyaan

Activity Diagram   

Activity diagram menunjukkan urutan kegiatan dalam proses, termasuk kegiatan sekuensial dan paralel. Simbol yang digunakan untuk kegiatan, keputusan dan sebagainya. Panah merupakan peristiwa yang menghubungkan kegiatan.

Simbol Activity Diagram


Gambar 31.4. Activity Diagram membuat Activity Diagram Langkah-langkah yang diperlukan untuk membuat model activity adalah:   

Tanyakan apa yang terjadi pertama, kedua, dan seterusnya. Menentukan apakah kegiatan terjadi secara berurutan atau paralel. Periksa semua skenario untuk use case.

Swimlame Diagram  

Termasuk pada activity diagram untuk menunjukkan partisi Tampilkan yang kegiatan: o Terjadi pada browser o Terjadi pada server o Terjadi pada mainframe


 

Dilakukan oleh mitra eksternal Bantuan membagi tugas di antara anggota tim

Swimlame Boundary    

Ketika suatu peristiwa melintasi swimlane boundary, data harus ditransmisikan. Suatu bentuk web dikirim ke server. Data yang ditempatkan ke dalam middleware untuk mengirimkan antara server dan mainframe. Data yang ditransmisikan ke dan dari mitra eksternal.

Sequence Diagram     

Sequence diagram menunjukkan suksesi interaksi antara class atau contoh objek dari waktu ke waktu. Hal ini juga menunjukkan proses dijelaskan dalam skenario tungga l. Yang paling kiri obyek obyek awal. Urutan waktu adalah dari atas ke bawah. Horisontal Diagram mewakili pesan atau sinyal yang dikirim antara class. o o

Panah padat merupakan panggilan sinkron, kelas pengirim menunggu respons. Panah setengah atau terbuka merupakan panggilan asynchronous, yang dikirim tanpa menunggu sinyal kembali.

Message Name Formats Message names may be in the following formats: messageName() messageName(parameter1, parameter2, …) messageName(parameterType:parameterName)(defaultValue) Contoh :


Gambar 31.5. Sequence Diagram Collaboration Diagrams   

Diagram Kolaborasi menunjukkan informasi yang sama sebagai urutan diagram. Penekanannya adalah pada organisasi objek. Urutan ditunjukkan dengan memasukkan nomor urut pada pesan tersebut.

Contoh :

Gambar 31.6. Collaboration Diagram


Class Diagram  

Diagram kelas menunjukkan class, atribut, dan operasi atau metode. Class A ditampilkan sebagai persegi panjang.

Class Diagram Atribut 



Atribut yang baik: o Private(the norm), ditandai dengan tanda minus. o Public, ditunjukkan dengan tanda plus. o Protected, ditunjukkan dengan tanda pound (#). o Atrributes mungkin termasuk tipe data dan nilai awal. Metode biasanya public.

Method Overloading  

Metode overloading adalah termasuk metode yang sama beberapa kali dalam satu class. Metode signature, nama dan parameter, dan jenis parameter, harus berbeda.

Tipe-tipe Class Kelas terbagi dalam beberapa kategori: 



Kelas entitas.  Batas atau antarmuka kelas.  Kelas abstrak.  Kelas kontrol. Setiap class dapat menggunakan simbol khusus, yang disebut stereotip UML.

Entity Class   

Entitas Class merupakan item dunia nyata. Atribut adalah mereka menyimpan untuk entitas. Metode bekerja dengan entitas.

Boundary or Interface Class   

Menyediakan sarana bagi pengguna untuk bekerja dengan sistem. Layar tampilan, jendela, kotak dialog, telepon nada-sentuh, sistem eksternal. Metode yang diperlukan untuk mengirim atau mengatur ulang tampilan layar, atau untuk memproduksi ulang

Abstract Class   

Kelas abstrak adalah orang tua atau kelas umum dalam suatu hubungan generalisasi / spesialisasi. Kelas abstrak tidak dapat langsung dipakai. Hanya anak kelas dapat membuat objek.


Control Active Class    

Control atau aktif kelas yang digunakan untuk mengontrol aliran kegiatan. Banyak kelas kontrol kecil dapat dimasukkan untuk mencapai penggunaan kembali. Atribut adalah yang dibutuhkan sementara oleh kelas kontrol. Metode yang digunakan dalam kegiatan pengendalian.

Gambar 31.7. Sequence Diagram Example Using Class Stereotype Symbols Relationship pada sebuah Class Diagram 

Hubungan adalah hubungan antara kelas dan meliputi: o Asosiasi, menunjukkan satu-ke-banyak hubungan antara kelas.  Sebuah tanda bintang (*) digunakan untuk mewakili banyak. o Kelas Asosiasi digunakan untuk memecah banyak-ke-banyak hubungan antara kelas.

Contoh :


Gambar 31.8. Association Class Utuh / sebagian relationship  

Satu kelas mewakili seluruh, kelas lainnya merupakan bagian yang terkandung dalam keseluruhan. Tiga jenis seluruh / bagian hubungan: o Aggregation. o Collection. o Composition



Aggregation. o Agregasi adalah "memiliki" hubungan. o Seluruh terdiri dari jumlah bagian-bagian. o Jika keseluruhan dihapus, bagian mungkin masih ada. o Berlian di ujung garis tidak terisi



Collection. o Terdiri dari keseluruhan dan anggotanya o Contohnya adalah sebuah perpustakaan dengan buku-buku atau distrik pemungutan suara dengan pemilih o Jika bagian dihapus, keseluruhan mempertahankan identitas




o Sebuah hubungan sebagai lemah Composition . o Seluruh memiliki tanggung jawab untuk bagian-bagian, dan hubungan yang lebih kuat. o Jika keseluruhan dihapus, bagian-bagian yang dihapus o Tampil dengan diamond diisi-in pada baris o Contoh: polis asuransi dengan pengendara

Generalisasi / spesialisasi atau gen / spek diagram menunjukkan hubungan antara hal yang lebih umum dan jenis tertentu hal.     

Hubungan ini digambarkan sebagai "adalah" hubungan (relationship). Sebagai contoh: mobil adalah kendaraan, truk adalah kendaraan. Hubungan generalisasi digunakan untuk model warisan (inheritance). General Class adalah parent, base atau superclass. Specialized Class adalah anak, berasal, atau subclass

Polymorphism   

Contoh

Polimorfisme atau metode utama adalah ketika sebuah metode didefinisikan dalam beberapa class dalam gen / spek hubungan. Subclass menimpa atribut class induk dan / atau metode. Jika sejumlah kelas yang terlibat, class yang paling spesifik digunakan


Gambar 31.9 Gen/Spec Finding Class Kelas mungkin ditemukan:     

Selama wawancara atau sesi JAD. Selama sesi brainstorming. Dengan menggunakan kartu CRC. Dengan memeriksa kasus penggunaan, mencari kata benda. Setiap benda dapat menyebabkan calon atau kelas potensial.

Menentukan Metode Class Metode kelas dapat ditentukan oleh:    

Menggunakan matriks CRUD. Melihat pesan yang dikirim antara class. Class penerima harus memiliki nama pesan sebagai metode. Menggunakan diagram statechart.


Statecart diagram         

Diagram statechart menunjukkan kelas negara dan peristiwa-peristiwa yang menyebabkan mereka untuk transisi antara negara. Hal ini juga disebut diagram transisi negara Suatu kejadian yang terjadi pada waktu dan tempat tertentu. Mereka menyebabkan perubahan keadaan, atau transisi "kebakaran" Setiap kali suatu objek perubahan state, beberapa atributnya harus berubah. Harus ada sebuah metode untuk mengubah atribut. Seringkali ada tampilan layar atau bentuk web untuk memasukkan atribut. Diagram statechart tidak diciptakan untuk semua kelas. Mereka dibuat ketika: o Class A memiliki siklus hidup yang kompleks. o Sebuah instance dari kelas dapat memperbarui atribut dalam beberapa cara melalui siklus hidup. o Class A memiliki siklus hidup operasional. o Dua class bergantung satu sama lain. o Perilaku objek saat ini tergantung pada apa yang terjadi sebelumnya.

Contoh :

Gambar 31.10 Statechart Diagram Packages o o

Wadah untuk hal-hal lain UML Tampilkan sistem partisi


o o o o

Tunjukkan yang use case atau class dikelompokkan menjadi subsistem Dapat menunjukkan komponen paket Bisa subsistem fisik Gunakan simbol folder

Contoh

Gambar 31.11. Packages

Langkah-langkah yang digunakan dalam UML adalah: o o o o o o

Tentukan model use case. Lanjutkan UML diagram untuk model sistem. selama sistem tahap analisis. Mengembangkan diagram class. Menggambar diagram statechart. Mulai desain sistem dengan memperbaiki diagram UML. Dokumen desain sistem Anda secara detail.

Buku 2. Pendekatan Praktis - Edisi 1 IGNATUS JOKO DEWANTO. Program Studi Teknik Informatika Fakultas Ilmu Komputer Universitas Esa Unggul

Recommend Documents