Belajar Gratis Sistem Informasi & Informatika

Apa yang dimaksud dengan "penjadwalan" dalam proyek software? Kita telah memilih process model yang sesuai, kita telah mengidentifikasi tugas-tugas software engineering yang harus dilakukan, kita memperkirakan jumlah pekerjaan dan jumlah orang, kita tahu tenggat waktunya, kita bahkan telah mempertimbangkan risikonya. Sekarang saatnya menghubungkan titik-titik tersebut. Artinya, kita harus membuat jaringan tugas dalam software engineering yang akan mendorong kita menyelesaikan pekerjaan tepat waktu. Setelah jaringan tersebut dibuat, kita harus menetapkan tanggung jawab untuk setiap tugas, memastikan itu dilakukan, dan menyesuaikan jaringan tersebut karena ada risiko-risiko yang terjadi. Singkatnya, ini adalah yang disebut dengan penjadwalan dan pelacakan proyek software. Siapa yang melakukannya? Di tingkat proyek, manajer proyek software menggunakan informasi yang diminta dari para software engineer. Pada tingkat individu, para software engineer itu sendiri.

Ruang lingkup proyek software menjelaskan fungsi dan fitur yang akan disampaikan kepada pengguna; data yang merupakan input dan output; "konten" yang disajikan kepada pengguna sebagai konsekuensi dari penggunaan software; dan kinerja, kendala, antarmuka, dan keandalan yang mengikat sistem. Lingkup didefinisikan menggunakan salah satu dari dua teknik berikut: Deskripsi naratif lingkup software dibuat setelah komunikasi dengan semua stakeholder. Satu set use cases dibat oleh para pengguna akhir. Fungsi yang dijelaskan dalam pernyataan ruang lingkup (atau dalam use cases) dievaluasi dan dalam beberapa kasus disempurnakan untuk memberikan rincian lebih lanjut sebelum awal "estimasi" proyek. Karena "estimasi" biaya dan jadwal berorientasi fungsional, beberapa tingkat dekomposisi seringkali bermanfaat. Pertimbangan kinerja mencakup requirements untuk pemrosesan dan waktu respons. Berbagai macam constraints akan mengidentifikasi batasan-batasan yang aka

Apa yang dimaksud dengan "estimasi" dalam proyek software? Kebutuhan nyata akan software sudah ditetapkan; para stakeholder sudah ada, software engineer siap untuk dimulai, dan proyek segera dimulai. Tetapi bagaimana kita melanjutkan perjalanan proyek? Perencanaan dalam proyek software meliputi lima kegiatan utama, yaitu — estimasi, penjadwalan, analisis risiko, perencanaan manajemen mutu, dan perencanaan manajemen perubahan (change management). Dalam konteks ini, kita hanya membahas "estimasi", yaitu — upaya kita untuk menentukan berapa banyak uang, effort, sumber daya, dan waktu yang diperlukan untuk membangun sistem atau produk berbasis software tertentu. Siapa yang melakukan hal ini? Manajer proyek software — dengan menggunakan informasi yang diminta dari para stakeholder proyek dan data metrik software yang dikumpulkan dari proyek sebelumnya.

Meskipun ada banyak ukuran kualitas software, correctness, maintanability, integrity, dan usability adalah yang paling dianggap memberikan indikator yang bermanfaat untuk tim proyek. Gilb memberikan definisi dan ukuran untuk masing-masing poin tersebut. Correctness . Correctness adalah sejauh mana software melakukan fungsi yang diperlukan. Cacat (lack of correctness) adalah berbagai problem yang dilaporkan oleh pengguna program setelah program dirilis ke penggunaan umum. Untuk tujuan penilaian kualitas, cacat dihitung selama periode waktu standar, biasanya satu tahun. Ukuran yang paling umum untuk correctness adalah cacat per KLOC (Kilo Lines of Codes), di mana cacat didefinisikan sebagai kurangnya kesesuaian dengan persyaratan yang terverifikasi.

Ratusan metrik sudah dicoba diusulkan untuk software komputer, tetapi tidak semua memberikan poin yang praktis kepada software engineer. Beberapa pengukuran terlalu kompleks, beberapa yang lain terlalu esoteris sehingga tidak banyak profesional yang mau memahaminya, dan beberapa yang lainnya menabrak gagasan intuitif dasar tentang apa sebenarnya software yang berkualitas tinggi itu.  Ejiogu mendefinisikan seperangkat atribut yang harus ada dalam metrik software yang efektif. Metrik dan pengukuran-pengukuran yang mengarah kesitu haruslah: Sederhana dan dapat dihitung . Sebuah metric seharusnya mudah dipelajari mengenai bagaimana metric tersebut diturunkan. Perhitungan metric seharusnya dapat dilakukan tanpa menyita terlalu banyak waktu dan usaha.

Lossless compression : secara singkat adalah bahwa teknik kompresi ini tidak ada informasi yang hilang. Sehingga metode ini merupakan metoda kompresi data yang memungkinkan data asli dapat disusun kembali dari data hasil kompresi maka rasio kompresi pun tidak dapat terlalu besar untuk memastikan semua data dapat dikembalikan ke bentuk semula. Metode lossless menghasilkan data yang identik dengan data aslinya. Kompresi lossless utamanya digunakan untuk pengarsipan, dan penyuntingan. Untuk keperluan pengarsipan seperti catatan bank, artikel text, dll. Teknik/metode yang masuk ke dalam kategori lossless compression Run-Length Coding (RLC) Entropy Coding  Variable-Length Coding (VLC): Shannon-Fano, Huffman Arithmetic Coding Dictionary-Based / LZ variations coding (LZW, LZ77, LZ78, etc)

Pengertian Manajemen Konfigurasi Software dalam Proses Pembuatan Software Apa itu Manajemen konfigurasi perangkat lunak (SCM / Software Configuration Management)? Ketika kita membuat perangkat lunak komputer, pasti ada perubahan. Dan karena itu pasti terjadi, kita perlu mengelolanya secara efektif. Manajemen konfigurasi perangkat lunak (SCM), sering disebut juga manajemen perubahan (change management), adalah serangkaian kegiatan yang dirancang untuk mengelola perubahan dengan mengidentifikasi produk/hasil kerja yang kemungkinan besar akan mengalami perubahan, membuat hubungan di antara mereka, menentukan mekanisme untuk mengelola berbagai versi produk kerja tersebut, mengendalikan perubahan yang terjadi, dan mengaudit dan melaporkan perubahan yang dilakukan.

Ketika akan merekan video dengan camcorder digital, banyak camcorders digital umumnya akan mengijinkan kita untuk memilih aspect ratio 4:3 atau 16:9. Ada tiga cara untuk menkonversi dari aspect ratio 4:3 ke 16:9, dan ada 2 cara untuk mengkonversi dari 16:9 ke 4:3. Bagaimana cara konversi di atas beserta kelemahan/kerugian dari hasil konversi tersebut? Metode konversi dari aspect ratio 16:9 ke 4:3 Konversi dari 16:9 ke 4:3 : Letter box dan Pan & Scan Letter box Kelemahan: menghasilkan ruang kosong di bagian atas dan bawah Pan and Scan Kelemahan: kehilangan kedua sisi gambar aslinya.

Video analog umumnya didistribusikan sebagai sinyal komposit, koneksi yang hampir universal antara kamera video, pemutar VCR / DVD dan monitor video. Sinyal tersebut kemudian ditumpangkan pada frekwensi radio untuk disalurkan ke rumah-rumah. Jenis-jenis video analog adalah sebagai berikut : Sinyal komposit : Sinyal komposit terdiri dari 3 bagian yaitu Luminance (informasi hitam dan putih), Chrominance (informasi warna) dan Synch (Sinkronisasi), ketiganya digabungkan untuk memastikan bahwa gambar yang ditampilkan tetap dalam waktu dekat dan selaras dengan sumber transmisi. Masalah dengan sinyal komposit adalah ketiga elemen tersebut harus dikodekan agar mereka dapat bergabung sebelum ditransmisikan dan di bagian penerima ketiga elemen ini harus di de-code agar dapat menampilkan gambar. Proses Coding – Decoding ini menyebabkan timbulnya distorsi dan gangguan yang tidak diinginkan. Terdapat 3 sistem pengkodean berbeda yang digunakan di seluruh dunia dan ketiganya tidak kompatibel sat

Maksud dari pengujian beban adalah untuk menentukan bagaimana WebApp dan lingkungan sisi servernya akan merespons berbagai kondisi pemuatan. Saat pengujian berlangsung, permutasi ke variabel berikut menentukan serangkaian kondisi pengujian: N, adalah jumlah pengguna bersamaan T, adalah jumlah transaksi online per unit waktu D, adalah data load yang diproses oleh server per transaksi Dalam setiap kasus, variabel-variabel ini didefinisikan dalam batas operasi normal sistem. Ketika setiap kondisi pengujian dijalankan, satu atau lebih tindakan berikut dikumpulkan, yaitu: rata-rata respons pengguna, rata-rata waktu untuk mengunduh unit data standar, atau rata-rata waktu untuk memproses transaksi. Kita harus memeriksa langkah-langkah ini untuk menentukan apakah penurunan kinerja yang drastis dapat ditelusuri ke kombinasi spesifik dari variabel N, T, dan D.

Dimensi-dimensi yang perlu dipertimbangkan untuk pengujian aplikasi web Pada pengujian aplikasi web, terdapat beberapa dimensi kualitas yang harus diperhatikan, antara lain: a. Content (kontent web) , dievaluasi pada kedua level semantic dan syntactic. b. Function (fungsionalitas) , diuji kebenaran, stabilitasnya, dan kesesuaian general hingga standar implementasi yang layak. c. Structure (struktur) , dinilai untuk memastikan bahwa fungsi dan konten dari aplikasi web disampaikan dengan benar, dapat diperluas, dapat didukung sebagai konten baru atau penambahan fungsionalitas. d. Usability (kemanfaatan) , diuji untuk memastikan bahwa setiap kategori dari user didukung oleh interface, serta dapat mempelajari dan mengaplikasikan semua navigasi yang dibutuhkan. e. Navigability (ke-navigasi-an) , diuji untuk memastikan semua semantic dan sintaks navigasi dilaksanakan utnuk menemukan error navigasi.

Pengujian white-box Pengujian white-box, kadang-kadang disebut pengujian glass-box, adalah filosofi desain pengujian yang menggunakan struktur kontrol yang dideskripsikan sebagai bagian dari desain di component-level untuk menurunkan pengujian. Dengan menggunakan metode pengujian white-box, kita dapat memperoleh kasus pengujian yang (1) menjamin bahwa semua jalur independen dalam modul telah dilakukan setidaknya satu kali, (2) menggunakan semua keputusan logis pada sisi yang benar dan salah, (3) menjalankan semua loop pada rentang batasannya dan dalam batasan operasionalnya, dan (4) menggunakan struktur data internal untuk memastikan validitasnya.

David Garvin menyatakan bahwa kualitas haruslah dipertimbangkan dengan mengambil sudut pandang multidimensi yang dimulai dengan penilaian tentang kesesuaian/kecocokan dan berakhir dengan pandangan transendental (estetika). Meskipun delapan dimensi kualitas dari Garvin tidak dikembangkan secara khusus untuk software, delapan dimensi tersebut dapat diterapkan ketika menelaah kualitas software: Performance quality (kualitas kinerja). Apakah software memberikan semua isi, fungsi, dan fitur yang ditentukan sebagai bagian dari model requirements dengan cara yang memberikan nilai kepada pengguna akhir?

Apakah bisa dimaklumi apabila kita menghasilkan software dengan predikat "good enough (cukup/lumayan baik)"? Jawaban atas pertanyaan ini adalah (harus): "ya," karena perusahaan-perusahaan software besar melakukannya (hal ini) setiap hari. Mereka membuat software dengan bug yang sudah diketahui dan me-rilis-nya ke para pengguna akhir secara masif. Mereka menyadari bahwa beberapa fungsi dan fitur yang ada dalam versi 1.0 mungkin bukanlah kualitas yang tertinggi dan merencanakan untuk perbaikan dalam versi 2.0. Mereka melakukan ini dan tahu bahwa beberapa pelanggan akan mengeluh, tetapi mereka juga menyadari bahwa time-to-market dapat mengalahkan kualitas yang lebih baik asalkan produk yang dirilis adalah berpredikat “cukup baik.” Apa sebenarnya yang dimaksud dengan "cukup baik"? Software yang cukup baik memberikan fungsi dan fitur berkualitas tinggi yang diinginkan pengguna, tetapi pada saat yang sama juga memberikan fungsi dan fitur khusus lainnya yan

Semua developer software pasti setuju bahwa software yang berkualitas tinggi adalah tujuan yang penting. Tetapi bagaimana kita mendefinisikan kualitas software? Dalam arti yang paling umum, kualitas software dapat didefinisikan sebagai: Proses software yang efektif yang diterapkan dengan cara menciptakan produk yang bermanfaat yang memberikan nilai yang bisa diukur bagi si pembuat dan si pengguna . Definisi ini menekankan tiga poin penting: