Tampilkan postingan dengan label System Operasi. Tampilkan semua postingan
Tampilkan postingan dengan label System Operasi. Tampilkan semua postingan

Metode-Metode Pengembangan Perangkat Lunak

Hallo semua... sudah lama gx berkecinambung dengan keyboard ni tangan, jari-jari jadi kangen dengan petakan tombol, hehhee. kali ini saya ingin mengshare tentang metode pengembangan perangkat lunak yang pada saat ini semakni tinggi daya develope nya. ok langsung saja

1. Linear Sequential Model (Model Sequential Linear)/ Model Waterfall
a. Model Waterfall
Menurut  (Pressman, Roger S. 2001) Metode Waterfall adalah suatu proses pengembangan perangkat lunak berurutan, di mana kemajuan dipandang sebagai terus mengalir ke bawah (seperti air terjun) melewati fase-fase perencanaan, pemodelan, implementasi (konstruksi), dan pengujian.
Tahapan metode Waterfall dapat digambarkan sebagai berikut:


Dalam pengembangannya, metode Waterfall memiliki beberapa tahapan yang runtut: Requirement (analisis kebutuhan), Desain Sistem (system design), Coding & Testing, penerapan program dan pemeliharaan. Tahapan tahapan dari metode Waterfall adalah sebagai berikut :

  1. Requirement Analysis
Pada tahap ini, pengembang sistem diperlukan suatu komunikasi yang bertujuan untuk memahami software yang diharapkan pengguna dan batasan software. Informasi ini biasanya dapat diperoleh melalui wawancara, survei atau diskusi. Informasi tersebut dianalisis untuk mendapatkan data yang dibutuhkan oleh pengguna.
2. System Design
Spesifikasi kebutuhan dari tahap pertama akan dipelajari dalam fase ini dan desain sistem disiapkan. Desain Sistem membantu dalam menentukan perangkat keras dan sistem persyaratan dan juga membantu dalam mendefinisikan arsitektur sistem secara keseluruhan.
3. Implementation
Pada tahap ini, sistempertama kali dikembangkan di program kecil yang disebut unit, yang terintegrasi dalam tahap berikutnya. Setiap unit dikembangkan dan diuji untuk fungsionalitas yang disebut sebagai Unit Testing.
4. Integration dan Testing
Semua unit yang dikembangkan dalam tahap implementasi diintegrasikan ke dalam sistem setelah pengujian masing-masing unit. Pasca integrasi seluruh sistem diuji untuk mengecek  setiap kesalahan dan kegagalan.
5. Operation dan Maintenance
Ini merupakan tahap terakhir dalam model waterfall. Softwareyang  sudah  jadi dijalankan  serta dilakukan pemeliharaan. Pemeliharaan termasuk dalam memperbaiki  kesalahan yang tidakditemukan pada langkah sebelumnya. Perbaikan implementasi unitsistem dan peningkatan jasa sistem sebagai kebutuhan baru
Kelebihan Waterfall :
  • Keuntungan pengembangan dengan metode waterfall adalah metode ini memungkinkan untuk departementalisasi dan kontrol. proses pengembangan model fase satu per satu, sehinggameminimalis kesalahan-kesalahan yang mungkin akan terjadi. Pengembanganya bergerak dari konsep,  yaitu melalui desain, implementasi, pengujian, instalasi, troubleshooting, dan berakhir di operasi dan pemeliharaan.
  • Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan tertentu.
  • Document pengembangan system sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya. Jadi  setiap fase atau tahapan akan mempunyai dokumen tertentu.
  • Metode ini masih lebih baik digunakan walaupun sudah tergolong kuno, daripada menggunakan pendekatan asal-asalan. Selain itu, metode ini juga masih masuk akal jika kebutuhan sudah diketahui dengan baik.
Kerugian Waterfall :
  • Kerugian pembangunan menggunakan metode waterfall adalah tidak memungkinkan untuk banyak refleksi atau revisi jika terjadi kesalahan. Karna setelah aplikasi ini dalam tahap pengujian, sangat sulit untuk kembali dan mengubah sesuatu yang tidak terdokumentasi dengan baik dalam tahap konsep.
  • Diperlukan majemen yang baik, karena proses pengembangan tidak dapat dilakukan secara berulang sebelum terjadinya suatu produk.
  • Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal pengembangan yang berakibat pada tahapan selanjutnya.
  • Pelanggan sulit menyatakan kebutuhan secara eksplisit sehingga tidak dapat mengakomodasi ketidak pastian pada saat awal pengembangan.
  • Pelanggan harus sabar, karena pembuatan perangkat lunak akan dimulai ketika tahap desain sudah selesai. Sedangkan pada tahap sebelum desain bisa memakan waktu yang lama.
  • Pada kenyataannya, jarang mengikuti urutan sekuensial seperti pada teori. Iterasi sering terjadi menyebabkan masalah baru.
b. Model v
Model v merupakan perluasan dari model waterfall. Disebut sebagai perluasan karena tahap-tahapnya mirip dengan yang terdapat dalam model waterfall. Jika dalam model waterfall proses dijalankan secara linear, maka dalam model V proses dilakukan bercabang. Dalam model V ini digambarkan hubungan antara tahap pengembangan software dengan tahap pengujiannya.

Berikut penjelasan masing-masing tahap beserta tahap pengujiannya:


  1. Requirement Analysis & Acceptance Testing
Tahap Requirement Analysis sama seperti yang terdapat dalam model waterfall. Keluaran dari tahap ini adalah dokumentasi kebutuhan pengguna. Acceptance Testing merupakan tahap yang akan mengkaji apakah dokumentasi yang dihasilkan tersebut dapat diterima oleh para pengguna atau tidak.
  1. System Design & System Testing
Dalam tahap ini analis sistem mulai merancang sistem dengan mengacu pada dokumentasi kebutuhan pengguna yang sudah dibuat pada tahap sebelumnya. Keluaran dari tahap ini adalah spesifikasi software yang meliputi organisasi sistem secara umum, struktur data, dan yang lain. Selain itu tahap ini juga menghasilkan contoh tampilan window dan juga dokumentasi teknik yang lain seperti Entity Diagram dan Data Dictionary.
  1. Architecture Design & Integration Testing
Sering juga disebut High Level Design. Dasar dari pemilihan arsitektur yang akan digunakan berdasar kepada beberapa hal seperti: pemakaian kembali tiap modul, ketergantungan tabel dalam basis data, hubungan antar interface, detail teknologi yang dipakai.
  1. Module Design & Unit Testing
Sering juga disebut sebagai Low Level Design. Perancangan dipecah menjadi modul-modul yang lebih kecil. Setiap modul tersebut diberi penjelasan yang cukup untuk memudahkan programmer melakukan coding. Tahap ini menghasilkan spesifikasi program seperti: fungsi dan logika tiap modul, pesan kesalahan, proses input-output untuk tiap modul, dan lain-lain.
  1. Coding
Dalam tahap ini dilakukan pemrograman terhadap setiap modul yang sudah dibentuk.
Keuntungan V Model :
  1. Bahasa yang digunakan untuk merepresentasikan konsep V model menggunakan bahasa formal. Contoh : dengan menggunakan objek model ataupun frame-frame • Meminimalisasikan kesalahan pada hasil akhir karena ada test pada setiap prosesnya
  2. Penyesuaian yang cepat pada projek yang baru
  3. Memudahkan dalam pembuatan dokumen projek
  4. Biaya yang murah dalam perawatan dan modifikasinya
  5. V Model sangat fleksibel. V Model mendukung project tailoring dan penambahan dan pengurangan method dan tool secara dinamik. Akibatnya sangat mudah untuk melakukan tailoring pada V Model agar sesuai dengan suatu proyek tertentu dan sangat mudah untuk menambahkan method dan tool baru atau menghilangkan method dan tool yang dianggap sudah obsolete.
  6. V Model dikembangkan dan di-maintain oleh publik. User dari V Model berpartisipasi dalam change control board yang memproses semua change request terhadap V Model.
Kerugian V Model :
  1. Aktifitas V-Model hanya difokuskan pada projectnya saja, bukan pada keseluruhan organisasi. V-Model adalah proses model yang hanya dikerjakan sekali selama project saja, bukan keseluruhan organisasi.
  2. Prosesnya hanya secara sementara. Ketika project selesai, jalannya proses model dihentikan. Tidak berlangsung untuk keseluruhan organisasi.
  3. Metode yang ditawarkan terbatas. Sehingga kita tidak memiliki cara pandang dari metode yang lain. Kita tidak memiliki kesempatan untuk mempertimbangkan jika ada tools lain yang lebih baik.
  4. oolnya tidak selengkap yang dibicarakan. SDE (Software Development Environment).Tidak ada tools untuk hardware di V-Model. Tool yang dimaksud adalah “software yang mendukung pengembangan atau pemeliharaan / modifikasi dari system IT.
  5. V Model adalah model yang project oriented sehingga hanya bisa digunakan sekali dalam suatu proyek.
  6. V Model terlalu fleksibel dalam arti ada beberapa activity dalam V Model yang digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang termasuk dalam activity tersebut dan apa yang tidak.
2. Metode Prototype (evolusioner)
Proses pengembangan sistem seringkali menggunakan pendekatan prototipe (prototyping).  Metode ini sangat baik digunakan untuk menyelesesaikan masalah kesalahpahaman antara  user  dan analis yang timbul akibat  user  tidak mampu mendefinisikan secara jelas kebutuhannya (Mulyanto, 2009).
Prototyping  adalah pengembangan yang cepat dan pengujian terhadap model kerja (prototipe) dari aplikasi baru melalui proses interaksi dan berulangulang yang biasa digunakan ahli sistem informasi dan ahli bisnis. Prototyping   disebut juga desain aplikasi cepat  (rapid application design/RAD) karena menyederhanakan dan mempercepat desain sistem (O’rien, 2005).
Sebagian  user   kesulitan mengungkapkan keinginannya untuk mendapatkan aplikasi yang sesuai dengan kebutuhannya. &esulitan ini yang perlu diselesaikan oleh analis dengan memahami kebutuhan  user  dan menerjemahkannya ke dalam bentuk model (prototipe). Model ini selanjutnya diperbaiki secara terus menerus sampai sesuai dengan kebutuhan  user.
Model Prototype dapat dilihat pada gambar dibawah ini.


Pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya;Pendekatan Prototyping melewati tiga proses, yaitu pengumpulan kebutuhan, perancangan, dan evaluasi Prototype.  Proses-proses tersebut dapat dijelaskan sebagai berikut:
  1. Perancangan: perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype;
  2. Evaluasi Prototype: klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.
Kelebihan prototyping :
  1. Dapat menjalin komunikasi yang baik antar user dan pengembang sistem
  2. Setiap perbaikan yang dilakukan pada prototype merupakan hasil masukan dari user yang akan menggunakan sistem tersebut, sehingga lebih reliabel
  3. User akan memberikan masukan terhadap sistem sesuai dengan kemauannya
  4. Menghemat waktu dalam mengembangkan sebuah sistem
  5. Menghemat biaya, terutama pada bagian analisa, karena hanya mencatat poin – point penting saja
  6. Cocok digunakan pada sebuah sistem kecil, yang digunakan pada ruang lingkup tertentu, seperti sistem di dalam sebuah kantor
  7. Penerapan dari sistem yang menjadi lebih mudah untuk dilakukan.
Kelemahan dari Metode Prototyping :
  1. Untuk menghemat waktu, biasanya pengembang hanya menggunakan bahasa pemrograman sederhana, yang mungkin rentan dari segi keamanannya
  2. Tidak cocok untuk diimplementasikan pada sebuah sistem yang sangat besar dan global, seperti sistem operasi komputer.
3. Rapid Application Development (RAD)
Rapid Application Development (RAD) adalah strategi siklus hidup yang ditujukan untuk menyediakan pengembangan yang jauh lebih cepat dan mendapatkan hasil dengan kualitas yang lebih baik dibandingkan dengan hasil yang dicapai melalui siklus tradisional (McLeod, 2002). RAD merupakan gabungan dari bermacam-macam teknik terstruktur dengan teknik prototyping dan teknik pengembangan joint application untuk mempercepat pengembangan sistem/aplikasi (Bentley, 2004). Dari definisi-definisi konsep RAD ini, dapat dilihat bahwa pengembangan aplikasi dengan menggunakan metode RAD ini dapat dilakukan dalam waktu yang relatif lebih cepat.
Profesor Clifford Kettemborough dari College Whitehead,  University of Redlands,  mendefinisikan Rapid Application Development sebagai “pendekatan untuk membangun sistem komputer yang menggabungkan Computer Assisted  Software Engineering (CASE) tools dan teknik, user­driven prototyping. RAD meningkatkan kualitas sistem secara drastis dan mengurangi waktu yang diperlukan untuk membangun sistem.




Berikut ini adalah tahap-tahap pengembangan aplikasi dari tiap-tiap fase pengembangan aplikasi.
  1. Requirements Planning (Perencanaan Syarat-Syarat)
Dalam fase ini, pengguna dan penganalisis bertemu untuk mengidentifikasikan tujuan-tujuan aplikasi atau sistem serta untuk megidentifikasikan syarat-syarat informasi yang ditimbulkan dari tujuan-tujuan tersebut. Orientasi dalam fase ini adalah menyelesaikan masalah-masalah perusahaan. Meskipun teknologi informasi dan sistem bisa mengarahkan sebagian dari sistem yang diajukan, fokusnya akan selalu tetap pada upaya pencapaian tujuan-tujuan perusahaan (Kendall, 2010).
  1. RAD Design Workshop (Workshop Desain RAD)
Fase ini adalah fase untuk merancang dan memperbaiki yang bisa digambarkan sebagai workshop. Penganalisis dan dan pemrogram dapat bekerja membangun dan menunjukkan representasi visual desain dan pola kerja kepada pengguna. Workshop desain ini dapat dilakukan selama beberapa hari tergantung dari ukuran aplikasi yang akan dikembangkan. Selama workshop desain RAD, pengguna merespon prototipe yang ada dan penganalisis memperbaiki modul-modul yang dirancang berdasarkan respon pengguna. Apabila sorang pengembangnya merupakan pengembang atau pengguna yang berpengalaman, Kendall menilai bahwa usaha kreatif ini dapat mendorong pengembangan sampai pada tingkat terakselerasi (Kendall, 2010).
  1. Implementation (Implementasi)
Pada fase implementasi ini, penganalisis bekerja dengan para pengguna secara intens selama workshop dan merancang aspek-aspek bisnis dan nonteknis perusahaan. Segera setelah aspek-aspek ini disetujui dan sistem-sistem dibangun dan disaring, sistem-sistem baru atau bagian dari sistem diujicoba dan kemudian diperkenalkan kepada organisasi (Kendall, 2010).
Kelebihan dan Kekurangan RAD
Metode pengembangan sistem RAD relatif lebih sesuai dengan rencana pengembangan aplikasi yang tidak memiliki ruang lingkup yang besar dan akan dikembangkan oleh tim yang kecil. Namun, RAD pun memiliki kelebihan dan kekurangannya sebagai sebuah metodoligi pengembangan aplikasi. Berikut ini adalah kelebihan metodologi RAD menurut Marakas (2006):
  1. Penghematan waktu dalam keseluruhan fase projek dapat dicapai.
  2. RAD mengurangi seluruh kebutuhan yang berkaitan dengan biaya projek dan sumberdaya manusia.
  3. RAD sangat membantu pengembangan aplikasi yang berfokus pada waktu penyelesaian projek.
  4. Perubahan desain sistem dapat lebih berpengaruh dengan cepat dibandingkan dengan pendekatan SDLC tradisional.
  5. Sudut pandang user disajikan dalam sistem akhir baik melalui fungsi-fungsi sistem atau antarmuka pengguna.
  6. RAD menciptakan rasa kepemilikan yang kuat di antara seluruh pemangku kebijakan projek.
Sedangkan, mengacu pada pendapat Kendall (2010), maka dapat diketahui bahwa kekurangan penerapan metode RAD adalah sebagai berikut:
  1. Dengan metode RAD, penganalisis berusaha mepercepat projek dengan terburu-buru.
  2. Kelemahan yang berkaitan dengan waktu dan perhatian terhadap detail. Aplikasi dapat diselesaikan secara lebih cepat, tetapi tidak mampu mengarahkan penekanan terhadap permasalahan-permasalahan perusahaan yang seharusnya diarahkan.
  3. RAD menyulitkan programmer yang tidak berpengalaman menggunakan prangkat ini di mana programmer dan analyst dituntut untuk menguasai kemampuan-kemampuan baru sementara pada saat yang sama mereka harus bekerja mengembangkan sistem.
4. Model Evolutionary Development/ Evolutionary Software Process Models
a. Incremental Model
Incremental model adalah model pengembangan sistem pada software engineering berdasarkan requirement software yang dipecah menjadi beberapa fungsi atau bagian sehingga model pengembangannya secara bertahap. dilain pihak ada mengartikan model incremental sebagai  perbaikan dari model waterfall dan sebagai standar pendekatan topdown. Layaknya Model Waterfall, model ini pun juga memiliki tahapan tahapan untuk perancangan perangkat lunaknya, yaitu:


tahapan tahapan model incremental
  1. Requirement , Requirment adalah proses tahapan awal yang dilakukan pada incremental model adalah penentuan kebutuhan atau analisis kebutuhan.
  2. Specification, Specification adalah proses spesifikasi dimana menggunakan analisis kebutuhan sebagai acuannya.
  3. Architecture Design, adalah tahap selanjutnya, perancangan software yang terbuka agar dapat diterapkan sistem pembangunan per-bagian pada tahapan selanjutnya.
  4. Code setelah melakukan proses desain selanjutnya ada pengkodean.
  5. Test merupakan tahap pengujian dalam model ini.
Beberapa Kelebihan Dari Mode Incremental atara lain :
  1. Merupakan model dengan manajemen yang sederhana
  2. Pengguna tidak perlu menunggu sampai seluruh sistem dikirim untuk mengambil keuntungan dari sistem tersebut. Increment yang pertama sudah memenuhi persyaratan mereka yang paling kritis, sehingga perangkat lunak dapat segera digunakan.
  3. Resiko untuk kegagalan proyek secara keseluruhan lebih rendah. Walaupun masalah masih dapat ditemukan pada beberapa increment. Karena layanan dengan prioritas tertinggi diserahkan pertama dan increment berikutnya diintegrasikan dengannya, sangatlah penting bahwa layanan sistem yang paling penting mengalami pengujian yang ketat. Ini berarti bahwa pengguna akan memiliki kemungkinan kecil untuk memenuhi kegagalan perangkat lunak pada increment sistem yang paling bawah.
  4. Nilai penggunaan dapat ditentukan pada setiap increment sehingga fungsionalitas sistem disediakan lebih awal.
  5. Memiliki risiko lebih rendah terhadap keseluruhan pengembagan sistem,
  6. Prioritas tertinggi pada pelayanan sistem adalah yang paling diuji
Kelemahannya adalah :
  1. kemungkinan tiap bagian tidak dapat diintegrasikan
  2. Dapat menjadi build and Fix Model, karena kemampuannya untuk selalu mendapat perubahan selama proses rekayasa berlangsung
  3. Harus Open Architecture
  4. Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment.
b. Spiral Model/ Spiral Boehm
(Software Engineering by Roger S. Pressman) Model spiral (spiral model) adalah model proses software yang evolusioner yangmerangkai sifat iteratif dari prototipe dengan cara kontrol dan aspek sistematis dari modelsekuensial linier. Model ini berpotensi untuk pengembangan versi pertambahan software secaracepat. Di dalam model spiral, software dikembangkan di dalam suatu deretan pertambahan.Selama awal iterasi, rilis incremental bias merupakan sebuah model atau prototype kertas.Selama iterasi berikutnya, sedikit demi sedikit dihasilkan versi sistem rekayasa yang lebih lengkap.


Komunikasi Pelanggan (Customer Communication)
Tugas yang dibutuhkan untuk membangun komunikasi yang efektif di antarapengembangan dan pelanggan
  1. Perencanaan (Planning)
      • Tugas yang dibutuhkan untuk mendefinisikan sumber
      • Sumber daya, ketepatanwaktu, dan proyek informasi lain yang berhubungan
  1. Analisis Risiko (Risk Analysis)
      • Tugas yang dibutuhkan untuk menaksir risiko
      • Risiko, baik manajemen maupunteknis.
  1. Perekayasaan (Engineering)
      • Tugas yang dibutuhkan untuk membangun satu atau lebih representasi dariaplikasi tersebut.
  1. Konstruksi dan peluncuran (Construction and Release)
      • Tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang (instal) danmemberikan pelayanan kepada pemakai (contohnya pelatihan dan dokumentasi).
  1. Evaluasi pelanggan (Customer Evaluation)
      • Tugas yang dibutuhkan untuk memperoleh umpan balik dari pelanggan dengandidasarkan pada evaluasi  representasi software, yang dibuat selama masa perekayasaan,dan diimplementasikan selama masa pemasangan.
Kelebihan model Spiral:
  • Setiap tahap pengerjaan dibuat prototyping sehingga kekurangan dan apa yang diharapkan oleh client dapat diperjelas dan juga dapat menjadi acuan untuk client dalam mencari kekurangan kebutuhan.
  • Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar.
  • Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak komputer.
  • Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses.
  • Menggunakan prototipe sebagai mekanisme pengurangan resiko dan pada setiap keadaan di dalam evolusi produk.
  • Tetap mengikuti langkah-langkah dalam siklus kehidupan klasik dan memasukkannya ke dalam kerangka kerja iteratif.
  • Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga mengurangi resiko sebelum menjadi permaslahan yang serius.
Kekurangan model Spiral:
  • Banyak konsumen (Client) tidak percaya bahwa pendekatan secara evolusioner dapat dikontrol oleh kedua pihak. Model spiral mempunyai resiko yang harus dipertimbangkan ulang oleh konsumen dan developer.
  • Memerlukan tenaga ahli untuk memperkirakan resiko, dan harus mengandalkannya supaya sukses.
  • Belum terbukti apakah metode ini cukup efisien karena usianya yang relatif baru.
  • Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang serius jika resiko mayor tidak ditemukan dan diatur.
  • Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolute.
5. Component Assembly Model (CAM/ Model Perakitan Komponen)
Pada kali ini saya akan membahas tentang CAM, untuk definisi nya sendiri Component Assembly Model adalah suatu model metodologi penelitian RPL yang merupakan gabungan dari berbagai model yang lain karena terdapat beberapa kesamaan dari model RPL prototype model, spiral boehm model dan RAD model.

Sifat karakteristik dari CAM ini yaitu yang seperti saya sebutkan tadi model spiral boehm dan sangat erat keterikatannya dengan model RAD (Rapid Application Development), model karena model CAM ini menggunakan peralatan-peralatan dan GUI (Graphic User Interface) untuk membangun software. Dengan kata lain pembuatan aplikasinya dibuat dari paket perangkat lunak yang berisi serangkaian komponen yang telah ada sebelumnya. Namun, waktu yang dibutuhkan dapat disesuaikan atau lebih efektif daripada harus mengerjakan program dari awal.
Seperti yang sudah saya sebutkan tadi CAM ini mirip dengan prototype model karena dalam pengembangannya di haruskan membuat prototype sesuai dengan kebutuhan customer agar lebih pasti perancangannya dan sesuai keinginan, dengan langkah ini artinya dapat menghemat dari segi efesiensi waktu dalam pengerjaanya.
Tahapan-tahapan CAM yaitu sebagai berikut :
  1. Tahap identifikasi calon-calon komponen (kelas objek)
  2. Tahap melihat komponen-komponen dalam pustaka
  3. Tahap mengekstrak komponen
  4. Tahap membangun komponen
  5. Tahap menyimpan komponen baru pada pustaka
  6. Tahap mengkonstruksi iterasi ke-n dari sistem.
Kelebihan CAM adalah tinggal mencaplok atau menggunakan program atau komponen yang sudah ada dan menyusunnya menjadi sebuah program yang lebih kompleks dan berkembang sesuai dengan kebutuhan user/pengguna sehingga dapat mengefisienkan penggunaan waktu dan tenaga.  Selain itu, model ini juga menyediakan kemampuan untuk memvisualisasikan hasil rakitan dengan kesanggupan untuk mengukur, menganalisa, merancang dan merancang ulang program.
Kekurangan CAM adalah seringnya program atau komponen-komponen terdahulu tidak kompatibel atau sejalan dengan model perakitan komponen ini sehingga untuk perusahaan berskala kecil akan kesulitan menemukan komponen yang sesuai untuk dirakit.
Jadi, bisa di ambil kesimpulan bahwa CAM ini sesuai di gunakan oleh perusahaan besar yang sudah berpengalaman mengembangkan software. Mereka dapat memanfaatkan software-software yang telah umum dikembangkan sebelumnya menjadi bentuk baru dari software yang ingin dikomersilkan dan para pengembang hanya perlu mengetahui kebutuhan pelanggan, mencari komponen yang berguna yang berguna untuk menjawab kebutuhan pelanggan dan akhirnya menempatkan mereka bersama-sama untuk membangun sebuah program baru yang bermanfaat.
6. The Concurrent Development Model
Concurrent Engineering merupakan model yang dapat direpresentasikan dengan skema sebagai series dari kerangka aktifitas, aksi software engineering dan juga tugas dari jadwal

Pada model ini aktifitas kerja dilakukan secara bersamaan, setiap proses kerja memiliki beberapa pemicu kerja dari aktifitas. Pemicu dapat berasal dari awal proses kerja maupun dari pemicu yang lain karena setiap pemicu akan saling berhubungan. Misalnya proses desain akan berubah atau dihentikan sementara karena ada perubahan permintaan kebutuhan dari customer.
Concurrent Process Model dapat digambarkan secara skematik sebagai rangkaian dari kegiatan teknis utama, tugas dan hubungan antar bagian. Jadi, pada intinya Metode CDM ini suatu skema model yang mengimplementasikan suatu proses kerja yang dilakukan cepat namun dikerjakan secara bersama-sama dan tetap efektif dalam menyelesaikan berbagai penyelesaian masalah sesuai permintaan customer.
Diagram Modeling Activity menunjukkan skematik dari satu aktivitas dengan Concurrent Process Model. Aktivitas analisa pada setiap orang mencatat bagian-bagian di setiap waktu sesuai jadwal. Dengan cara yang sama, aktivitas yang lain seperti komunikasi antara customer dapat digambarkan dengan cara yang sama.
Concurrent Process Model sering digunakan sebagai paradigma untuk pengembangan aplikasi Client/Server. Sistem Client/Server terdiri atas satu set komponen yang fungsional. Ketika diaplikasikan untuk Client/Server, Concurrent Process Model menggambarkan aktivitas di dua dimensi yaitu dimensi sistem dan dimensi komponen.
  1. Dimensi Sistem ditujukan menggunaan tiga aktivitas : Design, Perakitan (Assembly) dan Penggunaan (Use).
  2. Dimensi Komponen ditujukan dengan dua aktivitas : Design dan Realisasi.
Concurrency dicapai dalam jalan dua arah yaitu sebagai berikut :
  1. Sistem dan komponen aktivitas terjadi secara simultan dan dapat diperagakan menggunakan pendekatan yang berorientasi status sebelumnya.
  2. Kekhasan aplikasi Client/Server adalah diterapkan dengan banyak komponen, masing-masing dapat dirancang dan direalisasi secara bersamaan.
Kelebihan dari Model CDM : Hasil yang di dapat akan menghasilkan suatu sistem yang  sangat baik karena terdapat perancangan yang terjadi secara besar dan terencana secara matang.
Kekurangan dari Model CDM : Memungkinkan terjadinya perubahan besar-besaran, maka akan membuat biaya dan waktu yang diperlukan membengkak.
7. Formal Method Models
Teknik formal method adalah teknik yang mengandalkan perhitungan matematika dalam setiap prosesnya. Hanya digunakan pada sistem yang sangat memperhatikan keamanan atau keselamatan dari pengguna keamanan atau keselamatan dari pengguna. Contoh penggunaan teknik ini adalah aerospace engineering.
Dalam ilmu komputer, rekayasa perangkat lunak khusus, metode formal adalah jenis tertentu dari teknik matematis berdasarkan untuk spesifikasi, pengembangan dan verifikasi sistem perangkat lunak dan perangkat keras. Penggunaan metode formal untuk perangkat lunak dan desain hardware dimotivasi oleh harapan bahwa , seperti dalam disiplin ilmu teknik lainnya, melakukan analisis matematis yang tepat dapat berkontribusi untuk keandalan dan ketahanan dari desain.
Metode formal digambarkan sebagai penerapan berbagai cukup luas fundamental ilmu komputer teoritis, dalam kalkuli logika tertentu, bahasa formal, teori automata, dan semantik program, tetapi juga sistem jenis dan tipe data aljabar untuk masalah dalam spesifikasi perangkat lunak dan perangkat keras dan verifikasi.
Metode formal dapat digunakan di sejumlah tingkatan:
Tingkat 0: spesifikasi formal dapat dilakukan dan kemudian program yang dikembangkan dari ini informal. Hal ini telah dijuluki metode formal lite. Ini mungkin menjadi pilihan biaya yang paling efektif dalam banyak kasus.
Tingkat 1: Pengembangan Formal dan verifikasi formal dapat digunakan untuk menghasilkan sebuah program dengan cara yang lebih formal. Misalnya, bukti dari sifat atau penyempurnaan dari spesifikasi untuk program dapat dilakukan. Ini mungkin yang paling tepat dalam sistem integritas tinggi yang melibatkan keselamatan atau keamanan.
Level 2: provers Teorema dapat digunakan untuk melakukan sepenuhnya resmi mesin-diperiksa bukti. Hal ini bisa sangat mahal dan hanya praktis berharga jika biaya kesalahan sangat tinggi (misalnya, dalam bagian-bagian penting dari desain mikroprosesor).
Informasi lebih lanjut mengenai hal ini diperluas di bawah ini.
Seperti dengan semantik bahasa pemrograman, gaya metode formal dapat secara kasar diklasifikasikan sebagai berikut:
Denotational semantik, di mana makna dari suatu sistem dinyatakan dalam teori matematika dari domain. Pendukung metode tersebut bergantung pada sifat dipahami dengan baik domain untuk memberi arti bagi sistem, kritikus menunjukkan bahwa tidak setiap sistem mungkin secara intuitif atau alami dipandang sebagai fungsi.
Operasional semantik, di mana makna dari suatu sistem dinyatakan sebagai urutan tindakan model (mungkin) komputasi sederhana. Pendukung metode tersebut menunjukkan kesederhanaan model mereka sebagai alat untuk kejelasan ekspresif, kritikus kontra bahwa masalah semantik baru saja tertunda (yang mendefinisikan sem       antik dari model sederhana?).
Aksiomatis semantik, dimana arti dari sistem dinyatakan dalam prasyarat dan postconditions yang benar sebelum dan setelah sistem melakukan tugas masing-masing. Para pendukung perhatikan koneksi ke logika klasik, kritik mencatat bahwa semantik seperti itu tidak pernah benar-benar menggambarkan apa yang sistem tidak (hanya apa yang benar sebelum dan sesudahnya).
Lightweight Formal Methods
Beberapa praktisi percaya bahwa masyarakat metode formal telah ditekankan formalisasi penuh spesifikasi atau desain. Mereka berpendapat bahwa ekspresi dari bahasa yang terlibat, serta kompleksitas sistem yang dimodelkan, membuat formalisasi penuh sulit dan tugas mahal. Sebagai alternatif, berbagai metode formal yang ringan, yang menekankan spesifikasi parsial dan aplikasi terfokus, telah diusulkan. Contoh dari pendekatan ringan untuk metode formal termasuk objek Alloy notasi pemodelan, sintesis Denney tentang beberapa aspek dari notasi Z dengan kasus pengembangan penggunaan didorong, dan CSK VDM Alat.
Keuntungan menggunakan teknik formal method adalah : Meminimalkan resiko dengan adanya perhitungan komputasi.
Sedangkan kerugiannya adalah :
  1. biaya tinggi
  2. kompleks
  3. Tidak Umum untuk Ptoyek software pada umumnya
8. Fourth Generation Techniques/Model Teknik Generasi ke-4/4GT

Istilah Fourth Generation Techniques (4GT) mencakup seperangkat peralatan perangkat lunak yang berfungsi sebagai perangkat bantu yang memudahkan seorang pengembang software mengaplikasi beberapa karakteristik software pada tingkat yang tinggi, yang akan menghasilkan source code dan object code secara otomatis sesuai dengan spesifikasi (persyaratan khusus) yang dibuat oleh sang pengembang perangkat lunak.
Dewasa ini, 4GT tools dipakai sebagai bahasa non prosedur untuk DataBase Query, Pembentukan laporan (Report Generation), Manipulasi data, Definisi dan interaksi layar (screen), Pembentukan object dan source (Object and source generation ), Kemampuan grafik yang tinggi, dan Kemampuan spreadsheet.
Tahapan-tahapan model 4GT dapat diringkas sebagai berikut.
Tahap Pengumpulan Kebutuhan: tahap ini dimulai dengan mengumpulkan serangkaian kebutuhan yang nantinya akan diterjemahkan ke dalam prototipe. Namun, apabila pelanggan tidak yakin dengan apa yang diperlukan dan fakta-fakta tidak jelas diketahui maka prototipe tidak dapat dikerjakan oleh peralatan 4GT.
Tahap Merancang Strategi: tahap ini dibutuhkan untuk proyek besar yakni dengan menterjemahkan kebutuhan menjadi prototipe operasional  agar tidak timbul masalah yang sama jika dibuat dengan model konvensional. Namun, untuk proyek skala kecil tahap ini dapat dihilangkan dengan  langsung melakukan implementasi dengan menggunakan bahasa generasi keempat (4GT).
Tahap Implementasi Menggunakan Bahasa Keempat: untuk skala kecil tahap ini dapat langsung dilakukan ketika kebutuhan telah jelas, dan untuk proyek besar tahapan ini dijalankan setelah dirancang prototipe operasional. Implementasi yang menggunakan 4GT memudahkan pengembang software untuk menjelaskan hasil yang diharapkan yang nantinya akan diterjemahkan ke dalam bentuk kode sumber dan kode objek.
Tahap Produksi: Tahap ini merupakan langkah terakhir yakni mengubah implementasi  4GT ke dalam hasil akhir berupa produk.
Kelebihan model ini adalah pengurangan waktu dan peningkatan produktivitas yang besar.
Kekurangan model ini adalah kemungkinan akan sulit memanfaatkan alat bantu/peralatan/tools 4GT dibandingkan dengan menggunakan bahasa pemrograman yang konvensional, selain itu terdapat juga masalah dalam hal kode sumber yang tidak efisien. Di samping itu, pemeliharaan sistem software besar yang dikembangkan oleh 4GT juga masih sedang dalam proses pengkajian.
Model ini diaplikasikan untuk mengembangkan perangkat lunak yang memakai bentuk bahasa khusus atau notasi grafik yang dieksekusi/diselesaikan dengan syarat atau ketentuan yang dipahami oleh pemakai/pengguna/kustomer.






















Share:

Cara Mengganti Theme Windows

Udah lama ni ngak ngepost hehe :) wajar lagi ngak ada duit buat beli kouta,nah akhirnya sekarang saya akan memberi tahu kepada agan tentang cara mengganti theme di windows seperti


nah ini ada bahan dan caranya untuk membuat seperti di atas
  • Download ini dan ini
  • Setelah di download ekstrak semua yang sudah di download
  • Buka folder put_content_inside_of_me_in_your_themes_folder dan copas semua file ke C:\Windows\Resources\Themes 
  • Setelah itu install file UxStyle_sep23_x86_x64.exe
  • Dan klik kanan di desktop lalu pilih personalize
  • nah jika sudah tampil seperti ini

  • Tinggal pilih Theme yang agan mau

Semoga Bermanfaat. . . 
Salam I.C.A.R 
Share:

Cara Konfigurasi PHP Di Linux Slackware 14.1

Jika agan ingin mengkonfigurasi PHP di Linux "Slackware" Khususnya,agan harus merubah httpd.conf yang berada di /etc/httpd menjadi seperti di bawah ini,cara membukanya nano /etc/httpd/httpd.conf,jika tidak mw membenahinya Copas aja dan jika tidak mw Copas download aja script ini disini

#
# This is the main Apache HTTP server configuration file.  It contains the
# configuration directives that give the server its instructions.
# See for detailed information.
# In particular, see 
#
# for a discussion of each configuration directive.
#
# Do NOT simply read the instructions in here without understanding
# what they do.  They're here only as hints or reminders.  If you are unsure
# consult the online docs. You have been warned.  
#
# Configuration and logfile names: If the filenames you specify for many
# of the server's control files begin with "/" (or "drive:/" for Win32), the
# server will use that explicit path.  If the filenames do *not* begin
# with "/", the value of ServerRoot is prepended -- so "logs/access_log"
# with ServerRoot set to "/usr/local/apache2" will be interpreted by the
# server as "/usr/local/apache2/logs/access_log", whereas "/logs/access_log" 
# will be interpreted as '/logs/access_log'.

#
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
#
# Do not add a slash at the end of the directory path.  If you point
# ServerRoot at a non-local disk, be sure to specify a local disk on the
# Mutex directive, if file-based mutexes are used.  If you wish to share the
# same ServerRoot for multiple httpd daemons, you will need to change at
# least PidFile.
#
ServerRoot "/usr"

#
# Mutex: Allows you to set the mutex mechanism and mutex file directory
# for individual mutexes, or change the global defaults
#
# Uncomment and change the directory if mutexes are file-based and the default
# mutex file directory is not on a local disk or is not appropriate for some
# other reason.
#
# Mutex default:/var/run

#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the
# directive.
#
# Change this to Listen on specific IP addresses as shown below to 
# prevent Apache from glomming onto all bound IP addresses.
#
#Listen 12.34.56.78:80
Listen 80

#
# Dynamic Shared Object (DSO) Support
#
# To be able to use the functionality of a module which was built as a DSO you
# have to place corresponding `LoadModule' lines at this location so the
# directives contained in it are actually available _before_ they are used.
# Statically compiled modules (those listed by `httpd -l') do not need
# to be loaded here.
#
# Example:
# LoadModule foo_module modules/mod_foo.so
#
LoadModule authn_file_module lib/httpd/modules/mod_authn_file.so
#LoadModule authn_dbm_module lib/httpd/modules/mod_authn_dbm.so
#LoadModule authn_anon_module lib/httpd/modules/mod_authn_anon.so
#LoadModule authn_dbd_module lib/httpd/modules/mod_authn_dbd.so
#LoadModule authn_socache_module lib/httpd/modules/mod_authn_socache.so
LoadModule authn_core_module lib/httpd/modules/mod_authn_core.so
LoadModule authz_host_module lib/httpd/modules/mod_authz_host.so
LoadModule authz_groupfile_module lib/httpd/modules/mod_authz_groupfile.so
LoadModule authz_user_module lib/httpd/modules/mod_authz_user.so
#LoadModule authz_dbm_module lib/httpd/modules/mod_authz_dbm.so
#LoadModule authz_owner_module lib/httpd/modules/mod_authz_owner.so
#LoadModule authz_dbd_module lib/httpd/modules/mod_authz_dbd.so
LoadModule authz_core_module lib/httpd/modules/mod_authz_core.so
#LoadModule authnz_ldap_module lib/httpd/modules/mod_authnz_ldap.so
LoadModule access_compat_module lib/httpd/modules/mod_access_compat.so
LoadModule auth_basic_module lib/httpd/modules/mod_auth_basic.so
#LoadModule auth_form_module lib/httpd/modules/mod_auth_form.so
#LoadModule auth_digest_module lib/httpd/modules/mod_auth_digest.so
#LoadModule allowmethods_module lib/httpd/modules/mod_allowmethods.so
#LoadModule file_cache_module lib/httpd/modules/mod_file_cache.so
#LoadModule cache_module lib/httpd/modules/mod_cache.so
#LoadModule cache_disk_module lib/httpd/modules/mod_cache_disk.so
#LoadModule cache_socache_module lib/httpd/modules/mod_cache_socache.so
#LoadModule socache_shmcb_module lib/httpd/modules/mod_socache_shmcb.so
#LoadModule socache_dbm_module lib/httpd/modules/mod_socache_dbm.so
#LoadModule socache_memcache_module lib/httpd/modules/mod_socache_memcache.so
#LoadModule watchdog_module lib/httpd/modules/mod_watchdog.so
#LoadModule macro_module lib/httpd/modules/mod_macro.so
#LoadModule dbd_module lib/httpd/modules/mod_dbd.so
#LoadModule dumpio_module lib/httpd/modules/mod_dumpio.so
#LoadModule echo_module lib/httpd/modules/mod_echo.so
#LoadModule buffer_module lib/httpd/modules/mod_buffer.so
#LoadModule data_module lib/httpd/modules/mod_data.so
#LoadModule ratelimit_module lib/httpd/modules/mod_ratelimit.so
LoadModule reqtimeout_module lib/httpd/modules/mod_reqtimeout.so
#LoadModule ext_filter_module lib/httpd/modules/mod_ext_filter.so
#LoadModule request_module lib/httpd/modules/mod_request.so
#LoadModule include_module lib/httpd/modules/mod_include.so
LoadModule filter_module lib/httpd/modules/mod_filter.so
#LoadModule reflector_module lib/httpd/modules/mod_reflector.so
#LoadModule substitute_module lib/httpd/modules/mod_substitute.so
#LoadModule sed_module lib/httpd/modules/mod_sed.so
#LoadModule charset_lite_module lib/httpd/modules/mod_charset_lite.so
#LoadModule deflate_module lib/httpd/modules/mod_deflate.so
#LoadModule xml2enc_module lib/httpd/modules/mod_xml2enc.so
#LoadModule proxy_html_module lib/httpd/modules/mod_proxy_html.so
LoadModule mime_module lib/httpd/modules/mod_mime.so
#LoadModule ldap_module lib/httpd/modules/mod_ldap.so
LoadModule log_config_module lib/httpd/modules/mod_log_config.so
#LoadModule log_debug_module lib/httpd/modules/mod_log_debug.so
#LoadModule log_forensic_module lib/httpd/modules/mod_log_forensic.so
#LoadModule logio_module lib/httpd/modules/mod_logio.so
LoadModule env_module lib/httpd/modules/mod_env.so
#LoadModule mime_magic_module lib/httpd/modules/mod_mime_magic.so
#LoadModule expires_module lib/httpd/modules/mod_expires.so
LoadModule headers_module lib/httpd/modules/mod_headers.so
#LoadModule usertrack_module lib/httpd/modules/mod_usertrack.so
#LoadModule unique_id_module lib/httpd/modules/mod_unique_id.so
LoadModule setenvif_module lib/httpd/modules/mod_setenvif.so
LoadModule version_module lib/httpd/modules/mod_version.so
#LoadModule remoteip_module lib/httpd/modules/mod_remoteip.so
LoadModule proxy_module lib/httpd/modules/mod_proxy.so
LoadModule proxy_connect_module lib/httpd/modules/mod_proxy_connect.so
LoadModule proxy_ftp_module lib/httpd/modules/mod_proxy_ftp.so
LoadModule proxy_http_module lib/httpd/modules/mod_proxy_http.so
LoadModule proxy_fcgi_module lib/httpd/modules/mod_proxy_fcgi.so
LoadModule proxy_scgi_module lib/httpd/modules/mod_proxy_scgi.so
#LoadModule proxy_fdpass_module lib/httpd/modules/mod_proxy_fdpass.so
LoadModule proxy_wstunnel_module lib/httpd/modules/mod_proxy_wstunnel.so
LoadModule proxy_ajp_module lib/httpd/modules/mod_proxy_ajp.so
#LoadModule proxy_balancer_module lib/httpd/modules/mod_proxy_balancer.so
LoadModule proxy_express_module lib/httpd/modules/mod_proxy_express.so
#LoadModule session_module lib/httpd/modules/mod_session.so
#LoadModule session_cookie_module lib/httpd/modules/mod_session_cookie.so
#LoadModule session_dbd_module lib/httpd/modules/mod_session_dbd.so
#LoadModule slotmem_shm_module lib/httpd/modules/mod_slotmem_shm.so
#LoadModule slotmem_plain_module lib/httpd/modules/mod_slotmem_plain.so
#LoadModule ssl_module lib/httpd/modules/mod_ssl.so
#LoadModule dialup_module lib/httpd/modules/mod_dialup.so
LoadModule lbmethod_byrequests_module lib/httpd/modules/mod_lbmethod_byrequests.so
LoadModule lbmethod_bytraffic_module lib/httpd/modules/mod_lbmethod_bytraffic.so
LoadModule lbmethod_bybusyness_module lib/httpd/modules/mod_lbmethod_bybusyness.so
#LoadModule lbmethod_heartbeat_module lib/httpd/modules/mod_lbmethod_heartbeat.so
LoadModule mpm_event_module lib/httpd/modules/mod_mpm_event.so
LoadModule unixd_module lib/httpd/modules/mod_unixd.so
#LoadModule heartbeat_module lib/httpd/modules/mod_heartbeat.so
#LoadModule heartmonitor_module lib/httpd/modules/mod_heartmonitor.so
#LoadModule dav_module lib/httpd/modules/mod_dav.so
LoadModule status_module lib/httpd/modules/mod_status.so
LoadModule autoindex_module lib/httpd/modules/mod_autoindex.so
#LoadModule asis_module lib/httpd/modules/mod_asis.so
#LoadModule info_module lib/httpd/modules/mod_info.so
#LoadModule cgid_module lib/httpd/modules/mod_cgid.so
#LoadModule cgi_module lib/httpd/modules/mod_cgi.so
#LoadModule dav_fs_module lib/httpd/modules/mod_dav_fs.so
#LoadModule dav_lock_module lib/httpd/modules/mod_dav_lock.so
#LoadModule vhost_alias_module lib/httpd/modules/mod_vhost_alias.so
#LoadModule negotiation_module lib/httpd/modules/mod_negotiation.so
LoadModule dir_module lib/httpd/modules/mod_dir.so
#LoadModule actions_module lib/httpd/modules/mod_actions.so
#LoadModule speling_module lib/httpd/modules/mod_speling.so
LoadModule userdir_module lib/httpd/modules/mod_userdir.so
LoadModule alias_module lib/httpd/modules/mod_alias.so
#LoadModule rewrite_module lib/httpd/modules/mod_rewrite.so

#
# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.  
#
# User/Group: The name (or #number) of the user/group to run httpd as.
# It is usually good practice to create a dedicated user and group for
# running httpd, as with most system services.
#
User apache
Group apache


# 'Main' server configuration
#
# The directives in this section set up the values used by the 'main'
# server, which responds to any requests that aren't handled by a
# definition.  These values also provide defaults for
# any containers you may define later in the file.
#
# All of these directives may appear inside containers,
# in which case these default settings will be overridden for the
# virtual host being defined.
#

#
# ServerAdmin: Your address, where problems with the server should be
# e-mailed.  This address appears on some server-generated pages, such
# as error documents.  e.g. admin@your-domain.com
#
ServerAdmin you@example.com

#
# ServerName gives the name and port that the server uses to identify itself.
# This can often be determined automatically, but we recommend you specify
# it explicitly to prevent problems during startup.
#
# If your host doesn't have a registered DNS name, enter its IP address here.
#
ServerName localhost:80

#
# Deny access to the entirety of your server's filesystem. You must
# explicitly permit access to web content directories in other 
# blocks below.
#
    AllowOverride none
    Require all denied

#
# Note that from this point forward you must specifically allow
# particular features to be enabled - so if something's not working as
# you might expect, make sure that you have specifically enabled it
# below.
#

#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/srv/httpd/htdocs"
    #
    # Possible values for the Options directive are "None", "All",
    # or any combination of:
    #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
    #
    # Note that "MultiViews" must be named *explicitly* --- "Options All"
    # doesn't give it to you.
    #
    # The Options directive is both complicated and important.  Please see
    # http://httpd.apache.org/docs/2.4/mod/core.html#options
    # for more information.
    #
    Options Indexes FollowSymLinks

    #
    # AllowOverride controls what directives may be placed in .htaccess files.
    # It can be "All", "None", or any combination of the keywords:
    #   AllowOverride FileInfo AuthConfig Limit
    #
    AllowOverride None

    #
    # Controls who can get stuff from this server.
    #
    Require all granted

#
# DirectoryIndex: sets the file that Apache will serve if a directory
# is requested.
#
    DirectoryIndex index.html index.php index.htm

#
# The following lines prevent .htaccess and .htpasswd files from being 
# viewed by Web clients. 
#
    Require all denied

#
# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a
# container, error messages relating to that virtual host will be
# logged here.  If you *do* define an error logfile for a
# container, that host's errors will be logged there and not here.
#
ErrorLog "/var/log/httpd/error_log"

#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel warn

    #
    # The following directives define some format nicknames for use with
    # a CustomLog directive (see below).
    #
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
    LogFormat "%h %l %u %t \"%r\" %>s %b" common

   
      # You need to enable mod_logio.c to use %I and %O
      LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
   

    #
    # The location and format of the access logfile (Common Logfile Format).
    # If you do not define any access logfiles within a
    # container, they will be logged here.  Contrariwise, if you *do*
    # define per- access logfiles, transactions will be
    # logged therein and *not* in this file.
    #
    CustomLog "/var/log/httpd/access_log" common

    #
    # If you prefer a logfile with access, agent, and referer information
    # (Combined Logfile Format) you can use the following directive.
    #
    #CustomLog "/var/log/httpd/access_log" combined

    #
    # Redirect: Allows you to tell clients about documents that used to 
    # exist in your server's namespace, but do not anymore. The client 
    # will make a new request for the document at its new location.
    # Example:
    # Redirect permanent /foo http://www.example.com/bar

    #
    # Alias: Maps web paths into filesystem paths and is used to
    # access content that does not live under the DocumentRoot.
    # Example:
    # Alias /webpath /full/filesystem/path
    #
    # If you include a trailing / on /webpath then the server will
    # require it to be present in the URL.  You will also likely
    # need to provide a section to allow access to
    # the filesystem path.

    #
    # ScriptAlias: This controls which directories contain server scripts. 
    # ScriptAliases are essentially the same as Aliases, except that
    # documents in the target directory are treated as applications and
    # run by the server when requested rather than as documents sent to the
    # client.  The same rules about trailing "/" apply to ScriptAlias
    # directives as to Alias.
    #
    ScriptAlias /cgi-bin/ "/srv/httpd/cgi-bin/"


    #
    # ScriptSock: On threaded servers, designate the path to the UNIX
    # socket used to communicate with the CGI daemon of mod_cgid.
    #
    #Scriptsock cgisock

#
# "/srv/httpd/cgi-bin" should be changed to whatever your ScriptAliased
# CGI directory exists, if you have that configured.
#
    AllowOverride None
    Options None
    Require all granted

    #
    # TypesConfig points to the file containing the list of mappings from
    # filename extension to MIME-type.
    #
    TypesConfig /etc/httpd/mime.types

    #
    # AddType allows you to add to or override the MIME configuration
    # file specified in TypesConfig for specific file types.
    #
    #AddType application/x-gzip .tgz
    #
    # AddEncoding allows you to have certain browsers uncompress
    # information on the fly. Note: Not all browsers support this.
    #
    #AddEncoding x-compress .Z
    #AddEncoding x-gzip .gz .tgz
    #
    # If the AddEncoding directives above are commented-out, then you
    # probably should define those extensions to indicate media types:
    #
    AddType application/x-compress .Z
    AddType application/x-gzip .gz .tgz

    #
    # AddHandler allows you to map certain file extensions to "handlers":
    # actions unrelated to filetype. These can be either built into the server
    # or added with the Action directive (see below)
    #
    # To use CGI scripts outside of ScriptAliased directories:
    # (You will also need to add "ExecCGI" to the "Options" directive.)
    #
    #AddHandler cgi-script .cgi

    # For type maps (negotiated resources):
    #AddHandler type-map var

    #
    # Filters allow you to process content before it is sent to the client.
    #
    # To parse .shtml files for server-side includes (SSI):
    # (You will also need to add "Includes" to the "Options" directive.)
    #
    #AddType text/html .shtml
    #AddOutputFilter INCLUDES .shtml

#
# The mod_mime_magic module allows the server to use various hints from the
# contents of the file itself to determine its type.  The MIMEMagicFile
# directive tells the module where the hint definitions are located.
#
#MIMEMagicFile /etc/httpd/magic

#
# Customizable error responses come in three flavors:
# 1) plain text 2) local redirects 3) external redirects
#
# Some examples:
#ErrorDocument 500 "The server made a boo boo."
#ErrorDocument 404 /missing.html
#ErrorDocument 404 "/cgi-bin/missing_handler.pl"
#ErrorDocument 402 http://www.example.com/subscription_info.html
#

#
# MaxRanges: Maximum number of Ranges in a request before
# returning the entire resource, or one of the special
# values 'default', 'none' or 'unlimited'.
# Default setting is to accept 200 Ranges.
#MaxRanges unlimited

#
# EnableMMAP and EnableSendfile: On systems that support it, 
# memory-mapping or the sendfile syscall may be used to deliver
# files.  This usually improves server performance, but must
# be turned off when serving from networked-mounted 
# filesystems or if support for these functions is otherwise
# broken on your system.
# Defaults: EnableMMAP On, EnableSendfile Off
#
#EnableMMAP off
#EnableSendfile on

# Supplemental configuration
#
# The configuration files in the /etc/httpd/extra/ directory can be 
# included to add extra features or to modify the default configuration of 
# the server, or you may simply copy their contents here and change as 
# necessary.

# Server-pool management (MPM specific)
#Include /etc/httpd/extra/httpd-mpm.conf

# Multi-language error messages
#Include /etc/httpd/extra/httpd-multilang-errordoc.conf

# Fancy directory listings
#Include /etc/httpd/extra/httpd-autoindex.conf

# Language settings
#Include /etc/httpd/extra/httpd-languages.conf

# User home directories
Include /etc/httpd/extra/httpd-userdir.conf

# Real-time info on requests and configuration
#Include /etc/httpd/extra/httpd-info.conf

# Virtual hosts
#Include /etc/httpd/extra/httpd-vhosts.conf

# Local access to the Apache HTTP Server Manual
#Include /etc/httpd/extra/httpd-manual.conf

# Distributed authoring and versioning (WebDAV)
#Include /etc/httpd/extra/httpd-dav.conf

# Various default settings
#Include /etc/httpd/extra/httpd-default.conf

# Configure mod_proxy_html to understand HTML4/XHTML1
Include /etc/httpd/extra/proxy-html.conf

# Secure (SSL/TLS) connections
#Include /etc/httpd/extra/httpd-ssl.conf
#
# Note: The following must must be present to support
#       starting without SSL on platforms with no /dev/random equivalent
#       but a statically compiled-in mod_ssl.
#
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
#
# uncomment out the below to deal with user agents that deliberately
# violate open standards by misusing DNT (DNT *must* be a specific
# end-user choice)
#
#
#BrowserMatch "MSIE 10.0;" bad_DNT
#
#
#RequestHeader unset DNT env=bad_DNT
#


# Uncomment the following line to enable PHP:
#
AddType application/x-httpd-php .php
Include /etc/httpd/mod_php.conf
# Uncomment the following lines (and mod_dav above) to enable svn support:
#
#LoadModule dav_svn_module lib/httpd/modules/mod_dav_svn.so
#LoadModule authz_svn_module lib/httpd/modules/mod_authz_svn.so

  1. Jika sudah di Copas reboot PC/Laptop agan.
  2. Jika agan download agan pindahkan httpd.conf ke dalam folder /etc/httpd dengan cara
mv root/Download/httpd.conf /etc/httpd
jika sudah Reboot PC/Laptop agan
 
cara mengetahui PHP nya sudah sukses atau belum dengan cara
  • #touch /var/www/htdocs/info.php
  • #nano /var/www/htdocs/info.php
  • setelah terbuka layar blank agan isikan
phpinfo();
?>
 lalu save dengan menekan CTRL+X
  • sekarang buka Web Browser (google chrome,Firefox,dll)
  • coba ketikan localhost/info.php
  • jika sudah terbuka seperti ini itu berarti Configurasi PHP anda Sukses
 

Semoga Bermanfaat. . . 
Salam ICAR. . .
Share: