bab1 rpl

8/2/2019 BAB1 RPL

http://slidepdf.com/reader/full/bab1-rpl 1/23

Software Engineering/Rekayasaperangkat Lunak

•RPL adalah Ilmu dan Seni yang signifikan

dalam membangun Sebuah System Perangkat

Lunak, Yang diharapkan dari RPL :

1) on time (Tepat Waktu)

2) on budget (Tepat Budget)

3) with acceptable performance4) with correct operation.

8/2/2019 BAB1 RPL


Software Engineering

The economies of all developed nations aredependent on software.

More and more systems are softwarecontrolled.Semakin banyak sistem yang tergantung kepda perangkat

lunak

Software engineering is concerned with theories,methods and tools for professional softwaredevelopment. Rekayasa perangkat lunak adalah concern dengan

metode dan tool untuk pengembangan perangkat lunak secara profesional

Software engineering expenditure represents asignificant fraction of the GNP of developedcountries.

8/2/2019 BAB1 RPL


Software Costs Software costs often dominate system costs. The

costs of software on a PC are often greater than thehardware cost. Biaya Perangkat lunak sering mendominasi biaya sistem.

Software costs more to maintain than it does todevelop. Biaya software tidak hanya untuk membuat tetapi juga untuk

perawatan.

Software engineering is concerned with cost-effectivesoftware development. Rekayasa perangkat lunak konsen dengan efektifitas biaya pada

saat pembengunan perangkat lunak

8/2/2019 BAB1 RPL


Software Products Generic products: (Buat 1 untuk semua)

Stand-alone systems which are produced by adevelopment organization and sold on the openmarket to any customer.

Customized products: (Buat 1 untuk 1)

Systems which are commissioned by a specificcustomer and developed specially by somecontractor.

8/2/2019 BAB1 RPL


Software Product Attributes Maintainability

Dependability

Efficiency

Usability

8/2/2019 BAB1 RPL


Importance of Product Characteristics

The relative importance of these characteristicsdepends on the product and the environment inwhich it is to be used.

In some cases, some attributes may dominate

In safety-critical real-time systems, key attributesmay be dependability and efficiency.

Costs tend to rise exponentially if very high levelsof any one attribute are required.

8/2/2019 BAB1 RPL


Efficiency Costs

Cost

Efficiency

8/2/2019 BAB1 RPL


The Software Process Structured set of activities required to develop a

software system Satu Set Aktivitas yang dilakukan pada saat mengembangkan

perangkat lunak Specification

Design Validation

Evolution

Activities vary depending on the organizationand the type of system being developed.

Aktivitas bervariasi tergantung organisasi dan tipe sistemyang dikembangkan

Must be explicitly modeled if it is to bemanaged. Secara eksplisit harus dibuat model agar bisa dimanage

8/2/2019 BAB1 RPL


Engineering Process Model Specification: Set out the requirements and

constraints on the system.

Design: Produce a model of the system.

Manufacture: Build the system.

Test: Check the system meets the requiredspecifications.

Install: Deliver the system to the customer andensure it is operational.

Maintain: Repair faults in the system as theyare discovered.

8/2/2019 BAB1 RPL


Software Engineering is Different

Normally, specifications are incomplete.

Very blurred distinction between specification,design and manufacture.

No physical realization of the system for testing.

Software does not wear out - maintenancedoes not mean component replacement.

8/2/2019 BAB1 RPL


Generic Software Process Models

Waterfall Separate and distinct phases of specification and

development

Evolutionary

Specification and development are interleaved

Formal Transformation

A mathematical system model is formallytransformed to an implementation

Reuse-based

The system is assembled from existing components

8/2/2019 BAB1 RPL


Waterfall Process Model

Requirementsdefinition

System andsoftware design

Implementationand unit testing

Integration and

system testing

Operation andmaintenance

8/2/2019 BAB1 RPL


Evolutionary Process Model

ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outline

description

Concurr entactivities

8/2/2019 BAB1 RPL


Process Model Problems Waterfall

High risk for new systems because of specification anddesign problems.

Low risk for well-understood developments usingfamiliar

technology. Prototyping

Low risk for new applications because specification andprogram stay in step.

High risk because of lack of process visibility.

Transformational High risk because of need for advanced technology and

staff skills.

8/2/2019 BAB1 RPL


Hybrid Process Models Large systems are usually made up of several

sub-systems.

The same process model need not be used forall subsystems.

Prototyping for high-risk specifications.

Waterfall model for well-understooddevelopments.

8/2/2019 BAB1 RPL


Spiral Process Model

Risk analysis

Risk analysis

Risk analysis

Risk analysis Proto-

type 1

Prototype 2Prototype 3

Opera-

tionalprotoype

Concept of Operation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

Code

Unit tes t

IntegrationtestAcceptance

testService Develop, verifynext-level p roduct

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW

8/2/2019 BAB1 RPL


Spiral Model Advantages

Focuses attention on reuse options. Focuses attention on early error elimination.

Puts quality objectives up front.

Integrates development and maintenance. Provides a framework for hardware/software

development.

8/2/2019 BAB1 RPL


Spiral Model Problems

Contractual development often specifiesprocess model and deliverables in advance.

Requires risk assessment expertise.

8/2/2019 BAB1 RPL


Process Visibility

Software systems are intangible so managersneed documents to assess progress.

Waterfall model is still the most widely usedmodel.

8/2/2019 BAB1 RPL


Waterfall Model Documents

Activity Output documents

Requirements analysis Feasibility study, Outline requirements

Requirements definition Requirements document

System specification Functional specification, Acceptance test plan

Draft user manualArchitectural design Architectural specification, System test plan

Interface design Interface specification, Integration test plan

Detailed design Design specification, Unit test plan

Coding Program code

Unit testing Unit test report

Module testing Module test report

Integration testing Integration test report, Final user manual

System testing System test report

Acceptance testing Final system plus documentation

8/2/2019 BAB1 RPL


Process Model Visibility

Proces s model Proces s visibility

Waterfall model Good visibility, each activity produces somedeliverable

Evolutionary

development

Poor visibility, uneconomic to produce

documents during rapid iterationFormaltransformations

Good visibility, documents must be producedfrom each phase for the process to continue

Reuse-orienteddevelopment

Moderate visibility, it may be artificial toproduce documents describing reuse and

reusable components.Spiral model Good visibility, each segment and each ring

of the spiral should produce some document.

8/2/2019 BAB1 RPL


Professional Responsibility

Software engineers should not just be concernedwith technical considerations. They have widerethical, social and professional responsibilities.

No clear rights and wrongs about many of these

issues: Development of military systems

Whistle blowing

8/2/2019 BAB1 RPL


Ethical Issues

Confidentiality Competence

Intellectual property rights

Computer misuse