Teknik Pengujian Software

Overview

•Elemen kritis dari jaminan kualitas Software Merepresentasikan kajian pokok dari spesifikasi, desain, dan pengkodean
•Meningkatnya visibilitas Software sbg suatu elemen sistem dan “biaya” yg muncul akibat kegagalan Software
•Suatu hal yg wajar bagi suatu organisasi pengembang Software u/ meningkatkan 30 s/d 40 % usaha proyek total pd tahap pengujian
•Teknik pengujian Software a/ membahas dasar dan teknik pengujian Software u/ desain test case Software
•Dasar dan teknik pengujian Software
•Dasar-dasar pengujian Software menentukan sasaran penolakan bagi pengujian Software
•Desain test case berfokus pada serangkaian teknik u/ pembuatan test case yang memenuhi keselurahan sasaran pengujian
•Strategi mengenai pengujian dan debugging Software a/ dibahas pada chapter selanjutnya
Dasar dasar pengujian Software

Pada dasarnya, pengujian merupakan salah satu langkah pada proses Software yg dapat dianggap sbg hal yang destruktif daripada konstruktif. Perekayasa menciptakan sederetan test case yang dimaksudkan u/ “membongkar” Software yang sudah dibangun

•Sasaran-sasaran pengujian
•Prinsip pengujian
•Testabilitas
Sasaran-sasaran pengujian
•Dalam buku klasiknya mengenai pengujian Software, Glen Myers menyatakan sejumlah aturan yg berfungsi sebagai sasaran pengujian:
1.Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan
2.Test case yang baik adalah test case yang memiliki probabilitas tinggi u/ menemukan kesalahan yang belum pernah ditemukan sebelumnya
3.Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya
Prinsip pengujian

Sebelum mengaplikasikan metode u/ mendesain test case yang efektif, perekayasa Software harus memahami prinsip dasar yang menuntun pengujian Software. Davis mengusulkan serangkaian prinsip pengujian yang telah diadaptasi u/ digunakan dalam buku ini

•Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan

•Pengujian harus direncanakan lama sebelum pengujian itu dimulai
•Prinsip pareto berlaku u/ pengujian Software. Prinsip pareto mengimplikasikan bahwa 80 % dari semua kesalahan yang ditemukan selama pengujian sepertinya akan dapat ditelusuri sampai 20 persen dari semua modul program
•Pengujian harus mulai dari yang kecil dan berkembang ke pengujian yang besar
•Pengujian yang mendalam tidak mungkin
•u/ menjadi paling efektif, pengujian harus dilakukan o/ pihak ketiga

Risk Analysis and Management

Overview

•Risk are potential problems that might affect the successful completion of a software project.
•Risk involve uncertainty and potential losses.
•Risk analysis and management are intended[hope] to help a software team understand and manage uncertainty during the development process.
•The important thing is to remember that things can go wrong and to make plans to minimize their impact when they do.
•The work product is called a Risk Mitigation, Monitoring, an Management Plan (RMMM Plan).
Risk Strategies
•Reactive strategies – very common, also known as fire fighting, project team sets resources aside to delay with problems and does nothing until a risk becomes a problem.
•Proactive strategies – risk management begins long before technical work starts, risks are identified and prioritized by importance, then team builds a plan to avoid risks if they can or minimize them if the risks turn into problems
Software Risks
•Project risks – threaten the project plan
•Technical risks – threaten product quality and the timeliness of the schedule
•Business risks – threaten the viability [possible] of the software to be built (market risks, strategic risks, management risks, budget risks)
•Known risks – predictable from careful evaluation of current project plan and those extrapolated [predict/count] from past project experience
•Unknown risks – some problems simply occur without warning
Risk Identification
•Product-specific risks – the project plan and software statement of scope are examined to identify any special characteristics of the product that may threaten the project plan.
•Generic risks [common]– are potential threats to every software product (product size, business impact, customer characteristics, process definition, development environment, technology to be built, staff size and experience)
Risk Impacts
•Risk components – performance, cost, support, schedule
•Risk impact – negligible, marginal [tiny], critical [emergency], catastrophic [destroy]
•The risk drivers affecting each risk component are classified according to their impact category and the potential consequences of each undetected software fault or unachieved [fail] project outcome are described
Risk Projection (Estimation)
•Establish [make] a scale that reflects the perceived likelihood [possible] of each risk
•Delineate [describe] the consequences of the risk
•Estimate the impact of the risk on the project and product
•Note that overall accuracy of the risk projection to avoid misunderstanding
Risk Table Construction
•List all risks in the first column of the table
•Classify each risk and enter the category label in column two
•Determine a probability for each risk and enter it into column three
•Enter the severity of each risk (negligible, marginal, critical, catastrophic) in column four
•Sort the table by probability and impact value
•Determine the criteria for deciding where the sorted table will be divided into the first priority concerns and the second priority concerns
•First priority concerns must be managed ( a fifth column can be added to contain a pointer into the RMMM)
Assessing Risk Impact
•Factors affecting risk consequences – nature (types of problems arising), scope (combines severity with extent of project affected), timing (when and how long impact is felt)
•If cost are associated with each risk table entry Halstead’s risk exposure metric can be computed (RE = Probability * Cost) and added to the risk table
Risk Assessment
•Define referent levels for each project risk that can cause project termination (performance degradation, cost overrun, support difficulty, schedule slippage)
•Attempt [tyring] to develop a relationship between each risk triple (risk, probability, impact) and each of the reference levels.
•Predict the set of referent points that define a region of termination, bounded by a curve or areas of uncertainty).
•Try to predict how combinations of risks will affect a referent level
Risk Refinement
•Process of restating the risks as a set of more detailed risks that will be easier to mitigate, monitor, and manage.
•CTC (condition-transition-consequences) format may be a good representation for the detailed risks (e.g given that <condition> then there is a concern that (possibly) <consequences>)
Risk Mitigation, Monitoring, and Management
•Risk mitigation (proactive planning for risk avoidance)
•Risk monitoring (assessing whether predicted risks occur or not, ensuring risk aversion steps are being properly applied, collect information for future risk analysis, attempt [try] to determine which risks caused which problems)
•Risk management and contingency [possibly] planning (actions to be taken in the event that mitigation steps have failed and the risk has become a live problem)
Safety and Hazards Risks
•Risk are also associated with software failures that occur in the field after the development project has ended.
•Computers control many mission critical applications in modern times (weapons system, flight control, industrial processes, etc).
•Software safety and hazard analysis are quality assurance activities that are of particular [fact] concern [about] for these types of applications and are discussed later in the text
Risk Information Sheets
•Alternative to RMMM in which each risk is documented individually.
•Often risk information sheets (RIS) are maintained using database system.
•RIS components – risk id, date, probability, impact, description, refinement, mitigation/monitoring, management/contingency[possible]/ trigger[act]. Status, originator, assigned staff member.

PEDOMAN DESAIN INTERFACE

•Desain interface pemakai sangat dipengaruhi o/ pengalaman desainer
•Banyak referensi yg menyajikan serangkaian pedoman desain HCI yg a/ menghasilkan interface yg ramah dan efisien
•Ada 3 kategori pedoman desain HCI: interaksi umum, tampilan informasi dan entri data
Interaksi umum [pedoman yg biasa dipakai]
•Konsisten; gunakan format yg konsisten u/ pemilihan menu, input perintah, tampilan data, dan banyak lagi fungsi lain yg ada pada sebuah HCI
•Berikan umpan balik yg sangat berarti; berikan umpan balik auditori dan visual kpd user u/ memastikan  bahwa ada komunikasi 2 arah
•Mintalah verifikasi thd sembarang aksi destruktif yg signifikan; ex: hapus file à tambahkan message yakin?/ tidak
•Ijinkan kemudahan pembatalan sebagian besar aksi. Ex: undo
•Kurangi jumlah informasi yg harus diingat di antara aksi2; user tidak diharapkan u/ mengingat daftar angka / nama2 shg mereka dapat menggunkannya lagi pada fungsi berikutnya
•Usahakan adanya efisiensi dalam dialog, gerakan, pemikiran. Ex: jarak pergeseran mouse berjalan harus dipertimbangkan, penekanan tombol
•Memaafkan kesalahan; sistem harus melindungi dirinya sendiri dari kesalahan yg dapat menyebabkan kegagalan pd sistem
•Kategorikan aktivitas menurut fungsi dan atur geografi layar secara sesuai
•Sediakan fasilitas help yg sensitif konteks
•Gunakan verbal aksi yg sederhana / frasa verbal pendek u/ menamai perintah
Tampilan informasi
•Menampilkan hanya informasi yg relevan dengan konteks yg ada. Ex: user tidak boleh across data, menu dan grafik yg tdk ada hubungannya
•Jangan membanjiri user dg data, gunakan format representasi yg memungkinkan aimilasi informasi yg cepat. Ex: penggunaan grafik
•Gunakan label2 yg konsisten, penyingkatan standar, dan warna yg dapat diprediksi
•Ijinkan pemakai u/ memelihara konteks visual
•Hasilkan pesan kesalahan yg berarti
•Gunakan huruf besar dan kecil, pengelompokan teks sesuai kebutuhan
•Gunakan jendela u/ menggolongkan tipe2 informasi yg berbeda
•Gunakan tampilan analog u/ merepresentasikan informasi yg lebih mudah diasimilasikan dg bentuk representasi ini
•Pertimbangkan ketersediaan geografi layar tampilan dan gunakan secara efisien
Input data
•Minimalkan jumlah aksi input yg dibutuhkan dari pemakai
•Jagalah konsistensi di antara tampilan informasi dan input data
•Ijinkan pemakai mengkustomasi input
•Interaksi harus fleksibel tetapi juga diatur ke mode input yg disukai user
•Nonaktifkan perintah yg tidak sesuai di dalam konteks aksi yg sedang berlangsung
•Biarkan user mengontrol aliran interaktif
•Sediakan help u/ membantu semua aksi input
•Hilangkan input “mickey mouse”. Ex: berika nilai default shg tidak terjadi ambiguitas
DESAIN PROSEDURAL
•Pemrograman terstuktur. Ex: urutan , kondisi, pengulangan (u/ membatasi desain prosedural PL ke sejumlah operasi kecil yg dapat diprediksi)
•Notasi desain grafis. Ex: flowchart
•Notasi desain berbentuk tabel
•Bahasa desain program/ program desain language (PDL)

Evolusi desain PL

Evolusi desain PL

•Suatu proses kontinu yg terus berlangsung selama tiga dekade
•Kerja desain awal dikonsentrasikan pd kriteria u/ pengemb.program moduler dan metode u/ menyaring arsitektur PL dg cara top-down
•Aspek prosedural dari definisi desain yg tercakup dalam suatu filosofi (perograman terstruktur)
•Usaha selanjutnya mengusulkan metode struktur data ke dalam definisi desain
•Pendekatan yg lebih baru mengusulkan suatu pendekatan orientasi objek ke desain
Prinsip desain
•Desain perangkat lunak berupa proses dan model
•Proses desain à seragkaian langkah iteratif yg memungkinkan desainer menggambarkan semua aspek PL dibangun
•Keahlian kreatif, pengalaman, rasa tentang apa yg membuat PL baik, dan keseluruhan komitmen thd kualitas à faktor2 sukses bagi suatu desain kompeten
•Model desain à ekivalen rencana arsitek u/ sebuah rumah (dari betuk 3dàpembentukan detail spt layout pipa)
Konsep-konsep desain
•Abstraksi
•Penyaringan
•Modularitas
•Arsitektur PL
•Hirarki kontrol
•Partisi struktural
•Struktur data
•Prosedur PL
•Penyembunyian informasi
Abstraksi
•Pada saat kita bergerak melalui tingkat abstraksi yg berbeda, kita bekerja u/ membuat abstraksi data dan prosedural
•Abstraksi data à sekumpulan data yang menggambarkan objek data. Ex: pintu (tipe pintu, arah buka, berat, dimensi dsb)
•Abstraksi prosedural à urutan instruksi yang diberi nama yg mempunyai fungsi tertentu dan terbatas. Ex: kata “open” pada sebuah pintu. Open mengimplementasikan urutan panjang mulai dari berjalan k pintuàmeraih tombolàmembuka tombol dst
Penyaringan
•Penyaringan stepwise (seragkaian langkah) à strategi desain top down yg diusulkan o/ Wiklaus Wirth
•Arsitektur program dikembangkan dengan cara urut menyaring tingkat detail prosedural
Modularitas
•Adalah atribut tunggal dari PL yang memungkinkan sebuha program u/ dikelola secara intelektual
•PL monolitik (program besar yg terdiri dari modul tunggal) tidak dapat dipahami dengan mudah oleh pembaca
•Jumlah alur kontrol, cakupan referensi, jumlah variabel dan kompleksitas keseluruhan akan membuat pemahaman menjadi hampir tidak mungkin
•rumus
•Bagaimana kita menentukan sebuah modul yg sesuai u/ suatu ukuran yg diberikan? Meyer menyebutkan 5 kriteria yg memungkinkan kita mengevaluasi suatu metode desain
1.Dekomposabilitas modular
2.Komposabilitas modular
3.Kemampuan pemahaman modular
4.Kontinuitas modular
5.Proteksi modular
1.Dekomposabilitas modular (dekomposisi masalah menjadi submasalah2)
2.Komposabilitas modular (komponen desain reusable dipasang ke dalam sistem baru)
3.Kemampuan pemahaman modular (unit yg berdiri sendiri maka modul akan lebih mudah dibangun dan diubah)
4.Kontinuitas modular (meminimalisir efek dari perubahan kecil yg tjd)
5.Proteksi modular (bila tjd kondisi yg menyimpang pada modul pengaruh efek samping bisa diminimalisir)
Arsitektur PL
  • Mencakup struktur keseluruhan PL dan cara dimana struktur memberikan integrasi konseptual bagi suatu sistem
  • Arsitektur merupakan struktur  hirarki dari komponen program, cara bagaimana komponen tsb berinteraksi dll

Hirarki kontrol

•Disebut juga struktur program à merepresentasikan organisasi komponen program serta mengimplikasikan suatu hirarki kontrol

•hirarki kontrol merepresentasikan 2 karakteristik yg berbeda dari arsitektur PL à visibilitas dan konektivitas

•Visibilitas menunjukkan serangkaian komp.program yg dapat diminta / dipakai sbg data o/ komponen yg diberikan (ex:modul pd sistem BO dpt memilliki akses ke suatu array dar atribut data)
•Konektivitas: mengindikasikan serangkaian komponen yg diminta secara tidak langsung / digunakan sbg data o/ sebuah modul yg ditetapkan (ex. Sebuah modul yg secara langsung menyebabkan modul lain memulai eksekusi akan disambungkan dengan modul tsb)
Partisi struktural
•Struktur program harus dipartisi secara horisontal maupun vertikal
•Partisi arsitektur secara horisontal memberkan keuntungan:
1.Menghasilkan PL yg lebih mudah diuji
2.Membawa kpd PL yg lebih mudah dipelihara
3.Menghasilkan penyebaran efek samping yg lebih sedikit
4.Menghasilkan PL yg lebih mudah u/ diperluas
•Partisi vertikal (pemfaktoran):menyatakan bahwa kontrol (pembuatan keputusan) dan kerja harus didistribusikan secara top down dlm arsitektur program
Struktur data
•Representasi dari hubungan logis antara elemen2 data individual
•Struktur data seperti struktur program dapat direpresentasikan pada tingkat abstraksi yg berbeda
•Ex: stack à model konseptual dari suatu struktur data yg dpt dimplementasi sbg vendor/ linked list
Prosedur PL
•Berfokus pada detail2 pemrosesan dari masing2 modul secara individual
•Prosedur harus memberikan spesifikasi yg teliti thd pemrosesan, menckup urutan event, point2 keputusan, operasi dan struktur data itu sendiri
Penyembunyian informasi
•Bagaimana mendekomposisi suatu solusi PL u/ mendapatkan serangkaian modul terbaik?
•Menyatakan bahwa modul ditandai dg keputusan desain yg masing2 tersembunyi dari semua desain lain

6. KONSEP DAN PRINSIP DESAIN

Pendahuluan

•Desain = langkah pertama dalam fase pengembangan bagi setiap produk/ sistem yg direkayasa
•Definisi desain = proses aplikasi berbagai teknik dan prinsip bagi tujuan pendefinisian suatu perangkat, suatu proses/ sistem dalam detail yg memadai untuk memungkinkan realisasi fisiknya
•Tujuan desainer à menghasilkan suatu model/ representasi dari entitas yang kemudian akan dibangun
•Seperti desain rekayasa pada disiplin ilmu lainnya, desain PL berubah secara kontinu sebagai metode-metode baru, analisis yang lebih baik, serta membangun pemahaman yg lebih baik
Desain PL dan RPL
•Desain PL berada pada inti teknik dari proses RPL dan diaplikaskan tanpa memperhatikan model proses PL yg digunakan
•Begitu persyaratan PL telah mulai dianalisis dan ditentukan, maka desain PL menjadi yg pertama dari 3 aktifitas teknik- desain, coding dan testing.
•Dengan menggunakan satu dari sejumlah metode desain, langkah desain menghasilkan desain data, desain arsitektur, desain interface serta desain prosedural
•Desain data à mentransformasi model domain informasi yg dibuat selama analisis ke dalam struktur data yg akan diperlukan untuk implementasi PL (basisnya ERD & detail dari kamus data)
•Desain arsitektur à menentukan hubungan diantara elemen struktur utama dari program (kerangka kerja sebuah program komp. dari model analisis)
•Desain interface àbagaimana PL berkomunikasi dalam dirinya sendiri, dengan sistem yg berinteroperasi dengannya serta dengan user (mengimplikasikan aliran informasi [data/ kontrol])
•Desain prosedural àmentransformasi elemen2 struktural dari arsitektur program ke dalam suatu deskripsi prosedural dari komponen PL. (dasar dari desain prosedural dari PSPEC, CSPEC dan STD)
Proses desain
•Desain PL à suatu proses interaktif yang melaluinya dari analisis persyaratan diterjemahkan ke dalam suatu cetak biru u/ membangun PL
1.Desain dan kualitas PL
2.Evolusi desain PL
Desain dan kualitas PL
•McGlaughlin mengusulkan 3 karakteristik yang berfungsi sebagai pedoman bagi evaluasi suatu desain yg baik:
1.Desain harus mengimplementasikan keseluruhan persyaratan eksplisit yg dibebankan dalam model analisis, dan harus mengakomodasi semua persyaratan implisit yg diinginkan pelanggan
2.Desain harus menjadi panduan yg dapat dibaca, dapat dipahami bagi mereka yg menghasilkan code dan yg menguji serta memelihara PL
3.Desain harus memberikan suatu gambaran lengkap mengenai PL, yg menekankan data, dan domain perilaku dari perspektif implementasi
Pedoman u/ mengevaluasi kualitas desain secara detail
•Desain harus memperlihatkan suatu organisasi hirarki yg dengan baik menggunakan kontrol di antara elemen2 PL
•Desain harus modular à PL harus dipartisi secara logika ke dalam elemen2 yg melakukan fungsi dan subfungsi khusus
•Desain harus berisi data dan abstrasi prosedural
•Desain harus membawa ke arah modul (subrutin/prosedur) yg memperlihatkan karakteristik fungsional independen
•Desain harus mengarah kepada interface yg mengurangi kompleksitas hubungan antara modul2 dan dengan lingkungan eksternal
•Desain harus didapat dengan menggunakan metode berulang yang dikendalikan oleh informasi yg diperoleh selama analisis persyaratan PL

5. .. Continue Analysis modelling

Menggambarkan Sistem Dengan Dataflow Diagram

•Langkah awal adalah membuat “DIAGRAM KONTEKS”
•Diagram konteks : DFD di mana sistem terdiri dari satu proses
•Pada tahap ini terlihat semua external entity yang berinteraksi dengan sistem dan data flow, antara external entity dan sistem
•Budget monitoring system
•System berinteraksi dengan 3 external entity, yaitu :
1. DEPARTEMENTS
2. MANAGEMENTS
3. SUPPLIERS
•Aliran data utama dari Departements adalah “Spending Request”. Sebagai tanggapan dari sistem, Departemen menerima “Rejected Request” atau aliran data “Delivery Advice”
•Management menerima data flow “Request For Special Approval”, yang kemudian memberikan respons
•Management juga mengirim data flow “Budget Allocation” ke sistem dan mendapatkan data flow “Spending Summaries”
•Supplier menerima data flow “Part Order” dan mengembalikan data flow “Supplier Delivery Advice”
Setelah mendapatkan “Diagram Konteks”, langkah selanjutnya adalah membuat DFD yang memperlihatkan proses dari sistem utama, yang dinamakan dengan TOP LEVEL DFD
•Top level DFD memperlihatkan berbagai proses yang membentuk sistem
•Setiap proses mempunyai sebuah nama unik dan nomor proses
•Dari DFD di atas kita lihat bahwa data flow “Spending Request” dari Departements menuju ke proses “Check Funding”. Proses “Check Funding” melihat “Allocated Budget” dan menetapkan apakah izin khusus diperlukan dari management untuk diteruskan ke permintaan.
•Data flow “Approved Request” menuju ke proses “Classify Expenditure”, dan kemudian dimasukkan pada data store “Departemental-Accounts” dan “Type-Accounts”
•Akhirnya, jika diperlukan, “Part Order” untuk menetapkan bagian ( part ) semula dalam “Spending Request” diurus oleh supplier.
•Dua proses lainnya : “Setup Budget” dan “Provide Spending Summaries”
Kita dapat memperluas setiap proses pada Top Level DFD. Sebagai contoh diambil proses “Classify Expenditure”
Data Flow Diagram yang baik :
•Ketiadaan dari struktur flowchart
•Penyimpanan data
•Penamaan yang baik
Perbedaan antara Flowchart dan Data Flow Diagram :
•Flowchart terdiri dari box-box yang mendeskripsikan :
1.Komputasi
2. Decision / Keputusan
3. Iterasi
4. Loop
•Data Flow Diagram bukan Flowchart program dan tidak mempunyai elemen kontrol

4. Analysis Modelling

Pemodelan Fungsional dan Aliran Informasi
•Informasi ditransformasikan pada saat dia mengalir melalui sebuah sistem berbasis komputer.
•Sistem tersebut menerima input dengan berbagai cara dan menghasilkan suatu output.
•Akibatnya kita dapat menciptakan suatu model aliran bagi setiap sistem berbasis komputer tanpa melihat ukuran dan kompleksitasnya
Diagram Aliran Data/ Data Flow Diagram (DFD)
•Merupakan sebuah teknik grafis yang menggambarkan aliran informasi dan transformasi yang diaplikasikan pada saat data bergerak dari input menjadi output.
•Dikenal juga dengan sebutan grafik aliran data atau buble chart
Model aliran informasi
Komponen-komponen DFD :
• Proses
• External entity
• Data Flow
• Data Store
Proses
• Simbol proses adalah :  
• Proses menunjukkan apa yang dikerjakan oleh sistem
• Setiap proses memiliki nama yang unik dan nomor yang ditempatkan dalam simbol
File atau Data Store
•Simbol :
•File atau Data Store adalah tempat penyimpanan data
•Proses dapat menempatkan data ke dalam data store atau mengambil / mendapatkan data store
•Setiap data store mempunyai nama yang unik
External Entity
• Simbol :
• External entity adalah di luar sistem, tetapi mereka merupakan salah satu bagian yang memberikan input data ke dalam sistem atau digunakan oleh output sistem
• Source : External entity yang memberikan input data ke dalam sistem
• Sinks : External entity yang menggunakan data sistem
Data Flow
• Simbol :   anak manah menunjukkan arah aliran
• Aliran data pada sistem :
  1. antara dua proses
  2. dari sebuah data store ke sebuah proses
  3. dari sebuah proses ke sebuah data store
  4. dari sebuah source ke sebuah proses
  5. dari sebuah proses ke sebuah sink

 

Fundamental Software Design Concepts

•Abstraction – allows designers to focus on solving a problem without being concerned about irrelevant lower level details

1. Procedural abstraction = named      sequence of events

2. Data abstraction = named collection of   data objects

3. Control abstraction = program control   mechanism without specifying internal details

•Refinement = process of elaboration where the designer provides successively more detail for each design component
•Modularity = the degree to which software can be understood by examining the components independently of one another
•Software architecture = Hierarchical structure of program components (modules)
•Control hierarchy or program structure = represents the module organization and implies hierarchy of control (does not represent the procedural aspects of the software )
•Structrual partitioning
  1.   Horizontal partitioning defines three partitions (input, data transformations, and output)
  2. Vertical partitioning (factoring) distributes control in a top-down manner (control decisions in top level modules and processing work in the lower level modules)
•Data structure = representation of the logical relationship among individual data elements
• Software procedure = precise specification of processing (event sequences, decision points, repetitive operations, data organization/structure)
•Information hiding = information (data and procedure) contained within a module is inaccessible to modules that have no need for such information

3. Analysis Concepts and Principles

Overview

•After system engineering is completed, software engineers need to look at the role of software in the proposed system.
•Software requirements analysis is necessary to avoid creating a software product that fails to meet the customer’s needs.
•Data, functional, and behavioral requirements are elicited from the customer and refined to create a specification that can be used to design the system.
•Software requirements work products must be reviewed for clarity, completeness, and consistency
Requirements Analysis
•Software engineering task that bridges the gap between system level requirements engineering and software design
•Provides software designer with a representation of system information, function, and behavior that can be translated to data, architectural, and component-level designs.
•Expect to do a little bit of design during analysis and a little bit of analysis during design
Software Requirements Analysis Phases (analisis persyaratan)
• Problem recognition
• Evaluation and synthesis (focus is on   what not how)
• Modeling (data flow and control)
• Specification (inherent from modelling)
• Review
Communication Technic
•Analisis persyaratan PL selalu dimulai dengan komunikasi antara 2 bagian atau lebih
•Seorang pelanggan memiliki masalah yang dapat dipertanggungjawabkan melalui pemecahan berbasis komputer
•Pengembang merespon masalah dari pelanggan
•Komunikasi dimulai
1. Mengawali proses
•Teknik analisis yang paling umum digunakan untuk menjembatani jurang komunikasi antara pelanggan dan pengembang-> pertemuan/wawancara
•Biasanya kedua pihak ini tidak tahu harus mulai dari mana, keduanya ingin pertemuan itu segera berakhir dan pada saat yang sama keduanya ingin berhasil
Pertanyaan2 yang biasa ditanyakan seorang analis
•Siapa dibalik permintaan untuk pekerjaan ini?
•Siapa yang akan menggunakan pemecahan ini?
•Apa keuntungan ekonomi dari pemecahan yang berhasil?
•Apakah ada sumber lain untuk pemecahan yang anda inginkan?

Pertanyaan lanjutan yang bisa ditanyakan?

•Bagaimana anda akan menandai output yang baik yang akan didapatkan oleh pemecahan yang berhasil?
•Masalah apakah yang akan diselesaikan oleh pemecahan ini?
•Dapatkah anda memperlihatkna kepada saya (atau menjelaskan) lingkungan dimana pemecahan tersebut akan digunakan?
•Adakah masalah / batasan kinerja yang khusus yang akan mempengaruhi cara pemecahan tersebut?
2.Facilitated Action Specification Techniques (FAST)
•Meeting held at neutral site, attended by both software engineers and customers
•Rules established for preparation and participation
•Agenda suggested to cover important points and to allow brainstorming
•Meeting controlled by facilitator (customer, developer, or outsider)
•Definition mechanism (flip charts, stickers, electronic device, etc) is used
•Goal is to identify problem, propose elements of solution, negotiate different approaches, and specify a preliminary set of solution requirements
3. Quality Function Deployment (QFD) (penyebaran fungsi kualitas)
-Adalah teknik manajemen kualitas yang menerjemahkan kebutuhan pelanggan ke dalam persyaratan teknis bagi PL

QFD mengidentifikasi 3 tipe persyaratan:

•Persyaratan normal: sasaran dan tujuan dinyatakan bagi sebuah produk/sistem selama pertemuan dengan pelanggga. Contoh: tipe tampilan grafis yang diminta, fungsi sistem spesifik, dan tingkat kinerja yang didefinisikan
•Persyaratan yang diharapkan: persyaratan ini implisit terhadap produk/sistem dan sangat fundamental sehingga pelanggan tidak menyatakannya secara eksplisit. Contoh: reabilitas dan kebenaran operasional keseluruhan, mudahnya instalasi PL dll
•Exciting requirement: persyaratan ini sangat diharapkan oleh pelanggan dan terbukti sangat memuaskan. Contoh: PL pengolah kata dengan fitur standar. Produk yang disampaikan berisi sejumlah kemampuan layout halaman yang bagus dan tidak terduga.
Use-Cases
•Scenarios that describe how the product will be used in specific situations
•Written narratives that describe the role of an actor (user or device) as interaction with the system occurs
•Use-cases are designed from the actor’s point of view
•Not all actors can be identified during the first iteration of requirements elicitation, but it is important to identify the primary actors before developing the use-cases
Analysis Principles
•The information domain of the problem must be represented and understood
•The functions that the software performs must be defined
•Software behavior must be represented
•Modles depicting information, function, and behavior must be partitioned in a hierarchical manner that uncovers detail
•The analysis process should move from the essential information toward implementation detail

2. Project Management Concept (Konsep Management Proyek)

Pendahuluan

•Project management involves the planning, monitoring, and control of people, process, and events that occur during software development.
•Everyone manages, but the scope of each person’s management activities varies according their role in the project.
•Software needs to be managed because it is a complex undertaking(ush) with a long duration time.
•Managers must focus on the four P’s to be successful (people, product, process, and project).
•A project plan is a document that defines the four P’s in such a way as to ensure a cost effective, and high quality software product.
•The only way to be sure that a project plan worked correctly is by observing that a high quality product was delivered on time and under budget.

Management Spectrum

•People (recruiting, selection, performance management, training, compensation, career development, organization, work design, team/culture development)
•Product (product objectives, scope, alternative solutions, constraint tradeoffs)
•Process (framework activities populated with tasks, milestones, work products, and quality assurance points)
•Project (planning, monitoring, controlling)
People
•Players (senior managers, technical managers, practitioners, customer, end users)
•Team leadership model (motivation, organization, ideas/innovation)
•Characteristics of effective project managers (problem solving, managerial identity, achievement, influence and team building)
Software Team (Software Team Organizaton)

  Struktur tim “terbaik” tergantung pada gaya manajemen sebuah organisasi, jumlah orang yang akan ada dalam tim tersebut, tingkat ketrampilannya serta kesulitan masalah secara keseluruhan. Mantei mengusulkan 3 organisasi yang umum:

•Democratic decentralized (DD): (rotating task coordinator (tidak ada pemimpin yang permanen) and group consensus (keputusan thd masalah dan pendekatan yang dilakuakan dibuat oleh konsensus kelompok))àkomunikasi anggota tim bersifat horisontal

•Controlled decentralized (permanent leader, group problem solving, subgroup implementation of solutions)à komunikasi antar kelompok dan orang bersifat horizontal, namun komunikasi vertikal sepanjang hierarki kontrol juga terjadi disini
•Controlled centralized (top level problem solving and internal coordination managed by team leader)
Factors Affecting Team Organization
•Difficulty of problem to be solved
•Size of resulting problem
•Team lifetime
•Degree to which problem can be modularized
•Required quality and reliability(andal&dipercaya) of the system to be built
•Rigidity of the delivery date (kepastian tanggal penyampaian)
•Degree of communication required for the project
Coordination and Communication Issues (masalah koordinasi dan komunikasi): Kraul dan Streeter menguji sekumpulan teknik koordinasi proyek yang dikatergorikan dalam kelompok:
•Formal, impersonal approaches (e.g. documents, milestones, memos)
•Formal interpersonal approaches (e.g. review meetings:menyangkut pertemuan status pengkajian serta  perancangan, inspections)
•Informal interpersonal approaches (e.g. information meetings, problem solving)
•Electronic communication (e.g. e-mail, bulletin boards, video conferencing)
•Interpersonal network (e.g. informal discussion with people other than project team member)