Sabtu, 15 Oktober 2016

Ringkasan The Software Problem


Masalah software


Dalam masalah perangkat lunak biaya, jadwal, dan kualitas adalah kekuatan pendorong dasar. Oleh karena itu, metode dan alat-alat yang akan digunakan untuk memecahkan masalah dalam hal ini harus memastikan produktivitas yang tinggi dan kualitas tinggi. Biaya, Jadwal, dan Kualitas:

1.Biaya

Biaya jadwal dan kualitas menjadi kekuatan pendorong utama dalam software. dalam software ada tiga kekuatan dasar yaitu biaya, jadwal, dan kualitas. perangkat lunak ini harus diproduksi dengan biaya yang murah,dan dalam waktu yang wajar, serta harus berkualitas baik. Ketiga parameter tersebut sangat menentukan dalam proyek software. Software industri sangat mahal terutama karena  pengembangan perangkat lunak sangat padat karya. Untuk mendapatkan ide dari biaya yang terlibat,  mari kita perhatikan keadaan saat praktik di industri. Baris kode (LOC) atau ribuan baris kode (KLOC) disampaikan adalah yang paling umum digunakan ukuran ukuran software di industri.  Karena biaya utama memproduksi perangkat lunak adalah tenaga yang digunakan. produktivitas sering diukur dalam industri dalam hal LOC (atau KLOC) per bulan.

2.Jadwal

Jadwal merupakan faktor penting dalam banyak proyek. tren bisnis mendikte bahwa waktu dari pasar ke produk harus dikurangi; yaitu, waktu siklus dari konsep untuk pengiriman harus kecil. Untuk software ini berarti bahwa perlu dikembangkan lebih cepat, dan dalam waktu yang ditentukan. Sayangnya, sejarah perangkat lunak ini penuh dengan kasus di mana proyek telah secara substansial terlambat.
Oleh karena itu,perlu mengurangi biaya dan waktu siklus untuk perangkat lunak karna pembangunan adalah tujuan utama dari rekayasa perangkat lunak. Produktivitas dalam hal output (KLOC) per orang memadai dapat menangkap biaya dan kekhawatiran jadwal. Jika produktivitas lebih tinggi, biaya akan lebih rendah (pekerjaan yang sama kini dapat dilakukan dengan lebih sedikit orang perbulan). Demikian pula, jika produktivitas lebih tinggi, potensi pengembangan perangkat lunak dalam waktu kurang meningkatkan-tim produktivitas yang lebih tinggi akan menyelesaikan pekerjaan dalam waktu kurang dari tim yang sama dengan produktivitas rendah tentu saja, tergantung juga pada jumlah orang yang terletak pada proyek tersrebut. Oleh karena itu, mengejar produktivitas yang lebih tinggi adalah kekuatan pendorong dasar di balik rekayasa perangkat lunak.

3.Kualitas
Selain biaya dan jadwal, software faktor utama pendorong adalah kualitas. Hari ini, kualitas adalah salah satu mantra utama, dan strategi bisnis yang dirancang di sekitar. Sayangnya, sejumlah besar kasus terjadi mengenai tidak dapat diandalkan perangkat lunak-perangkat lunak sering tidak melakukan apa yang seharusnya dilakukan atau melakukan sesuatu tidak seharusnya dilakukan. Jelas, mengembangkan perangkat lunak berkualitas tinggi adalah tujuan mendasar lain dari rekayasa software. Namun, sementara biaya umumnya dipahami, konsep kualitas dalam konteks perangkat lunak perlu penjelasan lebih lanjut. Kualitas perangkat lunak terdiri dari enam atribut utama:


1.      Functionality: Kemampuan untuk menyediakan fungsi yang memenuhi dinyatakan dan tersirat kebutuhan ketika perangkat lunak yang digunakan
2.      Reliability: Kemampuan untuk menyediakan layanan kegagalan bebas
3.      Usability: Kemampuan untuk memberikan kinerja yang relatif sesuai dengan jumlah   sumber daya
4.      Efficiency: Kemampuan untuk memberikan kinerja yang relatif sesuai dengan jumlah sumber daya yang digunakan.
      5    Maintainability: Kemampuan yang akan dimodifikasi untuk keperluan membuat
           koreksi
6.      Portability: Kemampuan yang akan disesuaikan untuk different ditentukan environ tanpa tindakan menerapkan atau berarti selain yang disediakan untuk tujuan ini dalam produk
Untuk menentukan kualitas produk perangkat lunak, kita perlu menentukan jumlah cacat pada perangkat lunak yang disampaikan. Jumlah ini jelas tidak diketahui pada waktu pengiriman dan mungkin tidak akan pernah diketahui. Salah satu pendekatan untuk mengukur kualitas adalah untuk log cacat ditemukan dalam 6 bulan (atau 1 tahun) setelah melahirkan dan menentukan kualitas sehubungan dengan cacat ini. Ini berarti bahwa kualitas perangkat lunak yang dikirimkan hanya dapat ditentukan 6 bulan setelah pengiriman. Kepadatan cacat bisa, bagaimanapun, juga diperkirakan dari data masa lalu yang sama proyek-jika sama pendekatan yang digunakan, maka diharapkan proyek ini akan memiliki kerapatan cacat yang sama sebagai proyek masa lalu.

Perlu menunjukkan bahwa menggunakan definisi kualitas, apa cacat yang harus didefinisikan secara jelas. Sebuah cacat bisa ada beberapa masalah dalam perangkat lunak yang menyebabkan perangkat lunak untuk crash atau masalah yang menyebabkan output untuk tidak selaras dengan benar atau yang salah mengeja beberapa kata, dll yang tepat definisi apa yang dianggap cacat jelas akan tergantung pada proyek atau standar organisasi mengembangkan penggunaan proyek (biasanya itu adalah yang terakhir)




1.2 Skala dan Perubahan

 

Meskipun biaya, jadwal, dan kualitas adalah kekuatan pendorong utama untuk project (perangkat lunak industri), ada beberapa artribut lainnya skala dan perubahan dari domain masalah juga mempengaruhi pendekatan solusi yang dipekerjakan. Kebanyakan sistem perangkat lunak industri cenderung besar dan kompleks, membutuhkan puluhan ribu baris kode. Seperti yang diharapkan, pengembangan sistem besar membutuhkan satu set yang berbeda dari metode pengembangan sistem kecil, seperti metode yang digunakan untuk mengembangkan sistem yang kecil sering tidak meningkatkan ke sistem yang besar 


Setiap project software melibatkan penggunaan teknik dan management project. Dalam project kecil, metode informal bagi pengembangan dan pengelolaan dapat digunakan. Namun, untuk project-project besar harus jauh lebih ketat, dengan kata lain, untuk berhasil melaksanakan proyek, sebuah metode yang tepat untuk rekayasa sistem harus bekerja dan proyek telah dikelola ketat untuk memastikan biaya yang, jadwal, dan kualitas tetap dapat terkontrol. Seperti yang dibahas diatas, software harus berubah bahkan setelah itu diserahkan. dari berlangsung.

Seperti kode sumber, perlu diubah karena beberapa perubahan persyaratan atau karena beberapa hal cacat yang perlu dihapus. perubahan kebutuhan adalah karateristik dari domain masalah. Dalam dunia sekarang ini, pendekatan yang tidak dapat menerima dan mengakomodasi perubahan jarang digunakan, mereka dapat memecahkan hanya beberapa masalah yang tahan perubahan



0 comments:

Posting Komentar