Tahapan APSI

Tahapan APSI (Analisis dan Perancangan Sistem Informasi).

A. Latar Belakang:

Perkembangan IPTEK cukup pesat. Demikian halnya metoda yang digunakan untuk melakukan APSI, sudah berkembang. Pemodelan APSI, tidak cukup hanya dengan DFD atau Flowmap saja. DFD itu hanya menggambarkan sebagian program yang ada dalam komputer. Sedangkan Flowmap menggambarkan aliran dokumen, yang biasanya digunakan dalam Sistem Informasi Akunstansi (Keuangan).

Persoalannya adalah:

  1. Bagaimana kita memodelkan Sistem Informasi jika dalam suatu organisasi belum ada aliran dokumennya ?
  2. Bagaimana kita memodelkan Sistem Informasi jika dalam suatu organisasi belum ada komputernya ?
  3. Dari manakah sebaiknya kita memulai tahapan APSI ?

B. Lapisan supra sistem-sistem-sub sistem:

Untuk menjawab hal itu, kita perlu BEDAKAN, antara

  1. sistem informasi dengan sistem organisasi.
  2. sistem informasi dengan sistem pengolahan data
  3. sistem informasi dengan sistem perangkat lunak.

Penjelasan:

  • Sistem organisasi merupakan tempat beradanya beberapa sistem informasi. Sistem organisasi merupakan supra sistem dari sistem informasi.
  • Sistem pengolahan data merupakan elemen dari sistem informasi. Sistem pengolahan data merupakan salah satu sub sistem dari sistem informasi.
  • Sistem perangkat lunak merupakan elemen dari sistem informasi. Sistem perangkat lunak merupakan salah satu sub sistem dari sistem informasi.

C. Apa saja elemen dari sistem informasi ?

  1. User yang menggunakan dan berinteraksi langsung dengan elemen sistem informasi
  2. Sistem Perangkat Keras
  3. Sistem Jaringan Komputer
  4. Sistem Perangkat Lunak (untuk Client maupun server)
  5. Sistem Basis Data
  6. Interaksi Antara Manusia dengan Komputer (Interaksi User dengan komputer)
  7. Prosedur Operasi
  8. Prosedur Pemeliharaan
  9. Pengolahan Data non komputer

D. Apa saja garis besar tahapan APSI ?

1. Analisis Sistem organisasi. Tujuannya untuk

  • mengidentifikasi Core business dari organisasi
  • mengidentifikasi Aktivitas yang mengelola Core business
  • mengidentifikasi Resources Utama dari Core business tersebut
  • mengidentifikasi konteks dari Sistem informasi yang mendukung pengelolaan Aktivitas, Resources Utama maupun Core Business
  • mengidentifikasi kebutuhan informasi bagi perancangan Sistem informasi

2. Analisis dan Perancangan Sistem Informasi. Tujuannya untuk

  • membangun arsitektur sistem informasi
  • mengidentifikasi konteks Sistem Perangkat Lunak dan Sistem Basis Data (jika analisis dilakukan oleh ahli informatika)
  • mengidentifikasi konteks dan spesifikasi elemen lainnya (Sistem Perangkat Keras, Sistem Jaringan Komputer, dll).
  • mengdientifikasi functionalities dari calon aplikasi Perangkat Lunak
  • mengidentifikasi entitas data yang relevan dari calon sistem basis data

3. Analisis dan Perancangan Sistem Perangkat Lunak

  • Ikuti tahapan Software Engineering (RPL). Contoh Waterfall, Prototyping, Incremental Iterative, Spiral, OOA/OOD/OOT, dll.
  • Tujuannya adalah untuk membangun software (sistem perangkat lunak)

4. Analisis dan Perancangan Sistem Basis Data

  • Ikuti tahapan Perancangan Basis Data (Pemodelan Konseptual, Logika, dan Fisik dari Basis Data).
  • Tujuannya adalah untuk membangun Sistem Basis Data yang terpusat ataupun yang tersebar.

disajikan untuk matakuliah APSI yang diberikan oleh Witarto. mar 2007

15 thoughts on “Tahapan APSI

  1. Dini

    Saya ingin bertanya tentang :
    1.Apa saja yang meliputi software quality insurance.
    2. Tahap perancangan pada perangkat lunak
    3. Manfaat yang di dapat dari guna ulang perangkat lunak
    4. 3 pemeliharaan sistem pada pemeliharaan perangkat lunak
    5. Apa yang dimaksud metode berbasis komponen

    Saya berharap anda menjawab pertanyaan saya secepatnya

    Reply
  2. witarto

    Ini sih, pertanyaan mendasar dari P Toto Suharto. Beliau mengembangkan dan mendalami topik-topik yang Anda tanyakan. Saya menelusur ke arah lain. Lebih banyak ke social engineering.

    Namun saya akan coba jawab, beberapa dari topik pertanyaan tersebut.

    1. software quality insurance : Maknanya Jaminan kualitas pengembangan perangkat lunak. Ini topik yang sangat RPL oriented. Pressman, dan beberapa penulis RPL banyak membahas hal ini. Agaknya perbedaan bahasan mereka akan terletak pada referensi pembanding untuk mengukur kualitas.

    Ukuran kualitas suatu software bisa mempunyai banyak dimensi:
    1.1 Dibandingkan dengan user requirement.
    1.2 Dibandingkan dengan software lain yang punya konteks fungsional sama.
    1.3 Dibandingkan kemudahan penggunaannya, ini ada di Interaksi Manusia Komputer, seperti Learnabilty, Usability dll (maaf, saya tidak sedang dekat dengan literatur. Coba saja diakses ke Google.
    1.4 Dibandingkan dengan keamanan datanya.
    1.5 Dinilai dari modularitas softwarenya, apakah mudah dimaintenance, apakah requirement-nya ambigue, apakah modul atau kelasnya bisa diguna ulang.
    1.6 Dinilai dari kemudahannya ketika diproyeksikan pada suatu manajemen proyek, apakah mudah dimanage atau dikelola.

    Coba, Anda perkaya dengan apa yang sudah diberikan oleh P Toto Suharto.

    2. Tahapan perancangan perangkat lunak ?

    Itu sudah ada di buku-buku RPL. Saya yang banyak baca, ya Pressman. Tapi jangan lupa, banyak pengarang lain yang juga bagus. (Maaf, saya lupa pengarangnya, tapi saya pernah baca). Tapi karena menguasai Pressman sudah lumayan, saya agak menahan diri.

    Tahapan itu dasarnya (secara umum) adalah :

    2.1 Waterfall atau Sequential Linear (ini yang paling populer. Agaknya diadaptasi dari konsep tahapan membangun gedung. Bisanya digunakan jika requirementnya pasti, dan sering dibuat orang. Contoh, inventory, cash register, akuntansi dll.
    2.2 Prototyping, ini jika requirementnya tidak jelas benar. Biasanya dilakukan pada software yang belum pernah dikembangkan orang atau literaturnya jarang).
    2.3 Unified Process, dari tiga serangkai pencipta UML (Booch, Rumbahugh dan Jacobson).
    2.4 Agile Methode
    2.5 Methode yang digunakan Doug Rosenberg (saya lupa namanya), biasanya digunakan untuk membangun OOP software dengan dengan tingkatan kompleksitas yang sederhana.
    Baca sendiri lainnya di Pressman.

    3. Manfaat guna ulang dari kelas pada OOP. Ini pertanyaan tepatnya.

    Kelas merupakan spesifikasi objek. Hakekatnya, ini merupakan kombinasi data struktur dengan modul program. Sifat dari kelas bisa di-guna-ulang. Artinya, jika kita sudah PERNAH bikin aplikasi nyata perangkat lunak, dari proyek nyata, maka sebenarnya kita akan punya tabungan kelas-kelas untuk objek.

    GUNA ULANG, artinya apa yang sudah dibikin lagi, (digunakan lagi) untuk menyusun proyek software lain. Jika kelas yang dibutuhkan sedikit berbeda, kita bisa merujuk kelas yang sudah kita punya, dengan pendekatan inheritance. Jadi ini akan sangat menghemat waktu serta lebih efisien dibanding dengan pendekatan prosedural (cara lama, yang modelnya menggunakan bola-bola bakso DFD.).

    Tapi kalau seumur hidup seorang programmer hanya membuat satu aplikasi. konsep GUNA ULANG ya nggak ada gunanya.

    4. 3 Pemeliharaan Sistem pada perangkat lunak.

    Ah…. ini hafalan sekali. Tanya aja pada P Toto…🙂

    Kalau saya sih, praktis-praktis saja. Yang kita perlukan bukan sekedar memelihara perangkat lunak. Tapi MENJAGA DATA yang dikelola suatu perangkat lunak jangan rusak atau hilang. INI sangat penting dibanding memelihara perangkat lunak.

    Data hilang, perusahaan bisa bangkrut.
    Perangkat lunak rusak, ya tinggal instal ulang. Jangan terlalu banyak metoda, nanti malah tidak melakukan apa-apa.
    Perangkat keras rusak atau jaringan rusak ? Ah, instal ulang, atau upgrade yang baru.

    Dalam memelihara data, mekanisme yang sangat penting adalah prosedur (manual) Back-Up Data dan Recovery. Sedangkan pada software, ya itu, baca saja contoh file-file log, ang menggambarkan aktivitas suatu komputer yang mengaktifkan suatu fungsi atau proses perangkat lunak. Tapi yang paling penting, jangan sampai softwarenya canggih, namun suka merusak data. Ini ada… loh.

    5. Metoda berbasis komponen, contohnya pada Delphi. Anda tinggal klik and drag.
    KLIK gambar komponen button, Memo, Datasource dll.
    DRAG pada form yang Anda inginkan.

    Konsep ini setahu saya dikembangkan juga di Jerman (saya pernah ikuit seminarnya). Sebenarnya ini langkah lebih lanjut dari OOP.

    Coba tanya ke P Toto, ada loh, yang disebut Subject Oriented Programming..🙂

    > Dini wrote:
    > Saya berharap anda menjawab pertanyaan saya secepatnya

    Eh, emangnya apaan ? Ada apa dengan Anda, kok terburu-buru ?

    Selamat belajar.

    salam,

    wa

    Reply
  3. ixe_maniez

    ixe mw nanya nie,,,

    perbedaan tahapan pengembangan perangkat lunak dengan mempergunakan “component assembly model” dan “concurrent development model” tu apa sie???

    ixe uda cari kmana2 tapi kok ga dapet ya???

    Reply
  4. witarto

    Anda keluar konteks. Topik di atas tentang APSI, Sistem Informasi. Sedangkan pertanyaan Anda spesifik tentang pembuat perangkat lunak (software engineering). Beda skala antara Analisis Perancangan Sistem Informasi dan Rekayasa Perangkat Lunak. Kalau Anda termasuk orang-orang yang suka mencampur aduk-kan hal tersebut, Anda akan bingung sendiri, dan akan merasa berada di Point of No Where.

    Namun saya bisa memberikan sedikit arah, berdasarkan terminologi yang Anda tanyakan.

    Component assembly model, itu seperti kalau kalau Anda mau membangun perangkat lunak menggunakan tools atau wizzard, seperti yang ada pada Delphi, atau NetBean. Tinggal tampilkan form, lalu klik-klik komponen yang diinginkan, seperti Button, Textfield, Label, dstnya.

    Sedangkan concurrent merupakan terminologi yang biasa digunakan pada perangkat lunak khusus, yang disebut sistem operasi. Concurrent artinya berebutan. Mungkin yang dimaksud Concurrent development, ya, membuat perangkat lunak yang mengatur problema konkurensi dari thread-thread pada suatu sistem operasi.

    Reply
  5. witarto

    Coba baca ini :

    Zero-time enterprise modeling with component assembly and process model optimization techniques, WenAn Tan; Song Li; Fan Yang
    Computer and Information Technology, 2005. CIT 2005. The Fifth International Conference on Volume , Issue , 21-23 Sept. 2005 Page(s): 1135 – 1139
    Digital Object Identifier 10.1109/CIT.2005.203

    Summary: This paper presents a zero-time enterprise modeling method using component assembly and process model optimization techniques. The proposed method supports the application systems built on enterprise model with the dynamic-reconstructing ability to respond to market quickly. Using the proposed approach, customized enterprise model can be constructed rapidly by component assembly techniques with component base and industrial reference model; and enterprise business process model can be reengineered and optimized based on business process dynamic optimization techniques including process definition, simulation, optimization and enactment.

    http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/10445/33169/01562811.pdf?arnumber=1562811

    Atau baca ini

    http://www.webbasedprogramming.com/Java-1.2-Unleashed/ch24.htm
    http://cbs.colognet.org/overview.php
    http://www.stylusinc.com/Common/Concerns/SoftwareDevtPhilosophy.php

    Concurrent Dev Model baca ini

    http://eprints.ecs.soton.ac.uk/9103/
    sat.inesc-id.pt/~cf/Papers/icssea2003.pdf

    Reply
  6. witart

    Tahapan membangun perangkat lunak secara umum adalah
    1. User Requirement, ini akan menemukan konteks atau domain perangkat lunak, untukdicari fungsionalitasnya. Jenis fungsionalitas bisa menggunakan C-O-R-L-A-K-S, catat, olah, rekam, lapor/baca, Akses, Share.
    2. Analisis Requirement, ini mengurai fungsionalitas menjadi proses-proses pengolahan data, yang akan diterjemahkan dengan program komputer.
    3. Desain Perangkat Lunak, menterjemahkan proses-proses pengolahan atau method menjadi algoritma, yang mendekati sintaksis program komputer. Dalam tahapan ini belum tentu semua proses hasil analisis dapat dikonversi menjadi suatu desain, karena keterbatasan suatu sintaks bahasa pemrograman komputer, atau keterbatasan programmernya.
    4. Implementasi, menterjemahkan proses-proses yang terpilih dlaam Desain, menjadi coding dalam bahasa pemrograman komputer.
    5. Test dan Instalasi, memasangdalam skala modul atau integrasi dari program komputer, sambil menguji dengan pendekatan black box atau white box.

    Itu tahapan secara umu. Hanya pendekatan bisa berbeda-beda, ada yang sedikit-sedikit baru nambah, atau disebut iterative incremental, ada yang menyeluruh, atau Waterfall, ada yang spiral, ada pendekatan prototyping, namun kesemuanya mengandung unsur-unsur Req-An-Des-Test&Instal.

    salam,

    wa

    Reply
  7. Vina

    Pak Wit, bisa dijelaskan gak ya kenapa tahapan2 model waterfall itu bisa membantu (cocok) dengan suatu pengembangan aplikasi tertentu (misal seperti contoh dari bapak: aplikasi inventory). Trims

    Reply
  8. witarto

    He.. he… jadinya blog ini seperti ngdhepi ujian semesteran aja… bagi saya.

    Setahu saya, seperti kata guru saya dulu, Waterfall cocok untuk pengembangan yang predictable. Waterfall meniru proses pembangunan teknik sipil (gedung, jembatan, dll). Semua data sudah lengkap, ada contohnya. Proses atau tahapannya jelas, termasuk rujukan peraturannya. Biasanya digunakan untuk meng-komputerisasi sistem yang sudah mapan (establish) seperti perbankan, atau prosedur kerja di Kantor Pos. (Contoh bentuk pertama).

    Bentuk kedua, jika sistem yang akam dibangun Sistem Informasi berikut perangkat lunaknya masih amburadul, tidak jelas, maka yang paling pas adalah Prototyping.

    Ada juga yang menyebutkan Agyle itu cocok untuk persoalan kedua. Tapi gimana realistisnya methoda Agyle itu ? Yang jelas hanya kriterianya. Contohnya sangat kurang.

    Sama juga dengan penggunaan ER diagram dan Normalisasi. Jika data yang terkumpul berupa contoh dokumen berbentuk tabel-tabel, maka yang pas ya normalisasi. Jika contoh dokumennya ndhak jelas, ya udah, pakai langsung ER diagram. Dan pilih satu saja. Kalau sudah normalisasi, ya ndhak usah ER diagram. Buang waktu. Demikian juga sebaliknya, kalau ER Diagramnya sudah berhasil dibikin, ya ndhak usah normalisasi segala. Emangnya waktunya masih ada gitu ?

    Heeee…. ini pertanyaan untuk RPL, domainnya Pak Toto. Tanya Pak Toto saja untuk lebih jelasnya. Saya mah, Sistem Informasi wungkul…. he… he… Sesama bus kota, dilarang saling gandengan. Itu namanya bus gandeng, atau kereta api ?

    salam, wa

    Reply
  9. Pingback: Tahapan APSI (Analisis dan Perancangan Sistem Informasi) « Open Source Project - TI Informatika Untan

  10. diana

    Pak..maw tany..untuk konsep Pendekatan prototyping seperti apa..?
    tx B4..

    Contoh praktis:
    Datangi user (calon user Anda). Tanya apa yang perlu dicatat, diolah, disimpan, dan dilaporkan dalam aplikasinya. Lalu secara sederhana tunjukkan layout aplikasi kepada user Anda. Apakah user Anda bisa mengerti ? AKan indah jika dalam membuat layout Anda menggunakan tools, seperti kalau Anda menggunakan NetBean atau Delphi. Bikin form sederhana dan cepat, menjawab kebutuhan user Anda. Jelaskan, mana yang menjadi kunci rekaman, apakah perlu divalidasi, apakah perlu direkam, apakah perlu fasilitas editing. Jadi Anda merancang prototype sambil berkomunikasi langsung dengan user Anda.

    Ketika Anda pulang, sempurnakan prototype Anda. Tambahi sesuai permintaan user. Tambahi implementasi databasenya. Kemudian datangi lagi user Anda itu. Tanyakan apakah sudah mencukupi ? Apa yang perlu ditambah.

    Penambahan dilakukan bertahap. Aplikasinya dibangun mulai dari bentuk sederhana makin lama makin rumit, dan makin membesar. Perhatikan dengan teliti, apa yang menjadi perhatiandari user Anda. Demikian seterusnya, diulangi (iterasi) sampai aplikasinya terbentuk utuh.

    Ada yang bilang, metoda prototype ini disebut juga iterative incremental, bertambah sedikit-dikit sampai utuh lengkap.

    Kelemahannya, jika pembuat prototype tidak mampu membuat program dengan cepat, maka da akan kedodoran. Oleh karena itu, biasanya, programmer prototype harus mahir memanfaatkan tools pemrograman, seperti Eclipse. NetBean.

    Reply
  11. Naruto

    pak wit, saya disuruh dosen saya membandingkan metode ER dengan metode normalisasi, apakah hasil yang diperoleh sama pak??lebih mudah mana normalisasi or ER??

    Metoda ER diakui akan menghasilkan bentuk normal ketiga. Sementara dengan metoda Normalisasi bisa lebih, kalau nggak salah ingat sampai normal ke empat atau lebih.

    Jika Anda punya data berupa dokumen yang berisi contoh tabel data dari user, maka sebaiknya pakai Normalisasi. Namun untuk diimplementasikan di proyek-proyek, biasanya cukup sampai bentuk Normal ketiga.

    Jika Anda tidak punya data berupa dokumen tabel, sebaiknya Anda pakai ER diagram. Dengan berangkat menganalisis mulai dari mengenali entitas data. Entitas data ini substansinya ya dalam aplikasi yang akan dibuat, apa yang perlu dicatat, bagaimana mengolahnya, apa yang perlu direkam dan apa yang perlu dilaporkan. (ingat singkatan CORL di buku saya).

    Contoh pada Rumah Sakit : jika konteks aplikasinya untuk layanan pasien, entitas apa saja yang perlu dicatat dan dilaporkan ? Minimal itu entitas (catatan tentang) pasien, ruang rawat inap, dokter dan paramedis. Ini akan jadi strong entity (file master).

    Baru disitu dikembangkan lagi, kira-kira transaksi yang terjadi apa saja : entitas (catatan tentang) diagnosis, pendaftaran pasien, penempatan pasien, pemberian obat, dan tagihan. Ini akan jadi weak entity.

    Pada Rumah Sakit akan dibutuhkan database lain lagi, seandainya konteks aplikasinya berbeda, misal database untuk mendukung kegiatan laboratorium di rumah sakit itu. Entitasnya beda deui….

    Database pendukung inventaris Rumah Sakit, database pendukung payroll Rumah Sakit, itu entitasnya beda lagi.

    Belajar lagi… yah… biar lebih pinter..

    Reply
  12. Toto Suharto

    Pak Wit, ikutan nimbrung lagi…🙂

    Setahu saya ER adalah MODEL DATA, dan ERD adalah diagram untuk menggambarkannya. Sedangkan normalisasi adalah PROSES DEKOMPOSISI skema relasi karena skema tsb masih mengandung anomali. Jadi pak, pertanyaan (dosennya) Naruto kurang tepat, apakah mungkin membandingkan model data dengan proses dekomposisi? Tidak apple to apple!

    Mungkin yang dimaksud adalah perbandingan perancangan basis data dengan menggunakan pendekatan ER dan tanpa menggunakan ER…

    Wah, menurut saya gambar yang digunakan dalam ERD dan gambar dalam penggunaan Normalisasi beda, euy… he.. he..

    Sementara dalam penjelasan di atas, saya bandingkan cara membentuk tabel data dari database, dengan menggunakan ERD dibandingkan dengan menggunakan gambar dalam metoda Normalisasi.

    Jadi kalau gambar dengan gambar dibandingkan, mestinya masuk dalam kategori apple to apple, toh ?
    🙂

    Nuhun Pak Toto, komentarnya.🙂

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s