Selasa, 04 Agustus 2009

TEKNIK PENGUJIAN SOFTWARE







Teknik Pengujian Software

Dasar-dasar Pengujian Software
- Tujuan Pengujian, Prinsip-Prinsip, Kemampuan Pengujian
- Desain Kasus Test Software
- Pengujian White Box
- Kompleksitas Cyclomatic
- Matriks Grafik
- Mengontrol Pengujian Struktur (tidak termasuk) - Pegujian Kondisi ( tidak termasuk) - Pengujian Aliran Data ( tidak termasuk)
- Pengujian Pengulangan ( tidak termasuk)

- Pengujian Black-Box
- Metode pengujian Graph-Based (tidak termasuk)
- Pembagian Kesamaan
- Analisis Batas Nilai
- Tes Perbandingan (tidak termasuk)



Test Pokok Software

Test Software
adalah sebuah unsur kritis dari jaminan kualitas dan menghadirkan tinjauan ulang spesifikasi, desain dan persandian.

Test Software menunjukkan bahwa fungsi software tampak seperti bekerja menurut spesifikasi dan syarat tampilan

Tujuan Pengujian:

Myers [ MYE79] negara sebuah aturan yang dapat melayani baik seperti menguji sasaran hasil:

Pengujian
adalah suatu proses pelaksanaan suatu program dengan tujuan menemukan suatu kesalahan.
Suatu kasus test yang baik adalah apabila test tersebut mempunyai kemungkinan menemukan sebuah kesalahan yang tidak terungkap.
Suatu test yang sukses adalah bila test tersebut membongkar suatu kesalahan tidak ditemukan hingga kini.

Tujuan utama dari pengujian adalah untuk mendesain test yang secara sistematik membongkar jenis kesalahan dengan usaha dan waktu minimum



Prinsip-Prinsip Pengujian Software

Davids [ DAV95] menyarankan satu set pengujian prinsip:

Semua test harus dapat dilacak ke kebutuhan pelanggan.

Test harus direncanakan dengan baik sebelum pengujian mulai.

- Prinsip Pareto berlaku untuk pengujian
- 80% dari semua kesalahan yang terungkap selama pengujian akan mudah dapat dilacak bagi20% dari semua modul program

Pengujian seharusnya mulai “ dari yang kecil” dan pengujian perkembangan ke arah “yang besar”.

Pengujian menyeluruh adalah tidak mungkin.

- Paling efektif, pengujian harus diselenggarakan oleh suatu pihak ketiga mandiri.



Software Testability

Kemampuan Test Software Menurut Yakobus Bach:

Pengujian kemampuan Software adalah contoh bagaimana dengan mudahnya suatu program komputer dapat diuji.

Satu perangkat karakteristik program mendorong kearah kemampuan pengujian software:
Kemampuan Mengoperasi “ makin baik berjalan, maka semakin efisien dapat diuji.”
Kemampuan Observasi : “ Apa yang kamu lihat adalah apa yang kamu uji.”
Kemampuan mengendalikan : “ Makin baik kita dapat mengendalikan software, semakin pengujian dapat diotomatiskan dan dioptimalkan.”
Kemampuan memisahkan: Dengan mengendalian lingkup pengujian, kita dapat dengan cepat mengisolasikan permasalahan dan melaksanakan pengujian kembali yang lebih baik.”
Kesederhanaan: “ Semakin sedikit yang diuji, semakin dengan cepat kita dapat menguji itu.”
Stabilitas: “ Lebih sedikit perubahan, lebih sedikit gangguan untuk menguji.”
Kemampuan memahami :”Semakin banyak informasi yang kita punya , semakin lebih baik kita dalam menguji.”




Kasus Tes Mendisain

Dua software umum menguji pendekatan:
Pengujian Black Box dan White Box
Pengujian Black-Box:
Mengetahui fungsi yang spesifik dari suatu software, test disain untuk mempertunjukkan masing-masing fungsi dan mengecek kesalahannya.
Fokus utama:
fungsi, operasi, alat penghubung eksternal, informasi dan data eksternal
Pengujian White-Box :
Mengetahui internal dari suatu software, tes disain untuk melatih semua internal-internal dari suatu software untuk meyakinkan mereka dapat beroperasi menurut spesifikasi dan disain
Fokus utama: struktur internal, alur logika, arus kendali, aliran data, struktur data internal, kondisi-kondisi, pengulangan dan lain lain



Pengujian White Box dan Pengujian Alur Basis

Pengujian White-Box, juga dikenal sebagai pengujian glass-box.
Ini merupakan suatu kasus test mendisain metoda yang digunakan struktur kendali dari disain prosedur mengenai cara untuk memperoleh test kasus.

Menggunakan metode pengujian white-box, kita memperoleh kasus
test yang Menjamin bahwa semua alur mandiri di dalam suatu
modul telah dicoba paling sedikit sekali.
Melatih semua keputusan logis satu sisi benar dan salah
Melaksanakan semua pengulangan pada batasan-batasan mereka dan di dalam batas operasional mereka.
Melatih struktur data internal untuk meyakinkan kebenarannya.
Pengujian Alur basis dasar ( suatu teknik pengujian white-box):
Diusulkan pertama oleh Tommccabe [ MCC76].
Dapat digunakan untuk memperoleh suatu ukuran kompleksitas logis untuk suatu disain prosedur.
Digunakan sebagai suatu panduan untuk penjelasan suatu basis perangkat alur pelaksanaan.
Jaminan untuk melaksanakan tiap-tiap statemen di dalam program sedikitnya sekali.










Kompleksitas Cyclomatic

Kompleksitas Cyclomatic adalah suatu perangkat lunak metrik-> menyediakan suatu ukuran yang kwantitatif menyangkut kompleksitas yang global dari suatu program.

Manakala metrik ini digunakan dalam konteks pengujian alur basis, nilai menghitung untuk kompleksitas cyclomatic menggambarkan banyaknya alur mandiri di dalam basis satuan suatu program.

Tiga jalan untuk menghitung kompleksitas cyclomatic:
- Banyaknya daerah dari grafik arus sesuai dengan kompleksitas yang cyclomatic itu.
- Kompleksitas Cyclomatic, V(G), untuk suatu grafik arus G digambarkan sebagai V(G)= E- N + 2 di mana E adalah banyaknya arus tepi grafik dan N adalah banyaknya puncak arus.
- Kompleksitas Cyclomatic, V(G)= P+ 1 di mana P adalah banyaknya tangkai predikat terdapat di grafik arus G.



Menurunkan Kasus Test

Langkah 1: Menggunakan kode atau disain sebagai pondasi, menggambarsuatu bersesuaian grafik arus.
Langkah 2: Menentukan kompleksitas cyclomatic dari resultan aliran grafik.
Langkah 3: Menentukan suatu basis satuan secara linier alur mandiri.

Sebagai contoh,
alur 1: 1-2-10-11-13
alur 2: 1-2-10-12-13
alur 3: 1-2-3-10-11-13 a
alur 4: 1-2-3-4-5-8-9-2-…
alur 5: 1-2-3-4-5-6-8-9-2-..
alur 6: 1-2-3-4-5-6-7-8-9-2-..

Langkah 4: Menyiapkan kasus test yang akan memaksa pelaksanaan dari tiap alur di dalam perangkat basis
Alur 1: menguji kasus:
nilai ( k)= input yang valid, di mana k< I digambarkan di bawah.
nilai ( i)= - 999, di mana 2 <= I<= 100
hasil diharapkan: mengoreksi rata-rata didasarkan pada nilai k menilai dan jumlah yang tepat









Kesamaan Penyekatan

Kesamaan Penyekatan adalah suatu metode pengujian black-box
- membagi daerah masukan dari suatu program ke dalam kelas data
- memperoleh kasus test berdasar pada sekat ini.

Test Kasus mendisain untuk penyekatan kesamaan didasarkan pada suatu evaluasi kelas kesamaan untuk suatu daerah masukan.
Suatu kelas kesamaan menghadirkan satu sperangkat yang valid atau yang tidak valid untuk kondisi input..

Suatu kondisi masukan adalah:
- suatu nilai klasifikasi spesifik, bidang nilai-nilai- satu set nilai
- nilai terkait, atau suatu kondisi Boolean



Kelas Kesamaan

Kelas Kesamaan dapat digambarkan penggunaannya dengan petunjuk berikut :
Jika suatu kondisi masukan menetapkan suatu cakupan, yang sah dan dua kelas kesamaan cacat digambarkan.
Jika suatu kondisi input memerlukan suatu nilai spesifik, yang sah dan dua kelas kesamaan cacat digambarkan.
Jika suatu kondisi input menetapkan suatu anggota dari suatu set, satu yang sah dan satu kelas kesamaan cacat digambarkan.
Jika suatu kondisi masukan adalah Boolean, satu sah dan satu kelas cacat digambarkan.
Contoh:
kode area: kondisi input, Boolean- kode area boleh atau tidak mungkin disajikan.
kondisi input, cakupan- nilai digambarkan antara 200 dan 900
kata sandi: kondisi input, Boolean- suatu kata sandi tidak atau tidak mungkin disajikan.
Kondisi input, nilai- enam rangkaian karakter.
perintah: kondisi input, perangkat- yang berisi perintah yang dicatat sebelumnya












Analisis Nilai Batas

Analisis nilai Batas Batas menghargai analysis(BVA)
- suatu kasus test mendisain teknik
- melengkapi ke sasaran sekat kesamaan:

Analisis nilai batas memimpin ke arah suatu pemilihan kasus test yang dicoba membatasi nilai-nilai.

Petunjuk:
- Jika suatu kondisi input menetapkan suatu cakupan yang dibatasi oleh nilai a dan b, kasus pengujian harus dirancang dengan nilai a dan b, sedikit di atas dan di bawah a dan b.
Contoh: Bilangan bulat D dengan kondisi input [- 3, 10],
nilai test : - 3, 10, 11, - 2, 0

- Jika suatu kondisi input menetapkan suatu nilai-nilai nomor;jumlah, kasus test harus dikembangkan untuk berlatih angka-angka maksimum dan yang minimum. Nilai yang sedikit di atas dan di bawah maksimum dan minimum juga diuji.
Contoh:
Menyebut satu persatu data E dengan kondisi input: { 3, 5, 100, 102}
nilai test : 3, 102, - 1, 200, 5


Analisis Nilai Batas

Petunjuk 1 dan 2 diberlakukan bagi kondisi output.
- Jika struktur data program internal sudah menentukan batasan-batasan, yakinkan untuk mendisain suatu kasus test untuk mencoba struktur data pada batas nya

Seperti struktur data:

- susunan kondisi input:

unsur kosong, tunggal, unsur penuh, diluar batas

mencari-cari unsur:

- unsur ada di dalam susunan atau unsur adalah tidak di dalam susunan

Kamu dapat memikirkan struktur data lain:

- daftar, menetapkan, tumpukan, antri, dan pohon

STRATEGI PENGUJIAN SOFTWARE



Pengujian dan Strategi Software

Verifikasi dan Validasi
- Organisasi Pengujian Software
- Pengujian Software dan Process Pengujian
- Strategi Pengujian
- Rencana Uji dan Dokumentasi
- Pengujian Spesial untuk Sistem Aplikasi

Pengujian Software adalah satu elemen dari sebuah topik broader yang sering diartikan sebagai
è Verifikasi dan Validasi (V&V)

Verifikasi : menunjuk ke kumpulan aktifitas yang memastikan bahwa software mengimplementasi sebuah fungsi spesifik.

Validasi : menunjuk ke sebuah kumpulan berbeda dari aktivitas yang memastikan bahwa software yang telah dibangun dapat di-trace terhadap kebutuhan customer.

Boehm [BOE81]:
Verifikasi: “Apakah kita membangun produk dengan baik?”
Validasi: “Apakah kita membangun produk yang baik?”

Defenisi V&V meliputi banyak aktifitas SQA, termasuk
review teknis formal, kualitas dan audit konfigurasi
monitor performance, tipe yang berbeda dari pengujian software study feasibility dan simulasi


Organisasi Pengujian Software

Obyectif pengujian: tidak menutup error(defects) pada software, termasuk error pada:
- kebutuhan dari analisa kebutuhan
- desain terdokumentasi dalam spesifikasi desain
- coding (implementasi)
- sumber sistem dan lingkungan sistem
- masalah-masalah hardware dan interface-nya terhadap software

Pengujian Software dapat dipertimbangkan secara psikologi dihancurkan(destructive).

Siapa yang terlibat dalam pengujian software?
- developer
- tester (test engineer) in ITG
- SQA group

Organization pengujian software:
- Individual tester dalam sebuah tim pengembang
- Independent test group (ITG)



Test Unit (Test Level Komponen)

Pengujian unit: Komponen individual components diuji secara independen untuk memastikan kualitasnya. Fokusnya untuk tidak menutup error pada desain dan implementasi, meliputi:
struktur data pada sebuah komponen
logika program dan struktur program pada sebuah komponen
interface komponen
fungsi dan operasi dari sebuah component
Penguji/tester unit: pengembang dari komponen.



Test Integrasi

Test Integrasi: Sebuah group dari component dependent diuji bersama untuk memastikan kualitas dari unit integrasinya.

Fokusnya untuk meng-uncover error pada:
Desain dan konstruksi arsitektur software
Fungsi-fungsi yang terintegrasi atau operasi pada level sub-system
Interface dan interaksi diantaranya
Integrasi resource dan/atau integrasi lingkungan
Penguji integration: pengembang dan/atau test engineer.



Strategi Pengujian Integrasi

Pendekatan: a) integrasi non-incremental
b) integrasi incremental

Integrasi non-incremental :

- Big Band - menggabungkan (atau mengintegrasi) semua bagian dalam sekali.
Keuntungan: - sederhana
Kerugian: - sulit untuk men-debug, tidak mudah untuk mengisolasi error
- tidak mudah untuk memvalidasi hasil test - mustahil untuk membentuk sebuah sistem terintegrasi impossible
Integrasi incremental:
mengintegrasi sistem tahap demi tahap(atau bagian demi bagian) dalam sebuah pesanan yang didesain dengan baik.
Tiga metode penting:
a) Top-down
b) bottom-up
c) Sandwich
- menggunakan top-down untuk modul upper-level dan bottom-up untuk modul low-level



Integrasi Top-down

Ide:- Modul-modul diintegrasi dengan memindahkan downward melalui struktur kontrol.

Modul subordinate ke modul kontrol utama digabung ke sistem dalam cara depth-first atau breadth-first.

Proses integrasi(lima langkah):
1. modul kontrol utama digunakan sebagai sebuah test driver, dan stubs disubstitusi untuk semua modul secara langsung ke modul kontrol utama.
2. stub subordinate digantikan sekali satu waktu dengan modul actual.
3. test terkonduksi sebagai tiap modul diintegrasi.
4. pada pelengkapan tiap kumpulan test, stub lainnya diganti dengan modul real.
5. pengujian regresi dapat dikonduksi.

Integration top-down pros dan cons :
- biaya kostruksi stub
- fungsi kontrol utama dapat diuji lebih cepat.



Integrasi Bottom-Up

Ide:- Modul pada level terbawah diintegrasi pertama, kemudian dengan menggerakkan keatas melalui struktur kontrol.

Proses integration(lima langkah):
1. Modul low-level dikombinasikan ke cluster yang menunjukkan sebuah sub-function software spesifik.
2. sebuah driver ditulis untuk meng-coordinate input dan output test case.
3. Test cluster diuji.
4. Driver dipindah dan cluster digabungkan bergerak ke atas dalam struktur program.

Integrasi bottom-up pros dan cons:
- tidak ada biaya stub
- perlu pengujian driver
- tidak ada sistem yang dapat dikontrol hingga langkah terakhir



Uji Validasi

Uji Validasi : Software yang berintegrasi diuji berdasarkan pada kebutuhan untuk memastikan bahwa kita memiliki produk yang benar.

Fokus-nya adalah untuk meng-uncover error pada:
- Input/output sistem
- Informasi fungsi sistem dan data
- Interface sistem dengan bagian eksternal
- User interface
- Perilaku dan performance sistem

Penguji validasi : uji engineer pada orang-orang ITG atau SQA.



Uji Sistem

Uji sistem: Sistem software diuji keseluruhan. Ini memverifikasi semua elemen secara langsung untuk memastikan bahwa semua fungsi dan performance sistem diterima dalam lingkungan target.

Area fokus adalah:
- Fungsi dan performance sistem
- Reliability(ketersediaan) dan recoverability (kemampuan menutup/recovery test) sistem
- Instalasi (uji instalasi) sistem
- Perilaku pada kondisi tertentu (uji tekanan dan load) sistem
- Operasi user (acceptance test/alpha test/) sistem
- Integrasi dan kolaborasi hardware dan software
- Integrasi software eksternal dan sistem

Penguji sistem : uji engineer pada orang-orang ITG atau SQA.

Saat sebuah sistem akan dikeluarkan sebagai sebuah produk software, suatu proses pengujian yang disebut pengujian beta sering digunakan.



Pengujian Sistem

Pengujian recovery - suatu sistem uji yang memaksa software gagal dalam cara berbeda dan memverifikasi bahwa recovery ditampilkan.

Pengujian security – untuk memverifikasi bahwa mekanisme perlindungan dibangum ke sebuah sistem akan melindunginya dari improper penetration.

Pengujian stress – didesain untuk mengkonfrontasi program dengan kondisi yang tidak normal.
- kuantitas, frekuensi, atau volume.

Pengujian performance – didesain untuk menguji performance run-time software dalam konteks sebuah sistem terintegrasi.

Pengujian instalasi – didesain untuk menguji prosedur instalasi dan software pendukungnya.



Rencana Uji

Rencana uji berhubungan dengan mengeset standar untuk pengujian proses dibanding penggambaran pengujian produk.

Test plan/rencana uji terdiri atas:
- standar untuk proses pengujian
- resource yang diperlukan (hardware, software dan engineer)
- jadwal pengujian (pengujian task dan milestones)
- uji item (apa yang harus diuji)
- prosedur recording test
(hasil test harus secara sistematis direkam)
- constraint

Test planning adalah sebuah dari suatu test manager.
Sebuah test plan adalah output dari perencanaan.



Test Issues in Real World

Pengujian software sangat mahal.

Bagaimana mendapat pengujian secara otomatis??????

Kriteria pengujian, lingkup pengujian, pengujian adequate.

Pengujian software lainnya:

Pengujian GUI

Pengujian Software Berorientasi Object

Pengujian Komponen dan Pengujian Berbasis Komponen Software

Pengujian Fitur spesifik Domain

Pengujian Sistem Berbasis Web

DESAIN INTERFACE

Desain Interface
Internal and external interfaces
User interfaces
Desain User interface
aturan desain User interface
interaksi User-system
model-model Interface
sistem Menu
Command-line interface
Gambaran Information
Information display
input data
Petunjuk User guidance
error messages, help system design, dokumentasi user
Evaluasi Interface
Desain interface berfokus pada tiga area:
a) desain interfaces antar modul software
b) desain interfaces antara software dan prosedur non manual yang lain dan informasi customer
c) desain interface antara manusia dan komputer

Desain internal and external interface:
- desain interface program internal, --->
dinamakan desain intermodular interface
-----> interfaces antara proses fungsional internal dalam DFD.
memetakan transaksi dengan proses.

Desain external interface ---->
- memeriksa external entities dalam DFD.
- mendesain interface antara external entities dan proses internal.
->mengerjakan sesuatu pada data externaldan kontrol eksternal

User Interface Design Principles

Kebiasaan user:
Interface harus menggunakan aturan dan konsep yang diperoleh dari pengalaman user terdahulu.

Ketentuan:
Interface harus konsisten pada operasi yang sama yang harus diaktifkan pada
suatu saat.

Minimal surprise:
User seharusnya tidak pernah terkejut dengan behavior system



Recoverability:
interface harus memasukkan mekanisme untuk mengijinkan user menemukan error.
- konfirmasi tindakan yang merusak
- fasilitas untuk undo

Pedoman user:
interface harus menggabungkan beberapa bentuk context-sensitive pedoman
user dan asisten


Interface Design Guidelines

Interaksi umum:

konsisten/tetap

Menyediakan feedback yang berarti

Menanyakan verifikasi tindakan yang dapat merusak sistem

Mengijinkan beberapa tindakan untuk dapat kembali dengan mudah

Mengurangi beberapa informasi yang harus diingat antara tindakan

Memberikan efisiensi pada dialog, gerakan, dan pikiran

Mentoleransi kesalahan

Menggolongkan tindakan sesuai fungsi dan mengorganisasikan sesuai dengan screen geography

Menyediakan fasilitas bantuan yang sensitif

Memekai kata-kata yang sederhana atau pendek untuk menamakan perintah

User System Interactions

Model Interaksi:

A) manipulasi langsung:
--> iterface manipulasi langsung memberikan user model informasi spacenya. Mereka berinteraksi dengan informasi ini melalui tindakan langsung, misalnya penggantian informasi, pemindahan informasi dan sebagainya.
contohnya: editor layar atau work processors

B) sistem menu:
pada interface menu, user memilih satu atau beberapa kemungkinan untuk memberi perintah kepada mesin. Mereka bisa memakai mouse, seperti menunjuk, memindahkan, memilih….

C) Interface Command-line:
interface perintah membutuhkan user mengetikan teks perintah pada sistem. Perintahnya bisa jadi query, permintaan untuk servis tertentu atau mungkin lanjutan dari perintah yang lain.

Manipulasi langsung:

Keuntungan :
- User merasa komputer berada dalam kontrol dan tidak ketakutan karenenya.
- Waktu pembelajaran user relatif pendek.
- User mendapatkan feedback dengan segera untuk tindakannya. Kesalahan dapat dideteksi dan dikoreksi dengan cepat.

Masalah:
- Bagaimana model dan ilustrasi informasi yang tepat dapat diperoleh?
Memberikan user space informasi yang besar, bagaimana mereka dapat menjalankan sepanjang space-nya dan selalu mengetahui posisisnya sekarang?
- Interface-nya biasanya kompleks.

Satu pengembangan simpel:
form pada interface berikut:

Sistem menu:
(a) Menu pull-down: (terprediksi, tapi butuh lebih banyak screen space)
Menampilkan judul menu.
User dapat memilih perintah yang ada pada menu ini.
(b) Menu pop-up: (fleksibel, dapat disesuaikan, mungkin membuat user terkejut)
Berhubungan dengan entity(misalnya sebuah field).
Memilih entity ketikan tombol mouse di klik.
--> Menyebabkan menu ditampilkan.
Keuntungan:
- User tidak perlu tau nama perintahnya.
- Meminimalkan pengetikan.
- Beberapa error karena user bisa dihindari.
- Bantuan keadaan saling ketergantungan dapat disediakan.
Masalah:
- Perawatan stuktur menu yang besar.
Solusi: a) scrolling menus, b) hierarchical menus
c) walking menus, d) associated control panels

Interface Command-line:

Keuntungan:
- Implementasinya mudah dan simpel sesuai dengan bahasa pemrosesan.
- Dapat mendukung sistem yang sangat kompleks dengan banyak perintah.
- User interface memerlukan sedikit effort.
- Meminimalkan pengetikan.
- Beberapa error karena user bisa dihindari.
- Bantuan keadaan saling ketergantungan dapat disediakan.

Problems:
- User harus mempelajari dan mengingat semua perintah
- Berat untuk mempelajari sistem dan tidak mudah untuk mengoperasikannya.
- User pasti membuat error.

Perhatian: interface command-line and interface menu-based tidak saling terpisah.

Model Interface à
GUI interfaces dengan well-predefined format dan gaya GUI.
(X windows and Motif, Micro software Windows, ….)

Termasuk elemen-elemen:
- buttons, switches, menus, indicators, displays, sliders.
- windows, panels, dialog boxes,…
- icons, tool bars, ….

Keuntungan:
- GUI sangat interaktif sesuai dengan GUI styles/ formats.
- sangat mudah untuk dipelajari dan dioperasikan.

Masalah:
- GUI styles and formats harus distandarisasi.
- desain GUI rumit.
- implementasinya kompleks dan luas.

Biasanya merupakan kombinasi dari:
menu-systems, command-line interfaces,
direct manipulation,


Information Representation

Ada beberapa cara untuk merepresentasikan informasi dalam user interface:
- Text, data, tabel
- gambar 2-D (or 3-D), diagram
- Multi-media (gambar, animasi, suara, video, …)
Representasinya dapat digunakan faktor berikut:
- warna, ukuran, gerakan, resolusi, …
- layar (or window) layout, operational sequence
- GUI hierarchical structure
Tipe representasi informasi:
- Input data (data yang diketikan, data terpilih, default data)
- Output data, tabel, report, diagram, or gambar
- pesan kesalahan (Error messages) dan pesan peringatan(waning messages)
GUI elements:
- windows (screens), panels
- menus (pull-down, pop-up, nested-menu)
- buttons, tool bars, icons
- check list, selection list, choice box, radio box
- text field, text area, label,

Information Representation - Display

Display Guidelines:

- Tampilkan informasi yang relevan pada konteks saat ini.

- Jangan menyembunyikan datadari user, gunakan format presentasi.

- Gunakan label yang konsisten, singkatan yang standar, dan warna yang terlihat

- Ijinkan user untuk mengembangkan konteks visual.

- Hasilkan pesar error yang berarti.

- Gunakan upper dan lower case, indention, dan text grouping untuk membantu pemehaaman user.

- Gunakan windows untuk menggolongkan informasi dengan tipe yang berbeda.

- Gunakan tampilan analog untuk merepresentasikan informasi yang lebih mudah dipahami dengan form representasi ini.

- Perimbangkan ketersediaan tempat pada layar dan gunakan dengan efektif.

METODE DESAIN



Metode-metode Desain Software

Desain --> sebagai sebuah proses dengan beberapa tahap dimana kita mendesain:
a) struktur data b) struktur program
c) karakteristik interface d) detail prosedur
berdasarkan pada informasi kebutuhan.

Perubahan bentuk memproses dari model analisa kebutuhan
à menghasilkan spesifikasi desain

Desain data:
- Focus utama adalah struktur data dan representasi logikanya
untuk tiap komponen pada sebuah sistem software.

Artinya: informasi yang disembunyikan dan abstrak data

Desain arsitektur dan desain struktural
- Sasaran pokok adalah mengembangkan suatu struktur program modular dan merepresentasikan hubungan kendali antar modul-modul.
- Menyediakan suatu gambaran arsitektur tentang sistem software.

Desain interface :

- Fokus utama adalah:
- desain interface antara modul-modul software
- desain interface antara software dan komponen-komponen eksternal, seperti hardware.
- desain user interface

Desain prosedur atau desain yang terperinci:

- Sasaran utama adalah untuk menyediakan algoritma dan desain detil yang berorientasi prosedur untuk tiap tugas atau fungsi suatu modul.
- Gunakan satu bahasa spesifikasi yang jelas untuk menulis prosedur.



Desain Data

Panduan desain data :

Terapkan analisa yang sistematis terhadap data
- obyek data, relasi, dan aliran data sebagai isi.

- Identifikasi semua struktur data dan operasi yang berhubungan

- Menetapkan suatu kamus data
- obyek data dan relasinya sebagai batasan

- Menunda keputusan desain yang low-level sampai di dalam proses desain

- Gunakan informasi yang tersembunyi dalam desain struktur data

- Suatu perpustakaan dari operasi dan struktur data yang bermanfaat
- data obyek yang dapat digunakan kembali
- template struktur data yang dapat digunakan kembali

- Gunakan sebuah desain software dan bahasa pemrograman untuk mendukung spesifikasi data dan abstraksi.


Desain File Data

Panduan untuk File Data:

- Desain untuk file data:

a) Tipe dan struktur file :
- file text ASCII, file sequential, file direct access, file index
- ukuran buffer dan ukuran record

b) Struktur file record:
- field data, tipe data, dan format

c) Aplikasi file data:
- konfigurasi, data aktif, data input/output, log operasi

d) Operasi file data:
- open(buka), close(tutup), creation(membuat), deletion(menghapus), read and update (membaca dan memperbaharui)

e) Operasi untuk record data:
- append(menambah), insert(menyisipkan), delete(menghapus), update(memperbaharui), read(membaca)


Desain Database

Evaluasi ERD untuk database.
- obyek data
- relasi
- atribut data pada tiap obyek

- Perbaikan ERD pada relasi, atribut data.

- Memilih tipe target database:
- database jaringan
- database relasi
- database berorientasi obyek

- Gambarkan skema database:
- Gambarkan tabel atau obyek database
- Tentukan key data(primary key d an foreign key)
- Tentukan tipe data
- Tentukan nilai default

- Normalisasi skema database
- Menulis defenisi database dalam sebuah bahasa pre-defined (dengan sebuah vendor database)


Langkah-langkah Desain Software

Langkah 1: Tinjau ulang model sistem pokok

Langkah 2: Tinjau ulang dan refine diagram aliran data untuk software

Langkah 3: Tentukan apakah DFD memiliki mempunyai karakteristik flow transformasi atau transaksi.

Langkah 4: Isolasikan pusat transformasi dengan penetapan batasan flow yang datang dan keluar.

Langkah 5: Lakukan “first-level factoring”

Langkah 6: Lakukan “second-level factoring”
Langkah 7: Refine iterasi pertama struktur program menggunakan desain heuristic untuk meningkatkan kualitas software.


Langkah-langkah Pemetaan Transaksi

Langkah-langkah desain untuk pemetaan transaksi adalah sama dan dalam beberapa kasus identik dengan langkah-langkah untuk pemetaan transformasi. Perbedaan utama pada pemetaan dari DFD ke struktur software.

Langkah 1: Tinjau ulang model sistem pokok
Langkah 2: Tinjau ulang dan refine diagram aliran data untuk software
Langkah 3: Tentukan apakah DFD memiliki mempunyai karakteristik flow
transformasi atau transaksi.
Langkah 4: Isolasikan pusat transaksi dan karakteristik aliran sepanjang
tiap action path.
Langkah 5: Petakan DFD dalam sebuah struktur program yang amenable
terhadap proses transaksi.
Langkah 6: Faktor-kan dan refine struktur transaksi dan struktur tiap
action path.
Langkah 7: Refine iterasi pertama struktur program menggunakan design
heuristic untuk meningkatkan kualitas software.


Desain Prosedur

Desain prodedur terjadi setelah desain data, arsitektur, dan interface dibangun. Ini menggambarkan detail algoritmic.

Kita dapat menspesifikasi desain detail dalam sejumlah cara:
A) Pemrograman struktur
-> menggunakan konstruksi, seperti sequence(urutan),
condition(kondisi), dan repetition(pengulangan) untuk
menspesifikasi algoritma.

B) Notasi desain grafis
-> flowchart (Gambar 14.17, dan 14.18),
-> box diagram (Gambar 14.19)

C) Notasi desain tabular (tabel keputusan pada Gambar 14.20, 14.21)
Tabel keputusan menyediakan sebuah notasi yang menerjemahkan
action dan kondisi (digambarkan pada narasi proses) ke bentuk
tabular

D) program design language (PDL) atau bahasa desain program –
dikenal sebagai structured English atau pseudocode (Gambar 14.22)

KONSEP DAN PRINSIP DESAIN

Desain software dan software engineering
Process desain
Prinsip desain
Konsep desain
- Abstraksi, perbaikan, modularity
Arsitektur software
- Hirarki control
- Partisi struktural
- Struktur data
- Procedur software
- Information yang tersembunyi
Desain modular yang efektif
- Ketergantungan fungsional, kohesi, penggabungan
Desain heuristic untuk modularity efektif
Model desain
Dokumentasi desain

Desain Software dan Software Engineering

Desain ->Langkah pertama dalam fase pengembangan untuk prodengineer manapun. Bertindak sebagai pondasi untuk semua software engineering dan pemeliharaan software dengan langkah-langkah yang mengikutinya.

Tujuan seorang perancang adalah menghasilkan suatu model(atau penyajian) dari sebuah entitas yang akan dibangun

Input desain software : Model analisa kebutuhan dan dokumentasi spesifikasi
Output desain software : Model desain dan dokumentasi spesifikasi desain

Desain - menerjemahkan kebutuhan ke model desain lengkap untuk sebuah produk software.
- menyediakan representasi software yang dapat diduga untuk kualitas.

Desain Software

Sejumlah metode desain dapat digunakan untuk menghasilkan desain software:
- Desain data: mentransformasi model domain informasi ke struktur data
- Desain arsitektur: menggambarkan relasi antar elemen struktural utama program
- Desain interface : mendeskripsikan bagaimana software berkomunikasi with user
- Desain prosedur: mentransformasikan elemen structural arsitektur program ke sebuah deskripsi prosedur dari komponen software.

Evolusi desain software:
- Konstruksi program modular[DEN73] dan metode perbaikan top-down[WIR71].
- Pemrograman terstruktur [DAH71, MIL72].
- Perpindahan data flow/data structure ke sebuah defenisi desain[JAC75][WAR74].
- Pendekatan berorientasi object[JAC92][GAM95].

Fitur umum metode desain software:
- Sebuah mekanisme untuk perpindahan sebuah model analisa ke representasi desain
Sebuah notasi untuk merepresentasi komponen fungsional dan interface-nya.
Heuristic untuk perbaikan dan partisi
Panduan untuk assessment kualitas

Proses Desain

Desain software --> sebuah proses iteratif dimana kebutuhan diterjemahkan ke sebauh “blueprint” untuk mengkonstruksi software.

Desain direpresentasikan pada level atas abstraction. Saat iterasi desain terjadi, perbaikan subsequent membawa ke representasi desain pada level abstraksi yang lebih bawah.

Kualitas desain sangat penting. Dua metode digunakan untuk mengecek kualitas:
a) Tinjauan ulang teknis formal, dan b) desain walkthrough

Tiga fitur umum sebuah desain yang baik dari McGlaughlin’s [McG91]:
- Desain harus mengimplementasikan semua kebutuhan(eksplisit/implisit)
- Desain harus dapat dibaca dan dimengerti
- Desain harus menyediakan suatu gambar lengkap software pada aspek aspek data, fungsi dan perilaku.


Kualitas Desain

Untuk mengevaluasi sebuah desain software, sebauh criteris kualitas desain dapat digunakan.

Berikut panduan untuk sebuah desain yang baik:
- Sebuah desain harus A design should exhibit a hierarchical organization about software
- Sebuah desain harus modular berdasarkan pada partisi logical.
Sebuah desain terdiri dari data dan abstraksi prosedural.
Sebuah desain harus membawa ke modul dengan fitur fungsional yang independen.
Sebuah desain harus membawa interface yang sederhana antar modul.
Sebuah desain harus diturunkan menggunakan metode yang dapat berulang.

Proses desain software memacu desain yang baik dalam aplikasi dengan prinsip desain fundamental, metodologi yang sistematik, dan melalui review(pengulangan).


Prinsip Desain

David [DAV95] memaparkan sekumpulan prinsip untuk desain software:

- Proses desain seharusnya tidak bertahan dari “tunnel vision”.
- Desain harus dapat di trace ke model analisa.
- Desain seharusnya tidak menemukan/invent wheel.
- Desain harus “memperkecil jarak intellectual” antara software dan masalah-masalah pada dunia nyata.
- Desain harus mengeluarkan uniformity dan integrasi.
- Desain harus terstruktur untuk mengakomodasi perubahan.
- Desain harus terstruktur untuk mendegradasi secara halus(degrade gently).
- Desain bukan coding.
- Desain harus di-assessed untuk kualitas.
Desain harus diulang untuk meminimalis kesalahan konsep.

Faktor kualitas eksternal: diobservasi oleh user.
Faktor kualitas internal: penting untuk engineer.

Konsep Desain

Abstraksi:

Tiap langkah pada proses software engineering adalah sebuah perbaikan pada tingkatan abstraksi dari solusi software.

- Abstraksi data: Sekumpulan data
- Abstraksi prosedural:
Satu urutan instruksi pada sebuah fungsi spesifik
- Abstraksi kontrol:
Sebuah program mengkontrol mekanisme tanpa menspesifikasikan detail internal.

Refinement(perbaikan): Perbaikan sebenarnya adalah sebuah proses dari elaborasi.

Stepwise dari perbaikan adalah sebuah strategi desain top-down yang dikeluarkan oleh Niklaus [WIR71].
Arsitektur sebuah program dikembangkan dengan sukses memperbaiki
level detail procedural.

Proses perbaikan program analog terhadap proses perbaikan dan partisi yang digunakan selama analisa kebutuhan. Perbedaan utama berada pada level detail implementasi, disamping pendekatannya.

Abstraksi dan perbaikan secara komplemen dikonsep.
Abstraksi memungkinkan seorang desainer untuk menspesifikasi prosedur dan data w/o detail.
Perbaikan membantu desainer untuk me-reveal detail low-level.

Konsep Desain - Modularity

Konsep modularity telah dipakai selama hampir empat dekade.
Software dibagi komponen dengan nama dan alamat yang berbeda, disebut modul.
Meyer [MEY88] mendefenisikan lima kriteria yang memungkinkan kita mengevaluasi sebuah metode desain dengan bergantung kepada kemampuannya mendefenisikanfive sebuah sistem modular efektif:
Modular decomposability: sebuah metode desain menyediakan sebuah mekanisme sistematik untuk men- decompose atau membagi masalah ke sub-masalahà mengurangi kompleksitas dan mendapatkan modularity

Modular composability: sebuah metode desain memungkinkan komponen desain yang telah ada dirakit ke sebuah sistem baru.

Modular understandability: sebuah modul dapat dimengerti sebagai sebuah unit yang berdiri sendiri dan akan lebih mudah membangun dan mengubahnya.

Modular continuity: perubahan kecil terhadap kebutuhan sistem menghasilkan perubahan pada tiap modul, dibanding perubahan system-wide.

Modular protection: sebuah kondisi aberrant terjadi dalam sebuah modul dan efeknya di-constrain
dalam modul.

Arsitektur Software

Arsitektur software adalah struktue hirarki dari komponen program components dan interaksinya.

Shaw dan Garlan [SHA95a] menggambarkan sekumpulan properti desain arsitektur:

Properti structural : Desain arsitektur mendefenisikan komponen sistem dan interaksinya.

Properti extra-functional : Desain arsitektur harus meng-address bagaimana arsitektur desain menerima kebutuhan untuk performance, kapasitas, ketersediaan(reliability), adaptability, keamanan.

Kumpulan sistem yang berhubungan:
desain arsitektur harus menggambar pola yang dapat diulang pada desain dengan sistem yang sama.






Metode desain arsitektural yang berbeda:

Model structural: merepresentasikan arsitektur sebagai sebuah koleksi terorganisir dari komponen

Model framework: meningkatkan level desain abstraksi dengan mengidentifikasi secara berulang
framework desain arsitektur(pola-pola)

Model dinamis: meng-address aspek-aspek perilaku arsitektur program

Model prosess: fokus pada desain bisnis atau proses teknis

Model functional: dapat digunakan untuk merepresentasikan hierarki fungsional sebuah sistem

Partisi Structural

Struktur program harus dipartisi secara horizontal dan vertikal. (Gambar 13.4)

(1)Partisi horizontal menggambarkan cabang-cabang yang terbagi dari hierarki modular untuk tiap fungsi program utama.

Cara termudah adalah mempartisi sebuah sistem menjadi:
input, transformasi data(pemrosesan), dan output

Keuntungan dari partisi horizontal:
- mudah untuk diuji, di-maintain, dan extend
- efek yang lebih kecil pada perubahan propagasi atau error propagasi

Kerugian: lebih banyak data dilewatkan melalui interface modul
--> menyulitkan kontrol keseluruhan dari aliran program

(2) Partisi vertical memaparkan kontrol dan work harus terdistribusi top-down dalam struktur program.

Keuntungan: baik pada kesesuain untuk perubahan:
- mudah untuk me-maintain perubahan
- mengurangi pengaruh perubahan dan propagasi.

Desain Modular Efektif

Informasi yang disimpan: Modul-modul seharusnya dispesifikasi dan didesain sehingga detail internal dari modul darus dapat terlihat atau dapat diakses terhadap modul lainnya.

Keuntungan utama: mengurangi pengaruh perubahan pada testing(pengujian) dan maintenance(perawatan).

Independen fungsional: Mendesain modul-modul berdasarkan fitur fungsional independen.

Keuntungan utama: modularity efektif

Cohesion: sebuah ekstensi alami dari konsep informasi yang disimpan sebuah modul dapat menampilkan sejumlah tusk

Sebuah modul cohesive menampilkan sebuha task tunggal dalam sebuah prosedur dengan interaksi kecil dengan lainnya.

Goal: untuk mencapai cohesion yang tinggi untuk modul-modul pada sebuah sistem.

Tipe-tipe yang berbeda dari cohesion:
- coincidentally cohesive: sekumpulan task yang berhubungan satu sama lain secara bebas.
- logically cohesive: koneksi logical antara elemen-elemen pemrosesan
- communication cohesion: data di-share antar elemen-elemen pemrosesan - procedural cohesion: pemesanan antara elemen-elemen pemrosesan

Desain Modular Efektif

Coupling: (Gambar 13.8)
Suatu ukuran interkoneksi antar modul-modul dalam sebuah struktur program.
Coupling tergantung pada kompleksitas interface antar modul.

Goal: mencoba untuk coupling terendah yang mungkin antar modul.

Coupling yang baik à mengurangi atau mencegah pengaruh perubahan dan efek ripple.
à mengurangi biaya pada perubahan program, testing,
maintenance

Tipe-tipe coupling:

- data coupling: parameter passing atau interaksi data

- control coupling: share logical kontrol yang berhubungan (untuk sebuah data kontrol)

- common coupling: sharing data umum

- content coupling: modul, penggunaan data atau pengontrolan
informasi di-maintain modul lain.

PRINSIP & KONSEP ANALISA KEBUTUHAN (REQUIREMENT_ANALYST)

Prinsip & Konsep Analisa Kebutuhan

Analisa Kebutuhan
- Teknik Komunikasi
- Memulai Proses
- Teknik Spesifikasi Aplikasi Yang dimudahkan
- Prinsip Analisa
- Daerah Informasi
- Modeling
- Penyekatan
- Prototipe Software
- Pemilihan Pendekatan Prototipe
- Metode Prototipe dan perkakasnya.
- Spesifikasi kebutuhan perangkat lunak
- Prinsip Spesifikasi
- Penyajian

Analisa Kebutuhan

Analisa kebutuhan
Adalah Suatu proses penemuan, perbaikan, modeling, dan spesifikasi.

Sepanjang proses, kedua-duanya pelanggan dan pengembang mengambil suatu peran aktif.

Terpusat pada: “ apa” sebagai pengganti “ bagaimana”

Input dari proses analisa kebutuhan:
- Rencana Proyek Software - Spesifikasi sistem ( jika terdapat)

Output
Adalah Spesifikasi dokumen kebutuhan software - menyediakan software insinyur dengan model yang dapat diterjemahkan ke dalam data, secara ilmu bangunan, alat penghubung, dan disain prosedur.

- pengembang dan pelanggan dapat memeriksa mutu dari software dan menyediakan pengaruh arus balik.

Yang melaksanakan analisa kebutuhan: analis sistem

Usaha dan tugas utama :
- Pengenalan masalah ( atau pemahaman sistem)
- Menemukan dan memahami kebutuhan system
- Menyuling kebutuhan
- Sintese dan Evaluasi:
- apakah merupakan solusi alternative
- memusatkan pada solusi apa harus dipilih atau digunakan sebagai ganti bagaimana cara menerapkan suatu solusi.
- Modeling: untuk menghadirkan berbagai aspek dari system
- data yang diperlukan
- informasi dan mengendalikan arus
- perilaku operasi
- Spesifikasi:
- fungsi software, dan tampilan
- menghubungkan antar unsur-unsur system
- batasan sistem

Proses Rancang Bangun Kebutuhan

Studi kelayakan:
- Mengidentifikasi dan perkiraan untuk melihat jika kebutuhan pemakai dapat dicukupi dengan menggunakan teknologi dan teknik sekarang.

- Analisa kebutuhan:
- Proses menurunkan kebutuhan sistem melalui pengamatan atas sistem yang berjalan, diskusi dengan para pemakai dan pelanggan, analisis tugas, dan seterusnya.

Definisi kebutuhan:
- Menterjemahkan informasi ke dalam suatu REQ. dokumen.

Spesifikasi kebutuhan:
- Menggambarkan kebutuhan sistem yang menggunakan suatu ketepatan yang konsisten, dan cara lengkap.
- Penggunaan beberapa metoda spesifikasi kebutuhan

Proses Analisa Kebutuhan

Pemahaman daerah:
- Pemahaman daerah aplikasi.
- Koleksi kebutuhan:
- Proses dari saling berinteraksi dengan pelanggan, para pemakai untuk menemukan kebutuhan untuk sistem itu.

- Penggolongan kebutuhan:
- Menggrupkan dan menggolongkan kebutuhan yang dikumpulkan itu.

- Resolusi konflik:
- Memecahkan kebutuhan konflik.

- Prioritisasi:
- Mengidentifikasi dan mendaftar kebutuhan menurut kepentingan mereka

- Pengesahan kebutuhan:
- Memeriksa dan mengesahkan kebutuhan yang dikumpulkan untuk melihat jika mereka lengkap, benar, dan serasi



Teknik Komunikasi

Memulai Proses
Q1 menetapkan: Konteks bebas bertanya untuk memimpin pemahaman dasar dari masalah

Siapakah di belakang solusi?

Siapa yang akan menggunakan solusi?
…..
Q2 menetapkan: Mempertanyakan untuk memperoleh suatu pemahaman yang lebih baik menyangkut masalah dan persepsi konsumen tentang suatu solusi.

Bagaimana kamu akan menandai “ baik” keluaran yang akan dihasilkan oleh suatu solusi sukses?

Apa permasalahan tujuan solusi ini?

Q3 menetapkan: Meta-Questions memusatkan pada efektivitas dari pertemuan.

Apakah kamu orang yang tepat untuk menjawab pertanyaan ini? Apakah jawab mu “ resmi”?


Teknik Spesifikasi Yang Dimudahkan

Software insinyur dan Pelanggan sering mempunyai suatu tak sadar “ kita dan mereka” pikirkan.
Ini mungkin menyebabkan: kesalah pahaman, kehilangan informasi penting,….
Untuk memecahkan masalah, pendekatan FAST diusulkan.
FAST mendorong kreasi dari suatu gabungan regu dari pengembang dan pelanggan.
Mereka bekerja sama
- untuk mengidentifikasi masalah dan mengusulkan dan
- untuk merundingkan unsur-unsur solusi yang berbeda dan pendekatannya
Petunjuk dasar dari FAST
- pegangan suatu pertemuan pada suatu lokasi netral
- menetapkan aturan untuk keikutsertaan dan persiapan
- mempunyai suatu agenda rapat formal
- mengendalikan pertemuan dasar dengan sebuah “ penghubung”
- menggunakan sebuah “ mekanisme definisi”
- mempunyai suatu gol umum untuk
- mengidentifikasi masalah
- mengusulkan unsur-unsur kebutuhan dan solusi
- merundingkan pendekatan berbeda




Penyebaran Fungsi Mutu

Penyebaran Fungsi Mutu ( QFD) adalah teknik manajemen mutu
- Menterjemahkan kebutuhan dari pelanggan ke dalam kebutuhan teknis untuk software.

QFD mengidentifikasi tiga jenis kebutuhan:
- Kebutuhan normal:
Sasaran hasil dan tujuan:
contoh: jenis pajangan grafis, fungsi sistem spesifik

- Kebutuhan yang diharapkan:
kebutuhan yang terkandung:
contoh: merampas human-machine interaksi ,merampas software instalasi

- Kegairahan kebutuhan:
Corak pergi di luar customer’s harapan

Prinsip Analisa

Masing-masing metoda analisa mempunyai suatu segi pandangan unik.
Semua metoda analisa terkait oleh satu set prinsip operasional:
- menghadirkan dan memahami daerah informasi- menggambarkan fungsi software
- menghadirkan perilaku dari software – menggunakan model untuk melukiskan informasi, fungsi, dan perilaku--> membongkar detil di dalam suatu lapisan pertunjukan.
- bergerak dari informasi penting ke arah yang lebih detil

Satu set petunjuk untuk rancang-bangun kebutuhan:
- memahami masalah sebelum permulaan untuk menciptakan model analisa
- mengembangkan prototipe untuk membantu pemakai untuk memahami bagaimana interaksi manusia dan mesin
- merekam asal dan pertimbangan untuk tiap-tiap kebutuhan
- menggunakan berbagai pandangan kebutuhan
- memprioritaskan kebutuhan
- bekerja untuk menghapuskan kerancuan

Daerah Informasi Software

Software dibangun untuk memproses data, untuk mengubah bentuk data dari yang satu dengan yang lain.
Software juga memproses peristiwa.
Prinsip analisis operasi yang pertama perlu untuk menguji daerah informasi.
Daerah informasi berisi tiga pandangan yang berbeda menyangkut data dan kendali:
- hubungan dan isi informasi:
isi informasi--> menghadirkan data individu dan object kendali
ada hubungan berbeda antara object dan data

- arus informasi:
menghadirkan cara di mana data dan kontrol berubah dari masing- masing gerak melalui suatu sistem. Data dan control bergerak antara dua perubahan bentuk ( fungsi).

- struktur informasi:
menghadirkan organisasi yang internal dari berbagai data dan materi kendali- struktur pohon data - data tebel ( n-dimensi)

Pemodelan

Selama modeling software kebutuhan analisa, kita menciptakan model menyangkut sistem untuk dibangun.
Model terpusat pada :- apa yang sistem harus lakukan, bukan bagaimana sistem mengerjakan itu.

Model pada umumnya mempunyai suatu notasi grafis untuk dihadirkan:
- informasi, pengolahan, perilaku sistem, dan corak lain

Yang kedua dan ketiga analisis operasi prinsip memerlukan:
- membangun model perilaku dan fungsi

Model Fungsional
Software Model fungsional mengubah bentuk informasi. Tiga fungsi umum:- masukan, memproses, keluaran

- Model Perilaku
Kebanyakan perilaku model software bereaksi terhadap peristiwa dari dunia luar. Suatu model perilaku menciptakan suatu penyajian menyangkut status software dan peristiwa yang menyebabkan perangkat lunak untuk berubah status

Peran penting model:
Model menopang analis di dalam pemahaman informasi, fungsi, dan perilaku dari suatu sistem.
Model menjadi titik-api untuk tinjauan ulang di dalam aspek kelengkapan, konsistensi, dan ketelitian dari spesifikasi itu.
Model menjadi pondasi untuk disain, menyediakan perancang dengan suatu penyajian penting dari software.

Prototipe Software

Dalam beberapa hal adalah mungkin untuk menerapkan analisis operasi prinsip dan memperoleh suatu model software dari suatu disain yang dapat dikembangkan.

Memilih pendekatan prototipe:
Pendekatan closed-ended disebut lembaran prototype iklan.
- Sebuah prototipe melayani sebagai demonstrasi keras dari kebutuhan.

Pendekatan open-ended disebut evolusiner membuat prototip.
- suatu prototipe bertindak sebagai evolusi pertama dari sistem yang telah selesai.

Gambar 11.7 memilih pendekatan prototipe yang sesuai.

Prototipe Perkakas dan Metoda:
- Teknik Generasi Keempat
- Komponen Software dapat dipakai kembali
- Spesifikasi Formal dan Lingkungan Prototipe

Spesifikasi Software

Prinsip Spesifikasi
Memisahkan kemampuan dari implementasi
Mengembangkan suatu model menyangkut perilaku yang diinginkan dari suatu system
Menetapkan konteks di mana software beroperasi
Menggambarkan lingkungan di mana sistem beroperasi
Menciptakan suatu model teori dibanding suatu implementasi atau disain model
Spesifikasi adalah suatu model abstrak dari suatu sistem riil
Menetapkan struktur dan isi dari suatu spesifikasi ( mudah untuk diubah)

Petunjuk untuk penyajian:
Isi dan Format penyajian harus relevan kepada masalah
Informasi yang dimasukkan di dalam spesifikasi harus sekumpulan
Diagram dan notasi format lain harus terbatas dalam jumlah dan digunakan secara konsisten.
Penyajian harus bisa berhadap-hadapan kembali

Standar spesifikasi kebuthan software:
IEEE ( standard No. 830-1984) dan U.S. Departemen Pertahanan
Dalam banyak kesempatan, suatu persiapan penggunaan manual harus disajikan untuk menghadiahi perangkat lunak sebagai black-box.

SYSTEM ENGINEERING

Hierarchy System Engineering
System Modeling
Information Engineering: An Overview
Product Engineering: An Overview
Information Engineering
Information Strategy Planning
Enterprise Modeling
Business-Level Data Modeling
Business Area Analysis
Process Modeling
Product Engineering
System Analysis
Identification of Need
Feasibility Study
Economic Analysis
Technical Analysis
Modeling The System Architecture
System Modeling and Simulation
System Specification

System engineering:
software engineering terjadi pada proses yang bersifat konsekuen

Sistem engineering terfokus pada :
- sistem dan masing-masing elemn, termasuk hardware, software
- product, service, teknologi

Proses sistem engineering sering disebut information engineering ketika context dari pekerjaan engineering terfokus pada bisnis enterprise

Product engineering terfokus pada product construction.

System Modeling

Sistem engineering merupakan proses modeling

The created models:
- define the process
- represent the process behavior
- define both exogenous and endogenous input to the model
- represent all linkages
Model terbuat dari :
- definisi proses
- represent process behavior
- difinisi dari masing-masing input exogenous dan endogenous untuk model
- represent semua linkages

Yang termasuk ke dalam faktor-faktor untuk membuat model :
- assumptions
- simplifications
- limitations, seperti hardware limitations
- constraints, seperti computation constraints
- preferences (solutions, architecture, ..)

Information Engineering: An Overview

Information engineering (IE)
Mendefinisikan arsitekture yang sesuai untuk bisnis yang dapat digunakan untuk informasi yang efektif

Tiga perbedaan arsitektur
- data architecture
-> menyediakan framework mengenai bisnis informasi
- application architecture
-> mancakup elements pada system.
- technology infrastructure
-> menyediakan dasar untuk data dan arsitektur aplikasi

Information strategy planning (ISP) --> world view
Business area analysis (BAA) ---> domain view
1. terfokus pada daerah bisnis yang lebih spesifik.
2. mendefinisikan data objects, relationship, dan data flow

Software engineering:
- business system design (element view)
- construction dan integration
terfokus pada ---> detail implementation

Information Engineering

Langkah pertama : information strategy planning (ISP)

Objectives:
Untuk mendefinisikan stretegi objective bisnis dan tujuannya
Untuk mengisolasi faktor kriitikal yang sukses
-Untuk menganalisa pengarub teknologi dan otomatisasi pada tujuan dan objectives
Untuk menganalisa keberadaan informasi untuk menetukan aturan-aturan untuk mendapatkan
tujuan dan objectives

ISP juga membuat model data pada level bisnis yang mendefinisikan key data object dan
Hubungan antara satu dengan yang lainnya dan untuk area bisnis yang berbeda
Model enterprise:
- pengalamatan struktur organisasi dan fungsi
- mendekompos fungsi bisnis untuk mengisolasi process
- berhubungan dengan objectives, goals, dan CSFs (critical success factors)

Fungsi bisnis
- beberapa aktivitas yang harus dilengkapi untuk mendukung
Beberapa aktivitas.
Process bisnis :
- transisi yang menerima spesifik input dan menghasilkkan output yang lebih spesifik.

Business-Level Data Modeling

Business-level data modeling merupakan enterprise modeling activity
- focuses pada data objects

Pada level bisnis, object type data termasuk :
- producers dan consumers dari information
- occurrences dari events
- aturan organizational
- unit organizational
- places
- information structures

Business Area Analysis

Business area analysis (BAA)
-> membangun detail framework untuk membangun informasi berdasarkan enterprise
-> membangun diagram dan matric untuk model dan record data dan aktivitas

Beberapa model yang berbeda dapat digunakan untuk :
- data models
- process flow models
- process decomposition diagrams
- a variety of cross-reference matrices

Process Modelling :
- menganggap set dari fungsi pada proses bisnis
- bagian dari proses bisnis dan merefine kembali
Fungsi penjualan :
- membangun hubungan antar customer
- menyediakan produk literatur dan informasi yang terhubung
- Address questions dan concerns
- menyediakan produk evaluasi
- menerima tawaran penjualan
- mengecek availibility dan tawaran konvigurasi
- menyiapkan delivery order
- mengkonfirmasikan konfigurasi, pricing, ship data dengan customer
- mengantarkan pesanan pada department
- mengikuti customer



Product Engineering

Business area analysis (BAA)
-> establishes a detailed framework for building an information-based enterprise.
-> membangun detail framework untuk membuat informasi berbasis enterprise.
-> menggunakan diagram dan matrik untuk model dan merecord data dan aktivitas

Product engineering merupakan pemecahan dari aktivitas masalah

Uncover, analyze dan allocate:
-> product data, function, behavior untuk masing-masing components engineering
-> function, performance, constraints
-> allokasi functions untuk components

Trade-off criteria:
- project consideration
- business consideration
- technical analysis
- manufacturing evaluation
- human issues
- environmental interfaces
- legal considerations

Sistem engneering juga menganggap solusi untuk masalah yang dihadapi customer
- apakah sistem yang telah sesuai telah siap?

System Analysis

Objectives dari system analysis:
- mengidentifikasi keperluan customer
- mengevaluasi konsep sistem untuk feasibility
- menunjukkan analisis ekonomi dan teknik
- mengalokasikan fungsi terhadap hardware, software, database, dan elemen lainnya
- membuat batasan-batasan biaya dan schedule
- membuat definisi dari sistem

Mengidentifikasi keperluan
- bertemu dengan customer, users, dan marketing people
- mengerti objectivitas product
- mendefinisikan tujuan dari ebjectivitas

Product evaluation:
-apakah teknologi telah siap untuk membangun sisttem?
-resource apa yang diperlukan pada development dan manufacturing?
-apa yang menjadi potensial market untuk produk?
-bagaimana membandingkan produk dengan produk yang lebih kompetitif?

Feasibility Study:

Economic feasibility – evaluasi cost development yang akan menjadi keuntungan
-Technical feasibility - feasibility study dari function, performance, dan constraints
-Legal feasibility - menentukan beberapa liability dari produk
-Alternatives - pendekatan alternatif lainnyauntuk mengembangkan produk

Hasil yang ideal untuk feasibility study:
- obvious economic justification,
- technical risk is low
- few legal problems
- no reasonable alternatives

Technical feasibility:
- Development risk
- Resource availability
- Technology

Legal feasibility:
- contracts, liability, infringement, myriad, …

Feasibility report direview dari project manajement dan upper manajemen

Technical Analysis

Analisis teknik terfokus pada assessment dari teknikal viability dari sistem yang telah diperkenalkan

- Teknologi apa yang diperlukan untuk melengkapi fungsi sistem dan performance?
Material yang baru, metode, algoritma atau proses apa yang diperlukan?
Resiko apa pada masing-masing development?
bagaimana pengaruh teknologi terhadap cost?

Ini penting sebagai catatan bahwa :
evaluasi analitik tidak selalu mungkin

Modeling merupakan mekanisme efektif untuk teknikan analisis dari sistem berbasis komputer

Kriteria-kriteria yang digunakan pada analisis teknikal sistem :

- kemampuan merepresentasikan sistem yang dinamis
- mudah untuk dimengerti dan lebih simpel
- faktor yang relevant terhadap masalah
- hubungan antara semua faktor
- dukungan implementasi
- mudah untuk dirubah dan diperluas

Model dari Sistem Arsitektur

Every computer-based system can be modeling as
Setiap sistem berbasis komputer memiliki model seperti :
-> informasi yang mentransform dengan menggunakan input – processing – output arsitektur
-> an information transform using an input - processing - output architecture
-> dua tambahan feature
- user interface processing dan maintenance dan self-test processing.

Untuk mengembangkan model system:
- architecture template:
1) user interface, 2) input, 3) system function dan control,
4) output, dan 5) maintenance dan self-test

Models:
- Architecture context diagram (ACD) Figure 10.11
membuat batasan informasi antara sistem (sub-system) di dalam environment

- Extended ACD Figure 10.12
ACD + external entities dan information flow

- Architecture Flow Diagram (AFD) Figure 10.13
menunjukkan subsistem utama dan aliran informasi yang penting

- AFD Hierarchy Figure 10.14
AFD + Hierarchy

Spesifikasi Sistem

Spesifikasi sistem :
Dokumen yang akan memberikan bantuan sebagai dasar bagi hardware / software, engineering, database engineering dan human engineering.

menggambarkan:
- fungsi sistem
- performance requirement sistem
- batasan-batasan sistem
- arsitektur sistem
- system information flow (input dan output dari the system)

Spesifikasi sistem berdasarkan pada figure 10.15

Software Process and Models

Software Process Models

Software Process

Software Process Models
Waterfall Model
Prototyping Model
RAD Model

Evolutionary Software Process Models
Incremental Model
Spiral Model
Component Assembly Model
Concurrent Development Model

Process Maturity
Process and Product

Software Process

Kerangka kerja proses common software :
Bisa digunakan untuk semua proyek software.
banyaknya kumpulan tugas, termasuk tugas, milestone, pengiriman dan SQO points.
Aktivitas Umbrella :
project tracking and control
technical reviews (formal or informal)
software quality assurance (SQA)
konfigurasi management
dokumentasi
Pengukuran
manajemen reuse dan resiko

Pemecahan masalah yang Terulang

Semua pembuatan software bisa dilihat sebagai pemecahan masalah yang terulang
Itu memiliki empat tingkatan :
definisi masalah-indetifikasi masalah dan definisinya
pembuatan teknik-menemukan solusi untuk memecahkannya
integrasi solusi-menggunakan solusi dan mengirimkan ke sistem
status QUO – Bagian yang ada kesalahan.

Software Process Models


Konsep:
- Sebuah model proses atau paradigma rekayasa software:
-> menunjukkan suatu strategi untuk melindungi proses, metode dan alat bantu yang secara bersama mengelola secara efektif dan mengirim produk software.

Pemilihan model proses berdasarkan pada:
- proyek dan aplikasi yang alami
- metode dan alat bantu yang digunakan
- kontrol dan pengiriman

Terdapat empat dasar aktivitas proses :
- Software specification.
- Software development
- Software validation
- Software maintenance (or evolution)

The Waterfall Model

Model waterfall adalah yang paling lama dan banyak secara luas digunakan
paradigma untuk rekayasa software.

Keuntungan:sederhana,langkah-secara terurut,fokus,dan mudah diikuti.

Masalah:

Tidak flesible sebab proyek yang nyata jarang mengikuti aliran yang terurut untuk menyusun Model.
Sangat sulit untuk customer terhadap mengahadapi semua kebutuhan yang eksplisit.
Customer harus memiliki kesabaran untuk menunggu keabsahan produk software dalam fase
Yang terlambat.(sampai program dimplementasikan)
Customer tercakup dalam awal proyek.
Pembuat sering ditunda secara tidak berhubungan diantara fase.

The waterfall model - the linear sequential model, disebut juga
“classic life cycle”
sistematika, pendekatan yang secara terurut untuk pembuatan software yang mulai dari level sistem dan progres menuju analisa, design, coding, testing dan perawatan.

The Prototyping Model

step 1: Kebutuhan bersama
step 2: A “design yang cepat” -> folus pada fungsi yang nyata dan kebiasaan dari produk
step 3: konstruksi Prototype
step 4: evaluasi Customer dari prototype
ulangi langkah 1.

Keuntungan:
Mudah dan cepat identifikasi kebutuhan customer
Customer mengecek protipe di awal tingkatan dan menyediakan input dan umpan baliknya.
Persetujuan yang baik dengan mengikuti kasus:
Customer tidak bisa menyediakn kebutuhan yang jelas.
Sangat rumit interaksi sistem dari pengguna
Menggunakan teknologi baru, hardware dan algoritma
Membuat domain baru sistem aplikasi

Masalah:
Prototipe bisa melayani sebagai “sistem pertama”.Brooks merekomendasikan untuk membuangnya.
Developer biasa ikut membuat produk didasarkan pada prototipe.
Developer sering membuat perjanjian implementasi dalam memerintahkan untuk dapat prototipe bekerja secara cepat.
Customer boleh terkejut bahwaa protipe adalah tidak sebuah produk, yang dibuat dengannya.

Evolusi Model Proses Software

Model proses klasik tidak dirancang untuk mengirimkan sistem yang produktif sehingga asumsinya pada:
Sistem yang sempurna akan dikirimkan setelah urutan linear diselesaikan
Customer mengetahui yang mereka inginkan di tingkatan awal

Realita dalam proses pembuatan software ->
banyaknya kebutuhan perubahan selama latihan pembuatan
Banyaknya aktivitas iterasi dan bekerja sebab evolusi alami dari produksi software

Persetujuan yang sulit dengan evolusi produk, beberapa evolusi model proses yang disusun :
the incremental model
the spiral model
Win-win spiral model
the component assembly model
the concurrent development model

The Spiral Model

spiral model (by Boehm[BOE88])
adalah sebuah evolusi model proses software
pasangan iterasi yang murni dari prototipe
mencakup aspek sistematik dari model terurut yang linear.
menyediakan kegunaan untuk pembuatan yang cepat dari versi pertambahan dari software..


Model spiral dibagi kedalam banyak daerah aktiitas:
customer communication
planning (resources, timelines, etc.)
risk analysis
engineering
construction & release
customer evaluation

Setiap bagian dipopulasi oleh rangkaian daru tugas kerja

The Component Assembly Model

Object Technologies -- kerakngka kerja teknis untuk sebuat model proses komponen dasar
untuk rekayasa software

Model komponen rakitan
banyak tidak bekerja dari sifat dari model spiral
adalah evolusi yang alami
meminta sebuah pedekatan secara berulang untuk membuat suatu software
memimpin penggunaan kemabali software

Keuntungan:
permintaan software digunakan kembali
--> biaya berkurang
--> pengurangan waktu daur pembuatan

Software Engineering

Introduction to Software Engineering


  • Evaluasi Software


  • Tentang Software

    • Karakteristik Software

    • Komponen Software

    • Aplikasi Software


  • Sejarah Software


  • Mengapa Software engineering?


  • Apa yang dimaksud software engineering?


  • Siapa yang melakukan software engineering?





Evolution of Software


-beberapa tahun lalu:

- Batch orientation

- Limited distribution

- Custom software

-era tahun ke -2:

- Multiuser

- Real-time

- Database

- Product software

-era tahun ke - 3:

- Distributed systems

- Embedded “intelligence”

- Low cost hardware

- Consumer impact

-era tahun ke - 4:

- Powerful desk-top systems

- Object-oriented technologies

- Expert systems

- Artificial neural networks

- Parallel computing

- Network computers


Karakteristik Software


  • Software memiliki fungsi ganda. Software dapat disebut sebagai produk, tetapi juga dapat disebut sebagai sarana yang dapat mengantarkan produk itu sendiri


  • Software bersifat logical dibanding elemen fisik dari sistem


  • Software memiliki beberapa karakteristik yang dapat membedakan dari hardware


  • Software dikembangkan atau dibangun, tetapi tidak menghasilkan classical sense


  • Banyak software yang sudah bisa digunakan secara langsung atau bersifat custom built, tetapi ada pula yang masih menggabungkan antar beberapa komponen.


Aplikasi Software


System Software - Kumpulan dari beberapa program yang dibuat untuk memberikan servis terhadap program lainnya pada setiap level. Contohnya : compiler, operating sistem


Real-time Software - Program yang dapat memonitor/menganalisa/mengontrol kejadian nyata yang terjadi di dunia ini


Business Software - Program yang dapat mengakses, menganalisa dan memproses informasi bisnis.


Engineering and Scientific Software - Software yang menggunakan algoritma “number crunching” untuk membedakan science dan applications. Sistem simulation, computer-aided design.


Embedded Software - Software terletak pada read only memory dan digunakan untuk mengontrol produk dan sistem yang akan dikirimkan untuk konsumen dan industrial markets.


Artificial Intelligence (AI) Software - program yang digunakan untuk teknik AI dan metodenya digunakan untuk memecahkan masalah yang kompleks. Contohnya : expert sistem, pengenalan pola, games.


Internet Software - program yang mensupport pengaksesan internet. Contohnya : search engine, browser, e-commerce software,authoring tools.


Software Tools and CASE environment - tools dan program yang dapat membantu pembuatan aplikasi software dan sistem.contohnya : test tools dan version control tools.


Software Crisis


Dalam dunia industri, ada istilah “crisis”


Arti : “Crisis”

Waktu yang menentukan atau krusial.



Software crisis

  • Sekumpulan masalah yang ditemui dalam membuat sofware

    • Masalah pengembangan software

    • Masalah dalam perawatan yang semakin banyak untuk software yang ada


Contoh ciri-ciri software “crisis” :

- Build a wrong product.

- Project schedule problems

- Cost estimation problems


Software Myths (I)


Banyak penyebab pada kegagalan software disebabkan oleh mitos yang timbul pada sejarah awal pengembangan software.

-- mitos software disebarkan dengan penjelasan yang salah dan membingungkan.

-- Manager software dibawah tekanan untuk menentukan anggaran, menyusun jadwal dan meningkatkan kualitas


Myths --> Pendirian yang menyesatkan orang ---> masalah serius dalam produksi software

Management Myths:


Kita cukup memiliki buku yang menyediakan standar dan prosedur untuk mengembangkan software. Tanpa perlu menyediakan orang untuk mempelajarinya.”


“Jika kita tidak menepati jadwal, kita dapat menambah programmer”


Software Myths (II)


Customers dari software mungkin berasal dari :

- di luar perusahaan yang telah merequest software dibawah kontrak

- seseorang yang berasal dari dalam (in house group)

- marketing atau sales group.


Customer Myths:


pernyataan umum adalah memulai dengan menulis program secukupnya kemudian kita dapat memberikan penjelasan dengan detail”


“project requirement secara langsung berubah, tetapi perubahan dengan mudah dapat ditampung karena software bersifat fleksibel”


Software Myths (III)


Pelaksana Software:

Planing group - System analysts, system architects

Development group - Software engineers

Verification group - Test engineers, quality assurance group

Support group - Customer supporters, technical supports

Marketing/sales - Marketing people and product sales


Practitioner’s Myths:


pertama kali kita menulis program dan kemudian mendapatkan pekerjaan, sehingga pekerjaan kita selesai”


sampai pada akhirnya program dapat di running, sampai benar-benar yakin bahwa program tidak ada cara untuk meningkatkan quality”


“software dapat diserahkan apabila telah berhasil (telah sukses)”


Major task dari pembuatan software adalah teknik penulisan program.


“Schedule dan requirement merupakan hal yang penting ketika kita menulis program”


What is Software Engineering?


Walaupun ratusan pengarang telah mengembangkan definisi tersendiri tentang software engineering, definisi ini diusulkan oleh Fritz Bauer[NAU 69] yang menyediakan basis :


[Software engineering adalah] prinsip yang digunakan pada sound engineering yang digunakan untuk mendapatkan software yang bersifat ekonomis dan dapat bekerja secara efisien pada real machines”


The IEEE [IEE93] telah mengembangkan definisi yang lebih lengkap dengan pernyataan :


Software Engineering : (1) aplikasi yang bersifat sistematik, disipilin dengan mendekati metode pengembangan, operasi, dan maintemaintenance dari software; (2) studi dengan pendekatan pada definisi nomor (1)”


Pressman’s view:

“Software engineering is a layered technology (Figure 2.1)”





Software methods:

Metode Software engineering menyediakan teknik “how to” untuk membangun software. Metode --> meliputi bagaimana menyelesaikan task :

- requirement analisis, design, coding, testing dan maintenance



Software process:

Proses Software engineering mendekatkan dengan :

- teknologi bersama

- memungkinkan secara rational dan pengenbangan secara bertahap

dari software komputer


Proses Software engineering merupakan set framework dari area key process.

Yang dibentuk dari basis untuk :

- project management, budget, dan schedule control

- teknik metode aplikasi

- kualitas produk control


Software tools:

  • Program menyediakan sistem otomatis atau semi otomatis untuk proses dan metode.

  • Program yang memberikan dukungan pada engineers untuk menyelesaikan

masing-masing task.


What is Software Engineering?
- A Generic View


Engineering --> analysis, design, construction, verification, and management

of technical (or social) entities.


Tiga phase dalam production software

- phase definition

- phase development

- phase maintenance


Phase definition : (dilakukan dalam tahap pendefinisian dan perencenaan dari software sistem)

Phase definition terfokus pada apa yang terjadi dalam software sistem.

- informasi apa yang harus diproses pada sistem?

- fungsi apa saja yang harus disediakan oleh sistem?

- performance sistem dan kriteria yang diperlukan oleh sistem?

- apa yang diperlukan pada sistem behavior?

- dengan cara apa requirement akan direpresentasikan?


Tiga tugas utama pada phase definisi :

- sistem atau informasi engineering]

- software project planning

- requirement analisis



Phase Development : (terjadi selama proses pengembangan dari software sistem)


Phase development terfokus pada bagaimana.

- bagaimana sistem menjadi terstruktur?

- bagaimana data-data yang ada menjadi terstruktur?

- bagaiman informasi dapat diproses?

- bagaimana fungsi dapat diimplementasikan?

- bagaiamana karakteristik dari interface?

- bagaimana design dapat menjadi lebih spesifik?

- bagaimana testing dapat ditunjukkan?


Terdapat tiga tipe task dari phase development :

- software design

- code generation, dan

- software testing


Phase maintenance : -> evaluasi dari produk software setelah sistem testing.

Phase maintenance mengulang kembali langkah-langkah pada phase definisi dan pengembangan


Phase development terfokus pada perubahan software sistem.


  • Error correction – apabila ini terjadi maka dilakukan perubahan software sehingga software menjadi benar.


  • Adaptation – memodifikasi software untuk mengakomodasi perubahan yang terjadi terhadap lingkungan.


  • Enhancement – mengembangkan software dengan melakukan penambahan fungsi-fungsi yang baru untuk customer/user.

-Prevention - preventive maintenance, called software reengineering.

dengan membuat perubahan pada software sehingga dapat lebih mudah dikoreksi, ditangani.


Why Software Engineering?


Objectives:


  • Mengidentifikasi masalah baru dan solusi dari produk software

  • Mempelajari sistematik metode terbaru, prinsip, pendekatan untuk sistem analisis, design, implementasi, testing, maintenance.

  • Menyediakan teknik kontrol terbaru, manage, dan monitor proses software

  • Membangun tools software terbaru dan environment untuk mendukung software engineering.




Major Goals:


  • Untuk meningkatkan produktivitas dan kualitas

  • Untuk meningkatkan efektivitas dari kontrol schedule software dan planning. --- Untuk mengurangi cost dari development proses

-Untuk memenuhi keinginan dan requirements dari customer.

-Untuk menangani konduksi dari proses software engineering.

-Untuk meningkatkan practice software engineering.

-Untuk memberikan dukungan pada engineers terhadap aktivitas yang sistematik dan lebih efisien.