P14 Software Re-Engineering

P14 Software Re-Engineering

A. Sidiq P. Prodi Teknik Informatika & Prodi Sistem Informasi Fakultas Teknologi Informasi Universitas Mercu Buana Yogyakarta

Software Engineering

SQ - http://sidiq.mercubuana-yogya.ac.id

[email protected]

Software Engineering ●

Th 70 an – 80 an → hanya memperhatikan technical aspect


[email protected]

Technical & Non Technical Aspect ●

●

Technical Aspect –

Coding

–

Testing

–

Configure

Non Technical Aspect –

Bussiness Process

–

Social (bunch people)


[email protected]

Pengadaan Software ●

Buy/Get Free –

Available

–

Time

–

Cost

–

Skill

●

Build –

Dengan SE → untuk sesuatu yg complex (subjective)

–

Tanpa SE → berawal dari software yg sederhana ●

Walau 1/3 tidak menggunakan SE, tetapi secara implisit menggunakan proses tersebut (coding, testing, run)


[email protected]

Jadi, sebenarnya kita memakai atau tidak memakai SE tergantung dari berapa (dari 100%) kompleksitas dari software yang akan kita bangun. SQ - http://sidiq.mercubuana-yogya.ac.id

[email protected]

Tendensi saat ini lebih ke konsumtif, karena itu beberapa permasalahan rela merubah proses bisnis menyesuaikan ke software


[email protected]

Software ???

●

Technical Knowledge → pengetahuan berkaitan dengan teknis

●

Requirement → persyaratan yang diperlukan untuk membangun PL

●

Design constraint → batasan PL dimana akan dirancang dan diimplementasikan Suatu Software mutlak membutuhkan Requirement dan Design Contraint SQ - http://sidiq.mercubuana-yogya.ac.id

[email protected]

Requirement ●

Non functional –

Menekankan pada aspek-aspek di luar functional software tersebut (software behavior) ● ● ●

●

Performa (kemampuan) Scalability (kemampuan diakses) Maintainability (menambahkan fitur baru)

Functional –

Fungsi-fungsi yang dilakukan untuk software tersebut (Masukan, Keluaran, Batasan) SQ - http://sidiq.mercubuana-yogya.ac.id

[email protected]

Design ●

Design Contraint –

Kapan kita bisa memilih komponenkomponen pada design contraint tergantung pada :

●

Design Decision –

Programming Language

–

Algorithms

–

Frameworks*

–

Architecture


[email protected] 10

Technical Knowledge



Software Engineering Layer (Pressman, 2010)



Software Re-Engineering



Software Re-Engineering



Software Crisis Background



●

●

●

Increasing complex system (sistem semakin kompleks) Technology overflood (banjir teknologi/ banyak teknologi berkembang) More and more distributed system (sistem yang terdistribusi)

●



●

●

Legacy code (legalitas kode) –

Kode/program yang sudah ada sebelumnya

–

Apabila disuruh membenahi program orang lain maka lebih baik untuk membuat dari awal.

Shorter development cycles (siklus pengembangan yang pendek untuk memenuhi kebutuhan konsumen) –

Sulit untuk mengadopsi model waterfall dalam development saat ini.



●

●

Poorly defined initial requirements (definisi pada tahap inisiasi kelas konsumen rendah)

Inadequate system (testing yang kurang) –

Menyangkut masalah testing sebelum produk tersebut dirilis.



●

Poor risk management (manajemen resiko jelek) –

Hati-hati dengan permintaan konsumen,

–

Harus dipikirkan dengan benar kondisi konsumen,

–

Konsumen hanya memikirkan RBT

–

Misal :



Masalah Testing di Indonesia ●

Build fast → mau cepat –

●

Masalah waktu karena TTM (Time To Market) → apabila tidak melepas produk dalam waktu singkat maka akan dirilis oleh kompetitor.

Limited budget –

Role played game → 1 orang merangkap banyak peran

–

Misal : Minimal 3 orang dalam dev soft



Gotchas Sindrome



●

Uncomfortable UX –

●

UX todak nyaman → Solusi : MOCK (user interface)

Technology Not Match –

Teknologi tidak cocok ettapi kita paksakan → Solusi : pengkajian pemilihan teknologi

–

Misal : ● ●

Customer → Desktop Tim → bisanya web / PHP

dipaksakan



●

Broken Architecture –

Solusi : framework selection, misalnya : ● ●

–

Supaya architecture cocok

Ciri utama : ● ●

●

Desktop : MVP Web : MVC Re upload Entire site

Resources Is Not Sufficient –

Solusi : software estimation → terlalu banyak pengeluaran waktu tidak cukup SQ - http://sidiq.mercubuana-yogya.ac.id


Tugas ●

Dokumen Pengujian PL –

●

Download : Blog → RPL → Dokumen Pengujian

Source Code : 99,99 % Selesai. Tugas dipresentasikan pd pertemuan ke 14



Agenda ●

●

UAS RPL –

Kelas 21 : 04 Januari 2016

–

Kelas 22 : 04 Januari 2016

Note : Jika tidak hadir pada saat presentasi Dianggap tidak mengikuti UAS

Syarat : 1. Slide Presentation a) Proposal → 2 Slide b) Analisis → terkait dengan pengguna sistem → 1 Slide c) ERD + DB Relationship d) DFD e) Rancangan Struktur f) Tabel Uji

2. Project (Demo) SQ - http://sidiq.mercubuana-yogya.ac.id


Kemarin adalah sepenggal kisah masa lalu, Esok adalah sebuah bayangan, Hari ini adalah fakta yang dapat menjadikan mimpi indah untuk kemarin, Dan esok menjadi sebuah harapan. (DnD)



Time to celebrate the year that was, and look forward to the adventures that will be ! Thanks for a great 2015 and wishing you a happy start to 2016.

From all of us at FTI UMBY. SQ - http://sidiq.mercubuana-yogya.ac.id


Thanks u For Participating In My Class C U Next ... Year



P14 Software Re-Engineering

Recommend Documents