Site blog

Halaman: () 1 ... 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 ... 41 ()
Gambar dari FATRA NONGGALA PUTRA 5116201057
by FATRA NONGGALA PUTRA 5116201057 - Tuesday, 20 December 2016, 12:56
Anyone in the world

1. Pengertian

Agile Development Methods adalah sekelompok metodologi pengembangan perangkat lunak yang didasarkan pada prinsip-prinsip yang sama atau pengembangan sistem jangka pendek yang memerlukan adaptasi cepat dari pengembang terhadap perubahan dalam bentuk apapun. Agile development methods merupakan salah satu dari Metodologi pengembangan perangkat lunak yang digunakan dalam pengembangan perangkat lunak. Agile memiliki pengertian bersifat cepat, ringan, bebas bergerak, dan waspada. Sehingga saat membuat perangkat lunak dengan menggunakan agile development methods diperlukan inovasi dan responsibiliti yang baik antara tim pengembang dan klien agar kualitas dari perangkat lunak yang dihasilkan bagus dan kelincahan dari tim seimbang. (wikipedia)

 

2. Prinsip Agile Software Development
Agile Software Development juga melihat pentingnya komunikasi antara anggota tim, antara orang-orang teknis dan businessmen, antara developer dan managernya. Ciri lain adalah klien menjadi bagian dari tim pembangun software. Ciri-ciri ini didukung oleh 12 prinsip yang ditetapkan oleh Agile Alliance. Menurut Agile Alliance, 12 prinsip ini adalah bagi mereka yang ingin berhasil dalam penerapan Agile Software Development:

  1. Kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus menerus.
  2. Menerima perubahan kebutuhan, sekalipun diakhir pengembangan.
  3. Penyerahan hasil/software dalam hitungan waktu beberapa minggu sampai beberapa bulan.
  4. Pihak bisnis dan pengembang harus bekerja sama setiap hari selama pengembangan berjalan.
  5. Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja dalam lingkungan yang mendukung dan yang dipercaya untuk dapat menyelesaikan proyek.
  6. Komunikasi dengan berhadapan langsung adalah komunikasi yang efektif dan efisien
  7. Software yang berfungsi adalah ukuran utama dari kemajuan proyek
  8. Dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk menjaga perkembangan yang berkesinambungan
  9. Perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile
  10. Kesederhanaan penting
  11. Arsitektur, kebutuhan dan desain yang bagus muncuk dari tim yang mengatur dirinya sendiri
  12. Secara periodik tim evaluasi diri dan mencari cara untuk lebih efektif dan segera melakukannya.

Dua belas prinsip tersebut menjadi suatu dasar bagi model-model proses yang punya sifat agile. Dengan prinsip-prinsip tersebur Agile Process Model berusaha untuk menyiasati 3 asumsi penting tentang proyek software pada umumnya:

  1. Kebutuhan software sulit diprediksi dari awal dan selalu akan berubah. Selain itu, prioritas klien juga sering berubah seiring berjalannya proyek.
  2. Desain dan pembangunan sering tumpang tindih. Sulit diperkirakan seberapa jauh desain yang diperlukan sebelum pembangunan.
  3. Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan.


3. Kelebihan dari Agile Method

  1. Meningkatkan kepuasan kepada klien
  2. Pembangunan system dibuat lebih cepat
  3. Mengurangi resiko kegagalan implementasi software dari segi non-teknis
  4. Jika pada saat pembangunan system terjadi kegagalan,kerugian dar segi materi relative kecil

 

4. Metode Kerja Agile
Dalam proses pengembangan agile, jika suatu proyek pengembangan software dikerjakan dengan menggunakan metode Agile, maka selama waktu  pengerjaannya akan selalu dijumpai proses pengembangan yang dilakukan berulang. Setiap perulangan (iterasi) meliputi berbagai kegiatan yang wajib dilakukan dalam proyek pengembangan software itu sendiri yaitu :

  1. Perencanaan
  2. Requirements Analysis : Langkah ini merupakan analisa terhadap kebutuhan sistem. Pengumpulan data dalam tahap ini bisa malakukan sebuah penelitian, wawancara atau study literatur. Seorang sistemanalis akan menggali informasi sebanyak-banyaknya dari user sehingga akan tercipta sebuah sistem komputer yang bisa melakukan tugas-tugas yang diinginkan oleh user tersebut. Tahapan ini akan menghasilkan dokumen user requirment  atau bisa dikatakan sebagaidata yang berhubungan dengan keinginan user dalam pembuatan sistem. Dokumen ini yang akan menjadi acuan sistem analis untuk menterjemahkan ke dalam bahasa pemprogram.
  3. Desain : Proses desain akan menerjemahkan syarat kebutuhan kesebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuat coding. Proses ini berfokus pada : struktur data, arsitektur perangkat lunak, representasi interface, dan detail(algoritma) prosedural. Tahapan ini akan menghasilkan dokumen yang disebut software requirment. Dokumen yang akan digunakan proggrammer untuk melakukan aktivitas pembuatan sistemnya.
  4. Coding : Coding merupakan penerjemahan design dalam bahasa yangbisa dikenali oleh komputer. Dilakukan oleh programmer yang akan meterjemahkan transaksi yang diminta oleh user. Tahapan ini yang merupakan tahapan secara nyata dalam mengerjakan suatu sistem.Dalam artian penggunaan komputer akan dimaksimalkan dalam tahapan ini.
  5. Testing :adalah menemukan kesalahan-kesalahan terhadap sistem tersebut dan kemudian bisa diperbaiki
  6. Dokumentasi
5-9436b7c132.jpg
Gambar 1. Tahapan kerja Metode Agile
 
asdm.png
Gambar 2. Model Agile Software Development
 
delivery_agile.gif
Gambar 3. Model Lain dari Model Agile Software Development
 

Bagian dari metode agile software development adalah: Extreme Programming
Keuntungan menggunakan teknik extreme programming.
(a) Menjalin Komunikasi yang Baik dengan Klien.
(b) Meningkatkan Komunikasi dan Sifat Saling Menghargai antar Developer.

Kelemahan menggunakan teknik extreme programming:
(a) Developer harus selalu siap dengan perubahan karena perubahan selalu diterima.
(b) Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga)

Associated Kursus: KI142303KI142303
 
Anyone in the world

1. Pengertian SRS

Software Requirements Specification (SRS) atau dapat diartikan Spesifikasi Kebutuhan Perangkat Lunak (SKPL), adalah suatu dokumen yang menjelaskan tentang berbagai kebutuhan yang harus dipenuhi oleh suatu software. Pada dasarnya SRS adalah suatu dokumen yang menyatakan kebutuhan perangkat lunak sebagai hasil dari proses analisis yang dilakukan dalam konteks pengembangan perangkat lunak. 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. Dokumen ini dibuat untuk membantu membuat spesifikasi perangkat lunak yang akan dikembangkan. Isi dari dokumen ini sebagian besar adalah terjemahan dari dokumen IEEE Std 830-1993.

IEEE membuat standar SRS agar dokumen penting itu tidak ambigu dan tentu saja komplit. Dengan standar itu, user dapat mencurahkan semua keinginannya terkait software tersebut dengan jelas dan akurat sehingga sang developer pun dapat memahami apa yang diinginkan pengguna dengan tepat. Bahkan, bagi perorangan, standar ini dapat membantunya dalam mengembangkan outline SRS yang baku khusus untuk perusahaannya, membantunya membuat dokumen SRS dengan format dan isi yang standar (minimal), serta membantunya mengembangkan rincian-rincian pendukung lainnya. Ada beberapa istilah yang digunakan dan harus diketahui untuk memahami standar SRS yang dibuat IEEE ini. Istilah-istilah tersebut adalah:

  • Kontrak: dokumen yang mengikat secara hukum dan disepakati oleh customer dan supplier, termasuk syarat-syarat teknologi dan organisasi, biaya, serta jadwal pengerjaan. Kontrak bisa mengandung sesuatu yang kurang formal tetapi bermanfaat, seperti komitmen atau harapan dari pihak yang terlibat.
  • Customer (pelanggan) : Pihak yang membayar untuk produk dan biasanya yang menentukan persyaratan (requirements).
  • Supplier (pemasok): Pihak yang membuat produk software untuk customer.
  • Pengguna: Pihak yang mengoperasikan atau berinteraksi langsung dengan software. Pengguna dan customer biasanya bukan orang yang sama.

 

 2. Manfaat SRS

  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.

 

3. Hal yang perlu dipertimbangkan dalam menyusun SRS

  • Sifat SRS

  1. Fungsionalitas : Untuk apa suatu perangkat lunak dibuat.
  2. Antar muka eksternal (External Interface) : Dengan apa perangkat lunak berinteraksi dengan user, system hardware, perangkat keras di luar sistem dan perangkat lunak lain.
  3. Performansi : Sejauh apa kecepatan, ketersediaan (availability), waktu tanggap (response time),waktu recovery dari berbagai fungsi perangkat lunak yang dibuat.
  4. Atribut : Seberapa tingkat portabilitas, tingkat kebenaran (correctness), tingkatpemeliharaan (maintainability), dan tingkat keamanan yang ingin dicapai.
  5. Batasan perancangan : Apakah diperlukan suatu standar, bahasa yang khusus, kebijaksanaan integritasbasisdata, batasan sumberdaya, lingkungan operasi, dan lain-lain yang membatasi pilihan-pilihan yang bisa digunakan atau keputusan-keputusan yang bisa diambilketika perancangan.
  • Lingkungan SRS

Mengingat SKPL pada akhirnya akan menjadi dasar bagi kontrak antara developer dan customer , maka suatu dokumen SKPL harus memenui syarat-syarat berikut:
 
  1. Mendefinisikan kebutuhan software dengan benar. Kebutuhan software muncul karena ada pekerjaan yang harus diselesaikan atau karena ada karakteristik khusus dari proyek.
  2. Tidak menjelaskan rancangan atau implementasi dengan rinci. Penjelasan tersebut tidak diperlukan karena bagi pengguna hal tersebut lebih teknis dan tidak perlu.
  3. Tidak memaksakan penambahan suatu batasan dari perangkat lunak
  • Karakteristik dari SRS yang baik, yaitu:

    1. Correct (benar)
    2. Unambiguous (tidak ambigu, tapi jelas)
    3. Complete (lengkap)
    4. Consistent (konsisten)
    5. Ranked for importance and/or stability (prioritas penting dan atau stabilitas)
    6. Verifiable (dapat diverifikasi)
    7. Modifiable (bisa dimodifikasi)
    8. Traceable (bisa dilacak)

  • Penyusunan SRS secara bersama-sama
  • Evolusi SRS
  • Membuat prototipe, seperti model atau contoh
  • Mencantumkan desain sistem di SRS
  • Pencantuman persyaratan proyek di SRS. Untuk persyaratan proyek ada dokumen tersendiri
Associated Kursus: KI142303KI142303
 
Gambar dari ROZITA 5116201037
by ROZITA 5116201037 - Tuesday, 20 December 2016, 08:17
Anyone in the world
Definisi : Unified Modeling Language, adalah metode untuk memvisualisasikan sistem yang dibuat untuk mempermudah programmer dalam membuat program dengan bahasa pemrograman berbasis objek (OOP).
 
Isi dari UML adalah diagram-diagram yang menunjukkan bagaimana sebuah sistem bekerja. Diagram-diagram UML ada banyak, tapi tidak semua diagram harus dipakai, tergantung kebutuhannya aja. Diagram yang biasanya dipakai adalah ; use case diagram, class diagram, sequence diagram, dan activity diagram 

Tugas untuk membuat UML bukanlah tugas dari seorang programmer, tetapi tugas dari seorang system analyst. UML ini akan menjadi acuan programmer dalam melakukan koding. Buat kita yang lagi belajar aplikasi, bikin UML akan sangat berguna. Kita jadi tahu bagaimana cara membuat aplikasi mulai dari membangun sistemnya itu sendiri. Kita jadi paham betul alur program yang akan kita buat.

Point yang penting dalam membuat UML adalah :

" UML dibuat untuk mempermudah, bukan mempersulit, visualisasikanlah sistem yang seaman mungkin dengan cara yang sesimpel mungkin "

Yang penting adalah UML sistem divisualisasikan secara aman, dan mudah dimengerti oleh programmer.
 
Langkah-Langkah Membuat UML
Dalam membuat UML, setiap orang biasanya mempunyai gayanya masing-masing. Langkah pembuatannya tidak selalu sama. Setelah ane searching ke berbagai sumber di internet, berikut adalah salah satu langkah membuat UML :
 
    1. Membuat Functional requirement
      Pertama kita buat dulu tulisan yang bercerita tentang sistem apa yang akan kita buat. Tulisan ini tidak harus formal dan memiliki format tertentu, kita tulis aja program yang akan kita buat maunya seperti apa terus program itu bisa ngapain aja.

      UML%2B1.png

      Klik Untuk Perbesar
    2. Membuat Use Case Diagram
       
      Kita buat aktor-aktor yang berperan dalam system. Aktor = siapa saja orang yang akan berperan di dalam system, contoh : pegawai, pembeli, manager, supplier. Nah kita gambarkan apa saja yang bisa dilakukan aktor-aktor tersebut di dalam system

      UML%2B2.png
      Klik Untuk Perbesar

 

  1. Membuat Class Diagram
    Kita buat class-class yang ada di dalam system. Kita tentukan attribute-attributenya. Class-class ini adalah class yang nantinya akan digunakan dalam kodingan program. Nanti kita tentukan juga method untuk tiap-tiap classnya. Tetapi penentuan method kita lakukan setelah tahap selanjutnya yaitu membuat sequence diagram.

    UML%2B3.png
    Klik untuk Perbesar
     
  2. Membuat Sequence Diagram.
    sequence%2Bdiagram.gif
    klik untuk perbesar


    Langkah selanjutnya adalah membuat Sequence diagram berdasarkan scenario yang telah kita buat. Sequence diagram ini bisa dibilang adalah model yang lebih detail dari skenario yang telah kita buat, disini kita masukkan hal-hal yang sifatnya lebih menarah ke teknis. Tiap-tiap scenario harus dibuat sequence diagramnya, contoh, misalkan kita punya 3 skenario : 1. Scenario transaksi online 2. Scenario transaksi offline 3. Scenario registrasi. Naah kita buat 3 sequence diagram berdasarkan 3 scenario tersebut.
  3. Membuat Activity Diagram.
    Langkah terakhir adalah membuat activity diagram. Activity diagram ini mirip dengan flow chart. Jadi setelah kita buat 5 hal diatas sekarang kita bisa menggambarkan bagaimana system bekerja secara keseluruhan. Naah sekarang saatnya kita buat diagramnya, diagram tentang bagaimana system bekerja secara keseluruhan

Sumber :http://catatan-syam.blogspot.co.id/2013/11/konsep-langkah-langkah-membuat-uml.html

Associated Kursus: KI142303BKI142303B
 
Gambar dari ROZITA 5116201037
by ROZITA 5116201037 - Tuesday, 20 December 2016, 08:17
Anyone in the world
Saat ini, perangkat lunak memiliki dua peran. Di satu sisi berfungsi sebagai sebuah produk, dan di sisi lain sebagai kendaraan yang mengantarkan sebuah produk. Sebagai produk, perangkat lunak mengantarkan potensi penghitungan yang dibangun oleh perangkat lunak komputer.
Sebagai kendaraan yang dipakai untuk mengantarkan produk perangkat lunak berlaku sebagai dasar untuk kontrol komputer (sistem operasi), komunikasi informasi (jaringan) dan penciptaan serta kontrol dari program-program lain (peranti dan lingkungan perangkat lunak).
 
 
Definisi Perangkat Lunak (PL)
IEEE-Standar Glossary of Software Engineering Terminology, 1990:
“Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.”
Maksudnya :
Perangkat lunak merupakan kumpulan dari program, prosedur, dan dokumen data lain yang saling berhubungan yang merepresentasikan masalah di dunia nyata yang
dikonfigurasikan dalam sebuah bentuk aplikasi yang harus dikerjakan komputer.
 
 
Definisi Rekayasa Perangkat Lunak (RPL)
RPL atau Software Engineering (SE) _ Disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah digunakan. Perangkat Lunak yang dibuat harus mampu:
  1. Tepat waktu
  2. Tepat anggaran
  3. Meningkatkan kinerja
  4. Mengoperasikan prosedur sistem dengan benar
 
Karakteristik Perangkat Lunak
Perangkat lunak lebih merupakan elemen logika dan bukan merupakan elemen sistem fisik. Dengan demikian, perangkat lunak memiliki ciri yang berbeda dari perangkat keras :
  1. Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam bentuk yang klasik (pabrikasi). Biaya untuk perangkat lunak dikonsentrasikan kepada pengembangan. Hal ini berarti proyek perangkat lunak tidak dapat diatur seperti pengaturan proyek-proyek pemanufakturan.
  2. Perangkat lunak tidak pernah usang. Perangkat lunak tidak rentan terhadap pengaruh lingkungan yang merusak yang menyebabkan perangkat keras menjadi usang. Selama hidupnya, perangkat lunak mengalami perubahan (pemeliharaan). Aspek lain dari keusangan menggambarkan perbedaan antara perangkat keras dan perangkat lunak. Bila komponen suatu perangkat keras telah usang, komponen dapat diganti dengan suku cadangnya. Namun tidak ada suku cadang bagi perangkat lunak. Setiap kegagalan perangkat lunak menggambarkan kesalahan dalam perancangan atau proses di mana rancangan diterjemahkan ke dalam kode mesin yang dapat dieksekusi.
  3. Sebagian besar perangkat lunak dibuat secara custom-built, serta tidak dapat dirakit dari komponen yang sudah ada. Perhatikan bagaimana perangkat keras untuk produksi berbasis mikroprosesor dirancang dan dibuat. Setelah masing-masing komponen diseleksi, perangkat keras dapat dipesan secara terpisah. Sementara pada perangkat lunak, tidak katalog komponen perangkat lunak. Memang memungkinkan untuk memesan perangkat lunak secara terpisah, tetapi tetap merupakan satu kesatuan yang lengkap, bukan sebagai komponen yang dapat dipasangkan ke dalam program-program yang baru.
 
 
Bentuk produk perangkat lunak:
1. Produk Generik (Umum)
Sistem stand-alone standar yang diproduksi oleh organisasi pengembang dan dijual ke pasar terbuka ke siapapun yg membelinya. Biasa disebut sebagai software shrink-wrapped.
Contoh : pengolah kata (word processor).
2. Produk pesanan (yang disesuaikan)
Sistem yang dipesan oleh pelanggan tertentu. Dikembangkan khusus bagi pelanggan oleh kontraktor perangkat lunak. Contoh : Sistem untuk mendukung proses bisnis tertentu dan sistem kontrol lalu lintas udara.
 
Perbedaan PENTING antara 2 bentuk perangkat lunak :
  •  Pada produk generik, organisasi yang mengembangkan perangkat lunak mengontrol spesifikasi perangkat lunak.
  •  Pada produk pesanan, spesifikasi biasanya dikembangkan dan dikontrol oleh organisasi yang membeli perangkat lunak tersebut.
 
Karakteristik perangkat lunak yang baik:
  •  Mempunyai daya guna yang tinggi (usability)
  •  Mempunyai kinerja sesuai fungsi yang dibutuhkan pemakai
  •  Mampu diandalkan (be reliable)
  •  Mudah dirawat/diperbaiki (maintenability)
  •  Lebih efisien
  •  Mempunyai antarmuka yg menarik (eye cathcing user interface)
  •  Mempunyai siklus hidup yang cukup lama (long life time)
Aplikasi Perangkat Lunak
Perangkat lunak dapat diaplikasikan ke berbagai situasi di mana serangkaian langkah prosedural (seperti algoritma) telah didefinisikan.
 
 
Perangkat Lunak Sistem. Perangkat lunak sistem merupakan sekumpulan program yang ditulis untuk melayani program-program yang lain. Banyak perangkat lunak sistem (misal kompiler, editor, dan utilitas pengatur file) memproses struktur-struktur informasi yang lengkap namun tetap. Perangkat lunak sistem ditandai dengan eratnya interaksi dengan perangkat keras komputer.
 
Perangkat Lunak Real-Time. Program-program yang memonitor/menganalisis kejadian dunia nyata pada saat terjadinya disebut perangkat lunak real-time. Elemen-elemen perangkat lunak real-time mencakup komponen pengumpul data yang mengumpulkan dan memformat informasi dari lingkungan eksternal, sebuah komponen analisis yang mentransformasi informasi pada saat dibutuhkan oleh aplikasi, sebuah komponen kontrol/output yang memberi respon kepada lingkungan eksternal, serta sebuah komponen monitor yang mengkoordinasi semua komponen lain agar respon real-timenya (I milidetik sampai 1 menit) dapat tetap terjaga. Perlu dicatat di sini bahwa real-time berbeda dengan interaksi atau timesharing. Sistem real-time harus merespon di dalam suatu rentang waktu yang tetap. Waktu respon sebuah sistem interaktif (timesharing) secara normal dapat diperpanjang tanpa memberikan risiko kerusakan pada hasil.
 
Perangkat Lunak Bisnis. Sistem diskrit (contohnya payroll, account receivable/payable, inventory) telah mengembangkan perangkat lunak sistem informasi manajemen (MIS) yang mengakses satu atau lebih database besar yang berisi informasi bisnis. Aplikasi perangkat lunak bisnis juga meliputi penghitungan klien/server serta penghitungan interaktif (misal pemrosesan transaksi point-of-sale).
 
 Perangkat Lunak Teknik dan Ilmu Pengetahuan. Perangkat lunak teknik dan ilmu pengetahuan ditandai algoritma number crunching. Perangkat lunak ini memiliki jangkauan aplikasi mulai dari astronomi sampai vulkanologi, dari analisis otomotif sampai dinamika orbit pesawat ruang angkasa, dan dari biologi molekuler sampai pabrik yang sudah diotomatisasi. Computer-aided design, simulasi sistem, dan aplikasi interaktif yang lain, sudah mulai memakai ciri-ciri perangkat lunak sistem genap dan real-time.
 
Embedded Software. Embedded software ada dalam read-only memory dan dipakai untuk mengontrol hasil serta sistem untuk keperluan konsumen dan pasar industri. Embedded software dapat melakukan fungsi yang terbatas serta fungsi esoterik (misal key pad control untuk microwave) atau memberikan kemampuan kontrol dan fungsi yang penting (contohnya fungsi dijital dalam sebuah automobil seperti kontrol bahan bakar, penampilan dash-board, sistem rem, dll).
 
Perangkat Lunak Komputer Personal. Pengolah kata, spreadsheet, grafik komputer, multimedia, hiburan, manajemen database, aplikasi keuangan, bisnis dan personal, jaringan eksternal atau akses database hanya merupakan beberapa saja dari ratusan aplikasi yang ada.
 
Perangkat Lunak Kecerdasan Buatan. Perangkat lunak kecerdasan buatan (Artificial Inteligent /AI) menggunakan algoritma non-numeris untuk memecahkan masalah kompleks yang tidak sesuai untuk perhitungan atau analisis secara langsung. Perangkat lunak kecerdasan buatan adalah pengenalan pola (image dan voice), pembuktian teorema, dan permainan game. Di tahun-tahun terakhir, cabang perangkat lunak kecerdasan buatan yang baru, yang disebut artificial neural network, telah berkembang. Jaringan syaraf mensimulasi struktur proses-proses otak dan kemudian membawanya kepada perangkat lunak kelas baru yang dapat mengenali pola-pola yang kompleks serta belajar dari pengalaman-pengalaman masa lalu.
 
Sumber : http://bokdimal.blogspot.co.id/2013/03/produk.html
Associated Kursus: KI142303BKI142303B
 
Gambar dari ROZITA 5116201037
by ROZITA 5116201037 - Tuesday, 20 December 2016, 08:16
Anyone in the world

Pada dasarnya seorang pengguna komputer dalam menggunakan software atau perangkat lunak hanya bisa memakainya saja. Akan tetapi hampir kebanyakan dari pengguna komputer tidak menyadari bahwa software yang mereka gunakan suatu saat bisa saja tidak dapat digunakan lagi karena beberapa faktor. berikut akan saya jelaskan sedikit mengenai apa itu software, bagaimana pemeliharaan software, apa saja jenis dalam memelihara software, dan juga manfaat yang akan kita dapatkan jika kita memelihara software.

Perangkat lunak (software) adalah seluruh komponen pengolahan data yang dapat membantu memecahkan masalah diluar dari perangkat hardware yang meliputi system design, program dan prosedur.

Beberapa penggambaran umum tentang perangkat lunak :

  1. Perintah (program komputer) yang mana bila dieksekusi akan menghasilkan fungsi sebagai mana yang kita inginkan.
  2. Struktur data yang memungkinkan suatu aplikasi dapat memanipulasi informasi secara proporsional.
  3. Dokumen yang menggambarkan suatu kegunaan dari pada sebuah program.
Perangkat lunak tersebut dibedakan menjadi 2 tipe yaitu :
  1. Produk Generik, yaitu sistem stand alone yang di produksi oleh perusahaan pengembang perangkat lunak dan di pasarkan ke pasar umum. Contohnya: Microsoft Office.
  2. Produk Pesanan, yaitu produk perangkat lunak yang mana akan dikembangkan bila ada perusahaan/konsumen yang memesannya. Contohnya: Sistem Penerimaan Mahasiswa untuk sebuah kampus.

Sedangkan, Pemeliharaan Perangkat lunak (software) adalah proses umum pengubahan/pengembangan perangkat lunak setelah diserahkan ke konsumen. Perubahan mungkin berupa perubahan sederhana untuk membetulkan error koding atau perubahan yang lebih ekstensif untuk membetulkan error perancangan/perbaikan signifikan untuk membetulkan error spesifikasi/akomodasi persyaratan baru.

Ada 4 katagotri pemeliharaan software yaitu :

  1. Corrective Maintenance, perubahan yang dilakukan guna memperbaiki kesalahan.
  2. Adaptive Maintenance, perawatan berdasarkan perubahan lingkungan.
  3. Perfective Maintenance, perubahan untuk meningkatkan kualitas sistem tanpa merubah fungsinya.
  4. Preventive Maintenance, Meningkatkan reliability, future maintainability, future enhancement (reverse engineering dan re-engineering).
Beberapa permasalahan yang sering muncul dalam pemeliharaan software :
  • Kesulitan melakukan pelacakan evolusi software pada versi sebelumnya.
  • Kesulitan pelacakan pada proses pengembangan software.
  • Sulit untuk mengerti program orang lain.
  • Tidak adanya dokumentasi yang baik.
  • Tidak adanya narasumber.
  • Kebanyakan software dirancang tanpa adanya pemikiran untuk diubah.

Manfaat dari pemeliharaan software yang bersifat preventif :

  • Pemeliharaan Pencegahan Layanan yaitu Pembaruan perangkat lunak anti-virus, scan virus secara teratur, terus update antivirus perangkat lunak saat ini. Minimalkan resiko yang terkait dengan menerima file yang terinfeksi. File berharga tidak terganggu/dirusak oleh infeksi virus.
  • Backup data, perlindungan dan Pemulihan Bencana. Mengevaluasi strategi cadangan, pengujian, pemantauan dan verifikasi fungsi backup data dan mengembalikan. Meningkatkan uptime sistem dan kritis ketersediaan data dalam kasus kehilangan data. Backup merupakan bagian penting dari perlindungan data.

 

Sumber : http://shandabrotz.blog.widyatama.ac.id/2014/01/07/rpl-tugas-10-pemeliharaan-jenis-pemeliharaan-dan-manfaat-pemeliharaan-software/

Associated Kursus: KI142303BKI142303B
 
Gambar dari ROZITA 5116201037
by ROZITA 5116201037 - Tuesday, 20 December 2016, 08:15
Anyone in the world

Pengujian perangkat lunak (software testing) adalah bagian integral dari sebuah pembangunan perangkat lunak (software development). Sering kali, pembangunan sebuah perangkat lunak disempitkan dengan pengkodean (coding) atau pemograman dan pengujian perangkat lunak adalah salah satu proses vital dalam pembangunan perangkat lunak yang sering diabaikan. Padahal proses ini sangat penting, terutama untuk pembangunan perangkat lunak yang akan diproduksi secara masal (mass production), yang menuntut adanya jaminan mutu dan bebas kesalahan (bug-free) sebelum masuk pada tahap produksi. Meskipun begitu, untuk pembangunan perangkat lunak berdiri sendiri (standalone) atau dibangun untuk keperluan tertentu (in-house development), proses pengujian akan dapat menurunkan secara signifikan biaya pembangunan (development cost) dan biaya perawatan (maintenance cost).

Tulisan ini bertujuan memberikan gambaran umum tentang pengujian perangkat lunak dan mengklarisifikasi beberapa istilah yang sering membingungkan. Secara umum pengujian perangkat lunak adalah satu proses mengeksekusi perangkat lunak yang dibangunkan untuk mendeteksi dan menemukan perbedaan antara aktual dan yang dirancang atau diperlukan atau dituntut atau diharapkan. Lebih detilnya, definisi “Testing” menurut American National Standards Institute dan IEEE adalah sebagai berikut: “A process of analyzing a software item to detect the differences between existing and required conditions (that is defects/errors/bugs) and to evaluate the features of the software item” Dapat dikatakan bahwa tujuan utama pengujian perangkat lunak adalah untuk memastikan tidak ada kesalahan dan sesuai dengan ekspektasi yang diharapkan yang tertuang dalam rencana dan perancangan yang telah dibuat dan disetujui sebelumnya. Lalu kapan sebenarnya pengujian perangkat lunak itu perlu dilakukan dan kapan pengujian harus diakhiri? Tidak ada satu petunjuk yang memastikan kapan harus dimulai, tetapi ditahun 1976 Boehm menyimpulkan dari beberapa studi kasus di beberapa perusahaan besar IT dunia, bahwa semakin lambat satu kesalahan ditemukan, maka biaya perbaikannya akan meningkat pesat secara exponensial seperti digambar berikut. CostSoftwareError Menentukan kapan pengujian perangkat lunak harus dihentikan lebih sulit lagi, karena tidak ada seseorang pun yang dapat mengatakan bahwa perangkat lunaknya telah teruji 100%. Akan tetapi ada beberapa kondisi atau keadaan dimana bisa dipertimbangkan bahwa pengujian suatu perangkat lunak bisa dihentikan. Pertama, bila tengat waktu pengujian telah ditentukan dan telah sampai waktu tengatnya. Kedua, bila eksekusi dengan skenario hasil yang ditetapkan telah selesai. Ketiga, bila fungsi yang harus ada dan tingkat pengkodean telah mencapai batas tertentu. Keempat, bila tingkat kesalahan (bug rate) turun pada level yang bisa ditolerir dan tidak ada kesalahan fatal yang terindentifikasi. Dan, terakhir apabila ada keputusan dari pihak manajemen.

Pengujian Perangkat Lunak (Software Testing) Vs Pembetulan Perangkat Lunak (Software Debugging) Pengujian perangkat lunak bukanlah pembetulan perangkat lunak dan dilakukan oleh dua peran (role) yang berbeda, walau dalam keseharian peran ini bisa dilakukan oleh orang yang sama. Pengujian perangkat lunak yang dilakukan oleh seorang penguji (tester) melibatkan identifikasi kesalahan (error/bug/defect) tanpa terlibat dalam perbaikan. Sedangkan pembetulan perangkat lunak yang dilakukan oleh seorang pemogram (developer) adalah aktivitas mengindentifikasi kesalahan, mengisolirnya dan memperbaiki kesalahan yang ditemukan. Jadi boleh dikatakan seorang penguji melakukan validasi (validation) terhadap perangkat lunak yang dibangun oleh seorang atau kumpulan pemogram termasuk menguji kesesuaian fungsi-fungsi dengan keperluan/tuntutan (requirement) yang telah didefinisikan. Pertanyaan-pertanyaan yang mungkin muncul dalam proses validasi ini, misalnya: Apakah pemogram telah membangun perangkat lunak yang benar? Apakah fungsi-fungsi yang didefinisikan bisa bekerja dengan benar? Proses validasi ini dilakukan dengan anggapan bahwa pemogram telah melakukan proses verifikasi (verification) sebelum dan selama proses pembangunan perangkat lunak untuk mencapai objektif pembangunan sebuah perangkat lunak. Pertanyaan-pertanyaan yang mungkin muncul dalam proses verifikasi ini, misalnya: Apakah perangkat lunak dibangun dengan benar? Apakah perangkat lunak berfungsi secara benar? Dalam proses validasi dan verifikasi ini ada beberapa terminologi yang biasa dijumpai: Error: Keadaan atau kondisi yang diharapkan berbeda dengan apa yang didapati Fault: Keadaan dimana perangkat lunak gagal melakukan apa yang diharapkan Failure: Keadaan dimana perangkat gagal melakukan fungsi-fungsi tertentu Pengujian Perangkat Lunak Vs Jaminan Mutu (Qualitiy Assurrance) dan Pengawasan Mutu (Quality Control) Dikarenakan pengujian perangkat lunak juga berkenaan dengan mutu, maka beberapa terminologi yang berkenaan dengan mutu sering juga disinggung dalam pembahasan pengujian perangkat lunak. Aktivitas dalam jaminan mutu adalah untuk memastikan bahwa proses, prosedur dan standar yang digunakan dalam proses verifikasi dilakukan sesuai untuk perangkat lunak yang dibangun dan keperluan yang diinginkan. Sedangkan aktivitas pengawasan mutu adalah untuk memastikan bahwa perangkat lunak yang dibangun sesuai dengan keperluan yang sudah didokumentasikan (documented requirements). Jadi kedua aktivitas jaminan dan pengawasan mutu ini berbeda dengan aktivitas dalam pengujian perangkat lunak yang dalam hal ini adalah untuk mengindentifikasi kesalahan.

 

sumber : http://mti.binus.ac.id/icasce2013/single/pengujian-perangkat-lunak

Associated Kursus: KI142303BKI142303B
 
Anyone in the world
  • Business Workflow Components. After the UI components collect input from the user and pass it to the business layer, the application can use this input to perform a business process. Many business processes involve multiple steps that must be performed in the correct order, and may interact with each other through an orchestration. Business workflow components define and coordinate long-running, multistep business processes, and can be implemented using business process management tools. Business workflow components work with business process components that instantiate and perform operations on workflow components. For more information on business workflow components.
  • Business Entity Components. Business entities, or—more generally—business objects, encapsulate the business logic and data necessary to represent real world elements, such as Customers or Orders, within your application. They store data values and expose them through properties; contain and manage business data used by the application; and provide stateful programmatic access to the business data and related functionality. Business entities also validate the data contained within the entity and encapsulate business logic to ensure consistency and to implement business rules and behavior. For more information about business entity components.
 
Anyone in the world

Business layer components implement the core functionality of the system, and encapsulate the relevant business logic. The following types of components are commonly found in the business layer:

  • Application Façade. This optional component typically provides a simplified interface to the business logic components, often by combining multiple business operations into a single operation that makes it easier to use the business logic, and reduces dependencies because external callers do not need to know details of the business components and relationships between them.
  • Business Logic Components. Business logic is defined as any application logic that is concerned with the retrieval, processing, transformation, and management of application data; application of business rules and policies; and ensuring data consistency and validity. To maximize reuse opportunities, business logic components should not contain any behavior or application logic that is specific to a use case or user story.
 
Anyone in the world

The User Requirements Specification describes the business needs for what users require from the system. User Requirements Specifications are written early in the validation process, typically before the system is created. They are written by the system owner and end-users, with input from Quality Assurance. Requirements outlined in the URS are usually tested in the Performance Qualification or User Acceptance Testing. User Requirements Specifications are not intended to be a technical document; readers with only a general knowledge of the system should be able to understand the requirements outlined in the URS.

The URS is generally a planning document, created when a business is planning on acquiring a system and is trying to determine specific needs. When a system has already been created or acquired, or for less complex systems, the user requirement specification can be combined with the functional requirements document.

User Requirements Examples

Good requirements are objective and testable. For example:

  • Screen A accepts production information, including Lot, Product Number, and Date.
  • System B produces the Lab Summary Report.
  • Twenty users can use System C concurrently without noticeable system delays.
  • Screen D can print on-screen data to the printer.
  • System E will be compliant with 21 CFR 11.

The URS should include:

  • Introduction – including the scope of the system, key objectives for the project, and the applicable regulatory concerns
  • Program Requirements – the functions and workflow that the system must be able to perform
  • Data Requirements – the type of information that a system must be able to process
  • Life Cycle Requirements – including how the system will be maintain and users trained

For more examples and templates, see the User Requirements Specification Template.

Requirements are usually provided with a unique identifier, such as an ID#, to aid in traceability throughout the validation process.

User Requirements Specifications should be signed by the system owner, key end-users, and Quality. Once approved, the URS is retained according to your organization’s practices for document retention.

Alternative Document Names and Acronyms

The following terms or abbreviations are sometimes used: User Requirements Specification, User Requirement Specifications, User Requirements, User Specifications, URS, UR, US.

Validation Document Resources

Associated Kursus: KI141325AKI141325A
 
Anyone in the world

The User Requirements Specification describes the business needs for what users require from the system. User Requirements Specifications are written early in the validation process, typically before the system is created. They are written by the system owner and end-users, with input from Quality Assurance. Requirements outlined in the URS are usually tested in the Performance Qualification or User Acceptance Testing. User Requirements Specifications are not intended to be a technical document; readers with only a general knowledge of the system should be able to understand the requirements outlined in the URS.

The URS is generally a planning document, created when a business is planning on acquiring a system and is trying to determine specific needs. When a system has already been created or acquired, or for less complex systems, the user requirement specification can be combined with the functional requirements document.

User Requirements Examples

Good requirements are objective and testable. For example:

  • Screen A accepts production information, including Lot, Product Number, and Date.
  • System B produces the Lab Summary Report.
  • Twenty users can use System C concurrently without noticeable system delays.
  • Screen D can print on-screen data to the printer.
  • System E will be compliant with 21 CFR 11.

The URS should include:

  • Introduction – including the scope of the system, key objectives for the project, and the applicable regulatory concerns
  • Program Requirements – the functions and workflow that the system must be able to perform
  • Data Requirements – the type of information that a system must be able to process
  • Life Cycle Requirements – including how the system will be maintain and users trained

For more examples and templates, see the User Requirements Specification Template.

Requirements are usually provided with a unique identifier, such as an ID#, to aid in traceability throughout the validation process.

User Requirements Specifications should be signed by the system owner, key end-users, and Quality. Once approved, the URS is retained according to your organization’s practices for document retention.

Alternative Document Names and Acronyms

The following terms or abbreviations are sometimes used: User Requirements Specification, User Requirement Specifications, User Requirements, User Specifications, URS, UR, US.

Validation Document Resources

 
Halaman: () 1 ... 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 ... 41 ()