16.45
Unknown
Enterprise Unified Process
Oleh:
Adhy Suryo Wicaksono
Adhy Suryo Wicaksono
Bayu Akbar
Fachri Adityo
Fajar Hidayatullah
Depok
2013
BAGIAN I
Kata Pengantar
Puji dan syukur kami panjatkan ke Hadirat Tuhan Yang Maha Esa, karena
berkat limpahan Rahmat dan Karunia-Nya sehingga kami dapat menyusun buku
ini dengan baik, serta tepat pada waktunya. Dalam buku ini kami akan
membahas mengenai “ENTERPRISE UNIFIED PROCESS”
Buku ini telah dibuat dengan berbagai observasi, pencarian materi dan
beberapa bantuan dari berbagai pihak untuk membantu menyelesaikan buku
ini. Oleh karena itu, kami mengucapkan terimak kasih kepada semua pihak
yang telah membantu dalam penyusunan buku ini.
Kami menyadari bahwa masih banyak kekurangan yang mendasar pada buku
ini. Oleh karena itu kami mengundang pembaca untuk memberikan saran
serta kritik yang dapat membangun kami. Kritik konstruktif dari pembaca
sangat kami harapkan untuk penyempurnaan buku selanjutnya.
Akhir kata semoga buku ini dapat memberikan manfaat terhadap kita semua.
Daftar Isi
BAGIAN I
Kata Pengantar
Bab 1. Pendahuluan
1.1 Latar Belakang
1.2 Tujuan
1.3 Ruang Lingkup
Bagian II
Bab 2. Konsep Enterprise Unified Process
2.1 Pengertian Enterprise Unified Process
2.2 Penurunan pada Enterprise Unified Process
2.2.1 Pengertian Rational Unified Process
2.2.2 Sejarah Rational Unified Process
2.2.3 Keuntungan Rational Unified Process
Bagian III
Bab 3
3.1 Fase-fase Enterprise Unified Process
3.1.1 Inception
3.1.2 Elaboration
3.1.3 Construction
3.1.4 Transition
3.1.5 Production
3.1.6 Retirement
3.2 Praktik-praktik Enterprise Unified Process
Bagian IV
Bab 4 Contoh kasus fase-fase Enterprise Unified Process SMS Gateway
4.1 Inception
4.2 Elaboration
4.3 Construction
4.4 Transition
4.5 Production
4.6 Retirement
Bab 5 Penutup
5.1 Kesimpulan
DAFTAR PUSTAKA
2.2.2 Sejarah Rational Unified Process
2.2.3 Keuntungan Rational Unified Process
Bagian III
Bab 3
3.1 Fase-fase Enterprise Unified Process
3.1.1 Inception
3.1.2 Elaboration
3.1.3 Construction
3.1.4 Transition
3.1.5 Production
3.1.6 Retirement
3.2 Praktik-praktik Enterprise Unified Process
Bagian IV
Bab 4 Contoh kasus fase-fase Enterprise Unified Process SMS Gateway
4.1 Inception
4.2 Elaboration
4.3 Construction
4.4 Transition
4.5 Production
4.6 Retirement
Bab 5 Penutup
5.1 Kesimpulan
DAFTAR PUSTAKA
BAB 1
PENDAHULUAN
1.1 Latar Belakang
Enterprise
Unified Process (EUP) adalah perpanjangan varian dari Rasional Unified
Proses dan dikembangkan oleh Scott W. Ambler dan Larry Constantine pada
tahun 2000, terakhir dikerjakan ulang pada tahun 2005 oleh Ambler, John
Nalbone dan Michael Vizdos. EUP diperkenalkan untuk mengatasi beberapa
kekurangan dari RUP, yaitu kurangnya dukungan sistem dan akhir
penggunaan sistem software. Jadi dua fase dan beberapa disiplin ilmu
baru ditambahkan ke RUP.
1.2 Tujuan
Tujuan pelaksanaan ini adalah untuk memberikan panduan pembelajaran bagaimana, EUP merupakan implementasikan dalam suatu pengembangan perangkat lunak
1.3 Ruang Lingkup
Pengembangan aplikasi intranet potal dilakukan menggunakan metodologi Enterprise Unified Process (EUP) dengan menggunakan perangkat lunak Rational Enterprise Suite. Perangkat bantu yang digunakan adlah Rational Requisite Pro untuk menemukan dan mendokumentasikan kebuuhan user terhadap aplikasi yang akan dikembangkan dan Rational Rose untuk melakukan pengembangan kerangka aplikasi
2.1 Pengertian Enterprise Unified Process
Enterprise Unified Process (EUP) adalah perpanjangan varian dari Rasional Unified Proses dan dikembangkan oleh Scott W. Ambler dan Larry Constantine pada tahun 2000, terakhir dikerjakan ulang pada tahun 2005 oleh Ambler, John Nalbone dan Michael Vizdos.EUP diperkenalkan untuk mengatasi beberapa kekurangan dari RUP, yaitu kurangnya dukungan sistem dan akhir penggunaan sistem software. Jadi dua fase dan beberapa disiplin ilmu baru ditambahkan ke RUP. EUP melihat pengembangan perangkat lunak bukan sebagai kegiatan mandiri, tetapi tertanam dalam siklus hidup sistem (yang akan dibangun atau ditingkatkan atau diganti), Siklus hidup TI dari perusahaan dan organziation/bisnis adlah siklus hidup perusahaan itu sendiri. Ini berkaitan dengan pengembangan perangkat lunak dilihat dari sudut pandang pelanggan.
2.2 Penurunan pada Enterprise Unified Process
Rational Unified Process (RUP) merupakan suatu metode rekayasa perangkat lunak yang dikembangkan dengan mengumpulkan berbagai best practises yang terdapat dalam industri pengembangan perangkat lunak. Ciri utama metode ini adalah menggunakan use-case driven dan pendekatan iteratif untuk siklus pengembangan perankat lunak. Gambar dibawah menunjukkan secara keseluruhan arsitektur yang dimiliki RUP. RUP menggunakan konsep object oriented, dengan aktifitas yang berfokus pada pengembangan model dengan menggunakan Unified Model Language (UML). Melalui gambar dibawah dapat dilihat bahwa RUP memiliki, yaitu:
Tujuan pelaksanaan ini adalah untuk memberikan panduan pembelajaran bagaimana, EUP merupakan implementasikan dalam suatu pengembangan perangkat lunak
1.3 Ruang Lingkup
Pengembangan aplikasi intranet potal dilakukan menggunakan metodologi Enterprise Unified Process (EUP) dengan menggunakan perangkat lunak Rational Enterprise Suite. Perangkat bantu yang digunakan adlah Rational Requisite Pro untuk menemukan dan mendokumentasikan kebuuhan user terhadap aplikasi yang akan dikembangkan dan Rational Rose untuk melakukan pengembangan kerangka aplikasi
Dalam implementasi akan dikembangkan aplikasi intranet protal untuk
fullright indonesia sebagai model dan studi kasus dengan menggunakan RUP
dalam proses pengembangan aplikasi, Adapu ruang lingkup pengembang
Aplikasi intranet portal mencakup hal-hal sebagai :
- Pengembangan spesifikasi dan moldul aplikasi antar muka (interface) yang menjadi penghubung antar pengguna dengan infrastruktur dan sumber daya yang dimiliki Fulbright Indonesia.
- Pengembangan spesifikasi dan modul aplikasi perangkat bantu (tools) yang dapat diintegrasikan ke sistem seperti yang diperlukan oleh sistem.
- Pengembangan spesifikasi database yang diperlukan oleh sistem.
BAB 2
Konsep
Enterprise Unified Process
Enterprise Unified Process (EUP) adalah perpanjangan varian dari Rasional Unified Proses dan dikembangkan oleh Scott W. Ambler dan Larry Constantine pada tahun 2000, terakhir dikerjakan ulang pada tahun 2005 oleh Ambler, John Nalbone dan Michael Vizdos.EUP diperkenalkan untuk mengatasi beberapa kekurangan dari RUP, yaitu kurangnya dukungan sistem dan akhir penggunaan sistem software. Jadi dua fase dan beberapa disiplin ilmu baru ditambahkan ke RUP. EUP melihat pengembangan perangkat lunak bukan sebagai kegiatan mandiri, tetapi tertanam dalam siklus hidup sistem (yang akan dibangun atau ditingkatkan atau diganti), Siklus hidup TI dari perusahaan dan organziation/bisnis adlah siklus hidup perusahaan itu sendiri. Ini berkaitan dengan pengembangan perangkat lunak dilihat dari sudut pandang pelanggan.
2.2 Penurunan pada Enterprise Unified Process
2.2.1 Pengertian Rational Unified Process
Rational Unified Process (RUP) merupakan suatu metode rekayasa perangkat lunak yang dikembangkan dengan mengumpulkan berbagai best practises yang terdapat dalam industri pengembangan perangkat lunak. Ciri utama metode ini adalah menggunakan use-case driven dan pendekatan iteratif untuk siklus pengembangan perankat lunak. Gambar dibawah menunjukkan secara keseluruhan arsitektur yang dimiliki RUP. RUP menggunakan konsep object oriented, dengan aktifitas yang berfokus pada pengembangan model dengan menggunakan Unified Model Language (UML). Melalui gambar dibawah dapat dilihat bahwa RUP memiliki, yaitu:
- Dimensi pertama digambarkan secara horizontal. Dimensi ini mewakili aspek-aspek dinamis dari pengembangan perangkat lunak. Aspek ini dijabarkan dalam tahapan pengembangan atau fase. Setiap fase akan memiliki suatu major milestone yang menandakan akhir dari awal dari phase selanjutnya. Setiap phase dapat berdiri dari satu beberapa iterasi. Dimensi ini terdiri atas Inception, Elaboration, Construction, dan Transition.
- Dimensi kedua digambarkan secara vertikal. Dimensi ini mewakili aspek-aspek statis dari proses pengembangan perangkat lunak yang dikelompokkan ke dalam beberapa disiplin. Proses pengembangan perangkat lunak yang dijelaskan kedalam beberapa disiplin terdiri dari empat elemen penting, yakni who is doing, what, how dan when. Dimensi ini terdiri atas
Business Modeling, Requirement, Analysis and Design, Implementation,
Test, Deployment, Configuration dan Change Manegement, Project
Management, Environtment.
Pada penggunaan kedua standard tersebut diatas yang berorientasi obyek (object orinted) memiliki manfaat yakni:
- Improve productivity Standard ini dapat memanfaatkan kembali komponen-komponen yang telah tersedia/dibuat sehingga dapat meningkatkan produktifitas
- Deliver high quality system Kualitas sistem informasi dapat ditingkatkan sebagai sistem yang dibuat pada komponen¬komponen yang telah teruji (well-tested dan well-proven) sehingga dapat mempercepat delivery sistem informasi yang dibuat dengan kualitas yang tinggi.
- Lower maintenance cost Standard ini dapat membantu untuk menyakinkan dampak perubahan yang terlokalisasi dan masalah dapat dengan mudah terdeteksi sehingga hasilnya biaya pemeliharaan dapat dioptimalkan atau lebih rendah dengan pengembangan informasi tanpa standard yang jelas.
- Facilitate reuse Standard ini memiliki kemampuan yang mengembangkan komponen-komponen yang dapat digunakan kembali untuk pengembangan aplikasi yang lainnya.
- Manage complexity Standard ini mudah untuk mengatur dan memonitor semua proses dari semua tahapan yang ada sehingga suatu pengembangan sistem informasi yang amat kompleks dapat dilakukan dengan aman dan sesuai dengan harapan semua manajer proyek IT/IS yakni deliver good quality software within cost and schedule time and the users accepted.
Dari gambar diatas, terlihat ada sembilan core process workflow dalam
RUP. Semuanya merepresentasikan pembagian worker dan activities ke dalam
logical grouping. Ada dua bagian utama yaitu process workflows dan
supporting workflows. Dalam process workflows terdapat Bussiness
modeling yang didalamnya dibuat dokumen bussiness process yang dipakai
disebut bussiness use cases. Dokumen ini menjamin stakeholder memahami
kebutuhan bisnis proses yang diperlukan.
Tujuan dari requirement workflow adalah mendeskripsikan ‘what’/apa yang
harus dikerjakan oleh sistem serta membolehkan developer dan costumer
untuk menyetujui deskripsi itu. Analysis&Design workflows bertujuan
untuk menunjukkan ‘how/bagaimana merealisasikan sistem dalam tahap
implementasi. Didalamnya kita akan menemukan problem domain juga solusi
dari problem yang mungkin akan muncul dalam sistem. Hasil yang diberikan
pada tahapan ini adalah design model sebagai ‘blueprint’ dari source
code yang akan dibuat dan juga analysis model (optional). Implementation
workflow bertujuan untuk mengimplementasikan classes dan objects dalam
hubungannya dengan component, mengetest component yang dihasilkan
sebagai unit, dan untuk mengintegrasikan hasil yang dibuat oleh
masing-masing implementer/teams ke dalam executable system. RUP
menjelaskan bagaimana kita me-reuse exiting complements atau
me-implement new component sehingga membuat sistem mudah dibangun dan
meningkatkan kemungkinan untuk me-reusenya. Test workflow bertujuan
untuk memeriksa interaksi antar objek, penggabungan component dari
software dengan tepat, dan memeriksa apakah semua kebutuhan sudah
dipenuhi dengan tepat. Selain itu, test bertujuan untuk
mengidentifikasikan dan meyakinkan bahwa kerusakan yang ada telah
diatasi sebelum men-deploy software.
RUP menawarkan pendekatan iterative yang memungkinkan kita mengetest
keseluruhan project dengan menemukan kerusakan sejak dini sehingga
mengurangi cost untuk memperbaikinya. Test menghasilkan tiga macam
ukuran qualitas yaitu reliability, functionality, application dan system
performance. Deployment workflow dilakukan untuk menghasilkan product
release dengan sukses dan aktifitas mengantar software kepada end user
seperti membuat external releases dari software ,packing software,
distributing software, installing software, serta membantu user memahami
sistem. Aktifitas ini dilakukan pada fase transition. Dalam RUP,
deployment workflow berisi paling sedikit detailnya daripada workflow
yang lain. Project management menyediakan framework untuk mengatur
software-intensive projects, panduan untuk planning, staffing,
executing, dan monitoring projects, dan framework untuk mengatur resiko
yang ada. Dikatakan sukses apabila produk tersebut dapat memenuhi
kebutuhan user dan kebanyakan customer.
Configuration and change management menyediakan panduan untuk mengatur
penyusunan software systems, mengatasi perubahan request management, dan
dapat menjadi salah satu cara untuk melaporkan suatu kerusakan.
Environment bertujuan menyediakan software development organization
beserta software development environment, yang dibutuhkan untuk
mendukung development team. Seperti yang kita tahu dalam software
development, tujuan yang akan diraih adalah membangun/meningkatkan
sebuah software sesuai dengan kebutuhan (Bussiness Process). Sedangkan
sebuah proses disebut efektif jika menetapkan sebuah garis pedoman yang
menjamin kualitas software yang dibangun, mengurangi resiko dan
meningkatkan perkiraan kepada masalah yang mungkin muncul, serta
menggunakan best practise. Rational Unified Process menawarkan dan
menjelaskan penerapan six best practise yang efektif pada software
development, diantaranya adalah :
- Develop Software Iteratively Pendekatan secara iterative digunakan untuk mengurangi resiko yang dapat terjadi selama lifecycle. Setiap akhir iterasi akan diperoleh executable release yang memungkinkan keterlibatan end user dan feedback yang diberikan secara terus-menerus. Pendekatan ini juga mepermudahkan penyesuaian perubahan kebutuhan, features, maupun jadwalnya.
- Manage Requirements Rational Unified Process mendeskripsikan bagaimana mendapatkan, mengorganisasikan, dan mendokumentasikan fungsionalitas dan batasan yang dibutuhkan. Sehingga akan memudahkan dalam memahami dan mengkomunikasikan kebutuhan bisnis.
- Use Component-based Architecture RUP menggunakan pendekatan sistematis dalam mendefinisikan arsitektur yang menggunakan component. Karena memang proses yang dilakukan difokuskan pada awal pembangunan sebuah software. Dalam proses ini akan mendeskripsikan bagaimana menyusun arsitektur yang fleksibel, mudah dipahami, dan mengembangkan efektif software reuse.
- Visually Model Software Proses yang dilakukan menunjukkan bagaimana memvisualisasikan model yang mencakup struktur dan kelakuan dari arsitektur dan komponen.
- Verify Software Quality Application perfoemance dan kemampuan tahan uji yang buruk dapat menghalangi diterimanya sebuah aplikasi software. Sehingga diperlukan penelaahan lebih lanjut tentang kualitas software dengan mematuhi kebutuhan aplikasi berdasarkan kemampuan tahan uji, fungsionalitas, application performance, dan system performance.
- Control Changes to Software Proses akan mendeskripsikan bagaimana mengontrol dan memonitor perubahan untuk kesuksesan iterative development. Selain itu, proses juga akan memandu kita bagaimana menyusun workspace yang aman bagi para developer dengan mengisolasi perubahan yang dilakukan di workspace lain dan dengan mengontrol perubahan pada seluruh software artifact. Sehingga membuat team bekerja sebagai unit tersendiri dengan mendeskripsikan bagaimana mengintegrasikan dan membangun management secara otomatis.
RUP sebagai architecture-centric. Architeture ini merupakan fokus yang
dibahas pada fase elaboration yang akan dibahas pada bagian lain makalah
ini. Software architecture design merupakan artifact dasar yang
diperoleh dari sebuah architecture. Artifact lain yang diperoleh dari
sebuah architecture ini diantaranya dapat membuat garis pedoman desain
yang dipakai, struktur produk, dan team structure. Dalam
merepresentasikan sebuah architecture pada software development kita
menggunakan yang disebut The 4+1 view model yang telah kita kenal saat
mempelajari UML. View model itu terdiri dari : logical view (dipakai
oleh analyst/designer), implementation view (dipakai oleh progammer),
process view (dipakai oleh system integrator), dan deployment view
(dipakai oleh system engineering), serta ditambah dengan use case view
(dipakai oleh end user). Keuntungan dari architecture centric process
diantaranya memperbolehkan kita untuk menambah dan menambah intellectual
control sebuah proyek untuk mengatur kompleksitas dan membangun system
integrity. Proses arsitektur ini memiliki lifecycle phase, yang terdiri
dari inception phase, elaboration phase, construction phase, dan
transition phase. Setiap fase yang ada dihubungkan dengan milestone,
yaitu suatu point evaluasi dari suatu tahap fase yang sudah selesai
dibuat,
RUP merupakan produk proses perangkat lunak yang awalnya dikembangkan
oleh Rational Software. Rational Software diakuisisi oleh IBM pada
Februari 2003. Produk ini memuat basis-pengetahuan yang bertautan dengan
artefak sederhana disertai deskripsi detail dari beragam aktivitas. RUP
dimasukkan dalam produk IBM Rational Method Composer (RM C) yang
memungkinkan untuk kustomisasi proses. Dengan mengombinasikan pengalaman
dari banyak perusahaan, dihasilkan enam praktik terbaik untuk rekayasa
perangkat lunak modern: Pengembangan iteratif, dengan risiko sebagai
pemicu iterasi primer Kelola persyaratan Terapkan arsitektur yang
berbasis komponen Visualisasikan model perangkat lunak Secara kontinyu,
verifikasi kualitas Kendalikan perubahan.
Keuntungan yang didapat dengan menggunakan pendekatan iterasi
diantaranya adalah : mengurangi resiko lebih awal, perubahan yang
dilakukan lebih mudah diatur, higher level of reuse, project team
memiliki waktu lama untuk memahami sistem yang akan dibangun, dan
menghasilkan kualitas yang lebih baik di segala aspek.
RUP menawarkan berbagai kemudahan dalam membangun sebuah sotfware, ada yang disebut Six Best Practices yang terdiri dari :
- Develop Iteratively
- Manage Requirement
- Use Component-based Architecture
- Model Visually
- Verify Quality
- Control Changes to software
Semua proses yang dilakukan oleh RUP akan memberikan keuntungan pada
tahapan membangun sebuah software. Saat melakukan perancangan sebuah
perangkat lunak, tentunya setiap tahapan akan mendapatkan masalah.
Biasanya gejala/symptom yang menunjukkan ada masalah dalam proses
perancangan software seperti berikut :
- Ketidak akuratan dalam memahami kebutuhan end-user.
- Ketidakmampuan untuk menyetujui perubahan kebutuhan yang diajukan.
- Modul-modul yang dibutuhkan tidak dapat dihubungkan.
- Software yang sulit untuk dibangun atau diperluas.
- Terlambat menemukan kerusakan project yang serius.
- Kualitas software yang buruk.
- Kemampuan software yang tidak dapat diterima.
Team members yang bekerja sendiri-sendiri sulit untuk mengetahui
perubahan yang telah dilakukan karena ada perbedaan dalam membangun
software tersebut. Ada ketidakpercayaan dalam membangun dan me-release
proses. Usaha untuk menghilangkan symptom ini tidak akan menyelesaikan
masalah yang dihadapi software developer karena gejala ini dapat terjadi
oleh adanya penyebab utama masalah yang timbul saat membangun sebuah
sistem, yaitu :
- Requirement management yang tidak mencukupi
- Komunikasi yang ambigu dan tidak tepat
- Arsitektur yang rapuh
- Kompleksitas yang sangat besar
- Tidak terdeteksinya ketidakkonsistenan antara requirement,desain, dan implementasi
Pengetesan yang tidak mencukupi
- Penilaian status project yang subjektif
- Keterlambatan pengurangan resiko yang disebabkan waterfall development
- Perkembangan yang tidak terkontrol
- Otomatisasi yang kurang
Semua hambatan yang ditemui saat membangun software akan dapat diatasi
dengan menggunakan best practise yang telah disebutkan di awal
pembahasan. Dengan menggunakan best practise yang diterapkan oleh
Rational Unified Process, akar masalah yang menyebabkan timbulnya
symptom dalam software developer akan teratasi dengan baik.
Sebelum kita membahas lebih dalam mengenai Rational Unified Process,
kita perlu untuk mengetahui terlebih dahulu apa maksud dari proses itu
sendiri. Proses merupakan suatu tahapan yang mendefinisikan siapa yang
mengerjakan apa, kapan dan bagaimana meraih suatu tujuan yang pasti. RUP
merepresentasikan empat elemen dasar untuk memodelkan pertanyaan yang
muncul dari sebuah proses, yaitu workers, activities, artifacts, dan
workflows.
Worker mendefinisikan behavior/kelakuan dan responsibilities dari
seseorang atau sebuah team. Dalam Unified Process, worker lebih
diartikan sebagai bagaimana team/individual seharusnya bekerja.
Sedangkan tanggungjawab bagi worker adalah melakukan serangkaian
aktifitas sebagai pemilik dari sekumpulan artifact.
Activity dari spesific worker adalah sebuah unit kerja yang dilakukan
seorang individu. Tujuannya cukup jelas,yaitu membuat/meng-update
artifact. Setiap activity diberikan kepada spesific worker dan harus
dapat digunakan sebagai elemen dalam planning dan progress software
development. Contoh activity diantaranya : merencanakan sebuah iteration
untuk worker Project Manager, menemukan use case dan aktor untuk worker
System Analyst, dan sebagainya.
Artifact merupakan sekumpulan informasi yang dihasilkan, diubah, dan
dipakai dalam sebuah proses. Artifact digunakan sebagai input bagi
worker untuk melakukan activity dan juga sebagai output dari activity.
Dalam object-oriented design, activities adalah operasi yang dilakukan
aktif object(worker) sedangkan artifact sebagai parameter dari
activities tersebut. Contoh artifact yaitu: model (uses case model),
document,source code,dan lain-lain.
Workflow adalah serangkaian activities yang menghasilkan nilai hasil
yang dapat terlihat. Dalam UML, workflow digambarkan dengan sequence
diagram, collaboration diagram, atau activity diagram. Workflow tidak
selalu dapat dipakai untuk merepresentasikan semua ketergantungan yang
ada diantara activities. Karena,terkadang dua buah activities yang
digambarkan dalam workflow sebenarnya sangat rapat jalinannya yang
melibatkan worker yang sama padahal mungkin penggambarannya tidak
terlalu tepat.
3.1.1 Inception
3.1.2 Elaboration
Tahap untuk menentukan use case (set of activities) dari perangkat lunak berikut rancangan arsitekturnya.
3.1.3 Construction
Membangun produk perangkat lunak secara lengkap yang siap diserahkan kepada pemakai.
3.1.4 Transition
Menyerahkan perangkat lunak kepada pengguna, mengujinya ditempat pengguna, dan memperbaiki masalah-masalah yang muncul saat dan setelah pengujian.
3.1.5 Production
Selama fase ini, anda akan mempertahankan proyek, artinya dengan menjalankan usaha komunikasi, kemudian melanjutkan pelatihan dan pengjaran, dan melanjutkan pengaturan dari proses yang akan anda pelajari.
3.1.6 Retirement
Dalam fase ini terdapat pemindahan data dan sistem integrasi yang baik
4.2 ELABORATION
4.3 Construction
4.4 Transition
4.5 Production
BAB 3
3.1 Fase-Fase Enterprise Unified Process
Tahap inception fokus pada penentuan manfaat perangkat lunak yang harus
dihasilkan, penetapan proses-proses bisnis (business case), dan
perencanaan proyek.
- Menentukan Ruang lingkup proyek
- Membuat ‘Business Case’
- Menjawab pertanyaan “apakah yang dikerjakan dapat menciptakan ‘good business sense’ sehingga proyek dapat dilanjutkan
3.1.2 Elaboration
Tahap untuk menentukan use case (set of activities) dari perangkat lunak berikut rancangan arsitekturnya.
- Menganalisa berbagai persyaratan dan resiko
- Menetapkan ‘base line’
- Merencanakan fase berikutnya yaitu construction
3.1.3 Construction
Membangun produk perangkat lunak secara lengkap yang siap diserahkan kepada pemakai.
- Melakukan sederetan iterasi
- Pada setiap iterasi akan melibatkan proses berikut: analisa desain, implementasi dan testing
3.1.4 Transition
Menyerahkan perangkat lunak kepada pengguna, mengujinya ditempat pengguna, dan memperbaiki masalah-masalah yang muncul saat dan setelah pengujian.
- Membuat apa yang sudah dimodelkan menjadi suatu produk jadi
- Dalam fase ini dilakukan: Beta dan performance testing; Membuat dokumentasi tambahan seperti training, user guides, dan sales kit; Membuat rencana peluncuran produk ke komunitas pengguna
3.1.5 Production
Selama fase ini, anda akan mempertahankan proyek, artinya dengan menjalankan usaha komunikasi, kemudian melanjutkan pelatihan dan pengjaran, dan melanjutkan pengaturan dari proses yang akan anda pelajari.
3.1.6 Retirement
Dalam fase ini terdapat pemindahan data dan sistem integrasi yang baik
3.2 Praktik Praktik Enterprise Unified Process
- Mengembangkan iteratif
- Mengelola persyaratan
- Arsitektur Pembtuktian
- Modeling/Perancangan
- Memverifikasi kualitas secara terus-menerus
- Mengelola perubahan
- Pembangunan Berkolaborasi
- Melihatlah pencapaian pembangunan
- Memberikan perangkat lunak bekerja secara teratur
- Mengelola risiko
BAB 4
Contoh kasus fase-fase Enterprise Unified Process SMS Gateway
4.1 Inception
Mendefinisikan Ruang Lingkup
Deskripsi Proses Bisnis
Sistem SMS Gateway Akademik ini dibuat untuk membantu menangani layanan
informasi akademik yang bersifat “mobile” untuk mahasiswa dengan
memanfaatkan fasilitas SMS. SMS Gateway Akademik ini diperuntukkan bagi :
- Mahasiswa, untuk melihat informasi yang terkait dengan kegiatan akademisnya, seperti status registrasi, jadwal kuliah, jadwal ujian, nilai UTS, nilai UAS, IP, IPK dan info umum seperti seminar.
- Calon mahasiswa baru, untuk mengetahui kelulusan setelah ujian saringan masuk.
Develop Business Use Case
Business Object Model
Business Object Model Administrasi Sistem
Business Object Model Kelola Info
4.3 Business Object Model Lihat Informasi
Perangkat Keras
- Personal Computer (PC), dengan spesifikasi minimal:
- Processor : Intel Pentium III 800Mhz
- Memory : SDR 256MB
- Serial port : COM 1 (standar RS232)
- Hardisk: 1GB GSM modem/Handphone sebagai alat komunikasi, penghubung PC dengan pengirim data.
Sistem Operasi
Sistem operasi yang digunakan minimal berjalan pada Windows 98.
DBMS
DBMS yang digunakan adalah MySQL Server 4.0.18
Tools
Tools yang digunakan untuk membangun perangkat lunak adalah bahasa pemrograman Java (Java 2 SDK 1.4)
Kebutuhan Fungsionl
| Ref | Fungsi |
| R.1.1 | Melakukan koneksi perangkat lunak dengan database |
| R.1.2 | Melakukan set terminal yang menghubungkan PC dengan handphone (pada sistem SMS gateway) |
| R.1.3 | Menangani konversi pemrosesan PDU menjadi format teks sehingga didapat no telepon dan pesan (SMS terima) |
| R.1.4 | Menangani konversi no telepon tujuan dan pesan (format teks) ke format PDU (SMS kirim) |
| R.1.5 | Menangani pemeriksaan respon dari terminal (SMS masuk dan SMS belum terbaca) |
| R.1.6 | Menangani penghapusan SMS yang telah dibaca pada handphone (sistem) |
| R.1.7 | Menangani penyimpanan data SMS yang diterima (log SMS diterima) |
| R.1.8 | Menangani penyimpanan data SMS yang belum/ sudah dikirim (log SMS kirim, hasil pemrosesan) |
| R.1.9 | Melakukan parsing pesan SMS yang masuk (parameter parsing adalah spasi) |
| R.1.10 | Menentukan isi SMS balasan, yang didapat dari hasil pemrosesan(query) hasil parsing SMS |
| R.1.11 | Mengirimkan SMS yang belum dikirim |
Sequence Diagram
Sequence diagram adalah salah satu bentuk interaction diagram yang mengambarkan proses terjadinya sesuatu.
Sequence Diagram Terima SMS
Sequence Diagram proses SMS masuk
Sequence Diagram kirim balasan
Sequence Diagram Insert Info umum
Sequence Diagram Edit/ Delete Info umum
Sequence Diagram lihat Log Terima/ Log Kirim
Sequence Diagram Start Up
Sequence Diagram ShutDown
Rancangan Interface
Basis Data
Rancangan Deployment
Lingkungan Operasional Sistem
Black Box Testing
Operate systemà SMS Gateway telah dioperasikan di Universitas
Muhammadiyah sebagai layanan akademik Support Systemà Mensupport sistem
SMS Gateway Memanage permintaan perubahanà Apabila ada
perubahan-perubahan fitur.
Memonitor sistem : Dengan memberikan perawatan terhadap sistem maupun
dokumen perawatannya Saran-saran perawatan sistem : Untuk menjaga sistem
tetap berjalan stabil dan benar, admin bisa melakukan hal-hal berikut:
Periksa baterai handphone jangan sampai habis, jika terminal yang
dipilih adalah handphone.
Jika terjadi kegagalan hubungan dengan terminal,
- periksa kabel data, terhubung dengan port mana (COM1/COM2), karena sistem melakukan koneksi dengan COM1.
- periksa setting baud rate, pilih dalam menu handphone, set menjadi 19200. Menyiapkan dan recover dari kerusakan
4.6 Retirement
Migrasi Data
- Memindahkan data dari M.Access ke MySQL
Removal System
- Mengubah sistem Operasi Windows 98 ke Windows XP
BAB 5
PENUTUP
5.1 KESIMPULAN
RUP (Rational Unified Process) merupakan suatu Software engineering
process hasil kerja awal dari “Three Amigos” –Ivar Jacobson, Grady
Booch, dan James Rumbaugh- yang bertujuan untuk memastikan kualitas yang
terbaik pada suatu produksi software dengan memperkirakan jadwal dan
biaya yang harus dikeluarkan. RUP merupakan process product dari
Rational® Software dengan konsep utamanya adalah tentang model, workflow
dan workers, serta tentang phase dan iterasi.
Enterprise Unified Process (EUP) adalah perpanjangan varian dari
Rasional Unified Proses dan dikembangkan oleh Scott W. Ambler dan Larry
Constantine pada tahun 2000, terakhir dikerjakan ulang pada tahun 2005
oleh Ambler, John Nalbone dan Michael Vizdos. EUP diperkenalkan untuk
mengatasi beberapa kekurangan dari RUP, yaitu kurangnya dukungan sistem
dan akhir penggunaan sistem software. Jadi dua fase dan beberapa
disiplin ilmu baru ditambahkan ke RUP.
Daftar Pustaka
[1] Beck, Kent. Extreme Programming Explained: Embrace Change. Addison-Wesley,1999.
[2] Satzinger, John, et al. 2007 System Analys and Design, 5th Ed., Thomson Course tech., Canada.
[3]
[EUP 2005] Enterprise Unified Process: Extending the Rational Unified
Process by Scott W. Ambler, John Nalbone, and Michael Vizdos, published
Prentice Hall PTR
[4] http://www.enterpriseunifiedprocess.com/
[5] http://aelinik.free.fr/cmm/tr25_l4a.html
[6] http://www.enterpriseunifiedprocess.com/essays/zachmanFramework.html
[7] http://yulianfindawati.blogspot.com/
[8] http://aih25.blogspot.com/2013/03/rup-rational-unified-process.html
0 komentar:
Posting Komentar