if 1483 - rpl teknik informatika upn “veteran” yk rekayasa perangkat lunak (if 1483) pertemuan...

IF 1483 - RPL TEKNIK INFORMATIKAUPN “VETERAN” YK

REKAYASA PERANGKAT LUNAK

(IF 1483)

Pertemuan 11 Prototipe, Implementasi dan Testing


Deskripsi Menjelaskan implementasi PL dan

merealisasikan PL yang didisain


Tujuan Instruksional Umum (TIU) Mahasiswa mampu merealisasikan disain

menjadi perangkat lunak


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”


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


Siklus Hidup PrototypingFull System Prototype Life Cycle

Analyze & Gather

Requirements

Design

Build Prototype

Evaluate &Refine

Requirements

Engineer productto ensure

completion


Konsep Siklus Hidup PrototipeConcept Prototype Life Cycle

Analysis

Design

DevelopPrototype

Evaluate & RefineRequirements

FeasibilityAnalysis

Analysis

Design

Program/Unit Test

Test

Implement

Prototype Activities


Parsial System Prototype

Analysis

Design

Program/Unit Test

ImplementPrototype

FeasibilityAnalysis

Analysis

Design

Program/Unit Test

Test

Implement

Prototype Development


“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]


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


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


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


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


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


Faktor Kualitas Perangkat LunakSoftware Quality Factors Correctness Reliability Efficiency Integrity Usability Maintainability

Flexibility Testability Portability Reusability Interoperability


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


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?


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]


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


Alur Informasi TestTest Information Flow

Testing

Evaluation

ReliabilityModel

Debug

Softwareconfiguration

Testconfiguration

Testresults

Expectedresults

Errorrate data

Corrections

Predictedreliability

Errors


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


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


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


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


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


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


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


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


Ringkasan Materi Prototyping dan tipe prototype Implementasi Testing


Tugas Melakukan coding terhadap disain yang

telah dibuat


ReferensiSoftware Engineering: A Practitioner's Approach (Bab 16, 17,22)

Pengarang : Roger S. Pressman Penerbit: Fourth Edition, McGraw-Hill, 1997

if 1483 - rpl teknik informatika upn “veteran” yk rekayasa perangkat lunak (if 1483) pertemuan...

Documents