REKAYASA PERANGKAT LUNAK(RPL)

Teknik Informatika STIKOM Artha Buana Kupang2013

SATUAN ACARA PERKULIAHAN

1. Produk dan Proses Perangkat Lunak2. Analisis Kebutuhan Perangkat

Lunak3. Design Perangkat Lunak4. Pengujian Perangkat Lunak

+ Project

OUTLINE KULIAH MINGGU I

Pengertian RPL Mengapa RPL Tujuan RPL Produk Perangkat Lunak Proses Perangkat Lunak

PENGERTIAN RPL (1)

Rekayasa Perangkat Lunak adalah cabang computer science yang berhubungan dengan pembangunan sistem perangkat lunak yang besar dan kompleks, sehingga dibangun oleh suatu tim (Ghezzi).

Rekayasa perangkat lunak adalah ilmu yang membahas semua aspek produksi perangkat lunak (Sommerville).

PENGERTIAN RPL (2) Rekayasa Perangkat Lunak (IEEE) :

(1) aplikasi/penerapan dari pendekatan yang sistematis, disiplin dan terkuantifikasi untuk mengembangkan, menjalankan dan memelihara perangkat lunak

(2) studi mengenai pendekatan (1)

Rekayasa Perangkat Lunak (Fritz Baeur) :

pembentukan dan penggunaan prinsip-prinsip teknik untuk mendapatkan perangkat lunak yang ekonomis yang dapat bekerja secara efisien pada mesin real.

MENGAPA RPL ? (1)

Banyak projek-projek sukses tidak menggunakan RPL , contoh : projek-projek awal Microsoft

Tetapi sering projek tidak dapat diulang kembali.

MENGAPA RPL ? (2)

Lebih banyak lagi projek-projek yang gagal karena tidak menggunakan RPL. Kegagalan terjadi karena : Ukuran projek tidak sebanding dengan usaha/SDM Berhentinya personil kunci Gagal mengerti kebutuhan Projek yang dihasilkan tidak sesuai dengan kualitas Munculnya teknologi baru dll

MENGAPA RPL ? (3)

SOME STATISTICS : One in four systems miscarry 20% turnover in staff is not uncommon Large systems take 3 to 5 years to develop Corporations are spending up to 20% of revenue

on Information Technology Y2K problem took up to 50% of resources in at

least one bank in Australia. Many of the systems were built in the 1980s

Kegagalan Investasi IS/IT

Kegagalan Investasi SI/TI Case Study : LAMP Project

In March 1997 the state of Washington killed the biggest IT project in its history, the License Application Mitigation Project (LAMP), aimed at automating the state's vehicle registration and license renewal processes.

The project began in the early nineties and was supposed to be online in 1995.

Initially budgeted at $ 16 M the project cost climbed to $ 41.8 M in 1992, $51 M in

1993 and was last estimated (March 1997) at $67.5 M of which $40 M had been spent without result.

MENGAPA RPL ? (4)

Krisis Perangkat Lunak , menyebabkan:

keterlambatan penyelesaian proyek PL

biaya mahal

kualitas tidak terpenuhi

Sehingga dikembangkan

teknik/metode pengembangan

perangkat lunak

TUJUAN RPL

memberi kerangka kerja untuk membangun perangkat lunak yang berkualitas tinggi

PRODUK DAN PROSES

Keduanya adalah aspek penting dalam RPL

Kita harus mampu menghasilkan produk software yang berkualitas untuk customer melalui proses yang konsisten, terkelola dengan baik dan cost-effective

PRODUK PERANGKAT LUNAK

Definisi Perangkat Lunak Komputer

Karakteristik Perangkat Lunak

Peranan Perangkat Lunak

DEFINISI PERANGKAT LUNAK

1. Instruksi-instruksi (program komputer) yang memberikan fungsi dan unjuk kerja yang diinginkan jika dieksekusi

2. Struktur data yang memungkinkan program memanipulasi informasi

3. Informasi deskriptif baik dalam bentuk hardcopy atau virtual yang menjelaskan operasi dan kegunaan program

KARAKTERISTIK PERANGKAT LUNAK

Tidak sama dengan produk hardware Software is developed or engineered, it isn’t

manufactured like a personal computerSoftware doesn’t wear out Most software is custom-built, rather than being

assembled from existing components

Lifetime of Software

The Software Crisis

Worse, this isn’t really changing software productivity has improved 6% per year (on average over

30 years) Unlike Hardware

Moore’s law: processor speed/memory capacity doubles every two years

Time (10 years)

“Productivity”

Software

Hardware

A GOOD SOFTWARE PRODUCT?

A software product should perform the required

function be reliable be maintainable be efficient have an appropriate user

interface

PERANAN PERANGKAT LUNAK

Perangkat lunak berperan hampir dalam setiap

aspek kehidupan :

- Transportasi - Bisnis

- Pendidikan - Medis

- Telekomunikasi - Hiburan

- Industri, dll

PROSES PERANGKAT LUNAK

Layer Rekayasa Perangkat Lunak

Fase Generik Rekayasa Perangkat Lunak

Model-model Proses Perangkat Lunak

Software Engineering Software Engineering

a “quality” focus

life-cycle model / process

methods

tools

A Layered Technology

Focus: the underlying philosophy. High quality means project timeliness because of less debugging and rework

Model: structured sequence of high-level tasks Methods: technical tasks for building software Tools: automated or semi-automated support (CASE)

FASE GENERIK RPL1. Definition (“what”):

Establish what the system requirements are Use system engineering, project planning, requirements analysis

2. Development (“how”): Establish how the system is to be realized – designed and built Use software design, code generation, testing

3. Support: (“change”) Handle changes as the software environment evolves Four flavours: correction, adaptation, enhancement, prevention

4. Umbrella Activities: Ongoing across every phase Project management, risk management, etc.

FASE GENERIK (PRESSMAN)

Communication Planning Modelling Construction Deployment

Steps in a Generic Software Process

Project Definition Requirements Analysis Design Program Implementation Component Testing Integration Testing System Testing System Delivery Maintenance

Process Activities (1) Project Definition

States the purpose of the projectMakes initial decision on political and technical feasibility of the project

Requirements AnalysisHigh level definition of the functionality of the system, primarily from

the point of view of the users Design

Looks at the software requirements of the system and the architecture of the system

Lower level design activities - data structures, interface representations, procedural (algorithmic) details

Process Activities (2)

Program ImplementationWriting or generating the code to build the system

Component TestingTesting of the individual components while they are being built and

after they have been completed Integration Testing

Testing of the way individual components fit together System Testing

Testing of the whole system usually in concert with the users (acceptance testing)

Process Activities (3)

System DeliveryImplementation of the system into the working

environment and replacement of the existing system Maintenance

CorrectiveAdaptivePerfective

MODEL PROSES PL (1)

Model proses atau disebut paradigma RPL adalah strategi pengembangan yang meliputi proses, metode, tool dari fase generik

Model dipilih berdasarkan :

sifat dari projek atau aplikasi

metode dan tool yang digunakan

deliverables yang dibutuhkan

pengalaman tim projek

MODEL PROSES PL (2) Model Build and Fix

Model Waterfall

Model Modified Waterfall

Model Prototipe

Model RAD (Rapid Application Development)

Model Evolusioner

Component Based Development

Model Formal Methods

Extreme Programming

MODEL BUILD AND FIX

Chaos! No specification or design. Rework until the client is satisfied. Only works on small projects All changes are in coding phase (expensive) Not a realistic option

Build first version Modify

until client is satisfied

Maintenance

Retirement

MODEL WATERFALL (1)Project

Definition

System Delivery

Maintenance

Requirements Analysis

Design

Component Testing

Integration Testing

System Testing

Program Implementation

Adapted (in 1970) from conventional engineering cycle Broken into phases, customers and developers sign-off

documents at each phase, one-way trip Cannot return to fix problems in previous phases

MODEL WATERFALL (2)

Most widely used, though no longer state-of-the-art Each step results in documentation May be suitable for well-understood developments using

familiar technology Not suited to new, different systems because of

specification uncertainty Difficulty in accommodating change after the process has

started Can accommodate iteration but indirectly Working version not available till late in process

MODIFIED WATERFALL MODEL

Well established and widely used Driven by text documents Needs up-front requirements Customers only see the product at the end

Requirements

Specification

Implementation

Integration

Design

Maintenance

MODEL PROTOTIPE (1)

Listen to Customer

Build/ReviseMock-up

Customertest-drivesmock-up

MODEL PROTOTIPE (2)

Specifying requirements is often very difficult Users don’t know exactly what they want until they

see it Prototyping involves building a mock-up of the

system and using to obtain for user feedback Ideally mock-up serves as mechanism for identifying

requirements

MODEL RAD (1)

Business

modelling

Data modelling

Process modelling

Application

generation

Testing and turnover

Business

modelling

Data modelling

Process modelling

Application

generation

Testing and turnover

Business

modelling

Data modelling

Process modelling

Application

generation

Testing and

turnover

Team 1 Team 2 Team 3

MODEL RAD (2)

Similar to waterfall but uses a very short development cycle (60 to 90 days to completion)

Uses component-based construction and emphasises reuse and code generation

Use multiple teams on scaleable projects Requires heavy resources Requires developers and customers who are heavily

committed Difficult to use with new technology

MODEL EVOLUSIONER (1)

Pada sistem yang kompleks, perangkat lunak

berkembang sepanjang suatu periode waktu.

Model evolusioner bersifat iterative, dimana

Software Engineer secara bertahap

mengembangkan software menjadi versi

yang lebih lengkap

MODEL EVOLUSIONER (2)

Model Incremental

Model Concurrent Development

Model Spiral

MODEL INCREMENTAL (1)

analysis deliverydesign coding testing

analysis deliverydesign coding testing

analysis deliverydesign coding testing

analysis deliverydesign coding testing

1st Increment

2nd Increment

3rd Increment

4th Increment

Project Definition

MODEL INCREMENTAL (2)

Applies an iterative philosophy from prototyping model to the waterfall model

Divide functionality of system into increments and use a linear sequence of development on each increment

First increment delivered is usually the core product, i.e only basic functionality

Reviews of each increment impact on design of later increments

Manages risk well

MODEL CONCURRENT DEVELOPMENT

Deliver increasing functionality at each build (usually n = 5..20)

First build is the core Get partial functionality early Allows specialisation (e.g. full time designers) Not as well proven

Analysis Design Code Integrate Build 1

Analysis Design Code Integrate Build 2

Build n

MODEL SPIRAL (1)

MODEL SPIRAL (2)

Incremental releases early releases may be paper or prototypes later releases become more complicated

Models software until it is no longer used Emphasises Identifying and managing risks Is a realistic approach to the problems of large scale

software development Can use prototyping during any phase in the evolution of

product

COMPONENT BASED DEVELOPMENT (1)

COMPONENT BASED DEVELOPMENT (2)

berhubungan dengan banyak karakteristik dari

model spiral

menggunakan teknologi Objek oriented

MODEL METODE FORMAL Use of mathematical techniques to specify the requirements

of the system e.g the B method, Z, VDM, Object-Z Mainly used in life or mission-critical applications, e.g NASA Attacks ambiguity, incompleteness and inconsistency;

allows formal verification Can get very high quality software Problems

Time-consuming and expensiveFew developers have necessary skills, so extensive training

requiredDifficult to use as a tool to communicate with users

EXTREME PROGRAMMING (1)

Merupakan salah satu agile development process (lainnya : Scrum, Adaptive Software Development, Crystal) diperkenalkan oleh Kent Beck pada tahun 1999.

Merupakan model iteratif yang kontroversial dengan fitur unik (e.g. pair programming)Works well for vague requirements Unproven, only really good for small projects

EXTREME PROGRAMMING (2) Beberapa fitur dari XP :

Small releases from smallest feature Simple Design use the simplest possible design Testing – tests are written first, by both programmers and customer Refactoring refactor duplicate code Pair programming 2 programmers Collective ownership no single person owns a module Continuous integration 40-hour week programmers go home on time On-site customer access a real live customer Coding standards The Planning Game user story & effort Metaphor each project has an organizing metaphor

TUGAS KELOMPOK

Buatlah sebuah rangkuman yang menggambarkan masing-masing model proses serta kelebihan dan kekurangan masing-masing model termasuk beberapa model Agile Development Process terbaru.

PUSTAKA (1)

Carlo Ghezzy, Mehdi Jazayeri & Dino Mandrioli, 2003, Fundamentals of Software Engineering, Pearson Education Inc.

Ian Sommerville, 2001, Software Engineering, 6th edition, Pearson Education Inc.

Roger S. Pressman, 2010, Software Engineering : A Practitioner’s Approach, McGraw Hill Companies.

PUSTAKA (2)

Shari Lawrence Peleeger, 2001, Software Engineering Theory and Practice,Prentice Hall Inc.

Sumber-sumber lain dari internet