System Development Lyfe Cycle (SDLC)

System Development Lyfe Cycle (SDLC)
SDLC adalah tahapan-tahapan pekerjaan yang dilakukan oleh analis sistem dan programmer dalam membangun sistem informasi. Langkah yang digunakan meliputi :
1. Melakukan survei dan menilai kelayakan proyek pengembangan sistem informasi
2. Mempelajari dan menganalisis sistem informasi yang sedang berjalan
3. Menentukan permintaan pemakai sistem informasi
4. Memilih solusi atau pemecahan masalah yang paling baik
5. Menentukan perangkat keras (hardware) dan perangkat lunak (software)
6. Merancang sistem informasi baru
7. Membangun sistem informasi baru
8. Mengkomunikasikan dan mengimplementasikan sistem informasi baru
9. Memelihara dan melakukan perbaikan/peningkatan sistem informasi baru bila diperlukan
System Development Lyfe Cycle (SDLC) adalah keseluruhan proses dalam membangun sistem melalui beberapa langkah. Ada beberapa model SDLC. Model yang cukup populer dan banyak digunakan adalah waterfall. Beberapa model lain SDLC misalnya fountain, spiral, rapid, prototyping, incremental, build & fix, dan synchronize & stabilize.
Dengan siklus SDLC, proses membangun sistem dibagi menjadi beberapa langkah dan pada sistem yang besar, masing-masing langkah dikerjakan oleh tim yang berbeda.
Dalam sebuah siklus SDLC, terdapat enam langkah. Jumlah langkah SDLC pada referensi lain mungkin berbeda, namun secara umum adalah sama. Langkah tersebut adalah
1. Analisis sistem, yaitu membuat analisis aliran kerja manajemen yang sedang berjalan
2. Spesifikasi kebutuhan sistem, yaitu melakukan perincian mengenai apa saja yang dibutuhkan dalam pengembangan sistem dan membuat perencanaan yang berkaitan dengan proyek sistem
3. Perancangan sistem, yaitu membuat desain aliran kerja manajemen dan desain pemrograman yang diperlukan untuk pengembangan sistem informasi
4. Pengembangan sistem, yaitu tahap pengembangan sistem informasi dengan menulis program yang diperlukan
5. Pengujian sistem, yaitu melakukan pengujian terhadap sistem yang telah dibuat
6. Implementasi dan pemeliharaan sistem, yaitu menerapkan dan memelihara sistem yang telah dibuat
Siklus SDLC dijalankan secara berurutan, mulai dari langkah pertama hingga langkah keenam. Setiap langkah yang telah selesai harus dikaji ulang, kadang-kadang bersama expert user, terutama dalam langkah spesifikasi kebutuhan dan perancangan sistem untuk memastikan bahwa langkah telah dikerjakan dengan benar dan sesuai harapan. Jika tidak maka langkah tersebut perlu diulangi lagi atau kembali ke langkah sebelumnya.
Kaji ulang yang dimaksud adalah pengujian yang sifatnya quality control, sedangkan pengujian di langkah kelima bersifat quality assurance. Quality control dilakukan oleh personal internal tim untuk membangun kualitas, sedangkan quality assurance dilakukan oleh orang di luar tim untuk menguji kualitas sistem. Semua langkah dalam siklus harus terdokumentasi. Dokumentasi yang baik akan mempermudah pemeliharaan dan peningkatan fungsi sistem.
System Development Life Cycle (SDLC)
SDLC adalah tahapan-tahapan pekerjaan yang dilakukan oleh analis sistem dan programmer dalam membangun sistem informasi. Konsep ini umumnya merujuk pada sistem komputer atau informasi. Oleh karena itu SDLC juga merupakan pola yang diambil untuk mengembangkan sistem perangkat lunak, yang terdiri dari tahap-tahap: rencana(planning),analisa (analysis), desain (design), implementasi (implementation), uji coba (testing) dan pengelolaan (maintenance). Dalam rekayasa perangkat lunak, konsep SDLC mendasari berbagai jenis metodologi pengembangan perangkat lunak. Metodologi-metodologi ini membentuk suatu kerangka kerja untuk perencanaan dan pengendalian pembuatan sistem informasi, yaitu proses pengembangan perangkat lunak. Terdapat 3 jenis metode siklus hidup sistem yang paling banyak digunakan, yakni: siklus hidup sistem tradisional (traditional system life cycle), siklus hidup menggunakan protoyping (life cycle using prototyping), dan siklus hidup sistem orientasi objek (object-oriented system life cycle) .

Langkah yang digunakan meliputi :

1. Melakukan survei dan menilai kelayakan proyek pengembangan sistem informasi
2. Mempelajari dan menganalisis sistem informasi yang sedang berjalan
3. Menentukan permintaan pemakai sistem informasi
4. Memilih solusi atau pemecahan masalah yang paling baik
5. Menentukan perangkat keras (hardware) dan perangkat lunak (software)
6. Merancang sistem informasi baru
7. Membangun sistem informasi baru
8. Mengkomunikasikan dan mengimplementasikan sistem informasi baru
9. Memelihara dan melakukan perbaikan/peningkatan sistem informasi baru bila diperlukan

System Development Lyfe Cycle (SDLC) adalah keseluruhan proses dalam membangun sistem melalui beberapa langkah. Ada beberapa model SDLC. Model yang cukup populer dan banyak digunakan adalah waterfall. Beberapa model lain SDLC misalnya fountain, spiral, rapid, prototyping, incremental, build & fix, dan synchronize & stabilize.           
Dengan siklus SDLC, proses membangun sistem dibagi menjadi beberapa langkah dan pada sistem yang besar, masing-masing langkah dikerjakan oleh tim yang berbeda.

Dalam sebuah siklus SDLC, terdapat enam langkah. Jumlah langkah SDLC pada referensi lain mungkin berbeda, namun secara umum adalah sama. Langkah tersebut adalah
  1. Analisis sistem, yaitu membuat analisis aliran kerja manajemen yang sedang berjalan
  2. Spesifikasi kebutuhan sistem, yaitu melakukan perincian mengenai apa saja yang dibutuhkan dalam pengembangan sistem dan membuat perencanaan yang berkaitan dengan proyek system
  3. Perancangan sistem, yaitu membuat desain aliran kerja manajemen dan desain pemrograman yang diperlukan untuk pengembangan sistem informasi
  4. Pengembangan sistem, yaitu tahap pengembangan sistem informasi dengan menulis program yang diperlukan
  5. Pengujian sistem, yaitu melakukan pengujian terhadap sistem yang telah dibuat
  6. Implementasi dan pemeliharaan sistem, yaitu menerapkan dan memelihara sistem yang telah dibuat


Siklus SDLC dijalankan secara berurutan, mulai dari langkah pertama hingga langkah keenam. Setiap langkah yang telah selesai harus dikaji ulang, kadang-kadang bersama expert user, terutama dalam langkah spesifikasi kebutuhan dan perancangan sistem untuk memastikan bahwa langkah telah dikerjakan dengan benar dan sesuai harapan. Jika tidak maka langkah tersebut perlu diulangi lagi atau kembali ke langkah sebelumnya.

Kaji ulang yang dimaksud adalah pengujian yang sifatnya quality control, sedangkan pengujian di langkah kelima bersifat quality assurance. Quality control dilakukan oleh personal internal tim untuk membangun kualitas, sedangkan quality assurance dilakukan oleh orang di luar tim untuk menguji kualitas sistem. Semua langkah dalam siklus harus terdokumentasi. Dokumentasi yang baik akan mempermudah pemeliharaan dan peningkatan fungsi system

SDLC adalah System Development Life Cycle, yang sederhananya adalah tahapan - tahapan pengembangan sistem. Tahapannya pun sebagai berikut.
  1. Identification, yaitu proses mengidentifikasi kebutuhan! apa saja yang diinginkan dengan memiliki sebuah website, tentunya hal ini berkaitan dengan fasilitas - fasilitas yang ada di dalam website yang akan dibangun itu sendiri
  2. Analysis, proses menganalisa kebutuhan, proses menganalisa fasilitas - fasilitas apa saja yang diinginkan dalam web yang akan dibangun tersebut berdasarkan proses Identification.
  3. Design, yaitu proses perancangan sistem yang akan dibangun baik itu dari sisi desain layout atau tampilan (nilai artistik & estetika nya) ataupun dari sisi teknis seperti database dan aplikasi atau fasilitas yang akan menjadi bagiannya, berdasarkan hasil analisa sebelumnya.
  4. Implementation, yaitu proses development, proses meng-implemntasi design yang telah dibuat.
  5. Testing & Documentation, adalah proses penge-test-an hasil development dan proses mendokumentasikan apa yang telah dibuat.

Model pengembangan perangkat lunak sangat dibutuhkan dalam pengembangan perangkat lunak karena terdapat beberapa keterbatasan sewaktu mengembangkan perangkat lunak, yaitu

1. Biaya          
2. Waktu                    
3. Sumber Daya        

Model pengembangan digunakan untuk membantu memonitor dan mengontrol progress dan karena biaya kebanyakan sistem mengalami over time dan over budget. Tanpa metodologi, tidak ada aturan-aturan yang didefinisikan untuk “how do we proceed?” terutama berguna untuk pengembang sistem yang masih baru           


Metodologi digunakan untuk memastikan bahwa tidak ada aktivitas yang terlupakan dan kebanyakan (55%) sistem besar gagal. Model Proses Pengembangan Sistem adalah proses pengembangan sistem yang sangat resmi dan seksama yang mendefinisikan seperangkat aktifitas, metode-metode, best practices, deliverables, dan automated tools yang digunakan oleh pengembang sistem dan project manager untuk pengembangan dan pemeliharaan sistem dan perangkat lunak.   

Model proses pengembangan perangkat lunak menggambarkan urut-urutan kejadian yang
diperlukan untuk membangun sesuatu produk perangkat lunak tertentu. Model proses pengembangan suatu perangkat lunak sangat diperlukan untuk mendefinisikan, menjelaskan, mengabstraksikan, memodifikasi, memperbaiki dan mendokumentasikan produk perangkat lunak, untuk menggunakan model proses yang baik harus memenuhi 3 ketentuan, yaitu :
  • Model harus mempunyai ‘descriptive power’ Sebuah model harus dapat mendeskripsikan yang dikerjakan dalam tahapannya. Software yang baik biasanya dapat terlihat melalui proses pengembangannya, jika suatu model tidak dapat mendeskripsikan prosesnya maka tidak semua orang dapat mengerti cara kerja pengembangannya. Maka buat apa memakai sebuah model yang hanya beberapa orang dalam tim saja yang mengerti.
  • Pola yang dibuat harus dapat mudah dibaca orang lain Suatu model digunakan agar semua orang dapat mengerti tahapannya sehingga mengerti apa yang dikerjakan agar menghasilkan perangkat lunak yang berkualitas.
  • Bisa dikomputerisasikan Model pengembangan digunakan agar dapat membantu mengembangkan perangkat lunak yang berkualitas, jika salah satu tahapan tidak dapat dikomputerisasikan maka model tersebut hanya akan menambah masalah dalam pengembangan bukannya mengurangi masalah. Oleh karena itu suatu model harus dapat melalui tahap komputerisasi.

Siklus hidup pengembangan sistem

Dari Wikipedia, ensiklopedia bebas
Untuk kegunaan lain, lihat SDLC (disambiguasi) .
Description: http://upload.wikimedia.org/wikipedia/commons/thumb/7/7e/SDLC-Maintenance-Highlighted.png/240px-SDLC-Maintenance-Highlighted.png
Description: http://bits.wikimedia.org/static-1.24wmf4/skins/common/images/magnify-clip.png
Model siklus hidup pengembangan sistem, menyoroti tahap pemeliharaan.
Pengembangan sistem siklus hidup (SDLC), juga disebut sebagai pengembangan aplikasi siklus hidup, adalah istilah yang digunakan dalam rekayasa sistem , sistem informasi dan rekayasa perangkat lunak untuk menggambarkan suatu proses perencanaan, membuat, pengujian, dan menggunakan sistem informasi. [1] Pengembangan sistem konsep siklus hidup berlaku untuk berbagai hardware dan software konfigurasi, sebagai suatu sistem dapat terdiri dari hardware saja, software saja, atau kombinasi keduanya. [2]

Isi

Sekilas

Siklus hidup pengembangan sistem terdiri dari sejumlah didefinisikan secara jelas dan berbeda fase kerja yang digunakan oleh para insinyur sistem dan pengembang sistem untuk merencanakan, desain, membangun, menguji, dan memberikan sistem informasi . Seperti apa yang diproduksi pada jalur perakitan, sebuah SDLC bertujuan untuk menghasilkan sistem berkualitas tinggi yang memenuhi atau melebihi harapan pelanggan, berdasarkan kebutuhan pelanggan, dengan memberikan sistem yang bergerak melalui setiap fase yang jelas, dalam waktu yang dijadwalkan-frame dan perkiraan biaya. [3] Sistem komputer yang kompleks dan sering (terutama dengan munculnya baru-baru arsitektur berorientasi layanan ) menghubungkan beberapa sistem tradisional berpotensi disediakan oleh vendor perangkat lunak yang berbeda. Untuk mengelola tingkat kompleksitas, sejumlah model SDLC atau metodologi telah diciptakan, seperti " air terjun "; " spiral "; " pengembangan perangkat lunak Agile "; " prototipe cepat "; " tambahan "; dan "sinkronisasi dan menstabilkan". [4]
SDLC dapat dijelaskan sepanjang spektrum gesit untuk iteratif untuk sekuensial. Metodologi Agile, seperti XP dan Scrum , fokus pada proses ringan yang memungkinkan untuk perubahan yang cepat (tanpa harus mengikuti pola pendekatan SDLC) sepanjang siklus pengembangan. Iteratif metodologi, seperti Rational Unified Proses dan metode pengembangan sistem dinamis , fokus pada yang terbatas lingkup dan memperluas atau memperbaiki produk oleh beberapa iterasi proyek. Sequential atau besar-desain-muka (BDUF) model, seperti air terjun, fokus pada perencanaan lengkap dan benar untuk membimbing proyek-proyek besar dan risiko untuk hasil yang sukses dan dapat diprediksi [ rujukan? ]. Model-model lain, seperti pembangunan anamorphic , cenderung fokus pada bentuk pembangunan yang dipandu oleh lingkup proyek dan iterasi adaptif pengembangan fitur.
Dalam manajemen proyek proyek dapat didefinisikan baik dengan siklus hidup proyek (PLC) dan SDLC, selama kegiatan yang sedikit berbeda terjadi. Menurut Taylor (2004) "siklus hidup proyek mencakup semua kegiatan proyek , sedangkan siklus hidup pengembangan sistem berfokus pada produk menyadari persyaratan ". [5]
SDLC digunakan selama pengembangan proyek IT, itu menggambarkan tahapan yang berbeda yang terlibat dalam proyek dari papan gambar, melalui penyelesaian proyek.

Sejarah

The siklus hidup produk menggambarkan proses untuk membangun sistem informasi dalam cara yang sangat disengaja, terstruktur dan metodis, mengulangi setiap tahap kehidupan produk. Siklus hidup pengembangan sistem, menurut Elliott & Strachan & Radford (2004), "berasal pada tahun 1960, untuk mengembangkan skala besar fungsional sistem bisnis di zaman skala besar konglomerat bisnis . kegiatan sistem informasi berkisar berat pengolahan data dan angka-angka rutinitas ". [6]
Beberapa kerangka kerja pengembangan sistem telah sebagian didasarkan pada SDLC, seperti analisis sistem terstruktur dan metode desain (SSADM) diproduksi untuk pemerintah Inggris Kantor Pemerintah Commerce pada 1980-an. Sejak saat itu, menurut Elliott (2004), "siklus hidup tradisional pendekatan untuk pengembangan sistem telah semakin digantikan dengan alternatif pendekatan dan kerangka kerja, yang berusaha untuk mengatasi beberapa kekurangan yang melekat pada SDLC tradisional". [6]

Tahapan

Description: http://upload.wikimedia.org/wikipedia/en/thumb/9/99/Question_book-new.svg/50px-Question_book-new.svg.png
Bagian ini membutuhkan tambahan kutipan untuk verifikasi . Harap membantu memperbaiki artikel ini dengan menambahkan kutipan ke sumber terpercaya . Unsourced bahan mungkin akan ditantang dan dihapus. (September 2010)
Sistem PEMBANGUNAN kerangka siklus hidup memberikan urutan kegiatan untuk desainer sistem dan pengembang untuk mengikuti. Ini terdiri dari serangkaian langkah-langkah atau fase di mana setiap fase dari SDLC menggunakan hasil sebelumnya.
The SDLC mematuhi tahapan penting yang penting bagi para pengembang, seperti perencanaan , analisis , desain , dan implementasi , dan dijelaskan dalam bagian di bawah ini. Ini mencakup evaluasi sistem ini, pengumpulan informasi, studi kelayakan dan persetujuan permintaan. Sejumlah model SDLC telah diciptakan: air terjun, air mancur, spiral, membangun dan memperbaiki, prototyping cepat, incremental, dan sinkronisasi dan menstabilkan. Yang tertua dari ini, dan yang paling terkenal, adalah model air terjun: urutan tahap di mana output dari setiap tahap menjadi masukan untuk selanjutnya. Tahap ini dapat dicirikan dan dibagi dengan cara yang berbeda, termasuk yang berikut: [7]
  • Analisis awal: Tujuan dari tahap 1 adalah untuk melakukan analisis awal, mengusulkan solusi alternatif, menggambarkan biaya dan manfaat dan menyerahkan rencana awal dengan rekomendasi.
Melakukan analisis awal: pada langkah ini, Anda perlu mencari tahu tujuan organisasi dan sifat dan ruang lingkup masalah yang diteliti. Bahkan jika masalah hanya merujuk pada segmen kecil dari organisasi itu sendiri maka Anda perlu mencari tahu apa yang menjadi tujuan dari organisasi itu sendiri. Kemudian Anda perlu melihat bagaimana masalah yang sedang diteliti cocok dengan mereka.
Mengusulkan alternatif solusi: Dalam menggali ke tujuan organisasi dan masalah-masalah tertentu, Anda mungkin sudah dibahas beberapa solusi. Proposal alternatif dapat berasal dari wawancara karyawan, klien, pemasok, dan / atau konsultan. Anda juga dapat mempelajari apa yang kompetitor lakukan. Dengan data ini, Anda akan memiliki tiga pilihan: meninggalkan sistem seperti, meningkatkan, atau mengembangkan sistem baru.
Jelaskan biaya dan manfaat.
  • Analisis sistem, persyaratan definisi: Mendefinisikan tujuan proyek menjadi fungsi didefinisikan dan operasi dari aplikasi yang dimaksud. Menganalisa kebutuhan informasi pengguna akhir.
  • Pengembangan: Kode sebenarnya yang tertulis di sini.
  • Integrasi dan pengujian: Membawa semua potongan ke dalam lingkungan pengujian khusus, kemudian memeriksa untuk kesalahan, bug dan interoperabilitas.
  • Penerimaan, instalasi, penyebaran: Tahap akhir pengembangan awal, di mana perangkat lunak yang dimasukkan ke dalam produksi dan menjalankan bisnis yang sebenarnya.
  • Pemeliharaan: Selama tahap pemeliharaan SDLC, sistem ini dinilai untuk memastikan tidak menjadi usang. Ini juga di mana perubahan yang dibuat untuk awal perangkat lunak. Ini melibatkan evaluasi terus menerus dari sistem dalam hal kinerjanya.
  • Evaluasi: Beberapa perusahaan tidak melihat ini sebagai tahap resmi dari SDLC, tetapi apakah itu merupakan bagian penting dari siklus hidup. Langkah evaluasi merupakan perpanjangan dari tahap Pemeliharaan, dan dapat disebut di beberapa kalangan sebagai Post-implementasi Ulasan. Di sinilah sistem yang dikembangkan, serta seluruh proses, dievaluasi. Beberapa pertanyaan yang perlu dijawab meliputi: apakah sistem yang baru diimplementasikan memenuhi kebutuhan bisnis dan tujuan awal? Apakah sistem yang handal dan fault-tolerant? Apakah fungsi sistem sesuai dengan persyaratan fungsional disetujui. Selain mengevaluasi perangkat lunak yang dirilis, adalah penting untuk menilai efektivitas proses pembangunan. Jika ada aspek dari seluruh proses, atau tahapan tertentu, bahwa manajemen tidak puas dengan, ini adalah waktu untuk memperbaiki. Evaluasi dan penilaian adalah masalah yang sulit. Namun, perusahaan harus merefleksikan proses dan alamat kelemahan.
  • Pembuangan: Pada fase ini, rencana yang dikembangkan untuk membuang sistem informasi, perangkat keras dan perangkat lunak dalam membuat transisi ke sistem baru. Tujuannya di sini adalah untuk benar bergerak, arsip, membuang atau merusak informasi, perangkat keras dan perangkat lunak yang digantikan, dalam hitungan yang mencegah kemungkinan pengungkapan yang tidak sah dari data sensitif. Kegiatan pembuangan memastikan migrasi yang tepat ke sistem baru. Penekanan khusus diberikan kepada pelestarian yang tepat dan arsip data yang diproses oleh sistem sebelumnya. Semua ini harus dilakukan sesuai dengan persyaratan keamanan organisasi. [8]
Pada contoh berikut (lihat gambar) tahap ini dari siklus hidup pengembangan sistem dibagi dalam sepuluh langkah dari definisi untuk penciptaan dan modifikasi produk IT bekerja:
Description: http://upload.wikimedia.org/wikipedia/commons/thumb/b/bb/Systems_Development_Life_Cycle.jpg/720px-Systems_Development_Life_Cycle.jpg
Description: http://bits.wikimedia.org/static-1.24wmf4/skins/common/images/magnify-clip.png
Fase kesepuluh terjadi ketika sistem tersebut dijual dan tugas yang dilakukan adalah baik dihilangkan atau ditransfer ke sistem lain. Tugas dan produk kerja untuk setiap tahap dijelaskan dalam bab-bab berikutnya. [9]
Tidak setiap proyek akan membutuhkan bahwa tahap secara berurutan dieksekusi. Namun, fase saling bergantung. Tergantung pada ukuran dan kompleksitas proyek, tahapan dapat dikombinasikan atau mungkin tumpang tindih. [9]

Investigasi sistem

Tahap investigasi sistem alamat kebutuhan atau peluang yang dapat dicapai oleh sponsor atau proposal IT. Selama langkah ini, kita harus mempertimbangkan semua prioritas saat ini yang akan terpengaruh dan bagaimana mereka harus ditangani. Sebelum adanya perencanaan sistem yang dilakukan, sebuah studi kelayakan harus dilakukan untuk menentukan apakah menciptakan sistem baru atau perbaikan adalah solusi yang layak. Ini akan membantu untuk menentukan biaya, manfaat, kebutuhan sumber daya, dan kebutuhan pengguna tertentu dibutuhkan untuk penyelesaian. Proses pembangunan hanya dapat dilanjutkan setelah manajemen menyetujui rekomendasi dari studi kelayakan. [10]
Berikut ini adalah komponen yang berbeda dari studi kelayakan:

Analisis sistem

Tujuan dari analisis sistem adalah untuk menentukan di mana masalahnya adalah dalam upaya untuk memperbaiki sistem. Langkah ini melibatkan mogok sistem dalam bagian yang berbeda untuk menganalisis situasi, menganalisis tujuan proyek, mogok apa yang perlu dibuat dan berusaha untuk melibatkan pengguna sehingga persyaratan tertentu dapat didefinisikan.

Desain

Dalam desain sistem fungsi desain dan operasi dijelaskan secara rinci, termasuk layar layout, aturan bisnis, diagram proses dan dokumentasi lainnya. Output dari tahap ini akan menjelaskan sistem baru sebagai kumpulan modul atau subsistem.
Tahap desain mengambil sebagai masukan awal persyaratan diidentifikasi dalam dokumen persyaratan yang telah disetujui. Untuk kebutuhan masing-masing, satu set dari satu atau lebih elemen desain akan diproduksi sebagai hasil dari wawancara, lokakarya, dan / atau upaya prototipe.
Desain elemen menggambarkan fitur sistem yang diinginkan secara detail, dan umumnya termasuk diagram hirarki fungsional, diagram tata letak layar, tabel aturan bisnis, diagram proses bisnis, pseudo-code, dan diagram hubungan entitas-lengkap dengan kamus data penuh. Elemen desain ini dimaksudkan untuk menggambarkan sistem secara cukup rinci, sehingga pengembang yang terampil dan insinyur dapat mengembangkan dan memberikan sistem dengan desain masukan tambahan minimal.

Lingkungan

Lingkungan adalah daerah di mana pengembang sistem dapat membangun, mendistribusikan, menginstal, mengkonfigurasi, tes, dan melaksanakan sistem yang bergerak melalui SDLC dikendalikan. Setiap lingkungan sejalan dengan daerah yang berbeda dari SDLC dan dimaksudkan untuk memiliki tujuan tertentu. Contoh lingkungan tersebut meliputi:
  • Lingkungan pengembangan, di mana pengembang dapat bekerja secara independen satu sama lain sebelum mencoba untuk menggabungkan pekerjaan mereka dengan karya orang lain,
  • Membangun lingkungan umum, di mana pekerjaan digabung dapat dibangun, bersama-sama, sebagai sistem gabungan,
  • Lingkungan pengujian integrasi sistem, di mana pengujian dasar dari sebuah sistem integrasi poin untuk sistem hulu atau hilir lainnya dapat diuji,
  • Pengguna pengujian penerimaan lingkungan, di mana para pemangku kepentingan bisnis dapat menguji terhadap kebutuhan bisnis asli mereka,
  • Lingkungan produksi, di mana sistem akhirnya bisa dikerahkan untuk, untuk digunakan oleh pengguna akhir akhir dimaksudkan mereka.
Perencanaan untuk, provisioning, dan operasi dari lingkungan tersebut dikenal sebagai praktek manajemen TI lingkungan . [11]

Pengujian

~ Diuji pada berbagai tingkat dalam pengujian perangkat lunak . Unit, sistem dan user pengujian penerimaan sering dilakukan. Ini adalah wilayah abu-abu sebagai banyak pendapat yang berbeda ada seperti apa tahap pengujian dan berapa banyak, jika iterasi apapun yang terjadi. Iterasi umumnya tidak bagian dari model air terjun, tapi biasanya beberapa terjadi pada tahap ini. Dalam pengujian seluruh sistem diuji satu per satu
Berikut ini adalah jenis pengujian:

Pelatihan dan transisi

Setelah sistem telah distabilkan melalui pengujian yang memadai, SDLC memastikan bahwa pelatihan yang tepat pada sistem dilakukan atau didokumentasikan sebelum transisi sistem untuk pengguna staf pendukung dan akhir.
Pelatihan biasanya meliputi pelatihan operasional bagi orang-orang yang akan bertanggung jawab untuk mendukung sistem serta pelatihan bagi para pengguna akhir yang akan menggunakan sistem setelah pengiriman ke lingkungan operasi produksi.
Setelah pelatihan telah berhasil diselesaikan, insinyur sistem dan pengembang transisi sistem untuk lingkungan produksi akhir, di mana ia dimaksudkan untuk digunakan oleh pengguna akhir dan didukung oleh dukungan dan operasi stafnya.

Operasi dan pemeliharaan

The penyebaran sistem meliputi perubahan dan perangkat tambahan sebelum dekomisioning atau matahari terbenam dari sistem. Mempertahankan sistem merupakan aspek penting dari SDLC. Sebagai personil kunci perubahan posisi dalam organisasi, perubahan baru akan dilaksanakan. Ada dua pendekatan untuk pengembangan sistem; ada pendekatan tradisional (terstruktur) dan berorientasi objek . Teknik Informatika meliputi pendekatan sistem tradisional, yang juga disebut analisis terstruktur dan desain teknik. The berorientasi objek pendekatan memandang sistem informasi sebagai koleksi benda-benda yang terintegrasi satu sama lain untuk membuat sistem informasi yang lengkap.

Evaluasi

Tahap akhir dari SDLC adalah untuk mengukur efektivitas dari aplikasi dan mengevaluasi perangkat tambahan potensial.

Analisis sistem dan desain

Sistem analisis dan desain (SAD) adalah proses pengembangan sistem informasi (IS) yang efektif menggunakan hardware, software, data, proses, dan orang-orang untuk mendukung bisnis tujuan perusahaan. Analisis sistem dan desain dapat dianggap kegiatan meta-pengembangan, yang berfungsi untuk mengatur panggung dan terikat masalah. SAD dapat dimanfaatkan untuk mengatur keseimbangan yang benar antara bersaing persyaratan tingkat tinggi dalam domain analisis fungsional dan non-fungsional. Analisis sistem dan desain berinteraksi kuat dengan perusahaan arsitektur terdistribusi, perusahaan IT Architecture, dan arsitektur bisnis, dan sangat bergantung pada konsep-konsep seperti partisi, interface, kepribadian dan peran, dan penyebaran / pemodelan operasional untuk sampai pada deskripsi sistem tingkat tinggi. Deskripsi tingkat tinggi ini kemudian lebih lanjut dipecah menjadi komponen-komponen dan modul yang dapat dianalisis, dirancang, dan dibangun secara terpisah dan terintegrasi untuk mencapai tujuan bisnis. SDLC dan SAD merupakan landasan penuh siklus hidup produk dan perencanaan sistem.

Analisis berorientasi objek

Analisis berorientasi objek (OOA) adalah proses menganalisis tugas (juga dikenal sebagai domain masalah ), untuk mengembangkan sebuah model konseptual yang kemudian dapat digunakan untuk menyelesaikan tugas. Sebuah model OOA khas akan menggambarkan perangkat lunak komputer yang dapat digunakan untuk memenuhi seperangkat persyaratan yang ditentukan pelanggan. Selama fase analisis pemecahan masalah, programmer mungkin mempertimbangkan pernyataan tertulis persyaratan, dokumen visi formal, atau wawancara dengan stakeholder atau pihak lain yang berkepentingan. Tugas ditangani mungkin akan dibagi menjadi beberapa sub-tugas (atau domain), masing-masing mewakili bisnis yang berbeda, teknologi, atau daerah lain yang menarik. Setiap subtask akan dianalisis secara terpisah. Kendala-kendala pelaksanaan, (misalnya, konkurensi , distribusi , ketekunan , atau bagaimana sistem akan dibangun) tidak dianggap selama fase analisis; melainkan, mereka ditangani selama desain berorientasi objek (OOD).
Model konseptual yang dihasilkan dari OOA biasanya akan terdiri dari satu set kasus penggunaan , satu atau lebih UML diagram kelas , dan sejumlah diagram interaksi . Hal ini juga dapat mencakup beberapa jenis antarmuka pengguna mock-up.
Masukan untuk desain berorientasi obyek disediakan oleh output dari analisis berorientasi objek . Sadarilah bahwa artefak keluaran tidak harus benar-benar dikembangkan untuk melayani sebagai masukan desain berorientasi objek; analisis dan desain dapat terjadi secara paralel, dan dalam praktek hasil dari satu kegiatan dapat memberi makan lain dalam siklus umpan pendek melalui proses berulang-ulang. Kedua analisis dan desain dapat dilakukan secara bertahap, dan artefak dapat terus tumbuh bukan sepenuhnya dikembangkan dalam satu tembakan.
Beberapa artefak masukan khas untuk object-oriented:
  • Model konseptual : Model konseptual adalah hasil dari analisis berorientasi objek, ia menangkap konsep-konsep dalam domain masalah. Model konseptual secara eksplisit memilih untuk menjadi independen dari rincian implementasi, seperti konkurensi atau penyimpanan data.
  • Gunakan kasus : Use case adalah deskripsi dari urutan peristiwa yang, bila digabungkan, menyebabkan sistem melakukan sesuatu yang berguna. Setiap use case menyediakan satu atau lebih skenario yang menyampaikan bagaimana sistem harus berinteraksi dengan pengguna yang disebut aktor untuk mencapai tujuan bisnis yang spesifik atau fungsi. Aktor use case mungkin pengguna akhir atau sistem lainnya. Dalam banyak situasi menggunakan kasus yang dijabarkan lebih lanjut dalam diagram use case. Diagram use case digunakan untuk mengidentifikasi aktor (pengguna atau sistem lain) dan proses yang mereka lakukan.
  • Sistem Sequence Diagram : diagram Sistem urutan (SSD) adalah gambar yang menunjukkan, untuk skenario tertentu dari kasus penggunaan, peristiwa yang menghasilkan aktor-aktor eksternal, pesanan mereka, dan kemungkinan peristiwa antar-sistem.
  • Dokumentasi user interface (jika ada): Dokumen yang menunjukkan dan menggambarkan tampilan dan nuansa dari antarmuka pengguna akhir produk. Hal ini tidak wajib untuk memiliki ini, tetapi hal ini membantu untuk memvisualisasikan produk akhir dan karena itu membantu desainer.
  • Model data relasional (jika ada): Sebuah model data adalah model abstrak yang menggambarkan bagaimana data direpresentasikan dan digunakan. Jika objek database tidak digunakan, model data relasional biasanya harus dibuat sebelum desain, karena strategi yang dipilih untuk pemetaan objek-relasional merupakan output dari proses desain OO. Namun, adalah mungkin untuk mengembangkan model data relasional dan artefak desain berorientasi objek secara paralel, dan pertumbuhan artefak dapat merangsang perbaikan artefak lainnya.

Siklus hidup

Manajemen dan kontrol

Description: http://upload.wikimedia.org/wikipedia/commons/thumb/a/a2/SDLC_Phases_Related_to_Management_Controls.jpg/400px-SDLC_Phases_Related_to_Management_Controls.jpg
Description: http://bits.wikimedia.org/static-1.24wmf4/skins/common/images/magnify-clip.png
Fase SPIU terkait dengan kontrol manajemen. [12]
The SDLC fase berfungsi sebagai panduan program untuk kegiatan proyek dan menyediakan cara yang fleksibel tetapi konsisten untuk melakukan proyek ke kedalaman yang cocok dengan lingkup proyek. Masing-masing tujuan fase SDLC dijelaskan dalam bagian ini dengan kiriman kunci, deskripsi tugas yang direkomendasikan, dan ringkasan tujuan pengendalian terkait untuk manajemen yang efektif. Hal ini penting bagi manajer proyek untuk membangun dan memantau tujuan pengendalian selama setiap fase SDLC ketika menjalankan proyek. Tujuan pengendalian membantu memberikan pernyataan yang jelas dari hasil yang diinginkan atau tujuan dan harus digunakan di seluruh proses SDLC. Tujuan pengendalian dapat dikelompokkan menjadi kategori utama (domain), dan berhubungan dengan fase SDLC seperti yang ditunjukkan pada gambar. [12]
Untuk mengelola dan mengendalikan setiap inisiatif SDLC, setiap proyek akan diminta untuk menetapkan beberapa derajat dari struktur rincian kerja (WBS) untuk menangkap dan jadwal pekerjaan yang diperlukan untuk menyelesaikan proyek. WBS dan semua materi program harus disimpan dalam "proyek deskripsi" dari notebook proyek. Format WBS sebagian besar diserahkan kepada manajer proyek untuk membangun dengan cara yang paling tepat menggambarkan pekerjaan proyek.
Ada beberapa area kunci yang harus didefinisikan di WBS sebagai bagian dari kebijakan SDLC. Diagram berikut ini menjelaskan tiga bidang utama yang akan dibahas dalam WBS dengan cara yang ditetapkan oleh manajer proyek. [12]

Rincian kerja terstruktur organisasi

Description: http://upload.wikimedia.org/wikipedia/commons/thumb/8/82/SDLC_Work_Breakdown_Structure.jpg/400px-SDLC_Work_Breakdown_Structure.jpg
Description: http://bits.wikimedia.org/static-1.24wmf4/skins/common/images/magnify-clip.png
Struktur rincian kerja. [12]
Bagian atas dari struktur rincian kerja (WBS) harus mengidentifikasi fase utama dan tonggak proyek dalam mode ringkasan. Selain itu, bagian atas harus memberikan gambaran tentang ruang lingkup penuh dan jadwal waktu proyek dan akan menjadi bagian dari upaya deskripsi proyek awal yang mengarah ke persetujuan proyek. Bagian tengah WBS didasarkan pada tujuh fase siklus hidup pengembangan sistem sebagai panduan untuk pengembangan tugas WBS. Unsur-unsur WBS harus terdiri dari tonggak dan "tugas" sebagai lawan dari "kegiatan" dan memiliki jangka waktu yang pasti (biasanya dua minggu atau lebih). Setiap tugas harus memiliki output yang terukur (ex dokumen, keputusan, atau analisis). Sebuah tugas WBS dapat bergantung pada satu atau lebih kegiatan (misalnya rekayasa perangkat lunak, rekayasa sistem) dan mungkin memerlukan koordinasi erat dengan tugas-tugas lain, baik internal maupun eksternal untuk proyek. Setiap bagian dari proyek membutuhkan dukungan dari kontraktor harus memiliki pernyataan kerja (SOW) tertulis untuk menyertakan tugas-tugas yang sesuai dari fase SDLC. Pengembangan SOW tidak terjadi selama fase tertentu SDLC tetapi dikembangkan untuk menyertakan kerja dari proses SDLC yang dapat dilakukan oleh sumber daya eksternal seperti kontraktor. [12]

Baseline

Baseline merupakan bagian penting dari siklus hidup pengembangan sistem. Baseline ini ditetapkan setelah empat dari lima fase SDLC dan sangat penting untuk sifat iteratif dari model. [13] Setiap awal dianggap sebagai tonggak dalam SDLC.
  • dasar fungsional: didirikan setelah tahap desain konseptual.
  • dialokasikan awal: didirikan setelah tahap desain awal.
  • dasar produk: didirikan setelah detail desain dan tahap pembangunan.
  • diperbarui dasar produk: didirikan setelah tahap konstruksi produksi.

Metodologi komplementer

Pelengkap metode pengembangan perangkat lunak siklus hidup pengembangan sistem adalah:
Perbandingan Metodologi Pendekatan (Post, & Anderson 2006) [14]
SDLC
RAD
Open source
Objects
JAD
Prototyping
Pengguna Akhir
Kontrol
Resmi
MIS
Lemah
Standar
Bersama
Pemakai
Pemakai
Time frame
Panjang
Pendek
Medium
Apa saja
Medium
Pendek
Pendek
-
Pengguna
Banyak
Beberapa
Beberapa
Bervariasi
Beberapa
Satu atau dua
Satu
Staf MIS
Banyak
Beberapa
Ratusan
Membagi
Beberapa
Satu atau dua
Tak satupun
Transaksi / DSS
Transaksi
Kedua
Kedua
Kedua
DSS
DSS
DSS
Antarmuka
Minimal
Minimal
Lemah
Jendela
Sangat penting
Sangat penting
Sangat penting
Dokumentasi dan pelatihan
Vital
Terbatas
Intern
Dalam Objects
Terbatas
Lemah
Tak satupun
Integritas dan keamanan
Vital
Vital
Diketahui
Dalam Objects
Terbatas
Lemah
Lemah
Usabilitas
Terbatas
Beberapa
Mungkin
Vital
Terbatas
Lemah
Tak satupun

Kekuatan dan kelemahan

Hanya sedikit orang di dunia komputasi modern akan menggunakan model air terjun yang ketat untuk SDLC mereka sebagai metodologi modern telah digantikan pemikiran ini. Beberapa akan berpendapat bahwa SDLC tidak lagi berlaku untuk model seperti komputasi Agile, tetapi masih istilah luas digunakan di kalangan teknologi. Praktek SDLC memiliki keunggulan dalam model tradisional pengembangan sistem, yang cocok lebih untuk lingkungan yang terstruktur. Kelemahan menggunakan metodologi SDLC adalah ketika ada kebutuhan untuk pengembangan iteratif atau (yakni pengembangan web atau e-commerce) dimana stakeholders harus meninjau secara rutin perangkat lunak yang dirancang. Alih-alih melihat SDLC dari perspektif kekuatan atau kelemahan, itu jauh lebih penting untuk mengambil praktek-praktek terbaik dari model SDLC dan menerapkannya ke apapun mungkin paling sesuai untuk perangkat lunak yang akan dibuat.
Suatu perbandingan kekuatan dan kelemahan dari SDLC:
Kekuatan dan Kelemahan dari SDLC [14]
Kekuatan
Kelemahan
Control.
Peningkatan waktu pengembangan.
Memantau proyek-proyek besar.
Peningkatan biaya pengembangan.
Langkah-langkah rinci.
Sistem harus didefinisikan di depan.
Mengevaluasi biaya dan target penyelesaian.
Kekakuan.
Dokumentasi.
Sulit untuk memperkirakan biaya, overruns proyek.
Didefinisikan dengan baik input pengguna.
Input pengguna kadang-kadang terbatas.
Kemudahan pemeliharaan.
Standar desain pengembangan dan.
Mentolerir perubahan staf MIS.
Sebuah alternatif untuk SDLC adalah pengembangan aplikasi yang cepat, yang menggabungkan prototyping, pengembangan aplikasi bersama dan pelaksanaan CASE tools. Keuntungan dari RAD adalah kecepatan, mengurangi biaya pengembangan, dan keterlibatan pengguna aktif dalam proses pembangunan.




Hari ini kita akan mencakup:
(1) Tiga cara untuk mendapatkan yang baru IS:
            Pembelian Software, Kembangkan in-house, Outsource
(2) Tiga cara untuk meningkatkan pembangunan
Proses:
Rekayasa ulang proses bisnis (BPR), Prototyping, Computer-aided engr software. (CASE) tools
2
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
PENDAHULUAN
·                     Perusahaan dapat mengalami sejumlah kesulitan dalam mengembangkan AIS secara internal, termasuk:
·                     Proyek backlogged selama bertahun-tahun karena permintaan tinggi untuk sumber daya.
·                     Sistem baru dirancang doesn 't memenuhi kebutuhan pengguna.
·                     Proses ini memakan waktu begitu lama bahwa pada saat itu s selesai, itu usang.
·                     Pengguna dapat 't cukup menentukan kebutuhan mereka.
·                     Perubahan AIS seringkali sulit untuk membuat setelah persyaratan telah ditulis ke dalam spesifikasi.
3
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Alternatif untuk in-house
·                     Pembelian perangkat lunak
·                     Menyewa luar perusahaan untuk mengembangkan & memelihara sistem
4
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Pembelian Software
·                     Software kaleng dijual di pasar terbuka untuk pengguna dengan persyaratan yang sama
·                     Software tujuan umum AIS (SAP, Oracle, Great Plains, Peachtree, Buku Cepat).
·                     Software juga dikembangkan untuk memenuhi kebutuhan bisnis tertentu.
·                     Kesulitan perangkat lunak kaleng:
·                     Perangkat lunak pihak 3 rd jarang memenuhi semua kebutuhan.
·                     Perlu untuk meng-upgrade ke versi baru.
·                     Kehilangan kontrol.
5
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Pembelian - Turnkey Sistem
·                     Vendor menginstal seluruh sistem (hardware dan software) dan menjual sebagai paket.
·                     Banyak vendor mengkhususkan diri dalam industri tertentu (misalnya, penyewaan video)
6
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Application Service Provider (ASP)
  Perangkat lunak berbasis web yang disampaikan melalui Internet. "Rent" daripada membeli perangkat lunak. Dapat mengurangi biaya, dan memungkinkan perusahaan untuk fokus pada kompetensi inti, bukan perangkat lunak.
Misalnya, versi Internet TurboTax
7
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Pembelian Software dan SDLC
·                     SDLC masih diikuti.
·                     Sistem Analisis: perusahaan harus melakukan penyelidikan awal, survei, dan analisis kelayakan untuk menentukan persyaratan.
·                     Konseptual desain sistem: menentukan apakah perangkat lunak yang memenuhi persyaratan sudah tersedia.
8
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Pembelian Software dan SDLC (lanjutan)
·                     Desain fisik: jika software yang dibeli, beberapa tahap desain fisik (coding) dapat dihilangkan. Mungkin perlu untuk memodifikasi perangkat lunak yang dibeli untuk memenuhi kebutuhan perusahaan, dan kontrol dan laporan masih perlu didefinisikan.
·                     Implementasi dan konversi: masih perlu mengkonversi sistem, menginstal dan hardware pengujian dan software, personil pilih dan kereta api, dan mendokumentasikan sistem baru. JANGAN mengembangkan & pengujian perangkat lunak atau program komputer dokumen.
·                     Operasi dan pemeliharaan: masih diperlukan. Vendor biasanya mempertahankan.
9
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Memilih Vendor
·                     Apakah software yang berlaku untuk bisnis Anda? Berapa lama waktu yang akan memenuhi kebutuhan Anda? Akankah vendor berada di sekitar?
·                     Mencari vendor: Lihatlah di buku telepon, Mendapatkan arahan, Pindai komputer atau perdagangan majalah, Menghadiri konferensi, organisasi Gunakan pencarian
10
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme

Mendapatkan hardware dan software
Setelah persyaratan AIS telah ditetapkan, organisasi dapat membeli perangkat lunak dan perangkat keras.
Perusahaan hanya membutuhkan PC dan beberapa perangkat lunak perkantoran biasanya dapat menyelesaikan penelitian mereka sendiri dan membuat pilihan.
    Ketika membeli sistem yang besar atau kompleks, request for proposal (RFP) harus disiapkan.
11
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Request for proposal (RFP)
RFP adalah undangan untuk penawar untuk mengusulkan sebuah sistem pada tanggal tertentu.
Semakin banyak informasi perusahaan menyediakan untuk vendor, semakin baik kesempatan perusahaan menerima sistem yang memenuhi persyaratan. Pastikan untuk membedakan antara persyaratan wajib dan diinginkan. (General RFP)
Setiap proposal dievaluasi.
Finalis diselidiki secara mendalam.
12
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme

Mengevaluasi proposal dan memilih sistem
·                     Hapuslah proposal yang:
·                     Hilang informasi penting.
·                     Gagal memenuhi persyaratan minimum.
·                     Apakah ambigu.
·                     Mereka yang lulus penyaringan awal harus dibandingkan dengan persyaratan AIS yang diusulkan untuk menentukan:
·                     Jika mereka memenuhi semua persyaratan wajib.
·                     Berapa banyak persyaratan yang diinginkan mereka bertemu.
·                     Finalis bisa diajak demo sistem mereka menggunakan data perusahaan-disediakan.
13
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Mengevaluasi proposal (contin.)
·                     Dalam meninjau proposal, Anda perlu mengevaluasi:
·                     Perangkat keras
·                     Perangkat lunak
·                     Vendor
14
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Hardware Evaluasi
15
·                     Kriteria untuk mengevaluasi hardware meliputi:
·                     Biaya
·                     Kemampuan untuk menjalankan perangkat lunak yang diperlukan
·                     Kecepatan pemrosesan dan kemampuan
·                     Kemampuan penyimpanan sekunder
·                     Input dan output kecepatan
·                     Kemampuan komunikasi
·                     Expandability
·                     Kemutakhiran teknologi
·                     Tersedianya
·                     Kompatibilitas dengan perangkat keras yang ada, perangkat lunak, dan peripheral
·                     Kinerja dibandingkan dengan pesaing
·                     Biaya dan ketersediaan dukungan dan pemeliharaan
·                     Warrantees dan jaminan
·                     Pengaturan pembiayaan
·                     Kemampuan untuk memenuhi persyaratan wajib
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Software Evaluasi
16
·                     Kriteria untuk mengevaluasi perangkat lunak meliputi:
·                     Kesesuaian dengan spesifikasi
·                     Perlu untuk modifikasi
·                     Kinerja (kecepatan, akurasi, keandalan)
·                     Gunakan oleh perusahaan lain
·                     Kepuasan pengguna lain
·                     Dokumentasi
·                     Kompatibilitas dengan perangkat lunak yang ada
·                     Keramahan-pengguna
·                     Kemampuan yang harus didemonstrasikan dan uji-driven
·                     Jaminan
·                     Fleksibilitas dan rawatan
·                     Kemampuan untuk penyelidikan online file dan catatan
·                     Vendor upgrade
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Vendor Evaluasi
17
·                     Kriteria untuk mengevaluasi vendor meliputi:
·                     Ukuran
·                     Stabilitas keuangan dan keamanan
·                     Pengalaman
·                     Kualitas dukungan dan jaminan
·                     Keteraturan update
·                     Kemampuan untuk menyediakan pembiayaan
·                     Kesediaan untuk menandatangani kontrak
·                     Kesediaan untuk memberikan referensi
·                     Reputasi untuk keandalan dan kehandalan
·                     Hardware dan software dukungan dan pemeliharaan
·                     Implementasi dan instalasi dukungan
·                     Kualitas dan tanggap personil
·                     Kesediaan untuk memberikan pelatihan
·                     Responsiveness dan ketepatan waktu dukungan
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
System Performance
Pendekatan untuk membandingkan kinerja sistem:
·                     Masalah patokan
·                     Titik scoring
·                     Persyaratan biaya
18
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Benchmarking
Masalah patokan
·                     SIA baru melakukan tugas pengolahan data dengan pekerjaan input, proses, dan output khas dari apa yang akan diperlukan dari sistem baru.
·                     Waktu pengolahan dihitung dan dibandingkan.
·                     SIA dengan waktu terendah dinilai paling efisien.
19
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Titik Scoring
·                     Berat A ditugaskan untuk setiap kriteria yang digunakan untuk mengevaluasi sistem, berdasarkan kepentingan relatif dari kriteria itu.
·                     Setiap kriteria berperingkat untuk setiap produk.
·                     Setiap Peringkat dikalikan kali berat ditugaskan untuk kriteria untuk mengembangkan skor tertimbang.
·                     Skor tertimbang ditambahkan untuk setiap produk.
20
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Titik Scoring - Contoh
·                     O 'Neil Co sedang mengevaluasi sistem yang ditawarkan oleh tiga vendor yang berbeda: Mampu Co, Baker Co, dan Masak Co
·                     O 'Neil telah menetapkan tiga kriteria yang akan mereka gunakan untuk mengevaluasi sistem yang berbeda: biaya, kecepatan, dan kehandalan penjual.
·                     Mereka telah memberikan bobot berikut untuk masing-masing kriteria, dengan keandalan penjual yang paling penting:
·                     Keandalan penjual - 9
·                     Biaya - 6
·                     Kecepatan - 4
21
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Titik Scoring - Contoh
22
O'Neil memeriksa paket yang ditawarkan oleh tiga vendor dan diberi nilai mereka berdasarkan tiga kriteria tersebut. Penilaian itu dari 1-5 dengan 5 menjadi skor tertinggi.
Kriteria
Mampu Co
Baker Co
Masak Co
Keandalan penjual (9)
2
5
4
Biaya (6)
5
3
4
Kecepatan (4)
3
4
2

SKOR TERTIMBANG
Kriteria
Mampu Co
Baker Co
Masak Co
Keandalan penjual (9)
18
45
36
Biaya (6)
30
18
24
Kecepatan (4)
12
16
8
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Titik Scoring - Contoh
Skor tertimbang untuk setiap perusahaan dijumlahkan:
·                     Mampu = 60 poin
·                     Baker = 79 poin
·                     Masak = 68 poin
Berdasarkan skor sebelumnya, tawaran mungkin akan diberikan kepada Baker Co
23
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Titik Scoring - Contoh
Contoh sebelumnya adalah penyederhanaan. Dalam skenario kehidupan nyata, beberapa faktor akan berbeda:
·                     Ada mungkin akan lebih banyak kriteria yang dipertimbangkan.
·                     Beberapa orang akan Peringkat kriteria, dan nilai akhir untuk masing-masing vendor mungkin akan menjadi gabungan dari orang-nilai individu.
24
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Persyaratan biaya
·                     Perkiraan biaya pembelian atau pengembangan fitur yang tidak termasuk dalam AIS tertentu.
·                     Total biaya AIS dihitung dengan menambahkan biaya akuisisi dengan pembelian dan biaya pengembangan.
·                     Total biaya = biaya sistem dengan semua fitur yang diperlukan.
·                     Fokus pada memiliki biaya terendah sementara memenuhi persyaratan (efisiensi).
25
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Menjalankan sbg percobaan
Verifikasi bahwa AIS yang terlihat terbaik di atas kertas sebenarnya yang terbaik dalam praktek:
·                     Test-mendorong perangkat lunak.
·                     Hubungi pengguna lain untuk referensi.
·                     Evaluasi personil penjual.
·                     Mengkonfirmasi rincian proposal.
26
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
In-house
Mengembangkan perangkat lunak kustom sulit, tetapi beberapa perusahaan lebih memilih pendekatan ini-terutama jika perusahaan besar, memiliki kebutuhan yang unik, dan percaya sistem mereka memberikan keunggulan kompetitif.
(1) perangkat lunak yang dikembangkan oleh staf IS.
(2) perangkat lunak yang dikembangkan oleh pengguna akhir.
Akuntan membantu memberikan kontribusi dengan menjadi pengawas proyek, pengguna, atau anggota tim pengembangan.
27
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Software end-user-Dikembangkan
·                     Salah satu pendekatan untuk mengembangkan perangkat lunak di-rumah adalah untuk mengambil bagian terbesar dari upaya keluar dari tangan departemen IS dan menempatkannya di lap pengguna informasi utama.
28
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Software end-user-dikembangkan
·                     Akhir-pengguna komputasi (EUC) adalah tangan-pengembangan, pemanfaatan, dan pengendalian sistem informasi berbasis komputer oleh pengguna.
·                     Dengan EUC, individu menggunakan TI untuk memenuhi kebutuhan mereka sendiri IS daripada bergantung pada sistem profesional.
·                     Mengapa?
·                     Permintaan untuk sistem informasi telah berkembang pesat sejak diperkenalkannya komputer.
·                     Salah satu solusi untuk memenuhi kebutuhan ini adalah memiliki pengguna akhir memenuhi kebutuhan informasi mereka sendiri.
29
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Pengembangan pengguna akhir
·                     Teknologi telah berkembang untuk mengotomatisasi banyak proses pengembangan sistem. Faktor-faktor yang berkontribusi terhadap EUC adalah:
·                     Peningkatan melek komputer.
·                     Bahasa pemrograman yang lebih mudah digunakan.
·                     PC murah.
·                     Berbagai paket perangkat lunak yang kuat dan murah.
30
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Komputasi pengguna akhir
·                     Sebagai pengguna akhir mulai untuk memenuhi kebutuhan awal mereka, dua hal terjadi:
·                     Pengguna menyadari komputer dapat digunakan untuk memenuhi lebih banyak kebutuhan informasi.
·                     Peningkatan akses ke data yang dibuat banyak kegunaan baru dan kebutuhan untuk informasi.
·                     Result: Sebuah pertumbuhan yang luar biasa dalam komputasi pengguna akhir yang diperkirakan akan terus berlanjut.
31
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Pengembangan pengguna akhir
Pengembangan Pengguna Akhir terjadi ketika pengguna informasi, seperti manajer, akuntan, dan auditor internal, mengembangkan aplikasi mereka sendiri dengan menggunakan spesialis komputer sebagai penasehat. Tidak sesuai untuk sistem yang sangat kompleks. Mungkin cocok untuk proyek-proyek sederhana.
32
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
EUC - Manfaat
·                     Manfaat end-user computing:
·                     Penciptaan pengguna, kontrol, dan pelaksanaan
·                     Sistem yang memenuhi kebutuhan pengguna
·                     Aktualitas
·                     Membebaskan sumber daya sistem
·                     Fleksibilitas dan kemudahan penggunaan
33
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
EUC - Risiko
·                     Risiko komputasi end-user:
·                     Logika dan pengembangan kesalahan
·                     Aplikasi tidak cukup diuji
·                     Sistem yang tidak efisien
·                     Sistem tidak terkontrol dan didokumentasikan
·                     Sistem yang tidak kompatibel
·                     Duplikasi sistem dan data dan sumber daya terbuang
·                     Peningkatan biaya
34
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Mengelola dan mengendalikan EUC
·                     Memberikan bantuan-meja
·                     Pengguna hujan T dalam bagaimana risiko dan manfaat EUC
·                     E valuate hardware dan software produk baru
·                     Menetapkan standar untuk mengembangkan dan menerapkan perangkat lunak
·                     Data perusahaan C ontrol
35
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Outsourcing sistem
Outsourcing: menyewa perusahaan luar untuk menangani semua atau sebagian dari kegiatan pengolahan data organisasi. Berkembang pesat bisnis.
Kadang-kadang seluruh organisasi TI dipindahkan ke perusahaan lain.
36
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Outsourcing
Contoh kegiatan outsourcing:
·                     Instalasi
·                     Latihan
·                     Pemeliharaan
·                     Help desk
·                     Dukungan teknis
37
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Outsourcing
·                     Sebagian besar perusahaan yang melakukan outsourcing menggunakan beberapa perusahaan yang berbeda daripada satu sumber untuk:
·                     Meningkatkan fleksibilitas
·                     Kompetisi Foster
·                     Mengurangi biaya
·                     Sebagian besar perusahaan tidak outsourcing:
·                     Manajemen strategis lingkungan TI mereka
·                     Manajemen proses bisnis
·                     Arsitektur TI
38
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Outsourcing - Manfaat
·                     Menyediakan solusi bisnis
·                     Pemanfaatan aset
·                     Akses ke pengalaman yang lebih besar dan teknologi yang lebih maju
·                     Biaya yang lebih rendah
·                     Peningkatan waktu pengembangan
·                     Penghapusan penggunaan puncak-dan-lembah
·                     Fasilitasi perampingan
39
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Outsourcing - Risiko
·                     Kaku (kontrak jangka panjang)
·                     Kehilangan kontrol (sistem, data rahasia)
·                     Keunggulan kompetitif Mengurangi
·                     Terkunci dalam sistem (harus membangun kembali keahlian)
·                     Tujuan terpenuhnya (manfaat yang belum direalisasi)
·                     Layanan yang buruk (respons yang lambat)
·                     Peningkatan risiko (risiko bisnis)
40
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Business Process Reengineering
·                     Rekayasa ulang proses bisnis (BPR) adalah analisis dan desain ulang proses bisnis dan sistem informasi untuk mencapai peningkatan kinerja yang signifikan.
·                     Mengurangi perusahaan untuk proses bisnis penting.
·                     Membentuk ulang praktek kerja organisasi dan arus informasi untuk mengambil keuntungan dari kemajuan teknologi.
41
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Business Process Reengineering
·                     BPR:
·                     Menyederhanakan sistem.
·                     Membuatnya lebih efektif.
·                     Meningkatkan perusahaan 's kualitas dan pelayanan.
·                     Manajemen Proses Bisnis (BPM) perangkat lunak yang telah dikembangkan untuk membantu mengotomatisasi banyak tugas BPR.
42
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Business Process Reengineering
Michael Hammer telah ditetapkan beberapa prinsip yang membantu organisasi berhasil merekayasa ulang proses bisnis:
·                     Mengatur sekitar hasil, bukan tugas.
·                     Mengharuskan mereka yang menggunakan output untuk melakukan proses.
·                     Mengharuskan mereka yang memproduksi informasi untuk memprosesnya.
·                     Sentralisasi DAN membubarkan data.
·                     Mengintegrasikan kegiatan paralel.
·                     Memberdayakan pekerja, menggunakan built-in kontrol, dan meratakan struktur organisasi.
·                     Menangkap data sekali - pada sumbernya.
43
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Tantangan yang dihadapi oleh usaha-usaha rekayasa ulang
Banyak upaya BPR gagal atau jatuh pendek dari tujuan mereka. Perusahaan harus mengatasi kendala berikut:
·                     Tradisi (perubahan budaya & kepercayaan)
·                     Perlawanan
·                     Waktu dan biaya persyaratan (BPR mahal, membutuhkan waktu)
·                     Kurangnya dukungan manajemen
·                     Skeptisisme (hal yang sama, kotak yang berbeda)
·                     Pelatihan ulang (mahal)
·                     Kontrol (menjaga kontrol penting)
44
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Prototyping
Prototyping adalah sebuah pendekatan untuk merancang sistem di mana suatu model kerja yang disederhanakan dari suatu sistem dikembangkan.
·                     Prototipe (draft pertama) dibangun dengan cepat dengan biaya rendah dan diberikan kepada pengguna untuk bereksperimen.
·                     Bermain dengan prototipe memungkinkan pengguna untuk menentukan apa yang mereka lakukan dan tidak suka.
·                     Pengembang memodifikasi sistem dalam menanggapi komentar pengguna dan kembali hadir kepada mereka.
·                     Proses berulang-ulang terus sampai pengguna puas bahwa sistem memenuhi kebutuhan mereka.
45
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Prototyping
·                     Empat langkah yang terlibat dalam mengembangkan prototipe:
·                     (1) Mengidentifikasi persyaratan dasar
·                     (2) Mengembangkan prototipe awal
·                     (3) iterasi berulang
·                     (4) Gunakan sistem
46
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme

Kapan menggunakan prototyping
·                     Pengguna don 't memahami kebutuhan mereka, atau kebutuhan berubah dengan cepat.
·                     Persyaratan sistem sulit untuk didefinisikan.
·                     Input dan output sistem tidak diketahui.
·                     Tugas yang harus dilakukan adalah tidak terstruktur atau semi-terstruktur.
·                     Desainer tidak yakin tentang apa teknologi yang akan digunakan.
·                     Sistem ini sangat penting dan dibutuhkan cepat.
·                     Risiko mengembangkan sistem yang salah adalah tinggi.
·                     Reaksi para pengguna ke sistem baru pertimbangan pembangunan yang penting.
·                     Banyak strategi desain harus diuji.
·                     Staf desain memiliki sedikit pengalaman mengembangkan jenis sistem atau aplikasi.
·                     Sistem ini akan digunakan jarang sehingga efisiensi pengolahan tidak penting.
47
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Prototyping
Kandidat yang baik untuk prototyping:
·                     Sistem pendukung keputusan.
·                     Sistem informasi eksekutif.
·                     Sistem pakar.
·                     Information Retrieval sistem.
·                     Sistem yang melibatkan eksperimentasi dan pengembangan trial-and-error.
·                     Sistem di mana persyaratan berkembang sebagai sistem yang digunakan.
48
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Prototyping
Prototyping biasanya tidak sesuai untuk:
·                     Sistem yang besar atau kompleks yang:
·                     Sajikan komponen organisasi utama; atau
·                     Melintasi berbagai batas-batas organisasi.
·                     Komponen AIS standar, seperti:
·                     Piutang
·                     Hutang
·                     Manajemen persediaan
49
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Prototyping - Keuntungan
·                     Definisi yang lebih baik dari kebutuhan pengguna
·                     Keterlibatan pengguna yang lebih tinggi dan kepuasan
·                     Waktu pengembangan yang lebih cepat
·                     Sedikit kesalahan
·                     Kesempatan lainnya untuk perubahan
·                     Lebih murah
50
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Prototyping - Kekurangan
·                     Waktu pengguna yang signifikan
·                     Penggunaan kurang efisien dari sumber daya sistem
·                     Pengembangan sistem lengkap
·                     Sistem tidak cukup diuji dan didokumentasikan
·                     Reaksi perilaku negatif
·                     Pernah berakhir pengembangan
51
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Perangkat lunak komputer dibantu (atau sistem) rekayasa
·                     Perangkat lunak komputer dibantu (atau sistem) engineering (CASE) alat adalah paket terpadu alat berbasis komputer yang mengotomatisasi aspek-aspek penting dari proses pengembangan perangkat lunak.
·                     Digunakan untuk merencanakan, menganalisis, merancang program, dan memelihara sistem informasi.
·                     Juga digunakan untuk meningkatkan upaya manajer, pengguna, dan programmer dalam memahami kebutuhan informasi.
52
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
Software CASE
·                     Alat CASE tidak menggantikan desainer terampil, tetapi memberikan pengembang dengan dukungan yang efektif untuk semua fase SDLC.
·                     Software CASE biasanya mencakup perangkat untuk:
·                     Perencanaan strategis
·                     Proyek dan manajemen sistem
·                     Desain database
·                     Layar dan laporan tata letak
·                     Pembuatan kode otomatis
53
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
CASE - Keuntungan
·                     Peningkatan produktivitas (lebih dari 600%)
·                     Peningkatan kualitas Program (menjaga konsistensi)
·                     Penghematan biaya (80-90%)
·                     Peningkatan prosedur pengendalian
·                     Dokumentasi disederhanakan (otomatis)
54
2010 Foster Business School ACCTG. 320 AIS ​​L.DuCharme
CASE - Kekurangan
·                     Masalah dengan teknologi CASE:
·                     Ketidakcocokan dengan sistem lain
·                     Biaya (mahal sampai $ 350.000 untuk alat)
·                     Harapan Unmet (kurang dari 50% percaya manfaat yang diharapkan diperoleh)


Comments

Post a Comment

Popular posts from this blog

suwardjono BAB 9 BIAYA

Image
TUGAS TEORI AKUNTANSI BAB 9 BIAYA Disusun oleh Kelompok 8: Hannik Inayatur Rahma          (13312402) Elsa Delviana                          (13312424) Merryzsa Septerie Anitha       (13312506) Kelas E Dosen Pengampuh:      Yuni Nustini Tahun Pelajaran 2015/2016 Kata Pengantar Puji syukur kehadirat Allah SWT, atas Rahmat-Nyalah kami bisa membuat tugas teori akuntasi, dengan baik dan lancar tanpa adanya halangan yang menerpa kepada kelompok kami. Dan kami berterima kasih kepada dosen pengampuh ibu Yuni Nustini karena telah memberikan tugas ini agar kami bisa merangkum dan membuat sebuah tugas dengan kata-kata kami. Kami merasa banyak sekali kekurangan dalam memilih kata-kata pada saat merangkum sebuah karya orang lain ke kata-kata kami. Ka...
Read more

Kasus 6-4 Medoc Company

Image
Kasus 6-4 Medoc Company 1.       Saran apakah yang akan Anda berikan pada kendala struktur organisasi dalam kasus? ·          Memberikan informasi yang relevan kepada masing-masing  unit usaha untuk menentukan imbal balik yang optimum antara biaya dan pendapatan perusahaan. ·          Menghasilkan keputusan yang selaras dengan cita-cita -maksudnya, sistem harus dirancang sedemikian rupa sehingga keputusan engingkatkan laba unit usaha juga akan meningkatkan laba perusahaan. ·          Membantu pegukuran kinerja ekonomi dari unit usaha individual. ·          Memberikan sistem yang mudah dimengerti dan dikelola. Orang-orang yang Kompeten Secara ideal, para manajer harus memperhatikan kinerja jangka panjang daari pusat tanggung jawab mereka, sam seperti kinerja jangka pendeknya. Adapun ...
Read more

Diskusi Tim Audit

Diskusi Tim Audit Tinjauan Umum Unsur penting dalam sukses penugasan audit manapun, adalah komunikasi yang baik diantara anggota tim audit. Manfaat komunikasi yang baik adalah: ·          Produktivitas audit ·          Efektivitas audit ·          Pengembangan staf Komunikasi berkelanjutan yang efektif memerlukan: ·          Keterlibatan penuh dari partner penugasan dan anggota inti lainnya. ·          Kesediaan personel senior untuk mendengar personel yang lebih junior Pertemuan Perencanaan Tim Audit  Dalam penugasan yang lebih besar, pertemuan mengenai perencanaandijadwalkan jauh sebelum dimulainya pekerjaan lapangan. Tiga hal yang dibahas selanutnya yaitu sebagai berikut: ·          Berbagi insight tentang entitas ...
Read more