P13 Software Re-Engineering
A. Sidiq P. Universitas Mercu Buana Yogyakarta SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
Software Engineering
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
2
Software Engineering ●
Th 70 an – 80 an → hanya memperhatikan technical aspect
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
3
Technical & Non Technical Aspect ●
●
Technical Aspect ●
Coding
●
Testing
●
Configure
Non Technical Aspect ●
Bussiness Process
●
Social (bunch people)
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
4
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)
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
5
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]
6
Tendensi saat ini lebih ke konsumtif, karena itu beberapa permasalahan rela merubah proses bisnis menyesuaikan ke software
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
7
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 8
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) 9
Design ●
Design Contraint ●
Kapan kita bisa memilih komponenkomponen pada design contraint tergantung pada :
●
Design Decision ●
Programming Language
●
Algorithms
●
Frameworks*
●
Architecture
10
Technical Knowledge
11
Software Engineering Layer (Pressman, 2010)
12
Software Re-Engineering
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
13
Software Re-Engineering
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
14
Software Crisis Background
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
15
●
●
●
Increasing complex system (sistem semakin kompleks) Technology overflood (banjir teknologi/ banyak teknologi berkembang) More and more distributed system (sistem yang terdistribusi)
●
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected] SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
16
●
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.
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
17
●
●
Poorly defined initial requirements (definisi pada tahap inisiasi kelas konsumen rendah)
Inadequate system (testing yang kurang) ●
Menyangkut masalah testing sebelum produk tersebut dirilis.
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
18
●
Poor risk management (manajemen resiko jelek) ●
●
●
●
Hati-hati dengan permintaan konsumen, Harus dipikirkan dengan benar kondisi konsumen, Konsumen hanya memikirkan RBT Misal :
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
19
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
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
20
Gotchas Sindrome
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
21
●
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
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
22
●
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 -
[email protected]
23
Tugas ●
Berdasarkan tugas kelompok sebelumnya, selesaikan tahapan programming → Implementation
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
24
Agenda ●
06 Januari 2014 → UAS RPL
●
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
2. Project (Demo) SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
25
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)
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
26
Time to celebrate the year that was, and look forward to the adventures that will be ! Thanks for a great 2013 and wishing you a happy start to 2014.
From all of us at FTI UMBY. SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
27
Thanks u For Participating In My Class C U Next ... Year
SQ - http://sidiq.mercubuana-yogya.ac.id -
[email protected]
28