Site blog

Halaman: () 1 ... 39 40 41 42 43 44 45 46 ()
Anyone in the world

Many perceptions about user requirements

 

10 Langkah Untuk Keberhasilan Requirement Gathering:

Sering kita mendengar pada proyek akhir yang gagal “Requirement  yang tidak jelas”. Kita mulai mencari-cari hal yang patut disalahkan. Untungnya, ada cara sederhana untuk mengatasi masalah itu, itu jelas seperti itu menantang: pengumpulan requirement.

Tergantung pada metodologi proyek Anda, Anda dapat melakukan langkah ini pada awal selama fase Discovery, Anda dapat melakukannya selama proyek dalam setiap sprint atau membangun siklus, atau Anda dapat mengabaikan sama sekali dan berharap untuk yang terbaik.

Keberhasilan Requirement Gathering adalah baik dari segi seni dan ilmu pengetahuan, tetapi ada beberapa langkah umum yang dapat Anda ambil untuk menjaga ini langkah yang sangat penting dari proyek Anda pada proses yang benar.

1)      Menetapkan Sasaran & Tujuan Awal

Tanpa tujuan dan sasaran dinyatakan dengan jelas, Anda kekurangan kerangka untuk memandu dalam pengambilan keputusan. Bagaimana Anda tahu apakah requirement  baru diperkenalkan benar-benar cocok dalam proyek Anda? Sederhana: apakah itu membantu mencapai tujuan, atau apakah itu memenuhi tujuan? Jika demikian, itu mungkin cocok. Jika tidak, itu adalah calon yang baik untuk masa mendatang.

2)      Menuliskan kebutuhan user
Ketika Anda berada di tengah-tengah wawancara dengan stakeholder dan review dokumen, Anda dapat sering merasa seperti Anda memiliki pemahaman yang besar pada hal-hal. Tapi kemudian minggu berlalu, dan beberapa rincian mulai kabur, dan Anda sadar bahwa Anda tidak cukup memiliki pemahaman penuh X, Y, atau Z. Ini terdengar jelas, tapi memastikan bahwa Anda mengambil catatan rinci selama wawancara dengan stakeholder Anda adalah langkah yang kuat dalam sukses dalam requirements gathering.

3)      Transparan

Tentu, Anda memahami requirement . Dan klien Anda memahami requirement . Tapi apakah klien Anda mengerti pemahaman Anda tentang requirement ? Setelah setiap pertemuan, melalui catatan Anda dan membersihkan mereka - kemudian berbagi dengan tim proyek, termasuk klien. Transparansi ini tidak hanya membantu memastikan semua orang pada persepsi yang sama, dimulai dari transparansi

4)      Bicara dengan orang yang tepat

Sebuah proyek sering dapat memiliki "hidden" stakeholder. Tanyakan pertanyaan menyelidik di pertemuan awal dengan klien Anda untuk mencoba dan mendapatkan siapa pengguna yang sebenarnya - sering orang-orang tidak akan menjadi pengambil utama keputusan, tapi mereka sangat penting untuk sebuah proyek yang sukses. Pengguna yang tidak puas dipaksa untuk menggunakan sistem setiap hari yang dirancang tanpa masukan dari mereka adalah bahan utama untuk proyek gagal.

5)      Dapatkan Detil kebutuhan user

Jangan berasumsi bahwa Anda memahami segala sesuatu, bahkan jika itu tampak jelas. Requirement yang tampaknya sederhana seperti "kita ingin blog" dapat menutupi segala macam asumsi yang mendasari, requirement , dll. Apa kolom untuk posting blog? Bagaimana penulis berhasil? Bagaimana tagging? Kategori? Bagaimana tulisan ditampilkan? Apakah mereka dikumpulkan ke dalam arsip? Apakah ada feed RSS? Siapa penulis dan apa tingkat kemahiran teknis mereka?   Kebutuhan harus detil. Anda dapat tidak dapat memahami jika hanya dengan menangkap di bagian akhir dari kebutuhan.  Detil kebutuhan dapat dicapai dengan banyak pertanyaan dan tidak bergantung pada asumsi.

6)      Konfirmasi

Ini mengikat ke "transparan" tetapi tidak sepenuhnya hal yang sama. Hanya berbagi catatan Anda dengan klien adalah baik, tetapi jauh lebih berharga sebenarnya memiliki ulasan singkat dengan mereka. Hal ini berlaku untuk catatan pertemuan, cerita pengguna, diagram, wireframes,  semua requirement  artefak yang benar-benar Anda ciptakan. Mendapatkan konfirmasi yang sebenarnya dari klien Anda bahwa Anda mewakili requirement  dengan benar dalam format apa pun yang Anda gunakan

7)      Jadilah Seorang Pendengar Aktif

Membuat seseorang merasa mendengar adalah salah satu hal terbesar yang bisa Anda lakukan untuk mereka. Tapi itu melampaui hanya mendengarkan apa yang mereka katakan - Anda juga perlu mendengarkan apa yang mereka tidak katakan, dan bagaimana mereka mengatakan hal-hal, dan membaca bahasa tubuh mereka. Hal ini disebut " active listening " dan itu adalah komponen kunci kedua requirement  sukses pengumpulan dan komedi improvisasi. Jangan berasumsi bahwa Anda selalu mendapatkan seluruh cerita - mendengarkan isyarat kecil yang mengungkapkan poin rasa sakit, keinginan, tujuan tak tertulis, dan asumsi.

 

8)      Fokus Pada Kebutuhan, Bukan Alat

Hati-hati saat Anda mengumpulkan requirement bahwa Anda benar-benar berfokus dan mendengarkan apa kebutuhan klien Anda, bukan pada pilihan alat yang terbaik. Bahkan jika Anda tahu Anda akan menggunakan produk tertentu, Anda perlu menyesuaikan produk ke pengguna, bukan sebaliknya. Mendengarkan dan mengumpulkan dilakukan terlebih dahulu, kemudian menentukan mana kesenjangan yang antara kebutuhan klien Anda dan produk yang mungkin Anda ada dalam pikiran. Ingat: Requirement adalah tentang APA, bukan CARA.

9)      Prioritaskan

Dalam sebuah metodologi agile, kami bekerja menuju Minimum Viable Product (MVP), yang merangkum sedikitnya jumlah fungsi yang akan dihitung sebagai produk yang sukses pada saat peluncuran. Bahkan ketika mengikuti metodologi non-agile, prioritas adalah teman Anda ketika Anda mengumpulkan requirement. Sangat mudah untuk pengumpulan requirement  sesi berubah menjadi sesi pertemuan wishlist, di mana para pemangku kepentingan memberitahu Santa (yaitu Anda) segala sesuatu yang mereka inginkan. Intinya adalah untuk tidak mengabaikan informasi yang (sebenarnya sering mengungkapkan tujuan dan asumsi jika Anda menggunakan Active Listening) melainkan dengan jelas dan transparan memprioritaskan apa yang Anda dengar dan menggambarkan apa yang ada di lingkup untuk peluncuran awal Anda dan apa tidak. Anda pasti ingin lacak pada daftar keinginan item, “nice-to-haves,” tapi prioritas membantu Anda memfokuskan upaya Anda dan membantu Anda membuat keputusan jika waktu singkat.

10)   Ingat bahwa Anda Tidak Dapat Semuanya

Bahkan requirement  gathering terbaik akan kehilangan sesuatu. Mengapa? Karena Anda dan klien Anda adalah manusia, dan manusia membuat kesalahan. Anda akan memikirkan hal-hal kemudian bahwa Anda lupa untuk bertanya. Klien Anda akan memikirkan hal-hal yang mereka lupa untuk menyebutkan. Hal akan berubah. Prioritas akan bergeser. Kabar baiknya adalah bahwa jika Anda merencanakan ke depan untuk ini, Anda dapat membangun dalam waktu selama siklus hidup proyek Anda untuk manajemen kebutuhan yang sedang berlangsung. Kali ini penting karena kebutuhan (menjadi human-driven dan human-created) hanya tidak statis. Memberikan waktu Anda untuk secara aktif mengelola kebutuhan di seluruh proyek dapat membantu Anda berhenti scope creep sebelum dimulai, dan pastikan bahwa tim Anda selalu berfokus pada hak mengatur prioritas yang sesuai dengan kebutuhan yang sebenarnya.

 

(https://www.phase2technology.com/blog/what-the-heck-are-we-building-10-steps-to-successful-requirements-gathering)
[ Mengubah: Thursday, 1 December 2016, 11:18 ]
 
Anyone in the world

Elisitasi atau pengumpulan merupakan aktivitas awal dalam proses rekayasa kebutuhan (Requirement Engineering). Sebelum kebutuhan dapat dianalisis, dimodelkan atau ditetapkan, kebutuhan harus dikumpulkan melalui proses elisitasi. Elisitasi kebutuhan adalah sekumpulan aktivitas yang ditujukan untuk menemukan kebutuhan suatu sistem melalui komunikasi dengan pelanggan, pengguna sistem dan pihak lain yang memiliki kepentingan dalam pengembangan sistem (Sommerville and sawyer, 1997).

Pada aktivitas ini berbagai kebutuhan dari para pemangku kepentingan dikumpulkan. Seorang pelanggan mempunyai masalah dan ingin dapat ditangani menggunakan solusi berbasis komputer. Tantangan ini ditanggapi oleh pihak pengembang. Disinilah komunikasi dimulai antara pelanggan, pengembang dan calon pengguna dari sistem yang akan dibuat. Namun istilah elisitasi agak diperdebatkan. Ada yang menganalogikan seperti yang dilakukan oleh para arkeolog ketika mengumpulkan runtuhan-runtuhan di situs purbakala. Ada yang memberikan istilah requrement capture karena dilakukan terutama dengan mengumpulkan fakta-fakta. Bahkan ada pendapat lebih memilih menyatakan kebutuhan adalah sesuatu yang dibuat dari pada didapatkan (Dorfman and Thayer, 1990).

Sejalan dengan proses rekayasa kebutuhan secara keseluruhan, elisitasi kebutuhan bertujuan untuk (Leffingwel, 2000) :

1. Mengetahui masalah apa saja yang perlu dipecahkan dan mengenali batasan-batasan sistem (system boundaries)

Proses-proses dalam pengembangan perangkat lunak sangat ditentukan oleh seberapa dalam dan luas pengetahuan developer akan ranah permasalahan. Setiap ranah permasalahan memiliki ruang lingkup dan batasan-batasan. Batasan-batasan ini mendifinisikan sistem akhir yang dibentuk sesuai dengan lingkungan operasional saat ini. Identifikasi dan persetujuan batasan sistem mempengaruhi proses elisitasi selanjutnya. Identifikasi pemangku kepentingan dan kelas pengguna, tujuan dan tugas, dan skenario serta use case bergantung pada pemilihan batasan.

2. Mengenali siapa saja para pemangku kepentingan

Sebagaimana disebutkan pada bagian sebelumnya, instasiasi dari pemangku kepentingan antara lain adalah konsumen atau klien (yang membayar sistem), pengembang (yang merancang, membangun dan merawat sistem), dan pengguna (yang berinteraksi dengan sistem untuk mendapatkan hasil pekerjaan mereka). Untuk sistem yang bersifat interaktif, pengguna memegang peran utama dalam proses elisitasi. Secara umum, kelas pengguna tidak bersifat homogen, sehingga bagian dari proses elisitasi adalah mengidentifikasi kebutuhan kelas pengguna yang berbeda, seperti pengguna pemula, pengguna ahli, pengguna sesekali, pengguna cacat, dan lain-lain.

3. Mengenali tujuan dari sistem yaitu sasaran-sasaran yang harus dicapai

Tujuan merupakan sasaran sistem yang harus dipenuhi. Penggalian high level goal di awal proses pengembangan sangatlah penting. Penggalian tujuan lebih terfokus pada ranah masalah dan kebutuhan pemangku kepentingan daripada solusi yang dimungkinkan untuk masalah tersebut.

Tahap elisitasi termasuk tahap yang sulit dalam spesifikasiperangkat lunak. Secara umum kesulitan ini disebabkan tiga masalah, yakni : masalah cakupan (scope), masalah pemahaman, dan masalah perubahan (volatility) (Nuseibeh and Eastbrook,2000).

1. Masalah ruang lingkup

Pelanggan/pengguna menentukan detail teknis yang tidak perlu sebagai batasan sistem yang mungkin membingungkan dibandingkan dengan menjelaskan tujuan sistem secara keseluruhan.

2. Masalah pemahaman

Hal tersebut terjadi ketika pelanggan atau pengguna tidak benar-benar yakin tentang apa yang dibutuhkan oleh sistem, memiliki pemahaman yang sedikit dan tidak memiliki pemahaman penuh terhadap ranah masalah.

3. Masalah perubahan

Yaitu perubahan kebutuhan dari waktu ke waktu. Untuk membantu mengatasi masalah ini, perekayasa sistem (system engineering) harus melakukan kegiatan pengumpulan kebutuhan secara terorganisasi.

Ketiga masalah tersebut muncul karena (Sommerville, 2007) :

  1. Pemangku kepentingan sering tidak mengetahui apa yang diinginkan dan mengungkapkan keinginannya dalam kalimat yang umum. Mereka kesulitan dalam mengungkapkan apa yang mereka ingin untuk sistem lakukan atau membuat permintaan yang tidak realistis karena mereka tidak mengerti biaya dari permintaan mereka.
  2. Pemangku kepentingan mengungkapkan permintaan dalam istilah bidang pekerjaannya, sehingga perekayasa kebutuhan yang tidak memiliki pengalaman dibidang kerja pemesan harus memahami permintaan tersebut.
  3. Beberapa pemangku kepentingan memiliki permintaan yang berbeda-beda yang dinyatakan dalam cara yang berbeda pula. Perekayasa kebutuhan harus mempertimbangkan semua sumber kebutuhan dan menemukan kebiasaan dan konflik.
  4. Faktor politik dapat mempengaruhi kebutuhan sistem. Sebagai contoh, manajer meminta kebutuhan sistem tertentu yang akan meningkatkan pengaruh mereka dalam organisasi.
  5. Lingkungan bisnis dan ekonomi bersifat dinamis. Perubahan selama proses analisis pasti terjadi. Itulah pentingnya keterangan perubahan kebutuhan. Kebutuhan baru dapat muncul dari pemangku kepentingan baru yang pada dasarnya tidak dikonsultasikan.

Proses elisitasi adalah proses rekayasa kebutuhan yang berhubungan dengan kegiatan manusia. Masalah yang muncul juga masalah manusia. Oleh karena itu, seorang analis kebutuhan harus dibekali landasan teori ilmu sosial dan teknik praktik elisitasi kebutuhan yang baik. Ilmu sosial tersebut antara lain (Nuseibeh dan Eastbrook, 2000) :

  1. Cognitive psychology, yang menekankan tentang kesulitan seseorang dalam mendiskripsikan kebutuhannya. Sebagai contoh, seorang problem ranah expert sering memiliki tacit knowledge dan tidak menyetujui adanya instropeksi. Sehingga, mereka mungkin akan menjawab pertanyaan yang diajukan tidak sesuai dengan kebiasaan yang dilakukan. Perekayasa kebutuhan perlu memodelkan pemahaman pengguna tentang antarmuka perangkat lunak daripada hanya mengandalkan preferensi pelaksana.
  2. Antropologi memberikan pendekatan metodologis untuk mengamati untuk mengamati kegiatan manusia yang membantu pemahaman lebih mendalam tentang bagaimana sistem komputer membantu atau mengganggu kegiatan. Sebagai contoh, teknik ethnomethodologi untuk menganalisa hasil kerjasama dan interaksi tim.
  3. Sosiologi memberikan pemahaman tentang perubahan politik dan budaya yang disebabkan oleh komputerisasi. Pengenalan sebuah sistem komputer baru dapat mengubah cara kerja suatu dan perilaku dari suatu organisasi. Lebih dalam lagi, introduksi teknologi baru tersebut dapat mempengaruhi cara dan struktur komunikasi dalam organisasi. Sebagai akibatnya dimungkinkan terjadi perubahan kebutuhan dasar yang dilakukan untuk memuaskan pihak tertentu. Sebuah proses pengumpulan kebutuhan dapat menjadi terpolitisasi. Untuk itu, pendekatan rekayasa kebutuhan yang dapat mengatasi masalah ini adalah pendekatan scandinavian, dimana pendekatan ini bertujuan melibatkan proses definisi kebutuhan untuk mengetahui hasil yang paling terpengaruhi.
  4. Ilmu bahasa sangat penting karena elisitasi kebutuhan berkutat pada komunikasi. Analisa bahasa telah mengubah cara dimana bahasa alamiah digunakan dalam spesifikasi untuk mencegah kerancuan dan meningkatkan pemahaman. Perkakas bantu dari ilmu bahasa juga dapat digunakan untuk elisitasi kebutuhan sebagai contoh untuk menganalisa pola komunikasi dalam sebuah organisasi.

(Sumber : Analisa Kebutuhan dalam Rekayasa Perangkat Lunak, Daniel Siahaan, 2012)

[ Mengubah: Wednesday, 9 November 2016, 23:02 ]
 
Anyone in the world

SOFTWARE DESAIN ARSITEKTURAL UNTUK ARSITEK

Jika Anda seorang arsitek profesional atau mahasiswa arsitektur yang mencari cara untuk membuat pekerjaan Anda jauh lebih mudah dalam merancang, ada software desain arsitektur yang dapat memenuhi semua kebutuhan tersebut. Anda dapat menggunakan software ini untuk membantu dalam sebuah proyek dan bahkan dalam memulai untuk mendesain rumah sendiri di masa depan. Software ini dapat membantu kita dalam membuat desain 2D atau 3D dan kebanyakan memiliki fitur otomatis untuk membuat desain lebih mudah. Mereka datang dalam berbagai jenis di sesuai dengan kebutuhan Si perancang. Bahkan ada software yang dapat digunakan oleh pemula dan mereka yang memiliki sedikit pengalaman dalam desain arsitektur. Selain itu ada juga beberapa fitur-fitur canggih dan mengharuskan seorang arsitek yang berpengalaman untuk mengoperasikan dan memahami software tersebut.

Berikut adalah software desain arsitektural yang biasanya digunakan oleh arsitek.

A. MICROSTATION

Microstation adalah software berbasiskan grafik yang digunakan untuk penggambaran 2D maupun 3D mirip seperti software AutoCAD . Bahkan sistem kerjanya pun mirip dengan apa yang ada di AutoCAD ,Tetapi microstation memiliki kelebihan yaitu pada fitur yang lebih memudahkan user untuk mendesign.

Tidak semua orang bisa mengoperasikan Microstation, kebanyakan software ini dipakai untuk bidang teknik , infrastruktur, dan bisa di Customize sesuai keinginan user.

Namun ada banyak orang yang menggunakan software ini karena stabilitas ketika datang ke platform yang mereka dapat bekerja pada tidak seperti perangkat lunak lain. Mereka juga merasa lebih mudah untuk digunakan. Ada beberapa masalah dengan menggunakan software ini, yaitu adalah kompatibilitas dan dapat menyebabkan beberapa masalah alur kerja kepada pengguna. Beberapa gambar yang dari AutoCAD tidak dapat dilihat di Microstation. Hal ini menyebabkan mencari bantuan dari seorang arsitek untuk melakukan binding atau melakukan perubahan yang diperlukan pada Anda sendiri.

B. SKECTHUP

Sketchup adalah sebuah software komputer untuk membuat model 3 Dimensi (3-D) atas benda-benda fisik seperti gedung-gedung, peralatan rumah tangga, disain tata ruang dan sebagainya.

Setelah Google membeli hak dari perangkat lunak ini, perangkat lunak sekarang menjadi populer dan dikenal pengguna. Perangkat lunak ini memungkinkan pengguna untuk dengan cepat dan mudah membuat desain bangunan 3D. Meskipun fitur yang telah mungkin canggih seperti dapat Anda temukan di perangkat lunak lain, harganya wajar terutama jika Anda tidak memerlukan perangkat lunak yang canggih di tempat pertama. Perangkat lunak ini adalah kesepakatan besar bagi siswa yang mencari perangkat lunak yang dapat menghasilkan desain 3 dimensi dalam waktu singkat dan bagi orang-orang yang baru mulai pada karir arsitektur mereka.

C. REVIT ARCHITECTURE

Revit Architecture merupakan aplikasi building information modeling (BIM). Aplikasi BIM lebih dari sekedar aplikasi 3D modeling. Jika anda bekerja dengan model 3D, anda hanya dapat menggunakannya untuk visualisasi. Sementara dengan BIM, anda dapat melakukan jauh lebih banyak.

Berbeda dengan AutoCAD yang merupakan aplikasi CAD untuk umum, aplikasi BIM didesain khusus untuk para arsitek dan insinyur yang berkaitan dengan bangunan. Secara ringkas, BIM dapat diartikan anda membuat dan menggunakan model virtual dari bangunan. Sama seperti halnya jika anda membangun bangunan sesungguhnya, anda juga melakukan hal yang sama di Revit.

Ini adalah perangkat lunak yang dibangun untuk membangun model informasi atau BIM, yang merupakan kunci untuk desain berkelanjutan. Perubahan yang akan Anda buat akan secara otomatis dikoordinasikan seluruh proyek yang Anda bekerja masuk ini akan membantu Anda dalam membuat sebuah proyek terdiri dan lengkap.

D.  SOFTPLAN

Hal ini mudah untuk menggunakan perangkat lunak yang dapat Anda gunakan pada semua kebutuhan Anda merancang. Hal ini juga mendukung membangun model informasi yang memberikan dokumentasi lengkap, 3 dimensi kemampuan merancang, daftar bahan dan real time estimasi biaya repots. Perubahan yang Anda akan lakukan pada desain Anda secara otomatis akan dikoordinasikan seluruh proyek yang sedang Anda kerjakan. Ini adalah pilihan terbaik ketika Anda bekerja pada desain perumahan dan komersial.

E.  AUTODESK REVIT

Autodesk Revit Structure merupakan salah satu program bantu berbasis BIM (Building Information Modelling) yang membantu membantu pendokumentasian proyek secara lebih nyata dengan pemodelan tiga dimensi. Studi literatur terhadap karakteristik Revit Structure diperlukan untuk mengetahui semua sisi yang penting untuk diketahui pengguna sebelum memutuskan untuk menggunakan program ini pada saat perancangan konstruksi. Studi literatur secara terhadap Revit Structure akan memberikan pandangan yang lebih luas kepada pengguna dan memaksimalkan penggunaanya pada saat pelaksanaan perancangan konstruksi.

Kelebihan yang dimiliki Revit Structure bisa digunakan sebagai alasan untuk mulai mencoba melaksanakan perencanaan proyek konstruksi menggunakan aplikasi ini. Kekurangan yang dimiliki juga harus diketahui sehingga lebih waspada dan bersiap menutupi kekurangan yang ada saat penggunaannya.

F. VECTORWORK ARSITEKTUR

Ini mungkin tidak sesederhana untuk digunakan sebagai perangkat lunak lain, tetapi melalui keterlibatannya desainer dapat menghasilkan hasil yang luar biasa dan menghasilkan proyek-proyek yang luar biasa. Berjam-jam dan kadang-kadang frustasi bahwa Anda akan memiliki dalam belajar semua akan sia-sia, terutama bila Anda sudah bisa membuat cepat dan unik desain setelah beberapa waktu. Perangkat lunak ini juga mendukung membangun model informasi. Hal ini sebenarnya mudah untuk menggunakan aplikasi bila Anda terbiasa untuk itu. Ini adalah perangkat lunak yang cocok untuk orang-orang dengan pengalaman dan mereka yang ingin memiliki hasil terbaik.Hal ini tidak dianjurkan untuk pertama timer dalam desain arsitektur.

G. AUTOCAD ARCHITECTURE

AutoCAD adalah perangkat lunak komputer CAD untuk menggambar 2 dimensi dan 3 dimensi yang dikembangkan oleh Autodesk. Keluarga produk AutoCAD, secara keseluruhan, adalah software CAD yang paling banyak digunakan di dunia. Computer Aided Design (CAD) merupakan salah satu cabang dari ilmu komputer grafis. Fungsi atau kegunaan dari CAD adalah sebagai alat bantu untuk merancang produk bagi perencana atau perancang dalam waktu yang relatif singkat dengan tingkat keakurasian yang tinggi.

H. PUNCH SOFTWARE

 

Self-berjudul Amerika # ini 1 Home & Landscape De tanda Software adalah sebuah aplikasi yang menggabungkan kekuatan NexGen dengan kualitas fotografi yang menakjubkan realistis dari LightWorks yang akan memungkinkan arsitek atau desainer untuk menghasilkan desain hunian yang realistis dan besar pada mereka sendiri atau untuk klien mereka. Mereka memiliki paket yang dapat memenuhi kebutuhan arsitek ‘ketika datang ke desain. Perangkat lunak ini kompatibel dengan Windows dan meskipun pricy, selalu dapat menghasilkan hasil yang bagus

I.  CHIEF ARCHITECT

Chief Arsitek diciptakan untuk pasar Home Design Software profesional dan merupakan objek berbasis 3D pertama sistem CAD dengan prinsip desain objek cerdas; dikenal sebagai Gedung Informasi Modeling (BIM).

Ini adalah perangkat lunak desain profesional yang dapat membantu menghasilkan desain 3 dimensi. Hal ini alat otomatis yang dapat membuat desain rumah dan renovasi mudah. Ini adalah perangkat lunak yang paling arsitek memilih untuk menggunakan dalam desain arsitektur 2D atau 3D karena mudah digunakan dan masih bisa memberikan hasil yang mereka inginkan.

Premier Chief Arsitek adalah untuk semua aspek desain komersial residensial dan ringan. Powerfull membangun dan merancang alat membantu para profesional desain cepat membuat rencana sesuai dengan praktek bangunan standar. Setiap elemen ditempatkan dalam rencana telah umum digunakan default untuk membuat proses desain yang efisien dan produktif. Ketika Anda menggambar dinding, program secara otomatis membuat model 3D dan menghasilkan Daftar Bahan. Ada alat Gedung kuat Otomatis dan Manual untuk menghasilkan Dokumen Konstruksi dengan Rencana Situs, Rencana Lantai, Rencana Framing, Rencana Listrik / HVAC, Rincian Bagian, dan Ketinggian. Akhirnya, Chief Arsitek termasuk alat desain untuk foto-realistis rendering, rendering Artistik dan Tur Virtual untuk membantu klien memvisualisasikan desain Anda.

J. ArchiCAD

ArchiCAD adalah software yang diciptakan oleh Grafisoft pada tahun 1982. Hingga sekarang, ArchiCAD telah mengembangkan diri secara luarbiasa sehingga software ini sangat populer di dunia arsitektur. Di Indonesia pun sudah cukup banyak pengguna ArchiCAD, indikasinya bisa di lihat dari didirikannya Grafisoft Center Indonesia (sekitar tahun 2009 – maaf kalau salah), yang mana kegiatannya difokuskan pada pelatihan (sertifikasi internasional!) dan bekerjasama dengan berbagai perguruan tinggi Indonesia dalam penggunaan ArchiCAD (kalau di Bandung mereka bekerjasama dengan ITENAS dan UNLA – sekali lagi, maaf kalau salah, saya cuma baca di internet J ).

ArchiCAD menjadi software yang sangat mudah digunakan dalam perancangan arsitektur dibandingkan software CAD umum. Jadi jika Anda ingin menggambar atau merancang rumah, ada baiknya Anda mempertimbangkan untuk mempelajari dan menggunakan ArchiCAD, ada banyak kemudahan yang dapat Anda peroleh dibandingkan jika Anda menggunakan software CAD umum seperti AutoCAD, SketchUp, Solidworks dan lain-lain, karena dengan software CAD umum setiap obyek harus benar-benar dibuat dari nol, dan walaupun bisa menggunakan library, kita tetap akan disulitkan bila kita menginginkan customized object. Permasalahan itu terjawab pada ArchiCAD dengan komponen dan library-nya yang berbasis parametric object. Dengan obyek yang memiliki parameter, dengan mudah kita mengubah detail ukuran sesuai dengan kebutuhan dengan cara yang sangat mudah (bagi yang menguasai Solidworks pasti memahami arti dari parametric object). Konsep parametric object ini sangat bermanfaat ketika kita melakukan proses modifikasi desain, contohnya: apabila kita hendak menggeser posisi pintu atau mengubah ukuran jendela yang telah terpasang pada dinding, maka lubang pada dinding akan secara ostomastis ikut bergeser dan berubah ukuran tanpa ada tambahan perintah. Tentu hal ini tidak bisa dilakukan dengan software AutoCAD dan software CAD umum lainnya.

K.  3D STUIDIO MAX

3D Studio Max atau biasa dikenal dengan 3D Max adalah suatu software (Perangkat lunak) untuk membuat sebuah grafik vektor 3 dimensi dan animasi. ditulis oleh Autodesk Media & Entertainment, dulunya dikenal sebagai Discreet and Kinetix. 3D Studio Max dikembangkan dari pendahulunya yaitu 3D Studio for DOS, tetapi untuk platform Win32.

Kinetix kemudian bergabung dengan akuisisi terakhir Autodesk, Discreet Logic. Yang sampai saat penulis membuat artikel ini yang terbaru adalah 3D Studio Max versi 9. Para desain grafis banyak menggunakan software ini digunakan untuk membuat sebuah film animasi, arsitektur rumah, ataupun membuat logo suatu perusahaan.

sumber

[ Mengubah: Wednesday, 9 November 2016, 16:21 ]
 
Gambar dari MOHAMMAD NAZIR ARIFIN 5116201014
by MOHAMMAD NAZIR ARIFIN 5116201014 - Wednesday, 9 November 2016, 15:33
Anyone in the world

"Hello World" adalah program komputer sederhana yang hanya menghasilkan output atau tampilan "Hello World!" pada pengguna program. Hampir semua tutorial bahasa pemograman dimulai dengan pembuatan aplikasi sederhana ini. Hal ini biasanya berhubungan dengan cara menggunakan sintaks bahasa pemograman tersebut.

 
Anyone in the world

Someone must resolve conflicting requirements from different user classes, reconcile inconsistencies, and arbitrate questions of scope that arise. The product champions or product owner can handle this in many, but likely not all, cases. Early in the project, determine who the decision makers will be for requirements issues. If it’s not clear who is responsible for making these decisions or if the authorized individuals abdicate their responsibilities, the decisions will fall to the developers or analysts by default. Most of them don’t have the necessary knowledge and perspective to make the best business decisions, though. Analysts sometimes defer to the loudest voice they hear or to the person highest on the food chain. Though understandable, this is not the best strategy. Decisions should be made as low in the organization’s hierarchy as possible by well-informed people who are close to the issues.

[ Mengubah: Wednesday, 9 November 2016, 12:26 ]
 
Gambar dari PASCAL MANIRIHO 5116201701
by PASCAL MANIRIHO 5116201701 - Wednesday, 9 November 2016, 11:59
Anyone in the world

A software life cycle model (also called process model) is a descriptive and diagrammatic 

representation of the software life cycle. A life cycle model represents all the activities required to make a software product transit through its life cycle phases. It also captures the order in which these activities are to be undertaken. In other words, a life cycle model maps the different activities performed on a software product from its inception to retirement. Different life cycle models may map the basic development activities to phases in different ways. Thus, no matter which life cycle model is followed, the basic activities are included in all life cycle models though the activities may be carried out.in different orders in different life cycle models.During any life cycle phase, more than one activity may also be carried out .

Need for Software  life cycle model

The development team must identify a suitable life cycle model for the particular project and then adhere to it. Without using of a particular life cycle model the development of a software product would not be in a systematic and disciplined manner. When a software product is being developed by a team there must be a clear understanding among team members about when and what to do. Otherwise it would lead to chaos and project failure. This problem can be illustrated by using an example. Suppose a software development problem is divided into several parts and the parts are assigned to the team members. From then on, suppose the team members are allowed the freedom to develop the parts assigned to them in whatever way they like. It is possible that one member might start writing the code for his part, another might decide to 

prepare the test documents first, and some other engineer might begin with the design phase of the parts assigned to him. This would be one of the perfect recipes for project failure. A software life cycle model defines entry and exit criteria for every phase. A phase can start only if its phase-entry criteria have been satisfied. So without software life cycle model the entry and exit criteria for a phase cannot be recognized. Without software life cycle models it becomes difficult for software project managers to monitor the progress of the project.

Different software life cycle models

Many life cycle models have been proposed so far. Each of them has some advantages as well as some disadvantages. A few important and commonly used life cycle models are as follows:

  • Classical Waterfall Model
  • Iterative Waterfall Model 
  • Prototyping Model
  • Evolutionary Model
  • Spiral Model

 

[ Mengubah: Wednesday, 9 November 2016, 12:18 ]
 
Gambar dari PASCAL MANIRIHO 5116201701
by PASCAL MANIRIHO 5116201701 - Wednesday, 9 November 2016, 11:37
Anyone in the world

When a software program is modularized, its tasks are divided into several modules based on some characteristics. As we know, modules are set of instructions put together in order to achieve some tasks. They are though, considered as single entity but may refer to each other to work together. There are measures by which the quality of a design of modules and their interaction among them can be measured. These measures are called coupling and cohesion.

Cohesion
Cohesion is a measure that defines the degree of intra-dependability within elements of a module. The greater the cohesion, the better is the program design.

There are seven types of cohesion, namely

  • Co-incidental cohesion - It is unplanned and random cohesion, which might be the result of breaking the program into smaller modules for the sake of modularization. Because it is unplanned, it may serve confusion to the programmers and is generally not accepted.
  •  Logical cohesion - When logically categorized elements are put together into a module it is called logical cohesion.
  • Temporal Cohesion - When elements of module are organized such that they are processed at a similar point in time, it is called temporal cohesion.
  • Procedural cohesion - When elements of module are grouped together, which are executed sequentially in order to perform a task, it is called procedural cohesion.
  • Communicational cohesion - When elements of module are grouped together, which are executed sequentially and work on same data (information), it is called communicational cohesion.
  •  Sequential cohesion - When elements of module are grouped because the output of one element serves as input to another and so on, it is called sequential cohesion.
  •  Functional cohesion - It is considered to be the highest degree of cohesion, and it is highly expected. Elements of module in functional cohesion are grouped because they all contribute to a single well-defined function. It can also be reused.

Coupling

Coupling is a measure that defines the level of inter-dependability among modules of a
program. It tells at what level the modules interfere and interact with each other. The lower the coupling, the better the program.

There are five levels of coupling, namely:

  • Content coupling - When a module can directly access or modify or refer to the content of another module, it is called content level coupling.
  • Common coupling- When multiple modules have read and write access to some global data, it is called common or global coupling.
  • Control coupling- Two modules are called control-coupled if one of them decides the function of the other module or changes its flow of execution.
  • Stamp coupling- When multiple modules share common data structure and work on different part of it, it is called stamp coupling.
  •  Data coupling- Data coupling is when two modules interact with each other by means of passing data (as parameter). If a module passes data structure as parameter, then the receiving module should use all its components.

Ideally, no coupling is considered to be the best.

[ Mengubah: Wednesday, 9 November 2016, 12:20 ]
 
Gambar dari HENDRO EKO PRABOWO 5116201006
by HENDRO EKO PRABOWO 5116201006 - Wednesday, 9 November 2016, 11:31
Anyone in the world

Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the systems after it has gone into use. In this definition , there are two key phrases:

1. Engineering discipline

Engineering make things work. They apply theories, methods, and tools where these are appropriate. However, they use them selectively and always try to discover solution to problems even when there are no applicable theories and methods. Engineers also recognize that they must work to organizational and financial constraints so they look for solutions within these constrains

2. All aspects of software production

Software engineering is not just concerned with the technical processes of the software development. It also includes activities such as software project management and the development of tools, methods, and theories to support software production.

 

Engineering is about getting result of the required quality within the schedule and budget. This often involves making compromises-engineers cannot be perfectionists. People writing programs for themselves, however, can spend as much time as they wish on the program development.

[ Mengubah: Wednesday, 9 November 2016, 11:32 ]
 
Anyone in the world

Requirement adalah gambaran dari layanan (services) dan batasan bagi system yang akan dibangun. Atau requirement adalah pernyataan/gambaran pelayanan yang disediakan oleh system, batasan - batasan dari system dan bisa juga berupa definisi matematis fungsi - fungsi system.

 
Gambar dari PASCAL MANIRIHO 5116201701
by PASCAL MANIRIHO 5116201701 - Wednesday, 9 November 2016, 11:25
Anyone in the world

Back in time, all softwares were meant to be executed sequentially. By sequential execution we mean that the coded instruction will be executed one after another implying only one portion of program being activated at any given time. Say, a software has multiple modules, then only one of all the modules can be found active at any time of execution.

In software design, concurrency is implemented by splitting the software into multiple independent units of execution, like modules and executing them in parallel. In other words, concurrency provides capability to the software to execute more than one part of code in parallel to each other.

It is necessary for the programmers and designers to recognize those modules, which can be made parallel execution.

The spell check feature in word processor is a module of software, which runs alongside the word processor itself.

 

 

 

[ Mengubah: Wednesday, 9 November 2016, 12:28 ]
 
Halaman: () 1 ... 39 40 41 42 43 44 45 46 ()