Software Development Fundamentals With Python

Minggu 1 : Software Development With Python

Software development process logical dan temporal sequence terus relationship dan aktivitas-
aktivitas yang ada di dalam software development process ini juga nanti setiap fasenya.
Roles dan responsibility dari setiap orang yang ada di dalam proses software development
Requirement dari customer
Software development model itu terus software development life cycle itu apa saja seperti V
model, agile, waterfall dan berbagai model yang bisa digunakan terus fase-fase yang ada di
software development
Bagaimana cara memilih drive models, bagaimana menentukan models yang hendak akan
kita gunakan untuk menentukan software development kita terus faktor-faktor apa saja yang
mempengaruhi pemilihan dari software development itu
Requirement gathering itu ada analisis, ada planning, ada desain
Dari implementasi nanti kita bisa lepas masuk ke testing sampai nanti ke arah deployment
dan maintenance.
Mengidentifikasi solusi, menciptakan solusi dari masalahmasalah yang dimiliki oleh klien
kita itu juga akan kita bahas bagaimana kita menganalisa requirement yang ada, bagaimana
kita menentukan agreement dan sign off contract dengan klien-klien yang ada gitu itu di fase
pertama.

Unified modeling language atau UML tentang introduction nya, tipe-tipe diagramnya, class
diagram yang ada, relationship yang ada, package nya, structure dan beberapa usecase-
usecase modeling di UML.
Apa yang dimaksud dengan software arsitektur dan apa yang dimaksud IX405 dengan
software desain?
Dari basic nya mulai dari low level design sampai high level design
Database arsitektur, apa itu database, relational database bagaimana, bagaimana kita
menentukan melakukan define terhadap sebuah database, primary key apa, foreign key apa,
case study tentang database structure.
Technical requirement ini sangat menentukan karena ini adalah translate dari bisnis
recruitment.
Menggunakan git atau github juga untuk manajemen versi bagaimana kita me manage
repository, manage brand dan software versioning.
Implementation dan risk assessment.
Jadi bagaimana software is identification, analisis, planning serta monitoring nya.
Testing dan quality assurance karena tadi setelah fase implementasi itu setiap unit yang kita
buat dari software yang kita kembangkan itu akan diintegrasi menjadi satu baru disiapkan
testing nya. Nanti akan dilakukan uji coba setelah diintegrasi baru dilakukanlah quality
assurance jadi untuk menentukan software itu masuk standar sesuai kebutuhan klien apa
tidak.
Setelah testing sudah oke ini fase yang ditunggu-tunggu itu fase go live. Jadi kita akan push
ke production untuk bisa diakses oleh klien. Nah dari fase dari fase ke-5 ini yang fase go live
ini Kita akan masuk ke fase yang terakhir yaitu fase maintenance.
Karir page seorang developer. Bagaimana kita bisa menentukan karir kita sebagai developer
mulai dari seorang associate developer sampai menjadi seorang VIP of Engineering atau bisa
jadi seorang shift technology officer.
Di software development itu prosesnya biasanya beragam, tergantung dari perusahaan
tersebut memilih software development models yang akan mereka gunakan untuk kebutuhan
development aplikasi mereka biasanya ada berapa banyak faktor yang menentukan untuk
pemilihan models ini seperti halnya tentang resource nya, kompleksifitas dari project nya,
bug cost nya ataupun kebutuhan-kebutuhan lainnya yang bergantung pada pengembangan
software.
Di software development ini ada masuk yang namanya desain terus masuk juga produk
manajemen terus ada juga project manajemen.
Software development life cycle ini itu ada beberapa tahap lagi seperti yang sudah saya bahas
sebelumnya. Tahap pertama yaitu tahap masuk ke requirement gathering terus masuk ke
tahap ke-2 yaitu desain, lalu tahap berikutnya adalah implementasi, testing hingga Kita
deployment ke production atau yang biasa kita sebut dengan go live. Baru nanti di terakhir
kita masuk ke maintenance dari project yang sudah kita kembangkan.
Di dalam software development ini ada beberapa metodologis, metodologis yang akan saya
sebutkan ini itu akan kita bahas lebih lebih rinci di week ke-2 nanti diantaranya itu adalah
model agial, waterfall, spiral development, prototyping, V model, iterative dan incremental
development juga nanti kita akan bahas tentang RAD atau rapid application development.
Skenario dari sebuah project biasanya dalam skenario ini ada 2 kubu. Yang pertama adalah
klien, yang ke-2 adalah dari kubu developer atau teknikal konsultan tapi di tengah-tengahnya
nanti akan ada seorang solution arsitek yang akan menjadi penengah untuk pengembangan
ini.
Role-role yang ada di dalam software development ini antara lain adalah ada customer baru
dari customer nanti mereka akan menghubungi seorang account manager terus ada project
manager baru langsung ke solution arsitek nah dari solution arsitek nanti mereka akan lanjut
ke team development nya atau project team nah di project team ini biasanya ada seorang
content manager, ada development team, ada IT admin dan desain timnya. Itu udah mereka
udah kumpulkan semua gathering requirement nya dari kliennya yang ingin membuat e-
learning platform nah solution arsitek ini dia akan membantu membuatkan rencana dan akan
membantu melakukan implementasi terhadap software yang dikembangkan hingga software
tersebut bisa go live ke production sampai ke tahap berikutnya yaitu tahap maintenance

Role dan responsibility dari orang-orang yang ada di dalam software development proses ini.
Yang saya bilang tadi yang pertama orang yang akan bertanggung jawab terhadap semua
requirement itu adalah seorang solution arsitek dan dia akan bertugas berkomunikasi dengan
customer dan project tim
dalam proses development ini masih banyak orang-orang yang ikut berkontribusi terhadap
pengembangan software tersebut. Misalnya yang pertama adalah seorang account manager,
yang ke-2 ada seorang project manager, ada quality manager, ada seorang requirement
manager, ada juga support manager, konten koordinator, dan project tim di dalamnya. Nah
tugas seorang account manager yang pertama adalah Dia menjadi point of contact dengan
customer nya jadi dia itu menjadi frontline dari pengembangan project tersebut. Jadi
tanggung jawab dia itu menghubungi klien, bisnis requirement yang dibutuhkan yang
diinginkan oleh klien itu apa saja account manager ini akan bertanggung jawab. Nah yang ke-
2 adalah seorang project manager tanggung jawab dari seorang project manager ini dia adalah
menentukan timeline dari pengembangan software yang dikembangkan. Dia bertanggung
jawab atas keseluruhan proyek tersebut. Yang ke-3 adalah quality manager, IX405 quality
manager ini bertugas untuk melakukan quality assurance terhadap project dan produk yang
dikembangkan. Jadi dia mengatur kualitas dari sebuah software yang kita kembangkan terus
untuk accepted user baik itu internal ataupun eksternal dia juga yang bertugas untuk
mengatur segalanya. Me-manage semua yang ada tentang kualitas dari software yang
dikembangkan. Berikutnya adalah requirement manager nah requirement manager ini dia
bertugas untuk membuat technical requirement dari yang tadinya account manager dapatkan
dari seorang klien terkait dengan bisnis requirement seorang requirement manager ini dialah
yang bertugas untuk melakukan translate.
dari bisnis requirement ke teknikal specification itu ada tugas dia misal seperti ini Seorang
klien Saya ingin membuat website yang aman tugas dia bagaimana mengkonversi bahasa
klien tersebut ke bahasa teknikal oke berarti translate nya kalau ingin membuat website yang
aman berarti dipasang SSL atau HTTPS secure socket layer nya terus ada login terus
dipasang beberapa proteksi-proteksi keamanan. Itu akan dimasukkan ke teknikal specification
oleh seorang requirement manager ini.
support manager ini dia bertugas untuk melakukan manajemen isu-isu yang ada. Jadi ketika
development terjadi baik itu sudah masih dalam tahap pengembangan atau software yang
sudah jadi dia yang bertugas untuk melakukan melakukan pengecekan terhadap bugs yang
ada, isu-isu apa yang ada yang muncul di dalam software nya dia yang menganalisa dan
menginformasikannya ke tim developer terus ada konten koordinator. Konten koordinator ini
dia bertugas untuk manajemen konten manajemen sistem untuk project yang dikembangkan.
Jadi dia yang akan fokus semuanya untuk mengurus konten-konten nya. Nah yang terakhir
adalah project tim di dalam project tim itu itu banyak sekali jadi ada konten koordinat, ada
konten manajer terus ada development tim, ada IT admin, ada desain tim. Nah the hole
people di dalam ini tuh mereka biasanya disebut sebagai project tim bisa juga biasanya di
dalam itu ada QA engineer atau software-software engineer. Terus orang yang terakhir di
dalam software development itu biasanya adalah solution arsitek. Dia ini yang paling penting
di dalam pengembangan software karena dia harus mengerti konsep software nya, dia harus
benar-benar mengerti tentang requirement nya, definisi-definisi apa aja kebutuhan klien Dia
harus mengerti melakukan bisnis analisis, melakukan project management dan dia juga yang
akan ngebantu tim untuk quality assurance. Nah itu adalah role dan responsibility dari tim-
tim yang ada di software development.

Problem ini bagaimana kita mencoba mengerti customer requirement karena seringkali di
software development itu kalau requirement dari klien itu enggak jelas nanti hasil dari
software yang akan kita kembangkan itu akan berantakan itu pasti
ketika customer tadi berinteraksi dengan seorang account manager, account manager itu
harus benar-benar paham komunikasinya dengan seorang customer itu harus benar-benar
bagus. Karena jika tidak ada komunikasi yang bagus jadi requirement nya yang ada enggak
jelas nanti seorang solution arsiteknya juga akan bingung gimana memberikan detail-detail
teknikal ke project timnya. Karna biasanya seorang customer ini akan memberikan bisnis
requiment gitu jadi bisnis detail aja seperti yang saya bilang tadi saya hanya ingin membuat
website yang aman terus teknikal specifitacion nya itu di buat halaman login.
Contoh-contoh lain dari masalah-masalah yang ada di software development ini terkait
dengan customer requirement contohnya nih jadi Saya ingin manage video di dalam website
yang terproteksi jadi enggak sembarang orang bisa mengakses video tersebut kalau dia tidak
punya akses gitu. Teknikal specification akan menjadi di engineering timnya nanti dia akan
bikin yang pertama new website with authentication, yang ke-2 ada login page nya, yang ke-3
ada database of video dimana database video itu baru bisa diakses kalau sudah login. Terus
ada video atau file apa fungsionallity di dalamnya terus ada juga user profile page. Nah itu
adalah cara mengkonversi customer requirement ke teknikal specification.
Contoh lainnya ada klien ingin Saya ingin punya platform yang bisa mengirimkan broadcast
email seperti mailchimp atau seperti toolstools lainnya. Seorang customer seorang solution
arsitek tadi dia akan menganalisa nih masalah-masalahnya barulah dibuatkan dibantu
dibuatkan teknikal specification nya.
Ingin bikin broadcast platform berarti kita harus develop yang pertama itu new email
marketing tool terus kita harus bikin newsletter generator nya. Kita akan buat generator agar
bisa mengirim newsletter sesuai dengan keinginan user atau secara berkala. Terus kita juga
bisa buatkan database user atau customer terus di butuhkan juga test environment.
case study yang akan saya gunakan di sini adalah bagaimana kita membuat e-learning
platform? Jadi Saya di sini akan berakting sebagai seorang solution arsitek. Jadi kebutuhan
apa saja yang ada untuk pengembangan e-learning platform ini akan saya coba jelaskan. Nah
yang pertama, yang pertama itu pasti login atau registration ini pasti dibutuhkan untuk
webiste e-learning ini di dalamnya nanti itu akan ada manajemen registrasi, manajemen user
baik itu create, read, update ataupun diklat informasi user. Terus ada profile page, profile
page ini adalah informasi tentang user misal user nya udah berapa mengambil sertifikat, user
nya sudah berapa mengambil kursus, dia sosial medianya apa dan ini bisa dimasukkan ke
profil page ini. Yang berikutnya adalah modul course. Modul kursus ini itu berisi tentang the
hole sistem yang mengatur kursus-kursus yang ada di dalam e-learning platform kita. Baik itu
upload kursus, manajemen kursus itu ada semua di modul kursus. Terus di dalam modul-
modul kursus ini biasanya ada lecturer terus lecturer ini itu tugasnya adalah konten-konten
yang ada di dalam kursus tersebut atau biasanya kalau di IndonesiaX itu konten-kontennya
disebut sebagai week 1 section nya apa, IX405 week 2 section nya apa, week 3 section nya
apa seperti itu. Nah di dalam itu kita bisa masukkan per section nya itu satu video ataupun
satu konten. Itu tergantung user nya yang manage kursus tersebut. Nah di akhir week itu
biasanya ada exam, exercise atau biar bisa kita bilang tes aja lah gitu. Jadi biasanya di mooc
atau e-learning itu ada exam atau tes ini. Nah ini bisa kita masukin modul untuk cek level
under level of understanding dari setiap user. Terus itu dari sisi frontend nya kalau dari back
layer nya itu tentu ada instruktur studio nah atau ya kita sebut aja teacher admin biar lebih
enak teacher admin karna ini e-learning terus ada lagi app admin. Nah di teacher admin ini
adalah konten manajemen yang digunakan untuk mengelola kursus-kursus yang ada,
mengelola konten-konten baik itu dari konten kursus per section ataupun konten-konten exam
nya, tes dan lain sebagainya. Mengatur grading dan beberapa unsur-unsur yang ada di dalam
sebuah kursus. Untuk app admin, app admin ini digunakan untuk mengatur keseluruhan
system dimulai dari sistem itu ingin memiliki kategori apa saja ingin memiliki banner di
halaman depannya apa saja itu di manage itu di app admin bisa juga untuk manajemen-
manajemen user. Nah biasanya di yang pertama yang di login dan registrasi. Login dan
registrasi itu kebutuhannya enggak jauh beda detail-detail informasiinformasi umum dari user
nya. Terus untuk di halaman informasi kursus itu biasanya itemitem yang ada itu biasanya
kalau di e-learning itu ada video. Video introduction, ada image tentang instrukturnya nanti
ada paragraph seorang solution arsitektur tuh harus benar-benar mengerti apa elemen-elemen
apa saja yang ada di dalam sistem yang dikembangkan. Nah selain itu ketika semuanya udah
dibikin nanti seorang solution arsitek tersebut bisa mengatur the hole desainnya baik itu high
level design atau low level design nya. Nanti akan bebas mengaturnya, menganalisa sesuai
kebutuhan-kebutuhan user baru nanti development nya akan berjalan dengan lancar nah
untuk praktis coding nya nanti kita akan menggunakan phyton.
Minggu 2 : Software Development Process
Mengapa SDLC?
SDLC software development life cycle jadi ini sebenarnya adalah set of proses yang
digunakan untuk mengembangkan sebuah software.
tujuan utamanya sebenarnya untuk menghasilkan software yang benar-benar bagus.
SDLC ini untuk management control. Jadi untuk manage dari tim nya kita agar organisasi
kita lebih baik dalam pengembangan software. Terus bisa juga untuk dokumen yang lebih
efektif dan memastikan arsitektur dan desain yang lebih aman. Yang terakhir adalah kenapa
SDLC ini benar-benar diperlukan? Agar software yang kita buat itu sesuai dengan ekspektasi
dari klien.
Stage yang biasa yang terjadi di software development life cycle ini yang pertama adalah
project kick off atau inisiasi nah inisiasi dilakukan ketemu antara dua belah pihak yang ingin
mengembangkan software tersebut terus mereka melakukan requirement gahering setelah
requirement gathering mereka melakukan analisa setelah analisa masuk ke tahap desain baik
dari sisi arsitektur dan sistem desainnya. Baru masuk ke tahap development pengembangan
utama dari software tersebut. Setelah tadi yang saya bilang development itu dilanjutkan
dilanjutkan dengan integrasi dan testing. Baru setelah testing tersebut dilakukan deployment
atau go live nah setelah go live semuanya nanti di software development life cycle itu
dilakukan operation dan maintenance. Jadi setelah operation dan maintenance tersebut kalau
ada update-update lagi nanti akan terjadi kick off atau inisiasi lagi nah life cycle nya begitu
terus berputar terus seperti itu sampai software yang dibuat itu benar-benar bagus dan sesuai
dengan requirement bisnis dari user.

Kriteria Entry dan Exit di SDLC

software development life cycle ini ada poin-poin pentingnya. Yang pertama itu entry kriteria
nya, yang ke-2 exit kriteria, jadi 2 poin penting ini sangat menentukan ketika perputaran life
cycle di software development ini. Misal yang pertama di kick off stage atau initiating tadi
yang inisiasi. Jadi entry point nya itu adalah input dari user atau requirement-requirement
yang dimiliki oleh user dikumpulkandikumpulkan semuanya dari user nya dari stakeholder
dari aplikasi yang kita kembangkan itu jadi input di kick off tersebut nah output nya itu yang
akan jadi exit kriteria itu ada acception dari project planning, acception tersebut nanti pindah
ke fase berikutnya atau stage berikutnya.
Berikutnya itu adalah requirement gathering, requirement gathering itu entry point nya adalah
requirement-requirement yang ada atau perubahan-perubahan yang terjadi apa saja gitu dalam
software development nya. Terus untuk exit kriterianya bagaimana agar kita bisa keluar dari
fase requirement gathering ini. Nah agar bisa keluar output nya adalah kita membuat yang
namanya software requirements specification document. Baru itu dilempar ke stage
berikutnya yaitu stage analisis.
stage analisis ini entry point nya adalah yang tadi software requirement specification
documents atau bisa juga entry point nya perubahanperubahan yang terjadi di dalam software
tersebut. Sesuai dengan kebutuhan klien baru nanti exit kriterianya itu setelah itu dibuatlah
namanya software requirement spec document = software requirement gathering tadi. Baru
itu pindah ke stage desain .
stage desain ini entry point nya yang tadi software requirements specification document, exit
kriterianya apa? Desain ini exit kerjanya adalah dibuatnya sebuah desain specification
document. Jadi udah jadi desain specification document nya kita udah bisa masuk ke tahap
development.
Tahap development setelah entry point nya udah ada yang tadi desain specification document
baru kita buat aplikasinya di situ di buat semua tim itu fokusnya di develop aplikasinya udah
dibuatnya dari frontend nya, backend nya, fungsi fungsionallity yang ada, modul-modul yang
dibutuhkan software tersebut semuanya bikin di sini.
Setelah dibuat unit-unit yang udah jadi itu nanti akan menjadi output atau exit kriteria dari
development stage ini. Barulah itu kita bisa masuk ke stage testing tadi. Nah di stage testing
ini entry point nya ada unit, modul atau fungsi-fungsi yang udah jadi di fase development.
Jadi yang udah jadi itu dikumpulkan jadi satu itu diintegrasikan nah mereka akan membuat
yang namanya test case di dalamnya nih. Jadi ini yang biasanya tuh developer bilang test case
nya gimana, testing nya gimana. Ini testing nya pakai apa gitu pakai behavior, pakai user
testing, pakai testing yang model seperti apa pasti sering dengar di sosial media tentang ya
gimana developer melakukan testing nya. Testing itu sering terjadi di fase testing dan
integrasi ini itu output nya baru output nya ketika udah tidak ada software yang cacat apa
fungsi-fungsi yang cacat udah enggak ada modulmodul yang cacat testing nya semua lancar
all clear baru masuk ke stage development nya.
Stage developer nya itu exit point nya apa gitu, exit point untuk deployment ini itu biasanya
adalah build deployment into production
software yang udah jadi di software development nya tinggal masuk ke server productionnya.
terakhir adalah operation and maintenance. Nah di sini untuk operation dan maintenance itu
nah itu dikumpulkan tuh software bukan dikumpulkan sorry. Jadi software yang udah jadi itu
di tes tuh oleh enduser dicoba-coba oleh enduser mereka pakai kadang kalau mereka
menemukan masalah nanti langsung dilapor, lapornya kemana? ke support tim atau support
manager yang sempat kita bahas di week berikutnya. Karna dia akan manage bug fixing isu
dan beberapa kendala yang ada di software yang kita kembangkan. Nah itu pembahasan
singkat tentang software development life cycle, exit kriteria dan entry kriterianya.

Waterfall Model
model-model yang ada di software development. Yang pertama yang ingin saya bahas adalah
waterfall model. Untuk waterfall model biasanya itu yang pertama yang stage yang dilakukan
itu adalah requirement analysis,system design, implementation, testing, deployment hingga
maintenance. Yang pertama itu requirement itu dikumpulkan dalam satu dokumen
specification. Jadi semua dikumpulkan dulu di awal untuk waterfall diawal dikumpulkan
semuanya apa aja spesifikasi tentang kebutuhan user untuk software yang mau dibuat itu
semua ditulis di situ. Terus masuk ke tahap berikutnya nah untuk pindah ke stage berikutnya
ini itu harus benar-benarselesai untuk waterfall model ini jadi ketika requirement itu udah
benar-benar selesai baru pindah ke sistem desain nah di sistem desain itu, itu berisi
spesifikasi requirement untuk sistem, untuk hardware atau semua yang dibutuhkan untuk
membangun proyek yang sedang dikembangkan. Setelah semua di sistem desain itu selesai
udah dapet nih semuanya itu spesifikasinya, requirment nya udah jelas semua baru masuk
tahap implementasi nah fase ini di stage ini adalah pengembangan untuk aplikasi Jadi seperti
biasa untuk pengembangan dipisah per unit atau modul baru nanti masuk ke testing di testing
itu dilakukan integrasi untuk unit-unit yang sudah dibuat baru dilakukan testing kalau sudah
selesai di testing baru bisa pindah ke deployment. Nah di deployment ini aplikasi akan
diimplementasikan ke production dan bisa diakses oleh enduser terus setelah deployment itu
udah benar-benar selesai itu baru bisa pindah ke maintenance nah kalau kita lihat di grafik
untuk waterfall ini untuk bisa masuk ke stage berikutnya itu ingat ya harus benar-benar
selesai di state sebelumnya. Kalau tidak bisa selesai kita tidak bisa pindah ke stage
berikutnya. Itu kunci utama dari model waterfall ini. Nah kelebihan dari waterfall ini apa?
Kelebihannya adalah yang pertama itu simpel dan mudah digunakan juga ini sangat mudah
banget dimengerti baik itu dari mahasiswa yang baru lulus atau dari SMK juga untuk
mengerti waterfall ini atau orang awam juga itu gampang banget ngerti tentang waterfall ini.
Karena suatu proses harus benarbenar selesai baru bisa pindah ke proses berikutnya. Terus
mudah untuk dilakukan manajemen, kenapa? Karena setiap fasenya memiliki proses review.
Nah inget lagi enggak boleh pindah ke fase berikutnya kalau belum benar-benar selesai.
Terus setiap fasenya ini kelebihannya itu diselesaikan dalam satu waktu jadi enggak ada
berantakan harus ngerjain fase yang lainnya dulu gitu. Nah terus stage-stage yang adanya itu
itu pasti di waterfall ini requirement nya juga yang juga lebih mudah dipahami dan
dimengerti tapi ada kekurangannya untuk waterfall ini. Waterfall ini kekurangan yang
pertama adalah dia tidak bagus untuk long project. Jadi kalau project yang ingin kita buat itu
1 tahun dan sebenarnya software itu bisa di selesaikan dalam waktu 1, 6 bulan ataupun 3
bulan dengan model yang lain itu enggak bagus. Jadi enggak bagus untuk long time project
waterfall ini terus untuk proyek yang kompleks juga yang kompleksitasnya rumit banget ini
enggak bagus untuk menggunakan waterfall ini. Terus tidak bagus juga untuk project yang
memiliki requirement yang berubah-rubah karena biasanya klien itu ketika di tengah jalan
maunya berubah-rubah saya harusnya fitur ini fitur a harusnya punya fitur b, fitur c, fitur d ini
enggak bisa kalau di waterfall itu kan merusak proses development yang ada. Nah berikutnya
adalah saat proyek berada di fase testing itu sangat sulit untuk merubah apa yang sudah
dibuat. Nah jadi ketika udah testing tuh udah udah enggak bisa ngapa-ngapain itu mau
dirubah gimanapun Kita udah sampai sejauh ini mau gimana nih di rubah pasti bakal hancur
pasti bakal gagal software yang kita kembangkan dan yang terakhir adalah tidak bagus untuk
object oriented programming itu kekurangan untuk waterfall ini. Terus oke udah tahu nih
kelebihan sama kekurangan waterfall terus kapan kita menggunakan waterfall ini? Oke kita
menggunakan waterfall apabila yang pertama requirement nya sudah fix udah enggak akan
berubah-rubah lagi project yang singkat, itu bisa menggunakan waterfall product definition
yang stable terus teknologi yang digunakan untuk proyek tersebut dimengerti dengan baik.
Karena kalau kita enggak mengerti stek dari project yang akan kita kembangkan itu ya
percuma kan apa menggunakan waktu yang lebih lama untuk mengembangkan project
dengan waterfall model ini. Terus enggak boleh ada requirement yang ambigu sama sekali di
waterfall enggak boleh itu karena akan merusak proses development di tengah jalan nantinya.
Nah itu tentang software development models dengan waterfall.

V Model
Model berikutnya adalah V model, V model ini merupakan extension dari waterfall model
yang sudah saya bahas di section sebelumnya. Tapi ada hal yang paling penting di V model
ini yaitu adanya verifikasi dan validasi Tetep stage yang ada di dalam V model ini yang
pertama itu requirement analysis, yang kedua itu system design terus arsitektur desain, modul
desain, dan coding. Nah tetapi nanti akan ada 2 seperti yang bisa lihat di grafik ini. Jadi di
grafik gitu kalau kita lihat di bagian kiri itu ada verifikasi, yang di sebelah kanan itu ada
validasi seperti acception testing, system testing, integration testing dan unit testing.
Konsepnya sama seperti waterfall cuman ada verifikasi dan validasi. Kelebihan dari V model
ini dibandingkan dengan model-model yang lainnya adalah yang pertama V model ini sangat
fleksibel terus yang kedua aktivitas seperti planning, test, test design itu dilakukan sebelum
coding sehingga itu lebih menghemat waktu dan itu lebih better dari model yang sebelumnya
saya bahasa itu model waterfall. Terus V model ini juga sangat mudah dimengerti untuk
orang yang baru terjun di software development. Terus kelebihan yang terakhir adalah V
model ini sangat bagus untuk proyek-proyek Kecil. Nah kekurangannya apa kekurangannya
ini hampir sama juga dengan waterfall model jika terjadi perubahan di tengah development,
tes dokumen dan require dokumennya itu harus di update. Jadi mau enggak mau nih ketika
terjadi perubahan itu ya benar-benar harus di update semuanya tapi bedanya kalau di
waterfall seperti yang kita tahu kalau udah mentok di testing mau berubah mau kembali ke
fase stage berikutnya itu kan susah enggak akan bisa melanjutkan project nya. Terus
kekurangan lainnya dari V model ini software yang dibuat pada saat fase coding atau
implementasi. Itu jadinya itu enggak ada early prototype karena biasanya ada klien yang
membutuhkan prototype ya mungkin mereka buat ditunjukkan kepada CEO nya mereka CTO
nya mereka ataupun orang-orang yang berkepentingan terhadap project tersebut. Itu
minusnya enggak ada early prototype jadi enggak ada hasil yang sudah ada di muka lah gitu.
Nah kapan kita harus menggunakan V model ini? Sebenarnya simple aja kalau ingin
menggunakan V model ini itu saat requirement dari project yang small to medium lah itu
benar-benar sudah fix itu baru kita bisa menggunakan V model ini kalau semua requirement
udah oke kita pakai aja V model gapapa dan project nya enggak terlalu besar juga gitu. Terus
cost kita harus biasa benar-benar memastikan high confidence lah ke customer nya bahwa
tidak ada prototype yang dihasilkan selama proses development. Jadi kalau klien nya oke ga
ada prototype, ga ada contoh-contoh software yang akan kita gunakan apa nanti ketika tahap
development mereka oke ya udah gapapa kita pakai aja V model ini toh ini mudah dimengerti
lebih cepat juga dan bagus buat aplikasi yang kecil sampai medium.

Incremental Model
incremental model. Jadi model ini biasanya itu digunakan di saat requirement yang udah ada
itu itu wall understood jadi udah benar-benar dimengerti baik itu dari sisi solution arsiteknya
baik itu dari sisi kliennya baik itu dari sisi kita sebagai developer gitu. Terus ada kebutuhan
untuk ngedeliver modul ya multiple modul jadi misal ada beberapa fitur yang ingin
dikembangkan tetapi secara bersamaan. Kalau kita lihat di model-model berikutnya itu kita
hanya fokus aja kesatu modul baru bisa lanjutkan modul lainnya. Incremental model ini itu
bagus jadi kita bisa set multiple dari delivery jadi mau berapa mau modul bisa kita set.
Biasanya stage yang dilakukan itu stage yang pertama itu communication. Setelah
communication itu masuk ke stage planning dari planing nanti akan terjadi modeling, terus
terjadi stage contraction baru masuk ke deployment. Nah ketika di fase planning tadi kalau
kita ingat setelah fase communication ada namanya fase planning baru itu bisa dikembangkan
modul yang lainnya jadi secara bersamaan secara paralel itu bisa dibuat bisa dimulai
komunikasi komunikasi tentang modul berikutnya apa nih oke komunikasi dimulai planning
dilakukan modeling juga dilakukan construction dilakukan deployment juga dilakukan terus
ketika masuk ke tahap planning dari modul yang kedua tadi itu komunikasi juga sudah mulai
bisa dilakukan jadi secara berkelanjutan atau nested gitu. Jadi setelah communication,
planning, modeling, construction sampai deployment nah itu bisa sambil berjalan
modulmodul yang lainnya itu dikembangkan. Ini sangat bagus sekali untuk kita achieve
banyak modul dalam satu project kelebihan-kelebihannya dari incremental model ini yang
pertama menghasilkan prototype dari software lebih cepat karna prototype sudah dibuat lebih
awal. Kalau V model sama waterfall model yang saya jelaskan sebelumnya itu belum ada
prototype di awal. Baru bisa dicoba di akhir terus incremental model ini modul itu fleksibel
bisa dikembangkan kapan aja gitu. Tergantung kita kebutuhannya gimana terus biasanya ini
yang disenangi sama orang-orang lebih murah untuk biaya delivery softwarenya. Biasanya
untuk model ini murah banget lah gitu terus management risk dari incremental model ini
lebih gampang juga karna kita tadi pengerjaannya secara paralel untuk manajemen risknya
untuk organize semuanya itu lebih gampang jadinya tapi ada kekurangannya kekurangan
yang untuk incremental model ini itu harus ada planning dan desain yang baik, karena kalau
enggak ada planning dan desain yang baik kita mengembangkan banyak modul tadi.
Modulnya banyak nih banyak banget dah 4 5 6 modul kalau itu enggak di planning dengan
baik itu bisa hancur. Berikutnya adalah membutuhkan clear and complete definition untuk
seluruh project sebelum dibuat. Terus cost nya untuk yang incremental model ini dia lebih
mahal dibandingkan dengan waterfall. Karna ya tadi ada beberapa modul yang dikembangkan
secara bersamaan gitu. Kapan kita bisa menggunakan incremental model ini? Kita bisa
menggunakan model ini saat requirement dari sistem sudah clear dan dimengerti dengan baik
terus mayor requirement-requirement nya requirement yang paling besar yang paling
dibutuhkan harus sudah pasti walaupun beberapa details dari sistem yang dikembangkan
dapat berubah sewaktu-waktu. Its oke di incremental model ini terus kita bisa menggunakan
new teknologi juga enggak papa pakai aja teknologi baru dari hasil riset kita, hasil eksplorasi
kita di model ini. Its oke. Terus resource dengan skill set yang dibutuhkan itu enggak tersedia
misalnya wah ini belum ada nih yang bisa pakai golang atau yang bisa pakai python enggak
papalah gitu kita pakai incremental model dulu gitu untuk menutupi ini bisa pakai bahasa
pemrograman lain dulu gitu terus high risk feature dan high risk terhadap golnya nah itu saat
kita menggunakan incremental model ini.

Iterative Model
Iterative model ini biasanya itu enggak harus dimulai dengan full specification recruitment.
Terus development untuk iterative ini menggunakan model itu, itu dapat dimulai dari bagian
kecil dari software yang kita kembangkan. Karna proses pengembangan ini dapat terjadi
berulang kali jadi ada banyak versi nanti di iterative ini. Berulang kali untuk menghasilkan
versi baru dari software yang kita kembangkan tersebut, contoh untuk iterative pakai contoh
apa ya? Mobil gimana bisa jadi sebuah mobil? Coba bayangkan gimana bisa jadi mobil. Pasti
kita harus mikirin dulu gimana cara untuk berkendara dulu agar bisa mobil itu berlari dulu
engga harus langsung bikin mobil bisa kita mulai bangun sekuter. Sekuter misalnya dari
sekuter ya udah kita melakukan requirement dulu cari requirement apa aja kita planning, kita
desain kita bikin sekuternya setelah sekuternya jadi kita bisa masuk ke tahap berikutnya. Kita
bisa bikin sepeda karena kita udah tahu cara sekuter itu berjalan sepeda. Sepeda ini kita bikin
lagi nih mulai dari requirementnya, analisanya dan lain sebagainya. Kita bikin desainnya juga
kita bikin ngedevelop sepedanya udah, udah jadi sepeda. Baru setelah jadi sepeda gimana
biar lebih bagus lagi kita bikinlah motor. Nah dari motor ini tetap dilakukan yang namanya
requirement analisis tetap dengan lakukan yang namanya planning, development sampai go
live tadi. Setelah motornya jadi baru kita bisa pikirkan nih pengembangan yang lebih bagus
untuk berikutnya. Kita bisa bikin mobil nah itu untuk iterative jadi mulai dari hal yang kecil
dulu itu bisa dilakukan secara bertahap untuk memproduksi software yang lebih besar atau
lebih baik. Kalau kalian lihat diagramnya berikut di diagram tersebut kalian bisa lihat simple
nya adalah di diagram yang O itu ada desain nol terus ada implement nol terus analisis nol itu
yang pertama. Diagram selanjutnya itu ada desain 1, implements 1, analisis 1 begitu
seterusnya sampai design n, implement n atau analisis n. Itu tetap terjadi berulang-ulang
iterative. Itulah namanya iterative model sampai kita mendapatkan software yang lebih baik.
Kelebihan utama dari iterative model ini kita bisa membuat high level design dari sebuah
aplikasi yang kita buat sebelum benar-benar kita membangun product dan menentukan design
solution dari software yang kita buat. Terus kita bisa menemukan kecacatan dari sebuah
software yang kita kembangkan lebih awal. Kita bisa meminimalisir cacat yang ada di mobil
karena kita udah bisa menemukan cacatnya di motor. Sistem kerjanya pasti sama nanti
kedepannya mobil itu merupakan improvement dari motor tersebut. Nah banyak waktu dan
desain juga untuk desain dan sedikit waktu untuk dokumentasi ini jeleknya iterative. Karna
kita fokusnya desain, kita bikin bikin bikin bikin bikin terus aja bikin. Kita bisa menggunakan
resuable user feedback ketika bikin sekuter kita bisa dapat feedback dari user ketika kita bikin
sepeda tadi kita tetap dapat feedback nya, ketika kita bikin motor kita dapat feedbacknya lagi
nah itu bisa resuable terus sampai benar-benar softwarenya bagus. Tapi ada kekurangannya,
kekurangannya untuk mengembangkan iterative model ini untuk jangka panjang itu mahal
banget jadi costly banget gitu. Enggak bagus untuk ya company yang memiliki cost yang
minim gitu. Terus banyak resource yang dibutuhkan jadi resource untuk iterative model ini
harus benar-benar banyak dan ini enggak bagus untuk semua project karena ini jangka
panjang dan untuk proyek yang lebih besar. Terus untuk manajemennya itu benar-benar
dibutuhkan manajemen attention karena kalau rusak dari awal cacat dari awal aplikasinya di
skuter tadi mobil yang kita bikin juga di masa depan itu akan cacat juga. Kapan
menggunakan iterative model ini? Ya digunakan kalau projectnya high scale benar-benar
proyek yang besar terus ketika requirement of complete sistem itu clearly defined dan Kita
benar-benar udah mengerti tentang kompleksitas dari Project itu seperti apa. Terus mayor
requirement harus ditentukan dari awal walaupun di depan nanti itu bisa berubah-rubah fokus
kepada mayor requirement nya dulu. Nah itu tentang iterative model semoga kalian enggak
pusing ni kayaknya makin ke sini makin berat ni pembahasan kayaknya gitu yaudah itu
iterative model.

RAD Model
RAD model ini adalah salah satu model yang biasa digunakan untuk project yang singkat.
Fokus utama dari RAD model ini adalah komunikasi mainten di model ini ini benar-benar
harus komunikasi antara kedua belah pihak. Developer dan customer itu harus benar-benar
komitmen karena akan ada Rapid Fire Activity aktivitasnya akan banyak banget rapid
application development ini. Terus bagusnya lagi untuk RAD ini dapat memberikan preview
ke end user dan bisa memberikan feedback secara langsung terus komponen atau function
yang dikembangkan itu bisa secara paralel ini hampir mirip juga dengan incremental model
gitu. Tetapi stage yang ada untuk di RAD model ini biasanya itu yang berjalan secara paralel
itu dari bisnis modelingnya, data modeling, proses modeling, application generation yang
terakhir adalah testing dan turn over. Itu bisa dilakukan secara paralel itu bagusnya untuk
rapid application development ini jadi cocok banget untuk short project, kelebihan utamanya
dari RAD model ini development time itu itu bisa diminimalisir jadi bisa di reduce enggak
harus membutuhkan waktu yang lebih banyak. Terus meningkatkan reusability untuk sebuah
komponen atau modul yang ada di dalam aplikasi yang kita kembangkan. Terus ini
mendorong customer untuk memberikan feedback terus-menerus kepada software atau
kepada developer yang sedang mengembangkan software yang ada gitu. Jadi customer harus
benar-benar kasih feedback yang bagus itu untuk kelancaran project ini. Terus integrasi yang
dilakukan itu sejak awal dari setiap modul-modul unit-unit yang dikembangkan integrasi
dilakukan dari awal. Tapi kekurangannya adalah untuk RAD model ini dia sangat bergantung
pada tim dan individual performance untuk melakukan identifikasi pada bisnis requirement
jadi kalau salah satu orang yang bertanggung jawab untuk melakukan identifikasi kepada
bisnis requirement itu enggak bekerja dengan baik itu kemungkinan bisa membuat project
tersebut gagal. Terus hanya sistem yang bisa modular yang dapat menggunakan model ini
kalau enggak bisa modular kalau cuman satu aja ya udah kita enggak bisa menggunakan
RAD model ini. Terus ini sih kelemahan paling enggak enaknya dari RAD model itu benar-
benar harus membutuhkan developer yang jago. Jadi kalau developer nya enggak pernah
belajar gua nggak benar-benar mengerti tentang proyek yang akan dikembangkan jangan
harap untuk proyek yang dikerjakan itu berjalan dengan lancar. Itu kelemahannya. Kapan
menggunakan RAD model ini? Kalau saya bilang sih kita bisa menggunakan RAD model ini
bagus untuk software yang ingin dikembangkan dalam waktu yang singkat baik itu 1 2 atau 3
bulan itu bisa menggunakan RAD model ini. Terus resource dengan high bisnis knowledge
tersedia dan ada kebutuhan software dapat dikembangkan dalam waktu yang lebih singkat
seperti yang saya bilang di poin pertama tadi ingat ya kalau mau pakai RAD model harus cari
developer yang bener-bener jago terhadap proyek tersebut yang punya pengalaman.

Spiral Model
Model spiral ini itu selalu dimulai dengan desain goal dan selalu diakhiri dengan client
review. Ada 4 hal yang paling penting di spiral model ini. Yang pertama adalah
identification, yang ke-2 adalah desain, yang ke-3 adalah development atau build atau kita
juga bisa nyebutnya construction nah gitu. Terus yang terakhir adalah evaluation dan risk
analysis. Software yang dikembangkan dalam spiral model ini nanti bentuknya itu
inkremental rilis. Jadi ada series of release, ingat spiral yang pertama ketika identification
misal nih kita udah dapat bisnis requirement entar ke identification lanjut ke yang ke-2 di fase
desain baru dibuat di sana desain itu arsitektur desain. Terus di development itu kita bisa
membuat dulu proof of concept dari sebuah aplikasi nanti masuk ke stage berikutnya masuk
ke management risk. Nah setelah masuk ke fase ke-4 tersebut ke terakhir di fase evaluation
dan risk analysis nanti muter lagi tuh masuk ke fase identifikasi lagi lanjut ke fase desain
lanjut ke fase development mutar lagi ke fase evaluation dan risk analysis begitu seterusnya
mutar makanya dinamakan spiral. Kelebihan utama dari spiral model ini jadi untuk update
dan penambahan fungsi itu bisa dilakukan di akhir setiap stage. Setelah kita berada di akhir
stage nanti kan berputar lagi itu mulai lagi di identification di hal-hal baru jadi untuk ada
penambahan fungsi pun its oke kita tetap bisa menambahkan fungsi tersebut ke aplikasi yang
kita kembangkan. Terus estimasi costnya itu lebih mudah dan cepatini untuk seorang manajer
enak nih bisa lebih cepat dan lebih mudah untuk manajemennya. Terus development untuk
spiral model ini itu memakan waktu yang lebih cepat juga. Terus ya dari space untuk
customer feedback ketika user nya butuh feedback dia bisa melakukannya kapan aja di spiral
model ini. Nah kekurangannya adalah besar kemungkinan biasanya perusahaan yang
menggunakan spiral model ini itu tidak sesuai dengan schedule dan budget development.
Kadang minim kadang bengkak selalu terjadi di spiral model ini. Terus ini nggak cocok
untuk proyek yang kecil. Kalau kecil ya udahlah ya kita pilih yang model-model yang
sebelumnya aja. Terus untuk biaya itu pasti akan bengkak untuk yang proyek-proyek yang
kecil ini. Makanya nggak bagus. Terus kekurangannya kesuksesan dari proyek ini itu
bergantung pada stage yang terakhir. Jadi kalau stage yang ke-4 tadi yang di evaluation dan
risk analysis di stage tersebut nggak bagus karna akan berlanjut ke stage identifikasi
lagi.Kalau di situ nggak bagus itu bisa m enghancurkan proses developmentnya. Kelebihan
dan kekurangan dari spiral model sudah kita bahas tadi sekarang kapan sih kita bisa
menggunakan spiral model ini? Saran saya waktu untuk menggunakan spiral model ini yang
pertama ketika cost dan risk evaluation itu benar-benar sangat penting untuk development
nya. Kita tahu nih cost ini penting banget nih kalau sampai jelek untuk risk evaluationnya,
cost planningnya itu enggak bagus itu enggak bagus untuk spiral model ini. Terus ini juga
bagus untuk medium to high risk project dan kompleks requirements nya itu lebih kompleks.
Spiral model ini juga bagus untuk pengembangan new produk jadi ketika kalian punya
perusahaan atau sedang bekerja dengan perusahaan ingin mengembangkan new produk lain
itu bagus menggunakan spiral model ini. Terus yang terakhir adalah kapan kita menggunakan
spiral model itu ketika ada significances. Jadi kalau ada perubahan yang banyak gitu yang
terjadi dalam pengembangan software kita dan kita harus melakukan riset dan eksplorasi Kita
bisa menggunakan spiral model ini.

Agile Model
Ada software development moduls yang disebut agile. Mungkin istilah-istilah yang tadi itu
yang mungkin dari perkantoran dari kantor kalian itu dapatnya dari sini agile agile agile gitu.
Agile model ini sebenarnya untuk fase yang ada di dalam itu simpel aja sebenarnya. Misal
ada planning, requirement analysis, ada desain, ada building dan testing tapi di agile ini ada
hal yang lebih membuat saya tertarik ada yang namanya iterasi di agile ini. Tapi sebelum
masuk ke hal-hal tersebut biasanya untuk software yang dikembangkan secara agile ini
modelnya itu hampir mirip juga dengan incremental dan cycle nya itu terjadi bisa terus-
menerus jadi akan ada interaksi terus menerus. Biasanya untuk agile ini bagus untuk
individual interaction terus bagus juga untuk customer collaboration terus untuk perubahan-
perubahan yang ada itu itu bagus perubahan-perubahan yang cepat itu bagus menggunakan
agile ini. Fasenya tadi yang saya udah bilang dari planning sampai testing jadi ketika kita
ingin membuat beberapa modul. Beberapa modul jadi kita mau bikin aplikasi e-learning tadi
saya mau bikin modul registrasi, saya mau bikin modul login, saya mau bikin modul kursus
tetapi secara bersamaan dan itu bisa dilakukan dengan model agile ini. Bagusnya adalah
ketika kita melakukan planning di setiap modul tersebut melakukan requirement analysis
sampai ke tahap desain terus kita buat sampai testing kalau itu enggak bagus dan enggak
benar-benar fit sesuai dengan perencanaan yang kita lakukan kita lakukan iterasi. Biasanya
ada sprint di dalam sini di dalam agile ini ada sprint kita kelarkan project ini selama 3 minggu
gitu Oke kelar udah diputar lagi kalau belum selesai selalu ada iterasi itu namanya agile. Jadi
kalau belum kelar masih ada iterasi ada customer feedback, ada user feedback itu terus
menerus terjadi. Kelebihan dari agile model ini itu sangat fleksibel buat developer dan mudah
digunakan Terus fungsi-fungsi yang ada itu dapat dikembangkan secara rapid terus bagus
juga untuk team work. Jadi untuk kolaborasi agile ini sebenarnya sangat powerfull makanya
agile ini banyak digunakan di startup-startup atau perusahaan-perusahaan yang berkembang
saat ini. Terus banyak yang bilang agile ini the realistic approach to software development
katanya si seperti itu. Kalau ada perubahan-perubahan yang agak telat ya its oke di agile
karena perubahan itu kita open masuk nanti kita masukkan ke fase-fase pengembangannya
kalau enggak sesuai tetap akan terjadi interasi terus kekurangan, kekurangan dari agile ini itu
bergantung banget pada customer iteration. Jadi kalau iterasinya enggak bagus dari customer
feedback nya enggak enggak sesuai, enggak benar, pokonya enggak bagus aja itu akan
mengakibatkan software nya nggak bagus juga nanti. Jadi kalau software nya salah tim yang
mengembangkan software tersebut kemungkinan juga akan salah kita itu di agile. Terus ini
membutuhkan high individual depedency karena tidak banyak dokumentasi yang dihasilkan.
Untuk model ini terus transfer knowledgenya juga kadang susah karena biasanya di agile ini
kebanyakan iterasi iterasi iterasi kadang dokumentasi sering di lupakan di agile. Kapan
menggunakan model ini? Model ini bisa kita gunakan ketika software yang dikembangkan
membutuhkan perubahan baru update dapat diimplementasikan dengan cost yang lebih
murah. Terus untuk implementasi fitur baru developer hanya akan kehilangan pekerjaannya
ya beberapa hari lah atau mungkin beberapa jam untuk melakukan role back dan
implementasi terhadap perubahan-perubahan yang ada.Jadi enggak butuh waktu banyak juga
terus kalau kalian punya limited planning kalian juga bisa menggunakan agile model ini.
Karena pasti akan ada perubahan nah kalian tertarik enggak pakai agile model ni
dibandingkan model-model yang lain saya sih kalau untuk untuk startup atau yang ingin
belajar tentang agile model ini penerapannya di software indusrty ini bagus.

Prototype Model
prototype model ini basic idea dari prototype ini sebenarnya itu mengutamakan prototype
untuk lebih mengerti tentang requirement dari software yang dikembangkan itu. Jadi biar user
biar developer dan biar seluruh stakeholder yang ada di dalam software development ini lebih
tau tentang project yang dikembangkan harus dibuat prototype terlebih dahulu karna
prototype itu ya sampel lah gitu contoh. Terus prototype biasa dikembangkan sesuai dengan
requirement-requirement simpel yang ada dengan adanya prototype seperti yang saya bilang
tadi klien dapat lebih merasakan bagaimana software yang dibuat itu bekerja dan
menghasilkan software yang lebih baik karna nanti pasti ada feedback-feedback lagi udah liat
nih dari awal oh gini contohnya. Saya mau seperti ini perubahannya seperti ini ditambahkan a
ditambahkan b gitu. Tujuannya inti dari prototype ini adalah menghasilkan fungsional sistem
sesuai dengan kebutuhan user fungsi-fungsi yang ada yang biasa dibutuhkan itu akan
dihasilkan lewat model ini. Biasanya stage yang ada itu kita mulai dari biasa requirement
gathering ingat ya requirement gathering kita akan fokus dibahas di minggu ke-3 nanti. Terus
setelah requirement gathering masuk ke quick design, setelah desain kita bangun nih
prototype nya baru setelah prototype dibangun masuk ke customer evaluation setelah
customer evaluation kita bisa refining prototype kalau prototype yang enggak sesuai atau
nggak oke desain ulang desain ulang dong ganti-ganti kita balik lagi ke quick design tadi baru
putar ke building prototype balik lagi ke customer evaluation sampai itu benar-benar oke baru
kita masuk ke engineering the product kita bikin yg product yang benar-benar jadi. Setelah
prototype nya sudah oke terus kelebihan utama dari prototype model ini adalah yang pertama
itu user aktif berkontribusi terhadap pengembangan softwarenya karna dengan metodologi ini
itu dapat menghasilkan prototype user dapat lebih mengerti sistem yang sedang
dikembangkan itu seperti apa terus error dapat ditemukan lebih awal. Yang berikutnya adalah
user feedback yang lebih cepat dapat menghasilkan solusi yang lebih baik. Yang terakhir
kelebihannya adalah missing functionality dari software yang kita kembangkan itu dapat
ditemukan lebih mudah dan lebih wall. Tapi pasti ada kelebihan dan kekurangan kan seperti
model-model yang lainnya. Biasanya kekurangan dari model ini metodologi ini dapat
menghasilkan software yang lebih kompleks karena scope of project nya memungkinkan
untuk di ekspan dan jauh dari ekspektasi kita di awal. Lalu user biasanya bisa bingung ni
yang mana aplikasi yang mana prototype. Ini prototype mana aplikasi yang jadi mana gitu
jadi kadang bingung biasanya ada user yang seperti itu. Terus effort yang dilakukan untuk
membuat prototype bisa jadi terlalu berlebihan jika tidak di monitor dengan baik. Karena tadi
terlalu fokus bangun prototype produk yang aslinya sampai terbengkalai. Kapan kita bisa
menggunakan prototype model ini? Yang pertama itu saat software yang dibuat itu
membutuhkan banyak sekali interaksi dengan user. Terus biasanya online software atau web
itu membutuhkan banyak interaksi dengan user. Jadi untuk menggunakan prototype model ini
untuk pengembangan online software dan web itu sangat cocok gitu untuk prototype terus
yang terakhir kapan kita harus menggunakan model ini adalah ketika end user akan selalu
menguji softwarenya dan memberikan feedback pada prototype yang dibuat untuk
menghasilkan usable system. Intinya harus kolaborasi di prototype model ini. Udah kita
bahas semua tuh beberapa model-modelnya saya sudah ada di penghujung model yang
prototype ini ini udah habis saya simpan dulu di dapur sampai ketemu di section berikutnya.

Memilih Software Development Model

mostly perusahaanperusahaan di Indonesia sekarang banyak menggunakan model kalau
enggak waterfall ya mereka pakai agile gitu. Nah untuk memilih software development life
cycle model ini ada beberapa step yang perlu kita perhatikan. Yang pertama kita harus benar-
benar mempelajari dan mendapatkan insight dari setiap model yang ada gitu. Jadi enggak kita
enggak cuman tau aja nih ada model prototype, ada model RAD, ada model agile gitu. Jadi
kita harus benarbenar mengetahui flow nya, proses-proses yang ada itu apa saja yang terjadi,
gimana aja stage nya apa aja, kelebihan nya apa, kekurangannya apa, kapan kita bisa
menggunakan soft model yang ada terus ketika kita memilih modelnya itu kita harus benar-
benar fokus dan belajar ke domain tersebut gitu karena kita juga harus belajar tentang bisnis
kriterianya, bisnis objektif nya belum lagi teknikal kapabiliti dari tim yang ikut
mengembangkan software yang ada gitu. Terus teknologi constraint nya dan juga konsen-
konsen dari setiap stakeholder dari project yang ada. Terus biasanya nih kriteria-kriterianya
ni ada size optim nya misal berapa orang gitu itu menentukan juga ini pemilihan model terus
skill set nya apa saja gitu. Kalau misal project yang kita gunakan yang ingin kita kembangkan
itu maunya cepat kita pakai model apa gitu kalau proyeknya itu long term kita pakai proyek
apa. Jadi kita pakai model spiral itu untuk project yang jangka panjang terus teknologinya
juga kita harus paham kualitas dari requirementnya terus tipe-tipe off project, Kebutuhan
dokumentasi juga itu perlu diperhatikan ketika memilih model. Kalau agile kan seperti kita
tahu enggak banyak dokumentasi yang dihasilkan dari model tersebut. Terus kompleksitas
sistemnya, project managementnya, costnya juga ini penting banget. Jadi untuk menentukan
itu sangat ribet sekali sih milihnya nah ada beberapa faktor tadi ada dilaptop saya sebentar
saya cari dulu beberapa faktor yang bisa kita gunakan untuk menentukan model yang ingin
kita gunakan. Misal faktor-faktor yang pertama nih faktor yang pertama itu unclear user
requirement jadi kalau user requirement nya enggak bagus itu gimana gitu kalo untuk model
waterfall itu nggak direkomendasikan terus kalau V model kalau requirement enggak jelas ini
juga enggak direkomendasikan. Kalau prototyping masih bisa direkomendasikan tapi kurang
baik nah yang lebih baik untuk faktor yang unclear of user requirement ini adalah model
spiral dan model agile ini sangat direkomendasikan terus faktor berikutnya adalah unfamiliar
technology, unfamiliar technology ini kalau kita menggunakan model waterfall, V model dan
agile ini enggak cocok kalau untuk unfamiliar technology. Yang paling cocok untuk faktor ini
adalah model prototyping dan model spiral atau bisa juga menggunakan incremental dan
iterative. Kalau kebutuhannya kompleks sistem faktornya sistemnya harus benar-benar
komples ni nah yang bagus itu kita sebaiknya menggunakan model prototyping dan model
spiral atau bagus juga menggunakan incremental dan iterative. Terus kalau faktor yang
inginkan itu adalah relayable system nah ini satu-satunya yang paling bagus itu adalah spiral.
Spiral itu kalau untuk long term yang relayable kan pengembangannya akan dilakukan terus-
menerus di spiral ini itu bagus. Terus kalau untuk jangka pendek yang paling bagus itu
incremental dan iterative juga agile. Nah itu adalah faktor-faktor dan cara pemilihan dari
model yang ada di software development life cycle.
Minggu 3 : Software Development Process 2
1. Apa itu requirement gathering?
Mendapatkan bisnis requirement nya untuk mengetahui lebih jelas tentang the hole
business proccess dari software yang dikembangkan sehingga nanti output dari gathering
requirement ini adalah teknikal specification baru nanti kita bisa sign off kontraknya oke
kita bisa deal dan lanjutkan project nya. Biasanya itu bisnis requirement contohnya nih
contohnya itu saya ingin akses website yang aman gitu teknikal specification nya seperti
sempat saya bilang di minggu pertama itu ada login page nya, ada database of user nya,
ada password, email terus ada authentication proses hingga kita bisa menggunakan
sertifikat dan SSL. Contoh lainnya adalah Saya ingin mengupload media image gambar
atau video ke profil saya gitu. Nah itu teknikal specification kayak gimana? Kita bikin tuh
butirbutirnya oh ini bikin membership website, terus ada user authentication, ada profile
page nya, ada database user, ada gallery, ada upload function dan ada banyak dan upload
function> dan ada display foto itu untuk technical specification sampelnya. Ketika itu
udah oke nanti customer dan solution architect atau orang yang diberikan mandat untuk
mengurus proyek tersebut dari perusahaannya akan melakukan sign kontrak. Sign kontrak
oke nanti bisnis requirement nya kita pindahkan ke teknikal specification baru bisa dibuat
wireframe nya setelah wireframe oke kita udah bisa bikin project plan dan organization
plan nya baru dijabarkan tuh di dalam diagram proses description usecase nya apa, detail-
detail dari prosesproses yang apa yang ada itu apa saja. Untuk pembuatan diagram
tersebut itu akan kita bahas di minggu berikutnya. Biasanya itu seorang solution arsitek
ketika mendapatkan hasil dari gathering requirement ini dia udah bisa make sure nih
timeline dan maston akan bagaimana deliverable nya kayak gimana Terus dia udah bisa
mulai menentukan roles dan responsibility dari setiap orang yang ada di project tersebut.
Terus dia juga bisa membuat NDA, quality level dari sebuah project dan yang terakhir
bisa membuat reporting dan desain review untuk melanjutkan ke tahap yang berikutnya.

2. Ketidakpastian dalam teknikal dan Identifikasi solusi

Setelah kita mendapatkan informasi dari gathering requirement ada beberapa hal lagi
yang tidak pasti itu biasanya disebut dengan teknikal uncertainty atau ketidakpastian dari
sebuah teknikal thing. Jadi biasanya itu berasal dari kita menggunakan teknologi yang
tepat tetapi kita gagal accomplish gol yang sudah ditentukan di requirement penyebab-
penyebabnya apa? Biasanya itu lack of knowlede atau skill atau tidak pede untuk
mengembangkan aplikasinya gitu. Terus tim resource nya atau resource-resource yang
mengembangkan software tersebut mereka enggak punya pengalaman dengan teknologi
yang digunakan di proyek tersebut. Misal dokumentasi API yang kurang, bahasa-bahasa
pemrograman yang tidak bisa dimengerti oleh mereka ini kan enggak begitu paham terus
penggunaan IDI mereka gak terlalu ngerti jadi itu adalah hal-hal di teknikal uncertainty
terus biasanya itu akibat dari hal-hal ini tuh teknik ketidakpastian teknikal itu biasanya itu
API nya gagal terus ketidakmampuan untuk membangun algoritma untuk software yang
dikembangkan. Karena kalau algoritmanya tidak kita mengerti gimana jadinya software
yang kita kembangkan gitu. Nanti bakal banyak waktu lagi untuk belajar algoritma nya
banyak waktu lagi untuk ngerubah ngerubah sistemnya bagaimana gitu tapi biasanya
organisasi yang matur itu perusahaan yang matur itu menggunakan kebanyakan itu
production API ini contoh untuk API nya tapi ini enggak IX405 menutup kemungkinan.
Itu jauh dari kata software yang cacat enggak kemungkinan ketika menggunakan
production API ini jadi ketika sebuah organisasi menggunakan nonproduction API atau
biasa kita sebut staging bisa juga alfa atau beta untuk development jadi kita juga bisa di
situ tuh bisa ngelihat nanti oh API yang gagal itu seperti apa gitu itu akan lebih muda
ketika berada di staging. Terus beberapa risk associated with the technology gitu jadi risk
that efective the API itu itu akan mencoba mencari API-API yang lain gitu terus enggak
bisa menentukan solusi yang tepat untuk project yang sedang dikembangkan. Nah itu hal-
hal itu kadang tidak pasti itu ketika pengembangan itu itu terjadi karena ketika kita
mengumpulkan gathering requirement itu itu enggak jelas gitu Kita harus menghindari
ketidakpastian terhadap teknologi yang ada. Kenapa software yang dihasilkan oleh
perusahaan-perusahaan besar seperti Microsoft, Google atau seperti Apple itu sangat
bagus gitu. Kenapa? karena mereka sebelum memulai mengembangkan software tersebut
mereka tentunya melakukan identifikasi terhadap solusi yang ada sebelum mereka
melakukan deliver ke final solution nya. Nah biasanya itu gimana sih biar kita tahu itu
identify the solution of a problem ada beberapa pertanyaan ini biasanya dilakukan di
interview gathering requirement misal pertanyaannya adalah what is your final product?
Terus which tehnology di WeChat teknologi do you need? Teknologi apa aja nih misal
mau menggunakan teknologi yang menggunakan bahasa pemrograman python,
menggunakan golang, menggunakan ruby, java itu mulai menganalisa di sini. Terus what
are the main building block of your project? Jadi apa aja yang akan dibangun gitu di
dalam project tersebut terus which are you deliverable biasanya deliverable nya gimana
nih untuk project nya terus pertanyaan lainnya itu how to organize your work to specific
the requirement? Itu contohnya juga terus pertanyaan-pertanyaan lain yang sering masuk
ketika kita melakukan identifikasi terhadap sebuah masalah untuk menemukan solusi ini
contohnya ini aplikasi desktop apa mobile, ini aplikasi web apa gimana. Ini platform as a
service, software as a service atau as a service lainnya gitu harus responsif enggak bisa
diakses dari mobile, bisa diakses dari desktop dan bisa diakses dari device apa aja. Butuh
data protection enggak pertanyaan-pertanyaan yang sering dilakukan untuk
mengidentifikasi problem-problem yang ada untuk menemukan solusinya. Nah biasanya
final product itu yang dibikin itu bisa itu website, bisa itu mobile app, bisa itu
membership site seperti Facebook, Linkedin, Twitter yang punya fitur membership site,
bisa itu multimedia platform seperti YouTube terus bisa juga content management system
seperti jumlah. Main building block IX405 yang ada di dalam software final product
tersebut di antaranya adalah ada frontend, ada backend, ada admin area terus di dalamnya
akan ada interfaces, terus ada juga web services yang dibutuhkan untuk aplikasi itu
berjalan. Nah the hole building blocks itu kita harus bisa identifikasi juga karena item-
item yang ada di dalam building blocks itu juga itu akan banyak lagi gitu contoh di
frontend, frontend ini biasanya ini untuk website contohnya itu tampilan depan paling
depan yang diakses oleh enduser Ini biar responsif gimana nih kita bisa menggunakan
framework apa, kita bisa menggunakan reactjs, kita bisa menggunakan vueJS, atau kita
cuman menggunakan jack query aja. Terus di backend nya, backend kebutuhannya
mereka butuh cepat enggak gitu kalau cepat kita bisa pakai python kalau lama stable dan
low risk mungkin bisa pakai java mau yang lebih ekstrem gak? Kita bisa pakai rust atau
pakai golang untuk pengembangan backend nya Terus admin areanya nanti di dalamnya
ada fungsifungsi misal untuk manajemen usernya, untuk membuat, mengupdate,
menghapus dan beberapa aktivitas pengolahan user dan konten di dalam sebuah platform
tersebut. Terus web service nya apa, infrastrukturnya gimana itu harus benar-benar kita
lakukan identifikasi dari awal dan semua proses itu terjadi di gathering requirement ini

3. Identifikasi skills dan Organize work

Tadi kita sudah cari tahu cara bagaimana mengidentifikasi solusinya. Nah sekarang kita
bagaimana mengidentifikasi skill dan teknologi yang dibutuhkan untuk membuat
software yang kita kerjakan ini. Pertama adalah teknologi yang dibutuhkan itu apa itu.
Tadi saya udah bilang sample nya itu ada mau kita buat website, mau kita buat mobile
app, membership site, multimedia platform atau content management system. Contoh
yang pertama yang website teknologi yang digunakan untuk membangun website itu
biasanya adalah yang pertama itu hypertext markup language atau biasa disingkat HTML.
Yang kedua adalah cascading style sheet. Yang ketiga adalah javascript atau javascript
framework lainnya seperti react, vueJS atau bisa juga menggunakan jack query itu untuk
pengembangan website. Terus kalau kita ingin membangun mobile application nah untuk
membangun mobile application yang populer itu ada 2 platform ada IOS, ada android
kalau kalian ingin mengembangkan platform IOS berarti skill set dan teknologi yang
dibutuhkan adalah swift programming language dan objective C. Terus kalau untuk
android yang harus dipelajari atau teknologi yang digunakan adalah kotlin dan java untuk
membership site karena ini ada membership berarti membutuhkan database. Database kita
bisa menggunakan mysql, mongo db atau sequel database lainnya. Untuk backend nya
biasanya membership site ini kita bisa menggunakan PHP, bisa menggunakan python,
bisa menggunakan java, ruby atau C sharp. Terus untuk content management system ini
banyak digunakan untuk blog atau website-website. Biasanya orang-orang menggunakan
wordpress, orang-orang menggunakan jumlah atau drupal. Terus yang lebih kompleks
lagi multimedia platform nah ini agak kompleks karena itu ada multimedia resource nya
harus dari mana ini. Kita bisa menggunakan API application programming interface, kita
menggunakan YouTube API untuk mengambil konten-konten YouTube, konten-konten
video yang ada bisa menggunakan Facebook API terus kita bisa membuat video
streaming application nya. Nah itu tentang melakukan identifikasi skill dan teknologi
yang dibutuhkan. Berikut adalah world organization sebelum kita melakukan menentukan
software project dan arsitektur yang digunakan Kita harus melakukan organize proyek
yang kita kerjakan. Nah yang pertama kita harus menentukan dulu wireframe nya
wireframe nya kayak gimana Kita harus bisa membuat visual desain nya, yang berikutnya
kita harus membangun database arsitekturnya, jadi database arsitekturnya kayak gimana
itu harus kita buat juga tuh harus kita organize semuanya, harus di manage terus ada juga
kita membangun prototype terus bisnis logic atau workflow nya baik itu di high level
design atau low level design. Nah itu dibutuhkan juga untuk kita membuat pekerjaannya
lebih mudah gitu lebih tertata aja termanage lah gitu semua kerjaan development yang
kita kerjakan gitu. Terus setelah hal-hal tersebut itu disebutnya teknikal briefing dari
teknikal briefing tersebut itu muncullah testing specification. Di testing specification ini
itu ada yang namanya test case, ada namanya testing environment description dan
acceptance criteria. Nah di testing ini adalah yang menentukan kualitas dari software
yang kita kembangkan akan jadi seperti apa nantinya dan itu harus kita tata sebelumnya di
gathering require di proses gathering requirement ini. Semuanya harus lebih jelas. Oke
Kita sudah melihat tadi cuplikan video bagaimana seorang developer atau seorang
solution arsitek melakukan interview untuk mendapatkan detail-detail dari software yang
ingin dikembangkan oleh kliennya. Dari situ dari pertanyaan-pertanyaan itu kita udah bisa
tahu tuh gimana sih sebenarnya cara mengumpulkan requirement yang ada gitu. Itu saja
untuk minggu ke-3 untuk pembahasan tentang software development ini. Kita akan
berjumpa di minggu ke-4 yang akan kita bahas adalah tentang desain kita akan bahas lebh
lanjut di sana mulai dari week ke-4 sampai week ke-5 dan ke-6 kita akan lebih banyak ke
praktikal. Sampai jumpa di minggu berikutnya.
 Minggu 4 : Software Architecture
1. Software Architecture
Seorang developer itu bertanya apa saja kebutuhan dari kliennya. Mulai dari aplikasinya
sebesar apa, aplikasi yang akan digunakan oleh siapa saja dan berbagai bisnis requirement
yang dibutuhkan oleh klien agar dia bisa menghasilkan aplikasi yang diinginkan. Nah dari
situ developer itu harus menghimpun semuanya. Semua kebutuhan di situ nanti itu dirubah
dari bisnis requirement menjadi teknikal requirement. Setelah itu, kita baru bisa membuat
yang namanya software arsitektur dan desain.
Software arsitektur ini itu bagaimana kita membuat layout dari sebuah sistem yang ingin kita
bangun.
Blueprint dari sebuah sistem dijelaskan atau digambarkan secara singkat saja ya bisa disebut
ini high level design dari software yang akan IX405 kita kembangkan. Setelah itu cara
biasanya cara seorang developer membuat software arsitektur ini ada berbagai pilihan. Biasa
digunakan itu ada 3 yang pertama itu menggunakan UML atau unified modeling language.
ini merupakan sebuah solusi untuk object oriented biasanya di dalam membuat modeling
untuk software dan juga untuk membuat desain-desain software yang kita kembangkan. Terus
ada juga yang ke-2 yaitu arsitektur V model atau biasanya 4+1 V model. Jadi ini biasanya itu
enggak represent fungsi dan non functional requirement dari software yang kita kembangkan.
Yang ke-3 itu itu arsitektur description language atau ADL. Jadi ini biasanya itu kita
menjelaskan software itu secara keseluruhan arsitekturnya bagaimana itu secara formal dan
secara semantik.
software desain ini kalau kelebihannya itu itu untuk memudahkan seorang stakeholder dari
software yang kita kembangkan untuk berkomunikasi dengan developer. Terus nanti ke
depannya juga akan membantu seorang sistem analis untuk melakukan verifikasi kepada
sistem yang dikembangkan apakah itu tuh suatu aplikasi tersebut memenuhi kriteria dari
software yang dikembangkan atau tidak. Software desain ini juga bermanfaat ketika kita
mengembangkan aplikasi yang sangat besar atau large scale.
biasanya di arsitek arsitektur dari sebuah sistem yang lebih besar itu itu memiliki banyak
sekali komponen, banyak komponen, banyak package di dalamnya. Jadi ketika kita
menggunakan software desain yang lebih bagus menggunakan software arsitektur yang lebih
bagus ini akan mempermudah kita ke depannya untuk mengembangkan terus untuk project
planning juga akan lebih mudah ketika kita mengimplementasikan software arsitektur dan
software desain ini juga termasuk diproses quality assurance quality atribut yang ada di
dalamnya nanti itu akan sangat bermanfaat. Terus untuk di software desain, software desain
itu biasanya memiliki beberapa proses gitu. Proses yang pertama yang dilakukan ketika
developer atau seorang analis membuat software desain itu dibutuhkan yang namanya
software requirements specifications. Di situ tuh jelasin semuanya tentang functional atau
non IX405 functional requirement nya harus dijelaskan secara clear gitu harus jelas semuanya
di situ baru nanti dari software requirement specification nya itu dibuat yang namanya high
level designnya. High level design dibuat terus nanti dibuat lagi yang namanya detailed
design. Jadi dari spesifikasi masuk ke high level design terus masuk ke detail design. Yang
menjelaskan tentang aktivitas-aktivitas yang ada apa aja yang ada di dalam software yang
kita kembangkan. Terus relasi antara software arsitektur dan software design seperti yang
udah dibilang tadi relasi keduanya ini sangat perlu sekali karena software arsitektur itu
menjadi bagian utama dari kebutuhan kita untuk mengembangkan software. Baru setelah kita
masuk ke software arsitektur tersebut kita akan bisa lebih mudah masuk ke dalam software
desain
2. Komponen
ketika kita membangun sebuah aplikasi itu kita harus membagi aplikasi kita ke beberapa
komponen. Ketika kita membuat komponen itu akan memudahkan kita untuk
mengembangkan aplikasi yang lebih besar atau yang lebih scalability nya lebih bagus ke
depannya. Tapi di komponen ini ada beberapa hal yang perlu juga dibutuhkan atribut-
atribut nya apa aja. Yang pertama adalah replaceable. Replaceable ini maksudnya
komponen yang kita buat itu bisa diganti sedemikian rupa dan bisa diganti kapanpun
ketika inginkan. Misal ketika kita ingin membuat sebuah komponen di dalam aplikasi kita
komponen namanya komponen user gitu. Di dalam komponen user itu ada atribut apa aja
di dalamnya nanti misal ada first name, ada last name, ada e-mail. Nah itu komponen
tersebut bisa kita rubah kapan aja itu possible untuk pengembangan ke depannya. Yang
berikutnya adalah independen. Jadi biasanya kalau di object oriented programming itu
komponen itu bisa diekspresikan dengan objek gitu. Jadi ketika kita membuatnya itu
objek tersebut benar-benar independen gitu di dalam sebuah komponen tersebut. Terus
komponen tersebut harus bersifat serializable. Yang IX405 berikutnya reusable sama
dengan yang replaceable tadi tapi reusable ketika komponen tersebut ingin digunakan lagi
baik itu untuk koneksi dengan komponen lainnya, integrasi dengan aplikasi yang berbeda
itu bisa digunakan kembali. Terus komponen ini harus bersifat non context spesifik dan
juga harus bersifat extensible. Extensible ini maksudnya kita bisa mengembangkan
komponen tersebut semau kita kedepannya entah kita mau ngembangin komponen itu
lebih luas lagi seperti contohnya yang komponen user tadi. Jadi ada penambahan field-
field seperti field city, field country itu pengembangan-pengembangan berikutnya dari
komponen. Sifat extensible ini itu sangat diperlukan. Nah software komponen itu akan
lebih efektif kalau seorang developer itu bisa membuat dokumentasinya lebih baik. Nah
ini perlu banget buat developer kalau dokumentasi dari setiap komponen di dalam
aplikasi kita tidak bagus itu komponen tersebut tidak akan bisa digunakan lagi atau
developerdeveloper lain yang ingin menggunakan komponen tersebut itu akan mengalami
kesulitan kedepannya. Jadi diperlukan dokumentasi yang benar-benar jelas. Terus kalau
menggunakan komponen best design ini itu benefitnya apa sih buat developer, buat orang
businessman, buat seorang klien Jadi benefitnya itu ini mudah untuk dikembangkan
mudah juga untuk dilakukan deployment. Terus untuk mengurangi juga meminimalisir
biaya-biaya yang ada. Karna lewat komponen ini akan mempermudah developer dan
klien. Terus reusable seperti yang Saya bilang tadi sebelumnya terus modification of
technical complexity nya ini juga bagus banget ketika kita menggunakan komponen best
design dan yang berikutnya adalah reliability, reliability dari komponen best design ini ini
sangat bagus banget. Terus sistem maintenance dan evolution nya bersifat independen
dan juga itu better ketika tes ability nya. Jadi ketika dilakukan quality assurance ketika
dilakukan uji coba komponen best design ini sangat bagus untuk developer dan untuk
seorang klien. Nah itu benefit tentang komponen best design. Terus guideline gimana
untuk membuat komponen desain ini lebih bagus gitu biasanya itu kalau untuk komponen
itu bikin naming convention lebih baik. Terus connect arsitektur komponennya dengan
domain-domain aplikasi yang kita kembangkan. Terus spesifikasi dependensi antara
komponen yang ada gitu itu harus tersambung gitu tersambung dengan baik. Itu saran dari
saya untuk membuat komponen best design.

3. Interaction Oriented Architecture

salah satu modeling approach untuk memisahkan interaksi antara user dari data
abstraction dan data prosesinya. Sekarang Anda sudah berada dalam layar laptop saya.
Sesi ini Saya ingin membahas tentang interaction oriented arsitektur. Arsitektur ini adalah
sebuah modeling approach untuk memisahkan interaksi dari seorang user, dari data
abstraction dan bisnis data processing. Nah biasanya ada terima your part yang
memisahkan di interaction oriented arsitektur ini. Yang pertama yaitu data modul. Data
modul ini dia akan memprofit data abstraction, data extraction sorry dan semua bisnis
logic. Terus ada yang ke-2 itu kontrol modul. Kontrol modul itu dia akan
mengidentifikasi flow apa aja yang ada. Jadi akan mengolah flow-flow yang ada di dalam
sistem semua konfigurasi akan diolah oleh kontrol modul. Baru yang ke-3 itu adalah view
modul View modul itu merupakan persentasi. Jadi itu apa yang akan dilihat oleh user
nanti. Nah biasanya untuk interaction oriented arsitektur itu ada 2 mayor style. Yang
pertama yaitu model view controller dan yang ke-2 presentation abstraction control atau
PAC. Tapi kita akan membahas MVC saja di sini Pembahasan software developer
fundamentals ini karena MVC ini adalah interaction oriented arsitektur yang paling
banyak digunakan oleh developer. Yang pertama itu ada namanya model di sini. Jadi
model di sini itu berisi tentang data, logic, constraint dari seluruh aplikasi kita. Nah dari
model ini dia akan mengupdate jadi model akan meng update ke view. Nah view ini itu
akan menghasilkan tampilan yang bisa dilihat oleh user. Jadi ini view ini bisa saja berupa
form, berupa sebuah halaman website, bisa sebuah grafik dan sebagainya. Yang jelas itu
yang akan dilihat oleh user. Lalu ketika user berinteraksi dengan aplikasi kita apa aja
yang dilakukan oleh user gitu, inputinput apa saja misal user nya melakukan input
terhadap form. Jadi secara tidak langsung user itu menggunakan yang namanya
controller. Jadi controller ini dia yang akan mengolah seluruh data yang mengkonversi
input dari user terus dimasukkan ke model. Nah circle ini akan terus berlanjut. Ini adalah
namanya MVC, circle ini akan terus berlanjut di software yang kita kembangkan dan
proses proses ini tidak akan berhenti sampai user berhenti menggunakan aplikasi kita.
Jadi dari model update ke view user melihat lalu user yang menggunakan mereka
mengakses controller lalu controller mengolah dan menghasilkan output ke model yang di
mana yang lagi akan dilihat secara langsung oleh user.

4. Security
software security ini sebenarnya ini non functional requirement dari sebuah server sistem.
Biasanya tuh jarang sekali orang-orang yang memikirkan tentang software security ini,
Kenapa? Karena banyak klien atau banyak orang-orang yang ingin aplikasinya serba jadi
saja gitu jadi eh developer saya mau aplikasi saya dibikin dalam 2 minggu semua kelar
gitu. Nah seorang bisnis dia enggak mikirin gitu kalau software tersebut harus dibangun
security nya seperti apa. Kalau kaya gitu dibangun 2 minggu saja sudah kelar tanpa kita
memperhatikan security ke depannya pasti akan banyak kasus-kasus seperti data leak jadi
privacy-privacy user nya ke publish semua di internet itu karena software security nya
yang kurang bagus ketika proses pengembangannya. Nah di software security ini
sebenarnya minus nya kenapa orang-orang itu tidak suka karena ini meningkatkan
maintenance cost nya. karna security itu ada hal yang wajib sebenarnya di dalam software
di dalam kehidupan kita juga keamanan itu kita perlukan. Kalau di software itu per detik
per jam ya per hari ya kapan pun itu kita pasti butuh yang namanya software security ini
karena seperti kita tahu banyak sekali hacker-hacker yang berada di luar sana begitu
blackhead, greyhead mereka iseng-iseng buat ngutak-ngatik software kita gitu. Karena
kita nggak mikirin tersebut, hal tersebut keamanan sistem kita terganggu ya banyak sekali
data leak gitu. Terus biasanya juga ada yang namanya sistem down time terus loss of
productivity ini sering sekali terjadi. Kalau kita tidak mengimplementasikan software
security kepada aplikasi yang kita kembangkan itu. Terus faktor-faktor yang ada ketika
ingin mengembangkan information system security ini biasa seperti distributed system
terus penggunaan internet sebagai solusi dari aplikasi yang kita gunakan terus the use of
third party web service ini adalah hal-hal yang perlu diperhatikan juga gitu. Contoh ketika
kita menggunakan third party kita ingin integrasi aplikasi kita dengan Facebook misalnya,
dengan Google. Ketika kita melakukan integrasi tersebut itu kita perlu memikirkan juga
keamanan dari sistem kita data user kita bagaimana apakah integrasi tersebut ada
perlindungan datanya ataukah ada bug-bug yang ada di dalam proses integrasi software
tersebut. Nah biasanya kalau di security itu itu ada namanya integrated arsitektur
framework. Nah di integrated arsitektur framework ini nanti saya akan berikan dokumen
lengkapnya berupa pdf yang bisa kalian download di menu handout itu bisa kalian
dapatkan grafik yang sangat kompleks bisa IX405 kalian baca dari situ. Terus contoh
utamanya contoh ni untuk kita mengembangkan sebuah komponen yang tadi
komponennya tentang komponen user di dalam user itu ada namanya user access
management. Kan kita taunya ya udah bikin aja gitu komponen user yang penting bisa log
in yang penting bisa registrasi gitu. Biasanya kalau untuk software security itu kita perlu
yang namanya bikin kaya privileges managementnya user password management yang
seperti apa misal menggunakan hash, menggunakan enkripsi apa kepada password kita
jadi nggak sembarang untuk bikin user register sama user log in saja. Terus perlu yang
namanya user access right management. Ini biasanya kalau untuk aplikasi yang lebih
besar lagi, misal saya pernah mengembangkan aplikasi untuk financial disitu tuh ada
beberapa user right access nya. Jadi ada mulai dari user biasa terus ada mulai dari maker
nya terus ada taker nya terus ada lagi adminnya. Itu perlu di define juga fungsi-fungsinya
security nya bagaimana agar ketika user mengakses aplikasi yang kita kembangkan tidak
sembarangan menggunakan aplikasinya dan tidak sembarangan mengakses datanya. Jadi
ketika kita mengimplementasikan software security aplikasi kita akan lebih aman.

5. Software Architecture Performance

software arsitektur performance, modifiability, reusability dan reliability. Jadi ketika kita
membangun arsitektur sebuah software ini sebenarnya adalah sebuah fundamental dari
kita membuat sebuah software gitu. Nah jadi itu menentukan quality atribut, ada quality
atribut ada 4 yang saya sebutkan tadi yang pertama adalah modifiability. Jadi atribut yang
modifiability ini itu dibutuhkan di dalam sebuah software arsitektur. Kenapa? Karna
ketika kita mengembangkan sebuah software itu ketika kita hand over lagi project
tersebut ke developer lain itu possible enggak untuk developer tersebut melanjutkan
project yang sedang kita kembangkan tersebut. Kalau nggak berarti modifiability dan
software tersebut arsitekturnya itu tidak bagus. Terus yang berikutnya adalah reusability,
reusability ini itu biasanya ketika software yang kita kembangkan itu ingin digunakan lagi
atau ingin diintegrasikan dengan softwaresoftware lainnya. Nah ketika hal tersebut tidak
memenuhi kebutuhan berarti reusability dari sebuah software arsitektur tersebut itu tidak
memenuhi kriteria dari quality atribut yang disebutkan. Terus yang berikutnya adalah
reliability. Jadi reliability ini menentukan reliable gak sih software yang sedang kita
kembangkan kalau benar-benar tidak reliable berarti gak IX405 bagus dong untuk
developer berikutnya atau untuk proses integrasi atau software tersebut untuk jangka
panjang berarti tidak bagus gitu. Yang paling utama adalah kalau menurut saya itu itu
performance. Jadi performance dari sebuah software arsitektur sebuah software desain
dan terutama sebuah software itu sangat dibutuhkan karena ketika performance dari
sebuah aplikasi misalnya aplikasi yang kita kembangkan ini e-learning gitu. Jadi ketika
elearning tersebut performance tidak bagus sering down berarti itu akan membuat moral
dari user kita pelajar-pelajar yang ada di e-learning platform tersebut itu kecewa dan
kebanyakan dari mereka akan meninggalkan platform atau aplikasi tersebut dan pindah ke
aplikasi lain. Terus produktivitas dari user atau pelajar yang menggunakan platform kita
 itu akan berkurang dan pastinya revenue dari aplikasi yang kita kembangkan tersebut itu
akan berkurang juga. Terus untuk performance ini kenapa benar-benar penting karna ya
seperti itu biasanya kalau developernya mood-mood-an untuk mengembangkan
aplikasinya sehingga performance dari aplikasi tersebut tidak bagus ya benar-benar rugi
jadinya kliennya gitu. Nah itu untuk quality atribut di dalam software arsitektur.

6. Case Study
case study e-learning platform.

7. Case Study – Wireframe

8. Case Study – Wireframe

Implementation and Version Management

A. Fase implementasi
1. Instalasi all the applications, toolsand infrastructures needed to develop the final
software solutions. If you are using different systems, you need to have an
instalation plan.
2. Configurations  once you finished your instalation, you may need to implement
some configurations for the installed tools or for the infrastuctures or system hosting
you tools and applications
3. Development  this is where the functional leads transfer to business requirements
to the technical team and the technical team begins the work of programming and
configuring. According to the development method the process is different in Agile
projects development phases include also verification and validation process. 
coding phase
4. Integration  if you are going to use available in house components, or third party
compnents (e.g. OS or COTS) you need to have integrations in your team. They have
to coordinate with the team and integrate the different components to the final
solutions.
5. Deployment  it refers to installing the code where it can be used. You can deploy
released code, or code that is no where ready for release. In web deployment, it
common to deploy code to a test environment before testing it.

Developer harus memiliki :

1. Multi-Skills, software developers should roughly know what system administrators,
testers, integrations, etc. to understand how to act in the various phases and to
know what other roles request.
2. programming style the development team members should use naming and coding
conventions when writing software codes and also comment their software code to
be easily used by others
3. training, if it is needed the development team members should be trained for new or
updated technologies of methodologies.

In this phase the teams need to know and implement the following processes with the
repective tools
1. version management, the various releases have different versions and the team
members have to know how to generate software rekeases (where all parts and
components are integrated and tested)
2. Incident Management, during the development bags, errors and missing
functionilites may be some of the main issues encountered. The team members
need to know how to retrieve or register the information related to these issues and
issue tools e.g. JIRA to manage the issues and communicate the release of fixes.
3. Risk management is a task that must be conducted constantly to prevent costs and
delays during the project execution.
4. Documentation Management this is crucial process during the development phase.
In this way their deliverables can be easily and quickly understood by those that
need to implement their result s for their next work.
5. Change management, every team member has to be involved in the change
management process. This is usually implemented at the end of the development
phase at the end of the project in the maintenance phase, but you can have also
change requests during the development process if this is allowed or recommended.

Software Configuration Management (SCM) is a software engineering discipline

consisting of standard processes and techniques to manage the changes introduced to
software products.
Gunakan git atau github untuk melakukan integrasi agar memudahkan deployment.

B. PROSES DEPLOYMENT
Cara mem-publish aplikasi.

Continuous Integration (CI) dan Continuous Delivery digunakan untuk memudahkan

proses deployment. Harus membuat deployment checklist, tools apa yg digunakan, tools
apa yg cocok untuk software yang dikembangkan.

C. VERSION MANAGEMENT
When you have defined your release plan, version management is your tool to track the
various releases.
Dilakukan ketika terjadi penambahan penambahan fitur tertentu pada software. Untuk
melakukan tracking terhadap perubahan perubahan tersebut, maka harus dibuat version
management. Bisa digunakan tools, seperti github.

GO LIVE DAN MAINTENANCE

Go Live Process

Kendala yang terjadi pada saat Go Live : gagal login, tidak bisa enroll, tidak bisa
download video, tidak bisa akses kursus, dsb.

Maintenance
Software Maintenance Process terdiri dari :
1. Preparation
2. Request
3. Analysis

Proses Maintenance