Sedikit cerita tentang industri perangkat lunak...

bener-bener trueee stori... ^^

Sering mendengar para lamer atau nubie berkoar (yang nota bener masih para ABG) mempublikasikan dirinya sebagai hacker membuat saya beranggapan bahwa menjadi seorang hacker dan sejenisnya adalah hal yang keren menurut anggapan mereka.

Mulailah menggauli baris demi baris kode layaknya seorang santri menghafal ayat-ayat demi ayat dalam Alquran.

heheh tapi sebenernya tujuannya kedepan gimana? menjadi seorang kriminal?? bongkar sistem orang, pencurian data, carding nyolong kartu kredit orang lain atau jadi seorang profesional? duduk manis depan komputer membuat aplikasi yang nantinya di pakai ribuan orang?



dan jika pikiran anda sehat tentu anda akan dengan serta masuk dalam insdustri perangkat lunak itu sendiri. Menjadi sistem analis, programmer atau penetration testing.

Sampe disini anda menjadi nyaman? merasa tidak sia-sia perjuangan anda khatamberbagai kode aneh. Saya rasa jawabnya pasti tidak!!

Jika anda beruntung mampu membiayai berbagai setifikat yang harganya lumayan dan anda beruntung, mungkin anda adalah orang yang keren dalam sebuah perusahaan :D ... tentu saja dengan jabatan Application Development, Systems Administration atau programmer yang benaung di bawah departement IT besar dengan gaji yang lumayan.

Lalu? yang ga beruntung?? kerja di tempat kaya di bawah ni T_T

Marketing melakukan segala cara untuk mendapatkan customer, termasuk *ngasal*Customer minta bisa selesai 6 bulan (padahal normalnya butuh 1 tahun lebih), marketing langsung dengan enteng jawab 2 bulan pun bisa selesai.

Kalau berhasil -> management dan marketing yang dapat reward & bonus, engineer gigit jarikalau gagal -> engineer yang disalahkan





... selamat Pagi dan sekian??







http://kelepon.wordpress.com/2011/10/20/sedikit-cerita-tentang-industri-perangkat-lunak/

Sudah dengerkan cerita bayi kelindes truck dan warga cina diem doang?

http://www.youtube.com/watch?v=mJ8EXce0eqo
Video di atas itu di cina.. di indonesia juga ada
http://www.youtube.com/watch?v=kmyhvnaZ6fU&feature=youtu.be

Ada pendapat yang mengatakan bahwa di china memang banyak kejadian ketika seorang menolong, si penolong bisa saja terjerat hukum, di salahkan atau disuruh membayar biaya macem2 untuk mengurus korban.



Bukannya di kita juga sama? yang di tolong kadang-kadang tukang tepu, mau meres dll.


Hal2 diatas cuma excuse(alasan) yang dipakai org2 pengecut untk membenarkan tindakannya mengabaikan org yg sedang terkena bencana. Tolong jangan maklumi kemerosotan nilai kemanusiaan ini. Bukankah ini serupa dengan ketakutan masayarakat kita menolong seseorang krn takut dibebani biaya rumah sakit dan lain2? Saya sudah lama kesal dengan kepengecutan org2 semacam itu, tolong jangan tambahkan lagi alasan2 mereka untuk membenarkan kpengecutan mereka. Bisa bayangkan bila salah satu anggota keluarga kalian tertabrak dan orang2 mengabaikannya begitu saja dengan alasan2 diatas? Bisakah kalian memakluminya?!?

Tolong jangan sebarkan rasa saling curiga & syak wasangka seperti ini di Indonesia, isu ini hanya akan menambah kemerosotan moral. Kasian buat yg kebetulan mengalami kemalangan. Nasib mereka jd seperti istilah "sudah jatuh tertimpa tangga", sudah tertimpa musibah masih harus dicurigai dan dianggap ancaman pula. Tidak seharusnya kita mengabaikan keselamatan org lain atas dasar egoisme diri kita sendiri yg keburu berfikir negatif tentang para korban.

ketakutan seperti diatas, itu cuma minoritas kasus dibanding begitu banyak kasus pertolongan di Indonesia yang kebanyakan malah berakhir indah. Ane percaya kok kalo masyarakat indonesia lebih solider daripada China dan masih banyak yg bermoral dan menghargai nilai2 kemanusiaan, toh memang budaya dasar masyarakat kita suka tolong menolong dan persaudaraan. Buktinya masih banyak korban yg begitu menghargai pertolongan dari penolong dan menganggapnya saudara, bahkan rela memberikankan apapun terhadap penolongnya itu.

Bagaimanapun tidak ada kebaikan yang sia2, lagipula jangan keburu berfikir negatif sebelum bertindak, karena kita tidak akan pernah tau bagaimana akhirnya. Cukuplah niat tulus dan sikap spontan (tanpa berfikir yg jelek2 dulu tentang korban) untuk menolong org, jangan mengharapkan penghargaan atau kemudahan (karena dengan menolong sendiri kita sudah menerima konsekuensi untk "disusahkan").

Kalaupun pada akhirnya penolong dituduh macam2 oleh korban, percayalah tidak ada kebaikan yg sia2, cukuplah Tuhan yang mencatat kebaikan kita sbg penolong(toh kita tidak butuh penghargaan yg digembar gemborkan...).Bagaimanapun sebuah nyawa org yg kita tolong lebih berharga bahkan dibanding nama baik kita sendiri...Gak penting lah tuduhan seperti itu untuk dipermasalahkan, selama kita benar kita nggak blh takut, toh kebenaran itu akan terungkap dengan sendirinya.


Intinya menolong butuh keberanian & "kenekatan" (tp justru disitulah hebatnya), dan jika anda hanya mengharapkan pengakuan&penghargaan, jangan pernah menolong orang lain!

gw dari http://tinyurl.com/6h2basl oleh Abi Jamso pada 29 Oktober 2011 jam 2:10

Mau Tahu Aja...

PERBEDAAN INTERNET, INTRANET DAN EXTRANET

Mau tahu bedanya interNET, intraNET, sama extraNET....??

intermezzo dulu nih...
InterNET

Merupakan komunikasi jaringan komunikasi global yang menghubungkan seluruh komputer di dunia meskipun beda sistem oprasi dan mesin.

IntraNET

Adalah sebuah jaringan koputer berbasis protokol TCP/IP seperti internet, hanya saja digunakan dalam internal perusahaan atau kantor dengan aplikasi berbasis web dan teknologi komunikasi data seperti interNET ( bahkan warung internet (warNET) dapat dikategorikan sebagai intraNET)

EkstraNET
Jika sebuah badan usaha atau bisnis mengekspose sebagian dari internal jaringan ke komunitas di luar.

yah begitulah menurut saya :

Apa sih SDLC ?

SDLC (System Development Life Cycle), seperti namanya, didefinisikan sebagai proses (secara keseluruhan) dari sistem berkembang atau perangkat lunak untuk memenuhi persyaratan tertentu. Ini mencakup banyak kegiatan, mulai dari pemahaman mengapa sistem harus dibangun, mempelajari kelayakan proyek, menganalisis masalah, memilih desain sistem dan arsitektur, pelaksanaan dan pengujian itu, sampai dengan memberikan sistem sebagai produk kepada pengguna. SDLC adalah proses perbaikan bertahap, yang berarti bahwa hal itu dilakukan melalui beberapa tahapan pembangunan. Setiap fase terus dan memurnikan apa yang dilakukan dalam tahap sebelumnya. Tahapan pembangunan umum dikenal di SDLC adalah:

Planning Ini adalah proses memahami mengapa sistem harus dibangun dan mendefinisikan persyaratan. Ini juga mencakup studi kelayakan dari perspektif yang berbeda, teknis, ekonomi, dan aspek kelayakan organisasi.

Analysis Fase ini meliputi kegiatan seperti mengidentifikasi masalah dan analisis, dan bahkan memprediksi potensi masalah yang mungkin timbul di masa depan mengenai sistem. Kiriman / produk dari fase ini akan mendorong bagaimana sistem akan dibangun dan membimbing karya pengembang.

Design Analisis sistem mengarah ke desain keputusan, yang justru menentukan bagaimana sistem beroperasi dalam hal proses, data, perangkat keras, infrastruktur jaringan, antarmuka pengguna, dan faktor-faktor penting lainnya dalam lingkungan sistem.

Implamentation  Ini mungkin yang paling sumber daya, biaya, dan memakan waktu fase dari semua.Ini adalah ketika sistem sebenarnya dibangun, diuji, dan akhirnya diinstal. Ini juga mencakup kegiatan seperti pelatihan pengguna dan pemeliharaan sistem. Beberapa ahli seperti untuk memisahkan mereka ke dalam Penyebaran fase yang berbeda dan Pemeliharaan ( Development and Maintenance ). Namun empat fase yang paling umum dikenal dan langkah-langkah diterima.

SDLC mencoba untuk mencapai sistem berkualitas tinggi yang memenuhi atau melebihi persyaratan.Banyak metodologi telah dikembangkan dan diperkenalkan dalam rangka untuk melaksanakan SDLC, beberapa dari mereka juga mencoba untuk meningkatkan yang lain (sebelumnya) metodologi yang dikenal. Meskipun setiap metode berikut teknik yang berbeda dan langkah-langkah tertentu, mereka semua harus pergi ke dalam fase pembangunan yang sama dijelaskan di atas. Ada banyak metode pengembangan sistem yang dikenal hari ini, tapi kebanyakan dari mereka pada dasarnya diperpanjang dari tiga metodologi utama yang Terstruktur Desain, Analisis RAD (Rapid Application Development), dan berorientasi Obyek dan Desain.

Desain Terstruktur ( Structured Design )

Metode ini mengikuti pendekatan langkah-demi-langkah yang bergerak secara logis dari satu tahap ke tahap berikutnya. Bekerja dilakukan dalam setiap fase harus disetujui oleh sponsor proyek (ini biasanya pelanggan atau analis bisnis dalam sebuah organisasi) sebelum dapat melanjutkan ke tahap perkembangan berikutnya. Metodologi pengembangan Waterfall dapat diklasifikasikan sebagai metodologi semacam ini. Cara ini ketelitian dan fleksibel membuat metodologi ini rentan terhadap setiap perubahan bisnis yang terjadi saat pembangunan masih dalam perjalanan, karena sangat sulit untuk pergi ke belakang. Ini mungkin memerlukan mengulangi seluruh proses pembangunan dari awal dan membuang semua yang telah dilakukan, dan dalam kasus terburuk dapat menyebabkan perubahan kontrak proyek atau perjanjian dengan pelanggan.

Ada dua pendekatan dalam pengembangan sistem menggunakan metodologi ini, proses-berpusat dandata-berpusat pendekatan. Proses pendekatan yang berpusat pada upaya untuk mendapatkan pekerjaan dilakukan terutama dari perspektif proses yang ada dalam operasi sistem, yang kemungkinan akan menghasilkan sistem yang dibangun oleh proses-berorientasi komponen. Di sisi lain, pendekatan data-berpusat berkonsentrasi pada data yang digunakan oleh dan terlibat dalam sistem.

Metodologi desain terstruktur memiliki beberapa keunggulan dalam bahwa cara kekakuan dari metode ini memaksa pengembang (analis dan / timnya) dengan baik mengidentifikasi dan memahami persyaratan sistem lama sebelum tahap implementasi dimulai. Setidaknya harus telah disetujui oleh sponsor sebelum pengembang mulai coding program apapun.

Kurangnya kemampuan untuk pergi ke belakang dari tahap pengembangan metodologi ini membuat unaccommodateable perubahan proses bisnis sebagai hasil proyek. Proyek dilakukan dengan menggunakan metodologi ini memakan waktu lama sampai pengguna menerima beberapa kiriman karena biasanya sistem yang dibangun tidak dapat disajikan sampai benar-benar dilakukan pada akhir fase implementasi.

Gambar 1. Desain Terstruktur Metodologi

RAD ( Rapid Application Development )

Metodologi RAD masuk untuk mengatasi kelemahan metode Desain Terstruktur. RAD pembangunan berbasis mencoba untuk menyesuaikan fase SDLC memiliki beberapa bagian dari sistem (kemungkinan besar fungsi inti dari sistem) yang dikembangkan dengan cepat untuk disampaikan kepada pengguna.Beberapa jenis metode RAD juga mencoba untuk menjadi adaptif terhadap perubahan mungkin dalam proses bisnis dengan bersamaan melakukan semua fase pengembangan di (sekitar) waktu yang sama, seperti yang diwujudkan dalam Prototyping RAD dan Metodologi Pengembangan Agile.

RAD metodologi memperkenalkan penggunaan alat pengembangan maju seperti generator kode dangenerasi keempat bahasa pemrograman visual yang (4G) seperti Microsoft Visual Basic dan Borland Delphi.Penggunaan alat ini mempercepat proses pembangunan dan dalam tingkat tertentu menghasilkan kualitas yang lebih tinggi kode. Namun sebagai sistem dapat disampaikan dengan cepat, pengguna cenderung untuk mengubah harapan mereka tentang apa sistem dapat lakukan, sehingga persyaratan cenderung untuk berubah dan berkembang.

Ada tiga kategori dari RAD:

Phased Development ( Pengembangan bertahap ) 

Metode ini istirahat persyaratan menjadi serangkaian versi, berdasarkan yang beberapa versi dari sistem akan dibangun secara berurutan, menjadi fungsi yang paling mendasar dan penting dibundel dalam versi pertama. Berurutan di sini berarti bahwa pengembangan versi berikutnya akan dimulai hanya setelah versi sebelumnya telah disetujui dan dilaksanakan. Setiap versi memiliki sendiri Analisis-Desain-Implementasi fase (dalam skala yang lebih kecil dibandingkan dengan sistem secara keseluruhan). Semua versi ini nantinya akan disesuaikan untuk membentuk sistem yang lengkap yang memenuhi metode requirements. memberikan sistem yang berguna sangat cepat bagi pengguna, meskipun tidak mencakup semua fungsi dulu. Dan sebagai sistem akan dibangun berdasarkan versi berurutan banyak, sangat penting untuk mengidentifikasi fungsi penting dan mendasar untuk dimasukkan dalam versi pertama, sebuah analisis mendalam awal dari sistem ini adalah diperlukan.

Gambar 2. Metodologi Pengembangan bertahap

Prototyping

Metodologi ini digunakan biasanya ketika proses bisnis kemungkinan akan berubah sebagai hasil proyek atau ketika sponsor proyek memiliki sedikit gagasan tentang apa sistem yang akan dibangun. Analisis, Desain, dan fase Implementasi dilakukan secara bersamaan dan pada setiap siklus sehingga menghasilkan prototipe sistem yang akan ditinjau oleh sponsor proyek. Siklus diulang terus-menerus berdasarkan komentar sponsor sampai prototipe berhasil memenuhi persyaratan. Prototipe terakhir kemudian akan disebut pengembangan system.Prototyping hanya membutuhkan analisis dan desain dasar awal, tetapi sebagai akibatnya fungsi sistem yang penting tidak dapat diakui sampai di suatu tempat di tengah-tengah waktu proyek. Jadi ada kemungkinan untuk mengubah keputusan desain awal dan mulai dari awal lagi dari awal. Hal ini dapat memberikan sistem cepat bagi pengguna, meskipun tidak persis memenuhi persyaratan.

Figure 3. Metologi Prototyping 

Throw-away Prototyping

Throw-away Prototyping adalah mirip dengan metode Prototyping dalam hal itu juga mengembangkan prototipe. Tapi prototipe membuang-jauhnya agak presentasi saja, prototipe sebenarnya tidak apa-apa.Hal ini dimaksudkan untuk membantu pengguna memvisualisasikan sistem yang dibangun. Berdasarkan komentar pengguna, prototipe berikutnya terus dibangun sampai dapat memvisualisasikan sistem kerja yang nyata. Langkah berikutnya akan menerapkan sistem nyata. Ini prototipe membuang-jauhnya juga disebut dummy (mock-up) prototipe. Yang terbaik adalah jika mungkin untuk melakukan analisis awal menyeluruh sebelum pengembang mulai bekerja pada prototipe boneka pertama, sebagai dummy harus berisi rincian yang cukup tentang sistem nyata . Metode ini tidak memberikan sistem lengkap dalam timeline proyek seperti metode prototyping, tetapi pada akhirnya itu memberikan sistem yang lengkap sangat cepat. Ini umumnya memiliki waktu proyek yang lebih pendek dibandingkan dengan metode lain, karena bangunan boneka dianggap lebih mudah dan lebih memakan waktu daripada membangun prototipe bekerja.

Gambar 4. Throw-away Prototyping Metodologi

Object-oriented Analysis and Design ( Analisis berorientasi objek dan Desain )

Metodologi berorientasi objek dikembangkan berdasarkan pada kurangnya sinergi antara pendekatan proses-berpusat dan data-berpusat di SDLC. Dekomposisi sistem menjadi serangkaian proses (proses sentris) atau data (data sentris) tidak dapat dengan mudah diperoleh, karena kedua aspek yang erat terkait satu sama lain. Hal ini sulit untuk mengembangkan sistem dengan memfokuskan terutama hanya untuk satu aspek. Akibatnya, sistem yang dihasilkan cenderung diperpanjang hanya dalam satu dunia.Sebuah sistem proses yang dikembangkan sentris tidak dapat dengan mudah diperpanjang ketika ada perubahan dalam jenis data dalam sistem. Masalah seperti ini juga ada dalam sistem sentris data yang dikembangkan.

OO masalah metodologi terurai menjadi obyek. Objek dianggap sebagai bagian dari sistem yang mengandung baik proses dan data, sebuah objek dapat melakukan beberapa kegiatan / proses (dipetakan sebagai metode objek), sebuah objek juga mungkin memiliki negara (dipetakan sebagai atribut objek). Dengan cara ini, pengembang akan fokus pada entitas dalam sistem yang benar-benar proses dan membawa data, daripada fokus terutama hanya untuk satu aspek. OO berbasis pengembangan sistem ekstensif menggunakan alat yang disebut UML (Unified Modeling Language), yang merupakan set standar dalam diagram dan pemodelan teknik diciptakan oleh tiga juara OO, Grady Booch, Ivar Jacobson, dan James Rumbaugh, ketika mereka bekerja bersama dalam Rasional perangkat lunak. Pada tahun 1997 diusulkan untuk UML dan diterima oleh Object Management Group (OMG)sebagai notasi diagram standar dalam pengembangan berorientasi objek sistem.

Sebuah pendekatan OO dalam pengembangan sistem harus:

Use-case Drive

Ini berarti bahwa penggunaan-kasus adalah alat pemodelan utama untuk menentukan perilaku sistem. Gunakan-kasus menggambarkan bagaimana para pengguna sistem berinteraksi dengan sistem untuk melakukan aktivitas. Dan sebagai use case berfokus hanya untuk satu kegiatan pada satu waktu, itu adalah inheren sederhana.

Architecture Centric

Para arsitektur sentris jangka memberikan pandangan tingkat tinggi dari sistem yang dikembangkan.Arsitektur perangkat lunak yang dipilih untuk sistem harus drive spesifikasi, konstruksi, dan dokumentasi dari sistem itu sendiri. Arsitektur sistem harus mendukung tiga tampilan dari sistem:

• Functional View ( Tampilan Fungsional ) Menjelaskan perilaku sistem dari perspektif pengguna sistem. Gunakan kasus diagram digunakan untuk menggambarkan pandangan fungsional.
• Static view ( Tampilan Statis ) Menjelaskan struktur sistem dalam hal kelas, metode, atribut, dan hubungan objek dalam sistem.Pandangan ini digambarkan menggunakan CRC (Class Responsibility Kolaborasi) kartu, serta menggunakan diagram kelas dan objek.
• Dynamic View ( Tampilan Dinamis ) Menggambarkan perilaku sistem internal dalam hal komunikasi objek dan perubahan negara. Alat UML digunakan untuk menggambarkan pandangan ini adalah sequence diagram, diagram kolaborasi, dan negara-objek grafik.

Iteratif dan incremental

Iteratif dan incremental paradigma berarti bahwa setiap iterasi pengembangan sistem harus membawa sistem dekat dengan kebutuhan. Sebagai SDLC adalah proses bertahap, diagram UML digunakan dalam OO bergerak berbasis pengembangan dari hal yang konseptual dan abstrak dalam analisis dan tahap desain untuk menjadi lebih detail dan lebih dalam tahap implementasi.