Perbedaan Software Engineering & System Engineering

Ada yang bertanya, apa sih perbedaan antara "Software Engineering" dan "System Engineering" ?

Sekilas kedengarannya hampir sama, tetapi sebenarnya ada perbedaan yang

mendasar, penjelasannya akan saya bahas secara singkat di bawah ini..

System Engineering mempunyai kaitan dengan semua aspek pengembangan

sistem berbasis-komputer yang mencakup perangkat keras, perangkat lunak, dan
yang terkait dengan proses bisnis.

Sedangkan Software Engineering lebih berkonsentrasi pada komponen perangkat

lunak system yang lebih besar.

http://ciez-jabz.blogspot.co.id/2015/02/perbedaan-software-
engineering-system.html
System Engineering adalah suatu disiplin rancang-bangun yang
mana bertanggung jawab menciptakan dan melaksanakan proses
disiplin untuk memastikan bahwa pelanggan dan kebutuhan
stakeholder's terpuaskan dengan kualitas tinggi, terpercaya,
efisiensi biaya dan menjadwalkan cara memenuhi sepanjang
keseluruhan jalan kehidupan. Proses ini pada umumnya terdiri atas tujuh tugas: Satukan
masalah, alternative penyelidikan, model system, Mengintegrasikan, peluncuran system, Nilai capaian, dan evaluasi
kembali. Fungsi ini dapat diringkas dengan singkatan Similar: State, investigasi, Model, integrate, launch, Nilai dan
Re-Evaluate.
http://mariejeearekuwks.blogspot.co.id/2013/03/system-
engineering.html

Software engineering termasuk bagian dari ilmu komputer, lebih

tepatnya yaitu pengembangan dan pembangunan software sistem
komputer dan software aplikasi. System software terdiri
dari program yang mengatur utilitas komputisasi dan sistem
operasi. Aplikasi software termasuk user-focusedprogram,
seperti program database, web browser, dan lainnya.
https://medium.com/@makersinstitute/apa-itu-software-
engineering-8d0a9e5bea71

Spesifikasi kebutuhan Perangkat Lunak

23 March 2013Munadatan Nadiah

Kebutuhan Perangkat Lunak adalah kondisi, kriteria, syarat atau kemampuan yang
harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau
diinginkan pemakai.

Jenis perangkat lunak :

1. Kebutuhan fungsional : kebutuhan yang berkaitan dengan fungsi atau proses

transformasi yang harus mampu dikerjakan oleh perangkat lunak.

contoh : perangkat lunak harus dapat menyimpan semua rincian data pesanan
pelanggan

2. Kebutuhan Antarmuka : kebutuhan yang menghubungkan perangkat lunak dengan

elemen perangkat keras, perangkat lunak, atau basis data.

contoh : perangkat untuk input data dapat berupa keyboard, mouse, dan scanner.

3. Kebutuhan unjuk kerja : kebutuhan yang menetapkan karakteristik unjuk kerja yang
harus dimiliki oleh perangkat lunak

contoh : perangkat lunak harus bisa mengolah data sampai 1juta record untuk tiap
transaksi

Diagram Aliran Data/Data Flow Diagram : Diagram untuk menggambarkan aliaran

data dalam sistem, sumber dan tujuan data, proses yang mengolah data tersebut dan
tempat penyimpanan data.

Aturan Pembuatan Diagram Aliran Data:

1. Setiap proses wajib memiliki data masukan dan data keluaran, selain itu
TERLARANG.

2. Nama proses wajib menggunakan kata kerja

3. Data store tidak boleh mengalir langsung dari/ke data store lain, harus melalui proses
dulu.

4. Data store tidak boleh mengalir langsung ke tujuan data/entitas, harus melalui proses
dulu (idem dengan yang diatas)

5. Nama data store harus menggunakan kata benda

6. Entitas tidak boleh mengalir dari sumber data ke tujuan data, harus melalui proses
(serba lewat proses deh pokoknya)

7. Nama entitas harus menggunakan kata benda

8. Aliran data hanya boleh memiliki satu arah aliran, aliran dua arah hanya boleh dimiliki
antara proses dengan data store yang menunjukkan pembacaan dan peng-update-an
data.

9. Aliran data yang sama yang menuju beberapa proses, data store atau entitas data
yang berbeda, boleh digambarkan bercabang

10. Aliran data yang sama yang dari beberapa proses, data store atau entitass data
yang menuju satu proses tertentu boleh digambarkan bercabang.

11. Aliran data tidak boleh mengalir ke dirinya sendiri

12. Nama aliran data menggunakan kata benda.

Kamus data : merupakan suatu tempat penyimpanan (gudang) dari data dan informasi
yang dibutuhkan oleh suatu sistem informasi. kamus data digunakan untuk
mendeskripsikan rincian aliran data atau informasi yang mengalir dalam sistem, elemen
data, file maupun basis data dalam DFD.

Spesifikasi Proses : merupakan metode yang digunakan untuk menggambarkan

deskripsi dan spesifikasi dari setiap proses yang paling rendah yang ada pada sistem.

*bonus teknik wawancara:

1. pasang wajah manis, perkenalkan diri kamu layaknya sales

2. beritahu dari instansi mana kamu berasal

3. sebutkan keperluan kamu, tidak perlu terlalu detail, cukup garis besarnya saja

4. sebagai pembuka, ajak ngobrol mengenai perangkat yang sedang digunakan

5. biarkan narasumber yang memberi jadwal wawancara

6. jangan menyela, memojokkan narasumber apalagi sok tahu

7. tanyakan hal-hal yang sekiranya diketahui wawancara dan masih sesuai jalur

8. ucapkan terimakasih, jangan main kabur aja

https://catatannadia.wordpress.com/2013/03/23/spesifikasi-kebutuhan-perangkat-lunak/

Kebutuhan Perangkat Lunak

Jenis kebutuhan perangkat lunak dapat dibagi dalam 2 jenis,

1. Kebutuhan Fungsional ( Functional Requirement)

2. Kebutuhan Non Fungsional (Non Functional Requirement)
Functional Requirement
Mendeskripsikan layanan, fitur atau fungsi yang disediakan atau diberikan oleh sistem
bagi penggunanya. Kebutuhan fungsional awal merupakan fungsi atau layanan yang
merepresentasikan goal dari pengguna ketika hendak menggunakan sistem.
Contoh pada Sistem Mesin ATM :
1. Mengecek saldo
2. Menarik uang
3. Mentransfer uang
4. Melakukan pembayaran
Non-Functional Requirement
Mendeskripsikan sekumpulan batasan, karakteristik dan properti pada sistem, baik
dalam lingkungan pengembangan maupun operasional, atau atribut kualitas yang
harus dipenuhi oleh sistem. Contoh pada mesin ATM :
 1. Pengguna baru membutuhkan waktu belajar maksimal 10 menit untuk dapat
menggunakan fungsi-fungsi utama sistem
2. Sistem harus tetap berfungsi minimal 10 jam setelah pasokan listrik dari PLN
terhenti
3. Waktu yang dibutuhkan untuk kembali beroperasi setelah sistem mati minimal 2
menit
IEEE 803:1993 mengelompokkan kebutuhan non-fungsional ke dalam sejumlah
kategori kualitas dari suatu perangkat lunak.
Kategori tsb secara umum dibagi dalam 2 kelompok, yaitu :

 Faktor kualitas eksternal perangkat lunak. Kategori kualitas yang bisa diobservasi
atau menjadi ketertarikan utama dari pelanggan. Diantaranya :
1. Ketepatan (correctness)
2. Robustness
3. Unjuk Kerja (performance)
4. Ketersediaan dan kualitas antarmuka(interface)
5. Keandalan(Reability)
6. Ketersediaan (Availability)
7. Faktor kualitas internal perangkat lunak.
Kategori kualitas yang bisa diobservasi atau menjadi ketertarikan utama dari
pengembang. Diantaranya :

1. Kemudahan membaca/memahami struktur perangkat lunak(readibility)

2. Kemampuan untuk dilakukan pengujian (testability)
3. Ketersediaan dan kualitas dokumentasi (documentation)
4. Kemudahan pemeliharaan(maintainability)
5. Adaptasi terhadap lingkungan berbeda (portability)

https://aristysaputri3.wordpress.com/analisis-perangkat-lunak-2/pengenalan-rekayasa-kebutuhan/

aristysaputri3
TAK PERNAH AD A ILMU YG TAK BERGUNA DAN S I A-SIA,

User requirement (kebutuhan pengguna)

• Pernyataan tentang layanan yang disediakan sistem dan tentang batasan batasan operasionalnya.
Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah.
URD dapat digunakan sebagai panduan untuk perencanaan biaya, jadwal, tonggak
sejarah, pengujian, dll. Sifat eksplisit URD memungkinkan pelanggan untuk menunjukkannya kepada stake
holder untuk memastikan semua fitur yang diperlukan dijelaskan

Menggambarkan functional dan non-functional req yang dapat dipahami oleh pengguna (user) yang tidak
memiliki latar belakang teknis yang cukup. User requirement menjelaskan perilaku luar dari sistem, tidak
secara teknis, karena itu perlu menggunakan bahasa alami, atau bahasa yang sederhana.
Masalah dalam menyiapkan user req adalah:
•Bahasa alami kadang tidak cukup untuk menjelaskan, atau membuat
dokumen jadi sulit dibaca
•Jenis-jenis req, kadang jadi sulit dibedakan
•Sering digabungkan menjadi satu kumpulan requirement saja

http://ichachaca.blogspot.co.id/2010/06/pengantar-requirement-document.html

Secara sederhana, Software Requirement Specifications (SRS) adalah dokumen yang

menjelaskan tentang berbagai kebutuhan yang harus dipenuhi oleh suatu software. Dokumen
ini dibuat oleh developer (pembuat software) setelah menggali informasi dari calon pemakai
software. Pembuatannya pun seharusnya mengikuti standar yang ada dan paling diakui oleh
para praktisi rekayasa software di dunia. Oleh karena itu, standar yang akan dibahas di sini
adalah standar dari IEEE.

SRS yang baik akan bermanfaat bagi customer, supplier, ataupun perorangan. Manfaat-
manfaat tersebut antara lain:

1. Sebagai bentuk perjanjian antara customer dan supplier tentang software apa yang
akan dibuat
2. Mengurangi beban dalam proses pengembangan software
3. Sebagai bahan perkiraan biaya dan rencana penjadwalan
4. Sebagai dasar validasi dan verifikasi software di ujung penyelesaian proyek nantinya
5. Memfasilitasi transfer, semisal software tersebut ingin ditransfer ke pengguna atau
mesin-mesin yang lain. Customer pun merasa mudah jika ingin mentransfer
software ke bagian-bagian lain dalam organisasinya. Bahkan, jika terjadi pergantian
personil developer, proyek dapat mudah ditransfer ke personil baru dengan
memahami SRS ini.
6. Mendasari perbaikan produk software di kemudian hari. Jadi, kadang SRS boleh
diperbaiki dengan alasan dan mekanisme tertentu serta atas kesepakatan antara
customer dan developer.
https://cisini.wordpress.com/2012/10/16/srs/

Software Requirement Specification (SRS) adalah merupakan suatu document terstruktur yang
memuat pernyataan-pernyataan requirement, baik User Requiremenet maupun System Requirement.
SRS adalah dokumen yang menjadi acuan bagi semua pihak yang terkait, baik bagi user maupun
developer.
 SRS bukanlah sekedar wadah untuk menuliskan semua hasil interview dan meeting, melainkan
wadah untuk menuliskan requirement yang sudah dianalisa dan dikonfirmasi. Oleh karena itu SRS
harus dibuat terstruktur!

http://www.rustamaji.net/id/computing/user-requirement-vs-software-requirement

ABSTRAK
SDD (Software Design Document) adalah hasil akhir dari proses perancangan. SDDmerupakan penjelasan hasil
proses perancangan yang termasuk di dalamnya perbaikan
hasil perancangan tersebut untuk merepresentasikan perangkat lunak yang sedang dibangun
asil perancangan didokumentasi dalam SDD (
Software Design Descriptions
) yangberisi model atau representasi perangkat lunak untuk digunakan sebagai dasar prosesimplementasi (coding)
https://id.scribd.com/document/32112545/Modul-Rekayasa-Perangkat-Lunak

1. Waterfall
Pengertian model waterfall ini adalah suatu model klasik yang memiliki pengembangan
perangkat lunak secara sistematis. Jadi, dari model waterfall ini melakukan pengerjaan
dari suatu sistem dilakukan secara berurutan atau secara linear.

Kelebihan dari waterfall:

 Software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik.
 Dokumen pengembangan sistem sangat terorganisir. Mengapa? Karena pada setiap fasenya
harus terselesaikan secara lengkap sebelum nantinya akan melangkah ke fase berikutnya.

Kekurangan dari waterfall:

 Perubahan sulit dilakukan karena sifatnya yang kaku. Jadi, karena sifat kakunya inilah model
proses waterfall mungkin cocok ketika nanti kebutuhan yang dikumpulkan lengkap, sehingga
perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali pengguna yang
bisa memberikan kebutuhan secara lengkap, mungkin karena perubahan kebutuhan adalah
sesuatu yang wajar terjadi.

2. Prototype
Metode Prototype merupakan metode pengembangan perangkat lunak yang
memodelkan dari sistem kerja suatu perangkat lunak yang belum lengkap dari pihak
user.

Kelebihan dari prototype :

 User dapat berinteraksi aktif.
 Penentuan kebutuhan lebih mudah diwujudkan.
 Mempersingkat waktu pengembangan.

Kekurangan dari prototype :

 Proses analisis dan perancangan terlalu singkat.
 Mengesampingkan alternatif pemecahan masalah.
 Bisanya kurang fleksible dalam mengahadapi perubahan.
 Prototype yang dihasilkan tidak selamanya mudah dirubah.
 Prototype terlalu cepat selesai.

3. Spiral
Model spiral adalah model proses dari software yang evolsioner dan dapat merangkai
dengan sifat yang iteraktif dari prototype dengan cara kontrol dan aspek sistematis dari
model sekuensial linear. Model ini sangat berpotensi untuk pengembangan versi
software secara cepat.

Kelebihan dari spiral :

 Nantinya dapat disesuaikan agar perangkat lunak bisa digunakan selama perangkat lunak
komputer masih aktif.
 Model ini cocok untuk pengembangan sistem dan perangkat lunak skala besar.

Kekurangan dari spiral :

 Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa dikontrol.
 Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang serius jika
resiko mayor tidak ditemukan dan diatur.
 Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolute.

4. Rapin Aplication Development (RAD)

Model RAD merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier,
yang di mana perkembangan ini cepat dicapai dengan menggunakan pendekatan
kontruksi berbasis komponen.

Kelebihan dari RAD :

 Setiap fungsi mayor dapat dimodulkan dalam waktu tertentu kurang dari 3 bulan dan dapat
dibicarakan oleh tim RAD yang terpisah dan kemudian diintegrasikan sehingga waktunya lebih
efisien.
 RAD mengikuti tahap pengembangan sistem seperti umumnya, tetapi mempunyai kemampuan
untuk menggunakan kembali komponen yang ada sehingga pengembang tidak perlu membuat
dari awal lagi dan waktu yang lebih singkat

Kekurangan dari RAD adalah :

 Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang
memadai untuk menciptakan jumlah tim RAD yang baik.
 RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktivitas rapid-fire
yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat
diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan gagal.

5. Incremental
Model incremental (Incremental waterfall model) merupakan perbaikan dari
modelwaterfall dan sebagai standar pendekatan top-down. Ide dasar dari model ini
adalahmembangun software secara meningkat (Increment) berdasarkan kemampuan
fungsional.
Kelebihan dari Incremental :
 Penambahan kemampuan fungsional akan lebih mudah diuji, diverifikasi, dan divalidasi dan
dapat menurunkan biaya yang dikeluarkan untuk memperbaiki sistem.
 Nilai penggunaan dapat ditentukan pada setiap increament sehingga fungsionalitas sistem
disediakan lebih awal.
 Increment awal berupa prototype untuk membantu memahami kebutuhan pada increment
berikutnya.
 Memiliki risiko lebih rendah terhadap keseluruhan pengembagan sistem.
 Prioritas tertinggi pada pelayanan sistem adalah yang paling diuji.

Kekurangan dari Incremental :

 Tiap bagian tidak dapat diintegrasikan.
 Setiap tambahan yang dibangun harus dimasukkan kedalam struktur yang ada tanpa
menurunkan kualitas dari yang telah dibangun system tersebut sampai saat ini.
 Penambahan staf dilakukan jika hasil incremental akan dikembangkan lebih lanjut.
https://microcyber2.com/pengertian-model-proses-rekayasa-perangkat-lunak/