PENGEMBANGAN APLIKASI SISTIM INFORMASI PROFESIONAL

Bab ini berpusat pada dua pendekatan umum pada pengembangan aplikasi yaitu: pendekatan pengembangan system life cycle yang tradisional (SDLC = systems development life cycle) dan suatu pendekatan propotip yang evolusiner. Banyak karakteristik pendekatan pengembangan system dan teknik yang lebih baru yang akan diuraikan dalam bab ini, menganggap benar untuk pendekatan pengembangan aplikasi yang digunakan di dalam perangkat lunak. Suatu perbedaan kunci, tentu saja, adalah bahwa ketika aplikasi kebiasaan dibangun untuk para manajer bisnis organisasi yang spesifik dan pemakai akhir yang akan menggunakan aplikasi itu dalam kehidupannya sehari-hari akan memainkan peran kunci di dalam proses pengembangan.

METODOLOGI SIKLUS KEHIDUPAN PENGEMBANGAN SISTEM

Siklus kehidupan tradisional itu memproses berbagai macam pengembangan aplikasi dan dikenal sebagai siklus kehidupan pengembangan sistem (SDLC).

Pendekatan SDLC juga menyediakan suatu baseline untuk pemahaman apa yang dilibatkan di dalam pengembangan suatu sistem aplikasi, apakah oleh para profesional SISTEM INFORMASI yang dipekerjakan oleh suatu pabrikasi atau perusahaan jasa, dengan para profesional SISTEM INFORMASI yang dipekerjakan oleh suatu perusahaan pengembangan software atau konsultasi, atau oleh beberapa spesial kombinasi SISTEM INFORMASI internal dan eksternal.

Langkah-langkah SDLC

Metodologi SDLC umumnya meliputi tiga fase dan delapan langkah. Keseluruhan daya dorong ke tiga tahap SDLC adalah yang secara langsung. Tahap definisi adalah kritis menggambarkan dengan tepat apa yang sistem harus lakukan dalam detail yang jelas untuk spesialis SISTEM INFORMASI untuk membangun sistem yang benar. Di dalam tahap konstruksi, spesialis SISTEM INFORMASI menghasilkan suatu sistem kerja yang permanen menurut spesifikasi di dalam tahap lebih awal. Di dalam tahap implementasi, sistem yangbaru diinstal, menjadi operasional di dalam organisasi dan dirawat jika dibutuhkan sedemikian sehingga lebih lanjut untuk mencerminkan pengubahan kebutuhan organisasi. Dua langkah-langkah terakhir yaitu operasi dan pemeliharaan, dimasukkan dalam peredaran hidup untuk secara formal mengenali aplikasi kebiasaan yang besar itu adalah penanaman modal utama untuk suatu organisasi yang akan berlanjut untuk mempunyai biaya operasi.

Pemicu Proyek Sistem Baru

Ada tiga pendekatan yang digunakan oleh organisasi untuk memutuskan aplikasi baru yang mana yang akan digunakan untuk menanamkan modal. Di dalam beberapa organisasi proses dimulai dnegan ketundukan suatu proposal formal oleh suatu departemen bisnis. Beberapa organisasi besar menentukan bahwa proposal ini yang pertama ditinjau dan diprioritaskan oleh suatu panitia di departemen atau divisi pengukuran. Ketika sumber daya dan ivestasi substansiil dilibatkan, departemen mungkin diperlukan untuk menantikan suatu persetujuan tahunan dan prioritisasi memproses untuk terjadi. Ketika suatu proposal disetujui dan sumber daya SISTEM INFORMASI secara formal ditugaskan kepada proyek, proses SDLC yang formal mulai.

Tahap Definisi

Analisa kelayakan untuk langkah yang pertama proses SDLC ini manager proyek atau analis sistem secara khas ditugaskan yang akan bekerja bersama dengan para manajer bisnis untuk mempersiapkan suatu analisa yang seksama tentang kelayakan sistem yang diusulkan itu. Tiga jenis kelayakan yang berbeda akan ditaksir yaitu: ekonomi, operasional, dan kelayakan teknis. Analis SISTEM INFORMASI bekerja dekat dengan cara mensponsori para manajer yang mengusulkan sistem dan para manajer bisnis lain, untuk menggambarkan dalam beberapa detil apa sistem yang baru akan dilakukan, keluaran apa yang akan menghasilkan, masukan apa yang akan diterima, bagaimana masukan data boleh diperoleh, dan database apa yang diperlukan.

Kedua-duanya para manajer bisnis dan analis SISTEM INFORMASI bekerja sama untuk menyiapkan suatu analisa biaya sistem yang diusulkan menentukan kelayakan ekonomi. Analis SISTEM INFORMASI mempunyai tanggung jawab utama untuk menetapkan biaya-biaya pengembangan proyek.

Definisi Kebutuhan

Jika dokumen yang diproduksi dari analisa kelayakan menerima persetujuan organisatoris yang diperlukan, langkah definisi kebutuhan dimulai. Sebab melukiskan kebutuhan untuk suatu sistem adalah tugas rumit dan sulit seperti itu, analisis bersandar pada sejumlah teknik dan pendekatan. Yang bisa menyampaikan langkah definisi kebutuhan adalah suatu dokumen kebutuhan sistem menyeluruh yang berisi uraian yang terperinci masukan sistem dan keluaran, dan proses yang digunakan untuk mengkonversi data masukan kepada data keluaran. Langkah ini secara khas tunduk kepada persetujuan para manajer bisnis buat siapa sistem dibangun seperti halnya oleh para manajer SISTEM INFORMASI yang sesuai.

Tahap Konstruksi

· Disain sistem

Di dalam langkah ini, spesialis SISTEM INFORMASI medisain sistem phisik berdasarkan pada dokumen kebutuhan yang konseptual dari tahap definisi.

· Sistem yang membangun

Ada dua aktivitas yang terlibat di dalam membangun system-producing program komputer itu dan pengembangan database dan memfile untuk digunakan oleh sistem. Aktivitas ini dilakukan oleh spesialis SISTEM INFORMASI.

· Sistem pengujian

Pengujian adalah suatu usaha besar-besaran yang diperlukan oleh banyak orang sebanyak waktu menulis kode untuk sistem itu. Langkah ini melibatkan pengujian pertama oleh spesialis SISTEM INFORMASI yang diikuti oleh para pemakai yang menguji. Pertama, modul masing-masing kode harus diuji. Kemudian modul dirakit ke dalam subsistem dan menguji. Akhirnya subsistme dikombinasikan dan keseluruhan.

· Sistem pengintegrasian diuji

Dokumentasi sistem adalah juga suatu mekanisme komunikasi utama di antara berbagai anggota regu proyek sepanjang proses pengembangan, sistem informasiyang terlalu kompleks untuk memahami dengan lisan.

Tahap Implementasi

Sukses awal tahap implementasi adalah sangat tergantung pada kepentingan peran manajer bisnis.

Instalasi

Kedua-keduanya spesialis SISTEM INFORMASI dan para pemakai, memainkan peran kritis di dalam langkah instalasi, yang meliputi membangun database dan file dan mengubah data relevan dari sistem lama kepada sistem yang baru. Aktivitas Instalasi rumit lain adalah pelatihan pemakai akhir sistem, seperti halnya pelatihan lain para pemakai yang dilibatkan oleh sistem yang baru itu, menerapkan perangkat keras dan lunak adalah tanggung jawab organisasi. Mengubah kepada sistem yang baru mungkin adalah suatu proses sulit untuk para pemakai sebab sistem yang baru harus terintegrasi ke dalam aktivitas organisasi itu. Para pemakai harus tidak hanya belajar tentang bagaiman cara menggunakan sistem yang baru, tetapi juga merubah cara mereka melaksanakan pekerjaan mereka. Sekalipun perangkat lunak secara teknis sempurna, sistem akan mengalami suatu kegagalan jika orang-orang tidak ingin ia untuk bekerja atau tidak mengetahui bagaimana cara menggunakannya. Proses koversi memerlukan attitudinal untuk berubah. Adalah suatu kekeliruan untuk berasumsi bahwa orang-orang akan mengubah perilaku mereka ke dalam cara yang diharapkan atau yang diinginkan. Beberapa strategi untuk transisi para pemakai dari suatu sistem lama untuk yang baru biasanya digunakan : di dalam strategi yang paralel, organisasi berlanjut untuk beroperasi kaum tua sistem di dalam paralel dengan sistem yang baru sampai yang baru sedang bekerja dengan cukup baik untuk menghentikan kaum tua. Strategi Pilot (sistem mana dulu yang mau dibenahi/diserang baru bagian-bagian lainnya yang baru dibenahi) adalah suatu pilihan yang menarik ketika mungkin untuk memperkenalkan sistem yang baru di dalam satu bagian dari organisasi. Untuk yang besar, sistem kompleks, suatu koversi dibuat dengan strategi bertahap mungkin merupakan pendekatan yang terbaik. Di dalam perubahan strategi, organisasi secara total meninggalkan sistem tua ketika mengimplementasikan sistem yang baru. Kombinasi di atas empat strategi adalah juga mungkin.

Operasi

Langkah tahap implementasi yang kedua adalah untuk mengoperasikan aplikasi yang baru ke dalam “gaya produksi”. Di dalam langkah operasi, tanggung jawab SISTEM INFORMASI untuk aplikasi diserahkan ke operasi komputer dan personil pendukung teknis. Aplikasi baru secara khas tidak dipindah ke status produksi kecuali jika dokumentasi cukup telah disajikan oleh manager proyek.

Pemeliharaan

Pemeliharaan mengacu pada proses bagaimana mengubah suatu sistem setelah memasuki gaya produksi. Alasan yang paling jelas nyata untuk pemeliharaan adalah jangan mengoreksi kesalahan di perangkat lunak yang tidak ditemukan dan mengoreksi sebelum implementasi awalnya. Untuk melakukan perubahan suatu sistem, pemeliharaan programmer harus : pertama menentukan program apa yang harus diubah dan kemudian bagian-bagian apa dari spesifik masing-masing program yang perlu untuk diubah. Masalah utama lain dengan pemeliharaan adalah bahwa kebanyakan para profesional SISTEM INFORMASI menyukai untuk bekerja pada sistem baru yang menggunakan teknologi baru, dibanding memelihara sistem lama.

· Peran SDLC

Kebanyakan sistem aplikasi dikembangkan oleh suatu regu proyek temporer. Ketika proyek sistem diselesaikan, regu dibubarkan. Kebanyakan regu proyek meliputi wakil dari kedua-duanya organisasi SISTEM INFORMASI dan departemen bisnis yang relevan. Jika sistem akan digunakan dengan beberapa kesatuan organisasi atau oleh beberapa tingkatan orang-orang di dalam suatu unit, proyek regu boleh meliputi wakil dari hanya sebagian dari unit berbeda ini, termasuk para manajer tingkat yang lebih tinggi dan pemakai akhir yang berpengalaman siapa yang akan bekerja dengan aplikasi yang baru pada basis sehari-hari. Untuk itu pemilihan proyek regu kemudian menjadi sangat kritis supaya menghasilkan kesuksesan proyek sistem yang ditentukan.

· Memanage suatu rancangan SDLC

Semua proyek sistem secara khas diukur oleh tiga ukuran-ukuran sukses utama: mutu sistem, waktu penyelesaian dan biaya proyek. Tiga dari karakteristik suatu proyek pengembangan aplikasi:

Ukuran Proyek Dapat Dikendalikan

Pengalaman telah menunjukkan dengan meyakinkan bahwa proyek yang sangat besar menuntut beratus-ratus tahun pekerjaan usaha pengembangan, adalah sangat sukar untuk menyampaikan. Keseluruhan sistem kemudian bisa membangun sebagai urutan proyek dapat dikendalikan kecil, dibanding sebagai proyek raksasa tunggal.

Definisi Kebutuhan Akurat

Proses air terjun SDLC didasarkan pada pendapat tentang kebutuhan suatu sistem baru yang dapat digambarkan secara detil pada awal proses.

Sponsor Eksekutif

Walaupun semua proyek sistem besar memerlukan sponsor bisnis, intensitas dan panjangnya waktu yang dibutuhkan dengan SDLC proyek yang khas, hal ini berarti sponsor level eksekutif sangat menentukan. Para manajer bisnis perlu memahami keuntungan-keuntungan sistem potensial yang diusulkan dan dipersembahkan untuk menyokong sumber daya regu proyek sistem, seperti halnya pemakaian yang didukung oleh aplikasi kebiasaan yang baru.

· Keuntungan dan kerugian SDLC

Ditangan spesialis SISTEM INFORMASI dan para manajer bisnis yang berwawasan, proses SDLC ditetapkan secara formal langkah-langkah peran para pemakai secara jelas, pos pemeriksaan formal dan teknik untuk analisa, disain, pengujian dan implementasi. Perkakas ini dan disiplin yang kaku berhubungan dengan suatu metodologi SDLC yang membantu hasil manager proyek sistem sehingga menghasilkan suatu sistem *** yang baik, tepat waktu dan tepat di dalam anggaran.

Kerugian yang utama yang tidak bisa dipisahkan di dalam metodologi yaitu, Pertama, kesuksesan proyek bergantung pada keakuratan dan spesifikasi yang lengkap tentang kebutuhan yang terperinci pada permulaan pengembangan proses. Kedua, SDLC proses adalah suatu proses yang memakan waktu.

MEMBUAT PROTOTIP METODOLOGI

SDLC metodologi didasarkan pada pendapat tentang kebutuhan bisnis untuk sistem yang akan menjadi statis di dalam keseluruhan hidup proyek. Untuk itu, kebutuhan sistem harus ditetapkan dengan sepenuhnya dan harus diakhir sebelum tahap konstruksi dimulai. Ketika kebutuhan telah disetujui maka akan mengubah mereka memimpin ke arah biaya-biaya proyek penting dan keterlambatan jadwal potensial.

Pendekatan umum dipakai untuk mengetahui pembuatan prototip. Ini merupakan suatu jenis pengembangan evolusiner di dalam memproses. Membuat prototip konsep dapat juga diberlakukan bagi suatu proses dimana di dalam sistem ini dikembangkan untuk pemakai untuk mencoba seperti halnya untuk situasi dimana saja “suatu permainan” prototipe dikembangkan.

Dibagian yang berikutnya, kita pertama mendiskusikan. Membuat prototip sebagai alternatif lengkap untuk metodologi SDLC yang tradisional: langkah-langkahnya, pertimbangan manajemen proyek dan kerugian dan keuntungan keseluruhan dari perbandingan kepada suatu metodologi SDLC. Membuat prototip sebagai suatu alternatif bagi suatu metodologi SDLC adalah tidak praktis untuk memperbesar usaha sistem kompleks. Bagaimanapun ketika membuat prototip digunakan di dalam suatu SDLC memproses untuk membantu menentukan kebutuhan suatu aplikasi kebiasaan baru.

· Langkah-langkah Membuat Prototip

Proses mulai dengan identifikasi kebutuhan dasar versi awal sistem (step I). Di dalam langkah 2 pembangun sistem menghasilkan suatu sistem prototipe awal menurut kebutuhan yang basis dasar yang telah disetujui sejalan dengan langkah I. Langkah 3 adalah tanggung jawab pemakai itu. Di dalam langkah 4 pembangun memodifikasi sistem tersebut untuk menyertakan perubahan yang diinginkan. Langkah 5 melibatkan mengevaluasi prototipe yang akhir sebagai suatu sistem operasional. Langkah ke 6 pembangun sistem melengkapi menyudahi tahap konstruksi dengan pembuatan perubahan apapun yang diperlukan untuk meningkatkan efisiensi operasional dna untuk menghubungkan aplikasi yang baru dengan sistem yang operasional yang menyediakan data. Langkah ke 7 sama dengan tahap implementasi SDLC, sistem yang baru diinstal dan dipindah ke status operasional.

· Peran Prototipe

Memanage suatu proses pengembangan evolusiner secara jelas adalah dengan cara bergabung dengan LS dan tanggung jawab manajemen pemakai. Ya atau tidaknya peran manager proyek dimainkan oleh SISTEM INFORMASI itu sendiri, personil bisnis atau kedua-duanya SISTEM INFORMASI dan personil bisnis, kedua kelompok tersebut harus bresama-sama menentukan ketika melanjutkan meminta revisi kepada suatu prototipe, dan ketika interative percobaan itu berakhir dan meminjam kembali langkah-langkah. Sebab hanya kebutuhan basis dasar yang akan digambarkan analis sistem dan prototipe pembangun harus mempunyai beberapa ketrampilan berbeda menetapkan dibanding memerlukan untuk SDLC proses. Suatu pembuatan metodologi prototip juga memerlukan suatu yang mempunyai dedikasi peran pemakai akhir. Sebab ada pemakai berkesinambungan yang melibatkannya dengan berbagai versi sistem, pemakai akhir perlu untuk dibebaskan dari tanggung jawab lain untuk bekerja sama dengan aplikasi dan untuk pertukaran hidup proyek.

· Memanage suatu pembuatan prototip proyek

Memanage suatu pengembangan baru merancang dengan suatu metodologi berdasar pada suatu interative atau proses evolusiner memerlukan suatu mindset berbeda dibanding memanage proyek dengan menggunakan suatu metodologi SDLC berdasar pada suatu pendekatan pengembangan yang sangat terstruktur. Para manajer SISTEM INFORMASI juga menemukan cara memanage prototip proyek yang lebih sukar yang disebabkan karena kesulitan perencanaan berapa lama ini akan diambil, berapa banyak perkataan berulang-ulang akan diperlukan, atau persisnya ketika pembangun sistem akan bekerja pada sistem.

· Keuntungan dan kerugian pembuatan prototip

Keuntungan dari metodologi pengembangan evolusiner menunjuk kerugian yang tidak bisa dipisahkan di dalam metodologi SDLC. Pertama, hanya kebutuhan sistem basis dasar yang diperlukan yang dihadapi untuk proyek. Ke dua, suatu sistem awal kerja tersedia untuk pemakai menguji jauh lebih dengan cepat. Ketiga, oleh karena alam interaktif dari proses, dnegan penggunaan model sistem kerja langsung, topdown komitmen kuat berdasar pada suatu pertimbangan proses mungkin lebih sedikit perlu. Keempat, pemakai awal penerimaan terhadap suatu aplikasi pengembangan dengan suatu proses evolusiner adalah nampaknya lebih tinggi dibanding dengan suatu SDLC memproses.

Kerugian-kerugian dari suatu metodologi evolusiner dihubungkan dengan bangunan yang evolusiner memproses, prototipe akhir secara khas kekurangan sebagian dari keamanan dan mengendalikan corak menemukan di dalam suatu sistem pengembangan dengan suatu SDLC proses. Kerugian potensi lain dihubungkan dengan memanage harapan pemakai.

· Membuat prototip di dalam suatu proses SDLC

Di dalam paragrap yang berikut kita akan menguraikan dua arah jalan bahwa pembuatan prototip biasanya disatukan ke dalam suatu SDLC proses. Pertama, pembuatan prototip digunakan di dalam tahap definisi untuk membantu para pemakai dalam menggambarkan kebutuhan sistem, terutama sekali untuk menghubungkan pemakai. Kedua cara membuat prototip yang digunakan menjadi lebih kompleks dan meliputi suatu implementasi pilot yang bekerja bagi prototipe.

PENDEKATAN LEBIH BARU

Permintaan untuk pengembangan yang lebih cepat dari aplikasi sistem baru mempunyai peningkatan yang lebih mantap diatas decade masa lalu. Di dalam bagian ini kita dengan singkat akan mendiskusikan beberapa pendekatan yang telah ditunjukkan untuk melihat pengembangan lebih cepat dari mutu tinggi aplikasi yang bermacam-macam.

· Desain Aplikasi Bersama (JAD)

JAD adalah suatu teknik dimana suatu regu para pemakai dan spesialis SISTEM INFORMASI terlibat dalam suatu proses yang kuat dan tersusun untuk mengembangkan disain sistem yang bis mengirim.

Sasaran pokok JAD teknik adalah untuk memperkecil total waktu yang diperlukan untuk informasi yang didapatkan dari banyak peserta.

· Rancang-Bangun Perangkat Lunak Computer-Aided (CASE)

Mengacu pada suatu koleksi perkakas perangkat lunak yang digunakan untuk mengotomatiskan beberapa atau semua tahap dari suatu SDLC proses, paket software CASE hanya mempunyai perkakas analisa awal dan akhir untuk mendukung langkah-langkah disain sistem dan definisi kebutuhan SDLC dikenal sebagai perkakas huruf besar.

· Pengembangan Aplikasi Cepat (RAD)

RAD adalah suatu metodologi campuran yang merupakan kombinasi dari aspek SDLC metodologi dan pembuatan prototip seperti halnya JAD teknik dan perkakas CASE. Tujuannya adalah untuk menghasilkan suatu sistem di dalam waktu enam bulan atau lebih sedikit.

Satu perbedaan kunci antar pendekatan membuat prototip yang khas dan pendekatan RAD adalah bahwa sistem dan pos pemeriksaan struktur checkpoint adalah tanda dari suatu pendekatan SDLC yang ditahan. Perbedaannya adalah bahwa ketika para pemakai mematikan tanda pada awal Dokumen Disain dasar CASE mereka mengetahui bahwa mereka juga dilibatkan di dalam langkah konstruksi, dan bahwa semua kaleng disain tetap dibuat sebagaimana diperlukan.

Serangkaian perintah yang sudah logis lalu dikompare sehingga siap saji/siap pakai. O-O juga menjaga janji besar untuk memproduksi sistem yang lebih baik dengan lebih sedikit biaya, dan perkakas untuk mendukung pendekatan ini sedang menjadi semakin siap tersedia.

TAHUN 2000 PEMELIHARAAN AFTERMATCH : APA YANG KITA MEMPELAJARI

Pemeliharaan pada tahun 2000 adalah suatu tantangan global penting. Ketiadaan komputer glitches dalam kaitannya dengan mengkoordinir usaha dan pembelanjaan dolar besar. Para manajer SISTEM INFORMASI melaporkan bahwa ada juga beberapa manfaat tidak langsung dari proyek kerja Y2K, mencakup pengujian sistem ditingkatkan dan mengubah prosedur kendali.

Bab ini berpusat pada dua pendekatan umum pada pengembangan aplikasi yaitu: pendekatan pengembangan system life cycle yang tradisional (SDLC = systems development life cycle) dan suatu pendekatan propotip yang evolusiner. Banyak karakteristik pendekatan pengembangan system dan teknik yang lebih baru yang akan diuraikan dalam bab ini, menganggap benar untuk pendekatan pengembangan aplikasi yang digunakan di dalam perangkat lunak. Suatu perbedaan kunci, tentu saja, adalah bahwa ketika aplikasi kebiasaan dibangun untuk para manajer bisnis organisasi yang spesifik dan pemakai akhir yang akan menggunakan aplikasi itu dalam kehidupannya sehari-hari akan memainkan peran kunci di dalam proses pengembangan.

METODOLOGI SIKLUS KEHIDUPAN PENGEMBANGAN SISTEM

Siklus kehidupan tradisional itu memproses berbagai macam pengembangan aplikasi dan dikenal sebagai siklus kehidupan pengembangan sistem (SDLC).

Pendekatan SDLC juga menyediakan suatu baseline untuk pemahaman apa yang dilibatkan di dalam pengembangan suatu sistem aplikasi, apakah oleh para profesional SISTEM INFORMASI yang dipekerjakan oleh suatu pabrikasi atau perusahaan jasa, dengan para profesional SISTEM INFORMASI yang dipekerjakan oleh suatu perusahaan pengembangan software atau konsultasi, atau oleh beberapa spesial kombinasi SISTEM INFORMASI internal dan eksternal.

Langkah-langkah SDLC

Metodologi SDLC umumnya meliputi tiga fase dan delapan langkah. Keseluruhan daya dorong ke tiga tahap SDLC adalah yang secara langsung. Tahap definisi adalah kritis menggambarkan dengan tepat apa yang sistem harus lakukan dalam detail yang jelas untuk spesialis SISTEM INFORMASI untuk membangun sistem yang benar. Di dalam tahap konstruksi, spesialis SISTEM INFORMASI menghasilkan suatu sistem kerja yang permanen menurut spesifikasi di dalam tahap lebih awal. Di dalam tahap implementasi, sistem yangbaru diinstal, menjadi operasional di dalam organisasi dan dirawat jika dibutuhkan sedemikian sehingga lebih lanjut untuk mencerminkan pengubahan kebutuhan organisasi. Dua langkah-langkah terakhir yaitu operasi dan pemeliharaan, dimasukkan dalam peredaran hidup untuk secara formal mengenali aplikasi kebiasaan yang besar itu adalah penanaman modal utama untuk suatu organisasi yang akan berlanjut untuk mempunyai biaya operasi.

Pemicu Proyek Sistem Baru

Ada tiga pendekatan yang digunakan oleh organisasi untuk memutuskan aplikasi baru yang mana yang akan digunakan untuk menanamkan modal. Di dalam beberapa organisasi proses dimulai dnegan ketundukan suatu proposal formal oleh suatu departemen bisnis. Beberapa organisasi besar menentukan bahwa proposal ini yang pertama ditinjau dan diprioritaskan oleh suatu panitia di departemen atau divisi pengukuran. Ketika sumber daya dan ivestasi substansiil dilibatkan, departemen mungkin diperlukan untuk menantikan suatu persetujuan tahunan dan prioritisasi memproses untuk terjadi. Ketika suatu proposal disetujui dan sumber daya SISTEM INFORMASI secara formal ditugaskan kepada proyek, proses SDLC yang formal mulai.

Tahap Definisi

Analisa kelayakan untuk langkah yang pertama proses SDLC ini manager proyek atau analis sistem secara khas ditugaskan yang akan bekerja bersama dengan para manajer bisnis untuk mempersiapkan suatu analisa yang seksama tentang kelayakan sistem yang diusulkan itu. Tiga jenis kelayakan yang berbeda akan ditaksir yaitu: ekonomi, operasional, dan kelayakan teknis. Analis SISTEM INFORMASI bekerja dekat dengan cara mensponsori para manajer yang mengusulkan sistem dan para manajer bisnis lain, untuk menggambarkan dalam beberapa detil apa sistem yang baru akan dilakukan, keluaran apa yang akan menghasilkan, masukan apa yang akan diterima, bagaimana masukan data boleh diperoleh, dan database apa yang diperlukan.

Kedua-duanya para manajer bisnis dan analis SISTEM INFORMASI bekerja sama untuk menyiapkan suatu analisa biaya sistem yang diusulkan menentukan kelayakan ekonomi. Analis SISTEM INFORMASI mempunyai tanggung jawab utama untuk menetapkan biaya-biaya pengembangan proyek.

Definisi Kebutuhan

Jika dokumen yang diproduksi dari analisa kelayakan menerima persetujuan organisatoris yang diperlukan, langkah definisi kebutuhan dimulai. Sebab melukiskan kebutuhan untuk suatu sistem adalah tugas rumit dan sulit seperti itu, analisis bersandar pada sejumlah teknik dan pendekatan. Yang bisa menyampaikan langkah definisi kebutuhan adalah suatu dokumen kebutuhan sistem menyeluruh yang berisi uraian yang terperinci masukan sistem dan keluaran, dan proses yang digunakan untuk mengkonversi data masukan kepada data keluaran. Langkah ini secara khas tunduk kepada persetujuan para manajer bisnis buat siapa sistem dibangun seperti halnya oleh para manajer SISTEM INFORMASI yang sesuai.

Tahap Konstruksi

· Disain sistem

Di dalam langkah ini, spesialis SISTEM INFORMASI medisain sistem phisik berdasarkan pada dokumen kebutuhan yang konseptual dari tahap definisi.

· Sistem yang membangun

Ada dua aktivitas yang terlibat di dalam membangun system-producing program komputer itu dan pengembangan database dan memfile untuk digunakan oleh sistem. Aktivitas ini dilakukan oleh spesialis SISTEM INFORMASI.

· Sistem pengujian

Pengujian adalah suatu usaha besar-besaran yang diperlukan oleh banyak orang sebanyak waktu menulis kode untuk sistem itu. Langkah ini melibatkan pengujian pertama oleh spesialis SISTEM INFORMASI yang diikuti oleh para pemakai yang menguji. Pertama, modul masing-masing kode harus diuji. Kemudian modul dirakit ke dalam subsistem dan menguji. Akhirnya subsistme dikombinasikan dan keseluruhan.

· Sistem pengintegrasian diuji

Dokumentasi sistem adalah juga suatu mekanisme komunikasi utama di antara berbagai anggota regu proyek sepanjang proses pengembangan, sistem informasiyang terlalu kompleks untuk memahami dengan lisan.

Tahap Implementasi

Sukses awal tahap implementasi adalah sangat tergantung pada kepentingan peran manajer bisnis.

Instalasi

Kedua-keduanya spesialis SISTEM INFORMASI dan para pemakai, memainkan peran kritis di dalam langkah instalasi, yang meliputi membangun database dan file dan mengubah data relevan dari sistem lama kepada sistem yang baru. Aktivitas Instalasi rumit lain adalah pelatihan pemakai akhir sistem, seperti halnya pelatihan lain para pemakai yang dilibatkan oleh sistem yang baru itu, menerapkan perangkat keras dan lunak adalah tanggung jawab organisasi. Mengubah kepada sistem yang baru mungkin adalah suatu proses sulit untuk para pemakai sebab sistem yang baru harus terintegrasi ke dalam aktivitas organisasi itu. Para pemakai harus tidak hanya belajar tentang bagaiman cara menggunakan sistem yang baru, tetapi juga merubah cara mereka melaksanakan pekerjaan mereka. Sekalipun perangkat lunak secara teknis sempurna, sistem akan mengalami suatu kegagalan jika orang-orang tidak ingin ia untuk bekerja atau tidak mengetahui bagaimana cara menggunakannya. Proses koversi memerlukan attitudinal untuk berubah. Adalah suatu kekeliruan untuk berasumsi bahwa orang-orang akan mengubah perilaku mereka ke dalam cara yang diharapkan atau yang diinginkan. Beberapa strategi untuk transisi para pemakai dari suatu sistem lama untuk yang baru biasanya digunakan : di dalam strategi yang paralel, organisasi berlanjut untuk beroperasi kaum tua sistem di dalam paralel dengan sistem yang baru sampai yang baru sedang bekerja dengan cukup baik untuk menghentikan kaum tua. Strategi Pilot (sistem mana dulu yang mau dibenahi/diserang baru bagian-bagian lainnya yang baru dibenahi) adalah suatu pilihan yang menarik ketika mungkin untuk memperkenalkan sistem yang baru di dalam satu bagian dari organisasi. Untuk yang besar, sistem kompleks, suatu koversi dibuat dengan strategi bertahap mungkin merupakan pendekatan yang terbaik. Di dalam perubahan strategi, organisasi secara total meninggalkan sistem tua ketika mengimplementasikan sistem yang baru. Kombinasi di atas empat strategi adalah juga mungkin.

Operasi

Langkah tahap implementasi yang kedua adalah untuk mengoperasikan aplikasi yang baru ke dalam “gaya produksi”. Di dalam langkah operasi, tanggung jawab SISTEM INFORMASI untuk aplikasi diserahkan ke operasi komputer dan personil pendukung teknis. Aplikasi baru secara khas tidak dipindah ke status produksi kecuali jika dokumentasi cukup telah disajikan oleh manager proyek.

Pemeliharaan

Pemeliharaan mengacu pada proses bagaimana mengubah suatu sistem setelah memasuki gaya produksi. Alasan yang paling jelas nyata untuk pemeliharaan adalah jangan mengoreksi kesalahan di perangkat lunak yang tidak ditemukan dan mengoreksi sebelum implementasi awalnya. Untuk melakukan perubahan suatu sistem, pemeliharaan programmer harus : pertama menentukan program apa yang harus diubah dan kemudian bagian-bagian apa dari spesifik masing-masing program yang perlu untuk diubah. Masalah utama lain dengan pemeliharaan adalah bahwa kebanyakan para profesional SISTEM INFORMASI menyukai untuk bekerja pada sistem baru yang menggunakan teknologi baru, dibanding memelihara sistem lama.

· Peran SDLC

Kebanyakan sistem aplikasi dikembangkan oleh suatu regu proyek temporer. Ketika proyek sistem diselesaikan, regu dibubarkan. Kebanyakan regu proyek meliputi wakil dari kedua-duanya organisasi SISTEM INFORMASI dan departemen bisnis yang relevan. Jika sistem akan digunakan dengan beberapa kesatuan organisasi atau oleh beberapa tingkatan orang-orang di dalam suatu unit, proyek regu boleh meliputi wakil dari hanya sebagian dari unit berbeda ini, termasuk para manajer tingkat yang lebih tinggi dan pemakai akhir yang berpengalaman siapa yang akan bekerja dengan aplikasi yang baru pada basis sehari-hari. Untuk itu pemilihan proyek regu kemudian menjadi sangat kritis supaya menghasilkan kesuksesan proyek sistem yang ditentukan.

· Memanage suatu rancangan SDLC

Semua proyek sistem secara khas diukur oleh tiga ukuran-ukuran sukses utama: mutu sistem, waktu penyelesaian dan biaya proyek. Tiga dari karakteristik suatu proyek pengembangan aplikasi:

Ukuran Proyek Dapat Dikendalikan

Pengalaman telah menunjukkan dengan meyakinkan bahwa proyek yang sangat besar menuntut beratus-ratus tahun pekerjaan usaha pengembangan, adalah sangat sukar untuk menyampaikan. Keseluruhan sistem kemudian bisa membangun sebagai urutan proyek dapat dikendalikan kecil, dibanding sebagai proyek raksasa tunggal.

Definisi Kebutuhan Akurat

Proses air terjun SDLC didasarkan pada pendapat tentang kebutuhan suatu sistem baru yang dapat digambarkan secara detil pada awal proses.

Sponsor Eksekutif

Walaupun semua proyek sistem besar memerlukan sponsor bisnis, intensitas dan panjangnya waktu yang dibutuhkan dengan SDLC proyek yang khas, hal ini berarti sponsor level eksekutif sangat menentukan. Para manajer bisnis perlu memahami keuntungan-keuntungan sistem potensial yang diusulkan dan dipersembahkan untuk menyokong sumber daya regu proyek sistem, seperti halnya pemakaian yang didukung oleh aplikasi kebiasaan yang baru.

· Keuntungan dan kerugian SDLC

Ditangan spesialis SISTEM INFORMASI dan para manajer bisnis yang berwawasan, proses SDLC ditetapkan secara formal langkah-langkah peran para pemakai secara jelas, pos pemeriksaan formal dan teknik untuk analisa, disain, pengujian dan implementasi. Perkakas ini dan disiplin yang kaku berhubungan dengan suatu metodologi SDLC yang membantu hasil manager proyek sistem sehingga menghasilkan suatu sistem *** yang baik, tepat waktu dan tepat di dalam anggaran.

Kerugian yang utama yang tidak bisa dipisahkan di dalam metodologi yaitu, Pertama, kesuksesan proyek bergantung pada keakuratan dan spesifikasi yang lengkap tentang kebutuhan yang terperinci pada permulaan pengembangan proses. Kedua, SDLC proses adalah suatu proses yang memakan waktu.

MEMBUAT PROTOTIP METODOLOGI

SDLC metodologi didasarkan pada pendapat tentang kebutuhan bisnis untuk sistem yang akan menjadi statis di dalam keseluruhan hidup proyek. Untuk itu, kebutuhan sistem harus ditetapkan dengan sepenuhnya dan harus diakhir sebelum tahap konstruksi dimulai. Ketika kebutuhan telah disetujui maka akan mengubah mereka memimpin ke arah biaya-biaya proyek penting dan keterlambatan jadwal potensial.

Pendekatan umum dipakai untuk mengetahui pembuatan prototip. Ini merupakan suatu jenis pengembangan evolusiner di dalam memproses. Membuat prototip konsep dapat juga diberlakukan bagi suatu proses dimana di dalam sistem ini dikembangkan untuk pemakai untuk mencoba seperti halnya untuk situasi dimana saja “suatu permainan” prototipe dikembangkan.

Dibagian yang berikutnya, kita pertama mendiskusikan. Membuat prototip sebagai alternatif lengkap untuk metodologi SDLC yang tradisional: langkah-langkahnya, pertimbangan manajemen proyek dan kerugian dan keuntungan keseluruhan dari perbandingan kepada suatu metodologi SDLC. Membuat prototip sebagai suatu alternatif bagi suatu metodologi SDLC adalah tidak praktis untuk memperbesar usaha sistem kompleks. Bagaimanapun ketika membuat prototip digunakan di dalam suatu SDLC memproses untuk membantu menentukan kebutuhan suatu aplikasi kebiasaan baru.

· Langkah-langkah Membuat Prototip

Proses mulai dengan identifikasi kebutuhan dasar versi awal sistem (step I). Di dalam langkah 2 pembangun sistem menghasilkan suatu sistem prototipe awal menurut kebutuhan yang basis dasar yang telah disetujui sejalan dengan langkah I. Langkah 3 adalah tanggung jawab pemakai itu. Di dalam langkah 4 pembangun memodifikasi sistem tersebut untuk menyertakan perubahan yang diinginkan. Langkah 5 melibatkan mengevaluasi prototipe yang akhir sebagai suatu sistem operasional. Langkah ke 6 pembangun sistem melengkapi menyudahi tahap konstruksi dengan pembuatan perubahan apapun yang diperlukan untuk meningkatkan efisiensi operasional dna untuk menghubungkan aplikasi yang baru dengan sistem yang operasional yang menyediakan data. Langkah ke 7 sama dengan tahap implementasi SDLC, sistem yang baru diinstal dan dipindah ke status operasional.

· Peran Prototipe

Memanage suatu proses pengembangan evolusiner secara jelas adalah dengan cara bergabung dengan LS dan tanggung jawab manajemen pemakai. Ya atau tidaknya peran manager proyek dimainkan oleh SISTEM INFORMASI itu sendiri, personil bisnis atau kedua-duanya SISTEM INFORMASI dan personil bisnis, kedua kelompok tersebut harus bresama-sama menentukan ketika melanjutkan meminta revisi kepada suatu prototipe, dan ketika interative percobaan itu berakhir dan meminjam kembali langkah-langkah. Sebab hanya kebutuhan basis dasar yang akan digambarkan analis sistem dan prototipe pembangun harus mempunyai beberapa ketrampilan berbeda menetapkan dibanding memerlukan untuk SDLC proses. Suatu pembuatan metodologi prototip juga memerlukan suatu yang mempunyai dedikasi peran pemakai akhir. Sebab ada pemakai berkesinambungan yang melibatkannya dengan berbagai versi sistem, pemakai akhir perlu untuk dibebaskan dari tanggung jawab lain untuk bekerja sama dengan aplikasi dan untuk pertukaran hidup proyek.

· Memanage suatu pembuatan prototip proyek

Memanage suatu pengembangan baru merancang dengan suatu metodologi berdasar pada suatu interative atau proses evolusiner memerlukan suatu mindset berbeda dibanding memanage proyek dengan menggunakan suatu metodologi SDLC berdasar pada suatu pendekatan pengembangan yang sangat terstruktur. Para manajer SISTEM INFORMASI juga menemukan cara memanage prototip proyek yang lebih sukar yang disebabkan karena kesulitan perencanaan berapa lama ini akan diambil, berapa banyak perkataan berulang-ulang akan diperlukan, atau persisnya ketika pembangun sistem akan bekerja pada sistem.

· Keuntungan dan kerugian pembuatan prototip

Keuntungan dari metodologi pengembangan evolusiner menunjuk kerugian yang tidak bisa dipisahkan di dalam metodologi SDLC. Pertama, hanya kebutuhan sistem basis dasar yang diperlukan yang dihadapi untuk proyek. Ke dua, suatu sistem awal kerja tersedia untuk pemakai menguji jauh lebih dengan cepat. Ketiga, oleh karena alam interaktif dari proses, dnegan penggunaan model sistem kerja langsung, topdown komitmen kuat berdasar pada suatu pertimbangan proses mungkin lebih sedikit perlu. Keempat, pemakai awal penerimaan terhadap suatu aplikasi pengembangan dengan suatu proses evolusiner adalah nampaknya lebih tinggi dibanding dengan suatu SDLC memproses.

Kerugian-kerugian dari suatu metodologi evolusiner dihubungkan dengan bangunan yang evolusiner memproses, prototipe akhir secara khas kekurangan sebagian dari keamanan dan mengendalikan corak menemukan di dalam suatu sistem pengembangan dengan suatu SDLC proses. Kerugian potensi lain dihubungkan dengan memanage harapan pemakai.

· Membuat prototip di dalam suatu proses SDLC

Di dalam paragrap yang berikut kita akan menguraikan dua arah jalan bahwa pembuatan prototip biasanya disatukan ke dalam suatu SDLC proses. Pertama, pembuatan prototip digunakan di dalam tahap definisi untuk membantu para pemakai dalam menggambarkan kebutuhan sistem, terutama sekali untuk menghubungkan pemakai. Kedua cara membuat prototip yang digunakan menjadi lebih kompleks dan meliputi suatu implementasi pilot yang bekerja bagi prototipe.

PENDEKATAN LEBIH BARU

Permintaan untuk pengembangan yang lebih cepat dari aplikasi sistem baru mempunyai peningkatan yang lebih mantap diatas decade masa lalu. Di dalam bagian ini kita dengan singkat akan mendiskusikan beberapa pendekatan yang telah ditunjukkan untuk melihat pengembangan lebih cepat dari mutu tinggi aplikasi yang bermacam-macam.

· Desain Aplikasi Bersama (JAD)

JAD adalah suatu teknik dimana suatu regu para pemakai dan spesialis SISTEM INFORMASI terlibat dalam suatu proses yang kuat dan tersusun untuk mengembangkan disain sistem yang bis mengirim.

Sasaran pokok JAD teknik adalah untuk memperkecil total waktu yang diperlukan untuk informasi yang didapatkan dari banyak peserta.

· Rancang-Bangun Perangkat Lunak Computer-Aided (CASE)

Mengacu pada suatu koleksi perkakas perangkat lunak yang digunakan untuk mengotomatiskan beberapa atau semua tahap dari suatu SDLC proses, paket software CASE hanya mempunyai perkakas analisa awal dan akhir untuk mendukung langkah-langkah disain sistem dan definisi kebutuhan SDLC dikenal sebagai perkakas huruf besar.

· Pengembangan Aplikasi Cepat (RAD)

RAD adalah suatu metodologi campuran yang merupakan kombinasi dari aspek SDLC metodologi dan pembuatan prototip seperti halnya JAD teknik dan perkakas CASE. Tujuannya adalah untuk menghasilkan suatu sistem di dalam waktu enam bulan atau lebih sedikit.

Satu perbedaan kunci antar pendekatan membuat prototip yang khas dan pendekatan RAD adalah bahwa sistem dan pos pemeriksaan struktur checkpoint adalah tanda dari suatu pendekatan SDLC yang ditahan. Perbedaannya adalah bahwa ketika para pemakai mematikan tanda pada awal Dokumen Disain dasar CASE mereka mengetahui bahwa mereka juga dilibatkan di dalam langkah konstruksi, dan bahwa semua kaleng disain tetap dibuat sebagaimana diperlukan.

Serangkaian perintah yang sudah logis lalu dikompare sehingga siap saji/siap pakai. O-O juga menjaga janji besar untuk memproduksi sistem yang lebih baik dengan lebih sedikit biaya, dan perkakas untuk mendukung pendekatan ini sedang menjadi semakin siap tersedia.

TAHUN 2000 PEMELIHARAAN AFTERMATCH : APA YANG KITA MEMPELAJARI

Pemeliharaan pada tahun 2000 adalah suatu tantangan global penting. Ketiadaan komputer glitches dalam kaitannya dengan mengkoordinir usaha dan pembelanjaan dolar besar. Para manajer SISTEM INFORMASI melaporkan bahwa ada juga beberapa manfaat tidak langsung dari proyek kerja Y2K, mencakup pengujian sistem ditingkatkan dan mengubah prosedur kendali.

About forumkuliah

Dosen, trainer, writer

Posted on January 23, 2009, in Sistem Informasi Manajemen. Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: