Konsep dan Prinsip Analisis

Konsep dan Prinsip Analisis

1. Analisis kebutuhan P.L

Analisa kebutuhan merupakan langkah awal untuk menentukan perangkat lunak seperti apa yang akan dihasilkan, ketika kita melaksanakan sebuah proyek pembuatan perangkat lunak. Perangkat lunak yang baik dan sesuai dengan kebutuhan pengguna sangat bergantung kepada keberhasilan dalam melakukan analisa kebutuhan. Tidak peduli bagaimana hebatnya seseorang dalam menulis kode perangkat lunak, atau membuat antar muka yang menawan, jika terjadi kesalahan dalam analisa kebutuhan, itu artinya perangkat lunak yang dibuat menjadi tak berguna.

Analisa kebutuhan adalah sebuah proses untuk mendapatkan informasi, model, spesifikasi tentang perangkat lunak yang diinginkan klien/pengguna. Kedua belah pihak, yaitu klien dan pembuat perangkat lunak terlibat aktif dalam tahap ini. Informasi yang diperoleh dari klien/pengguna inilah yang menjadi acuan untuk melakukan desain perangkat lunak.

Ada 3 faktor yang harus dipenuhi ketika melakukan analisa kebutuhan ini yaitu : lengkap, detail, dan benar. Lengkap artinya semua yang diharapkan oleh klien telah didapatkan oleh pihak yang melakukan analisa. Sedangkan detail maksudnya adalah berhasil mengumpulkan informasi yang rinci sampai hal-hal yang kecil. Semua data dari analisa kebutuhan ini haruslah benar, sesuai apa yang dimaksud oleh klien, bukan benar menurut apa yang difikirkan oleh pihak yang melakukan analisa. Sebuah kutipan anonim yang sering disampaikan mengenai hal ini adalah : “Saya percaya anda sangat mengerti dengan apa yang saya katakan, namun saya tidak yakin bahwa apa yang anda dengar adalah sama dengan apa yang saya maksud”.

2. Teknik komunikasi

Komunikasi adalah proses penyampaian suatu pesan oleh seseorang kepada orang lain untuk memberi tahu atau untuk mengubah sikap, pendapat, atau perilaku, baik langsung secara lisan, maupun tak langsung melalui media.

TEKNIK KOMUNIKASI

• Mengawali Proses

Gause dan Weinberg [GAU89] menyarankan agar analis memulainya dengan mengajukan pertanyaan bebas konteks, dimana pertanyaan tersebut berfokus pada pelanggan, tujuan keseluruhan, dan keuntungan.

Contoh:

• Siapa di balik permintaan untuk pekerjaan ini?
• Apa keuntungan ekonomi dari pemecahan yang berhasil?
• Rangkaian pertanyaan berikutnya memungkinakan analis mendapatkan pemahaman yang lebih baik mengenai masalah dan pelanggan, untuk menyatakan persepsinya terhadap suatu pemecahan.

Contoh:

• Masalah apakah yang akan diselesaikan oleh pemecahan ini?
• Dapatkah anda memperlihatkan kepada saya atau menjelaskan lingkungan dimana pemecahan tersebut akan digunakan?

Rangkaian pertanyaan berikutnya berfokus pada efektifitas pertemuan. [GAU89] memberikan contohnya sebagai berikut:

• Apakah ada orang lain yang dapat memberikan informasi tambahan?
• Apakah ada hal lain yang harus saya tanyakan kepada anda?

Pertanayan-pertanyaan tersebut akan membantu anda mengawali komunikasi yang perlu untuk berhasilnya analisis. Pada dasarnya sesi tanya jawab seharusnya digunakan pada pertemuan pertama dan kemudian diganti dengan format yang mengkombinasikan lemen-elemen pemecahan masalah, negosiasi, dan spesifikasi

• Teknik Spesifikasi Aplikasi yang Terfasilitasi

Adanya teknik pendekatan spesifikasi aplikasi yang teratasi / facilitated aplication spesification techniques (FAST) dapat mendorong munculnya tim gabungan antara pengembang dan pelanggan yang bekerjasama untuk mengidentifikasimasalah, mengusulkan elemen pemecahan, menegosiasi pendekatan yang berbeda, dan mengkhususkan rangkaian pemecahan awal [ZAH90].Banyak pendekatan yang berbeda terhadap FAST telah diusulkan. Masing-masing pendekatan menggunakan skenario yang sangat berbeda, tetapi semuanya menerapkan beberapa variasi tuntutan dasar seperti: Pertemuan dilakukan di sisi netral dan dihadiri baik oleh pengembang maupun pelanggan. Aturan main untuk persiapan dan partisipasi dibuat.

Sebuah mekanisme definisi (dapat merupakan sebuah lembar kerja, diagram flip, stiker dinding, atau papan tembok) digunakan. FAST bukanlah obat bagi masalah yang dihadapi dalam pengumpulan awal berbagai persyaratan, tetapi pendekatan tim memberikan keuntungan dari banyak sudut pandang, diskusi sesaat, dan penyaringan, serta merupakan langkah maju konkrit ke arah pengembangan spesifikasi.

• Penyebaran Fungsi Kualitas

Disebut juga Quality function deployment (QFD) adalah teknik manajemen kualitas yang menerjemahkan kebutuhan pelanggan ke dalam persyaratan teknis bagi perangkat lunak.

QFD mengidentifikasi 3 persyaratan [ZUL92] yaitu:

• Persyaratan normal:
• Sasaran dan
• tujuan dinyatakan bagi sebuah produk atau sistem selama pertemuan dengan pelanggan.

Bila persyaratan ini ada, maka pelanggan akan menjadi puas.

Contoh : tipe tampilan grafis yang diminta, dan tingkat kerja yang didefinisikan. Persyaratan yang diharapkan: Persyaratan ini implisit terhadap produk atau sistem dan sangat fundamental sehingga pelanggan tidak menyatakannya secara eksplisit. Ketidakhadirannya menyebabkan ketidakpuasan.

Contoh: Mudahnya instalasi perangkat lunak.

Exciting requirment: Persyaratan ini sangat diharapkan oleh pelanggan dan terbukti sangat memuaskan bila ada. Misalnya, perangkat lunak pengolah kata diharapkan dengan fitur standar. Produk yang disampaikan berisi sejumlah kemampuan layout halaman yang sangat menyenangkan dan tidak terduga. Dalam kenyataan, QFD mencakup seluruh proses rekayasa [AKA90]. Tetapi banyak konsep QFD dapat diaplikasikan ke dalam masalah komunikasi pelanggan yang dihadapi oleh perekayasa perangkat lunak selama tahap awal analisis

persyaratan.

3. Prinsip Analisis

Masing-masing metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis dihubungkan oleh serangkaian prinsip operasional:

1. Domain informasi dari suatu masalah harus direpresentasikan dan dipahami.
2. Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
3. Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus diwakilkan.
4. Model-model yang menggambarkan informasi, fungsi, dan tingkah laku harus dipecah-pecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan.
5. Proses analisis harus bergerak dari informasi dasar ke detail implementasi.

Dengan mengaplikasikan prinsip-prinsip tersebut, analis mendekati suatu masalah secara sistematis. Domain informasi diuji sehingga fungsi itu dapat dipahami secara lebih lengkap. Model-model digunakan sehingga karakteristik fungsi dan tingkah laku dapat dikomunikasikan dengan cara yang rapi. Pembagian diterapkan untuk mengurangi keruwetan. Pandangan esensial dan implementasi dari perangkat lunak diperlukan untuk mengakomodasi batasan logis yang dibebankan oleh persyaratan pemrosesan dan batasan fisik yang dibebankan oleh elemen sistem yang lain. Perekayasa perangkat lunak yang mempercayai prinsip tersebut akan dapat lebih mengembangkan spesifikasi perangkat lunak yang kemudian akan menjadi dasar yang kuat bagi desain.

Model dalam perangkat lunak harus dapat memodelkan informasi yang ditransformasikan oleh perangkat lunak, fungsi (dan subfungsi) yang memungkinkan transformasi terjadi, dan tingkah laku sistem pada saat transformasi terjadi. Dalam beberapa kasus, model yang kita buat menggunakan notasi grafis yang menggambarkan informasi, pemrosesan, tingkah laku sistem, dan karakteristik lain sebagai simbol yang berbeda dan dapat dikenali. Informasi deskriptif dapat diberikan dengan menggunakan bahasa natural atau bahasa khusus untuk menggambarkan persyaratannya.

Prinsip analisis operasional mengharuskan kita membangun model fungsi dan tingkah laku.

• Model fungsional: Perangkat lunak mentransformasi informasi, dan untuk melakukannya, perangkat lunak harus melakukan paling tidak tiga fungsi genetik: input, pemrosesan, dan output. Pada saat model fungsional dari suatu aplikasi dibuat, perekayasa perangkat lunak memfokuskan diri pada fungsi-fungsi masalah khusus. Model fungsi dimulai dengan sebuah model tingkat konteks tunggal (yakni nama perangkat lunak yang akan dibuat). Dengan serangkaian iterasi, maka lebih banyak lagi detail fungsionaldiberikan, sampai seluruh rancangan dari semua fungsionalitas sistem terwakili.

• Model tingkah laku: Sebagian besar perangkat lunak merespon kejadiankejadian dari dunia luar. Karakteristik stimulus-respon ini membentuk dasar dari model tingkah laku. Model tingkah laku menciptakan representasi pernyataan-pernyataan perangkat lunak dan event-event yang menyebabkan perangkat lunak mengubah pernyataan.

Model yang diciptakan selama analisis persyaratan melayani sejumlah peran penting:

- Model membantu analis dalam memahami informasi, fungsi, dan tingkah laku suatu sistem, sehingga membuat tugas analisis persyaratan menjadi lebih mudah dan lebih sistematis.

- Model menjadi titik fokus bagi kajian sehingga merupakan kunci bagipenentuan kelengkapan, konsistensi, dan akurasi dari spesifikasi.

- Model menjadi dasar bagi pengerjaan desain, memberi perancang suatu representasi esensial dari perangkat lunak yang dapat diterjemahkan ke dalam suatu konteks implementasi.

Meskipun metode pemodelan yang digunakan sering menjadi masalah preferensi personal atau organisasional, aktivitas pemodelan adalah dasar bagi kerja analisis yang baik.

4. Prototyping Perangkat Lunak

Prototyping perangkat lunak adalah salah satu metode siklus hidup sistem yang didasarkan pada konsep working model. Yang bertujuan untuk mengembangkan model menjadi sistem final. Artinya sistem akan dikembangkan lebih cepat daripada metode sebelumnya dan biayanya akan menjadi lebih rendah. Ada banyak cara untuk memprotoyping, begitu pula dengan penggunaannya. Ciri khas dari metodologi ini adalah pengembang sistem (system developer), klien, dan pengguna dapat melihat dan melakukan eksperimen dengan bagian dari sistem komputer dari sejak awal proses pengembangan.

Protoyping juga membantu dalam hal menemukan kebutuhan di tahap awal pengembangan, terutama jika klien tidak yakin dimana masalah berasal. Selain itu protoyping juga berguna sebagai alat untuk mendesain dan memperbaiki user interface – bagaimana sistem akan terlihat oleh orang-orang yang menggunakannya.

5. Spesifikasi dan kajian spesifikasi

Metode spesifikasi sama dengan pemecahan masalah. Pereka PL yang dipaksa bekerja dengan spesifikasiyang tidak lengkap,tidak konsisten,atau salah akan mengalami frustasi atau keraguan.akibatnya, kualitas ,ketepatan waktu dan kelengkapan perangkat lunak menjadi korban.

Prinsip spesifikasi

Spesifikasi, tanpa mempedulikan mode dimana kita melakukannya, dapat dilihat sebagai sebuah proses representasi. Persyaratan diwakilkan dengan suatu cara yg membawa ke arah implementasi yang berhasil. Berikut ini sejumlah prinsip spesifikasi yang diadaptasi dari kerja Blazer dan Goldman[BLA 86].

1. Memisahkan fungsional dari implementasi
2. Mengembangkan suatu model dari system yang diperlukan yg meliputiData dan respon fungsional dari suatu system terhadap berbagai stimulus dari lingkungan.
3. Membangun konteks dimana PL beroperasi dengan menentukan cara dimana komponen system yg lain berinteraksi dengan PL.
4. Menentukan lingkungan dimana system beroperasi dan menunjukan bagaimana “ sekumpulan agen yang sangat terjalin bereaksi terhadap stimulus dalam lingkungan.
5. Menciptakan sebuah model yg kognitif daripada model desain atau implementasi.Model kognitif menggambarkan sebuah system sebagaimana dirasakan oleh komunitas pemakainya.
6. mengenali spesifikasi harus toleran terhadap ketidak lengkapan dan dapat di tambah.
7. Membangun muatan dan struktur spesifikasi dengan suatu cara yang akan memungkinkan spesifikasi dapat ditambah agar dapat berubah.

Representasi

Kita mengetahui bahwa persyaratan PL dapat ditentukan dalam berbagai cara. Akan tetapi, bila persyaratan itu dimasukan pada kertas atau media presentasi electronic, maka diperoleh panduan sederhana:

-Format dan muatan representasi harus relevan dengan masalah.

-Informasi yang di isikan kedalm spesifikasi harus disarangkan.

Spesifikasi persyaratan PL

Spesifikasi persyaratan PL dibuat pada puncak tugas analisis. Fungsi dan kinerja yang dialokasikan pada PL sebagai bagian dari rekayasa system, diperhalus dengan membangun sebuah diskripsi informasi lengkap,diskripsi tingkah laku dan fungsional lengkap,indikasi persyaaratan kinerja dan batasan desain, criteria validasi yang sesuai, dan data lain yang berkenaan dengan persyaratan. The Nation Bureau of Standards, IEE( standard no. 830- 1984) dan Departement Pertahanan AS mengusulkan format calon untuk spesifikasi persyaratan perangkatan perangkat lunak. Berikut merupakan kerangka kerj untuk spesifikasi.

a. Pendahuluan

- Refrensi system

- Deskripsi keseluruhan

- Batasan proyek PL

b.Deskripsi informsi

- Representasi isi informasi

- Representasi aliran informasi

- aliran data

- aliran kontrol

c.Deskripsi fungsional

- Pembagian fungsional

- deskripsi fungsional

- gambaran pemrosesan

- retriksi / keterbatasan

- persyaratan kinerja

- batasan desain

- diagram pendukung

- diskripsi control

- spesifikasi control

- batasan desain

d.Diskripsi prilaku

- peryataan system

- event dan tindakan

e.Validasi dan kreteria

- batas kinerja

- kelas- kelas pengujian

- respon PL

- pertimbangan khusus

f.Bibliografi

g.Lampiran

~ Kajian spesifikasi

Kajian dari suatu spesifikasi persyaratan perangkat lunak dilakukan baik oleh pelanggan atau pengembang PL. Karena spesifikasi membentuk dasar bagi desain dan aktivitas rekayasa selanjutnya, maka kajian harus dilakukan dengan hati- hati. Kajian dilakukan pertama kali pada tingkat makroskopik.pada tingkat ini pengkaji akan memastikan bahwa spesifikasi sudah lengkap, konsisten, dan, akurat

Pertanyaan - pertayan berikut dapat di ajukan contohnya

Apakah tujun dan sasaran yang diyatakan bagi perangkat lunak tetap konsisten dengan tujuan dan sasaran system?

• Apakah interface penting kesemua element system sudah digambarkan?
• Apakah fungsi mayor tetap ada pada ruang lingkup, dan sudah digambarkan dengan lengkap dn tepat?
• Apakah tingkah laku PL konsisten dengan informasi yang harus diproses dan fungsi harus dilakukannya?
• Apakah batasan desain realistis?
• Apakah resiko teknologis pengembang sudah dipertimbangkan?

Pengkaji dapat mengembangkan pertayaan diatas dengan :

Mencari konektor persuasive

• Bila suatu daftar yang diberikan tidak lengkap,pastikan jenisnya sudah dipahami.
• Pastikan jangkauan yg dinyatakan tidak berisi asumsi yg tidak dinyatakan.
• Hati hatilah pada kata kerja yang kabur
• Hati hati terhadap kata ganti yang ambiguitas
• Cari pertanyaan yang mengimplimentasikan kepastian Bila kajian lengkap spesifikasi persyaratan PL diakhiri oleh pelanggan atau pengembang.

Perubahan yang diminta setelah spesifikasi itu di akhiri tidak akan dieleminasi, tetapi pelanggan harus mencatat bahwa masing – masing perubahan setelah pengakhiran spesifikasi merupakan ekstensi dari ruang lingkup PL yang demikian dapat menambah biaya dan atau dapat memperpanjang jadwal proyek.Bahkan dengan prosedur kajian terbaikpun, tetap ada sejumlah masalah spesifikasi. Spesifikasi sulit di uji dalam berbagai cara yang berarti sehingga inkonsistensi dan penghilangan dapat berlangsung tanpa terlihat. Selama kajian , perubahan terhadap terhadap spesifikasi dapat disetujui.Sangat sulit untuk menili pengaruh global dari suatu perubahan ; yaitu bagaimana suatu perubahan dalam suatu fungsi mempengaruhi persyaratan bagi fungsi- fungsi yang lain.

referensi :

http://tekomunikasi.blogspot.com/

http://id.wikipedia.org/wiki/Protoyping_perangkat_lunak

http://suryainformation.wordpress.com/2010/05/23/analisis-kebutuhan-dalam-rekayasa-perangkat-lunak/

http://lokomediasi.blogspot.com/2009/08/prinsip-konsep-analisa-kebutuhan.html

http://iiaahhdudul.blogspot.com/2011/10/konsep-dan-prinsip-analisis.html

Baca Selengkapnya →Konsep dan Prinsip Analisis

Use Diagram

A. Konsep Use Case Diagram

Diagram Use Case adalah diagram yang menunjukkan fungsionalitas suatu sistem atau kelas dan bagaimana sistem tersebut berinteraksi dengan dunia luar dan menjelaskan sistem secara fungsional yang terlihat user. Biasanya dibuat pada awal pengembangan. Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya. Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan system untuk melakukan pekerjaan-pekerjaan tertentu.

Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem. Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use case yang meng-include dieksekusi secara normal. Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common. Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain.

Use case diagram adalah gambaran graphical dari beberapa atau semua actor, use case, dan interaksi diantara komponen-komponen tersebut yang memperkenalkan suatu sistem yang akan dibangun. Use case diagram menjelaskan manfaat suatu sistem jika dilihat menurut pandangan orang yang berada di luar sistem. Diagram ini menunjukkan fungsionalitas suatu sistem atau kelas dan bagaimana sistem tersebut berinteraksi dengan dunia luar.

Use case diagram dapat digunakan selama proses analisis untuk menangkap requirements sistem dan untuk memahami bagaimana sistem seharusnya bekerja. Selama tahap desain, use case diagram berperan untuk menetapkan perilaku (behavior) sistem saat diimplementasikan. Dalam sebuah model mungkin terdapat satu atau beberapa use case diagram. Kebutuhan atau requirements sistem adalah fungsionalitas apa yang harus disediakan oleh sistem kemudian didokumentasikan pada model use case yang menggambarkan fungsi sistem yang diharapkan (use case), dan yang mengelilinginya (actor), serta hubungan antara actor dengan use case (use case diagram) itu sendiri.

B. Lambang dalam Use Case Diagram

1. Actor , ketentuan:

• Actor menggambarkan orang, system atau external entitas / stakeholder yang menyediakan atau menerima informasi dari system
• Actor memberi input atau menerima informasi dari system
• Actor biasanya menggunakan Noun
• Actor digambarkan dengan gambar stick figure atau dengan gambar visual
• Tidak boleh ada komunikasi langsung antar actor (Actors don’t interact with one another )
• Indikasi <> untuk sebuah actor yang merupakan sebuah system
• Adanya actor bernama “Time” yang mengindikasikan scheduled events (suatu kejadian yang terjadi secara periodik/bulanan)
• Letakkan actor utama anda pada pojok kiri atas dari diagram (in western culture people read from left to right, top to bottom)
• Actor jangan digambarkan ditengah-tengah use cases (actors are placed to the outside of the diagram, and not the middle of it)

2. Use Case , ketentuan:

• Use case dibuat berdasar keperluan actor, merupakan “apa” yang dikerjakan system, bukan “bagaimana” system mengerjakannya
• Use case diberi nama yang menyatakan apa hal yang dicapai dari hasil interaksinya dengan actor.
• Use case dinotasikan dengan gambar (horizontal ellipse)
• Ø Use case biasanya menggunakan kata kerja
• Ø Nama use case boleh terdiri dari beberapa kata dan tidak boleh ada 2 use case yang memiliki nama yang sama

3. Relasi

Ada 4 jenis relasi yang bisa timbul pada use case diagram:

Association antara actor dan use case

• Ujung panah pada association antara actor dan use case mengindikasikan siapa/apa yang meminta interaksi dan bukannya mengindikasikan aliran data
• Sebaiknya gunakan Garis tanpa panah untuk association antara actor dan use case
• Ø association antara actor dan use case yang menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan system anda

v Association antara use case

Ø <> termasuk didalam use case lain (required) / (diharuskan)

ü Pemanggilan use case oleh use case lain, contohnya adalah pemanggilan sebuah fungsi program

ü Tanda panah terbuka harus terarah ke sub use case

ü Gambarkan association include secara horizontal

Ø <> perluasan dari use case lain jika kondisi atau syarat terpenuhi

ü Kurangi penggunaan association Extend ini, terlalu banyak pemakaian association ini membuat diagram sulit dipahami.

ü Tanda panah terbuka harus terarah ke parent/base use case

ü Gambarkan association extend secara vertical

v Generalization/Inheritance antara use case

• Ø Gambarkan generalization/inheritance antara use case secara vertical dengan inheriting use case dibawah base/parent use case
• Ø Generalization/inheritance dipakai ketika ada sebuah keadaan yang lain sendiri/perlakuan khusus (single condition)

v Generalization/Inheritance antara actors

• Gambarkan generalization/inheritance antara actors secara vertical dengan inheriting actor dibawah base/parent use case

Baca Selengkapnya →Use Diagram

Membuat Background Keren Power Point 2007

Mau bikin presentasi sekarang nggak susah lagi. Microsoft udah baik banget ciptakan power point khusus buat bantu kamu yang doyan ngomong di depan publik. Tapi apa bagusnya? Biasa aja tuh? Ya memang, tapi apa nggak bosan dengan tampilan power point yang biasa-biasa aja? Apalagi liat templatenya, idih jadul banget. Untuk kamu tahu, sebenarnya banyak rahasia yang tersimpan dalam aplikasi power point. Ya sayangnya kita lebih suka gunakan template jadul original buatan power point itu sendiri. Hasilnya presentasi kita ya gitu gitu aja. Bikin bosan. Padahal hanya dengan sedikit mengotak atik lembar kerja power point, kamu bisa bikin template buatan sendiri yang dijamin nggak bakal ada yang niru, karena hasilnya bisa beragam tergantung kreativitas kamu sendiri.

Btw, template itu apa sih? Template itu sama aja kayak background yang ada di belakang teks presentasi kamu. Nah sekarang aku bakal ngasih tahu kamu cara bikin template power point asli cuma milik kamu. Caranya gampang, jadi ikutin aja ya??

1. Buka aplikasi power point kamu. Di dalamnya sediakan sebuah slide kosong. Pasti tahu kan cara ngambilnya?

2. Klik kanan slide kosong dan pilih Format Background. Nah, muncul deh window pilhannya. Yuuk kita mulai beraksi!

,

3. Disana, kamu bisa klik link Fill yang ada di ruas kanan window. klik option Picture or Texture Fill. Tugas kamu, pilih File yang linknya ada dibawah Insert from.

4. Pilih gambar apa aja yang kamu mau dari library picture kamu, atau dari mana aja boleh lah, yang penting oke. Aku sih pilih gambar yang imut, biar lebih menarik dan cocok kayak aku. ^_^. Otomatis gambar yang kamu pilih bakal menjelma jadi background slide.

5. Sekarang kamu harus berpaling pada link Picture, masih di jendela format background. Klik panah mungil yang ada disamping option Recolor. Muncul deh banyak pilihan yang bakal merubah warna background kamu. Untuk contoh kita ambil Dark Variations (Teks Color 2 Dark). sekarang lihat apa yang terjadi pada background kamu.

6. Berikutnya pilih menu Insert yang ada di Toolbar. Klik Picture dan pilih lagi gambar yang sama dengan gambar yang kamu pilih untuk background sebelumnya. Akibatnya, background kamu bakal berubah ke bentuk awal lagi. Tapi jangan khawatir, sebenarnya background kamu nggak berubah, Cuma gambarnya aja yang ditambah.

7. Pilih Picture Tool pada toolbar. Klik panah kecil di sudut kanan grup Size untuk memperkecil ukuran gambar. Ganti ukuran Left buat croping jadi 15 cm. Background kamu bakal jadi separo jelas separonya lagi memudar atau istilahnya Faded picture background with full-color overlay. Biar garis pinggirnya musnah, klik Picture Effects > Soft Edges> 25 Point.

Selamat deh, karena sekarang kamu udah berhasil bikin template sendiri yang nggak kalah ama bikinan mereka-mereka tuh hehe. Tapi biar presentasinya lebih menarik, kamu bisa tambahkan shape sebagai wadah menulis teks. Ganti warna dan tambahkan animasi shadow pada Shape Fill.

Bingung ya? Ingat teknik ini nggak bakal bisa kamu kuasai tanpa mencobanya di rumah. Sekarang memang sudah banyak media presentasi modern yang berkembang untuk menyajikan presentasi menarik. Sayangnya kamu harus instal software aplikasinya dulu sebelum beraksi. Tapi hanya dengan sedikit kreativitas saja kamu bisa membuat poresentasi cantik hanya dengan aplikasi power point. Semakin tinggi kreativitas kamu, dijamin hasilnya akan lebih bagus dari yang kamu bayangkan. Jadi jangan berhenti mencoba sampai kamu bisa bikin presentasi yang super menarik. Biar lebih jelas coba aja klik link download dibawah ini.

Download Filetype pptx

Download Filetype pdf

Sumber: www.microsoft.com

Baca Selengkapnya →Membuat Background Keren Power Point 2007

Membuat File PDF menggunakan MS Office Word 2007

Dear pembaca.. Kali ini aku mau bagi tips kecil-kecilan yang moga-moga bermanfaat buat kamu..nyimpan file dengan tipe PDF. Jujur aku sendiri lebih tertarik dengan file PDF dari pada filetype lainnya, udah bentuknya simpel, jelas dibaca n gak ribet downloadnya.. ya udah lanjut aja ke langkah-langkahnya yuk..

1. kamu harus pastikan dulu bahwa kamu udah install SaveAsPDFandXPS. Kalau belum klik aja link berikut buat ambil sofwarenya. Download Disini

2. Buka MS Office Word 2007 di komputer kamu. Ketikan data yang mau kamu jadikan filetype pdf

3. Klik Office Button ---> Save as ---> PDF or XPS (bakal muncul kalau sofwarenya udah diinstal)

4. Pilih lokasi penyimpanan File pdf kamu dan Klik Publish. Sekarang liat hasilnya.

Baca Selengkapnya →Membuat File PDF menggunakan MS Office Word 2007