IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
REKAYASA PERANGKAT LUNAK
(IF 1483)
Pertemuan 11 Prototipe, Implementasi dan Testing
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Deskripsi Menjelaskan implementasi PL dan
merealisasikan PL yang didisain
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Tujuan Instruksional Umum (TIU) Mahasiswa mampu merealisasikan disain
menjadi perangkat lunak
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Prototyping Definisi
HistoryMembuktikan kegunaan teknologi baru
Proving usefulness of new technologiesMenghindari dokumentasi yang terlalu banyak
pada siklus hidup sekuensial tradisional Circumvent the overload of documentation in traditional sequential life cycle
“Development of a system or system component in a short period of time without formal written specifications”
“ Pengembangan sistem/komponen sistem dalam periode yang pendek tanpa menggunakan spesifikasi yang formal”
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Tipe2 dari Prototyping Model
Human-Machine Interaction Working prototype with subset of functionality Existing application that performs part of desired
functions, but with improvements noted Beneficial Uses
Complete iterative development of an application when requirements are not well-understood
Proof of concept for technology Rapid development of subsystem to ease critical
work situation
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Siklus Hidup PrototypingFull System Prototype Life Cycle
Analyze & Gather
Requirements
Design
Build Prototype
Evaluate &Refine
Requirements
Engineer productto ensure
completion
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Konsep Siklus Hidup PrototipeConcept Prototype Life Cycle
Analysis
Design
DevelopPrototype
Evaluate & RefineRequirements
FeasibilityAnalysis
Analysis
Design
Program/Unit Test
Test
Implement
Prototype Activities
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Parsial System Prototype
Analysis
Design
Program/Unit Test
ImplementPrototype
FeasibilityAnalysis
Analysis
Design
Program/Unit Test
Test
Implement
Prototype Development
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
“Plan to Throw One Away”“In most projects, the first system built is barely usable. It may be too slow,
too big, awkward to use, or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved. The discard and re-design may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done. Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.
The management question, therefore is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. Seen this way, the answer is much clearer. Delivering that throwaway to customers buys time, but is does so only at the cost of agony for the user, distraction for the builders while they do the redesign, and a bad reputation for the product that the best redesign will find hard to live down.
Hence, plan to throw one away; you will, anyhow.
[Brooks, The Mythical Man-Month: Essays on Software Engineering]
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Langkah2 PrototypingSoftware Prototyping Steps
Step 1: Evaluate whether the software to be developed is a good candidate for prototyping
Step 2: Analyst develops an abbreviated representation of the requirements
Step 3: After requirements model review, create abbreviated design specification
Step 4: Create, test, and refine prototype Step 5: Prototype presented to and tested
by customer Step 6: Iterate steps 4 and 5
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Prototyping Problema
Misuse to circumvent analysis & design Failure to complete prototype as proper application Customer misinterpretation of working system Developed with implementation compromises
Current/Future Use High-level programming languages used as proof of
concept or to discuss requirements Validate designs
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Implementasi Aktivitas Biasa (Natural activities)
Coding / pengkodean Integrasi modul-modul Testing / pengetesan
Aktivitas yang sering dilupakan Forgotten activities
Deployment / penyebaran Konvers Data & program Dokumentasi pengguna dan pelatihan
User documentation & training
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Perencanaa Implementasi Implementation Planning
Keputusan (Decisions) Bahasa Pemrograman Programming Language Sistem manajemen basisdata
Database management system LIngkungan Pengembangan
Development Environment Jadwal Implementasi Implementation Schedule
Estimation techniques Transisi menuju pemeliharaan
Transition to maintenance
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Teknik Estimasi Perangkat LunakSoftware Estimation Techniques
Method Advantages DisadvantagesAlgorithmic Objective formula
Calibrated to experience Does not accommodate exceptions Assumes history predicts future
ExpertJudgement
Additional factors into judgement Quality of expertise Biases, incomplete recall
Analogy Based upon experience Related experiences Biases, incomplete recall
Parkinson Might relate to experience Reinforces poor practice
Price to Win Often wins contract Produces large overruns Misrepresentation
Top-Down System level focus Efficient use of resources
Less detailed and stable Overlooks technical complexity
Bottom-Up More detailed basis Fosters individual commitment
May overlook system complexity Requires more effort
FunctionPoints
Objective, repeatable inputs Based on history Must be calibrated
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Faktor Kualitas Perangkat LunakSoftware Quality Factors Correctness Reliability Efficiency Integrity Usability Maintainability
Flexibility Testability Portability Reusability Interoperability
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Penjaminan Mutu Perangkat LunakSoftware Quality Assurance
Verification & Validation Are building the product right? Are we building the right product?
QualityStandards
andProcedures
SoftwareEngineering
Methods
Software configurationmanagement
Testing
Measurement
Formaltechnicalreviews
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Testing Definisi
Proses mencari kesalahan Process of finding errors Review akhir dari specifikasi, disain & pengkodean
Tujuan Purpose Menjamin seluruh elemen dalam aplikasi bekerja
dengan baik, sesuai dengan yang diharapkan dan memenuhi kriteria performance
Tipe-tipe kesalahan Types of Errors Kenapa sangat susah ? Why is it so difficult?
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Aturan Dasar TestingTesting Ground Rules
Tujuan Testing is the process of executing a program
with the intent of finding errors A good test case is one that has a high probability
of finding an error A successful test is one that uncovers an error
Kepentingan
“The development of software systems involves a series of production activities where opportunities for injection of human fallibilities are enormous…Because of human inability to perform and communicate with perfection, software development is accompanied by a quality assurance activity.” [Deutsch]
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Ground Rules (continued) Manfaat (Benefits)
Uncover errors in software Demonstrates that software functions appear to be
working according to specification Demonstrate performance requirements have been
met Provide indication of software reliability and quality
However, testing cannot show the absence of defects
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Alur Informasi TestTest Information Flow
Testing
Evaluation
ReliabilityModel
Debug
Softwareconfiguration
Testconfiguration
Testresults
Expectedresults
Errorrate data
Corrections
Predictedreliability
Errors
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Strategi Logika TestingLogic Testing Strategies
Kotak Hitam Black Box Equivalence partitioning Boundary value analysis Error guessing Cause-effect graphing
Kotak Putih White Box Logic tests Mathematical proofs Cleanroom testing
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Strategi Proses TestingProcess Testing Strategies
Top Down Underlying principle
main logic of application needs more testing than supporting logic
Early comparison of application & requirements
Requires scaffolding Quality of software
should be improved by iterative nature of testing
Easily support testing of human interface
Top Down (continued) Works well with
prototyping/iterative development
Bottom Up Underlying principle
Any change to a module can affect its functioning
All modules are coded and tested individually
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Perbandingan Strategi TestComparison of Test Strategies
Test Strategy Method Goal Disadvantages
White-Box Logic Proveprocessing
Functional flaws, datasensitive conditions, &errors across modulesdifficult to test
Black-Box Data Prove results Type 2 errors & logicproblems difficult to find
Top-Down Incremental Exercise criticalcode to improvereliability
Scaffolding takes timeConstant change mayintroduce new errors
Bottom-Up All ornothing
Perfect parts;If parts work,whole shouldwork
Functional flaws foundlate cause delaysErrors across modulesdifficult to trace and find
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Petunjuk Unit TestingUnit Testing Guidelines
Primary Goals Conformance to specifications
Determine extent to which processing logic satisfies the functions assigned to the module
Logical and operational requirements taken from specifications
Processing accuracy Input Process Output
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Petunjuk Tes Integrasi Integration Testing Guidelines Primary goals
Compatibility Calling of modules in an operational environment Verify that all modules are called correctly, do not
cause abnormal ends Inter-module processing accuracy
Check that data transfers between modules operate as intended within constraints
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
System & QA Testing Guidelines
Verify the interacting modules: Fulfill the user’s functional requirements Human interface works as intended All processing is within constraints All modules are compatible, and upon failure
degrade gracefully Has sufficient procedures to provide disaster
recovery All operations procedures for the system are
useful and complete
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Developing QA & System Test Step 1: List all actions,
functions, and transactions to be tested
Step 2: Design transactions to test all actions, functions and transactions
Step 3: Develop a single-user test script for above
Step 4: Interleave the tests across the users participating in the test to fully test multi-user functioning of the application
Step 5: Develop test scripts for each user
Step 6: Conduct the test Step 7: Review test results an
reconcile anomalous findings Step 8: After completion,
compile minimum set of transactions into regression test package
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Petunjuk Test CaseTest Case Guidelines
Developed to verify that specific requirements or design are satisfied
Each component must be tested with at least two test cases: success and failure
All modules should be deliberately failed at least once to verify degradation
To ensure comprehensiveness, use methodical approach to identify logic paths or system components
Real data should be used to reality test the modules after successful test data is used
Test cases can be used to test multiple requirements
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Ringkasan Materi Prototyping dan tipe prototype Implementasi Testing
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Tugas Melakukan coding terhadap disain yang
telah dibuat
IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
ReferensiSoftware Engineering: A Practitioner's Approach (Bab 16, 17,22)
Pengarang : Roger S. Pressman Penerbit: Fourth Edition, McGraw-Hill, 1997