Archive for 2014

Model Pengembangan Software

►
Model Pengembangan Software  Menurut Ian Sommerville
A.    Model Waterfall
Pada tahun 1960-an dan 1970-an, proyek pengembangan perangkat lunak merupakan pekerjaan yang sangat memakan biaya dan waktu karena pengembangan  perangkat lunak ini difokuskan pada perencanaan dan pengendalian (Basili dan Musa, 1991). Kemunuclan model waterfall adalah untuk membantu mengatasi kerumitan yang terjadi akibat proye-proyek pengembangan perangkat lunak (Boehm, 1976). Seperti yang terlihat pada gambar di bawah, sebuah model air terjum memacu tim pengembang untuk merinci apa yang seharusnya perangkat lunak lakukan (mengumpulkan dan menentukan kebutuhan system) sebelum system tersebut dikembangkan.


Tahapan-tahapan utama dari model ini memetakan kegiatan-kegiatan pengembangan dasar yaitu :
1.      Analisis dan definisi persyaratan. Pelayanan, batasan dan tujuan sistem ditentukan melalui konsultasi dengan user system. Persyaratan ini kemudian didefinisikan secara rinci dan berfungsi sebagai spesifikasi system.
2.      Perancangan system dan perangkat lunak. Proses perancangan system membagi persyaratan dalam system perangkat keras atau lunak. Kegiatan ini menentukan arsitektur system secara keseluruhan. Perancangan perangkat lunak melibatkan identifikasi dan deskripsi abstraksi system perangkat lunak yang mendasar dan hubungan-hubungannya.
3.      Implementasi dan pengujian unit. Pada tahap ini, perancangan perangkat lunak direalisasikan sebagai serangkaian program atau unit program. Pengujuan unit melibatkan verifikasi bahwa setiap unit telah memenuhi spesifikasinya.
4.      Integrasi dan pengujian system. Unit program atau program individual diintegrasikan dan diuji sebagai system yang lengkap untuk menjamin bahwa persyaratan system telah dipenuhi. Setelah pengujian system, perangkat lunak dikirim kepada pelanggan.
5.      Operasi dan pemeliharaan. Biasanya (walau tidak seharushya), ini merupakan fase siklus hidup yang paling lama. Sistem diinstal dan dipakai. Pemeliharaan mencakup koreksi dari berbagai error yang tidak ditemukan pada tahap-tahap terdahulu, perbaikan atas implementasi unit system dan pengembangan pelayanan system, sementara persyaratan-persyaratan baru ditambahkan.  
Model Waterfall

B.     Pengembangan Evolusioner
Pengembangan evolusioner berdasarkan pada ide untuk mengembangkan implementasi awal, memperlihatkan kepada user untuk dikomentari, dan memperbaiki versi demi versi sampai system yang memenuhi persyaratan diperoleh. Tidak ada kegiatan spesifikasi, pengembangan, dan validasi yang terpisah, alih-alih kegiatan-kegiatan ini dilakukan pada saat yang bersamaan dengan umpan balik yang cepat untuk masing-masing kegiatan. Ada dua jenis pengembangan evolusioner:
1.      Pengembangan eksploratori. Tujuan proses ini adalah bekerja dengan pelanggan untuk menyelidiki persyaratan mereka dan mengirimkan sistem akhir. Pengembangan dimulai dengan bagian-bagian sistem yang dipahami. Sistem berubah dengan adanya tambahan fitur-fitur baru sesuai usulan pelanggan.
2.      Prototipe yang dapat dibuang (throw-away). Tujuan pengembangan evolusioner adalah untuk memahami persyaratan pelanggan dan dengan demikian mengembangkan definisi persyaratan yang lebih baik untuk sistem. Prototipe berkonsentrasi pada eksperimen, dengan persyaratan pelanggan yang tidak dipahami dengan baik.

Pendekatan evolusioner terhadap pengembangan perangkat lunak seringkali lebih efektif dari pendekatan air terjun dalam menghasilkan sistemyang memenuhi kebutuhan langsung dari pelanggan. Keuntungan proses perangkat lunak yang berdasarkan pada pendekatan evolusioner adalah bahwa spesifikasi dapat dikembangkan secara inkremental. Sementara user mendapat pemahaman yung lebih baik dari masalahmereka, sistem perangkat lunak dagat merefleksikannya.  Namun demikian, dari sudut pandang rekayasa dan manajemen, ada tiga masalah dengan cara ini:
1.      Proses tidak bisa dilihat. Manajer memerlukan hasil reguler untuk mengukur kemajuan. Jika sistem dikembangkan dengan cepat, tidaklah efektif dari segi biaya jika dihasilkan dokumen yang merefleksikan setiap versi sistem.
2.      Sistem seringkali memiliki struktur yang buruk. perubahan yang terus-menerus cenderung merusak struktur perangkat lunak. penyesuaian perubahan perangkat lunak menjadi kian sulit dan mahal.
3.      Mungkin diperlukan alat bantu dan teknik khusus. Keperluan ini memungkinkan pengembangan yang cepat tetapi mungkin tidak kompatibel dengan alat bantu atau teknik lain dan relatif hanya sedikit orang yang memiliki keahlian untuk memakainya.
Untuk sistem kecil (kurang dari 100.000 baris kode) atau sistem berukuran menengah (sampai 500.000 baris kode) dengan waktu hidup yang pendek, pendekatan evolusioner untuk pengembangan  merupakan pendekatan yang paling baik. Akan tetapi, untuk sistem yang besar dan memiliki waktu hidup yang lama, masalah-masalah dengan pengembangan evolusioner bisa menimbulkan masalah yang besar. Untuk sistem-sistem ini, direkomendasikan proses campuran, yang memakai fitur-fitur terbaik dari model air terjun dan pengembangan evolusioner. cara ini bisa melibatkan pengembangan prototipe yang dapat dibuang dengan menggunakan pendekatan evolusiner unfuk menangani ketidakpastian pada spesifikasi sistem. Sistem ini bisa diimplementasi kemudian dengan tn"nggunutun pendekatan yang lebih terstruktur. Bagian-bagian sistem yang dipahami dengan baik dapat dispesifikasi dan dikembangkan dengan menggunakan proses yang berdasarkan pada model air terjun. Bagian sistem yang lain, seperti interface untuk dispesifikasi sebelumnya, harus dikembangkan dengan pendekatan perffograman eksploratori.



C.     Pengembangan Sistem Formal
Pengembangan sistem formal merupakan pendekatan terhadap pengembangan  perangkat lunak yang memiliki kesamaan dengan model air terjun, tetapi proses pengembangannya didasarkan pada transformasi matematis dari spesifikasi system menjadi program yang dapat dijalankan.
Pengembangan system formal
Perbedaan kritis antara pendekatan ini dan model air terjun adalah :
1.      Spesifikasi persyaratan perangkat lunak diperbaiki menjadi spesifikasi formal yang rinci yang dinyatakan dalam notasi matematis
2.      Proses pembangunan perancangan, , imprementasi, dan pengujian unit digantikn oleh proses pengembangan transformasional di mana spesifikasi formal diperbaiki, melalui serangkaian transformasi, menjadi program.
Pada proses transfoirnasi, representasi matematis formal dari sistem secara sistematis diubah menjadi representasi sistem yang lebih rinci, tetapi tetap benar secara matematis. Setiap langkah menambahkan perincian sampai speiifikasi formal diubah menjadi program yang ekivalen. Transformasikan sampai cukup dekat sehingga usaha verifikasi transformasi tidak berlebihan. oengan demikian dapat dijamin, dengan menganggap tidak adanya error verifikasi, bahwa program merupakan implementasi yang benar dari spesifikasi.
Keuntungan pendekatan transformasional dibandingkan dengan penyetujuan bahwa suatu program telah memenuhi spesifikasinya adalah bahlwa jarak Antara setiap transformasi lebih kecil dari pada jarak antara spesifikasi dan program. Bukti program sangat panjang dan tidak praktis untuk sistem berskala besar. Pendekatan transformasional yang terdiri dari serangkaian langkah yang lebih kecil akan lebih mudah ditelusuri. Namun demikian,pemilihan transfomasi apa yang akan dipakai merupakan pekerjaan yang membutuhkan keahlian dan membuktikan hubungan transformasi adalah sesuatu yang sulit.
Contoh yang paling dikenal tentang proses pengembangan formal ini adalah proses Cleanroom yang aslinya dikembangkan oleh IBM (Mills er al., 1987; Selby et al1987; Linger, 1994; Prowell et al, 1999). Proses Cleanroom bergantung pada pengembangan perangkat lunak incremental dansetiap tahap dikembangkan dan kebenarannya didemonstrasikan dengan menggunakan pendekatan formal. Tidak ada pengujian kesalahan pada proses dan pengujian system difokuskan pada penilaian keandalan system.
Pendekatan Cleanroom dan pendekatan lain bagi  pengembangan formal yang berdasarkan pada metode B (Wordsworth, 1996) telah diterapkan dengan sukses.  Ada sedikit kesalahan pada system yang dikirimkan dan biaya pengembangan tidak berbeda secara signifikan dari biaya pendekatan lain. Pendekatan ini terutama disesuaikan dengan pengembang system  yang memiliki persyaratan keselamatan keandalan, atau keamanan yang ketat. Pendekatan formal menyederhanakan pembuatan kasus keselamatan atau keamanan yang menunjukkan kepada pelanggan atau badan sertifikasi bahwa sistem tersebut telah memenuhi persyaratan keselamatan atau keamanan.
Di luar domain khusus ini, proses yang berdasarkan pada transformasi formal tidak digunakan secara luas.  Cara ini memerlukan keahlian khusus dan sesungguhnya untuk sebagian besar system, proses ini tidak memberikan keuntunganbiaya atau kualitas yang signifikan dibandingkan dengan pendekatan yang lain. Alasan utamanya adalah bahwa interaksi sistem tidak menerima spesifikasi system dan hal ini menyita bagian sangat besar dari usaha pengembangan sebagian besar sistem perangkat lunak.

D.    Pengembangan Berorientasi Pemakaian Ulang
Pada sebagian besar proyek perangkat lunak terjadi pemakaian ulang. Hal ini biasanya terjadi secara intormal ketika orang yang bekerja di proyek tersebut mengetahui adanya rancangan atau kode yang mirip dengan yang dibutuhkan. Mereka mencari rancangan atau kode ini, memodifikasinya sebagaimana dibutuhkan, dan menggabungkannya dalam sistem. pada pendekatan evolusioner, pemakaian ulang seringkali dipandang penting untuk pengembangan system yang cepat.
Pemakaian ulang informal ini terjadi dengan mengabaikan proses generik yangdipakai. Namun d"mlkian, dalam beberapa tahun belakangan ini  suatu pendekatan terhadap pengembanganperangkat lunak (rekaya perangkat lunak berdasarkan komponen) yang berdasarkan atas pemakaian  ulang telah muncul dan penggunaannya bertambah luas.
Pendekatan yang berorientasi pemakaian ulang ini bergantung pada sejumlah besar komponen  perangkat  lunak yang dapat dipakai ulang yang bisa didapa dan beberapa kerangka kerangka kerja untuk komponen-komponen ini. Kadangkala komponen-komponen  ini merupakan sistem juga (COTS atau-Commercial Off-The-Shelf systems / Sistem Siap Beli Komersial yang dapat digunakan untuk memberikan fungsionalitas khusus seperti format teks, perhitungan numeric, dll.
Pengembangan berorientasi pemakaian ulang
Sementara tahap spesifikasi persyaratan dan tahap validasi dapat dibandingkan dengan proses lain, tahap pertengahan pada proses berorientasi pemakaian ulang ini ternyata berbeda. Tahap-tahap ini adalah:
1.      Analisis komponen. Jika diketahui spesifikasi persyaratan, komponen-komponen untuk implementasi spesifikasi tersebut akan dicari. Biasanya, tidak ada kesesuaian yang tepat dan komponen yang dapat dipakai hanya memberikan sebagian dari fungsionalitas yang dibutuhkan.
2.       Modifikasi persyaratan. Pada tahap ini, persyaratan dianalisis dengan menggunakan informasi mengenai komponen yang telah didapat. persyarltan kemudian dimodifikasi untuk merefleksikan komponen yang tersedia. Jika modifikasi tidak mungkin dilakukan, maka kegiatan analisis komponen bisa diulang untuk mencari solusi alternatif.
3.      Perancangan sistem dengan  pemakaian arang. pada fase ini, kerangka kerja sistem dirancang, atau kerangka kerja yang telah ada dipakai ulang. Perancang memperhitungkan komponen yang dipakai ulang dan mengatur kerangka kerja untuk menyesuaikan. Beberapa perangkat lunak yang baru mungkin perlu dirancang jika komponen yang dapat dipakai ulang tidak tersedia.
4.      Pengembangan dan integrasi. perangkat runak yang tidak dapat dibeli akan dikembangkan dan komponen dan sistem corS diintegrasikan untuk membentuk sistem. Integrasi sistem, pada model ini, bisa merupakan bagian dari proses pengembangan dan bukan merupakan kegiatan yang terpisah.

Model yang berorientasi pemakaian ulang mempunyai keuntungan nyata yaitu mengurangi besarnya perangkat lunak yang akan dikembangkan, sert-a memperkecil biaya dan risiko. Keuntungan ini biasanya memungkinkan penyelesaian perangkat lunak dengan cepat. Akan tetapi, kompromi persyaratan sangatlah penting dan bisa menghasilkan sistem yang tidak memenuhi kebutuhan sebenarnya dari user. Lebih jauh lagi, kontrol terhadap evolusi sistem akan hilang sementara versi baru dari komponen yang dapat dipakai ulang tidak terkontrol oleh organisasi yang memakai komponen ini.
Saturday, April 26, 2014
Posted by Unknown
0 Comments
Tag :

Google Kembangkan Lensa Kontak Komputer

►

Google Kembangkan Lensa Kontak Komputer


Google kembali menunjukkan ambisinya dalam mengembangkan perangkat teknologi yang dapat dikenakan (wearable technology). Perusahaan mesin pencarian Internet terbesar itu, Kamis, menyatakan sedang mengembangkan lensa kontak pintar. Menurut USAToday, lensa tersebut mengukur glukosa dalam air mata menggunakan chip nirkabel dan sensor glukosa mini.
Pada tahap awal, Google berharap teknologi ini dapat membantu mengelola diabetes penggunanya dengan lebih baik. Proyek ini merupakan penemuan terbaru yang muncul dari unit perusahaan Google X yang bekerja dalam waktu jangka panjang.
Teknologi ini beresiko tidak akan sukses secara komersial, namun berpotensi mengubah cara hidup seseorang secara drastis. Google X juga telah menghasilkan mobil yang bisa mengemudi sendiri (self-driving) dan Google Glass.
Google menyatakan go public dengan proyek lensa kontak pada tahap awal karena tengah mencari mitra ahli yang dapat membawa teknologi ini ke pasar di masa mendatang.
sumber:http://teknologitinggi.wordpress.com/2014/01/19/google-kembangkan-lensa-kontak-komputer/
Tuesday, April 8, 2014
Posted by Unknown
0 Comments

AndroidManifest.xml

►
1.     <action>
Syntax :
Menambahkan sebuah tindakan untuk intent filter. Sebuah elemen <intent-filter> harus berisi satu atau lebih elemen <action>.

2.     <activity>
Syntax :

Mendeklarasikan sebuah aktivitas (subclass dari aktivitas) yang mengimplementasikan baigan dari visual aplikasi (interface) bagi pengguna. Semua aktivitas harus bisa merepresentasikan elemen <activity> dalam file manifest. Jika tidak dideklarasikan maka sistem tidak akan tahu dan tidak akan pernah di jalankan.
3.     <activity-alias>
Syntax :

Sebuah alias untuk aktifitas ditunjuk oleh atribut targetActivity. Target harus dalam aplikasi yang sama sebagai alias dan harus dideklarasikan sebelum alias dalam file manifest.
Alias menyajikan target aktifitas sebagai entitas independen. Alias memiliki intent-filter sendiri.
Elemen <activity-alias> merupakan subset dari atribut <activity>. Untuk atribut subset, tidak ada nilai yang ditetapkan dari target yang dibawa oleh alias. Namun, untuk atribut bukan subset, nilai ditetapkan untuk target aktivitas yang berlaku untuk alias.
4.     <application>
Syntax :

Merupakan deklarasi dari aplikasi. Element ini berisi subelement yang mendeklarasikan setiap komponen aplikasi yang memiliki atribut dan dapat mempengaruhi semua komponen. Banyak atribut (seperti icon, label, permission, process, tasAffinity, dan allowTaskParenting) yang nilainya ditetapkan secara default untuk atribut dari elemen komponen yang sesuai. Lainnya (seperti debuggale, enabled, description, dan allowClearUserData) nilainya ditetapkan untuk aplikasi secara keseluruhan dan tidak bisa diganti oleh komponen.
5.     <category>
Syntax :

Menambahkan nama kategori ke dalam intent filter.
6.     <compatible-screens>
Syntax :

Menentukan spesifikasi setian konfigurasi layar dengan aplikasi yang kompetibel. Hanya satu contoh dari elemen <compatible-screens> yang diizinkan dalam manifest, tetapi itu bisa berisi beberapa elemen <screen>. Setiap elemen <screen> menentukan size-density yang cocok untuk aplikasi.
Sistem android tidak dapat membaca elemen manifest <compatible-screen>. Elemen ini hanya dapat digunakan oleh layanan eksternal (seperti Google Play) untuk dapat mengerti dengan baik kompatibilitas sebuah aplikasi dengan spesifikasi konfigurasi layar tertentu dan memungkinkan penyaringan bagi pengguna. Setiap konfigurasi layar tidak dideklarasikan dalam element.
7.     <data>
Syntax :

Menambahkan spesifikasi data ke intent-filter. Spesifikasi bisa saja berupa tipedata (atribut mimeType), URI, atau kedua dari tipe data dan URI.
Anda dapat menempatkan nomor dari elemen <data> dalam sebuah <intent-filter> untuk memberikan beberapa pilihan data. Tidak ada atribut yang memiliki nilai default.
Informasi tentang bagaimana intent-filter bekerja, termasuk aturan bagaimana intent objects cocok dengan filter, dapat ditemukan di dokumen lain, intent dan intent filters.
8.     <grant-uri-permission>
Syntax :

Menentukan subsets data dari penyedia konten yang disediakan. Data subsest mengindikasikan bagian dari content : URI. (Otoritas bagian dari URI mengidentifikasi penyedia konten). Memberian izin merupakan cara yang memungkinkan bagi klien dari penyedia yang biasanya tidak memiliki izin untuk mengakses data.
Jika penyedia konten atribut grantUriPermissions itu “true” izin dapat diberikan untuk setiap data yang berada diruang lingkup penyedia. Namun, jika atribut itu “false”, izin dapat diberikan hanya untuk data subset saja yang dijelaskan atau dispesifikasikan oleh element. Penyedia layanan bisa berisi nomor dari elemen <grant-uri-permission>. Setiap elemen bisa dispesifikasi oleh satu path (hanya satu dari tiga kemungkinan atribut).
9.     <instrumentation>
Syntax :

Mendeklarasikan sebuah kelas instrumentation yang memungkinakan pengguna untuk memonitar interaksi aplikasi menggunakan sistem. Objek instrumentation adalah instantiated dari komponen aplikasi.
10.    <intent-filter>
Syntax :

android:icon
sebuah icon mewakili aktifitas parent, layanan, atau penerima broadcast ketika komponen menyediakan kepada pengguna yang memiliki kemampuan yang dideskripsikan oleh filter.
Atribut ini harus ditetapkan sebagai referensi untuk sumber daya yang berisi definisi gambar. Nilai default  ditetamkan oleh induk komponen atribut icon.
android:label
Sebuah label untuk komponen pengguna dapat dibaca. Label harus ditetapkan sebagai referensi dari sumber daya string, sehingga dapat dialokasikan seperti string lain dalam pengguna antarmuka. Nilai default  dari label ditetapkan oleh komponen induk. Jika induk tidak menentukan label, nilai default ditetapkan oleh atribut elemen <application>.
android:priority
prioritas harus diberikan kepada komponen induk dengan penanganan intents dari deskripsi tipe oleh filter.
11.    <manifest>
Syntax :


Elemen root dari file AndroidManifest.xml. file tersebut berisi sebuah elemen <application> dam spesifikasi xmlns:android dan atribut package.
12.    <meta-data>
Syntax :


sebuah name-value untuk item tambahan, data yang bisa menyediakan kepada komponen induk. komponen elemen bisa berisi nomor dari subelemen <meta-data>. Nilai dari semuanya adalah kolesi dalam sebuah onjek bundle tunggal dan membuat komponen yang tersedia sebagai bidang PackageItemInfor.metaData. Hal ini sangat disarankan agar dapat menghindari supply data sebagai bagian terpisah dari <meta-data>.
13.    <path-permission>
Syntax :

android:path
path URI yang lengkap untuk sebuah subses dari konten penyedia data.
android:PathPrefix
inisialisai bagian dari URI untuk subset dari konten penyedia data.
android:pathPattern
path URI yang lengkap untuk subset penyedia data, tetapi satu bisa menggunakan wildcards berikut :
·      Aterisk (*). Ini cocok untuk urutan 0 ke banyak kejadian dari karakter sebelumnya.
·      Sebuah periode diikuti dengan tanda bintang (*). Hal ini cock untuk 0 atau lebih karakter.
android:permission
nama dari izin dari klien harus memiliki perintah untuk read dan write konten dari penyedia data.
android:readPermission
sebuah izin dari klien harus memiliki perintah query yang menyediakan konten.
android:writePermission
izin dari klien harus memilik perintah untuk mengubah data yang dikontrol oleh konten penyedia.
14.    <permission>
Syntax :

Mendeklarasikan sebuah izin keamanan yang bisa digunakan untuk batas akses ke komponen spesifik atau fitur dari aplikasi lain.
15.    <permission-group>
Syntax :

Mendeklarasikan nama untuk kelompok logis dari izin terkait.
16.    <permission-tree>
Syntax :

Mendeklarasikan nama dasar untuk tree-permission
17.    <provider>
Syntax :

Mendeklarasikan konten dari penyedia komponen. Sebuah konten penyedia merupakan subclass dari ContentProvider yang menyediakan struktur akses ke manajemen data dari aplikasi. Semua konten penyedia dalan aplikasi harus bisa didefinisikan dalam sebuah elemen <provider> dalam file manifest.
18.    <receiver>
Syntax :

Mendeklarasikan penerima broadcast (sebuah subclass BroadcastReceiver) sebagai satu dari komponen aplikasi.
19.    <service>
Syntax :

Mendeklarasikan sebuah layanan (subclass Service) sebagai satu dari komponen aplikasi. Semua layanan harus bisa menyediakan elemen <service> dalam file manifest.
20.    <supports-gl-texture>
Syntax :

Mendeklarasikan format teksture GL kompresi tunggal yang di dukung oleh aplikasi. Sebuah aplikasi “support” format teksture GL kompresi jika itu mampu memberikan asset tekstur yang dikompresi dalam format tersebut setelah aplikasi diinstal dalam perangkat. 
21.    <supports-screens>
Syntax :

Menentukan ukuran layar dari aplikasi pendukung dan memungkintakan screen compatibility mode untuk layar besar daripada aplikasi pendukung.
22.    <uses-configuration>
Syntax :

Mengindikasi fitur perangkat keras dan perangkat lunak dari kebutuhan aplikasi.
23.    <uses-feature>
Syntax :

Mendeklarasikan fitur tunggal perangkat keras dan perangkat lunak yang digunakan oleh aplikasi. Tujuan umum dari deklarasi <uses-feature> adalah untuk informasi entitas eksternal dari fitur perangkat keras dan perangkat lunak yang tergantung pada aplikasi.
24.    <uses-library>
Syntax :

Menentukan spesifikasi library yang dibagi dari aplikasi saling berhubungan. Elemen ini memberitahu sistem untuk memasukkan code library dalam class loader untuk paket.
25.    <uses-permission>
Syntax :

Meminta izin dari aplikasi untuk beroperasi dengan benar. Hak akses yang diberikan oleh pengguna saat aplikasi diinstal, bukan bersifat sementara saat berjalan.
26.    <uses-sdk>
Syntax :

Mengekspresikan kompatibilitas aplikasi dengan satu atau lebih versi dari platform android, melalui sebuah API level integer. Level API diungkapkan oleh aplikasi akan dibandingkan ke level API yang diberikan oleh sistem android, yang mungkin berbeda diantara perangkat android lainnya.

Sumber : http://developer.android.com/guide/topics/manifest/manifest-intro.html
irzavika
Sunday, April 6, 2014
Posted by Unknown
0 Comments
Tag : , ,

- Copyright © 2013 Laboratorium Pemrograman dan Basis Data -Metrominimalist- Powered by Blogger - Designed by Johanes Djogan -