Projek menterjemah dimulai 29/5/2006. Ianya merupakan ringkasan dari modul OUM + Nota dari laman web saya. Tujuan utama adalah untuk membantu rakan supaya mudah memahami Subjek ini.

 

Membuat nota bukanlah suatu perkara mudah, oleh itu saya meletakkan nota ini dalam kategori

DONATION WARE

Iaitu sumbangan dari pembaca amatlah dialu-alukan.

 

Sumbangan boleh dilakukan melalui akaun bank di atas nama saya: Rozaimy Baharuddin

1)   Maybank       114253224132

    2) RHB               2-14099-00004030

 

Sekiranya sumbangan wang ringgit tidak dapat disumbangkan. Cukuplah sekadar email saya di sumbangan@gmail.com apabila saudara/i memuat turun dari laman web saya. Seterusnya email sekali lagi selepas saudara/i memperolehi keputusan peperiksaan. Ini membolehkan saya mengetahui keberkesanan nota ini.

 

Terima Kasih kerana sudi menjadi nota ini sebagai rujukan.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Bab 5 IT Project Estimates (Anggaran Projek IT)

 

5.1 Software Estimates (Anggaran Perisian)

 

Anggaran adalah taksiran hasil kuantitatif

 

Anggaran perisian merangkumi anggaran usaha, kos, jadual dan pekerja (jumlah perkerja)

 

Usaha (effort) adalah jumlah jangka masa yang diperlukan oleh seseorang untuk menyiapkan tugasan

 

Jadual (schedule) adalah jumlah jangka masa yang dirancang untuk melengkapkan tugas

 

Anggaran untuk pembangunan projek perisian mesti mempunyai unit ukuran. Contoh: usaha (effort) di ukur dalam seorang dalam jam (person-hours), seorang dalam seminggu (person-weeks),  seorang dalam bulan (person-months) dll. Unit ukuran yang digunakan adalah untuk pengkhususan:

 

a)      Produk (rekabentuk, kod sumber dll)

b)      Proses (aktiviti analisis, rekabentuk dan pengkodan dll)

c)      Manusia (people) (produktiviti  rekabentuk individu dll)

 

Anggaran yang baik berupa penerangan mengenai skop projek, penilaian teknik yang digunakan, dan ketepatan anggaran yang dibuat. Anggaran awalan akan menghasilkan keputusan yang tepat dan boleh dipercayai anggarannya dan faktor kos yang mempengaruhi pembangunan perisian mudah difahami. Anggaran ada satu proses yang berterusan apabila berlaku perubahan dari segi skop, perubahan perlu dilakukan apabila berlaku perbezaan parameter seperti usaha, kos, jadual, kakitangan dll.

 

 

5.1.1 Benefits

 

Manfaat terhadap anggaran perisian adalah:

 

 

 

 

 

 

 

5.1.2 Stages where Estimates are Done (Peringkat Dimana Anggaran Selesai)

 

Peringkat

Penerangan

Strategic Planning

(Perancangan Strategik)

Kos dan faedah daripada pengkomputeran aplikasi yang berpotensi harus dianggarkan untuk menentukan keutamaan yang perlu diberikan pada setiap projek

Feasibility Study

(Pengkajian Kebolehlaksanaan)

Pengajian kebolehlaksanaan mesti dipastikan manfaat daripada sistem yang dicadangkan dapat dijustifikasi ke atas kosnya

System Specification

(Spesifikasi Sistem)

Usaha itu diperlukan untuk dilaksanakan usul reka bentuk yang berbeza perlu dibuat anggaran. Anggaran pada peringkat reka bentuk juga mesti dipastikan pengkajian kebolehlaksaan masih munasabah

Evaluation of Supplier’s Proposals

(Penilaian Cadangan Pembekal)

Kakitangan di dalam software house yang menimbangkan cadangan atau tender mesti disemak dengan spesifikasi sistem dan menyediakan anggaran berdasarkan cadangan penilaian tersebut

Project Planning

(Perancangan Projek)

Sebagai perancangan dan pelaksanaan tentang kemajuan projek kepada peringkat yang lebih terperinci, lebih terperinci anggaran terhadap elemen kerja yang kecil akan dibuat

 

 

Anggaran dibuat pada pelbagai peringkat terhadap projek perisian. Pada setiap peringkat, alasan untuk anggaran dan metod yang digunakan tidak sama. Langkah penting seperti yang ditunjukkan pada jadual di atas.

 

 

 

 

Parkinson’s Law

Brooks’ Law

“Work expands to accommodate the time available”

“Putting more people on a late job makes it later”.

This implies that given an easy target, staff will work less hard.

 

The effort required to implement a project will go up disproportionately with the number of staff assigned to the project.

 

 

 

 

 

 

 

 

5.1.3 Problems with Over-estimates dan Under-estimates (Masalah Anggaran berlebihan dan Anggaran Terkurang)

 

Terlebih anggaran boleh menyebabkan projek mengambil masa yang lama dari sepatutnya.

 

Terkurang anggaran boleh menyebabkan projek mengambil masa lebih singkat dari satu anggaran murah hati. Bahaya kepada anggaran terkurang adalah ia akan memberi kesan kepada kualiti. Kakitangan yang kurang mahir mungkin terdesak dengan tarikh akhir projek itu perlu disiapkan dan akan melakukan kerja yang tidak berkualiti (sub standard).

 

Anggaran terkurang akan menyebabkan jumlah pekerja akan dikurangkan oleh pengurus dan akibatnya meningkatkan tekanan terhadap pekerja yang terlibat dalam projek tersebut.

 

 

5.1.4 Software Estimation Process (Proses Anggaran Perisian)

 

Anggaran perisian adalah proses terus menerus yang mesti digunakan sepanjang kita hayat projek. Proses mengenai saiz, kos dan jadual perisian bermula dengan definasi keperluan fungsian yang diperlukan dalam projek. Dua atau lebih orang mesti terlibat di dalam membuat anggaran pembangunan. Pengurus projek tidak sepatutnya bergantung kepada seseorang atau metod untuk membina anggaran perisian.

 

Terdapat lima prosedur untuk proses anggaran perisian iaitu:

 

Prosedur

Penerangan

Estimate Size

(Anggaran saiz)

Produk perisian selalunya diukur dalam Source Lines Of Code (SLOC).  WBS, SLOC atau fungsi mata boleh digunakan untuk menanggarkan saiz perisian produk. Tentukan sama ada perisian tersebut dibangunkan menggunakan kod sumber baru atau kombinasi kod baru dengan kod lama. Anggaran kos untuk penyesuaian kod sedia adalah sama penting dengan anggaran kos untuk kod baru. Malah kadang-kadang penyesuaian kod lama lagi sukar untuk dibangunkan. Anggaran saiz perisian produk mesti berdasarkan kepada data lama (jika ada) dan pengalaman yang lepas-lepas

Estimate Cost and Effort (Anggaran Kos dan Usaha)

Kunci utama pada peringkat ini adalah anggaran saiz untuk projek tersebut. Anggaran mesti termasuk semua aktiviti pekerjaan yang terlibat dengan tugas. Aktiviti ini termasuk upah pekerja untuk tugas kerja lain yang terlibat dengan projek tersebut. Anggaran kos perlu dibuat seawal kitar hayat projek iaitu sebaik sahaja keperluan perisian ditentukan. Anggaran kos selalunya mengenai usaha (effort) atau orang sehari/minggu, yang mana boleh diterjemahkan sebagai asas kadar upah buruh. Contoh:

Kos untuk 20 bulan kitar hayat projek adalah pada kadar 17.8 orang sehari, Kadar bayaran adalah RM 200 seorang sehari, maka jumlah kos adalah RM 71,200

Estimate Schedule (Anggaran Jadual)

Tujuan membuat anggaran jadual adalah untuk menentukan jumlah masa (length of time) yang diperlukan untuk menyiapkan projek dan menentukan milestones yang utama dan membuat penilaian akan berlaku. Sebelum proses ini, anggaran fungsian WBS, saiz dan kos mesti disiapkan. Jadual anggaran boleh dihasilkan dengan cara manual atau dengan menggunakan model anggaran automatik atau kedua-duanya sekali

Inspect and Approve Estimate (Memeriksa dan Menyokong Anggaran)

Tujuan pada peringkat ini adalah untuk meningkatkan kualiti anggaran yang dihasilkan dan mendapatkan komitmen pengurusan atasan. Objektif pada peringkat ini termasuk:

  • pengesahan rekabentuk perisian dan fungsian WBS,
  • verifikasi  ke atas metod anggaran yang digunakan,
  • memastikan data dan andaian yang digunakan di dalam membuat anggaran adalah betul,
  • memperoleh saiz,
  • jadual dan anggaran kos
  • mengesahkan dan merekodkan anggaran rasmi untuk projek

Track Estimates

(Prestasi Anggaran)

Tujuan pada peringkat ini adalah untuk memeriksa ketepatan anggaran apabila masa berlalu dan membangunkan data empiris dengan berlalunya masa. Anggaran mesti dlihat merentas masa untuk membandingkan perancangan dengan keadaan sebenar yang mendatang. Ini membolehkan kakitangan projek melihat progres dan bagaimana ketepatan mereka membuat anggaran.

 

 

5.1.5 Basic for Software Estimation (Asas Kepada Anggaran Perisian)

 

The Need for Historical Data (Perlu Data Bersejarah)

Kebanyakkan metod anggaran memerlukan maklumat mengenai bagaimana projsek dilaksanakan dimasa lalu. Data yang ada perlu dinilai mengikut kepakaran orang yang menganggar itu, ini kerana setiap projek mempunyai persekitaran yang berbeza seperti bahasa pengaturcaraan berlainan, alat bantuan perisian yang ada, piawai yang dilaksanakan dan kemahiran kakitangan.

 

Measure of Work (Ukuran Kerja)

Masa yang digunakan untuk menulis sesuatu program akan berbeza mengikut kemampuan dan kemahiran juru aturcara. Masa pelaksanaan mungkin berbeza kerana faktor persekitaran projek.  Amalan biasa digunakan untuk menyatakan kandungan kerja yang perlu dilakukan terhadap sistem yang akan dibangunkan adalah dengan menggunakan ukuran seperti SLOC. Penggunan jadual atau diagram atau cara anggaran saiz yang mengunakan keperluan fungsian.

 

Complexity (Kerumitan)

Dua porgram yang mempunyai SLOC atau KLOC (thousand lined of Code) yang sama tidak semestinya mengambil masa yang sama untuk menulisnya walaupun dibuat oleh pembangun perisian yang sama pada persekitaran yang sama. Satu program mungkin lebih rumit dari problem yang lain. Kerumitan sesuatu kerja perlulah diambil kira dalam membuat anggaran.

 

5.2 Software Effort Estimation Techniques (Teknik Anggaran Usaha Perisian)

 

5.2.1 Bottom-up Estimation (Anggaran dari Bawah ke Atas)

 

Dengan menggunakan pendekatan dari bawah ke atas, anggaran terhadap projek dipecahkan kepada tugas-tugas komponen dan kemudian anggaran terhadap usaha yang perlu dilakukan akan dikira untuk setiap tugas.Dengan projek yang besar, proses memecahkan akan dilakukan berulang kali, setiap tugas akan dianalisis kepada komponen sub tugas dan ditukar untuk analisis seterusnya. Setiap tugas ada jumlahkan untuk mendapat anggaran keseluruhan. Keadah ini amat sesuai digunak untuk memperolehi maklumat yang lebih terperinci dan merupakan peringkat perancangan projek. Dimana projek tersebut merupakan projek baru atau tiada data lama yang dapat diguna pakai maka kaedah dari atas ke bawah (bottom-up) adalah lebih sesuai.

 

 

 

5.2.2 Top-down Estimation (Anggaran dari Atas ke Bawah)

 

Ini merupakan anggaran keseluruhan projek. Selalu digunakan oleh pemilik perisian global yang mengeluarkan produk perisian.  Anggaran ini selalunya berdasarkan pengalaman projek lepas termasuk kos untuk semua fungsian di dalam projek. Sebagai contoh: Kos untuk Fungsian untuk intergrasi dokumen, jaminan kualiti perisian, konfigurasi pengurusan dll.

 

 

5.2.3 Expert Judgment (Pakar Pendapat)

 

Metod ini bergantung kepada seorang atau lebih orang yang mahir di dalam sesuatu percubaan mengenai sesuatu masalah. Contoh: Aplikasi kawasan atau pembangunan persekitaran. Metod ini banyak digunakan di dalam metod anggaran secara manual.

 

 

5.2.4 Estimating by Analogy (Anggaran Menerusi Analogi)

 

Merupaka satu metod yang lama tetapi dapat dipercayai. Metod ini merupakan perbandingan terhadap cadangan projek terhadap projek yang telah siap yang secara amnya sama dimana kosnya telah diketahui. Kemiripan itu harus sampai sehingga jenis perniagaan terlibat, saiz aplikasi secara menyeluruh, skop am sistem dan metod teknikal, piawai dan bahasa yang digunakan. Jika terdapat perbezaan dari yang dinyatakan tadi,  perubahan perlu dilakukan. Metod ini menekan keperluan kos perisian terhadap pengkalan data yang lama. Semakin banyak data yang boleh didapati, semakin tepat anggaran yang akan dibuat.

 

Kelebihan metod analogi ini adalah menganggarkan kos keseluruhan projek dengan cepat seperti semasa menyiapkan cadangan. Bahaya yang mungkin dihadapi mengunakan metod analogi adalah perbezaan antara projek lama dengan projek baru. Sekiranya projek lama mempunyai fungsian yang lebih mudah dari projek baru, maka akan berlaku anggaran yang berlebihan (over estimate). Begitu juga sebaliknya akan berlaku kekurangan anggaran (under estimate).

5.2.5 Analysis Effort Method (Metod Analisis Usaha)

 

Metod ini amat sesuai untuk menghasilkan anggaran permulaan untuk sesuatu projek iaitu sebelum projek bermula. Secara amya, anggaran usaha (effort) memerlukan analisis kerja ke atas sejumlah fungsian projek dan kemudian menyediakan anggaran untuk peringkat projek yang berikut melalui penggunaan ratio terhadap analisis usaha.

 

Setelah fungsian dikenal pastik, maka penilai perlu menilaikan usaha (effort) yang perlukan untuk analisis setiap fungsian. Dalam membuat anggaran, penilai akan menggunakan kemahiran dan pengalaman mereka, membincangkan idea mereka dengan orang lain dan mungkin mengunakan statistik dari projek sebelum ini yang mana mempunyai fungsian yang hampir sama. Dengan adanya analisis anggaran untuk fungsian individu, ianya akan dapat dijumlahkan untuk memberikan nilai untuk fungsian kawasan -- fungsian kumpulan – untuk subsistem dan untuk keseluruhan sistem.

 

Langkah seterusnya membuat sedikit penilaian terhadap 3 faktor kunci, yang mana ianya akan dilaksanakan pada projek didalam batas saiz, kesesuaian dan kerumitan.

·        Faktor saiz berkait dengan jumlah orang yang akan terlibat diwaktu puncak projek tersebut.

·        Faktor kesesuaian adalah selalunya berkait dengan jenis kerja dan jenis perniagaan dan persekitaran teknikal yang melibatkan kebiasaan kakitangan yang terlibat di dalam projek.

·        Faktor kerumitan diambil kira jenis-jenis isu teknikal yang akan digunakan di dalam projek

 

Menggunakan ketiga-tiga faktor: kadar (ratio) diantara analisis dan fungsian lain disebarang peringkat dapat ditentukan. Kadar itu nanti boleh digunakan untuk mengira anggaran usaha (effort) pada setiap peringkat dan jua pada keseluruhan projek.

 

 

5.2.6 Programming Method (Metod Aturcara)

 

Metod ini bermula dari sudut yang berbeza dengan Metod analisis usaha, iaitu melakukan pemeriksaan terhadap usaha aturcara yang diperlukan dan memperolehi nilai-nilai sepanjang tugas-tugas projek dilaksanakan. Cara paling mudah adalah dengan melakukan penilaian program untuk menentukan program yang mana akan menjadi kecil, medium atau besar. Penilai kemudian akan menggunakan metrik dari projek lain atau dari pengalamannya sendiri, untuk menentukan usaha purata bagi  peringkat projek yang diberi tumpuan.

 

 

5.2.7 Three-point Technique/Three Time Probalistic Model

 

Metod (kaedah) ini mengunakan tiga anggaran untuk masa: optimis, putus harap (pessimistic) dan anggaran

 

Sama seperti Metod Analisis Usaha, anggaran disini akan meliputi aktiviti utama projek.

 

·        Optimistic time(0) adalah masa tersingkat yang mana aktiviti boleh disiapkan, terkecuali ajaiban langsung.

·        Pessimistic time (p) adalah masa yang paling teruk yang dibenarkan untuk semua alasan yang munasabah

·        Most likely (M) adalah masa yang biasa dalam keadaan biasa

 

 

5.2.8 The Delphi Technique (Teknik Delphi)

 

Metod ini berasaskan kepada idea memperolehi anggaran daripada orang yang berkelayakan dan kemudian menyatu padukan anggaran tersebut untuk menghasilkan anggaran terakhir. Ini kerana setiap orang mempunyai tahap pengalaman yang berbeza terhadap membuat anggaran, dan terhadap perkakasan dan perisian yang akan digunakan. Terdapat beberapa peringkat pendekatan:

 

(i)                  Setiap penilai diberikan spesifik kerja yang perlu dilakukan (aktiviti, tugas dll) dan akan diminta menyediakan anggaran terhadap kerja tersebut.

(ii)                Anggaran kemudian akan diringkaskan tanpa mengetahui siapa yang membuat penilaian dan ringkasan tersebut akan diedarkan kepada setiap penilai

(iii)               Para penilai akan menilai semua anggaran yang mereka buat sendiri dan memperbaiki anggaran (penilaian) mereka sekiranya mereka merasakan ianya perlu.

 

Prosedur di atas boleh dilakukan beberapa kali mengikut kemahuan mereka demi mencapai persetujuan. Teknik Delphi merupakan pendekatan berkumpulan

 

 

5.2.9 COCOMO (Constructive Cost Model) (Model Membangun Kos)

 

Metod COCOMO dibangunkan oleh Dr. Barry Boehm. Ia lebih dikenali sebagai model ‘software costing’.

 

Basic Model komputer COCOMO membangun perisian di atas dasar usaha (dan kos) sebagai fungsian terhadap saiz program di dalam anggaran jumlah baris kod (line of code).

 

Model komputer jenis pertengahan (intermediate) COCOMO membangun perisian di atas dasar usaha (effort) sebagai fungsian terhadap saiz program dan menentukan “cost drivers”.

 

Model komputer jenis tinggi (advanced) COCOMO mengabungkan  semua kriteria yang ada di dalam mode jenis pertengahan dengan penilaian terhadap kesan  ‘cost drivers’ untuk setiap langkah (analisis, rekabentuk dll) didalam kitar hayat projek.

 

 

 

 

 

 

5.2.10 Function Point Analysis (

 

Ini merupakan metod ‘top-down’ yang dicipta oleh Allan Albrecht. Metod ini digunakan untuk mengukur saiz fungsian program secara berasingan dengan bahasa pengaturcaraan yang digunakan.

 

 

 

5.3 COCOMO (Constructive Cost Model)

 

Terdapat 3 jenis susunan di dalam model ini.

 

5.3.1 The Basic COCOMO

 

Formula tidak perlu hafal, masukkan data yang diberi kepada formula yang sesuai. Dalam soalan akan nyatakan jenis mode yang perlu digunakan seperti contoh di bawah:

 

Example: Estimate the number of persons required to do an organic mode software project with an estimated size of 35,000 deliverable lines of code.

 

 

 

 

 

 

 

5.3.2 The Intermediate COCOMO

 

Sebagai tambahan kepada saiz projek, model ini mengambil kira banyak faktor lain yang memberi kesan terhadap keperluan sumber di dalam sesuatu projek. Faktor termasuk anggaran sumber ke atas Basic Model Usaha (effort) COCOMO. Dengan cara ini, terdapat 15 kos drivers dikenalpasti dan dikumpulkan kepada empat kategori utama iaitu:

 

(a)    Atribut Produk (3 kos driver)

(b)   Atribut Komputer atau Perkakasan (4 kos driver)

(c)    Atribut Projek (3 kos driver)

(d)   Atribut Personel (5 kos driver)

 

Nilai untuk setiap kos driver akan dikategori kepada 6 iaitu

i)                    Very low

ii)                   Low

iii)                 Nominal

iv)                 High

v)                  Very High

vi)                 Extra High

 

Nilai semua kos driver akan didarabkan untuk memperolehi effort adjusment factor (EAF). Kebiasan range EAF adalah diantara 0.9 sehingga 1.4.

 

 

5.3.3 The Advanced COCOMO or COCOMO II

 

Model ini mempertimbangkan faktor yang berlainan yang mana diguna pakai semasa peringkat yang berlainan dalam pembangunan sistem dan mengeluarkan anggaran yang lebih terperinci terhadap fasa-fasa yang ada dalam basis. Model ini membenarkan anggaran dibuat keatas subsistem dan anggaran-anggaran ini seterusnya akan digabungkan untuk menjadi anggaran keseluruhan projek. Pendekatan menggunakan berbagai pendarab (multipliers) dan eksponen, yang mana nilai telah ditentukan oleh pakar.

 

 

5.3.4 Kelebihan dan Kelemahan COCOMO

 

Kelebihan – mudah, kerana memerlukan jumlah data yang kecil untuk menentukan usaha dan kos. Ia merupakan nilai statik yang mempunyai model satu nilai. Rumus adalah diperoleh daripada analisa yang dilakukan terhadap beberapa projek dan ini boleh diguna pakai untuk menjadi asas kepada keadaan sebenar.

 

Kelemahan – merupakan model anggaran empiris.  Data empiris yang menyokong model ini mengunakan sampel projek yang terhad. Ini menambahkan kemungkinan menghasilkan keputusan yang tidak tepat kerana model yang berlainan bergantung kepada konstant yang tidak tetap. Walaubagaimanapun, dengan menggunakan data yang banyak dari projek-projek sebelum ini, boleh membuatkan keputusan COCOMO menjadi lebih baik.

5.4 Function Point (FP) Analysis

 

Metod ini mempunyai tiga peringkat.

 

(a)     Analisis sistem dari keperluan maklumat pemprosesan pada peringkat logik, pertimbangan perlaksanaan adalah berkecuali dan mengkira ‘unadjusted function points’ (UFP).

(b)    ‘Processing Complexity Adjustment (PCA) mengira untuk membenarkan pemikiran seperti mudah digunakan, pemprosesan disebarkan, boleh dijaga dll.

(c)     UFP adalah difaktorkan oleh PCA untuk memperolehi mata function point yang terakhir untuk projek tersebut.

 

Basic model berdasarkan Sistem Informasi Berkomputer (computer-based information systems)  mengandungi lima komponen utama atau ‘jenis pengguna luar’ yang akan memberi manfaat kepada pengguna seperti mana yang ditunjukkan pada jadual di bawah:

 

Komponen

Penerangan

Internal Logical Files (ILF)

Merupakan fail logikal data yang menyimpan informasi untuk aplikasi yang akan menghasilkan (generates), menggunakan (uses) dan menjaga data tersebut.

External Logical Files (ELF)

Fail ini mengandungi data atau informasi kawalan datang dari, dihantar kepada, atau dikongsi oleh aplikasi lain. Fail-fail ini membenarkan data di bawa masuk atau di bawa keluar dari satu komputer ke komputer lain

External Input (EI)

Transaksi input (dari papan kekunci, talian komunikasi, tape dll) yang akan mengemaskini fail dalaman komputer. Dalam sistem interaktif, input skrin merupakan input luaran (external)  yang utama.

External Output (EO)

Transaksi dimana data adalah merupakan output kepada pengguna. Contoh: Report dan mesej

External Inquiries (EIQ)

Pertanyaan (queries) dari pengguna

 

 

Analisis yang dibuat perlu mengenai pasti setiap ‘instance’ untuk setiap jenis pengguna luararn di dalam projek sistem. Setiap komponen di atas akan dikelaskan sama ada tinggi, purata atau  rendah mengikut kerumitannya. Pengiraan setiap jenis pengguna luaran pada setiap kumpulan kerumitan akan didarab dengan pemberat khas untuk mendapatkan mata ganjaran.

 

 

Mata ganjaran FP (function point) kemudian akan dijumlahkan untuk memperolehi kiraan keseluruhan FP, yang mana menunjukkan informasi saiz pengolahan (processing).

 

Saiz pengolahan (processing) adalah ukuran permulaan di dalam ‘unadjusted function points (UFP). Kerumitan teknikal penyelarasan (technical complexity adjustment – TCA) boleh digunakan kepada UFP.

 

Setiap fungsian bisnes akan hanya dikira sekali untuk mengelakkan perkiraan yang sama.

 

Satu masalah yang ada pada FP adalah persoalan sama ada jenis pengguna luar adalah jenis kerumitan tinggi, rendah atau purata merupakan sesuatu yang objektif.

 

Metod Albrecht mempunyai banyak penghalusan yang dibuat yang kini dikenali sebagai ‘International FP user group (IFPUG).

 

 

5.4.1 Mark II Approach

 

Metod ini merupakan satu percubaan untuk melakukan pembaikan terhadap metod Albrecht. Idea Analisis FP diperbaharui oleh Charles Symons dari UK yang mencipta MK II Function Point Analysis (FPA). Di dalam versi ini terdapa tiga aspek sistem:

 

(a)    Maklumat pengolahan saiz logik (information processing logic size), diambil dari sistem input, pengolahan dan output.

(b)   Secara teknikal adalah rumit, sama ada secara kumpulan (batch) atau atas talian (online). Ia melibatkan permintaan terhadap kriteria prestasi (performance)) atau mudah digunakan.

(c)    Faktor yang mempengaruhi prestasi seperti pembangunan persekitaran general, kakitangan yang mencukupi dsbnya.

 

Untuk perkiraan kena baca sendiri. Tak perlu hafal. Semua nilai akan diberi.