Introduction to Software Engineering

Membuat Spesifikasi Kebutuhan Software (SKS/SRS) merupakan salah satu kegiatan dalam mata rantai kegiatan pembangunan perangkat lunak atau software engineering, yang biasanya dilakukan pada fase awal pembuatan software. Kegiatan pelatihan kali ini khusus membahas topik mengenai pembuatan SKS, dengan pertimbangan bahwa SKS merupakan dokumen awal yang penting dalam seluruh mata rantai software engineering, dimana dokumen tersebut memberikan gambaran yang jelas dan lengkap mengenai spesifikasi software yang akan dibangun sesuai dengan apa yang diinginkan atau dibutuhkan oleh client. Dalam mata rantai software engineering, pembuatan SKS banyak melibatkan pihak client sebagai calon user, dalam rangka menggali dan mendefinisikan SKS dalam bentuk yang tertulis, sehingga kesesuaian software yang dibangun kemudian dapat diverifikasi.

Tulisan “Introduction to Software Engineering” ini bertujuan untuk memperkenalkan peserta kepada apa yang disebut dengan “software engineering”, yang merupakan gambaran global mengenai keseluruhan proses pembangunan software, dimana pembuatan SKS merupakan salah satu proses di dalamnya. Dengan membaca makalah ini, peserta diharapkan dapat memperoleh gambaran yang lebih luas mengenai proses pembangunan software secara umum, dan dapat mengidentifikasikan posisi dan peran dari dokumen SKS dalam keseluruhan proses pembangunan software.

Software engineering itu sendiri dapat diartikan sebagai proses pembuatan software dengan mengikuti tatacara atau metodologi tertentu, sehingga keseluruhan proses pembuatan software dapat didefinisikan, dilakukan kembali, diverifikasi dan dimengerti oleh semua pihak yang terlibat dalam pembuatan software tersebut. Dalam pembangunan fisik, misalnya membangun gedung, jalan atau jembatan, keberadaan metodologi yang jelas ini penting meskipun hasil-hasilnya dapat selalu dilihat dan dicek secara fisik, apalagi dalam hal pembangunan software, dimana hasil-hasilnya seringkali tidak dapat langsung dilihat secara fisik. Karena itu implementasi software engineering yang standar sangat dibutuhkan dalam proyek-proyek pembangunan software, agar hasil yang diperoleh sesuai dengan yang diinginkan.

Pada dasarnya ada tiga pilihan yang dapat diambil oleh suatu perusahaan untuk memenuhi kebutuhan akan software:

  1. Membeli produk software yang sudah ada (off-the-self package), kemudian dilakukan penyesuaian dengan kebutuhan sistem yang ada di dalam perusahaan. Namun, off-the-self package belum tentu tersedia atau sesuai dengan kebutuhan, sehingga diperlukan keahlian pengguna dari dalam perusahaan untuk kastemisasi. Selain itu, harga off-the-self package yang ada bisa jadi terlalu mahal bagi perusahaan.
  2. Membangun sendiri software yang dibutuhkan dengan sumber daya yang ada di dalam perusahaan. Untuk aplikasi yang cukup besar, hal ini dapat menjadi sangat kompleks dan berada di luar jangkauan kemampuan perusahaan kecil atau sedang, karena memerlukan sumber daya, termasuk peralatan, personil dan dana yang besar.
  3. Meminta bantuan perusahaan pembuat perangkat lunak (software vendor atau developer) untuk membuat software yang dibutuhkan perusahaan. Hal ini dapat menjadi pilihan yang tepat dengan pertimbangan biaya yang lebih rendah, kesesuaian dengan kebutuhan perusahaan dan pemeliharaan.

 

Namun, kerjasama antara user dengan software developer tidak selalu berjalan dengan mulus. Seringkali, pembangunan software tertunda, atau sumber daya manusia melebihi perkiraan, atau ada masalah kualitas setelah pemeliharaan. Hal ini seringkali terjadi karena user memberikan komitmen kepada software developer, dan proyek segera dimulai, tanpa memperhatikan rencana dan pembagian tugas yang jelas antara user dengan developer. Industri dan pemerintah menyadari bahwa masalah yang fundamental adalah ketidakmampuan untuk mengatur proses pembangunan software.

Sistem yang baik sangat sulit diwujudkan melalui proyek yang tidak disiplin dan kacau. Memang, dalam organisasi yang tidak disiplin sekalipun, beberapa proyek pembangunan software bisa saja memberikan hasil yang cukup baik. Tetapi, biasanya hal ini terjadi hanya karena kerja keras dari suatu tim yang berdedikasi tinggi. Dengan demikian, hasil bergantung dari keberadaan individu tertentu yang sama. Sukses yang bergantung dari keberadaan individu tertentu ini tidak memberikan dasar bagi produktifitas dan peningkatan mutu jangka panjang. Kemajuan yang berkesinambungan hanya dapat terjadi melalui usaha yang terfokus dan terus-menerus untuk membangun standarisasi software engineering dan praktek manajemen yang efektif.

Makalah ini memperkenalkan mengenai software engineering, manfaat dari penerapannya, dan gambaran singkat mengenai beberapa standar software engineering yang ada.

Penerapan software engineering yang standar memberikan manfaat baik untuk software developer, user, manajemen proyek, maupun pesonil yang terlibat langsung dalam pembangunan software. Ditinjau dari sudut software developer, penerapan software engineering yang standar memberikan manfaat keluar sebagai berikut:

  1. Memperjelas aktifitas-aktifitas yang diperlukan dalam software development sehingga dapat dimengerti oleh semua pihak yang terlibat, termasuk developer, user, pemasok, pembeli dan sebagainya.
  2. Memperjelas pembagian tanggung jawab dan kontrak kerja antara user dan developer tentang apa yang harus dikerjakan, bagaimana mengerjakannya, dan oleh siapa.
  3. Memberikan kriteria yang baik untuk memperkirakan biaya yang dibutuhkan dalam software development sehingga dapat menjadi dasar justifikasi untuk pengeluaran perusahaan.
  4. Menjamin kualitas sistem yang dihasilkan.

Selain itu, penerapan software engineering yang standar memberikan manfaat ke dalam perusahaan software developer, antara lain sebagai  berikut:

  1. Memberikan pedoman dalam proses pembangunan software sesuai dengan spesifikasi yang telah disetujui bersama.
  2. Dengan standar, metode dan format yang sama, penggunaan kembali software menjadi mungkin. Hal ini dapat mengurangi waktu operasional, biaya dan resiko, karena produk telah diuji coba.
  3. Efisiensi dalam kegiatan organisasi, peningkatan kegiatan operasional, peningkatan mutu produk dan pelayanan.
  4. Implementasi standar mutu dapat menjamin kepuasan pemegang saham dan peningkatan atau perbaikan secara terus menerus.
  5. Impelementasi standar akan sangat membantu organisasi dalam memenuhi persyaratan sistem manajemen mutu untuk keperluan sertifikasi.
  6. Implementasi standar dapat membangun image perusahaan sebagai salah satu modal berkompetisi di pasar internasional.
  7. Memudahkan dalam melatih personil baru karena ada standar baku yang tertulis.

 

Software Engineering Standar

Kegiatan software development tidaklah sederhana, tetapi meliputi kegiatan manajemen, operasional, pemeliharaan, infrastruktur, kastemisasi, dokumentasi, review, verifikasi, validasi, jaminan kualitas, koreksi dan pelatihan. Kebutuhan akan adanya software engineering standar sudah lama disadari. J.M. Juran mendefinisikan pendekatan empat langkah untuk meningkatkan kualitas (Juran, 1988). W.E. Deming mengusulkan pendekatan empat belas poin (Deming, 1986). P.B. Crosby membuat kerangka manajemen kedewasaan untuk menilai suatu organisasi dalam menjamin kualitas dalam praktek bisnis (Crosby, 1979). Semuanya menyimpulkan bahwa peningkatan jangka panjang hanya dapat dicapai melalui analisa dan kegiatan yang sistematis.

Beberapa software engineering standar telah disusun oleh industri dan organisasi yang bergerak dalam bidang pembangunan software, antara lain: Thomson-SCF, NASA-CMM, Fujitsu-SDEM90, STAGE, STEAD, IEEE, ISO, Rational dan sebagainya. Sebagian dari standar-standar ini telah dipublikasikan untuk umum. Beberapa standar seperti Rational telah tersedia dalam bentuk software development software package. Kita dapat melihat bahwa pada saat ini belum ada suatu standar yang berlaku secara internasional. Karakteristik beberapa standar seperti Fujitsu-SDEM90, Thomson-CSF dan NASA-CMM akan digambarkan dengan singkat di bawah ini.

Fujitsu-SDEM90

Kerangka sistem development dalam SDEM90 dibangun dengan konsep ruang, yang menunjukkan tanggung jawab dari aktifitas pembangunan sistem, dan v-curve yang menggambarkan prinsip fundamental produksi. Dalam sistem yang konvensional, sulit untuk memperlihatkan tanggung jawab, aktifitas apa yang harus diselesaikan oleh siapa. Gambar 1 menunjukkan perbandingan antara metode yang konvensional dengan metode SDEM90. Seperti terlihat pada gambar, SDEM90 menekankan pada pentingnya koordinat vertikal yaitu ruang.

 

 

Model Proses Konvensional

 

 

Time/Phase

 

App. Dev.

    

       A               B                 C

------------O------------O-------------O---

 

 

 

 

Kerangka SDEM90

 

Space

Real World

 

       A

------------

                       B

                ------------

                                       C

                                    --------------

Interface

 

Com. World

 

 

 

Gambar 1
Perbandingan Antara Model Konvensional dengan SDEM90

 

SDEM90 memperkenalkan koordinat ruang, yang dibagi menjadi REAL WORLD, INTERFACE dan COMPUTER WORLD sebagai sub-ruang yang utama, dan membagi tanggung jawab dalam koordinat ini.  Proses development itu sendiri tidak tertalu eksplisit dalam sistem ini, jadi kurang begitu jelas bagi developer. Namun, memang sistem ini bertujuan untuk memperlihatkan seluruh aktifitas kepada semua pihak yang terlibat.

REAL WORLD menggambarkan aktifitas bisnis yang sebenarnya. Antara REAL WORLD dan COMPUTER WORLD, ada ruang INTERFACE, termasuk di dalamnya semua spesifikasi sistem seperti fungsionalitas, performance, information requirement dan sebagainya. Dengan menambahkan DEVELOPMENT LOGISTICS untuk memberikan resource yang diperlukan, space coordinate disusun seperti terlihat pada Gambar 2.

 

Concept

Category

Subcategory

Real World

Business

Business

Interface

Systen Specification

System Function

Data Structure

Performance

Reliability and Security

Operation and Maintenance

Conversion

Computer World

Software

Application Software

Data

Basic Software

Environment

Hardware

Host

Workstation

Network

Facilities

Development Logistic

Development Support

Development Standard

Techniques and Tools

Education

System Configuration Management

Development Supplies

Project Management

Project Management by Metrics

Organisation and Personnel

Costs

 

 

Gambar 2

Isi dari koordinat Ruang

 

 

Umumnya, proses produksi dimulai dari mendapatkan order dari customer, produksi di pabrik, dan akhirnya produk yang dipesan dikirimkan kepada customer. Dengan kata lain, proses dimulai dari REAL WORLD, melalui ruang selebihnya, dan kembali ke REAL WORLD. Sistem ini disebut dengan V-Curve.

 

Ketika V-curve dipetakan di atas koordinate Ruang seperti pada Gambar 3, kita menemukan aktifitas yang diperlukan di titik perpotongan semagai aktifitas-aktifitas utama. Selain aktifitas utama, ada aktifitas-aktifitas yang diperlukan dalam proyek yang sesungguhnya. Kita dapat menempatkan aktifitas-aktifitas ini di titik perpotongan dalam matriks dua dimensi. Dengan demikian kita mendefinisikan peta dari aktifitas sistem development. Kemudian, aktifitas disusun menjadi Work Breakdown Structure  (WBS) yang dapat dimengerti.

 

v-curve.png

 

Gambar 3

 

Konsep V-Curve dan Fase

 

Efektivitas dari SDEM90 adalah dalam hal-hal yang berikut:

 

  1. Presentasi yang eksplisit dari aktifitas-aktifias yang diperlukan
  2. Dapat menjadi basis untuk perkiraan biaya.
  3. Dapat menjadi basis untuk pembagian tanggung jawab
  4. Dapat menjadi basis untuk transfer teknologi

 

Standar SDEM90 metodologi terdiri dari beberapa jenis untuk proyek-proyek yang berbeda, yaitu:

 

  1. Metodologi Perencanaan Strategis
  2. Metodologi Pemeliharaan Sistem
  3. Metodologi Pembuatan Sistem, yang terdiri dari
    1. Metodologi Proyek Besar (LPM)
    2. Metodologi Proyek Kecil (SPM)
    3. Metodologi Prototipe (PM)

 

Berikut ini gambaran dari penggunaan Metodologi Proyek Besar (LPM):

 

A. Fase

 

LPM membagi operasi yang harus diselesaikan menjadi fase. Fase utama terdiri dari Perencanaan, Perancangan, Konstruksi, Testing, Implementasi, Pemeliharaan dan Evaluasi. LPM menggunakan metode waterfall dimana setiap sub-fase harus diselesaikan secara berurutan.

 

B. Kategori

 

Kategori didasari dengan BUSINESS WORLD, COMPUTER WORLD dan INTERFACE. Kategori yang lain adalah operasi yang berhubungan dengan manajemen proyek. Kategori dapat dipergunakan untuk pelimpahan tanggung jawab pekerjaan kepada tim atau individu.

 

C. Dekomposisi/Integrasi

 

Prosedur dekomposisi dan integrasi digunakan dalam LPM. Prosedur ini memecah sistem yang akan dibangun menjadi komponen-komponen yang kecil dan dapat dikerjakan. Kemudian, komponen-komponen ini secara sistematis dibangun kembali. Setiap tingkat dari prosedur integrasi ini termasuk verifikasi dan validasi dari komponen hasilnya.

 

D. Work Breakdown Structure (WBS)

 

Operasi proyek diatur dalam suatu struktur hirarkis, yang disebut work breakdown structure (WBS). Struktur ini dibagi menjadi 3 tingkat yaitu (1) process, (2) aktifitas dan (3) tugas. Tingkat pertama menggambarkan organisasi keseluruhan dari proyek dan dapat menjadi alat manajemen. Tingkat kedua memungkinkan resource seperti waktu, pekerja, teknik, alat dan bahan ditetapkan. Tingkat ketiga menjelaskan detail pekerjaan yang sebenarnya

 

E. Hasil

 

LPM menekankan pentingkan hasil selama proyek. Hasil ini memungkinkan komunikasi antar personel yang terkait dalam proyek dan personel di luar proyek. LPM mengatur hasil ke dalam struktur tiga tingkat yang mirip dengan WBS, yaitu (1) File, (2) Report dan (3) Dokumen.

 

 

Thomson-CSF

 

Karakteristiknya Thomson-CSF antara lain prosedur yang ketat, dokumen yang cukup banyak untuk setiap aspek dan fase dari software development dan pedoman standar penulisan yang seragam. Hal ini tentunya dapat menjamin kontrol terhadap proses development dan kualitas hasil yang tinggi sampai ke element yang paling kecil.

 

Secara garis besar, dari proses software development menurut Thomson-CSF adalah sebagai berikut:

 

  1. Desain dan analisa kebutuhan sistem
  2. Analisa kebutuhan software
  3. Desain awal
  4. Desain detail
  5. Koding CSU dan testing
  6. Integrasi CSC dan testing
  7. Testing CSCI
  8. Integrasi sistem dan testing

 

Pada setiap tingkat development tersebut, dokumen dihasilkan dan disetujui untuk melanjutkan ke tingkat selanjutnya. Sebagai ilustrasi, tahap awal dari standar ini adalah proses spesifikasi, yang bertujuan untuk membentuk suatu persetujuan kerja dengan customer, untuk memenuhi daftar kebutuhan teknis yang harus dipenuhi oleh software tersebut. Jadi, spesifikasi adalah komitmen antara customer dengan developer, yang berakhir pada Software Specification Review (SSR). Dokumen spesifikasi terdiri dari:

 

  1. Software Requirement Specification (SRS), menggambarkan requirement dari satu Computer Software Configuration Item (CSCI)
  2. Interface Requirements Specification (IRS), menggambarkan interface antara satu atau lebih CSCI.

 

Pedoman untuk penulisan dokumen-dokumen tersebut adalah sebagai berikut:

 

A. Dokumen Software Requirement Specification (SRS)

 

  1. Scope
    1. Identification
    2. CSCI Overview
    3. Documen Overview
  2. Reference Documents
    1. Government Documents
    2. Non-Government Documents
  3. Engineering Requirements
    1. CSCI external interface requirements
    2. CSCI capability requirements
    3. CSCI internal interface
    4. CSCI data elemets requirements
    5. Sizing and timing requirements
    6. Safety requirements
    7. Security requirements
    8. Design Constrains
    9. Software quality factors
    10. Human performance and Engineering requirements
    11. Requirements traceability
  4. Qualification Requirements
    1. Qualification Methods
    2. Special qualification requirements
  5. Preparation for Delivery
  6. Notes

 

B. Dokumen Interface Requirement Specification (IRS)

 

  1. Scope
    1. Identification
    2. System overview
    3. Document Overview
  2. Reference Documents
    1. Government documents
    2. Non-governmet documents
  3. Interface Specification
    1. Interface diagrams
    2. Overal specification
    3. Name and Identifier of the interface
      1. Interface requirements
      2. Data requirements
      3. Data message description
  4. Quality assurance
  5. Preparation for delivery
  6. Notes

 

Berikut ini beberapa dokumen lain yang harus dihasilkan pada setiap fase-fase tertentu dalam standar Thomson-SCF:

 

  1. Software Product Specification (SPS)
  2. Software Quality Program Plan (SQPP)
  3. Software Development Plan (SDP)
  4. Version Description Document (VDD)
  5. Software Test Plan (STP)
  6. Software Test Description (STD)
  7. Software Test Report (STR)
  8. Computer Resources Integrated Support (CRISD)
  9. Computer System Operation Manual (CSOM)
  10. Firmware Support Manual (FSM)
  11. Software Programmer Manual (SPM)
  12. Software User Manual (SUM)
  13. Software Design Document (SDD)
  14. Software Requirement Specification (SRS)
  15. Interface Requirement Specification (IRS)

 

 

Standar NASA-CMM

 

Standar Capability Maturity Model (CMM), yang disusun oleh The Software Engineering Institute (SEI), didasari oleh pengetahuan yang diperoleh dari pengkajian proses software dan feedback yang banyak dari industri dan pemerintah. CMM Model mengklasifikasi organisasi ke dalam lima proses kedewasaan, yaitu:

 

  1. Tingkat Initial (Tahap Awal). Dalam tingkat ini, proses pengembangan software dilakukan secara tidak teratur. Hanya sedikit proses yang terdefinisi dan sukses sangat bergantung dari usaha dan keberadaan individu tertentu.
  2. Tingkat Repeatable (Dapat Mengulangi). Dalam tingkat ini, manajemen proyek yang dasar sudah ada untuk mengawasi biaya, jadwal dan fungsi.  Disiplin proses yang utama telah ada untuk mengulangi keberhasilan proyek  yang sejenis.
  3. Tingkat Defined (Terdefinisi). Dalam tingkat ini, proses pengembangan software, baik aktifitas manajemen maupun teknis, telah didokumentasikan, distandarkan dan diintegrasikan ke dalam proses pengembangan software yang standar dari organisasi tersebut, dan semua proyek mengikuti standar tersebut.
  4. Tingkat Managed (Terkelola). Dalm tingkat ini, proses pengembangan software yang lebih rinci dan kualitas produk telah diketahui. Baik proses pengembangan software maupun kualitas produk telah dimengerti secara kuantitatif dan terkontrol.
  5. Tingkat Optimising (Mengoptimalkan). Dalam tingkat ini, proses peningkatan yang berkelanjutan dilakukan melalui umpan balik kuantitatif dari proses pengembangan ataupun melalui inovasi ide dan teknologi.

 

Proses software yang standar sangat penting untuk mencapai tingkat kedewasaan organisasi yang lebih tinggi.

 

Pada tingkat organisasi, standar proses software digambarkan, diatur, dikontrol dan ditingkatkan. Pada tingkat proyek, penekanan ada pada tingkat desain, kegunaan proses software dan nilai yang ditambahkan kepada proyek. Standar CMM menggambarkan elemen-elemen fundamental di dalam proyek, dan juga menggambarkan hubungan antara elemen proses software. Standar ini membangun metode yang konsisten dalam melakukan aktifitas software dalam organisasi, yang sangat penting untuk kestabilan jangka panjang dan peningkatan.

 

Setiap proyek mempunyai kebutuhan, batasan dan sumber daya yang berbeda. Sebagian kebutuhan ini ada pada software. Untuk mengakomodasi kebutuhan, batasan, dan sumber daya dalam setiap proyek, pedoman ini dissuaikan.

 

Standar software engineering CMM dapat digambarkan sebagai berikut:

 

  1. Software management
    1. Plan software project
    2. Track software project
  2. Software Configuration Management
    1. Place software product under software cnfiguration management
    2. Dispositioning software configuration management reports or request
    3. Prepare software product for delivery
  3. Software Development
    1. Participate in system requirements definition
    2. Perform software development
    3. Participate in system development and system qualification testing
  4. Software Process
    1. Identify and test process improvement
    2. Maintain the organisation assets
    3. Develop and supply organisational training

 

Kesimpulan

 

Mendefinisikan aktifitas software development dalam bentuk standar software engineering dapat efektif dalam memperjelas dan membuat bisnis IT menjadi transparan, dan hal ini dapat menjadi dasar untuk transfer teknologi. Manfaat dari standar software engineering dapat dirasakan keluar maupun ke dalam organisasi dalam bentuk pedoman dan garansi kualitas dalam pelaksanaan proyek maupun organisasi secara keseluruhan.

 

Ada beberapa industri standar yang saat ini telah dipublikasikan, dan penerapannya perlu disesuaikan dengan karakteristik proyek yang akan dilakukan. Standar Fujitsu-SDEM90 memberikan visualisasi yang lebih jelas untuk pembagian tanggung jawab antara user dan software developer, dan memberikan dasar yang jelas untuk perkiraan biaya yang dibutuhkan. Sedangkan standar Thomson-CSF memberikan pedoman yang jelas, ketat dan sistematis dalam software development.

 

 

 

Daftar Singkatan

 

 

CRISD

Computer Resources Integrated Support

CSCI

Computer Software Configuration Item

CSOM

Computer System Operation Manual

FSM

Firmware Support Manual

IRS

Interface Requirement Specification

IRS

Interface Requirement Specification

ME

Maintenance and System Evaluation

OT

Operational Test

PG

Programming

PS

Program Structure Design

PT

Program Test

SA

System Analysis

SD

System Development

SDD

Software Design Document

SDP

Software Development Plan

SI

Software Integration

SP

System Planning

SPM

Software Programmer Manual

SPS

Software Product Specification

SQPP

Software Quality Program Plan

SRS

Software Requirement Specification

SS

System Structure Design

SSR

Software Requirement Specification

SSR

Software Specification Review

ST

System Test

STD

Software Test Description

STP

Software Test Plan

STR

Software Test Report

SUM

Software User Manual

UI

User Interface Design

VDD

Version Description Document

WBS

Work Breakdown Structure