Langsung ke konten utama

Software Requirements Specification (SRS) Enterprise Resource Planning

Software Requirements Specification (SRS)

Modul Akuntansi, Sales, dan Purchase Order


1. Pendahuluan

1.1 Tujuan Dokumen

Dokumen Software Requirements Specification (SRS) ini bertujuan untuk:

  • Mendefinisikan kebutuhan fungsional dan non-fungsional aplikasi web internal perusahaan yang mengacu pada konsep Odoo (accounting, sales, purchase order).

  • Menjadi acuan bagi tim pengembang, analis sistem, QA, dan stakeholder terkait dalam proses desain, implementasi, dan pengujian.

  • Menjadi dasar untuk pengukuran keberhasilan implementasi sistem.

1.2 Ruang Lingkup Sistem

Aplikasi ini adalah sistem ERP sederhana berbasis web dengan modul utama:

  1. Sales (Penjualan)

  2. Purchase Order (Pembelian)

  3. Accounting (Akuntansi)

Karakteristik utama:

  • Aplikasi monolith, dibangun dengan Django (backend & frontend) dan MySQL sebagai database.

  • Styling menggunakan Bootstrap.

  • Fokus pada:

    • Kemudahan penggunaan (usability).

    • Keamanan aplikasi (security).

  • Digunakan secara internal oleh perusahaan untuk mengelola proses bisnis terkait penjualan, pembelian, dan akuntansi.

1.3 Definisi, Istilah, dan Singkatan

  • Sales Order (SO): Dokumen pemesanan dari customer.

  • Purchase Order (PO): Dokumen pemesanan barang/jasa ke vendor/supplier.

  • Invoice Penjualan: Tagihan ke customer.

  • Invoice Pembelian: Tagihan dari vendor.

  • Chart of Accounts (CoA): Daftar akun-akun dalam sistem akuntansi.

  • User: Pengguna yang terautentikasi.

  • Role: Peran pengguna (Admin, Finance, Sales, Purchasing, Auditor, dll.).

  • ERP: Enterprise Resource Planning.

1.4 Referensi

  • Konsep fungsional mengacu pada modul dasar Odoo (Sales, Purchase, Accounting) sebagai inspirasi alur dan fitur.

  • Standar keamanan web umum (OWASP Top 10).

  • Konsep dasar akuntansi: double entry, debit/kredit, jurnal umum, buku besar.

2. Gambaran Umum Sistem

2.1 Perspektif Produk

Sistem ini adalah aplikasi web internal berbasis browser, bekerja sebagai:

  • Portal terpusat untuk:

    • Membuat dan mengelola Sales Order.

    • Mengelola Purchase Order.

    • Mencatat transaksi keuangan dan menghasilkan laporan akuntansi dasar.

  • Sistem monolith dengan arsitektur web biasa (Django MVC/MVT):

    • Presentation Layer: Template Django + Bootstrap.

    • Business Logic Layer: Django views, services, models.

    • Data Layer: MySQL.

2.2 Fungsi Utama Sistem (Ringkasan)

  1. Autentikasi & Otorisasi

    • Login, logout, manajemen user & role.

  2. Dashboard

    • Ringkasan penjualan, pembelian, piutang, hutang, cashflow sederhana.

  3. Modul Sales

    • Master pelanggan, produk.

    • Pembuatan penawaran (quotation) → konversi ke Sales Order → pengiriman (opsional) → invoice penjualan.

  4. Modul Purchase

    • Master vendor, produk.

    • Purchase Requisition (opsional) → Purchase Order → penerimaan barang (goods receipt) → invoice pembelian.

  5. Modul Accounting

    • Chart of Accounts.

    • Jurnal umum.

    • Posting otomatis dari modul Sales & Purchase.

    • Buku besar, neraca saldo, laporan laba rugi, neraca.

  6. Audit Trail & Log Aktivitas

    • Melacak perubahan data (create, update, delete) oleh user.

  7. Keamanan Data

    • Role-based access control (RBAC).

    • Validasi input, proteksi terhadap serangan umum (SQL Injection, XSS, CSRF, dll).

2.3 Tipe Pengguna

  • Administrator Sistem

    • Kelola user, role, parameter sistem.

  • User Sales

    • Mengelola pelanggan, quotation, SO, invoice penjualan terbatas.

  • User Purchasing

    • Mengelola vendor, PR (bila ada), PO, penerimaan barang, invoice pembelian terbatas.

  • User Finance/Accounting

    • Mengelola CoA, jurnal, rekonsiliasi, laporan keuangan.

  • Manajemen (Director/Manager)

    • Akses read-only ke laporan dan dashboard.

  • Auditor Internal

    • Akses read-only ke log dan laporan tertentu.

2.4 Batasan

  • Sistem hanya diakses melalui browser modern.

  • Tidak ada mobile app khusus (hanya web responsive).

  • Tidak ada API publik ke sistem lain pada fase awal (monolith full).

  • Integrasi dengan sistem eksternal (mis. bank, e-faktur, payroll) tidak termasuk lingkup awal.

3. Kebutuhan Fungsional

3.1 Autentikasi & Otorisasi

FR-001 – Login Pengguna

  • Sistem harus menyediakan halaman login dengan input:

    • Username / Email.

    • Password.

  • Password diverifikasi dengan hash yang aman.

  • Jika login gagal > X kali, akun bisa:

    • Di-lock sementara (configurable) atau

    • Diminta captcha (opsional).

FR-002 – Logout Pengguna

  • Pengguna dapat melakukan logout secara eksplisit.

  • Session harus berakhir dan cookie terkait dihapus/invalid.

FR-003 – Manajemen Pengguna

  • Admin dapat:

    • Membuat user baru.

    • Mengubah data user (nama, email, role, status aktif/nonaktif).

    • Reset password user (mengganti dengan password sementara).

  • Sistem harus menyimpan minimal:

    • Nama lengkap.

    • Username unik.

    • Email.

    • Role.

    • Status (aktif/nonaktif).

FR-004 – Manajemen Role & Permission

  • Admin dapat mendefinisikan role dan mengatur permission terhadap:

    • Menu (Sales, Purchase, Accounting, Settings).

    • Aksi (create, read, update, delete, approve).

  • Mapping role → permission disimpan di database.

FR-005 – Password Policy

  • Password minimal X karakter (mis. 8).

  • Kombinasi huruf besar, huruf kecil, angka, dan simbol (opsional).

  • Sistem menyediakan fitur ubah password dan forgot password (opsional, jika pakai email).

3.2 Dashboard

FR-010 – Dashboard Umum

  • Setelah login, user melihat dashboard yang menampilkan:

    • Total SO bulan berjalan (jumlah & nilai).

    • Total PO bulan berjalan.

    • Piutang dan Hutang outstanding (ringkasan).

    • Notifikasi dokumen yang menunggu approval (jika user adalah approver).

  • Tampilan menyesuaikan role:

    • Sales: fokus pada penjualan.

    • Purchasing: fokus pada pembelian.

    • Finance: fokus pada piutang, hutang, cash/bank.

3.3 Modul Sales

3.3.1 Master Data Sales

FR-020 – Master Customer

  • User Sales / Admin dapat:

    • Menambahkan customer baru.

    • Mengubah data customer.

    • Menonaktifkan customer.

  • Data minimal customer:

    • Kode customer (unik).

    • Nama.

    • Alamat.

    • No. telepon.

    • Email.

    • NPWP (opsional).

    • Term pembayaran (Net 7, Net 30, dll).

    • Status (aktif/nonaktif).

FR-021 – Master Produk (Sales)

  • Sistem menyimpan master produk yang digunakan di Sales & Purchase.

  • Data minimal:

    • Kode produk (unik).

    • Nama produk.

    • Kategori produk.

    • Satuan (unit).

    • Harga jual default.

    • Harga beli default (opsional).

    • Status (aktif/nonaktif).

3.3.2 Proses Sales

FR-030 – Penawaran (Quotation)

  • User Sales dapat membuat quotation:

    • Memilih customer.

    • Menambahkan item produk (qty, harga, diskon).

    • Menambahkan syarat & ketentuan.

  • Sistem menghitung:

    • Subtotal per item.

    • Diskon.

    • PPN (jika diperlukan).

    • Total nilai penawaran.

  • Status quotation:

    • Draft → Sent → Won (menjadi SO) / Lost (gagal).

FR-031 – Konversi Quotation ke Sales Order

  • Quotation dengan status “Won” dapat dikonversi menjadi Sales Order.

  • Data yang diturunkan:

    • Customer, daftar item, harga, syarat pembayaran.

  • Nomor SO di-generate otomatis dengan format tertentu (configurable).

FR-032 – Sales Order (SO) Management

  • User Sales dapat:

    • Membuat SO langsung (tanpa quotation) jika diperlukan.

    • Mengubah SO selama status masih Draft.

    • Melihat histori SO per customer.

  • Status SO:

    • Draft → Confirmed → Partially Delivered (opsional) → Fully Delivered → Invoiced (parsial/ penuh) → Paid (diatur oleh modul accounting).

  • SO yang sudah Confirmed tidak dapat dihapus, hanya dapat dibatalkan (void) dengan log alasan.

FR-033 – Pengiriman Barang (Delivery Order) (opsional)

  • Sistem dapat mencatat pengiriman:

    • Mengacu pada SO.

    • User memilih item dan qty yang dikirim.

  • Status pengiriman mempengaruhi status SO (Partial/Fully Delivered).

FR-034 – Invoice Penjualan Otomatis

  • Dari SO yang sudah Confirmed (atau dari Delivery Order), sistem dapat membuat invoice penjualan.

  • Data invoice:

    • Customer, alamat penagihan.

    • Daftar item & harga.

    • Pajak (PPN).

    • Terms & due date.

  • Status invoice:

    • Draft → Posted → Paid / Partially Paid / Cancelled.

  • Saat Invoice berstatus Posted:

    • Sistem harus membuat jurnal akuntansi otomatis (Piutang Dagang, Penjualan, PPN Keluaran).

3.4 Modul Purchase Order

3.4.1 Master Data Purchase

FR-040 – Master Vendor

  • User Purchasing / Admin dapat:

    • Menambahkan vendor.

    • Mengubah data vendor.

    • Menonaktifkan vendor.

  • Data minimal:

    • Kode vendor (unik).

    • Nama.

    • Alamat.

    • Kontak person.

    • No. telepon.

    • Email.

    • NPWP (opsional).

    • Term pembayaran.

    • Status.

3.4.2 Proses Purchase

FR-050 – Purchase Requisition (Opsional)

  • User non-purchasing dapat membuat request pembelian:

    • Menginput barang yang dibutuhkan, qty, alasan.

  • Purchasing dapat meng-approve dan mengkonversi ke PO.

FR-051 – Purchase Order (PO)

  • User Purchasing dapat membuat PO:

    • Pilih vendor.

    • Daftar item (produk), qty, harga.

    • syarat pembayaran, delivery address.

  • sistem menghitung:

    • Subtotal.

    • Pajak (PPN masukan).

    • Total PO.

  • Status PO:

    • Draft → Confirmed → Received (partial/full) → Invoiced → Paid.

  • PO yang Confirmed tidak bisa dihapus, hanya dibatalkan.

FR-052 – Penerimaan Barang (Goods Receipt)

  • Dari PO, user mencatat penerimaan barang:

    • Qty yang diterima per item.

    • Batch/serial number (opsional).

  • Status penerimaan mempengaruhi:

    • Status PO (Partial/Full).

    • Stok barang jika nanti ada modul Inventory (future).

FR-053 – Invoice Pembelian Otomatis

  • Dari PO (Confirmed/Received) user dapat membuat invoice pembelian.

  • Data invoice:

    • Vendor, alamat, terms, due date.

    • Item & harga, pajak (PPN masukan).

  • Status invoice:

    • Draft → Posted → Paid / Partially Paid / Cancelled.

  • Saat Posted, sistem membuat jurnal otomatis (Hutang Dagang, Persediaan/Beban, PPN Masukan).

3.5 Modul Accounting

3.5.1 Master Data Akuntansi

FR-060 – Chart of Accounts (CoA)

  • User Finance / Admin dapat:

    • Definisikan akun-akun (kode, nama, tipe).

    • Menandai akun sebagai:

      • Asset, Liability, Equity, Revenue, Expense.

    • Menonaktifkan akun (tidak bisa dipakai untuk transaksi baru).

  • Sistem harus mencegah penghapusan akun yang sudah dipakai di jurnal.

FR-061 – Journal Configuration

  • Sistem memberikan template jurnal untuk:

    • Penjualan (Sales Journal).

    • Pembelian (Purchase Journal).

    • Kas/Bank (Cash/Bank Journal).

    • Jurnal Umum.

  • Masing-masing jurnal menentukan default akun yang digunakan untuk posting otomatis.

3.5.2 Transaksi Akuntansi

FR-070 – Jurnal Otomatis

  • Dari Invoice Penjualan & Pembelian, sistem:

    • Membuat jurnal double-entry otomatis.

    • Menandai jurnal sebagai “Auto Generated”.

  • Contoh (Penjualan):

    • Dr Piutang Dagang

    • Cr Penjualan

    • Cr PPN Keluaran

FR-071 – Jurnal Umum Manual

  • User Finance dapat membuat jurnal manual:

    • Memilih jurnal (General).

    • Menginput tanggal, deskripsi.

    • Daftar akun dengan debit/kredit.

  • Sistem memvalidasi:

    • Total debit = total kredit.

  • Jurnal manual diberi status:

    • Draft → Posted.

FR-072 – Rekonsiliasi Pembayaran

  • Pembayaran piutang:

    • Menghubungkan pembayaran dengan invoice penjualan.

    • Mengurangi saldo piutang.

  • Pembayaran hutang:

    • Menghubungkan dengan invoice pembelian.

    • Mengurangi saldo hutang.

  • Sistem harus menampilkan status invoice (Paid, Partially Paid, Outstanding).

3.5.3 Laporan Keuangan

FR-080 – Laporan Buku Besar (General Ledger)

  • User Finance dapat melihat laporan:

    • Per akun.

    • Per periode (filter tanggal).

  • Menampilkan:

    • Saldo awal.

    • Daftar transaksi (debit/kredit).

    • Saldo akhir.

FR-081 – Trial Balance (Neraca Saldo)

  • Sistem menampilkan:

    • Daftar akun dengan total debit/kredit dan saldo.

    • Periode tertentu.

FR-082 – Laporan Laba Rugi

  • Sistem menyusun laporan:

    • Pendapatan.

    • Beban.

    • Laba/rugi bersih.

FR-083 – Neraca (Balance Sheet)

  • Sistem menyusun:

    • Aset.

    • Kewajiban.

    • Ekuitas.

3.6 Audit Trail & Logging

FR-090 – Audit Log

  • Sistem mencatat setiap operasi penting:

    • Login/Logout.

    • Create/Update/Delete pada master dan transaksi (Customer, Vendor, SO, PO, Invoice, Jurnal).

  • Informasi log:

    • Timestamp.

    • User.

    • Jenis operasi.

    • Objek (jenis & ID).

    • Ringkasan perubahan (sebelum / sesudah, minimal field penting).

FR-091 – History Per Dokumen

  • Di layar detail dokumen (SO, PO, Invoice) terdapat tab “History” yang menampilkan:

    • Perubahan status.

    • User yang melakukan.

    • Tanggal & waktu.

3.7 Pengaturan Sistem

FR-100 – Konfigurasi Umum

  • Admin dapat mengatur:

    • Nama perusahaan.

    • Logo perusahaan.

    • Mata uang default.

    • Format penomoran dokumen (prefix, running number).

    • Pajak default (persentase PPN).

    • Kebijakan keamanan (expired password, lock account, dsb).

4. Kebutuhan Non-Fungsional

4.1 Usability

NFR-001 – UI Konsisten

  • UI menggunakan komponen Bootstrap secara konsisten:

    • Navbar, card, table, form, button, modal.

  • Warna dan tipografi mengikuti tema perusahaan (bisa diatur via CSS custom).

NFR-002 – Responsive Design

  • Tampilan bisa diakses dengan nyaman dari desktop/laptop dan tablet.

  • Minimal resolusi desktop 1366x768 didukung penuh.

NFR-003 – Navigasi Sederhana

  • Menu utama:

    • Dashboard

    • Sales

    • Purchase

    • Accounting

    • Settings

  • Breadcrumbs untuk membantu user memahami posisi di dalam sistem.

NFR-004 – Validasi Form yang Jelas

  • Validasi front-end (HTML5 + JS) dan back-end (Django forms).

  • Pesan error jelas dan dekat dengan field terkait.

  • Field wajib diisi ditandai (mis. tanda *).

4.2 Keamanan

NFR-010 – Autentikasi Aman

  • Password disimpan menggunakan algoritma hash yang kuat (mis. PBKDF2, Argon2 atau bcrypt via Django).

  • Wajib gunakan HTTPS pada lingkungan produksi (config di server).

NFR-011 – Proteksi CSRF

  • Setiap form yang memodifikasi data harus menggunakan CSRF token (built-in Django CSRF protection).

NFR-012 – Proteksi XSS & SQL Injection

  • Semua input user divalidasi dan disanitasi.

  • Mengandalkan:

    • ORM Django untuk query database (menghindari raw SQL unescaped).

    • Auto-escaping pada template.

  • Tidak mem-parse input sebagai HTML kecuali betul-betul diperlukan dan aman.

NFR-013 – Role-Based Access Control

  • Setiap request dicek permission-nya berdasarkan role.

  • Endpoint dan view yang tidak berhak harus memunculkan error 403 atau redirect ke halaman lain.

NFR-014 – Session Management

  • Session timeout setelah X menit tidak aktif (configurable).

  • Cookie session diberi flag:

    • HttpOnly.

    • Secure (di produksi).

  • Jika user logout atau password direset, session yang berjalan dapat diinvalidasi (opsional).

NFR-015 – Audit & Logging Keamanan

  • Pencatatan:

    • Percobaan login gagal.

    • Perubahan konfigurasi keamanan.

  • Log disimpan di table khusus dan/atau file log.

4.3 Kinerja (Performance)

NFR-020 – Respons Wajar

  • Untuk beban normal (mis. hingga 50 user konkuren internal):

    • 95% request halaman utama dan form harus merespon < 3 detik.

  • Query database dioptimasi melalui index pada kolom-kolom kunci (id, tanggal dokumen, customer/vendor, dll).

4.4 Reliabilitas & Ketersediaan

NFR-030 – Backup

  • Sistem harus memiliki mekanisme backup database (di level infrastruktur/prosedur):

    • Backup harian (minimal) dengan retensi sejumlah hari tertentu.

  • Dokumentasi prosedur restore database.

NFR-031 – Integritas Data

  • Transaksi penting (invoice, jurnal, posting) harus menggunakan transaction/atomic di Django:

    • Jika satu bagian gagal, seluruh transaksi dibatalkan.

4.5 Maintainability & Extensibility

NFR-040 – Struktur Kode Jelas

  • Kode Django mengikuti:

    • Konsep apps per modul (sales, purchase, accounting, core/settings).

    • Pemisahan models, views, forms, templates, urls, services.

NFR-041 – Dokumentasi

  • Disediakan dokumentasi:

    • Struktur database utama.

    • Flow utama modul (Sales, Purchase, Accounting).

    • Cara deploy & konfigurasi.

4.6 Portabilitas

NFR-050 – Platform

  • Aplikasi dapat berjalan di:

    • Server Linux (disarankan).

    • Web server: gunicorn/uwsgi + Nginx/Apache.

  • MySQL 5.7+ / MariaDB 10.3+.

5. Model Data (Ringkasan)

Ini ringkasan entitas utama (tidak full ERD, tapi cukup sebagai acuan awal).

5.1 Entitas Utama

  • User

    • id, username, password_hash, email, role_id, is_active, created_at, updated_at

  • Role

    • id, name, description

  • Customer

    • id, kode, nama, alamat, phone, email, npwp, term_payment, status

  • Vendor

    • id, kode, nama, alamat, phone, email, npwp, term_payment, status

  • Product

    • id, kode, nama, kategori, satuan, harga_jual_default, harga_beli_default, status

  • Quotation

    • id, nomor, customer_id, tanggal, status, total, user_id, terms

  • QuotationLine

    • id, quotation_id, product_id, qty, harga, diskon, pajak

  • SalesOrder (SO)

    • id, nomor, customer_id, tanggal, status, total, user_id, terms, referensi_quotation

  • SalesOrderLine

    • id, so_id, product_id, qty, harga, diskon, pajak

  • PurchaseOrder (PO)

    • id, nomor, vendor_id, tanggal, status, total, user_id, terms

  • PurchaseOrderLine

    • id, po_id, product_id, qty, harga, diskon, pajak

  • Invoice

    • id, nomor, tipe (sales/purchase), partner_type (customer/vendor), partner_id, tanggal, due_date, status, total, journal_id

  • InvoiceLine

    • id, invoice_id, product_id, qty, harga, pajak, akun_pendapatan/akun_beban

  • Account (CoA)

    • id, kode, nama, tipe, is_active

  • Journal

    • id, kode, nama, tipe, akun_debit_default, akun_kredit_default

  • JournalEntry (Header)

    • id, nomor, tanggal, journal_id, ref, status (draft/posted), created_by

  • JournalItem (Line)

    • id, journal_entry_id, account_id, debit, kredit, keterangan

  • Payment

    • id, nomor, tanggal, tipe (inbound/outbound), amount, metode, rekening, partner_id, invoice_id

  • AuditLog

    • id, user_id, timestamp, action, object_type, object_id, before_data, after_data, ip_address

6. Antarmuka Pengguna (High-Level)

6.1 Layout Global

  • Top Navbar:

    • Logo perusahaan.

    • Nama aplikasi.

    • Menu user (profil, ubah password, logout).

  • Sidebar Menu:

    • Dashboard

    • Sales

      • Customers

      • Products

      • Quotations

      • Sales Orders

      • Invoices

    • Purchase

      • Vendors

      • Purchase Orders

      • Invoices

    • Accounting

      • Chart of Accounts

      • Journals

      • Journal Entries

      • Reports (GL, Trial Balance, P&L, Balance Sheet)

    • Settings

      • Users

      • Roles & Permissions

      • Company Settings

6.2 Desain Form & Tabel

  • Tabel data menggunakan:

    • Paginasi.

    • Pencarian (filter).

    • Sorting kolom.

  • Form input:

    • Menggunakan grid bootstrap (col-*) untuk rapi.

    • Tombol utama (Save, Cancel) selalu di bawah.

7. Aturan Bisnis (Ringkasan)

  • Dokumen dengan status “Posted” atau “Confirmed” tidak boleh dihapus, hanya boleh:

    • Dibatalkan (void) dengan alasan.

    • Dibuat jurnal pembalik (untuk akuntansi, opsional).

  • Tidak boleh ada jurnal dengan debit ≠ kredit.

  • Tidak boleh mengubah CoA yang sudah digunakan di jurnal (hanya boleh nonaktif).

  • Penomoran dokumen (SO, PO, Invoice, Journal) unik per tipe dan per tahun (misal: SO/2025/0001).

8. Kriteria Penerimaan (Acceptance Criteria) Tingkat Tinggi

  • User Sales dapat:

    • Membuat Quotation, mengkonversi ke SO, membuat Invoice, dan melihat status pembayaran.

  • User Purchasing dapat:

    • Membuat PO, mencatat penerimaan, membuat Invoice pembelian.

  • User Finance dapat:

    • Melihat daftar invoice, melakukan pencatatan pembayaran, membuat jurnal manual, dan menghasilkan laporan keuangan dasar.

  • Manajemen dapat:

    • Login, melihat dashboard dan laporan tanpa bisa mengubah data transaksi.

  • Sistem:

    • Mencatat semua audit log penting.

    • Melindungi dari akses tanpa otorisasi (role-based).

    • Dapat berjalan stabil dalam penggunaan harian internal.

Komentar

Posting Komentar

Postingan populer dari blog ini

Cara Efektif Menggunakan StringGrid

StringGrid merupakan salah satu VCL yang sangat berguna. Jika anda sudah familiar dengan Webbased Application, anda bisa analogikan StringGrid dengan Table. Table digunakan untuk meenampilkan data. Adapun StringGrid, selain sebagai komponen untuk menampilkan data, dia juga juga bisa sebagai tempat untuk memasukkan data, lihat gambar di bawah ini : Pada gambar di atas, saya menampilkan form jurnal umum sebagai contoh penggunaan StringGrid. Pada contoh di atas, stringgrid dipakai untuk memasukkan data item jurnal berupa Kode dan nama perkiraan, status Debet/Kredit dan Nominal. Untuk memanfaatkan Stringgrid saya mempunyai beberapa konstanta yang mencerminkan nomor urut kolom, misalnya _KolKode merujuk pada kolom Kode Perkiraan, _KolNama merujuk pada kolom Nama. Lebih jelasnya lihat baris kode berikut : Const _KolKode : Integer = 0; _KolNama : Integer = 1; _KolDK : Integer = 2; _KolNominal : Integer = 3; Konstanta-konstanta tersebut saya pakai di beberapa tempat. Diantaran...
4 komentar
Baca selengkapnya

Tanda-tanda programmer buruk

Dalam dunia pekerjaan, ada berbagai cara untuk menjadi tidak efektif. Berikut adalah beberapa perilaku yang sering terjadi pada beberapa programmer yang pernah saya kerjakan selama bertahun-tahun: "Saya Seorang Insinyur Perangkat Lunak, Bukan Programmer"  Anda tahu seperti apa mereka. Mereka membawa keyboard mekanis ke kantor? Mereka tidak bisa ikut dalam pertemuan harian karena terlalu sibuk memikirkan masalah tersebut (hanya butuh 5 menit untuk menyampaikan apa yang Anda pikirkan). Berapa lama waktu yang dibutuhkan untuk mendapatkan latte? Saya tidak begitu yakin bagaimana seseorang bisa menjadi begitu sombong dengan pengalaman 3 tahun, tapi begitulah adanya. Saya suka mengesankan orang dengan gelar pekerjaan saya. Siapa? Apa maksud Anda, tidak ada yang peduli. Mungkin sebaiknya Anda menghabiskan lebih banyak waktu untuk bekerja dan sedikit waktu untuk memikirkan status Anda? Papan Tulis di Belakang  Beberapa orang di industri ini memiliki gelar. Saya pernah bekerja deng...
Posting Komentar
Baca selengkapnya

Singleton Pattern

Motivasi Kadang ada keadaan di mana kita hanya boleh memiliki satu instan dari suatu kelas. Sebagai contoh, kita hanya boleh memiliki satu window manager (atau satu sistem file atau satu spooler printer) pada satu aplikasi. Biasanya singleton digunakan untuk managemen sumber daya internal maupun eksternal secara terpusat dan bisa diakses dimanapun. Singleton merupkan salah satu design pattern yang paling sederhana. Singleton hanya melibatkan satu kelas yang bertanggung jawab untuk menginstansiasi dirinya sendiri dan pada saat yang bersamaan menyediakan akses secara global terhadap instan tersebut. Pada pattern singleton, instan bisa diakses dari manapun tanpa harus memanggil contructor dari kelas instan tersebut Tujuan • Memastikan bahwa satu kelas hanya bisa dibuat instannya sekali. • Menyediakan akses secara global terhadap instan singleton tersebut. Implementasi Pada bahasa pemrograman Java, implementasi dari singleton adalah dengan membuat sebuah atribut static pada...
Posting Komentar
Baca selengkapnya