1. Dian Lukitasari/5209100038
RizkaMarsaPramadani/52091000044
Terdapat 9 faktor yang menjadi penyebab error pada software, yaitu :
1. Faulty requirement definition
2. Client-developer communication failures
3. Deliberate deviation from SW requirements
4. Logical design errors
5. Coding errors
6. Non-compliance with documentation and coding instructions
7. Shortcomings of the testing process
8. Procedure errors
9. Documentation errors
Berikut adalah penjelasan dari salah satu penyebab diatas berikut dengan studi kasus serta solusinya.
Faulty requirement definitionmerupakan error yang disebabkan oleh kesalahan dalam menganalisa
kebutuhan dari klien.DalamFaulty requirement definition, suatu software perludiketahuidahuluapa yang
dimaksuddengan software requirement. Berdasarkansumber – sumber yang didapat.Software
requirements berisikankebutuhandankendala yang ditempatkanpadaprodukperangkatlunak yang
memberikankontribusipadasolusidaribeberapamasalahdunianyata.
Menganalisa kebutuhan merupakan hal yang paling utama dalam mengembangkan software. Dikarenakan
analisa kebutuhan yang tidak tepat akan menghasilkan perangkat lunak yang tidak berguna karena
dianggap tidak memenuhi yang diinginkan klien. Kuranghati-hatidanpelaksanaan yang tidakteliti,
sehinggamengakibatkanterjadinyakesalahananalisakebutuhansungguhmenimbulkanbanyakkerugian.Deng
andiperolehnyakebutuhan yang jelasdanbenarsesuaidenganapa yang dimaksudolehklien,
menunjukkanlangkahawal yang baik, yang
akanmembantuketikakitamelanjutkankepadatahapberikutnyadalampembuatanperangkatlunak.
Ada 3 faktor yang harusdipenuhiketikamelakukananalisakebutuhaniniyaitu :
1. Lengkap,
2. Detail,
3. danBenar.
Lengkapberartisemua yang diharapkanolehklientelahdidapatkanolehpihak yang
melakukananalisa.Sedangkandetailmaksudnyaadalahberhasilmengumpulkaninformasi yang
rincisampaihal-hal yang kecil. Semua data darianalisakebutuhaniniharuslahbenar, sesuaiapa yang
dimaksudolehklien, bukanbenarmenurutapa yang difikirkanolehpihak yang melakukananalisa.
2. StudiKasus
Suatuperusahaan software developer bernama PT Mataharibergerakdibidang software untuk POS
(Point of Sale) yang digunakan di Toko-tokodan supermarket
untuktransaksidenganparapembelidanjugauntukmanajemenkeluarmasukbarang,
danpelaporannya.Sebuah supermarket Panama menginginkankomputerisasi di bisnis retail yang
dijalankannyadenganmemesan software tersebutke PT Matahari. PT Mataharimenawarkan
software yang sudahdibuatnyadanbanyakdipakai di beberapa supermarket danmendemokan
software tersebutpadapihak customer supermarket Panama.Ternyataadabeberapa system ataufitur
yang tidakadaseperti yang diharapkanoleh customer
danfiturtersebutsangatdiperlukandalamoperasibisnis di supermarket Panama.Salah
satunyaadalahfiturdiskonpembelian.PT Mataharimenggunakanpersentasedalam system
diskonpembelian.Dari pihak supermarket Panama menggunakan system rupiah
dalamsistemdiskonpembeliankarenapemberiandiskonhanyadiberikanpadapembeli-
pembelitertentu yang memenuhisyaratdanpertimbanganmanajemen.Supermarket Panama
jugamenginginkanadasistempelaporanberupagrafiksehinggamudahdalammengambilkeputusanbis
nisselanjutnya.Pihak customer menginginkanpelaporanharussistematis, menarik,
danmudahuntukdiambilkesimpulan.
Dari permasalahantersebutdiatas, perlunya requirement elicitation
untukmengindentifikasikebutuhan
costumer.Untukmengubahfiturdiskonpembeliandarisistempersenke rupiah mungkinsudahjelas,
danterdefinisidenganbaik, dan relative mudahuntukdimengertiolehpihak software
developer.Namununtukfiturpelaporan yang menarik,
sistematisdanmudahuntukdiambilkesimpulanmerupakanpermasalahancenderungabstrak.Dan
inimungkinpekerjaaninimemerlukanbeberapa kali revisikarenatidaksesuaidengankebutuhan
customer.
Solusi :
Sebaiknyapihak developer mencariaspek-aspekapasaja yang
diinginkandalamsistempelaporandanmanajemenbisnis retail danmendefinisikannyadalam
requirement specification untukditetapkansebagaiacuanpembuatan software yang
bisadipahamiolehkeduabelahpihak. Requirement specification
inidigunakansebagaibatasanpekerjaan yang harusdikerjakanoleh software developer,
sehinggaketikatahap testing, customer tidaklagimenuntutjika customer ternyatamasihmerasaada
requirement yang terlupakanpada software tersebut.Permintaan agar software
tersebutmenarikdanmudahdipahamisebaiknya developer
mendesainGUInyaterlebihdahulusebelummemulai coding.Jika GUI
sudahdisetujuimakaakandigunakansebagaiacuanuntukproyekpembuatan software.
Namunsebaiknyapihak developer masihtetapfleksibeluntukmelayanijika customer
memintaperubahanpadadesainatau requirement specification yang
sudahditetapkanbersamadenganpertimbangantertentumisalnya, pihak customer
harusmenggantibiayarevisi.
Referensi :
