Rencana Kasus dan Pengujian

RENCANA KASUS DAN PENGUJIAN

Dalam Proyek ini kami telah menguji Kasus yang ada dengan menguji suatu Aplikasi Program yang telah kami buat.

Dalam pengujian ini kami menggunakan pengujian secara manual ( tidak langsung ) yang artinya kami menguji dengan bantuan suatu item tertentu untuk membantu dalam pengujian yang kami lakukan.

kami juga mencoba menguji dengan cara secara langsung, yang artinya kami menggunakan software Microsoft Visual Basic Net 2008, yang mempunyai fitur yang secara langsung dapat kami uji melalui program tersebut, dengan Database yaitu Software MSQL 2005.

Program Aplikasi ini dapat anda ambil disini Download Rencana Kasus dan Pengujian

Rancangan

RANCANGAN

1. Perancangan Sistem

Perancangan sistem adalah membangun dan mendesain suatu sistem yang telah dianalisis dan direncanakan sebelumnya, untuk dapat diimplementasikan kepada suatu badan atau organisasi sehingga dapat mengatasi permasalahan yang ada.

3.2.1 Prosedur Sistem yang diusulkan

Dalam perancangan sistem yang baru akan memakai sistem komputerisasi dimana dalam melakukan kegiatannya, bagian Gudang akan lebih mudah dalam melakukan proses Pencarian lokasi yang kosong untuk barang yang masuk dan pencarian lokasi barang yang akan diambil penyewa. Tiap gudang bisa menampung banyak barang dari penyewa yang berbeda yang ditempatkan pada lot (lokasi penempatan) dengan nomor lot yang sudah diatur. Barang-barang yang dititipkan dari satu perusahaan bisa ditempatkan pada gudang dan lot yang berbeda sesuai dengan jenis barang dan ketersediaan tempat.Dengan adanya sistem yang diusulkan, bagian gudang akan dapat melakukan proses tersebut dengan lebih mudah, cepat serta mengurangi kesalahan dalam pekerjaan tersebut. Karena pada saat ini, proses yang terjadi pada gudang yaitu proses Pencarian lokasi yang kosong untuk barang yang masuk dan pencarian lokasi barang yang akan diambil penyewa masih banyak kesalahan dan banyak membingungkan. Dengan perancangan sistem yang baru dengan menggunakan suatu Aplikasi yang dibuat serta datanya akan disimpan pada suatu database, dapat memudahkan pekerjaan pada bagian gudang untuk mengumpulkan data sebagai informasi proses Pencarian lokasi yang kosong untuk barang yang masuk dan pencarian lokasi barang yang akan diambil penyewa.

Dalam perancangan sistem yang berbasis komputer maka data yang ada akan memiliki back-up data dan tidak memakan banyak tempat untuk penyimpanan karena memakai database dalam penggunaannya. Sistem yang diusulkan diatas sejalan dengan apa yang diperlukan oleh PT. SIMPANA BARANGA, yaitu efisiensi, cepat, keakuratan serta kemudahan dalam proses Pencarian lokasi yang kosong untuk barang yang masuk dan pencarian lokasi barang yang akan diambil penyewa pada gudang.

3.1.1 Rancangan Sistem

Rancangan sistem yang diusulkan pada PT. SIMPANA BARANGA terlihat pada model proses dan model data sebagai berikut:

3.2.1.1 Model Proses

Model proses dalam menghasilkan informasi yang dipergunakan untuk pembuatan data penyewa, data barang masuk, data barang keluar, mengelola lot,data statistik penyewaan, melihat status lot, laporan penyewaan pada PT. SIMPANA BARANGA terlihat dalam diagram dibawah ini.

1. Diagram Konteks Sistem yang Diusulkan

Diagram konteks merupakan diagram yang dibuat untuk menentukan lingkup proyek awal. Diagram ini hanya menunjukkan antarmuka utama sistem dengan lingkungannya. Berikut diagram konteks yang diusulkan pada rancangan sistem baru yang mungkin akan diterapkan pada PT. Simpana Baranga dapat dilihat pada Gambar 1.1

Gambar 1.1 Diagram Konteks

2. Diagram Dekomposisi

Diagram Dekomposisi adalah diagram yang kegiatannya menguraikan sistem menjadi subsistem dan proses. Diagram Dekomposisi yang akan diusulkan pada PT. Simpana Baranga dapat dilihat pada Gambar 1.2.

Gambar 3.3 Diagram Dekomposisi Sistem yang Diusulkan

3. Diagram Aliran Data Kejadian

Diagram aliran data kejadian adalah diagram aliran data yang menggambarkan konteks kejadian untuk kejadian tunggal. Diagram aliran data kejadian yang diusulkan pada PT. Simpana Baranga dapat dilihat pada gambar dibawah ini.

i. Diagram aliran data kejadian tambah data Pengguna.

Gambar 1.3 Proses 1.1 Tambah Data Pengguna

ii. Diagram aliran data kejadian ubah data Pengguna

Gambar 1.4 Proses 1.2 Ubah Data Pengguna

iii. Diagram aliran data kejadian hapus data Pengguna.

Gambar 1.5 Proses 1.3 Hapus Data Pengguna

iv. Diagram aliran data kejadian ubah Password.

Gambar 1.6 Proses 1.4 Ubah Password

v. Diagram aliran data kejadian Input barang keluar.

Gambar 1.7 Proses 2.1 Input Barang Keluar

vi. Diagram aliran data kejadian Input Barang Masuk.

Gambar 1.8 Proses 2.2 Input barang masuk

vii. Diagram aliran data kejadian Cetak Laporan barang masuk.

Gambar 1.9 Proses 2.3 lihat Laporan Barang Masuk

viii. Diagram aliran data kejadian Cetak Laporan barang keluar.

Gambar 1.10 Proses 2.4 Cetak Laporan Barang Keluar

ix. Diagram aliran data kejadian Cetak Laporan Persediaan Barang.

Gambar 1.11 Proses 2.5 Cetak Laporan Persediaan Barang.

x. Diagram aliran data kejadian Laporan Persediaan barang.

Gambar 1.12 Proses 3.1 Laporan Persediaan barang

xi. Diagram aliran data kejadian Laporan barang masuk.

Gambar 1.13 Proses 3.2 Laporan barang masuk

xii. Diagram aliran data kejadian Laporan barang keluar.

Gambar 1.14 Proses 3.3 Laporan barang keluar.

4. Diagram Aliran Data Sub Sistem Pengguna

Diagram aliran data sub sistem adalah diagram yang menggambarkan kejadian-kejadian yang terjadi dalam subsistem pada PT. Simpana Baranga.

Diagram aliran data subsistem pengguna pada PT. Simpana Baranga dapat dilihat pada gambar 1.15.

Gambar 1.15 Diagram Aliran Data Sub Sistem Pengguna

5. Diagram Aliran Data Sub Sistem Gudang

Diagram aliran data sub sistem gudang yang akan diterapkan pada PT. Simpana Baranga dapat dilihat pada gambar 1.16.

Gambar 1.16 Diagram Aliran Data Sub Sistem Gudang

5. Diagram Aliran Data Sub Sistem Laporan

Diagram aliran data sub sistem Direktur yang akan diterapkan pada PT. Simpana Baranga dapat dilihat pada gambar 1.17.

Gambar 1.17 Diagram Aliran Data Sub Sistem Manajer

5. Diagram Aliran Data Sistem

Diagram aliran data sistem adalah diagram yang menggambarkan semua proses yang terjadi di dalam sistem Informasi Persediaan barang pada PT. Simpana Baranga. Diagram aliran data keseluruhan dapat dilihat pada gambar 1.18.

Gambar 1.18 Diagram Aliran Data Sistem Keseluruhan

Jika Ingin Mengambil Klik Di sini Download Rancangan

Arsitektur Perangkat Lunak

Arsitektur Aplikasi Pelacak Barang

Desain Arsitektur Untuk Aplikasi Pelacak Barang(APB)

1. Overview

1.1 System Overview

APB digunakan untuk mempermudah user dalam melakukan proses yang berkaitan dengan penyimpanan,pengambilan,pencarian barang yang ada digudang. Serta mencetak laporan untuk managemen.

1.2 System Context

Seperti yang sudah dijelaskan dalam SRS, user adalah sumber informasi. Tidak ada sumber informasi yang lain selain user yang menggunakan aplikasi APB yang ada di dalam perusahaan.

1.3 Stakeholders pada APB

StakeHolders utama yang ada dalam system adalah user itu sendiri dan pemilik system. Peranan kedua StakeHolders ini adalah:

• Bagi Users: Menyediakan informasi bagi pelanggan yang ingin menyimpan,mengambil barang yang ada digudang. Serta memberikan laporan bila diminta oleh atasan.
• Bagi Pemilik: System mudah untuk diubah, yang akan digunakan untuk mengurusi masalah yang terjadi pada SRS yang mungkin terjadi dimasa yang akan datang. Perfoma waktu respon adalah factor yang lain dimana system harus di evaluasi.

1.4. Ruang lingkup dokumen ini

Pada dokumen ini, kami menuliskan 2 kemungkinan arsitektur untuk PAB, dengan membandingkan berbagai attribute yang memenuhi syarat dan memilih yang paling tepat yang merupakan tujuan utama dari doketmen arsitektur untuk PAB.
Dengan mendiskusikkan 2 kemungkinana,kami juga menyediakan alasan untuk memilih arsitektur terakhir. Untuk arsitektur , kami hanyan mempertimbangkan komponen atau bagian-bagian dan tampilan konektor saja.

1.5. Definisi dan Singkatan

Definisi :

User Pengguna Program APB

StakeHolders Pemeran utama

Singkatan :

APB Aplikasi Pelacak Barang

2. Desain Arsitektur

Arsitektur ini terdiri dari repositori data, yang berisi informasi tentang Laporan, transaksi, status, dan login. Berikut ini adalah komponen prinsip ini arsitektur.

2.1. Arsitektur 1 :

No Komponen Tipe Komponen Penjelasan

1 Tempat Penyimpanan Data Database Modul ini mengandung informasi tetang data penyewaan, laporan,pengamanan data, dan status gudang.

2 Kontrol Utama Proses(modul antar muka) User Login

3 Create,delete,transaksi Proses(Perubahan pada database) Informasi yang berkaitan dengan isi data, database, laporan, transaksi

4 Transaksi Proses(Perhitungan) Modul ini menghitung biaya penyewaan dan lain-lain
5 Status Gudang Proses (akses database) Modul ini menampilkan tentang status gudang

Berikut ini adalah konektor arsitektur:

No Konektor Tipe konektor Penjelasan

1 Konektor R/W Akses database/ perubahan Konektor ini berada di antara data repository dan module 3,4,5

2 Konektor hanya membaca Akses Database Konektor ini berada diantara data repository dan module 5

3 Konektor hanya menulis Akses database dan Perubahan Konektor ini berada diantara data repository dan module 4

Gambar 2.1 Data Repository

2.2. Arsitektur

2: Access Layer Model (4 lapis)

Arsitektur ini mirip dengan arsitektur repositori data. Perbedaan utama terletak pada fakta bahwa di sini, kita memiliki akses data lapisan memisahkan logika bisnis dan data repositori. Pengambilan dan modifikasi data dilakukan melalui lapisan akses data, sementara semua pengolahan data atau pelaksanaan logika bisnis yang dilakukan dalam logika bisnis lapisan. Lapisan ke-4 adalah lapisan presentasi (kontrol induk) yang bertanggung jawab untuk berinteraksi dengan pengguna dan modul lapisan logika bisnis. Kegunaan dari lapisan akses data berasal dari kenyataan bahwa jika jenis database diubah, maka lapisan akses hanya perlu diubah sedangkan logika pengolahan tetap sama. Komponen tetap sama kecuali bahwa sekarang kita akan memiliki komponen akses data baru mendapatkan / menaruh data yang akan bertanggung jawab untuk membaca dan menulis data sesuai dengan Laporan / Login / Transaksi. Diagram di bawah menunjukkan arsitektur ini.

Gambar 2.2 4 Lapisan Arsitektur

2.3 Perbandingan Arsitektur

Disini kita akan membandingkan 2buah arsitektur.

Kriteria Arsitektur 1 Arsitektur 2

Perubahan pada data depository Sulit Mudah

Perubahan data dari lokasi user Mudah Mudah

Penambahan fungsi Mudah Sulit

Penambahan User Mudah Mudah.

3. Arsitektur Terakhir untuk APB

Dari table diatas dapat kita lihat bahwa arsitektur 2 lebih baik karena perubahan data untuk data repository mudah dilakukan dan juga untuk melakukan perubahan data dari lokasi user mudah dilakukan,penambahan user mudah untuk dilakukan apabila memiliki hak akses untuk melakukannnya. Untuk melakukan penambahan fungsi ini sedikit sulit karena kita harus membongkar APB untuk menambah fungsi-fungsi baru.

Mau Ambil Klik disini Download

Rencana Proyek

Rencana Manajemen Proyek Sistem manajemen Pergudangan

1. Ringkasan Proyek
1.1 Ikhtisar Proyek
Personal Sistem Manajemen Investasi (PIM) ini dimaksudkan untuk membantu perusahaan
pergudangan dalam pengelolaan baik data barang masuk maupun data barang keluar.

1.2 Ruang Lingkup Proyek
Seperti dijelaskan di SRS, ruang lingkup proyek ini adalah mengelola data penyewa terutama mengelola pembukuan informasi, termasuk data barang masuk, mengelola data barang keluar, mengelola Lot atau lokasi penempatan serta memantau baik dari statistic penyewaan maupun status Lot dan juga mengelola untuk penerimaan laporan penyewaan untuk manajer.

1.3 Proses Pengembangan
Kami mengikuti model iteratif pengembangan perangkat lunak. Produk yang akan dikembangkan dalam mengikuti dua iterasi. Iterasi Pertama : Modul inti akan dikembangkan dalam iterasi yang akan mencakup modul berikut:

Iterasi kedua : iterasi ini akan melengkapi produk dengan fungsionalitas penuh. Itu berikut
perangkat tambahan akan dilakukan dalam iterasi ini:

Catatan: Produk ini setelah iterasi pertama adalah sistem kerja yang lengkap, meskipun tidak
dengan fungsionalitas penuh.

1.4. dan Jadwal Tim:
Tim ini terdiri dari 4 orang berikut:
a. Nur Sa’adah
b. Renia Yunita
c. Iin Andriani
d. WindySabatini
Berikut adalah jadwal dan usaha selama 2 iterasi :

Jumlah Usaha dalam manusia-jam: 282
Akhir pengiriman tanggal: 19/06/2010

1.5 Asumsi yang dibuat:
Asumsi yang dibuat tergantung apa yang kurang dalam SRS.

2. Detil Usaha dan Jadwal
Kami menggunakan pendekatan bottom up untuk estimasi. Dalam hal ini kami daftar modul utama dan tugas dan kemudian memperkirakan upaya mereka dan jadwal. Tugas tugas kepada anggota proyek juga ditentukan.

2.1 Iterasi Pertama:

Upaya diperkirakan orang-jam untuk iterasi kedua (termasuk uji): 90

3. Organisasi Tim
Kami akan memiliki tim yang lumayan kecil, maka kita menggunakan struktur tim datar teman satu kuliah, dengan satu orang memiliki peran tambahan manajer proyek. Setelah tabel memberikan organisasi:

Nama Peran

Tugas tugas kepada mereka akan dipertahankan dalam jadwal rinci, tingkat-tinggi
pandangan yang diberikan di atas.

4. Hardware dan Software yang diperlukan sumber daya
Sumber daya perangkat keras hanya diperlukan adalah computer, port dan sebagainya.

5. Rencana Mutu
Proses pengendalian mutu untuk proyek ini akan terdiri dari: Arsitektur SRS dan Review: SRS dan arsitektur Sistem manajemen pergudangan akan ditinjau oleh tim termasuk orang-orang dari luar pengembangan.
Desain Review: Desain dokumen akan dievaluasi oleh tim proyek.
Pengujian Unit: Setiap programer bertanggung jawab untuk Unit Pengujian modul-nya. Itu
Buat modul / Hapus / Ubah nama / Edit Portofolio / Keamanan / Transaksi penyewaan dan Hitunglah Net Worth / ROI akan diuji. Untuk beberapa modul, unit Laporan pengujian akan
diproduksi.
Sistem Pengujian: Akan dilakukan sesuai dengan rencana pengujian sistem.

6. Rencana Manajemen Risiko

7. Proyek Pelacakan
Karena proyek kecil, pelacakan yang rumit tidak diperlukan. Berikut ini adalah proyek pelacakan rencana:
 Kami akan melacak terutama jadwal dan tugas. Ini akan dilakukan melalui mingguan
pertemuan dan status laporan mingguan (yang akan dikirim melalui blog.). Status dari
tugas dicapai dan tidak terjawab akan dilaporkan mingguan.
 Upaya pelacakan akan dilakukan secara informal, dan jika-diperlukan estimasi kembali
akan dilakukan.
Resiko akan dikunjungi kembali bulanan dalam pertemuan kajian.

Ingin Mengambil Klik Disini Download

Jadwal Rencana Proyek Klik Disini Download Rencana Proyek

Kebutuhan dan Spesifikasi perangkat lunak

Kebutuhan dan Spesifikasi Perangkat Lunak

1. Pengantar
1.1 Tujuan
Aplikasi pencarian barang yang bertujuan dalam membantu proses bisnis pada PT. Simpana Baranga yang bergerak dibidang jasa pergudangan. Aplikasi ini digunakan untuk membantu dalam pencarian lokasi dalam penempatan barang yang masuk serta pencarian barang yang akan keluar gudang dan dapat digunakan untuk memantau status lot yang terisi maupun status lot yang kosong serta dapat meningkatkan layanan kepada para penyewa dengan mempersingkat waktu bongkar-muat barang yang dititipkan atau yang akan diambil. Dokumen ini menggambarkan tentang Aplikasi Pencarian Lokasi yang kosong untuk barang yang masuk dan pencarian lokasi Barang yang akan diambil oleh penyewa yang digunakan untuk membantu dalam proses jasa penyewaaan gudang pada PT. Simpana Baranga.

1.2 Ruang Lingkup
Fitur-fitur apa saja yang ada didalam ruang lingkup perangkat lunak (software) serta apa saja yang tidak termasuk dalam ruang lingkup software yang akan dikembangkan Yaitu : 1. Pengelolaan data penyewa(staff layanan) 2. Pengelolaan data barang masuk(staff gudang) 3. Pengelolaan data barang keluar(Staff gudang) 4. Pengelolaan lot (Staff Gudang) 5. Pemantauan Statistik Penyewaan(manager) 6. Pemantauan status lot (manager dan staff gudang) 7. Laporan penyewaan (manager).

1.3 Definisi
a. APB : Aplikasi Pencari Barang
b. Lot : Tempat penyimpanan barang/Satuan Paket Barang
c. User : Pengguna

2. Deskripsi Keseluruhan
2.1 Perspektif produk
Aplikasi ini ditujukan untuk PT. Simpana Baranga, yang bertujuan untuk membantu user atau pihak manajemen Pergudangan dalam mengelola barang dalam hal penyewaan gudang serta mengelola informasi data penyewa dan laporan–laporan yang diperlukan pihak manajemen. Aplikasi ini tidak dipengaruhi aplikasi atau perangkat lainnya, Aplikasi Database yang digunakan sebagai tempat penyimpanan data. Program ini bisa dijalankan pada operasi sistem yang berbasis Windows.

2.2 Fungsi – fungsi produk
Aplikasi yang mendukung beberapa use case berikut :

2.3 Karakteristik
User User harus dapat memahami proses bisnis dalam pergudangan, seperti penempatan barang dan proses masuk keluar barang. User harus memahami bagaimana cara menggunakan suatu aplikasi secara keseluruhan.

2.4 Pemeran Utama
Pemeran utama dalam APB adalah user dan aplikasi.

2.5 Masalah Umum
a. Database yang digunakan terpisah dari aplikasi utama.
b. APB adalah Aplikasi yang bersifat multi user.
c. Aplikasi dijalankan dikomputer yang memiliki prosesor minimal pentium 4

2.6 Asumsi dan Ketergantungan
Untuk menjalankan aplikasi, diperlukan Aplikasi database yang bernama Microsoft SQL server 2005.

3. Kebutuhan khusus
3.1 Kebutuhan Fungsional
Kami menjelaskan kebutuhan fungsional dengan menjabarkan berbagai use Case.

3.1.1 Diagram Use Case

Gambar 1.1 Diagram Use Case

Tabel glosarium use case dibawah ini merupakan bagian-bagian dari subsistem use case.

Tabel 1.1 Glossarium Use Case

1.2 Aplikasi Login ( Password ) PT. Simpana Barangan

Gambar 1.2 Aplikasi Menu Utama PT. Simpana Barangan

Keterangan :

Use case yang berkaitan dengan instalasi :

Use case 1 : Instalasi

Pemeran utama : User( staf gudang )

Pre kondisi : Software Microsoft SQL Server 2005 tersedia

Skenario Utama :

1. User menempatkan aplikasi ke dalam drive yang diinginkan

2. Mengaktifkan database

3. Membuat Login APB Pada Database Melalui APB

Skenario Alternatif :

2(a). Microsoft SQL Server 2005 belum tersedia

2(a)1. User menginstal Microsoft SQL Server 2005

2(b). Mengaktifkan Database Gagal

2(b)1. Coba Lagi

2(c)2. Batal Menjalankan Aplikasi

Use case yang berkaitan dengan hak akses pemakai :

Use case 2 : Login

Aktor utama : User (staf gudang dan manajemen)

Pre kondisi : -

Skenario Utama :

1. Menjalankan APB, user diminta untuk mengisi id Login dan Password.

2. User memberikan ID login dan password

3. System melakukan verifikasi

4. Tampilan menu utama muncul

Skenario Alternatif :

4(a). Login gagal.

4(a)1. Belum memiliki ID Login dan Password

4(a)1.1. Membuat Login dan Password (daftar)

4(a)1. ID login atau password yang diberikan user salah

4(a)2. Kembali mengisi ID login dan password

4(a)3. Lapor ke Admin

Use case 3 : Ubah Password

Aktor utama : user (manajemen )

Pre kondisi : user sudah login

Skenario Utama :

1. user membuka jendela password yang tersedia di menu.

2. user memilih ID dan password yang ditampilkan dari database password dan mengganti password dengan yang baru

3. System melakukan verifikasi

4. Password baru telah terdaftar dalam aplikasi

Skenario Alternatif :

4(a). Password baru yang dimasukkan oleh user tidak cocok dengan verifikasi Password.

4(a)1. Memasukan lagi Password yang sama pada

kolom Password baru dan kolom Verifikasi Password baru.

User Case 4 : Hapus User

Aktor utama : user (manajemen)

Pre kondisi : user sudah login

Skenario Utama :

1 user membuka form password yang tersedia di menu.

1. user memilih ID ditampilkan dari database dan menghapus ID yang tidak terpakai

2. System melakukan verifikasi

3. ID telah terhapus dari aplikasi

Use case yang berkaitan dengan menampilkan informasi :

Use case 5 : Status Lot

Aktor utama : user (manajemen atau staf gudang)

Pre kondisi : user sudah login

Skenario Utama :

1. User memilih sub menu untuk menampilkan status lot

Skenario Alternatif :

1(a). Status lot tidak tampil, karena jumlah lot belum

ditentukan
1(a).1. Menentukan jumlah lot terlebih dahulu

Use case 6 : Laporan Penyewaan

Aktor utama : user (manajemen)

Pre kondisi : user sudah login

Skenario Utama :

1. User memilih sub menu untuk menampilkan laporan penyewaan per-periode

Skenario Alternatif :

1(a). Laporan penyewaan belum lengkap karena periode

waktu yang ditentukan belum berakhir

Use case yang berkaitan dengan menampilkan informasi :

Use case 7 : Input data penyewa

Aktor utama : user (staf layanan)

Pre kondisi : user sudah login

Skenario Utama :

1. User menginput data penyewa ke dalam database

Skenario Alternatif :

1(a). Data yang diserahkan si penyewa tidak lengkap, akibatnya error pada saat penginputan

Use case 8 : Ubah data penyewa

Aktor utama : user (staf layanan & manajemen)

Pre kondisi : user sudah login

Skenario Utama :

1. User mengupdate / mengubah data penyewa yang ada dalam database

Skenario Alternatif :

1(a). Ada Data yang kosong (data belum lengkap)

Use case 9 : Hapus data penyewa

Aktor utama : user (staf layanan & manajemen)

Pre kondisi : user sudah login

Skenario Utama :

2. User menghapus data penyewa yang ada dalam database

Skenario Alternatif :

1(a). Data penyewa gagal dihapus, karena user yang sedang digunakan tidak memiliki hak untuk menghapus data penyewa

Use case yang berkaitan dengan aktifitas gudang :

Use case 10: Penentuan Lot

Aktor utama : user (staf gudang)

Pre kondisi : user sudah login

Skenario Utama :

1. User memilih sub menu untuk menampilkan jendela Pengaturan lot

2. User menentukan jumlah lot pergudang sesuai dengan kebutuhan

Use case 11 : Pencatatan barang masuk

Aktor utama : user (staf gudang)

Pre kondisi : user sudah login

Skenario Utama :

1. User memilih sub menu untuk menampilkan Jendela Pendaftaran

penitipan barang

2. User mengecek ketersediaan lot

3. User menginput data formulir penitipan barang

4. User menetapkan barang mau ditempatkan di lot yang sesuai.

Skenario Alternatif :

3(a). Lot penuh, sehingga penyewaan tempat(yang dipilih)

dibatalkan

3(a)1. Peralihan ke Gudang Lain

3(b). Barang yang dititipkan tidak Persyaratan

Use case 12 : Pencatatan barang keluar

Aktor utama : user (staf gudang)

Pre kondisi : user sudah login

Skenario Utama :

1. User memilih sub menu untuk menampilkan jendela Pendaftaran

pengeluaran barang

2. User menginput data formulir pengeluaran barang

3. User mencari lot tempat dimana barang ditempatkan

Skenario Alternatif :

3(a). Barang yang dicari melalui aplikasi tidak ditemukan

karena databarang yang ada didatabase tidak sesuai dengan penempatan lot yang digudang

3(a)1. Barang yang akan keluar harus dicari secara manual

Use case yang berkaitan dengan perhitungan biaya sewa :

Use case 12 : Biaya sewa

Aktor utama : user (staf gudang)

Pre kondisi : user sudah login

Skenario Utama :

1. User menghitung jumlah biaya yang harus pada penyewa

4. Kebutuhan Kinerja

(a) Minimal Komputer Pentium 4 1.8 Ghz 128 MB RAM

(b) Waktu tanggap <>

4. Spesifikasi Perangkat Lunak

5.1 Server dan Client

Spesifikasi komputer server terdiri dari prosesor Intel Pentium Xeon 3360, memori 2GB dan harddisk 320 GB sedangkan komputer client terdiri dari prosesor Intel Pentium Core 2 Duo, memori 1GB, dan harddisk 120GB. Server menggunakan sistem operasi Microsoft SQL Server 2003, sedangkan client menggunakan Windows XP

5.2 Alat Perangkat Lunak yang Dibutuhkan

- Microsoft Visual Studio 2008

- Microsoft SQL Server 2005

Untuk Ambil Posting Klik disini Download