DIODA
Dioda adalah merupakan jenis komponen pasif. Dioda memiliki dua kaki/kutub yaitu kaki anoda dan kaki katoda . Dioda terbuat dari bahan semi konduktor tipe P dan semi konduktor tipe N yang di sambungkan.
Semi konduktor tipe P berfungsi sebagai Anoda dan semi konduktor tipe N berfungsi sebagai katoda. Pada daerah sambungan 2 jenis semi konduktor yang berlawanan ini akan muncul daerah deplesi yang akan membentuk gaya barier.Gaya barier ini dapat ditembus dengan tegangan + sebesar 0.7 volt yang dinamakan sebagai break down voltage, yaitu tegangan minimum dimana dioda akan bersifat sebagai konduktor/penghantar arus listrik.
Dioda bersifat menghantarkan arus listrik hanya pada satu arah saja, yaitu jika kutub anoda kita hubungkan pada tegangan + dan kutub katoda kita hubungkan dengan tegangan - (kita beri bias maju dengan tegangan yang lebih besar dari 0.7 volt) maka akan mengalir arus listrik dari anoda ke katoda (bersifat konduktor). Jika polaritasnya kita balik (kita beri bias mundur) maka arus yang mengalir hampir nol atau dioda akan bersifat sebagai isulator.
Karena sifat dioda yang bekerja sebagai konduktor jika kita beri bias maju dan bekerja sebagai isulator pada bias mundur, maka dioda sering digunakan sebagai penyearah (rectifier) arus bolak-balik. Contoh penggunaannya adalah pada rangkaian adaptor, DC power supply (Catu Daya DC) dsb.
Simbol Dioda
Secara grafis, kondisi dioda dalam keadaan tidak diberi bias tegangan adalah seperti terlihat pada gambar berikut
Dioda dalam keadaan tanpa bias tegangan
Dalam gambar di atas dapat dilihat bahwa di daerah pengosongan terbentuk pasangan elektron dan hole, karena elektron bebas dari Tipe N tertarik ke daerah Tipe P. Elektron yang pindah ini, meninggalkan hole pada tipe N. Pasangan elektron-hole inilah yang kemudian akan menghalangi perpindahan elektron lebih lanjut dan dikenal sebagai potensial Barrier.
Karena terbentuk oleh dua jenis semikonduktor (N dan P), maka dioda hanya dapat melewatkan arus listrik dalam satu arah saja (ketika bias maju).
Menurut bahan semi konduktor yang digunakan dalam pembuatannya, dioda ada 2 jenis yaitu :
1. Dioda silikon: Dibuat dari bahan silikon (si)
2. Dioda germanium: Dibuat dari bahan germanium (ge)
Jenis-jenis dioda dan penggunaannya :
- Dioda silikon: Banyak digunakan pada peralatan catu daya sebagai penyearah arus, pengaman tegangan kejut dsb. Contoh : 1N4001, 1N4007, 1N5404 dsb.
- Dioda zener: Digunakan untuk membatasi/mengatur tegangan. Contoh : zener 6.2 volt, zener 3.2 volt dsb.
- Dioda Bridge: 4 buah dioda yang dirangkai menjadi rangkaian jembatan/bridge. Banyak digunakan pada rangkaian catu daya sebagai penyearah gelombang penuh (full wave rectifier). Contoh : B40C800, kiprox pada kendaraan bermotor dsb.
Forward Bias
Ketika kaki katoda disambungkan dengan kutub negatif batere dan anoda disambungkan dengan kutub positif, maka dikatakan bahwa dioda sedang dibias dengan tegangan maju. Bias maju ini diperlihatkan pada gambar berikut.
Dioda dengan bias tegangan maju
Dalam bias maju, kutub negatif batere akan menolak elekton-elektron bebas yang ada dalam semikonduktor tipe N, jika energi listrik yang digunakan adalah melebihi tegangan barir, maka elektron yang tertolak tersebut akan melintasi daerah deplesi dan bergabung dengan hole yang ada pada tipe P, hal ini terjadi terus menerus selama rangkaian di gambar tersebut adalah tertutup. Kondisi inilah yang menyebabkan adanya arus listrik yang mengalir dalam rangkaian.
Reverse Bias
Sebaliknya jika kaki katoda disambungkan dengan kutub positif batere dan anoda disambungkan dengan kutub negatif batere, maka kondisi ini disebut sebagai bias tegangan balik, seperti terlihat dalam gambar berikut.
Dioda dengan bias tegangan mundur
Ketika dioda dibias mundur, maka tidak ada aliran arus listrik yang melewati dioda. Hal ini dikarenakan elekton bebas yang ada pada tipe N tertarik oleh kutub positif batere dan demikian juga hole pada tipe P berekombinasi dengan elektron dari batere, sehingga lapisan pengosongan menjadi semakin lebar. Dengan semakin lebarnya lapisan pengosongan ini, maka dioda tidak akan mengalirkan arus listrik. Ketika tegangan bias mundur terus diperbesar, maka pada suatu harga tegangan tertentu dioda akan rusak, karena adanya proses avalan yang menyebabkan dioda rusak secara fisik.
A. Garis Beban dan Titik Operasi Dioda
Jika suatu rangkaian dioda yang seri dengan suatu hambatan pembatas (R) dan sumber tegangan (VDD), dianalisa, maka akan didapat persamaan sebagai berikut:
Jika tegangan input dan hambatan pembatas diketahui, maka hanya tegangan dan arus dioda yang tidak diketahui. Persamaan ini menyatakan hubungan yang linear antara tegangan dan arus.
Pada saat Vd sama dengan nol, maka
Titik ini disebut dengan titik jenuh (saturation point) yang terletak pada sumbu tegak arus. Sementara itu, jika Vd sama dengan Vin, maka
ID = 0
Titik ini disebut dengan titik putus (cut off point) yang terletak pada sumbu mendatar. Jika kedua titik ini dihubungkan, atau dengan mengukur titik-titik lain, akan didapatkan sebuah garis yang khas, disebut garis beban (load line).
Apabila grafik garis beban dioda digambarkan pada grafik dioda, maka akan didapatkan grafik seperti pada Gambar 1. Kedua grafik itu memiliki sebuah titik potong, yang disebut dengan titik operasi (operating point), yang menyatakan arus dan tegangan dioda sesuai dengan tegangan input dan tahanannya.
Gambar 1. Load Line dan Operating Point
B. Model Dioda
Dioda dalam prakteknya, seringkali didekati dengan menggunakan pendekatan atau model. Sudah barang tentu, model ini tetap berdasarkan kepada representasi matematika dan grafik dari karakteristik V-I dari dioda itu sendiri. Penyederhanaan model ini, hanya ingin memberikan gambaran global dari cara kerja dioda, namun belum merepresentasikan detil-detil penting dari dioda itu sendiri. Terdapat beberapa model pendekatan dioda, yaitu: Model Dioda Ideal, Model Dioda Offset dan Model Dioda Real. Model Dioda Ideal memiliki karakteristik V-I seperti pada Gambar 2 (a). Pada model ini, suatu dioda berlaku sebagai konduktor yang sempurna (bertegangan nol) bila diberi forward biased dan berlaku sebagai isolatif yang sempurna (berarus nol) bila diberi reverse biased. Dalam istilah rangkaian, dioda berlaku seperti saklar (swithc), bila diberi forward biased ia bertindak sebagai saklar tertutup (ON), dan bertindak seperti saklar terbuka (OFF) bila diberi reverse biased. Model ini sangat ekstrim, sehingga untuk kondisi-kondisi tertentu, diperlukan model yang lebih baik lagi.
Sesungguhnya, diperlukan tegangan offset sekitar 0,7 volt sebelum dioda Silikion menjadi konduktor dengan baik. Gambar 2(b). memperlihatkan karakteristik V-I dioda, dimana tidak ada arus mengalir sampat tegangan dioda mencapai 0,7 volt. Pada titik ini dioda mulai konduksi. Jadi, dioda dianggap seperti sebuah switch yang disarikan dengan sebuah baterai 0.7 volt. Jika tegangan sumber lebih besar dari 0.7 volt, switch menutup dan tegangan dioda adalah 0.7 volt. Namun, jika tegangan sumber kurang dari 0.7 volt maka switch membuka.
Pada model ketiga ini, tahanan dalam dioda, Rf, diperhitungkan. Gambar 2(c)., menunjukkan model dioda real ini. Sehingga, pada saat konduksi, arus menghasilkan tegangan pada Rf, dimana semakin besar arus, semakin besar pula tegangan tersebut. Rangkain ekivalen pada model real dioda ini, adalah seperti sebuah saklar yang diseri dengan baterai 0.7 volt dan tahanan Rf.
Gambar 2. Model Dioda
Selasa, 29 September 2009
Resiko pada proyek teknologi informasi
MANAJEMEN RESIKO
Menurur Robert Charette dalam bukunya Software Engineering Risk Analysis and Management, resiko adalah : Pertama, resiko berhubungan dengan kejadian masa yang akan datang. Sekarang dan kemarin tidak mendapat perhatian aktif, karena kita telah mendapatkan apa yang telah kita tabur lewat sepak terjang di masa lalu. Kedua, bahwa resiko melibatkan perubahan, seperti dalam perubahan pikiran, pendapat, aksi atau tempat. Dan yang ketiga, resiko melibatkan pilihan dan ketidakpastian bahwa pilihan itu akan dilakukan.
Bila resiko dipertimbangkan dalam konteks rekayasa perangkat lunak, maka masa yang akan datang adalah perhatian kita mengenai :
1. Resiko apa yang menyebabkan proyek perangkat lunak menjadi serba salah ?
2. Bagaimana perubahan pada persyaratan pelanggan, teknologi pengembangan, komputer target, dan semua entitas lain yang berhubungan dengan proyek, mempengaruhi ketepatan waktu dan keberhasilan keseluruhan ?
3. Bagaimana banyak orang harus dilibatkan, berapa banyak penekanan pada kualitas yang dianggap memadai ?
Peter Drucker mengatakan “Meskipun tidak ada gunanya mencoba mengeliminasi resiko, dan sangat mungkin dipertanyakan bila kita mencoba meminimalkannya, sangat penting bahwa resiko yang diambil merupakan resiko yang tepat.” Sebelum kita mengidentifikasian “resiko yang benar” yang akan diambil selama menjalankan suatu proyek perangkat lunak, penting untuk mengidentifikasi semua resiko secara jelas.
STRATEGI RESIKO REAKTIF VS. PROAKTIF
RESIKO PERANGKAT LUNAK
Resiko selalu melibatkan dua karakteristik yaitu :
1. Ketidakpastian
Kejadian yang menandai resiko mungkin atau tidak mungkin terjadi, yaitu ada 100% resiko yang mungkin.
2. Rugi
Bila resiko menjadi realitas, akibat yang tidak diinginkan atau kerugian akan dialami.
Ada beberapa Kategori resiko yaitu :
1. Resiko Proyek
Resiko proyek mengancam rencana proyek. Yaitu bila resiko proyek menjadi nyata, ada kemungkinan jadwal proyek akan mengalami slip dan bahwa biaya menjadi bertambah. Resiko proyek mengidentifikasi hal potensial yang berhubungan dengan pembiayaan, jadwal, personil, sumber-sumber daya, pelanggan dan masalah persyaratan serta pengaruhnya terhadap proyek perangkat lunak.
2. Resiko Teknis
Resiko teknis mengancam kualitas dan ketepatan waktu perangkat lunak yang akan dihasilkan. Bila resiko teknis menjadi kenyataan, implementasinya menjadi sangat sulit atau tidak mungkin. Resiko teknis mengidentifikasi desain potensial, implementasi, interfecing, verifikasi dan masalah pemeliharaan.
3. Resiko Bisnis
Resiko bisnis mengancam viabilitas perangkat lunak yang akan dibangun. Resiko bisnis membahayakan proyek atau produk. Adapun lima resiko bisnis utama yaitu :
* Pembangunan produk atau system yang baik sekali yang sebenarnya tidak pernah diinginkan oleh setiap orang (resiko pasar).
* Pembangunan sebuah produk yang tidak lagi sesuai dengan keseluruhan strategi bisnis bagi perusahaan (resiko strategi)
* Pembangunan sebuah produk di mana bagian pemasaran tidak tahu bagaimana harus menjualnya
* Kehilangan dukungan manajemen senior sehubungan dengan perubahan pada focus atau perubahan pada manusia (resiko manajemen)
* Kehilangan hal-hal yang berhubungan dengan biaya atau komitment personal (resiko manajemen)
Sedangkan resiko yang diusulkan oleh Charette adalah :
1. Resiko yang sudah diketahui adalah resiko yang dapat diungkap setelah dilakukan evaluasi secara hati-hati terhadap rencana proyek, bisnis, dan lingkungan teknik dimana proyek sedang dikembangkan dan sumber informasi reliable lainnya.
2. Resiko yang dapat diramalkan diekstrapolasi dari pengalaman proyek sebelumnya.
3. Resiko yang tidak diharapkan dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya.
IDENTIFIKASI RESIKO
Identifikasi resiko adalah usaha sistematis untuk menentukan ancaman terhadap rencana proyek. Dengan mengidentifikasian resiko yang sudah diketahui dan dapat diprediksi, manajer proyek mengambil langkah pertama ke depan untuk menghindari resiko bilamana mungkin, serta menghindarinya setiap saat diperlukan.
Metode untuk mengidentifikasi resiko adalah menciptakan checklist item resiko. Checklist dapat digunakan pada identifikasi resiko dan berfokus pada beberapa himpunan bagian resiko yang sudah diketahui dan diprediksi dalam sub kategori berikut ini :
1. Ukuran produk
Resiko sehubungan dengan keseluruhan ukuran perangkat lunak yang akan dibangun atau dimodifikasi. Check list item resiko yang berhubungan dengan ukuran produk adalah :
* Ukuran produk diperkirakan dalam LOC atau FP ?
* Tingkat kepercayaan dalam estimasi ukuran yang diperkirakan ?
* Ukuran produk yang diestimasi dalam jumlah program, file dan transaksi ?
* Presentase deviasi dalam ukuran produk dari rata-rata produk terakhir ?
* Ukuran database yang dibuat atau digunakan oleh produk ?
* Jumlah pemakai produk ?
* Jumlah perubahan yang diproyeksikan ke persyaratan produk ? sebelum penyampaian ? setelah penyampaian ?
* Jumlah perangkat lunak yang digunakan kembali ?
2. Pengaruh bisnis
Resiko sehubungan dengan batasan yang dibebankan oleh manajemen atau pasar. Check list item resiko yang berhubungan dengan pengaruh bisnis adalah
* Pengaruh produk terhadap hasil perusahaan ?
* Visibilitas produk terhadap manajemen senior ?
* Kelayakan deadline penyampaian ?
* Jumlah pelanggan yang akan menggunakan produk dan konsistensi kebutuhan relative mereka dengan produk tersebut ?
* Jumlah produk/system lain dengan apa produk ini harus dapat saling dioperasikan ?
* Kepintaran pemakai akhir ?
* Jumlah dan kualitas dokumentasi produk yang harus diproduksi dan disampaikan kepada pelanggan ?
* Batasan pemerintahan pada konstruksi produk ?
* Biaya yang berhubungan dengan penyampaian yang terlambat ?
* Biaya yang berhubungan dengan produk detektif ?
3. Karakteristik pelanggan
Resiko sehubungan dengan kepintaran pelanggan dan kemampuan pengembang untuk berkomunikasi dengan pelanggan dengan cara yang tepat. Semua pelanggan tidak diciptakan sama. Pressman dan Herron menyatakan bahwa :
* Pelanggan mempunyai keinginan yang berbeda. Beberapa tahu apa yang mereka inginkan; yang lainnya tahu apa yang tidak mereka inginkan. Banyak pelanggan mau merinci detailnya, sementara yang lain dapat dipuaskan dengan janji-janji kosong.
* Pelanggan memiliki kepribadian yang berbeda. Beberapa menikmatinya sebagai pelanggan - tekanan, negosiasi, penghargaan psikologis dari suatu produk yang baik. Sementara lainnya tidak ingin menjadi pelanggan sama sekali.
* Pelanggan juga memiliki hubungan yang bervariasi dengan pemasok mereka. Beberapa mengenali produk dan produser secara baik; yang lainnya mungkin tidak, hanya berkomunikasi dengan produser melalui surat atau korespondensi serta beberapa melalui telepon.
* Pelanggan juga kadang-kadang bertentangan. Mereka menginginkan semua yang sudah ada kemarin secara gratis. Sering para pelanggan terperangkap di antara kontradisksi di dalam diri mereka sendiri.
Checklist item resiko yang mengidentifikasi resiko-resiko yang berhubungan dengan para pelanggan yang berbeda adalah :
* Pernahkan anda sebelumnya bekerja dengan pelanggan ?
* Apakah pelanggan memiliki gagasan yang solid mengenai apa yang diperlukannya ? sudahkah pelanggan menggunakan waktunya untuk menuliskannya ?
* Apakah pelanggan akan setuju dengan penggunaan waktu di dalam pertemuan pengumpulan persyaratan formal untuk mengidentifikasi ruang lingkup proyek?
* Apakah pelanggan bersedia membangun sambungan komunikasi cepat dengan pengembang ?
* Apakah pelanggan bersedia berpartisipasi dalam kajian ?
* Apakah pelanggan secara teknis pandai dalam area produk tersebut ?
* Apakah pelanggan bersedia membiarkan orang-orang melakukan pekerjaan mereka?
* Apakah pelanggan memahami proses perangkat lunak tersebut ?
4. Definisi proses
Resiko sehubungan dengan tingkat di mana proses perangkat lunak telah didefinisikan dan diikuti oleh organisasi pengembangan. Adapun masalah-masalah dalam proses :
* Apakah manajemen senior anda mendukung suatu pernyataan kebijaksanaan yang menekankan pentingnya suatu proses standar untuk pengembangan proses ?
* Sudahkah organisasi anda mengembangkan suatu deskripsi tertulis mengenai proses perangkat lunak yang akan digunakan pada proyek ini ?
* Apakah anggota-anggota staf ditugasi ke proses perangkat lunak pada saat perangkat lunak didokumentasi dan bersedia menggunakannya ?
* Apakah proses perangkat lunak digunakan untuk proyek lain ?
* Sudahkah organisasi anda mengembangkan atau mendapatkan serangkaian kursus pelatihan rekayasa perangkat lunak bagi para manajer dan staf teknik ?
* Apakah standar rekayasa perangkat lunak yang diterbitkan disediakan untuk setiap pengembangan perangkat lunak dan manajer perangkat lunak ?
* Sudahkah dokumen outline dan contoh-contoh dikembangkan untuk semua yang ditentukan sebagai bagian yang dapat disampaikan sebagai bagian dari proses perangkat lunak ?
* Apakah kajian teknis formal terhadap spesifikasi persyaratan, desain dan kode dilakukan secara regular ?
* Apakah kajian teknis formal terhadap prosedur pengujian dan test case dilakukan secara reguler ?
* Apakah hasil dari masing-masing kajian teknis formal didokumentasikan, termaksud kesalahan yang ditemukan dan sumber daya yang digunakan ?
* Apakah mekanisme untuk memastikan bahwa kerja yang dilakukan pada suatu proyek sesuai dengan standar rekayasa perangkat lunak ?
* Apakah manajemen konfigurasi digunakan untuk memelihara konsistensi diantara system/persyaratan perangkat lunak, desain, kode dan test case ?
* Apakah digunakan suatu mekanisme untuk mengontrol perubahan ke persyaratan pelanggan yang memperngaruhi perangkat lunak ?
* Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan dan rencana pengembangan perangkat lunak yang didokumentasikan untuk masing-masing subkontrak ?
* Apakah ada prosedur untuk menelusuri dan mengkaji kinerja subkontrak ?
Masalah-masalah teknis
* Apakah digunakan teknik spesifikasi aplikasi untuk membantu komunikasi di antara pelanggan dan pengembang ?
* Apakah metode spesifik digunakan untuk analisis perangkat lunak ?
* Apakah anda melihat suatu metode spesifik untuk data dan desain arsitektur?
* Apakah lebih dari 90 persen dari kode anda ditulis dengan bahasa orde yang lebih tinggi ?
* Apakah konvensi spesifik untuk dokumentasi kode didefiniskan dan digunakan ?
* Apakah anda menggunakan metode spesifik untuk desain test case ?
* Apakah digunakan peranti lunak untuk mendukung perencanaan dan aktivitas penelusuran ?
* Apakah digunakan peranti perangkat lunak manajemen konfigurasi untuk mengontrol dan menelusuri aktivitas perubahan di seluruh proses perangkat lunak ?
* Apakah digunakan peranti perangkat lunak untuk mendukung analisis perangkat lunak dan desain proses ?
* Apakah digunakan peranti untuk menciptakan prototipe perangkat lunak ?
* Apakah digunakan peranti perangkat lunak untuk mendukung proses pengujian ?
* Apakah peranti perangkat lunak digunakan untuk mendukung produksi dan manajemen dokumentasi ?
* Apakah metrik kualitas dikumpulkan bagi semua proyek perangkat lunak ?
* Apakah metrik produktivitas dikumpulkan bagi semua proyek perangkat lunak ?
Bila mayoritas jawaban terhadap pertanyaan tersebut adalah tidak, maka proses perangkat lunak lemah dan berisiko tinggi.
5. Lingkungan pengembangan
Resiko sehubungan dengan keberadaan dan kualitas peranti yang akan digunakan untuk membangun produk. Lingkungan proses perangkat lunak mendukung tim proyek, proses dan produk. Lingkungan yang salah dapat menjadi sumber resiko yang penting. Adapun checklist item yang berhubungan dengan lingkungan pengembangan :
* Apakah peranti manajemen proyek dapat diperoleh ?
* Apakah peranti manajemen proses dapat diperoleh ?
* Apakah peranti untuk analisis dan desain dapat diperoleh ?
* Apakah peranti analisis dan desain penyampaian metode sesuai bagi produk yang akan dibangun ?
* Apakah kompiler atau generasi kode dapat diperoleh sesuai untuk produk yang akan dibangun ?
* Apakah peranti pengujian dapat diperoleh dan sesuai dengan produk yang akan dibangun ?
* Apakah peranti manajemen konfigurasi perangkat lunak dapat diperoleh ?
* Apakah lingkungan menggunakan suatu database atau tempat penyimpanan ?
* Apakah semua peranti perangkat lunak diintegrasikan satu dengan lainnya ?
* Sudahkah anggota tim proyek menerima pelatihan dengan masing-masing peranti ?
* Apakah ada pakar lokal untuk menjawab pertanyaan-pertanyaan mengenai peranti tersebut ?
* Apakah bantuan dan dokumentasi on line bagi peranti memadai ?
Bila mayoritas jawaban terhadap pertanyaan tersebut adalah tidak, berarti lingkungan pengembangan perangkat lunak lemah dan beresiko tinggi.
6. Teknologi yang akan dibangun
Resiko sehubungan dengan komplesitas system yang akan dibangun dan kebaruan teknologi yang dikemas oleh system. Checklist item resiko yang berhubungan dengan teknologi yang akan dibangun adalah :
* Apakah teknologi yang akan dibangun adalah hal yang baru untuk organisasi anda ?
* Apakah persyaratan pelanggan memerlukan kreasi algoritma baru atau teknologi input atau output ?
* Apakah perangkat lunak berinterface dengan perangkat keras baru atau belum terbukti ?
* Apakah perangkat lunak yang akan dibangun berinterface dengan produk perangkat lunak yang dipasok oleh vendor yang belum terbukti ?
* Apakah perangkat lunak yang akan dibangun berinterface dengan suatu sistem database yang fungsi dan kinerjanya belum dibuktikan di dalam area aplikasi ini ?
* Apakah diperlukan interface pemakai khusus oleh persyaratan produk ?
* Apakah persyaratan untuk produk memerlukan kreasi komponen program yang tidak sama dengan yang dikembangkan terakhir oleh organisasi anda ?
* Apakah persyaratan memerlukan pemakaian analisis, desain, atau metode pengujian baru ?
* Apakah persyaratan memerlukan metode pengembangan perangkat lunak tidak konvensional, seperti metode formal, pendekatan AI based, dan jaringan saraf buatan.
* Apakah persyaratan meletakan batasan kinerja yang efektif pada produk tersebut?
* Apakah pelanggan tidak yakin bahwa fungsionalitas yang diminta dapat dilakukan?
Bila jawaban dari pertanyaan-pertanyaan di atas adalah ya, penyelidikan lebih lanjut harus dilakukan untuk memperkirakan resiko potensial.
7. Ukuran dan pengalaman staf - resiko sehubungan dengan keseluruhan teknik dan pengalaman proyek dari perekayasa perangkat lunak yang akan melakukan tugas tersebut. Checklist item resiko yang berhubungan dengan ukuran staf dan pengalaman adalah :
* Apakah orang-orang terbaik dapat didapatkan ?
* Apakah orang-orang tersebut memiliki gabungan keterampilan yang benar ?
* Apakah orang-orang yang ada mencukupi ?
* Apakah staf dimasukkan ke dalam seluruh durasi proyek ?
* Akankah banyak staf proyek bekerja hanya dalam paruh waktu pada proyek ini ?
* Apakah staf memiliki pengharapan yang tepat mengenai pekerjaan yang ada sekarang ?
* Sudahkah staf menerima pelatihan yang memadai ?
* Apakah pergantian di antara staf akan cukup rendah untuk memungkinkan kontinuitas ?
Bila jawaban terhadap pertanyaan-pertanyaan tersebut adalah tidak, maka penyelidikan lebih lanjut harus dilakukan untuk memperkirakan resiko potensial.
KOMPONEN RESIKO DAN DRIVER
Manajer proyek mengidentifikasi resiko driver yang mempengaruhi komponen resiko perangkat lunak. Adapun komponen resiko didefinisikan dengan cara :
1. Resiko kinerja - tingkat ketidakpastian di mana produk akan memenuhi persyaratannya dan cocok dengan penggunaannya.
2. Resiko biaya - tingkat ketidakpastian di mana biaya produk akan dijaga
3. Resiko dukungan - tingkat ketidakpastian di mana perangkat lunak akan mudah dikoreksi, disesuaikan dan ditingkatkan
4. Resiko jadwal - tingkat ketidakpastian di mana jadwal proyek akan dijaga dan produk akan disampaikan tepat waktu.
PROYEKSI RESIKO
Proyeksi resiko disebut juga perkiraan resiko, berusaha menjangkau setiap resiko dalam dua cara - kemungkinan atau probablititas di mana resiko adalah nyata dan konseskuensi masalah yang berhubungan dengan resiko yang harus terjadi. Ada empat aktivitas proyeksi resiko yaitu :
1. Membangun suatu skala yang merefleksikan kemungkinan resiko yang dirasakan
2. Menggambarkan konsekuensi resiko
3. Memperkirakan pengaruh resiko pada proyek dan produk
4. Mencatat keseluruhan akurasi proyeksi resiko sehingga tidak akan ada kesalahpahaman
MENILAI PENGARUH RESIKO
Ada tiga faktor yang kemungkinan besar mempengaruhi konsekuensi jika suatu resiko benar-benar terjadi yaitu :
1. Sifat
2. Ruang lingkupnya
3. Timingnya
Berikut ini langkah-langkah yang direkomendasikan untuk menentukan konsekuensi keseluruhan dari suatu resiko :
1. Tentukan probabilitas rata-rata dari kejadian untuk masing-masing komponen resiko
2. Dengan menggunakan tabel resiko, tentukan pengaruh untuk masing-masing komponen berdasarkan kriteria yang diperlihatkan
3. Lengkapi tabel resiko dan analisis hasilnya.
PENILAIAN RESIKO
Rumus untuk penilaian resiko : [ri,li,xi]
Dimana ri adalah resiko, li adalah kemungkinan dan xi adalah pengaruh dari resiko tersebut. Selama penilaian resiko, lebih jauh kita harus menguji akurasi estimasi yang dibuat selama proyeksi resiko, berusaha memprioritaskan resiko yang diungkap, dan mulai berpikir mengenai cara mengontrol dan atau mencegah resiko yang mungkin terjadi.
Selama penilaian resiko, kita melakukan langkah-langkah berikut :
1. Tentukan tingkat referen resiko untuk proyek
2. Usahakan untuk mengembangkan hubungan antara masing-masing [ri,li,xi] dan masing-masing tingkat referen
3. Prediksikan himpunan titik referen yang menentukan daerah terminasi, dibatasi oleh kurva atau area ketidakpastian. Cobalah memprediksi bagaimana penggabungan kombinasi resiko akan mempengaruhi suatu titik referen.
Menurur Robert Charette dalam bukunya Software Engineering Risk Analysis and Management, resiko adalah : Pertama, resiko berhubungan dengan kejadian masa yang akan datang. Sekarang dan kemarin tidak mendapat perhatian aktif, karena kita telah mendapatkan apa yang telah kita tabur lewat sepak terjang di masa lalu. Kedua, bahwa resiko melibatkan perubahan, seperti dalam perubahan pikiran, pendapat, aksi atau tempat. Dan yang ketiga, resiko melibatkan pilihan dan ketidakpastian bahwa pilihan itu akan dilakukan.
Bila resiko dipertimbangkan dalam konteks rekayasa perangkat lunak, maka masa yang akan datang adalah perhatian kita mengenai :
1. Resiko apa yang menyebabkan proyek perangkat lunak menjadi serba salah ?
2. Bagaimana perubahan pada persyaratan pelanggan, teknologi pengembangan, komputer target, dan semua entitas lain yang berhubungan dengan proyek, mempengaruhi ketepatan waktu dan keberhasilan keseluruhan ?
3. Bagaimana banyak orang harus dilibatkan, berapa banyak penekanan pada kualitas yang dianggap memadai ?
Peter Drucker mengatakan “Meskipun tidak ada gunanya mencoba mengeliminasi resiko, dan sangat mungkin dipertanyakan bila kita mencoba meminimalkannya, sangat penting bahwa resiko yang diambil merupakan resiko yang tepat.” Sebelum kita mengidentifikasian “resiko yang benar” yang akan diambil selama menjalankan suatu proyek perangkat lunak, penting untuk mengidentifikasi semua resiko secara jelas.
STRATEGI RESIKO REAKTIF VS. PROAKTIF
RESIKO PERANGKAT LUNAK
Resiko selalu melibatkan dua karakteristik yaitu :
1. Ketidakpastian
Kejadian yang menandai resiko mungkin atau tidak mungkin terjadi, yaitu ada 100% resiko yang mungkin.
2. Rugi
Bila resiko menjadi realitas, akibat yang tidak diinginkan atau kerugian akan dialami.
Ada beberapa Kategori resiko yaitu :
1. Resiko Proyek
Resiko proyek mengancam rencana proyek. Yaitu bila resiko proyek menjadi nyata, ada kemungkinan jadwal proyek akan mengalami slip dan bahwa biaya menjadi bertambah. Resiko proyek mengidentifikasi hal potensial yang berhubungan dengan pembiayaan, jadwal, personil, sumber-sumber daya, pelanggan dan masalah persyaratan serta pengaruhnya terhadap proyek perangkat lunak.
2. Resiko Teknis
Resiko teknis mengancam kualitas dan ketepatan waktu perangkat lunak yang akan dihasilkan. Bila resiko teknis menjadi kenyataan, implementasinya menjadi sangat sulit atau tidak mungkin. Resiko teknis mengidentifikasi desain potensial, implementasi, interfecing, verifikasi dan masalah pemeliharaan.
3. Resiko Bisnis
Resiko bisnis mengancam viabilitas perangkat lunak yang akan dibangun. Resiko bisnis membahayakan proyek atau produk. Adapun lima resiko bisnis utama yaitu :
* Pembangunan produk atau system yang baik sekali yang sebenarnya tidak pernah diinginkan oleh setiap orang (resiko pasar).
* Pembangunan sebuah produk yang tidak lagi sesuai dengan keseluruhan strategi bisnis bagi perusahaan (resiko strategi)
* Pembangunan sebuah produk di mana bagian pemasaran tidak tahu bagaimana harus menjualnya
* Kehilangan dukungan manajemen senior sehubungan dengan perubahan pada focus atau perubahan pada manusia (resiko manajemen)
* Kehilangan hal-hal yang berhubungan dengan biaya atau komitment personal (resiko manajemen)
Sedangkan resiko yang diusulkan oleh Charette adalah :
1. Resiko yang sudah diketahui adalah resiko yang dapat diungkap setelah dilakukan evaluasi secara hati-hati terhadap rencana proyek, bisnis, dan lingkungan teknik dimana proyek sedang dikembangkan dan sumber informasi reliable lainnya.
2. Resiko yang dapat diramalkan diekstrapolasi dari pengalaman proyek sebelumnya.
3. Resiko yang tidak diharapkan dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya.
IDENTIFIKASI RESIKO
Identifikasi resiko adalah usaha sistematis untuk menentukan ancaman terhadap rencana proyek. Dengan mengidentifikasian resiko yang sudah diketahui dan dapat diprediksi, manajer proyek mengambil langkah pertama ke depan untuk menghindari resiko bilamana mungkin, serta menghindarinya setiap saat diperlukan.
Metode untuk mengidentifikasi resiko adalah menciptakan checklist item resiko. Checklist dapat digunakan pada identifikasi resiko dan berfokus pada beberapa himpunan bagian resiko yang sudah diketahui dan diprediksi dalam sub kategori berikut ini :
1. Ukuran produk
Resiko sehubungan dengan keseluruhan ukuran perangkat lunak yang akan dibangun atau dimodifikasi. Check list item resiko yang berhubungan dengan ukuran produk adalah :
* Ukuran produk diperkirakan dalam LOC atau FP ?
* Tingkat kepercayaan dalam estimasi ukuran yang diperkirakan ?
* Ukuran produk yang diestimasi dalam jumlah program, file dan transaksi ?
* Presentase deviasi dalam ukuran produk dari rata-rata produk terakhir ?
* Ukuran database yang dibuat atau digunakan oleh produk ?
* Jumlah pemakai produk ?
* Jumlah perubahan yang diproyeksikan ke persyaratan produk ? sebelum penyampaian ? setelah penyampaian ?
* Jumlah perangkat lunak yang digunakan kembali ?
2. Pengaruh bisnis
Resiko sehubungan dengan batasan yang dibebankan oleh manajemen atau pasar. Check list item resiko yang berhubungan dengan pengaruh bisnis adalah
* Pengaruh produk terhadap hasil perusahaan ?
* Visibilitas produk terhadap manajemen senior ?
* Kelayakan deadline penyampaian ?
* Jumlah pelanggan yang akan menggunakan produk dan konsistensi kebutuhan relative mereka dengan produk tersebut ?
* Jumlah produk/system lain dengan apa produk ini harus dapat saling dioperasikan ?
* Kepintaran pemakai akhir ?
* Jumlah dan kualitas dokumentasi produk yang harus diproduksi dan disampaikan kepada pelanggan ?
* Batasan pemerintahan pada konstruksi produk ?
* Biaya yang berhubungan dengan penyampaian yang terlambat ?
* Biaya yang berhubungan dengan produk detektif ?
3. Karakteristik pelanggan
Resiko sehubungan dengan kepintaran pelanggan dan kemampuan pengembang untuk berkomunikasi dengan pelanggan dengan cara yang tepat. Semua pelanggan tidak diciptakan sama. Pressman dan Herron menyatakan bahwa :
* Pelanggan mempunyai keinginan yang berbeda. Beberapa tahu apa yang mereka inginkan; yang lainnya tahu apa yang tidak mereka inginkan. Banyak pelanggan mau merinci detailnya, sementara yang lain dapat dipuaskan dengan janji-janji kosong.
* Pelanggan memiliki kepribadian yang berbeda. Beberapa menikmatinya sebagai pelanggan - tekanan, negosiasi, penghargaan psikologis dari suatu produk yang baik. Sementara lainnya tidak ingin menjadi pelanggan sama sekali.
* Pelanggan juga memiliki hubungan yang bervariasi dengan pemasok mereka. Beberapa mengenali produk dan produser secara baik; yang lainnya mungkin tidak, hanya berkomunikasi dengan produser melalui surat atau korespondensi serta beberapa melalui telepon.
* Pelanggan juga kadang-kadang bertentangan. Mereka menginginkan semua yang sudah ada kemarin secara gratis. Sering para pelanggan terperangkap di antara kontradisksi di dalam diri mereka sendiri.
Checklist item resiko yang mengidentifikasi resiko-resiko yang berhubungan dengan para pelanggan yang berbeda adalah :
* Pernahkan anda sebelumnya bekerja dengan pelanggan ?
* Apakah pelanggan memiliki gagasan yang solid mengenai apa yang diperlukannya ? sudahkah pelanggan menggunakan waktunya untuk menuliskannya ?
* Apakah pelanggan akan setuju dengan penggunaan waktu di dalam pertemuan pengumpulan persyaratan formal untuk mengidentifikasi ruang lingkup proyek?
* Apakah pelanggan bersedia membangun sambungan komunikasi cepat dengan pengembang ?
* Apakah pelanggan bersedia berpartisipasi dalam kajian ?
* Apakah pelanggan secara teknis pandai dalam area produk tersebut ?
* Apakah pelanggan bersedia membiarkan orang-orang melakukan pekerjaan mereka?
* Apakah pelanggan memahami proses perangkat lunak tersebut ?
4. Definisi proses
Resiko sehubungan dengan tingkat di mana proses perangkat lunak telah didefinisikan dan diikuti oleh organisasi pengembangan. Adapun masalah-masalah dalam proses :
* Apakah manajemen senior anda mendukung suatu pernyataan kebijaksanaan yang menekankan pentingnya suatu proses standar untuk pengembangan proses ?
* Sudahkah organisasi anda mengembangkan suatu deskripsi tertulis mengenai proses perangkat lunak yang akan digunakan pada proyek ini ?
* Apakah anggota-anggota staf ditugasi ke proses perangkat lunak pada saat perangkat lunak didokumentasi dan bersedia menggunakannya ?
* Apakah proses perangkat lunak digunakan untuk proyek lain ?
* Sudahkah organisasi anda mengembangkan atau mendapatkan serangkaian kursus pelatihan rekayasa perangkat lunak bagi para manajer dan staf teknik ?
* Apakah standar rekayasa perangkat lunak yang diterbitkan disediakan untuk setiap pengembangan perangkat lunak dan manajer perangkat lunak ?
* Sudahkah dokumen outline dan contoh-contoh dikembangkan untuk semua yang ditentukan sebagai bagian yang dapat disampaikan sebagai bagian dari proses perangkat lunak ?
* Apakah kajian teknis formal terhadap spesifikasi persyaratan, desain dan kode dilakukan secara regular ?
* Apakah kajian teknis formal terhadap prosedur pengujian dan test case dilakukan secara reguler ?
* Apakah hasil dari masing-masing kajian teknis formal didokumentasikan, termaksud kesalahan yang ditemukan dan sumber daya yang digunakan ?
* Apakah mekanisme untuk memastikan bahwa kerja yang dilakukan pada suatu proyek sesuai dengan standar rekayasa perangkat lunak ?
* Apakah manajemen konfigurasi digunakan untuk memelihara konsistensi diantara system/persyaratan perangkat lunak, desain, kode dan test case ?
* Apakah digunakan suatu mekanisme untuk mengontrol perubahan ke persyaratan pelanggan yang memperngaruhi perangkat lunak ?
* Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan dan rencana pengembangan perangkat lunak yang didokumentasikan untuk masing-masing subkontrak ?
* Apakah ada prosedur untuk menelusuri dan mengkaji kinerja subkontrak ?
Masalah-masalah teknis
* Apakah digunakan teknik spesifikasi aplikasi untuk membantu komunikasi di antara pelanggan dan pengembang ?
* Apakah metode spesifik digunakan untuk analisis perangkat lunak ?
* Apakah anda melihat suatu metode spesifik untuk data dan desain arsitektur?
* Apakah lebih dari 90 persen dari kode anda ditulis dengan bahasa orde yang lebih tinggi ?
* Apakah konvensi spesifik untuk dokumentasi kode didefiniskan dan digunakan ?
* Apakah anda menggunakan metode spesifik untuk desain test case ?
* Apakah digunakan peranti lunak untuk mendukung perencanaan dan aktivitas penelusuran ?
* Apakah digunakan peranti perangkat lunak manajemen konfigurasi untuk mengontrol dan menelusuri aktivitas perubahan di seluruh proses perangkat lunak ?
* Apakah digunakan peranti perangkat lunak untuk mendukung analisis perangkat lunak dan desain proses ?
* Apakah digunakan peranti untuk menciptakan prototipe perangkat lunak ?
* Apakah digunakan peranti perangkat lunak untuk mendukung proses pengujian ?
* Apakah peranti perangkat lunak digunakan untuk mendukung produksi dan manajemen dokumentasi ?
* Apakah metrik kualitas dikumpulkan bagi semua proyek perangkat lunak ?
* Apakah metrik produktivitas dikumpulkan bagi semua proyek perangkat lunak ?
Bila mayoritas jawaban terhadap pertanyaan tersebut adalah tidak, maka proses perangkat lunak lemah dan berisiko tinggi.
5. Lingkungan pengembangan
Resiko sehubungan dengan keberadaan dan kualitas peranti yang akan digunakan untuk membangun produk. Lingkungan proses perangkat lunak mendukung tim proyek, proses dan produk. Lingkungan yang salah dapat menjadi sumber resiko yang penting. Adapun checklist item yang berhubungan dengan lingkungan pengembangan :
* Apakah peranti manajemen proyek dapat diperoleh ?
* Apakah peranti manajemen proses dapat diperoleh ?
* Apakah peranti untuk analisis dan desain dapat diperoleh ?
* Apakah peranti analisis dan desain penyampaian metode sesuai bagi produk yang akan dibangun ?
* Apakah kompiler atau generasi kode dapat diperoleh sesuai untuk produk yang akan dibangun ?
* Apakah peranti pengujian dapat diperoleh dan sesuai dengan produk yang akan dibangun ?
* Apakah peranti manajemen konfigurasi perangkat lunak dapat diperoleh ?
* Apakah lingkungan menggunakan suatu database atau tempat penyimpanan ?
* Apakah semua peranti perangkat lunak diintegrasikan satu dengan lainnya ?
* Sudahkah anggota tim proyek menerima pelatihan dengan masing-masing peranti ?
* Apakah ada pakar lokal untuk menjawab pertanyaan-pertanyaan mengenai peranti tersebut ?
* Apakah bantuan dan dokumentasi on line bagi peranti memadai ?
Bila mayoritas jawaban terhadap pertanyaan tersebut adalah tidak, berarti lingkungan pengembangan perangkat lunak lemah dan beresiko tinggi.
6. Teknologi yang akan dibangun
Resiko sehubungan dengan komplesitas system yang akan dibangun dan kebaruan teknologi yang dikemas oleh system. Checklist item resiko yang berhubungan dengan teknologi yang akan dibangun adalah :
* Apakah teknologi yang akan dibangun adalah hal yang baru untuk organisasi anda ?
* Apakah persyaratan pelanggan memerlukan kreasi algoritma baru atau teknologi input atau output ?
* Apakah perangkat lunak berinterface dengan perangkat keras baru atau belum terbukti ?
* Apakah perangkat lunak yang akan dibangun berinterface dengan produk perangkat lunak yang dipasok oleh vendor yang belum terbukti ?
* Apakah perangkat lunak yang akan dibangun berinterface dengan suatu sistem database yang fungsi dan kinerjanya belum dibuktikan di dalam area aplikasi ini ?
* Apakah diperlukan interface pemakai khusus oleh persyaratan produk ?
* Apakah persyaratan untuk produk memerlukan kreasi komponen program yang tidak sama dengan yang dikembangkan terakhir oleh organisasi anda ?
* Apakah persyaratan memerlukan pemakaian analisis, desain, atau metode pengujian baru ?
* Apakah persyaratan memerlukan metode pengembangan perangkat lunak tidak konvensional, seperti metode formal, pendekatan AI based, dan jaringan saraf buatan.
* Apakah persyaratan meletakan batasan kinerja yang efektif pada produk tersebut?
* Apakah pelanggan tidak yakin bahwa fungsionalitas yang diminta dapat dilakukan?
Bila jawaban dari pertanyaan-pertanyaan di atas adalah ya, penyelidikan lebih lanjut harus dilakukan untuk memperkirakan resiko potensial.
7. Ukuran dan pengalaman staf - resiko sehubungan dengan keseluruhan teknik dan pengalaman proyek dari perekayasa perangkat lunak yang akan melakukan tugas tersebut. Checklist item resiko yang berhubungan dengan ukuran staf dan pengalaman adalah :
* Apakah orang-orang terbaik dapat didapatkan ?
* Apakah orang-orang tersebut memiliki gabungan keterampilan yang benar ?
* Apakah orang-orang yang ada mencukupi ?
* Apakah staf dimasukkan ke dalam seluruh durasi proyek ?
* Akankah banyak staf proyek bekerja hanya dalam paruh waktu pada proyek ini ?
* Apakah staf memiliki pengharapan yang tepat mengenai pekerjaan yang ada sekarang ?
* Sudahkah staf menerima pelatihan yang memadai ?
* Apakah pergantian di antara staf akan cukup rendah untuk memungkinkan kontinuitas ?
Bila jawaban terhadap pertanyaan-pertanyaan tersebut adalah tidak, maka penyelidikan lebih lanjut harus dilakukan untuk memperkirakan resiko potensial.
KOMPONEN RESIKO DAN DRIVER
Manajer proyek mengidentifikasi resiko driver yang mempengaruhi komponen resiko perangkat lunak. Adapun komponen resiko didefinisikan dengan cara :
1. Resiko kinerja - tingkat ketidakpastian di mana produk akan memenuhi persyaratannya dan cocok dengan penggunaannya.
2. Resiko biaya - tingkat ketidakpastian di mana biaya produk akan dijaga
3. Resiko dukungan - tingkat ketidakpastian di mana perangkat lunak akan mudah dikoreksi, disesuaikan dan ditingkatkan
4. Resiko jadwal - tingkat ketidakpastian di mana jadwal proyek akan dijaga dan produk akan disampaikan tepat waktu.
PROYEKSI RESIKO
Proyeksi resiko disebut juga perkiraan resiko, berusaha menjangkau setiap resiko dalam dua cara - kemungkinan atau probablititas di mana resiko adalah nyata dan konseskuensi masalah yang berhubungan dengan resiko yang harus terjadi. Ada empat aktivitas proyeksi resiko yaitu :
1. Membangun suatu skala yang merefleksikan kemungkinan resiko yang dirasakan
2. Menggambarkan konsekuensi resiko
3. Memperkirakan pengaruh resiko pada proyek dan produk
4. Mencatat keseluruhan akurasi proyeksi resiko sehingga tidak akan ada kesalahpahaman
MENILAI PENGARUH RESIKO
Ada tiga faktor yang kemungkinan besar mempengaruhi konsekuensi jika suatu resiko benar-benar terjadi yaitu :
1. Sifat
2. Ruang lingkupnya
3. Timingnya
Berikut ini langkah-langkah yang direkomendasikan untuk menentukan konsekuensi keseluruhan dari suatu resiko :
1. Tentukan probabilitas rata-rata dari kejadian untuk masing-masing komponen resiko
2. Dengan menggunakan tabel resiko, tentukan pengaruh untuk masing-masing komponen berdasarkan kriteria yang diperlihatkan
3. Lengkapi tabel resiko dan analisis hasilnya.
PENILAIAN RESIKO
Rumus untuk penilaian resiko : [ri,li,xi]
Dimana ri adalah resiko, li adalah kemungkinan dan xi adalah pengaruh dari resiko tersebut. Selama penilaian resiko, lebih jauh kita harus menguji akurasi estimasi yang dibuat selama proyeksi resiko, berusaha memprioritaskan resiko yang diungkap, dan mulai berpikir mengenai cara mengontrol dan atau mencegah resiko yang mungkin terjadi.
Selama penilaian resiko, kita melakukan langkah-langkah berikut :
1. Tentukan tingkat referen resiko untuk proyek
2. Usahakan untuk mengembangkan hubungan antara masing-masing [ri,li,xi] dan masing-masing tingkat referen
3. Prediksikan himpunan titik referen yang menentukan daerah terminasi, dibatasi oleh kurva atau area ketidakpastian. Cobalah memprediksi bagaimana penggabungan kombinasi resiko akan mempengaruhi suatu titik referen.
Pengertian dan ruang lingkup proyek
PENGERTIAN PROYEK
Pengertian judul proyek untuk Tugas Akhir Konsepsi “Perancangan Ulang Kantor Pusat PT Asian Profile Indosteel di Surabaya” dijelaskan sebagai berikut:
Menurut Drs. Kamisa, ulang berarti: kembali; lagi; berkali-kali. Perancangan sama dengan: proses, cara, perbuatan merancang. Dan merancang diartikan: mengatur segala sesuatu (sebelum bertindak, mengerjakan, atau melakukan sesuatu), merencanakan.
Perancangan dalam konteks arsitektur, adalah semata-mata usulan pokok yang mengubah sesuatu yang sudah ada menjadi sesuatu yang lebih baik. Perancangan dapat dianggap sebagai sesuatu proses tiga bagian yang terdiri dari keadaan semula suatu metode atau proses tranformasi, dan sesuatu keadaan masa depan yang dibayangkan. Perancangan terjemahan dari design – yang dalam bentuk kata kerjanya dapat diartikan “merancang, untuk tujuan” – diartikan sebagai suatu produk perumusan keinginan atau cita-cita masa datang yang merupakan penguraian/bagian-bagian dari produk perencanaan. Sedangkan perencanaan sendiri terjemahan dari planning merupakan suatu hasil rangkaian kerja untuk merumuskan sesuatu yang didasari oleh suatu pola tindakan yang definitif, yang menurut pertimbangan yang sistematis akan dapat membawa keuntungan, tetapi dengan anggapan bahwa akan ada tindakan-tindakan selanjutnya berupa rangkaian kegiatan sistematis lainnya. Tindakan yang dirumuskan semula itu masih bersifat terbuka bagi kemungkinan adanya pilihan cara tindakan lain, dan mungkin disesuaikan apabila dianggap kurang menguntungkan pada saat tertentu. Jadi perancangan adalah kelanjutan yang berbentuk uraian atau penjabaran dari perencanaan.
Perancangan ulang terjemahan dari redesign, yang berarti tindakan merancang sekali lagi, yang sebelumnya telah ada rancangan pada suatu objek yang sama. Perancangan ulang ini dilakukan karena adanya kekurang-kekurangan pada rancangan yang lama, dan membuat rancangan baru yang diharapkan dapat lebih baik dan lebih menguntungkan.
Menurut Dhanny R. Cyssco dan Dr. Jack Dawson, pusat sama dengan center, bagian tengah. Dan menurut William D. Powell, dapat juga disamakan dengan main, yang berarti utama, besar, induk. Jadi kantor pusat dapat diartikan sebagai kantor utama atau kantor induk yang berada di bagian tengah.
PT Asian Profile Indosteel adalah nama perusahaan pemilik kantor tersebut. Dan Surabaya adalah nama kota tempat kantor itu berada.
Jadi Perancangan Ulang Kantor Pusat PT Asian Profile Indosteel di Surabaya dapat dijabarkan menjadi perumusan keinginan atau cita-cita yang didasari oleh suatu pola tindakan yang definitif, yang menurut pertimbangan yang sistematis akan dapat lebih membawa keuntungan dibandingkan rancangan sebelumnya pada objek bangunan yang dipakai untuk bekerja yang berkenaan dengan urusan administrasi dan organisasi milik PT Asian Profile Indosteel di suatu kota bernama Surabaya.
RUANG LINGKUP PROYEK
Pengertian : Jaman sekarang ini banyak kita menemukan contoh adanya proyek baik itu proyek skala kecil maupun besar, proyek komersial maupun pelayanan umum. Pembangunan pelabuhan, pembangunan pelabuhan, pembangunan bandara dan lain – lain disebut proyek dan Ruang lingkup proyek meliputi tata cara untuk menentukan waktu proyek dimulai, perencanaan lingkup proyek yang akan di garap, pendefinisian ruang lingkup proyek, verifikasi proyek serta kontrol atas perubahan yang mungkin terjadi saat proyek tersebut di mulai.
Contoh : proyek yang ada disekitar daerah saya yaitu seperti pembangunan perumahan, perbaikan jalan dan pembanguan mesjid.
Pengertian judul proyek untuk Tugas Akhir Konsepsi “Perancangan Ulang Kantor Pusat PT Asian Profile Indosteel di Surabaya” dijelaskan sebagai berikut:
Menurut Drs. Kamisa, ulang berarti: kembali; lagi; berkali-kali. Perancangan sama dengan: proses, cara, perbuatan merancang. Dan merancang diartikan: mengatur segala sesuatu (sebelum bertindak, mengerjakan, atau melakukan sesuatu), merencanakan.
Perancangan dalam konteks arsitektur, adalah semata-mata usulan pokok yang mengubah sesuatu yang sudah ada menjadi sesuatu yang lebih baik. Perancangan dapat dianggap sebagai sesuatu proses tiga bagian yang terdiri dari keadaan semula suatu metode atau proses tranformasi, dan sesuatu keadaan masa depan yang dibayangkan. Perancangan terjemahan dari design – yang dalam bentuk kata kerjanya dapat diartikan “merancang, untuk tujuan” – diartikan sebagai suatu produk perumusan keinginan atau cita-cita masa datang yang merupakan penguraian/bagian-bagian dari produk perencanaan. Sedangkan perencanaan sendiri terjemahan dari planning merupakan suatu hasil rangkaian kerja untuk merumuskan sesuatu yang didasari oleh suatu pola tindakan yang definitif, yang menurut pertimbangan yang sistematis akan dapat membawa keuntungan, tetapi dengan anggapan bahwa akan ada tindakan-tindakan selanjutnya berupa rangkaian kegiatan sistematis lainnya. Tindakan yang dirumuskan semula itu masih bersifat terbuka bagi kemungkinan adanya pilihan cara tindakan lain, dan mungkin disesuaikan apabila dianggap kurang menguntungkan pada saat tertentu. Jadi perancangan adalah kelanjutan yang berbentuk uraian atau penjabaran dari perencanaan.
Perancangan ulang terjemahan dari redesign, yang berarti tindakan merancang sekali lagi, yang sebelumnya telah ada rancangan pada suatu objek yang sama. Perancangan ulang ini dilakukan karena adanya kekurang-kekurangan pada rancangan yang lama, dan membuat rancangan baru yang diharapkan dapat lebih baik dan lebih menguntungkan.
Menurut Dhanny R. Cyssco dan Dr. Jack Dawson, pusat sama dengan center, bagian tengah. Dan menurut William D. Powell, dapat juga disamakan dengan main, yang berarti utama, besar, induk. Jadi kantor pusat dapat diartikan sebagai kantor utama atau kantor induk yang berada di bagian tengah.
PT Asian Profile Indosteel adalah nama perusahaan pemilik kantor tersebut. Dan Surabaya adalah nama kota tempat kantor itu berada.
Jadi Perancangan Ulang Kantor Pusat PT Asian Profile Indosteel di Surabaya dapat dijabarkan menjadi perumusan keinginan atau cita-cita yang didasari oleh suatu pola tindakan yang definitif, yang menurut pertimbangan yang sistematis akan dapat lebih membawa keuntungan dibandingkan rancangan sebelumnya pada objek bangunan yang dipakai untuk bekerja yang berkenaan dengan urusan administrasi dan organisasi milik PT Asian Profile Indosteel di suatu kota bernama Surabaya.
RUANG LINGKUP PROYEK
Pengertian : Jaman sekarang ini banyak kita menemukan contoh adanya proyek baik itu proyek skala kecil maupun besar, proyek komersial maupun pelayanan umum. Pembangunan pelabuhan, pembangunan pelabuhan, pembangunan bandara dan lain – lain disebut proyek dan Ruang lingkup proyek meliputi tata cara untuk menentukan waktu proyek dimulai, perencanaan lingkup proyek yang akan di garap, pendefinisian ruang lingkup proyek, verifikasi proyek serta kontrol atas perubahan yang mungkin terjadi saat proyek tersebut di mulai.
Contoh : proyek yang ada disekitar daerah saya yaitu seperti pembangunan perumahan, perbaikan jalan dan pembanguan mesjid.