Labels

RSS

Cara membuat project android

Apa yang kita butuhkan untuk melakukan pemrograman Android?

1. Pengetahuan Object Oriented Programming, khususnya Java
Android menggunakan Dalvik Virtual Machine untuk menjalankan program APK yang terinstall. Dalvik yang di-modifikasi google dibuat berdasarkan Java Virtual Machine milik Sun/ Oracle. Itulah sebabnya untuk membuat program untuk android, kita menggunakan Java sebagai cara yang paling mudah. Bagi yang punya pengalaman pemrograman C, bisa menggunakan Android NDK, hasilnya lebih cepat karena bersifat native, tapi rumitnya minta ampun.
2. Internet
3. PC, Minimal RAM 1 GB, disarankan 2GB, supaya cepat saat menjalankan emulator.
4. Kartu kredit, karena saat kita ingin memasukkan aplikasi ke Android Market, kita harus membayar US$ 25 dengan Kartu Kredit di http://market.android.com/publish
5. Program yang akan kita gunakan:
a. Java Development Kit, agar kita bisa menjalankan Eclipse. Download dari:
http://www.oracle.com/technetwork/java/javase/downloads/index.html
b. Eclipse
http://www.eclipse.org/downloads/,  pilih Eclipse IDE for Java Developers
c. Android SDK
Library untuk membuat program Android. Download dari:
http://developer.android.com/sdk/index.html
d. Plugin ADT untuk Eclipse, fungsinya untuk menghubungkan Eclipse dengan Android SDK, sehingga Eclipse yang sebelumnya editor java bisa digunakan untuk editor program android. Bisa download disini:
http://developer.android.com/sdk/eclipse-adt.html,   atau bisa ikuti langkah install langsung dari Eclipse nanti.
Agar lebih mudah, install program tersebut di satu buah folder, misalkan di D:\Java\
Cara instalasi:
1. Install Java Development Kit
2. Install eclipse, misalkan ke D:\Java\eclipse-java-indigo-win32, kemudian:
- Jalankan untuk pertama kali
- Pilih workspace, kemudian klik default
- Tutup tab welcome yang ada, maka kita sudah bertemu dengan antar muka Eclipse IDE
3. Install Android SDK, kemudian:
a. Buka folder Android SDK
b. Klik program SDK Manager
c. Klik bagian Available packages
d. Kita akan menggunakan SDK Froyo, karena versi ini paling banyak digunakan HP saat ini. Maka minimal yg dipilih adalah:
- SDK Platform Android 2.2, API 8, revision paling baru
- Samples for SDK API 8
- Google APIs, Adndroid API 8
- Android SDK Tools
- Android SDk Platform-tools
e. Kemudian install selected
f. Setelah selesai, hasilnya ada di Installed packages

4. Masih di bagian SDK Manager, kita buat emulator. Gunanya untuk mencoba hasil program yang kita buat, tanpa perlu dicoba di HP langsung

- klik virtual devices
- klik New…
- Beri nama, pilih target dengan Android 2.2, API 8
- SD Card Size, dibuat kecil, misalkan 16 MB
- Skin, pilih built-in, yang kecil saja, misalkan resolusi WQVGA400
- Kemudian Create AVD
- Setelah jadi, pilih device tadi, Klik start. Maka tampilan seperti HP Android akan keluar
5. Install Plugin ADT di Eclipse. Caranya:
a. klik Help > Install New Software….
b. klik Add, masukkan ini di bagian Location:
https://dl-ssl.google.com/android/eclipse/
klik OK
Atau,apabila kita tidak punya koneksi internet langsung, kita bisa mendownload ADT terlebih dahulu dihttp://developer.android.com/sdk/eclipse-adt.html. Pilih archive, kemudian pilih file zip hasil kita download.
c. Pilih semua Development Tools yang ada
d. Klik Next, dan Accept TOS yang ada
e. Finish, Tunggu sampai selesai download
f. Setelah menutup dan membuka kembali, akan keluar gambar android di toolbar
6. Menghubungkan Android SDK dengan Eclipse
a. Klik window, Android SDK & AVD Manager
b. Jangan centang send usage, klik Proceed
c. Buka window -> preferences
d. Pilih bagian Android
e. Browse SDk Location, Kemudian pilih folder tempat Android SDK, Apply
f. Setelah keluar jenis Android SDK yang terinstall, klik OK
g. Sekarang coba klik icon android di toolbar eclipse, AVD manager kita akan terpanggil

Kalau sudah beres, kita bisa mencoba membuat aplikasi :P
1. New, Project…
2. Android, Android Project
Project Name: WebsiteLoader
Build Target: Android 2.2
Package Name: us.om4g.WebsiteLoader
3. Finish
4. Coba Run sebagai Android Application

sumber


  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Apa itu RUP?



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.
Aktifitas yang dilakukan oleh Rational Unified Process adalah membuat dan memelihara  model. RUP juga meliputi pembahasan dari implementasi UML (Unified Modelling Language)  secara luas dan memfokuskan dirinya pada software yang memiliki metodologi berorientasi objek. Sehingga dapat kita bedakan dengan UML bahwa RUP merupakan sebuah proses yang dilakukan dalam rekayasa perangkat lunak sedangkan UML adalah bahasa standar yang digunakan untuk memvisualisasikan, mendeskripsikan, membangun, dan mendokumentasikan perangkat yang akan digunakan dalam membangun sebuah perangkat lunak. RUP dibutuhkan sebagai pedoman untuk menggunakan UML secara efektif. Sedangkan UML berfungsi sebagai standardisasi notasi yang berorientasi objek untuk mengkomunikasikan kebutuhan/requirement, architectures, dan desain secara jelas dengan user. Oleh karena itu, hubungan antara RUP dan UML sangatlah dekat.
Aktifitas yang dilakukan dalam Software development merupakan sebuah pekerjaan team. Karena perubahan teknologi yang cepat sehingga memerlukan spesialisasi tertentu dalam pelaksanaannya.  Produktivitas team ini dapat ditingkatkan dengan menggunakan RUP dalam mendukung pembangunan sebuah software. Mengapa? Karena setiap anggota team akan dibekali oleh pengetahuan dasar yang sama mengenai guidelines dan template dalam aktifitas software development, sehingga saat membangun sebuah sistem akan dijamin bahwa setiap anggota team akan menggunakan bahasa yang sama untuk merepresentasikan requirement yang diminta user. Jika telah ada standar yang digunakan dalam proses pembangunan sebuah software, diharapkan dapat mengoptimalkan hasil yang diperoleh. 
D
alam membangun sebuah software, kita membutuhkan tahapan-tahapan yang harus dipenuhi selama proses men-develop software.  Tahapan yang harus dilalui itu dapat kita gambarkan sebagai berikut :

Semua tahapan tersebut dapat dilalui dengan berbagai metode. Salah satu metode yang biasa digunakan adalah Waterfall workflow. Diagramnya adalah sebagai berikut :
 


Namun dengan metode ini dirasakan kurang efektif karena membutuhkan lebih banyak cost sampai menghasilkan sistem yang baik. Hal ini dapat terjadi karena modul yang ada dalam sistem tidak dibagi-bagi terlebih dahulu dalam pengujian software.  Masalah ini dapat diatasi dengan menggunakan metode iteration incremental yang membagi modul-modul sehingga kesalahan dapat diatasi sejak dini. Metode ini yang digunakan dalam RUP.


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. Yang akan kita bahas di bagian lain dari makalah ini.
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.
 

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Apa itu RUP?



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.
Aktifitas yang dilakukan oleh Rational Unified Process adalah membuat dan memelihara  model. RUP juga meliputi pembahasan dari implementasi UML (Unified Modelling Language)  secara luas dan memfokuskan dirinya pada software yang memiliki metodologi berorientasi objek. Sehingga dapat kita bedakan dengan UML bahwa RUP merupakan sebuah proses yang dilakukan dalam rekayasa perangkat lunak sedangkan UML adalah bahasa standar yang digunakan untuk memvisualisasikan, mendeskripsikan, membangun, dan mendokumentasikan perangkat yang akan digunakan dalam membangun sebuah perangkat lunak. RUP dibutuhkan sebagai pedoman untuk menggunakan UML secara efektif. Sedangkan UML berfungsi sebagai standardisasi notasi yang berorientasi objek untuk mengkomunikasikan kebutuhan/requirement, architectures, dan desain secara jelas dengan user. Oleh karena itu, hubungan antara RUP dan UML sangatlah dekat.
Aktifitas yang dilakukan dalam Software development merupakan sebuah pekerjaan team. Karena perubahan teknologi yang cepat sehingga memerlukan spesialisasi tertentu dalam pelaksanaannya.  Produktivitas team ini dapat ditingkatkan dengan menggunakan RUP dalam mendukung pembangunan sebuah software. Mengapa? Karena setiap anggota team akan dibekali oleh pengetahuan dasar yang sama mengenai guidelines dan template dalam aktifitas software development, sehingga saat membangun sebuah sistem akan dijamin bahwa setiap anggota team akan menggunakan bahasa yang sama untuk merepresentasikan requirement yang diminta user. Jika telah ada standar yang digunakan dalam proses pembangunan sebuah software, diharapkan dapat mengoptimalkan hasil yang diperoleh. 
D
alam membangun sebuah software, kita membutuhkan tahapan-tahapan yang harus dipenuhi selama proses men-develop software.  Tahapan yang harus dilalui itu dapat kita gambarkan sebagai berikut :

Semua tahapan tersebut dapat dilalui dengan berbagai metode. Salah satu metode yang biasa digunakan adalah Waterfall workflow. Diagramnya adalah sebagai berikut :
 


Namun dengan metode ini dirasakan kurang efektif karena membutuhkan lebih banyak cost sampai menghasilkan sistem yang baik. Hal ini dapat terjadi karena modul yang ada dalam sistem tidak dibagi-bagi terlebih dahulu dalam pengujian software.  Masalah ini dapat diatasi dengan menggunakan metode iteration incremental yang membagi modul-modul sehingga kesalahan dapat diatasi sejak dini. Metode ini yang digunakan dalam RUP.


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. Yang akan kita bahas di bagian lain dari makalah ini.
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.
 

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Apa itu SDLC

0Share

Apa Itu SDLC

SDLC (Software Development Life Cycle) berarti sebuah siklus hidup pemngembangan perangkat lunak yang terdiri dari beberapa tahapan-tahapan yang sangat penting dalam keberadaan perangkat lunak yang dilihat dari segi pengembangannya.

Tahapan SDLC
SDLC terdiri dari beberapa tahapan-tahapan berdasarkan analisa kebutuhan yang ada . Dimulai dari analisa kebutuhan perangkat lunak akan dibuat terlebih dahulu desain dari kebutuhan tersebut untuk mempermudah dalam pengerjaannya. Kemudian segala kebutuhan tersebut di implementasikan dengan dua tahap yaitu tahap analisa dan tahap evaluasi (User Acceptance Test). Setelah melakukan implementasi, maka proses tersebut akan dikembalikan kembali ke dalam tahap desain untuk pengembangan kembali perangkat lunak ke versi yang terbaru.
Proses Tahapan SDLC yang paling sering digunakan adalah :
1. Perencanaan:
Mempelajari konsep sistem dan permasalahan yang hendak diselesaikan. apakah sistem baru tersebut realistis dalam masalah pembiayaan, waktu, serta perbedaan dengan sistem yang ada sekarang.
2. Analisis Sistem:
Menganalisis konsep sistem, permasalahan dan keperluan yang hendak dibuat.
  1. Desain :
Mendesain sistem teknologi baru untuk permasalahan yang sama.
4 Konstruksi :
Perbaikan terhadap produk yang memiliki kesalahan/kerusakan
5 Implementasi
software yang telah diuji dan siap diimplementasikan kedalam sistem pengguna/ sudah siap diterapkan.
6 Maintenance:
sistem yang telah diimplemantasikan serta dapat mengikuti perkembangan dan perubahan apapun yang terjadi guna meraih tujuan penggunaannya
Kegunaan SDLC
Adapun kegunaan utama dari SDLC adalah mengakomodasi beberapa kebutuhan. Kebutuhan-kebutuhan itu biasanya berasal dari kebutuhan pengguna akhir dan juga pengadaan perbaikan sejumlah masalah yang terkait dengan pengembangan perangkat lunak. Kesemua itu dirangkum pada proses SDLC yang dapat berupa penambahan fitur baru (baca : kemampuan penggunaan) baik itu secara modular (baca : instalasi parsial atau update dan upgrade perangkat lunak) maupun dengan proses instalasi baru (baca : penggantian perangkat lunak menyeluruh atau software replacement). Dari proses SDLC juga berapa lama umur sebuah perangkat lunak dapat diperkirakan untuk dipergunakan yang dapat diukur atau disesuaikan dengan kebijakan dukungan (baca : software support) dari pengembang perangkat lunak terkait.
Implementasi SDLC
Secara sederhana proses implementasi SDLC dapat dilihat dari penamaan sebuah perangkat lunak - sebagai contoh berikut :
  • Sebuah aplikasi contoh “ABCDE” versi 1.0 {alpha|beta|STABLE|i386|x64}, dapat diartikan bahwa aplikasi contoh “ABCDE” tersebut dipublikasikan dalam tahap awal yang ditandai dengan label versi 1.0 atau biasanya disingkat dengan huruf v1.0. Bila dikemudian waktu label versi menjadi versi 1.2 atau v1.2 maka hal tersebut menandakan bahwa perangkat lunak tersebut telah mengalami revisi (baca : perbaikan) dari versi sebelumnya.

  • Penambahan akhiran {alpha|beta|STABLE} menunjukkan status pengembangan perangkat lunak tersebut - dimana yang berakhiran alpha menandakan bahwa perangkat lunak tersebut masih dalam pengembangan dalam tahap yang paling awal sehingga kemungkinan akan adanya kesalahan operasional dari perangkat lunak tersebut (baca : software error) masih akan sering dirasakan, dan masih layak di-uji-coba secara terbatas dalam laboratorium. Yang berakhiran beta menandakan bahwa sebuah perangkat lunak tersebut telah siap dipublikasikan dalam lingkup percobaan pada pengguna akhir sembari pengembang menerima masukan evaluasi dari pengguna secara langsung. Penandaan STABLE menunjukkan bahwa sebuah perangkat lunak telah lulus uji coba laboratorium secara baik dan layak untuk dipergunakan di-lingkungan produksi atau pengguna umum.

  • Penambahan akhiran {i386|x64|smp|sparc|ppc} menunjukkan dalam lingkungan komputasi berbasis prosesor apa sebuah perangkat lunak di-kembangkan dan untuk di-operasikan (baca : di-install). i386 menunjukkan bahwa sebuah perangkat lunak dikembangkan dan di-operasikan untuk lingkungan komputasi berbasis prosesor sekelas Intel 32-bit. x64 berarti dikembangkan untuk kelas prosesor Intel 64-bit. smp berarti perangkat lunak tersebut dapat digunakan untuk oleh komputer CPU berprosesor dua atau lebih. sparc menunjukkan bahwa perangkat lunak dikembangkan khusus untuk komputer berbasis prosesor SUN SPARC, ppc khusus untuk komputer berbasis CPU PowerPC atau PPC.
Kebutuhan SDLC
Penerapan SDLC yang baik dan benar pada prinsipnya juga membutuhkan biaya baik itu finansial dan non-finansial, baik itu teknis maupun non-teknis yang tidak sedikit. Kesemua hal tersebut wajib diperhitungkan secara cermat agar proses pengembangan perangkat lunak itu sendiri (yang menjadi inti utama dari SDLC) tidak terhambat atau bahkan terbengkalai.
Limitasi SDLC
Kadangkala, perkembangan dan penggunaan teknologi antara perangkat keras dan perangkat lunak, dan sesama perangkat lunak tidak sejalan (baca : lebih cepat atau lebih lambat antara satu dengan lainnya, antara mendukung dan tidak mendukung satu dengan lainnya) - sehingga terkadang hasil proses SDLC yang membutuhkan aplikasi pendukung lainnya (baca : software dependencies) maupun perangkat keras (baca : hardware) yang benar-benar mendukung (baca : perangkat keras baru) agak kesulitan dalam proses penyesuaian (baca : serapan) sehingga dapat menyebabkan proses implementasi SDLC “terkesan” stagnan.

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Blogger news

Popular Posts