Site blog

Halaman: () 1 ... 33 34 35 36 37 38 39 40 41 ()
Gambar dari MEIDA CAHYO UNTORO 5116201059
by MEIDA CAHYO UNTORO 5116201059 - Thursday, 10 November 2016, 20:24
Anyone in the world

Model Sekuensial Linier atau Waterfall Development Model

Model Sekuensial Linier atau sering disebut Model Pengembangan Air Terjun, merupakan paradigma model pengembangan perangkat lunak paling tua, dan paling banyak dipakai. Model ini mengusulkan sebuah pendekatan perkembangan perangkat lunak yang sistematik dan sekunsial yang dimulai pada tingkat dan kemajuan sistem pada seluruh tahapan analisis, desain , kode, pengujian, dan pemeliharaan.

software-development-life-cycle.png 

Berikut Merupakan Tahapan – tahapan Pengembangan  Model Sekuensial Linear / Waterfall Development Model :

  • Rekayasa dan pemodelan sistem/informasi

Langkah pertama dimulai dengan membangun keseluruhan elemen sistem dan memilah bagian-bagian mana yang akan dijadikan bahan pengembangan perangkat lunak, dengan memperhatikan hubungannya dengan Hardware, User, dan Database.

  • Analisis kebutuhan perangkat lunak

Pada proses ini, dilakukan penganalisaan dan pengumpulan kebutuhan sistem yang meliputi Domain informasi, fungsi yang dibutuhkan unjuk kerja/performansi dan antarmuka.  Hasil penganalisaan dan pengumpulan tersebut didokumentasikan dan diperlihatkan kembali kepada pelanggan.

  • Desain

Pada proses Desain, dilakukan penerjemahan syarat kebutuhan sebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuatnya proses pengkodean (coding). Proses ini berfokus pada  struktur data, arsitektur perangkat lunak, representasi interface, dan detail algoritma prosedural.

  • Pengkodean (Development)

Pengkodean merupakan proses menterjemahkan perancangan desain ke bentuk yang dapat dimengerti oleh mesin, dengan menggunakan bahasa pemrograman.

  • Pengujian (Test)

Setelah Proses Pengkodean selesai, dilanjutkan dengan proses pengujian pada program perangkat lunak, baik Pengujian logika internal, maupun Pengujian eksternal fungsional untuk memeriksa segala kemungkinan terjadinya kesalahan dan memeriksa apakah hasil dari pengembangan tersebut sesuai dengan hasil yang diinginkan.

  • Pemeliharaan (Maintenance)

Proses Pemeliharaan erupakan bagian paling akhir dari siklus pengembangan dan dilakukan setelah perangkat lunak dipergunakan. Kegiatan yang dilakukan pada proses pemeliharaan antara lain :

  • Corrective Maintenance : yaitu mengoreksi apabila terdapat kesalahan pada perangkat lunak, yang baru terdeteksi pada saat perangkat lunak dipergunakan.
  • Adaptive Maintenance : yaitu dilakukannya penyesuaian/perubahan sesuai dengan lingkungan yang baru, misalnya hardware, periperal, sistem operasi baru, atau sebagai tuntutan atas perkembangan sistem komputer, misalnya penambahan driver, dll.

Perfektive Maintenance : Bila perangkat lunak sukses dipergunakan oleh pemakai. Pemeliharaan ditujukan untuk menambah kemampuannya seperti memberikan fungsi-fungsi tambahan, peningkatan kinerja dan sebagainya.

 

Referensi

McLeod Jr. P, GP Schell. 2007. Sistem Informasi Manajemen. Edisi ke-9. Yuliyanto dan Heri, penerjemah: Jakarta: Indeks. Terjemahan dari: Management Information System, Edisi ke-8. Pearson Prentice Hall, Inc.

[ Mengubah: Thursday, 10 November 2016, 20:52 ]
 
Gambar dari ROZITA 5116201037
by ROZITA 5116201037 - Thursday, 10 November 2016, 11:24
Anyone in the world
Saat ini, perangkat lunak memiliki dua peran. Di satu sisi berfungsi sebagai sebuah produk, dan di sisi lain sebagai kendaraan yang mengantarkan sebuah produk. Sebagai produk, perangkat lunak mengantarkan potensi penghitungan yang dibangun oleh perangkat lunak komputer.
Sebagai kendaraan yang dipakai untuk mengantarkan produk perangkat lunak berlaku sebagai dasar untuk kontrol komputer (sistem operasi), komunikasi informasi (jaringan) dan penciptaan serta kontrol dari program-program lain (peranti dan lingkungan perangkat lunak).
 
 
Definisi Perangkat Lunak (PL)
IEEE-Standar Glossary of Software Engineering Terminology, 1990:
“Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.”
Maksudnya :
Perangkat lunak merupakan kumpulan dari program, prosedur, dan dokumen data lain yang saling berhubungan yang merepresentasikan masalah di dunia nyata yang
dikonfigurasikan dalam sebuah bentuk aplikasi yang harus dikerjakan komputer.
 
 
Definisi Rekayasa Perangkat Lunak (RPL)
RPL atau Software Engineering (SE) _ Disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah digunakan. Perangkat Lunak yang dibuat harus mampu:
  1. Tepat waktu
  2. Tepat anggaran
  3. Meningkatkan kinerja
  4. Mengoperasikan prosedur sistem dengan benar
 
Karakteristik Perangkat Lunak
Perangkat lunak lebih merupakan elemen logika dan bukan merupakan elemen sistem fisik. Dengan demikian, perangkat lunak memiliki ciri yang berbeda dari perangkat keras :
  1. Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam bentuk yang klasik (pabrikasi). Biaya untuk perangkat lunak dikonsentrasikan kepada pengembangan. Hal ini berarti proyek perangkat lunak tidak dapat diatur seperti pengaturan proyek-proyek pemanufakturan.
  2. Perangkat lunak tidak pernah usang. Perangkat lunak tidak rentan terhadap pengaruh lingkungan yang merusak yang menyebabkan perangkat keras menjadi usang. Selama hidupnya, perangkat lunak mengalami perubahan (pemeliharaan). Aspek lain dari keusangan menggambarkan perbedaan antara perangkat keras dan perangkat lunak. Bila komponen suatu perangkat keras telah usang, komponen dapat diganti dengan suku cadangnya. Namun tidak ada suku cadang bagi perangkat lunak. Setiap kegagalan perangkat lunak menggambarkan kesalahan dalam perancangan atau proses di mana rancangan diterjemahkan ke dalam kode mesin yang dapat dieksekusi.
  3. Sebagian besar perangkat lunak dibuat secara custom-built, serta tidak dapat dirakit dari komponen yang sudah ada. Perhatikan bagaimana perangkat keras untuk produksi berbasis mikroprosesor dirancang dan dibuat. Setelah masing-masing komponen diseleksi, perangkat keras dapat dipesan secara terpisah. Sementara pada perangkat lunak, tidak katalog komponen perangkat lunak. Memang memungkinkan untuk memesan perangkat lunak secara terpisah, tetapi tetap merupakan satu kesatuan yang lengkap, bukan sebagai komponen yang dapat dipasangkan ke dalam program-program yang baru.
 
 
Bentuk produk perangkat lunak:
1. Produk Generik (Umum)
Sistem stand-alone standar yang diproduksi oleh organisasi pengembang dan dijual ke pasar terbuka ke siapapun yg membelinya. Biasa disebut sebagai software shrink-wrapped.
Contoh : pengolah kata (word processor).
2. Produk pesanan (yang disesuaikan)
Sistem yang dipesan oleh pelanggan tertentu. Dikembangkan khusus bagi pelanggan oleh kontraktor perangkat lunak. Contoh : Sistem untuk mendukung proses bisnis tertentu dan sistem kontrol lalu lintas udara.
 
Perbedaan PENTING antara 2 bentuk perangkat lunak :
  •  Pada produk generik, organisasi yang mengembangkan perangkat lunak mengontrol spesifikasi perangkat lunak.
  •  Pada produk pesanan, spesifikasi biasanya dikembangkan dan dikontrol oleh organisasi yang membeli perangkat lunak tersebut.
 
Karakteristik perangkat lunak yang baik:
  •  Mempunyai daya guna yang tinggi (usability)
  •  Mempunyai kinerja sesuai fungsi yang dibutuhkan pemakai
  •  Mampu diandalkan (be reliable)
  •  Mudah dirawat/diperbaiki (maintenability)
  •  Lebih efisien
  •  Mempunyai antarmuka yg menarik (eye cathcing user interface)
  •  Mempunyai siklus hidup yang cukup lama (long life time)
Aplikasi Perangkat Lunak
Perangkat lunak dapat diaplikasikan ke berbagai situasi di mana serangkaian langkah prosedural (seperti algoritma) telah didefinisikan.
 
 
Perangkat Lunak Sistem. Perangkat lunak sistem merupakan sekumpulan program yang ditulis untuk melayani program-program yang lain. Banyak perangkat lunak sistem (misal kompiler, editor, dan utilitas pengatur file) memproses struktur-struktur informasi yang lengkap namun tetap. Perangkat lunak sistem ditandai dengan eratnya interaksi dengan perangkat keras komputer.
 
Perangkat Lunak Real-Time. Program-program yang memonitor/menganalisis kejadian dunia nyata pada saat terjadinya disebut perangkat lunak real-time. Elemen-elemen perangkat lunak real-time mencakup komponen pengumpul data yang mengumpulkan dan memformat informasi dari lingkungan eksternal, sebuah komponen analisis yang mentransformasi informasi pada saat dibutuhkan oleh aplikasi, sebuah komponen kontrol/output yang memberi respon kepada lingkungan eksternal, serta sebuah komponen monitor yang mengkoordinasi semua komponen lain agar respon real-timenya (I milidetik sampai 1 menit) dapat tetap terjaga. Perlu dicatat di sini bahwa real-time berbeda dengan interaksi atau timesharing. Sistem real-time harus merespon di dalam suatu rentang waktu yang tetap. Waktu respon sebuah sistem interaktif (timesharing) secara normal dapat diperpanjang tanpa memberikan risiko kerusakan pada hasil.
 
Perangkat Lunak Bisnis. Sistem diskrit (contohnya payroll, account receivable/payable, inventory) telah mengembangkan perangkat lunak sistem informasi manajemen (MIS) yang mengakses satu atau lebih database besar yang berisi informasi bisnis. Aplikasi perangkat lunak bisnis juga meliputi penghitungan klien/server serta penghitungan interaktif (misal pemrosesan transaksi point-of-sale).
 
 Perangkat Lunak Teknik dan Ilmu Pengetahuan. Perangkat lunak teknik dan ilmu pengetahuan ditandai algoritma number crunching. Perangkat lunak ini memiliki jangkauan aplikasi mulai dari astronomi sampai vulkanologi, dari analisis otomotif sampai dinamika orbit pesawat ruang angkasa, dan dari biologi molekuler sampai pabrik yang sudah diotomatisasi. Computer-aided design, simulasi sistem, dan aplikasi interaktif yang lain, sudah mulai memakai ciri-ciri perangkat lunak sistem genap dan real-time.
 
Embedded Software. Embedded software ada dalam read-only memory dan dipakai untuk mengontrol hasil serta sistem untuk keperluan konsumen dan pasar industri. Embedded software dapat melakukan fungsi yang terbatas serta fungsi esoterik (misal key pad control untuk microwave) atau memberikan kemampuan kontrol dan fungsi yang penting (contohnya fungsi dijital dalam sebuah automobil seperti kontrol bahan bakar, penampilan dash-board, sistem rem, dll).
 
Perangkat Lunak Komputer Personal. Pengolah kata, spreadsheet, grafik komputer, multimedia, hiburan, manajemen database, aplikasi keuangan, bisnis dan personal, jaringan eksternal atau akses database hanya merupakan beberapa saja dari ratusan aplikasi yang ada.
 
Perangkat Lunak Kecerdasan Buatan. Perangkat lunak kecerdasan buatan (Artificial Inteligent /AI) menggunakan algoritma non-numeris untuk memecahkan masalah kompleks yang tidak sesuai untuk perhitungan atau analisis secara langsung. Perangkat lunak kecerdasan buatan adalah pengenalan pola (image dan voice), pembuktian teorema, dan permainan game. Di tahun-tahun terakhir, cabang perangkat lunak kecerdasan buatan yang baru, yang disebut artificial neural network, telah berkembang. Jaringan syaraf mensimulasi struktur proses-proses otak dan kemudian membawanya kepada perangkat lunak kelas baru yang dapat mengenali pola-pola yang kompleks serta belajar dari pengalaman-pengalaman masa lalu.
 
Sumber : http://bokdimal.blogspot.co.id/2013/03/produk.html
 
Anyone in the world

 

  1. Introduction

          The estimated cost of software is one of the main problems and very important in the management and development of software projects to help software companies make a good management when developing software. In addition, one sign of good management of software development tends precise in estimating costs and software resources. 1-3It can handle both overestimates and underestimates the software effort and costs. Methods to estimate the cost of software has been introduced by the software industry. 4Among all the methods to estimate software costs, Constructive Cost model (COCOMO) is the most famous and widely used to calculate the cost of the software. 5In 2000, Barry Boehm introduced COCOMO II has proven to be more accurate with some improvement in some of the cost drivers. In addition to using COCOMO II, this paper also uses Fuzzy Logic Model. Basically, fuzzy logic is the logic of rights imprecision and approximate reasoning. More specifically, fuzzy logic can be seen as an attempt formalization / mechanization two remarkable human ability. 1,6Some of the advantages of fuzzy logic is: First, the ability to communicate, reason and make rational decisions in an environment of imprecision, uncertainty, incompleteness of information, conflicting information, the truth alignments and alignments of possibilities - in short, in an environment of imperfect information. Second, the ability to perform a variety of physical and mental tasks without any measurements and calculations. 6In another study, Triangular membership functions have been used to improve the accuracy of estimates from COCOMO II effort. Thus, this paper uses Trapezoidal Membership Function (TMF) to achieve better accuracy and a smooth transition in membership functions. By applying the TMF in COCOMO II cost drivers, the results are expected to be closer to the actual effort as well as the resulting error is getting less.

 2. Experimental Details

           Poor estimates not only lead the project over budget and schedule, but also entirely stopped. The ability to accurately estimate software development time, cost and labor, the change as newer methodology replaces the old one. Therefore, the software cost estimation model that is accurate is indispensable in project management software. This research is trying to learn every effort multipliers in COCOMO II. Every effort multiplier ( EM ) using linguistic values to represent each character EM. From the linguistic values ranging from Vey Low to Extra High, this study divides the two categories such as EM to EM qualitative and quantitative. Qualitative effort multiplier is DEPEND, Cplx, Doc, guile, PVOL, PCON, EQUIPMENT, SITE and other business that quantitative multiplier. Fuzzy models used to redesign EM quantitative descriptions can be translated into Fuzzy Logic. The difference for each level is the percentage of execution time available. This study uses a trapezoidal Membership Function ( TMF ) to Fuzzy Logic. TMF create a smooth transition from one level to another. Fuzzy Logic implemented using fuzzy logic tool box in MATLAB software. There are several types of Fuzzy Logic as Gaussian Membership Function, Triangular Membership Functions, Trapezoidal Membership Function and others in the tool box. The tool box is named as Editor Fuzzy Inference System ( FIS ). This FIS Editor GUI helps us to make the input and output with the range and number of membership functions we need. FIS Editor allows us to create rules from input to output. In this study, the following rules will look like this, R1 : IF Input DATA is low THEN Output data is decreased, R2 : IF Input DATA is nominal THEN Output data is unchanged. Cost estimate method proposed in this paper uses fuzzy logic tool box MATLAB software. Fuzzy Systems ( FIS ) used to implement various processing steps. The options available for creating and editing FIS with fuzzy logic software tool box using a graphical tool. This GUI tools helps to edit high-level features such as the number of input and output variables of the FIS. By using FIS editor, the membership function can be added to each of the cost drivers use the command ‘addmf’. Each driver in the hazy COCOMO can be defined by membership functions. Membership function editor by mfedit which allows us to examine and modify all membership function we can change the name, type and parameters.  7Proposed method redesign effort Multiplier by studying the behavior of COCOMO II. Trapezoidal membership functions is defined as follows :

f(x,a,b,c,d) = 0                                     when x < a and x > d

                = (x-a) / (b-a)                       when a <= x <= b

                = 1                                     when b <= x <= c

                = (d-x) / (d-c)                       when c <= x <= d

Click on the variable boxes to select a variable to edit. The box is highlighted in red and the Current Variable field displays the default settings of the selected variable. Double-click one of the variables to open the Membership Function Editor. Double-click the fuzzy rule processor to open the Rule Editor. If a variable exists but is not mentioned in the rule base, it is connected to the rule processor block with a dashed line. The value of TMF is taken from the value of every level in DATA EM. For example, low level has value of <10 so it draw the decreased interval to <10. After creating input and output to TMF, it set the rules based on rules that have been stated before. Then the new value of each level is resulted. Apply this to other qualitative EM. This paper try to improve accuracy to fuzzifying COCOMO II cost drivers which is includes a set of input software attributes : 17 Effort Multipliers ( Ems ), 5 Scale Factors ( SFs ), one size in KLOC ( SZ ). Study the behavior of COCOMO II cost drivers, then proposed to characterize the use of Trapezoidal Membership Function ( TMF ) for cost drivers to represent the linguistic values. The experimental result shows a more accurate effort estimation rather than COCOMO II and Gaussian Membership Function ( GMF ). These are the steps to calculate new set of weight and to improve error : First, inputs, there are three set of inputs ( size in KLOC, 17 Effort Multipliers ), 5 scale factors. Second, fuzzification, divided into three sub modules, SZ-Fuzzifications, SF-Fuzzifications, EM-Fuzzifications. The terms very low, low, nominal, high, very high and extra high. Third, inference engine, operates on a set of fuzzy rules. The fuzzy model rules contain the linguistic variables related to the project. Implemented this model using FIS tool in MATLAB. Fourth, defuzzification, calculates and converts the fuzzy output into crisp data form.

3. Results and Discussion

         Presents the result achieved by applying the proposed fuzzy model with Turkish Software Industry dataset consists of 17 projects and 5 different software companies it consists of 24 attributes. The attributes is divided into four categories such as seven attributes describe the project, fifteen attributes show COCOMO II Effort Multiplier in the range from Very Low to Extra High, kilo line of code ( KLOC ), and actual effort in person months. This research tries to compare the accuracy of the estimated effort with actual effort. To evaluate the accuracy of estimated effort, it use most common criteria such as Magnitude Relative Error ( MRE ) and Mean Magnitude Relative Error ( MMRE ), which is defined as . The MRE values are calculated for each project, while mean magnitude relative error computed the average of MRE from N projects. Which defined . The smaller value of MMRE is the closer to actual effort. For example, Project ID 4 by using COCOMO II Model 1032.58 % error by using Gaussian membership Function 1032.58 %, by using proposed method 1022.73 %. It means this proposed model can reduce 98.5 % error from COCOMO II Model and Gaussian Membership Function. And also for MMRE value in COCOMO II Model 733.14 %, by using Gaussian is 717.67 %, by using Trapezoidal is 716.85 %

4. Conclusion

          In conclusion, Fuzzy Logic is used to improve the accuracy of COCOMO II models and proposed model use Turkish Software Industry dataset. It has been found that the trapezoid function works better than COCOMO II and Gaussian function, it shows a smooth transition in the interval, the results are closer to the actual effort. The value of proposed method shows smaller than the MRE or MMRE is closer to the actual effort. MMRE had a 733.14% by using COCOMO II, using Gaussian 717.67%, 716.85% by using a trapezoid. The proposed method can reduce 16.29 % from the previous method.

 

Acknowledgments

        The authors would like to express heartfelt thanks to the Prof.Drs.Ec.Ir.Riyanarto Sarno,M.Sc.,Ph.D., Daniel Oranova Siahaan,S.Kom.,M.Sc.,PDEng, Adhatus Solichah Ahmadiyah S.Kom,M.Sc., Dr.Ir. Siti Rochimah,MT. for their helpful discussions.

 

References and Notes

1.   R.Sarno,J.Sidabutar,Sarwosri, “Improving the Accuracy of COCOMO’s Effort Estimation Based on Neural Networks and Fuzzy Logic Model,” Int. Conf. Information, Commun. Technol. Syst., pp. 197–202, (2015).

2. R.Sarno, J.Sidabutar,Sarwosri, "Comparison of different Neural Network architectures for software cost estimation,"Int.Conf.Compt.Control.Informatics Its Appl., pp. 68-73 (2015).

3. S.Waghmode, Dr. K. Kolhe, “A novel way of cost estimation in software development based on clustering techniques”, International Journal of Innovative Research in Computer and Communication Engineering, vol.2,Issue 4 (2014).

4. B.Boehm,Software Engineering Economics, New Jersey,USA: Prentice-Hall,Englewood Cliffs (1994).

5. L.Zadeh,”A new direction in AI-toward a compational theory of perceptions,”AI Magasine,pp.73-84 (2011).

6. V. Chandra, "Software effort estimation: a fuzzy logic approach," International Journal of Computer Applications, vol. 103, pp. 39-43 (2014).

7. Ziauddin, S.Kamal,S.Khan,J.A.Nasir,”A fuzzy logic based software cost estimation  model”,International Journal of Software Engineering and Its Applications,vol.7, no.2 (2013).

Table caption

Table 1.  Comparison of effort estimation result in MRE and MMRE

Project ID

MRE(%) using COCOMO II Model

MRE(%) using Gaussian Membership Function

MRE(%) using  Trapezoidal Membership Function

1

190,67

190,67

190,67

2

42,84

44,54

44,54

3

106,76

100,95

100,95

4

1032,58

1032,58

1022,73

5

1478,89

1475,73

1457,73

6

26,05

31,12

31,12

7

14,43

20,45

20,45

8

2841,79

2696,16

2696,16

9

1553,36

1539,47

1539,47

10

1499,90

1472,90

1472,90

11

0,07608

3,90

3,90

12

0,02745

3,56

3,56

MMRE(%)

733,14

717,67

716,85

 

 

 

 

 

 

[ Mengubah: Thursday, 10 November 2016, 22:10 ]
 
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 ]
 
Halaman: () 1 ... 33 34 35 36 37 38 39 40 41 ()