Anda di halaman 1dari 53

REKAYASA PERANGKAT LUNAK (RPL)

Teknik Informatika STIKOM Artha Buana Kupang 2013

SATUAN ACARA PERKULIAHAN


1.
2. 3. 4.

Produk dan Proses Perangkat Lunak Analisis Kebutuhan Perangkat Lunak Design Perangkat Lunak 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 : projekprojek 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 isnt manufactured like a personal computer Software doesnt wear out Most software is custom-built, rather than being assembled from existing components

Lifetime of Software

The Software Crisis

Worse, this isnt really changing software productivity has improved 6% per year (on average over 30 years) Unlike Hardware Moores law: processor speed/memory capacity doubles every two years
Hardware Productivity

Software Time (10 years)

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
- Telekomunikasi - Industri, dll

- Medis
- Hiburan

PROSES PERANGKAT LUNAK


Layer Rekayasa Perangkat Lunak Fase Generik Rekayasa Perangkat Lunak

Model-model Proses Perangkat Lunak

A Layered Technology
Software Engineering Software Engineering
tools

methods
life-cycle model / process a quality focus
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 RPL


1.

2.

3.

4.

Definition (what): Establish what the system requirements are Use system engineering, project planning, requirements analysis Development (how): Establish how the system is to be realized designed and built Use software design, code generation, testing Support: (change) Handle changes as the software environment evolves Four flavours: correction, adaptation, enhancement, prevention 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 project Makes initial decision on political and technical feasibility of the project Requirements Analysis High 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 Implementation Writing or generating the code to build the system Component Testing Testing 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 Delivery
Implementation

of the system into the working environment and replacement of the existing system

Maintenance
Corrective Adaptive Perfective

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


Build first version Modify until client is satisfied Maintenance

Retirement

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

MODEL WATERFALL (1)


Project Definition Requirements Analysis Design

Program Implementation Component Testing Integration Testing System Testing System Delivery Maintenance

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


Requirements

Specification
Design Implementation Integration Maintenance

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

MODEL PROTOTIPE (1)


Listen to Customer Build/Revise Mock-up

Customer test-drives mock-up

MODEL PROTOTIPE (2)


Specifying requirements is

often very difficult Users dont 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)


Team 1
Business modelling

Team 2
Business
modelling

Team 3
Business modelling Data modelling Data modelling Process modelling Application Application generation Testing and turnover Testing and turnover Testing and turnover

Data modelling

Process modelling

Process modelling

Application generation

generation

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)


1st Increment
analysis design coding testing delivery

2nd Increment
analysis Project Definition analysis design design coding testing delivery

3rd Increment
coding testing delivery

4th Increment
analysis design coding testing delivery

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


Analysis Design Code Integrate Build 1 Integrate Build 2

Analysis

Design

Code

Build n

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

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 expensive Few developers have necessary skills, so extensive training required Difficult 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 Practitioners Approach, McGraw Hill Companies.

PUSTAKA (2)

Shari Lawrence Peleeger, 2001, Software Engineering Theory and Practice,Prentice Hall Inc.
Sumber-sumber lain dari internet