Kegiatan RMO 6 Hari [PDF]

Citation preview

PENGANTAR GUNUNG RIDGELINE Penjual pakaian eceran (RMO) Ridgeline Mountain Outfitters (RMO) adalah perusahaan ritel besar yang berspesialisasi dalam pakaian dan aksesori terkait untuk semua jenis olahraga outdoor dan olahraga kegiatan. Gunung dan wilayah barat Amerika Serikat dan Kanada menyaksikan pertumbuhan luar biasa dalam kegiatan rekreasi dalam beberapa tahun terakhir, termasuk ski, snowboarding, bersepeda gunung, ski air, jet ski, sungai mengalir, berlayar, jogging, hiking, ATV, bersepeda, berkemah, mendaki gunung, dan rappelling. Dengan meningkatnya minat dalam olahraga luar ruangan, pasar untuk musim dingin dan pakaian olahraga musim panas dan aksesorisnya meledak, sehingga RMO terus berkembang lini pakaian olahraganya untuk merespons pasar ini. Pertumbuhan perusahaan memetakan sejarah menarik dari pesanan lewat pos, brickand- mortir, dan penjualan online. RMO memulai dengan menjual ke toko pakaian di Taman Kota, Utah, area. Pada akhir 1980-an dan awal 1990-an, mulai dijual langsung ke pelanggan yang menggunakan katalog dengan opsi mail-in dan pesanan telepon. Saya membuka toko pertamanya pada tahun 1994. Setelah Olimpiade Musim Dingin di Park City pada tahun 2002, bisnis meledak dan RMO dengan cepat berkembang ke 10 outlet ritel di seluruh Barat dan menambahkan penjualan Internet. Tahun lalu, pendapatan toko ritel adalah $ 67 juta, pendapatan telepon dan pesanan melalui pos adalah $ 10 juta, dan penjualan Internet adalah $ 200 juta. Sebagian besar penjualan terus berada di Barat, meskipun pasar di Indonesia beberapa daerah di Amerika Serikat bagian timur dan Kanada sedang tumbuh. Menjelang Musim Dingin Olimpiade di Vancouver, British Columbia, pada 2008, pertumbuhan dan laba RMO dihasilkan terutama dari penjualan dan layanan online, seperti halnya dengan sebagian besar pengecer khusus; Namun, bisnis bata-dan-mortir dan mail-order tetap penting, terlalu. Setelah Olimpiade Musim Dingin di Sochi pada tahun 2014, RMO bernegosiasi dengan beberapa Pemenang Medali Olimpiade Utah untuk dukungan. Ini memberikan minat tambahan di seluruh Barat dan memulai periode pertumbuhan cepat lainnya. Gambar 1-6 menunjukkan contoh katalog yang masih dikirim oleh RMO. Meskipun mail-order dan penjualan telepon sederhana, menerima dorongan katalog pelanggan online untuk melakukan pembelian, sehingga RMO terus memproduksi dan mengirimkan versi singkat. Gambar 1-7 menunjukkan halaman beranda pemesanan online RMO. RMO memproduksi sendiri lini pakaian luar dan olahraga. Namun, untuk menawarkan rangkaian lengkap pakaian di gerai ritelnya, ia juga menjual merek pakaian yang bersumber dari vendor lain. Selain itu, sebagian besar aksesori yang dijual adalah bersumber melalui vendor. ■■ Pameran Dagang Untuk menjaga lini produknya yang inovatif dan responsif terhadap permintaan konsumen, RMO's agen pembelian menghadiri pameran dagang pakaian dan aksesori di seluruh dunia di mana vendor memamerkan barang dagangan mereka. RMO bagus dalam mengantisipasi tren dan mendapat untung dari vendor spesial yang menarik. Selain itu, agennya selalu mengawasi produk dan aksesori baru untuk memperluas lini produk RMO secara tepat. Di pameran dagang, agen pembelian RMO sering menemukan produk mereka ingin menambah penawaran pakaian musim semi, musim panas, atau musim dingin. Di masa lalu, kapan Agen pembelian RMO ingin melakukan pemesanan dengan vendor, mereka akan melakukannya bertukar informasi kontak dengan vendor di pameran dagang dan kemudian tindak lanjut melalui email dan panggilan telepon untuk membuat pesanan pembelian. Pada saat ini Iklim bisnis 24/7, proses bisnis ini terlalu lambat. Dibutuhkan RMO untuk mempercepat agar tetap terdepan dalam persaingan, manfaatkan vendor berurusan di pameran dagang, dan lebih responsif terhadap permintaan pelanggan. Untuk mengatasi masalah ini, RMO memprakarsai proyek sistem informasi mengembangkan sistem untuk mengumpulkan dan melacak



informasi tentang pemasok dan tentang produk yang ditambahkan ke penawaran barang dagangannya. Kebutuhan Sistem Tradeshow untuk mengambil keuntungan dari perangkat nirkabel dan teknologi pengambilan data terbaru untuk memungkinkan agen pembelian untuk meneliti dan menyelesaikan pesanan pembelian di tempat di pameran dagang. RMO memutuskan untuk menggunakan manajemen proyek yang gesit dan iterative Pendekatan untuk menyelesaikan sistem kecil secepat mungkin dengan maksimal fleksibilitas. ■■ Mengembangkan Sistem Pameran Dagang RMO Kami akan mengatur proyek sampel kami — Sistem Pameran Trad RMO — menjadi beberapa iterasi. Rencana kami untuk iterasi pertama adalah menyelesaikannya hanya dalam enam hari. Tujuan utama kami adalah untuk memperkenalkan Anda dengan konsep dan teknik dari enam proses inti. Untuk melakukan ini, kita mungkin masuk lebih dalam ke proses inti daripada biasanya kita lakukan pada iterasi pertama dari proyek nyata. Selain itu, iterasi tampaknya akan dikelola jauh lebih formal daripada yang mungkin terjadi di dunia nyata untuk proyek sekecil itu. Iterasi kedua dan selanjutnya tidak akan dijelaskan secara detail, tetapi proyek Sistem Tradeshow yang lengkap akan membutuhkan beberapa iterasi lagi untuk produk jadi. Sebagian besar aplikasi sistem informasi baru memerlukan proyek dengan beberapa iterasi. Pada iterasi pertama, biasanya ada tiga tujuan utama. Pertama tujuannya adalah untuk mendapatkan persetujuan proyek. Tujuan kedua adalah untuk mendapatkan gambaran yang jelas dari keseluruhan visi sistem — keseluruhan fungsi dan persyaratan data. Tujuan ketiga adalah untuk menentukan spesifikasi detail dan mengembangkan solusi untuk satu bagian dari sistem (mis., sebenarnya menganalisis, merancang, membangun, dan menguji satu bagian dari sistem). Iterasi kedua dan ketiga akan terus bekerja pada bagian tambahan dari sistem berdasarkan visi sistem. Dalam proyek kami, kami akan menyentuh semua tujuan ini dalam iterasi pertama. Kami akan menunjukkan contoh Dokumen Visi Sistem dan kemudian mengembangkannya bagian dari keseluruhan sistem. Perlu dicatat bahwa pembagian proyek ini menjadi hari dan kegiatan sehari-hari agak sewenang-wenang. Organisasi berikut cukup bisa diterapkan, tetapi itu bukan satu-satunya cara untuk mengatur proyek. ■■ Kegiatan Proyek Awal Sebelum proyek benar-benar dimulai, kepala Departemen Pembelian RMO bekerja dengan analis sistem untuk mengidentifikasi dan mendokumentasikan bisnis tertentu perlu dan untuk menentukan tujuan proyek. Manajemen RMO kemudian meninjau tujuan proyek utama dan memberikan persetujuan anggaran. Setiap organisasi memiliki untuk memberikan persetujuan anggaran sebelum proyek dapat dimulai. Beberapa organisasi memiliki proses formal untuk mendapatkan proyek yang disetujui; organisasi lain punya yang kurang formal proses. Meskipun kegiatan ini adalah bagian dari Proses Inti 1 dari SDLC, mereka sering diselesaikan dengan baik sebelum dimulainya iterasi proyek pertama. Mereka mungkin disebut kegiatan pra-proyek Proses Inti 1: ■■ Identifikasi masalah dan dokumentasikan tujuan dari sistem solusi. ■■ Dapatkan persetujuan untuk memulai proyek. ❚❚ Dokumen Visi Sistem Seperti halnya semua proyek baru dalam RMO, Dokumen Visi Sistem dikembangkan untuk mengidentifikasi manfaat bagi perusahaan dan kemampuan fungsional yang akan dimasukkan dalam sistem. Seringkali, ini dilakukan dalam dua langkah: mengembangkan pendahuluan pernyataan manfaat dan kemudian menambahkan perkiraan biaya dolar spesifik dan manfaat dolar. Gambar 1-8 adalah



Dokumen Visi Sistem untuk proyek ini. Seperti dijelaskan sebelumnya, RMO membutuhkan sistem seluler yang dapat digunakan olehnya agen pembelian karena mereka menghadiri berbagai produk, pakaian, dan perdagangan kain menunjukkan. Sistem perlu memenuhi dua persyaratan utama. Pertama, harus fungsi untuk menangkap informasi tentang pemasok dan produk. Kedua, perlu dapat berkomunikasi dengan sistem kantor rumah, dan karena pameran dagang ini diadakan di berbagai tempat di seluruh dunia, berbagai metode konektivitas diperlukan. Investigasi awal mencakup berbagai opsi peralatan, seperti notebook komputer, tablet, dan telepon pintar. Smartphone tampaknya memiliki opsi koneksi terbaik, tetapi ukurannya yang kecil membuat tampilan detail foto agak sulit; iPad dan tablet portabel lainnya dengan tingkat lanjut opsi konektivitas juga tampaknya menjadi opsi yang layak. Karena smartphone dan tablet memiliki persyaratan serupa, analis memutuskan untuk mengembangkan aplikasi yang akan dieksekusi pada kedua jenis perangkat, memberikan beberapa opsi kepada agen pembelian untuk akses sistem. Menjelang akhir kegiatan proyek awal, pertemuan diadakan yang melibatkansemua orang kunci, termasuk perwakilan manajemen eksekutif. Itu keputusan dibuat untuk bergerak maju dengan proyek dan menganggarkan dana yang diperlukan.



KEGIATAN HARI 1 ❚❚ RMO — Sistem Tradeshow Secara Keseluruhan Proyek sebenarnya dimulai dengan Hari 1, yang pada dasarnya adalah hari perencanaan. Biasanya, tim proyek pertama-tama meninjau Dokumen Visi Sistem dan memverifikasibahwa pekerjaan pendahuluan masih berlaku. Ini meninjau ruang lingkup proyek untuk menjadi terbiasa dengan masalah, dan kemudian merencanakan iterasi dan kegiatan untuk sisa proyek. Proses inti SDLC kedua — Rencanakan dan memantau proyek — termasuk analisis bisnis dan kegiatan manajemen proyek. Kegiatan Inti Proses 2 ini selesai pada Hari 1: ■■ Tentukan komponen utama (area fungsional) yang dibutuhkan. ■■ Tentukan iterasi dan tetapkan masing-masing area fungsional ke iterasi. ■■ Tentukan anggota tim dan tanggung jawab. ❚❚ Merencanakan Proyek Keseluruhan dan Iterasi Proyek Banyak detail yang perlu dipertimbangkan dalam rencana proyek. Untuk proyek kami, kami akan melakukannya hanya fokus pada hal-hal mendasar. Kami akan menjelaskan perencanaan proyek lebih rumit di bab-bab selanjutnya. Tim proyek bertemu dengan pengguna untuk meninjau kebutuhan bisnis keseluruhan dan tujuan sistem baru. Visi Sistem Dokumen berfungsi sebagai titik awal untuk diskusi ini. Seperti yang sering terjadi, daftar kemampuan sistem menyediakan informasi dasar untuk menentukan rencana proyek keseluruhan. Langkah pertama adalah membagi sistem menjadi beberapa subsistem atau komponen. Subsistem adalah bagian yang berfungsi penuh dari yang lengkap sistem Informasi. Berdasarkan daftar kemampuan sistem, tim proyek mengidentifikasi dua subsistem ini: ■■ Subsistem Informasi Pemasok ■■ Subsistem Informasi Produk Subsistem Informasi Pemasok akan mengumpulkan dan mengelola informasitentang produsen atau grosir dan orang-orang penghubung yang bekerja untuk mereka. Subsistem Informasi Produk akan



menangkap informasi tentang berbagai produk yang ditawarkan oleh produsen atau grosir, termasuk detail deskripsi dan foto. Dokumen Visi Sistem Sistem Tradeshow RMO DESKRIPSI MASALAH Pameran dagang telah menjadi sumber informasi penting untuk produk baru, baru mode, dan kain baru. Selain penyedia pakaian luar dan besar kain, ada banyak penyedia yang lebih kecil. Penting bagi RMO untuk menangkap informasi tentang pemasok ini saat pameran dagang sedang berlangsung. Juga penting untuk mendapatkannya informasi tentang produk barang dagangan spesifik yang berencana dibeli oleh RMO. Selain itu, jika foto berkualitas dari produk dapat diperoleh saat di perdagangan menunjukkan, maka pembuatan halaman produk online sangat difasilitasi. Disarankan bahwa sistem baru dikembangkan dan digunakan sehingga pembelian lapangan agen dapat berkomunikasi lebih cepat dengan kantor pusat tentang pemasok dan spesifik produk yang menarik. Sistem ini harus digunakan pada peralatan portabel. KEMAMPUAN SISTEM Sistem baru harus mampu: • Mengumpulkan dan menyimpan informasi tentang produsen / grosir (pemasok) • Mengumpulkan dan menyimpan informasi tentang perwakilan penjualan dan kunci lainnya personil untuk setiap pemasok • Mengumpulkan informasi tentang produk • Mengambil gambar produk (dan / atau mengunggah gambar stok produk) • Berfungsi sebagai berdiri sendiri tanpa koneksi • Menghubungkan melalui Wi-Fi (Internet) dan mentransmisikan data • Menghubungkan melalui telepon dan mengirimkan data • Menghubungkan melalui telepon dan mengirimkan data MANFAAT BISNIS Diperkirakan bahwa penyebaran sistem baru ini akan memberikan yang berikut manfaat bisnis untuk RMO:



• Tingkatkan komunikasi tepat waktu antara peserta pameran dagang dan kantor pusat, dengan demikian meningkatkan kualitas dan kecepatan keputusan pesanan pembelian • Menjaga informasi yang benar dan terkini tentang pemasok dan personel utama mereka, dengan demikian memfasilitasi komunikasi yang cepat dengan pemasok • Menjaga informasi dan gambar yang benar dan cepat tentang produk baru, dengan demikian memfasilitasi pengembangan katalog dan halaman Web • Mempercepat penempatan pesanan pembelian untuk barang baru, dengan demikian menarik tren lebih cepat dan mempercepat ketersediaan produk



Langkah selanjutnya adalah mengidentifikasi urutan sub-sistem yang akan dikembangkan. Banyak masalah dipertimbangkan, seperti ketergantungan antara berbagai tugas, pengembangan berurutan versus paralel, ketersediaan tim proyek, dan urgensi proyek. Dalam kasus kami, tim memutuskan bahwa Subsistem Informasi Pemasok harus dijadwalkan untuk iterasi pertama dan Informasi Produk Subsistem harus dijadwalkan untuk iterasi kedua. Iterasi ketiga dan keempat akan menyelesaikan implementasi, pengujian, dan penyebaran sistem berdasarkan apa yang awalnya diimplementasikan dalam dua iterasi pertama. ❚❚ Merencanakan Sisa Iterasi Pertama: Subsistem Pemasok Setiap iterasi seperti proyek mini pengembangan sistem. Semua proses inti yang dijelaskan sebelumnya dapat diterapkan, dengan ruang lingkup terbatas pada komponen yang akan dikembangkan selama iterasi. Proses perencanaan untuk iterasi terdiri dari tiga langkah berikut: ■■ Identifikasi tugas yang diperlukan untuk iterasi. ■■ Atur dan susun tugas-tugas ini ke dalam jadwal. ■■ Identifikasi sumber daya yang diperlukan (terutama orang-orang), dan tetapkan orang ke tugas. Langkah pertama adalah mengidentifikasi — atau berupaya mengidentifikasi — semua tugas individu yang perlu dilakukan. Ketika tugas-tugas ini diidentifikasi, mereka dikompilasi dan diorganisir. Kadangkadang, daftar tugas yang terorganisir ini disebut struktur rincian kerja (WBS). Gambar 1-9 menunjukkan WBS untuk iterasi ini. Bagian dari upaya ini adalah mencoba memperkirakan berapa lama setiap tugas akan berlangsung. Karena iterasi ini memiliki ruang lingkup yang sangat terbatas (dan hanya enam hari), semua perkiraan akan dalam hitungan jam. Perkiraan ini tidak termasuk waktu yang dikeluarkan oleh mereka yang tidak di tim. Namun, dari mereka yang ada di tim, perkiraan termasuk waktu untuk karya asli, waktu untuk diskusi, dan waktu untuk meninjau dan memeriksa WBS untuk akurasi dan kebenaran



Langkah selanjutnya adalah mengatur tugas-tugas ini ke dalam jadwal. Sekali lagi, kita bisa menjadi sangat formal dan menggunakan alat penjadwalan proyek yang canggih, atau kita bisa daftar tugas-tugas dalam urutan yang kita pikir harus dilakukan. Membuat tugas secara berurutan merupakan bagian penting dari membangun jadwal karena mengidentifikasi setiap dependensi di antara tugas, meskipun banyak tugas dapat dilakukan secara paralel. Misalnya, tidak masuk akal untuk mencoba merancang basis data sebelum kami mengidentifikasi persyaratan informasi. Sekali lagi, manfaat besar perencanaan satu iterasi adalah bahwa kita dapat membuat jadwal tidak resmi, dan kita akan dapat menyesuaikan pekerjaan hari demi hari untuk menanggapi kompleksitas yang terjadi. Untuk iterasi ini, kami telah mengambil tugas dari WBS dan menempatkannya pada urutan hari demi hari yang kami sebut jadwal iterasi, seperti yang ditunjukkan pada Gambar 1-10. Manajer proyek dapat menggunakan diagram ini untuk menetapkan orang ke tugas dan untuk menempatkan tugas-tugas pada bagan jadwal tertentu dengan tanggal kalender jika perlu



Anda harus menyadari bahwa urutan aktivitas dan dependensi dari aktivitas tersebut diwakili dalam diagram ini dengan hanya akurasi sebagian. Sebagai contoh, kami menunjukkan bahwa pemrograman tidak dimulai sampai desain selesai. Namun, pada kenyataannya, mungkin ada beberapa tumpang tindih antara kedua kegiatan tersebut. Manfaat dari jadwal iterasi tiga kali lipat. Pertama, ini membantu tim mengatur pekerjaannya sehingga pengembang memiliki cukup waktu untuk memikirkan masalah desain kritis sebelum pemrograman dimulai. Kedua, menyediakan tolok ukur untuk melihat apakah iterasi sesuai jadwal. Misalnya, jika pertemuan dengan agen pembelian berlangsung sepanjang hari atau lebih dari satu hari, tim akan mengetahui sejak awal bahwa iterasi ini akan memakan waktu lebih lama dari yang diharapkan. Ketiga, manajer proyek dapat melihat bahwa pemrograman mungkin memerlukan lebih banyak sumber daya jika proyek akan tetap pada jadwal ini. Oleh karena itu, manajer proyek dapat mulai mengatur sumber daya untuk membantu bagian iterasi tersebut. Harus jelas bahwa bahkan diagram sederhana ini dapat membantu manajer proyek merencanakan dan mengatur pekerjaan.



KEGIATAN HARI 2 Keseluruhan Tradeshow System Hari 1 melibatkan perencanaan dan pengorganisasian proyek. Hari 2 melibatkan penemuan dan pemahaman detail, yang merupakan bagian penting dari analisis sistem. Sekarang kami akan menyelesaikan kegiatan analisis sistem secara lebih terperinci untuk Sistem Tradeshow yang lengkap. Kegiatan-kegiatan Inti Proses 3 ini meliputi: ■■ Lakukan tugas pencarian fakta untuk memahami persyaratan. ■■ Mengembangkan daftar use case dan diagram use case. ■■ Mengembangkan daftar kelas dan diagram kelas. ❚❚ Pencarian Fakta dan Keterlibatan Pengguna



Sebelum proyek dimulai, definisi persyaratan yang luas dikembangkan. Sekarang saatnya untuk memeriksa persyaratan-persyaratan tersebut dan menentukan dengan tepat apa yang dibutuhkan oleh sistem untuk dilakukan oleh pengguna. Ada berbagai teknik untuk memastikan bahwa pencarian fakta lengkap dan menyeluruh. Ini termasuk mewawancarai pengguna utama, mengamati proses kerja yang ada, meninjau dokumentasi yang ada dan sistem yang ada, dan bahkan meneliti perusahaan lain dan sistem lainnya. Langkah pertama adalah mengidentifikasi pengguna utama yang akan mendefinisikan detail ini. Dalam skenario ini, manajer Departemen Pembelian akan menjadi salah satu pengguna pertama yang bertemu. Dia mungkin akan menunjuk satu atau dua agen pembelian berpengetahuan yang dapat bekerja dengan tim secara berkesinambungan untuk mengembangkan spesifikasi dan untuk memverifikasi bahwa sistem bekerja sesuai kebutuhan. Semua proyek yang sukses tergantung pada keterlibatan pengguna yang berat. Dalam Bab 2, Anda akan belajar lebih banyak tentang mengidentifikasi pemangku kepentingan utama dan mengumpulkan informasi.



❚❚ Mengidentifikasi Kasus Penggunaan Mengidentifikasi dan menjelaskan kasus penggunaan adalah cara untuk mendokumentasikan apa yang dibutuhkan pengguna berkaitan dengan sistem, karenanya, istilah use case — kasus atau situasi di mana sistem digunakan. Misalnya, misalkan agen pembelian pergi ke pameran dagang dan menemukan jaket olahraga ringan baru yang akan bekerja dengan baik untuk kejatuhan RMO penawaran barang dagangan. Misalkan tugas pertama agen pembelian perlu lakukan adalah mencari tahu apakah pemasok ini telah bekerja dengan RMO sebelumnya. Karena itu, dibutuhkan case use untuk Sistem Tradeshow mungkin Carilah pemasok. Satu cara yang bagus untuk melakukannya membantu Anda berbicara tentang kasus penggunaan adalah dengan mengatakan, "Agen pembelian 'menggunakan' system untuk ‘Mencari pemasok.’ ”Ada beberapa metode yang digunakan untuk mengidentifikasi kasus penggunaan, yang akan Anda pelajari nanti dalam buku ini. Beberapa pengembang lebih suka menggunakan yang serupa konsep yang disebut cerita pengguna Gambar 1-11 adalah daftar awal kasus penggunaan untuk seluruh Sistem Tradeshow. Ketika tim proyek bertemu dengan agen pembelian dalam brainstorming sesi, mereka mengidentifikasi kasus penggunaan bersama. Karena iterasi pertama adalah focus hanya pada Subsistem Informasi Pemasok, tim proyek juga akan focus perhatiannya hanya pada empat kasus penggunaan pertama dalam daftar. ❚❚ Mengidentifikasi Kelas Domain Kelas domain mengidentifikasi hal-hal di dunia nyata yang dibutuhkan system tahu tentang dan melacak. Untuk menemukan kelas domain, kami mencari semua objek, atau hal-hal yang digunakan atau ditangkap oleh sistem. Objek datang dalam semua jenis dan variasi, dari barang berwujud (seperti produk barang dagangan yang dapat Anda lihat dan sentuh) ke konsep yang lebih abstrak yang tidak dapat Anda sentuh (seperti promosi), yang, meskipun tidak berwujud, adalah hal yang penting untuk diingat dan dilacak. Domain kelas adalah kategori objek yang diidentifikasi, seperti tabel dalam database mewakili kategori catatan yang dikandungnya. Kelas Produk mewakili semua dari objek produk yang digunakan oleh sistem.



Kelas domain diidentifikasi selama diskusi dengan agen pembelian dengan mencari kata benda yang menggambarkan kategori hal. Misalnya, agen akan sering berbicara tentang pemasok, produk barang dagangan, atau barang inventaris. Kata benda ini menjadi kelas domain, dan setiap kelas domain memiliki atribut (seperti informasi kontak, produk, atau lokasi bisnis) yang merinci informasi tersebut Anda perlu menyimpan tentang kelas domain. Gambar 1-12 menggambarkan nomina mana yang merupakan kelas domain mendasar untuk Sistem Pameran Dagang. Atribut adalah potongan informasi yang membantu mendefinisikan dan jelaskan detail tentang kelas domain. Selain hanya menyediakan daftar kelas domain, analis sistem sering mengembangkan diagram visual kelas, atributnya, dan hubungannya dengan kelas lain. Diagram ini disebut diagram kelas domain. Gambar 1-13 menunjukkan diagram kelas domain untuk Sistem Tradeshow. Setiap kotak adalah kelas dan dapat dianggap sebagai seperangkat objek tertentu yang penting bagi sistem. Atribut penting dari setiap kelas juga termasuk dalam setiap kotak. Ini mewakili informasi rinci tentang setiap objek yang akan dikelola oleh sistem. Perhatikan bahwa beberapa kelas memiliki garis yang menghubungkannya. Ini mewakili asosiasi antara kelas yang perlu diingat oleh sistem. Misalnya, kontak adalah orang yang bekerja untuk pemasok tertentu. Contoh spesifik mungkin bahwa Bill Williams adalah penghubung untuk Perusahaan Pakaian Olahraga Pasifik Selatan. Dengan demikian, sistem perlu mengasosiasikan Bill Williams dan South Pacific Sportswear Company. Baris asosiasi mendokumentasikan persyaratan itu. Diagram kelas domain adalah cara yang ampuh dan sering digunakan untuk memahami dan mendokumentasikan persyaratan informasi suatu sistem. Sistem Tradeshow sangat sederhana, dengan hanya empat kelas yang diidentifikasi — dua di antaranya milik Subsistem Informasi Pemasok. Sebagian besar sistem kehidupan nyata jauh lebih besar dan memiliki puluhan atau bahkan ratusan kelas domain. ■■ Kegiatan Hari 3 Tujuan dari kegiatan Hari 3 adalah untuk menganalisis secara rinci kasus penggunaan dan kelas domain yang dijadwalkan untuk diterapkan dalam iterasi pertama untuk Subsistem Pemasok. Termasuk dalam kegiatan Core Proses 3 ini: ■■ Lakukan pencarian fakta mendalam untuk memahami detail dari setiap kasus penggunaan. ■■ Memahami dan mendokumentasikan alur kerja terperinci dari setiap kasus penggunaan. ■■ Tentukan pengalaman pengguna dengan sketsa layar dan laporan yang diperlukan untuk setiap kasus penggunaan. Setelah bekerja dengan agen pembelian, pengembang menentukan kasus penggunaan berikut yang berkaitan dengan Subsistem Informasi Pemasok: ■■ Mencari pemasok ■■ Masukkan / perbarui informasi pemasok ■■ Cari informasi kontak ■■ Masukkan / perbarui informasi kontak



Dari daftar ini, pengembang kemudian akan membuat diagram use case. Kasus penggunaan diagram digunakan untuk menggambarkan secara grafis kasus penggunaan dan pengguna yang terlibat dalam subsistem. Gambar 1-14 menggambarkan diagram use case sederhana untuk Pemasok Informasi Subsistem menunjukkan empat kasus penggunaan sebagai oval dan dua pengguna sebagai tongkat angka. Garis yang menghubungkan pengguna dan use case menunjukkan siapa yang menggunakan system untuk use case: Agen pembelian melakukan keempat use case, tetapi Manajer juga mencari pemasok atau kontak. Tim proyek akan melihat dengan cermat langkah-langkah yang harus diikuti untuk setiap kasus penggunaan untuk lebih memahami bagaimana aplikasi perlu bekerja dan mengidentifikasi apa layar dan laporan perlu dikembangkan. Sebagai tim mendapat lebih banyak ke dalam detail, mungkin menemukan bahwa beberapa analisis awal tidak lengkap atau tidak benar dan dapat menyesuaikan WBS untuk mencerminkan perubahan. Ini saat yang tepat untuk membuat penemuan semacam itu — jauh lebih baik untuk menemukan kesalahan lebih awal daripada setelah program telah ditulis. ❚❚ Mengembangkan Deskripsi Kasus Penggunaan dan Diagram Alur Kerja Ada berbagai metode untuk mendokumentasikan detail kasus penggunaan. Satu itu Anda akan belajar nanti dalam teks ini disebut deskripsi kasus penggunaan. Metode lain sedang mengembangkan diagram aktivitas, yang menunjukkan semua langkah dalam use case. Tujuan dengan kedua metode ini adalah untuk mendokumentasikan interaksi antara pengguna dan sistem (mis., bagaimana pengguna berinteraksi dan menggunakan sistem untuk melakukan tugas kerja khusus untuk kasus penggunaan tunggal). Mari kita kembangkan diagram aktivitas untuk satu kasus penggunaan. Gambar 1-15 menggambarkan kasing kasus penggunaan pemasok. Oval pipih dalam diagram mewakili kegiatan, berlian merupakan titik keputusan, dan panah mewakili urutan aliran. Kolom menunjuk orang yang melakukan kegiatan, dalam hal ini agen pembelian di kolom pertama dan Pameran Dagang Sistem di kolom kedua. Biasanya, diagram aktivitas cukup mudah bagi pengguna untuk memahami dan mengkritik Panah yang melintasi garis antara pengguna (tengah) mewakili interaksi antara pengguna dan sistem. Ini sangat penting karena mereka menunjuk situasi di mana pengembang harus menyediakan layar atau halaman Web yang baik menangkap atau menampilkan informasi. Situasi ini menjadi bagian dari antarmuka pengguna. Pada Gambar 1-15, panah atas menunjukkan bahwa nama pemasok dimasukkan ke dalam sistem terlebih dahulu. Jadi, kami menyimpulkan bahwa use case harus memiliki pencarian online halaman dengan bidang yang tersedia untuk memasukkan nama pemasok. Panah berikutnya menunjukkan aplikasi memerlukan halaman yang menampilkan semua detail untuk masing-masing pemasok, termasuk daftar kontak yang ada. Pengguna mungkin juga ingin melihat lebih banyak perincian tentang penghubung tertentu untuk pemasok ini, jadi aplikasi harus menyediakan bidang permintaan informasi terperinci untuk kontak tertentu. Karena pengguna harus memilih salah satu hasil yang ditampilkan, kita harus mendesain halamannya setiap entri pada daftar adalah tautan panas atau dapat dipilih. ❚❚ Menentukan Tata Letak Layar Desain antarmuka pengguna termasuk menciptakan bagaimana sistem terlihat dan bagaimana pengguna berinteraksi dengannya. Karena antarmuka pengguna adalah jendela pengguna ke fungsionalitas dari sistem, itu pada dasarnya adalah sistem itu sendiri kepada pengguna. Jika antarmuka dirancang dengan buruk, pengguna tidak akan dapat mengambil keuntungan penuh dari sistem; mereka bahkan mungkin menganggap sistemnya kurang optimal. Di sisi lain tangan, antarmuka pengguna yang



dirancang dengan baik — yang intuitif dan mudah digunakan, memiliki berbagai fitur untuk memudahkan navigasi, dan memberikan informasi yang baik— akan meningkatkan utilitas sistem secara luar biasa. Gambar 1-16 mengilustrasikan tata letak halaman pertama yang digunakan untuk alur kerja dalam kasus penggunaan Cari pemasok. Setengah bagian atas halaman menyediakan bidang di mana pengguna memasukkan informasi pemasok, dan bagian bawah halaman menunjukkan hasilnya. Setelah hasilnya diberikan, kotak pencarian untuk entri data akan tetap terlihat untuk memungkinkan pengguna memasukkan pencarian lain. Setiap entri dalam hasil bagian akan dibangun sebagai tautan panas, sehingga pengguna dapat mengklik pada pemasok tertentu untuk mengambil informasi lebih rinci. Teknik drill-down ini biasa dilakukan metode yang digunakan dalam sistem saat ini dan secara intuitif akan mudah bagi pengguna. Data untuk semua bidang yang diperlukan disimpan dalam database. Pencarian mencari informasi dalam database, dan menampilkan data yang diperlukan, seperti nama, alamat, dan informasi kontak. Pencarian di seluruh internet juga dimungkinkan. Ini memungkinkan agen pembelian untuk mencari dan melihat situs Web pemasok sendiri, termasuk forum dan diskusi tentang pemasok. ■■ Kegiatan Hari 4 Fokus utama Hari 4 adalah merancang berbagai komponen solusi sistem, sesuai dengan Proses Inti 4: Desain Komponen Sistem. Hingga sekarang, kami sebagian besar telah mengumpulkan persyaratan pengguna. Pada Hari 4, kami merancang sistem berdasarkan pada kebutuhan pengguna, yang mengarah pada upaya pemrograman. Dalam hal itu, kegiatan desain dapat dianggap sebagai jembatan. Dokumen desain memberikan cetak biru untuk bagaimana solusi akan terstruktur dan bagaimana itu akan terjadi diprogram. Desain sistem juga cenderung melibatkan orang-orang teknis, dengan sedikit perlu untuk partisipasi pengguna. Desain bisa menjadi proses yang kompleks. Dalam proyek kecil kami, kami akan membatasi contoh desain hanya beberapa model dan teknik. Kegiatan hari 4 (Inti Proses 4) meliputi: ■■ Desain struktur basis data (skema). ■■ Desain struktur tingkat tinggi sistem. Perancangan basis data adalah kegiatan yang cukup mudah yang menggunakan kelas domain diagram dan mengembangkan skema basis data terperinci yang dapat langsung diimplementasikan oleh sistem manajemen basis data. Elemen-elemen seperti desain meja, kunci dan identifikasi indeks, tipe atribut, dan keputusan efisiensi lainnya dibuat selama kegiatan ini. Merancang struktur sistem tingkat tinggi dan program individu dapat menjadi proses yang rumit dan kompleks. Pertama, struktur keseluruhan system dirancang dengan mengidentifikasi subsistem dan koneksi ke sistem lain. Kemudian, dalam setiap subsistem, keputusan dibuat tentang modul program individual, seperti antarmuka pengguna, logika bisnis, dan akses basis data. Sudah lazim bagi pengembang untuk mulai menulis kode program seperti mereka mengembangkan bagian dari desain. Namun, praktik terbaik menunjukkan bahwa perancang lengkapi sebagian besar desain struktur tingkat tinggi sebelum menulis kode. Karena itu, dalam proyek RMO Tradeshow System, kami akan mencantumkannya sebagai kegiatan terpisah. ❚❚ Merancang Basis Data



Merancang basis data menggunakan informasi yang disediakan oleh diagram kelas domain untuk menentukan tabel, kolom dalam tabel, dan komponen lainnya. Terkadang, desain basis data dilakukan untuk seluruh sistem sekaligus atau dengan subsistem. Di lain waktu, itu dibuat sedikit demi sedikit — kasus penggunaan dengan kasus penggunaan. Untuk menjaga proyek kami sederhana, kami hanya akan menunjukkan desain database untuk dua Informasi Pemasok Kelas subsistem. Gambar 1-17 menunjukkan dua tabel database relasional yang menghasilkan dengan atribut yang disertakan bersama dengan tipe data dan properti lainnya. ❚❚ Pendekatan Umum untuk Desain Salah satu pertanyaan pertama yang dihadapi dalam desain perangkat lunak adalah bagaimana dan ke mana mulai. Sejauh ini, kami telah mengumpulkan tiga set informasi yang dapat menjawabnya pertanyaan: ■■ Gunakan kasing, dengan diagram aktivitas ■■ Kelas domain, dengan diagram yang menyertainya ■■ Halaman dan laporan, dengan spesifikasi logika program dan tampilan Kebetulan, di bagian sebelumnya, kami menggunakan diagram kelas sebagai dasaruntuk desain basis data. Kelas-kelas yang sama itu penting dalam mengembangkan objektif kelas program. Sebelum kita terjun lebih jauh ke dalam desain perangkat lunak, mari kita bahas secara singkat tujuannya desain sistem dan apa yang kita harapkan dari hasil atau hasilnya. Berorientasi pada objek program disusun sebagai satu set objek yang berinteraksi berdasarkan kelas. Untuk memprogram, kita perlu tahu apa kelasnya, apa logikanya di dalam setiap kelas (mis., fungsinya), dan kelas mana yang harus berinteraksi. Ini adalah tujuan akhir daridesain sistem. Kami melakukan desain ini dengan mulai dari level yang paling tinggi kemudian mengebor turun ke level terendah hingga kami telah menetapkan semua fungsi di dalam masing-masing kelas. Desain terperinci mendokumentasikan proses pemikiran tentang bagaimana memprogram masing-masing gunakan kasing. Untuk Hari 4, kami hanya fokus pada desain keseluruhan. ❚❚ Merancang Komponen Perangkat Lunak Gambar 1-18 menunjukkan keseluruhan struktur sistem baru dalam hal perangkat lunak komponen. Meski sosoknya sendiri tampak agak sederhana, beberapa penting keputusan telah terlibat dalam pengembangan desain ini. Pertama, perhatikan bahwa keputusan dibuat untuk membangun aplikasi ini sebagai sistem berbasis browser dirancang untuk digunakan pada smartphone dan tablet. Berbeda dan sangat popular Pendekatannya adalah membangun aplikasi smartphone atau tablet tertentu. Sistem berbasis browser terkadang tidak memberikan kecepatan konektivitas yang sama dan kontrol sebagai aplikasi smartphone atau tablet, tetapi lebih fleksibel karena mereka mudah digunakan pada peralatan yang berbeda, seperti laptop dan laptop tablet, tanpa modifikasi, dan pada smartphone dengan sedikit modifikasi karena ukuran layar. Keputusan desain tingkat tinggi ini akan menentukan struktur terperinci dari sistem. Sistem berbasis browser disusun dan dikonstruksi secara berbeda dari sistem aplikasi yang berjalan pada smartphone atau komputer tablet.



❚❚ Menentukan Diagram Kelas Desain Pendahuluan Sistem Tradeshow akan dibangun dengan menggunakan pemrograman berorientasi objek (OOP) teknik, dimulai dengan mengembangkan set kelas perangkat lunak danmetode mereka yang akan dibutuhkan untuk sistem. Gambar 1-19 adalah pendahuluan diagram kelas desain untuk Subsistem Informasi Pemasok yang mengidentifikasi kelas perangkat lunak yang diperlukan untuk sistem (misalnya, SupplierView dan Kelas ContactView). Pada Gambar 1-19, kami hanya menampilkan desain domain masalah kelas dan kelas tampilan antarmuka pengguna-antarmuka. Masalah desain domain kelas biasanya berasal dari kelas-kelas yang diidentifikasi selama analisis kegiatan — karenanya, nama: kelas desain masalah (kebutuhan pengguna). Kamu juga akan memperhatikan bahwa mereka sangat berhubungan dengan tabel database; faktanya, dalam proyek sederhana ini, mereka hampir persis sama dengan tabel database. Kelas desain pada Gambar 1-19 termasuk atribut yang diperlukan untuk kelas. Mereka juga memasukkan nama metode dari metode penting di dalamnya setiap kelas. Salah satu elemen terakhir dalam diagram kelas desain adalah panah yang ditampilkan di mana kelas mengakses metode kelas lain. ❚❚ Merancang Arsitektur Perangkat Lunak Subsistem Setelah kami memiliki struktur dan pendekatan keseluruhan untuk menerapkan sistem baru, kita mulai menelusuri desain perangkat lunak untuk subsistem. Angka 1-20 menggambarkan desain Subsistem Informasi Pemasok. Perhatikan bahwa subsistem ini selanjutnya dibagi menjadi beberapa lapisan: lapisan Lihat dan lapisan Domain. Salah satunya Keuntungan dari mempartisi sistem menjadi lapisan adalah lebih mudah untuk membangun dan mempertahankan dengan struktur semacam ini mengingat format modularnya. Misalnya, sistem akan berbasis browser, tetapi browser yang berbeda memerlukan teknik yang berbeda. Lebih baik untuk tidak menggabungkan kompleksitas ini dengan fungsi-fungsi program dasar. Oleh karena itu, mereka dipisahkan menjadi lapisan yang berbeda. Layer View mencakup dua kelas yang mewakili apa yang terlihat pada pengguna antarmuka — SupplierView dan ContactView — serta beberapa fungsi JavaScript. Lapisan Domain mencakup dua kelas yang saling berinteraksi dan dengan basis data — Pemasok dan Kontak. ❚❚ Mengelola Proyek Desain adalah kegiatan yang kompleks dengan berbagai perspektif — dari struktur tingkat tinggi desain untuk desain program terperinci tingkat rendah. Dalam proyek kami, kami telah berpisah tugas untuk mendesain struktur sistem keseluruhan dari desain rinci program itu sendiri. Namun, kegiatan ini sering dilakukan bersamaan. Struktur arsitektur perangkat lunak tingkat tinggi dasar didefinisikan terlebih dahulu, tetapi tingkat menengah dan desain tingkat rendah sering dilakukan bersamaan dengan pemrograman. Desain dan pemrograman terperinci adalah kegiatan yang cukup memakan waktu. Seorang manajer proyek harus memutuskan apakah akan memperpanjang proyek atau membawa tambahan programmer untuk membantu menulis kode. Dalam proyek kami, kami telah memilih untuk masukkan setengah hari waktu luang untuk membawa dua programmer tambahan dan kereta mereka. Tentu saja, kita dapat melanjutkan dan memulai kegiatan Hari 5 untuk memastikan hal itu kami menjaga proyek sesuai jadwal. ■■ Kegiatan Hari 5



Seperti disebutkan sebelumnya, meskipun desain dan pemrograman yang terperinci dapat dimulai sebelumnya dalam proyek, kami mengidentifikasinya sebagai kegiatan hari yang terpisah. Kami ingin menekankan bahwa bukan praktik yang baik untuk memulai pemrograman sebelum informasi penting diperoleh dan keputusan dibuat. Pendekatan yang jauh lebih baik adalah dengan memahami, mendesain, dan membangun bongkahan kecil dari sistem sekaligus. Berulang pengembangan mengantisipasi dan merencanakan perubahan dan penyempurnaan yang diharapkan persyaratan masalah yang terjadi selama perancangan dan pemrograman terperinci. Kegiatan hari 5 meliputi yang berikut (Proses Inti 5): ■■ Buat desain detail. ■■ Memprogram komponen subsistem. Ketika programmer menulis kode, mereka juga melakukan pengujian individual pada kelas dan fungsi yang mereka programkan. Buku teks ini tidak focus kegiatan pemrograman. Namun demikian, kami menyertakan contoh kode program demikian Anda dapat melihat bagaimana desain sistem terkait dengan kode program akhir. Gambar 1-21 memperlihatkan kode PHP yang mendefinisikan kelas SupplierView yang menerima dan memproses permintaan informasi pemasok. Perhatikan bahwa ia mengirim pesan ke Pemasok kelas meminta informasi saat dibutuhkan. ■■ Kegiatan Hari 6 Fokus kegiatan Hari 6 adalah pengujian akhir, langkah yang diperlukan sebelum sistem siap digunakan. Meskipun ada banyak jenis pengujian, kami hanya menyebutkan dua jenis saat ini: keseluruhan pengujian fungsional sistem dan pengguna ujian penerimaan. Pengujian fungsional biasanya merupakan tes untuk semua fungsi pengguna dan sering dilakukan oleh tim jaminan kualitas. Tes penerimaan pengguna serupa di alam, tetapi ini diselesaikan oleh pengguna, yang menguji kebenaran sistem dan "kebugarannya" untuk memenuhi persyaratan bisnis. Masing-masing dari berbagai kegiatan pengujian di Hari 6 memiliki urutan tugas yang serupa untuk melakukan. Tugas itu sendiri sangat tergantung pada data uji dan pada metode untuk menguji kasus uji tertentu. Dalam beberapa kasus, pengujian mungkin otomatis. Di tempat lain, individu mungkin perlu melakukan tes secara manual. Gambar 1-22 adalah diagram alur untuk menguji sistem baru. Dalam bagan alur ini, kita telah menunjukkan tugas pengujian yang berbeda sebagai langkah terpisah; pada kenyataannya, mereka cenderung semua dilakukan bersama. Namun, setiap test case yang diberikan akan mengikuti alur ini. ■■ Rekap Iterasi Pertama Gambar 1-23 adalah tangkapan layar dari halaman browser yang digunakan dalam Tradeshow Sistem untuk masuk dan melihat pemasok. Halaman ini akan terlihat di tablet. Itu Halaman smartphone akan terlihat berbeda, tetapi akan melakukan fungsi yang sama. Seperti yang dinyatakan sebelumnya, ini adalah iterasi pertama (enam hari) dari proyek yang lebih panjang. Menggunakan teknik Agile dan iterasi dalam proyek keseluruhan memungkinkan fleksibilitas dalam mendefinisikan dan membangun sistem baru. Dalam proyek enam hari ini, para pengguna sudah Keterlibatan besar sepanjang hari kecuali Hari 4 dan Hari 5. Masalah utama dalam mengembangkan sistem baru adalah bahwa seiring kemajuan proyek, persyaratan baru sering diidentifikasi. Ini terjadi karena pengguna dan tim proyek belajar lebih banyak tentang bagaimana menyelesaikan kebutuhan bisnis. Agile, iterative proyek disusun untuk menangani persyaratan baru ini — seringkali dengan menambahkan pengulangan lain untuk keseluruhan proyek.



Sebagai langkah terakhir dalam iterasi saat ini, atau mungkin sebagai bagian dari perencanaan proses untuk iterasi berikutnya, harus ada review dari tugas yang diselesaikan dan evaluasi keberhasilan iterasi saat ini. Pelajaran yang diambil dan masalah untuk dilakukan ke depan menciptakan lingkungan perbaikan yang berkelanjutan dan perbaikan. Karena itu, proyek berulang cenderung meningkat dan menjadi lebih efisien selama masa proyek. Dalam proyek ini, perencanaan untuk Iteration 2 akan mengkonfirmasi niat memfokuskan pada kasus penggunaan dan kelas domain untuk Informasi Produk Subsistem. Upaya akan fokus pada pemahaman detail penggunaan tiga kasus dan dua kelas domain diperlukan. Diagram aktivitas atau gunakan deskripsi kasus mungkin dibuat untuk kasus penggunaan kompleks. Dua tabel database lagi akan dirancang dan diimplementasikan. Dua lagi kelas tampilan perangkat lunak dan Desain kelas domain akan ditentukan. Kode kemudian akan ditulis dan diuji untuk mengimplementasikan kelas dan menggunakan case.