Site blog

Page: () 1 ... 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 ... 45 ()
Anyone in the world

Mark Zukerberg's challenge for 2016 was to build a simple AI to run his home -- like Jarvis in Iron Man. His goal was to learn about the state of artificial intelligence -- where we're further along than people realize and where we're still a long ways off. These challenges always lead me to learn more than he expected, and this one also gave me a better sense of all the internal technology Facebook engineers get to use, as well as a thorough overview of home automation.
So far this year, he has built a simple AI that he can talk to on his phone and computer, that can control his home, including lights, temperature, appliances, music and security, that learns his tastes and patterns, that can learn new words and concepts, and that can even entertain Max. It uses several artificial intelligence techniques, including natural language processing, speech recognition, face recognition, and reinforcement learning, written in Python, PHP and Objective C. In this note, he'll explain what he built and what he learned along the way.


  • Getting Started: Connecting the Home

In some ways, this challenge was easier than he expected. In fact, my running challenge (I also set out to run 365 miles in 2016) took more total time. But one aspect that was much more complicated than he expected was simply connecting and communicating with all of the different systems in my home.
Before he could build any AI, he first needed to write code to connect these systems, which all speak different languages and protocols. We use a Crestron system with our lights, thermostat and doors, a Sonos system with Spotify for music, a Samsung TV, a Nest cam for Max, and of course my work is connected to Facebook's systems. he had to reverse engineer APIs for some of these to even get to the point where he could issue a command from my computer to turn the lights on or get a song to play.
Further, most appliances aren't even connected to the internet yet. It's possible to control some of these using internet-connected power switches that let you turn the power on and off remotely. But often that isn't enough. For example, one thing he learned is it's hard to find a toaster that will let you push the bread down while it's powered off so you can automatically start toasting when the power goes on. he ended up finding an old toaster from the 1950s and rigging it up with a connected switch. Similarly, he found that connecting a food dispenser for Beast or a grey t-shirt cannon would require hardware modifications to work.
For assistants like Jarvis to be able to control everything in homes for more people, we need more devices to be connected and the industry needs to develop common APIs and standards for the devices to talk to each other

  • natural language

This was a two step process: first he made it so he could communicate using text messages, and later he added the ability to speak and have it translate my speech into text for it to read.
It started simple by looking for keywords, like "bedroom", "lights", and "on" to determine he was telling it to turn the lights on in the bedroom. It quickly became clear that it needed to learn synonyms, like that "family room" and "living room" mean the same thing in our home. This meant building a way to teach it new words and concepts.

  • Vision and Face Recognition

Even though he think text will be more important for communicating with AIs than people realize, he still think voice will play a very important role too. The most useful aspect of voice is that it's very fast. You don't need to take out your phone, open an app, and start typing -- you just speak.
To enable voice for Jarvis, he needed to build a dedicated Jarvis app that could listen continuously to what he say. The Messenger bot is great for many things, but the friction for using speech is way too much. My dedicated Jarvis app lets me put my phone on a desk and just have it listen. he could also put a number of phones with the Jarvis app around my home so he could talk to Jarvis in any room. That seems similar to Amazon's vision with Echo, but in my experience, it's surprising how frequently he want to communicate with Jarvis when I'm not home, so having the phone be the primary interface rather than a home device seems critical.


  • Facebook Engineering Environtment

As the CEO of Facebook, he don't get much time to write code in our internal environment. he has never stopped coding, but these days he mostly build personal projects like Jarvis. he expected he'd learn a lot about the state of AI this year, but he didn't realize he would also learn so much about what it's like to be an engineer at Facebook. And it's impressive.
My experience of ramping up in the Facebook codebase is probably pretty similar to what most new engineers here go through. he was consistently impressed by how well organized our code is, and how easy it was to find what you're looking for -- whether it's related to face recognition, speech recognition, the Messenger Bot Framework [] or iOS development. The open source Nuclide [] packages he ve built to work with GitHub's Atom make development much easier. The Buck [] build system he ve developed to build large projects quickly also saved me a lot of time. Our open source FastText [] AI text classification tool is also a good one to check out, and if you're interested in AI development, the whole Facebook Research [] GitHub repo is worth taking a look at.
One of our values is "move fast". That means you should be able to come here and build an app faster than you can anywhere else, including on your own. You should be able to come here and use our infra and AI tools to build things it would take you a long time to build on your own. Building internal tools that make engineering more efficient is important to any technology company, but this is something we take especially seriously. So he want to give a shout out to everyone on our infra and tools teams that make this so good.



Associated Course: KI142303BKI142303B
[ Modified: Thursday, 22 December 2016, 11:32 PM ]


    Anyone in the world

    Perbedaan QA engineer dan QA tester

    Pada beberapa perushaan startup kita kerap kali mendengar istilah QA engineer dan QA tester. Kedua jabatan tersebut sangat penting dalam menjaga kualitas perangkat lunak. Apakah perbedaan antara QA engineer dan QA tester ?

    QA Engineer

    QA engineer lebih fokus pada bagaimana proses pengembangan perangkat lunak dilakukan dengan baik daripada bagaimana hasil akhir perangkat lunak yang dihasilkan. Tugas QA engineer memastikan setiap proses pengembangan perangkat lunak berjalan dengan baik guna menjaga kualitas pengembangan perangkat lunak. Menjaga kualitas proses programming dan build/test menjadi salah satu fokus utama pada pekerjaan QA engineer.

    Beberapa tugas QA engineer adalah

    • Function – Test planning, Test Design and execution.
    • Prepare test plans, develop test cases and execute tests with a focus on coverage.
    • Engineers Quality. Good to answer – what is the quality of the product?
    • Logical thinkers. Ability to resolve issues using abstraction. Capability in analysis/predictions/improvements.
    • Can reconcile conflicting constraints.
    • Process and metrics/measurement driven.
    • Cost sensitive
    • Good for System/functionality testing
    • Best to have them involved in complete SDLC Cycle.

    QA Tester

    Berbeda dengan QA engineer, QA tester lebih berfokus kepada kualitas perangkat lunak yang digunakan. Pengujian-pengujian yang dilakukan oleh QA tester lebih fokus pada metode black-box. QA tester bertugas memastikan perangkat lunak yang di hasilkan sudah sesuai dengan keinginan user.

    Beberapa tugas QA tester antara lain

    • Function – Strong in test execution.
    • Write and execute test cases – may not be coverage driven. Requirements driven testing.
    • Determines Quality. Good to answer – did you find any bugs?
    • Linear thinkers, low capability of analysis and re-usability of efforts/resources.
    • Requires a defined environment. Typically are weak in finding solutions in ambiguous/constrained environments.
    • Low process oriented capability.
    • May not be cost sensitive (time, effort, monetary, etc.)
    • Good for UI Testing
    • Typical involvement is in later stage of SDLC

    Kesimpulan yang bisa kita ambil, untuk menjaga kualitas perangkat lunak maka dibutuhkan proses QA pada proses pembangunan perangkat lunak/SDLC dan setelah perangkat lunak jadi dan siap rilis. Untuk memenuhi kebutuhan tersebut jabatan QA dibagi menjadi QA engineer dan QA tester. Dimana QA engineer fokus pada proses SDLC dan QA tester fokus pada proses setelah SDLC atau sebelum delivery ke user. 
    karena QA engineer melakukan test pada setiap proses SDLC dibandingkan dengan QA tester yang hanya berfokus pada testing aplikasi yang sudah jadi. QA engineer memiliki beban kerja yang lebih berat, sehingga salary pun  lebih tinggi dari QA tester.

    Jadi mau pilih yang mana?, QA engineer atau QA tester?




      Picture of THIAR HASBIYA DITANAYA 5116201048
      by THIAR HASBIYA DITANAYA 5116201048 - Thursday, 22 December 2016, 11:12 PM
      Anyone in the world

      Software Framework

      Software Framework adalah sebuah abstraksi yang digunakan untuk mempermudah pembuatan perangkat lunak. Software Framework menyamakan persepsi setiap pengembang pada abstraksi yang sama. Penyamaan persepsi ini mempermudah pengembang baru untuk mengetahui keseluruhan perangkat lunak dengan lebih cepat. Paradigma yang paling populer digunakan pada software framework adalah MVC. MVC memisahkan aplikasi menjadi 3 bagian fungsionalitsa yaitu model,view, dan controller.

      Beberapa software framework yang sering digunakan adalah

      • php
        1. Laravel : full-stack web framework menggunakan paradigma MVC, memiliki fitur yang sangat lengkap dan pemodelan ORM(Object Relational Mapping) pada database
        2. CodeIgniter: full-stack web framework menggunakan paradigma MVC, memiliki fitur yang umum dan berjalan cepat dibandingkan framework php lainnya
        3. Lumen : Rest Api web framework dari Laravel. Lumen adalah versi REST API dari Laravel,lumen memiliki fitur yang lebih simpel dibandingkan Laravel
        4. Yii : full-stack web framework menggunakan paradigma MVC memiliki fitur lengkap dan beberapa scaffolding.
      • python
        • Flask : minimal web framework, digunakan untuk membangun aplikasi web atau API
        • Djanggo : full-stack web framework dengan paradigma MVC digunakan untuk membuat aplikasi web yang utuh
      • ruby
        • Ruby on Rails: Pesaing laravel, memiliki kelengkapan fitur seperti laravel dan berjalan menggunakan bahasa ruby, memiliki kelebihan pada syntax nya yang sederhana.
      • nodejs
        • Expressjs: minimal web framework yang dibangun menggunakan javascript, express dapat di desain sebagai API atau fullstack web framework.


      Associated Course: KI142303BKI142303B


        Picture of SOLEH ELFRIANTO HARDIYONO 5116201028
        by SOLEH ELFRIANTO HARDIYONO 5116201028 - Thursday, 22 December 2016, 10:43 PM
        Anyone in the world

                Pemanfaatan teknologi elektronik untuk menyampaikan, mendukung dan meningkatkan pengajaran dan pembelajaran (oleh : Learning Skills Development Agency [LSDA]).
                Penggunaan teknologi multimedia dan Internet untuk meningkatkan kualitas pembelajaran dengan memfasilitasi akses ke sumber daya dan layanan serta kolaborasi sesama member (UE)     
                jika seseorang belajar dengan cara yang menggunakan teknologi informasi dan komunikasi (TIK), dengan menggunakan elearning (oleh : DfES)

                Tersedianya fasilitas e-moderating dimana pengajar dan siswa dapat berkomunikasi secara mudah melalui fasilitas internet secara reguler atau kapan saja kegiatan berkomunikasi itu dilakukan tanpa dibatasi oleh jarak, tempat, dan waktu.
                Pengajar dan siswa dapat menggunakan bahan ajar yang terstruktur dan terjadwal melalui internet.
                Siswa dapat belajar (me-review) bahan ajar setiap saat dan dimana saja apabila diperlukan mengingat bahan ajar tersimpan di komputer.
                Bila siswa memerlukan tambahan informasi yang berkaitan dengan bahan yang dipelajarinya, ia dapat melakukan akses di internet.
                Baik pengajar maupun siswa dapat melakukan diskusi melalui internet yang dapat diikuti dengan jumlah peserta yang banyak.
                Berubahnya peran siswa dari yang pasif menjadi aktif.
                Relatif lebih efisien. Misalnya bagi mereka yang tinggal jauh dari Perguruan Tinggi atau sekolah konvensional dapat mengaksesnya.
                interaksi antara pengajar dan siswa atau bahkan antara siswa itu sendiri, bisa memperlambat terbentuknya values dalam proses belajar mengajar.
                Kecenderungan mengabaikan aspek akademik atau aspek sosial dan sebaliknya mendorong aspek bisnis atau komersial.
                Proses belajar dan mengajarnya cenderung ke arah pelatihan dari pada pendidikan.
                Berubahnya peran guru dari yang semula menguasai teknik pembelajaran konvensional, kini dituntut untuk menguasai teknik pembelajaran dengan menggunakan ICT (Information Communication Technology).
                Siswa yang tidak mempunyai motivasi belajar yang tinggi cenderung gagal.
                Tidak semua tempat tersedia fasilitas internet (berkaitan dengan masalah tersedianya listrik, telepon, dan komputer).
                Kurangnya mereka yang mengetahui dan memiliki keterampilan tentang internet.
                Kurangnya penguasaan bahasa komputer.

                Computer Based Training (CBT)
                eLearning dengan komunikasi satu arah, merupakanawal kemunculan aplikasi e-learning yang berjalan di PC standalone ataupun dalam kemasan CD-ROOM. Isi berupa  materi dalam bentuk tulisan maupun multimedia (video dan audio) dalam  format MOV, MPEG-1 atau AVI. Dengan menggunakan tools  yang disediakan maka pengguna mempunyai kesempatan untuk mencoba  soal-soal latihan tanpa batasan jumlah dan tingkat kesulitannya, Contohnya :
                - Toolbox (keluaran perusahaan Asymetrix sekarang bernama Clickllearn)
                - Autoware (keluaran Macromedia ).

                LMS (LearningManagement System)
                Seiring dengan perkembangan teknologi internet di dunia, masyarakat dunia mulai terkoneksi dengan internet. Kebutuhan akan        informasi yang cepat diperoleh menjadi mutlak, dan jarak serta lokasi  bukanlah halangan lagi. Disinilah muncul sebuah Learning Management     System atau biasa disingkat dengan LMS. Perkembangan LMS yang semakin pesat membuat pemikiran baru untuk mengatasi masalah     interoperability antar LMS yang ada dengan suatu standard. Standard yang   muncul misalnya adalah standard yang dikeluarkan oleh AICC (Airline     Industry CBT   Committee), IMS, IEEE LOM, ARIADNE, dsb. Contoh aplikasi ini adalah
                - Atutor, yang mana aplikasi ini terdapat fasilitas penulisan materi, upload materi, penugasan, pembuatan bank soal, pengujian dan penilaian serta fasilitas komunikasi (chatting, forum dan blog) dan modul lainnya (kalender dan photoalbum).

                Aplikasi e-learning berbasis web
                Perkembangan LMS menuju ke aplikasi e-learning berbasis Web            secara total,      baik untuk pembelajar (learner) maupun administrasi      belajar mengajarnya. LMS      mulai digabungkan dengan situs-situs portal   yang pada saat ini boleh dikata menjadi barometer situs-situs informasi,        majalah, dan surat kabar dunia. Isi juga semakin kaya dengan      berpaduan multimedia, video streaming, serta penampilan interaktif dalam    berbagai pilihan format data yang lebih standard, berukuran kecil dan stabil. Contoh aplikasi ini adalah Dokeos. Dokeos merupakan free            software yang di release oleh GNU GPL dan pengembangannya didukung oleh dunia internasional. Sistem operasinya bersertifikasi yang bisa         digunakan sebagai konten dari sistem managemen untuk pendidikan.      Kontennya meliputi distribusi bahan pelajaran, kalender, progres      pembelajaran, percakapan melalui text/audio maupun video, administrasi             test, dan menyimpan catatan. Tujuan utama dari dokeos adalah menjadi             sistem yang userfriendly dan flexibel serta mudah dipakai.


        Associated Course: KI142303BKI142303B


          Anyone in the world

          Berikut beberapa tool yang biasa digunakan untuk merancang pemodelan dalam pengembangan perangkat lunak :

          •     offline :

                  Power Designer
                  Star UML
                  Microsoft Visio

          •     Online

                  webSequenceDiagrams >
                  colorcombos >
                  mockflow >

          Associated Course: KI142303BKI142303B
          [ Modified: Friday, 23 December 2016, 12:26 AM ]


            Picture of OZZY SECIO RIZA 5116201030
            by OZZY SECIO RIZA 5116201030 - Thursday, 22 December 2016, 5:55 PM
            Anyone in the world

            Dalam rekayasa sistem dan rekayasa perangkat lunak, analisis kebutuhan mencakup pekerjaan-pekerjaan penentuan kebutuhan atau kondisi yang harus dipenuhi dalam suatu produk baru atau perubahan produk, yang mempertimbangkan berbagai kebutuhan yang bersinggungan antar berbagai pemangku kepentingan. Kebutuhan dari hasil analisis ini harus dapat dilaksanakan, diukur, diuji, terkait dengan kebutuhan bisnis yang teridentifikasi, serta didefinisikan sampai tingkat detail yang memadai untuk desain sistem.


            Analisis kebutuhan merupakan langkah awal untuk menentukan gambaran perangkat yang akan dihasilkan ketika pengembang melaksanakan sebuah proyek pembuatan perangkat lunak. Perangkat lunak yang baik dan sesuai dengan kebutuhan pengguna sangat tergantung pada keberhasilan dalam melakukan analisis kebutuhan. Untuk proyek-proyek perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah aktivitas sistem information engineering dan software project planning.

            Analisa kebutuhan yang baik belum tentu menghasilkan perangkat lunak yang baik, tetapi analisa kebutuhan yang tidak tepat menghasilkan perangkat yang tidak berguna. Mengetahui adanya kesalahan pada analisis kebutuhan pada tahap awal memang jauh lebih baik, tapi kesalahan analisis kebutuhan yang diketahui ketika sudah memasuki penulisan kode atau pengujian, bahkan hampir masuk dalam tahap penyelesaian merupakan malapetaka besar bagi pembuat perangkat lunak. Biaya dan waktu yang diperlukan akan menjadi sia sia.


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


            Analisa kebutuhan ini terdiri dari lima langkah pokok:

            1.Identifikasi Masalah
            2.Evaluasi dan sintesis


            Tujuan analisis kebutuhan

            Ada tiga tujuan utama dari proses analasis kebutuhan yang dapat diformulasikan sebagai beriukut :

            1. Mengelola hasil elistasi kebutuhan untuk menghasilkan dokumen spesifikasi kebutuhan yang isi keseluruhannya sesuai dengan apa yang diinginkan pengguna (Liu and Yen, 1996).
            2. Mengembangkan persyaratan kualitas yang memadai dan rinci, dimana para manajer dapat membuat pekerjaan proyek yang realistis dan staf teknis dapat melanjutkan dengan perancangan, implementasi dan pengujian (Wiegers, 2003).
            3. Membangun pemahaman tentang karakteristik ranah permasalahan dan sekumpulan kebutuhan untuk menemukan solusi

            Ketiga tujuan tersebut dapat dicapai oleh perekayasa kebutuhan dengan melalui serangkaian tahapan-tahapan aktivitas. 

            Tahap Analisis Kebutuhan

            Domain Understanding, dalam tahap ini perekayasa kebutuhan perangkat lunak harus mengetahui bagaimana organisasi perusahaan beroperasi dan apa yang menjadi permasalahan pada sistem yg sedang  berjalan pada saat ini. perekayasaan perlu memfokuskan kepada ‘Apa’ yg menjadi permasalahan. Perekaysaan hendaknya tidak berhenti pada menemukan “gejala” dari permasalahn itu terjadi untuk menemukan akar dari pemasalahan dari sistem yg berjalan tersebut.

            Requirements Collection, Tahapan ini merupakan tahapan pengumpulan kebutuhan akan sistem yang akan dibangun.Pada tahapan ini diperlukan adanya intekasi intensif dengan pemangku kepentingan terutama dengan pengguna akhir.

            Classification, Pada tahapan sebelumnya kumpulan kebutuhan masih tidak terstruktur.Untuk itu kebutuhan yang saling berkaitan dikelompokan,baik menurut kelas penggunaanya maupun jenis kebutuhananya. Kebutuhan kebutuhan tersebut diorganisasi ke dalam kelompk-kelompok yang koheren.Perekayasaan perlu memisahkan antara kebutuhan dan keinginan dari pengguna.

            Conflict resolution, Pada tahapan ini adalah menemukan dan menyelesaikan  kebutuhan yang di dalamnya terdapat konflik.

            Prioritisation, Pada tahapan dilakukan interaksi dengan pemangku kepentingan untuk mengidentifikasikan kebutuhan-kebutuhan priopritas dari masing-masing kebutuhan agar sumber daya yang tersedia pada organisasi dialokasikan untuk mengimplementasikan kebutuhan yg terutama dari pemangku kepentingan.

            Requirements Checking, Menganalisa sekumpulan kebutuhan dari hasil tahapan sebelumnya untuk memverifikasi dan memvalidasi berdasarkan aspek kelengkapan,konsistensi,dan kebutuhan nyata.

            Dalam rekayasa kebutuhan, analisa kebutuhan yang baik hedaklah menitik beratkan pada ranah permasalahan dan bukan pada ranah solusi. Tujuan utamanya adalah untuk mencapai pemahaman tetang sifat dari ranah permasalahan dan permasalahan  yang ada didalamnya . Pada dasarnya, analisi kebutuhan diawali dengan spesifikasi (layanan, atribut, properti, kualitas, batasan) dari sistem solusi yang hendak dibangun.

            Kegunaan analisis adalah untuk memodelkan permasalahan dunia nyata agar dapat dimengerti. Permasalahan dunia nyata harus dimengerti dan dipelajari supaya spesifikasi kebutuhan perangkat lunak dapat diungkapkan. Tujuan aktivitas ini adalah untuk mengetahui ruang lingkup produk (product space) dan pemakai yang akan menggunakannya. Analisis yang baik akan mengungkapkan hal-hal yang penting dari permasalahan, dan mengabaikan yang tidak penting.


            Referensi :



            Associated Course: KI142303BKI142303B
            [ Modified: Thursday, 22 December 2016, 5:57 PM ]


              Picture of OZZY SECIO RIZA 5116201030
              by OZZY SECIO RIZA 5116201030 - Thursday, 22 December 2016, 5:54 PM
              Anyone in the world

              White-box testing is a verification technique software engineers can use to examine if their code works as expected. White-box testing is testing that takes into account the internal mechanism of a system or component (IEEE, 1990). White-box testing is also known as structural testing, clear box testing, and glass box testing (Beizer, 1995). The connotations of “clear box” and “glass box” appropriately indicate that you have full visibility of the internal workings of the software product, specifically, the logic and the structure of the code.

              Using the white-box testing techniques outlined in this chapter, a software engineer can design test cases that (1) exercise independent paths within a module or unit; (2) exercise logical decisions on both their true and false side; (3) execute loops at their boundaries and within their operational bounds; and (4) exercise internal data structures to ensure their validity (Pressman, 2001).

              There are six basic types of testing: unit, integration, function/system, acceptance, regression, and beta. White-box testing is used for three of these six types:

              • Unit testing, which is testing of individual hardware or software units or groups of related units (IEEE, 1990). A unit is a software component that cannot be subdivided into other components (IEEE, 1990). Software engineers write white-box test cases to examine whether the unit is coded correctly. Unit testing is important for ensuring the code is solid before it is integrated with other code. Once the code is integrated into the code base, the cause of an observed failure is more difficult to find. Also, since the software engineer writes and runs unit tests him or herself, companies often do not track the unit test failures that are observed– making these types of defects the most “private” to the software engineer. We all prefer to find our own mistakes and to have the opportunity to fix them without others knowing. Approximately 65% of all bugs can be caught in unit testing (Beizer, 1990).
              • Integration testing, which is testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them (IEEE, 1990). Test cases are written which explicitly examine the interfaces between the various units. These test cases can be black box test cases, whereby the tester understands that a test case requires multiple program units to interact. Alternatively, white-box test cases are written which explicitly exercise the interfaces that are known to the tester.
              • Regression testing, which is selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified requirements (IEEE, 1990). As with integration testing, regression testing can be done via black-box test cases, white-box test cases, or a combination of the two. White-box unit and integration test cases can be saved and rerun as part of regression testing

              White Box Testing Techniques:

              • Statement Coverage - This technique is aimed at exercising all programming statements with minimal tests.
              • Branch Coverage - This technique is running a series of tests to ensure that all branches are tested at least once.
              • Path Coverage - This technique corresponds to testing all possible paths which means that each statement and branch is covered.

              Advantages of White Box Testing:

              • Forces test developer to reason carefully about implementation.
              • Reveals errors in "hidden" code.
              • Spots the Dead Code or other issues with respect to best programming practices.

              Disadvantages of White Box Testing:

              • Expensive as one has to spend both time and money to perform white box testing.
              • Every possibility that few lines of code are missed accidentally.
              • In-depth knowledge about the programming language is necessary to perform white box testing.



              Laurie Williams. “White-Box Testing. 2006


              Associated Course: KI142303BKI142303B


                Picture of OZZY SECIO RIZA 5116201030
                by OZZY SECIO RIZA 5116201030 - Thursday, 22 December 2016, 5:54 PM
                Anyone in the world

                Often software engineering projects and products are not precise about the targets that should be achieved. Software requirements are stated, but the marginal value of adding a bit more functionality cannot be measured. The result could be late delivery or too-high cost. The “good enough” principle relates marginal value to marginal cost and provides guidance to determine criteria when a deliverable is “good enough” to be delivered.

                These criteria depend on business objectives and on prioritization of different alternatives, such as ranking software requirements, measurable quality attributes, or relating schedule to product content and cost. The RACE principle (reduce accidents and control essence) is a popular rule towards good enough software. Accidents imply unnecessary overheads such as gold-plating and rework due to late defect removal or too many requirements changes. Essence is what customers pay for. Software engineering economics provides the mechanisms to define criteria that determine when a deliverable is “good enough” to be delivered. It also highlights that both words are relevant: “good” and “enough.” Insufficient quality or insufficient quantity is not good enough.

                Agile methods are examples of “good enough” that try to optimize value by reducing the overhead of delayed rework and the gold plating that Software Engineering Economics 12-15 results from adding features that have low marginal value for the users (see Agile Methods in the Software Engineering Models and Methods KA and Software Life Cycle Models in the Software Engineering Process KA). In agile methods, detailed planning and lengthy development phases are replaced by incremental planning and frequent delivery of small increments of a deliverable product that is tested and evaluated by user representatives

                The five key process ideas (KPIs) of good enough software :

                1. Utilitarian Strategy

                The utilitarian strategy applies to problem, projects, and products. The term is one that I've coined out of necessity (or possibly ignorance, as I just haven't found a suitable alternative). It refers to the art of qualitatively analyzing and maximizing net positive consequences in an ambiguous situation. It encompasses ideas from systems thinking, risk management, economics, decision theory, game theory, control theory, and fuzzy logic.

                2. Evolutionary strategy

                An evolutionary strategy, applied either to problems, projects, or products, alternates observation with action to effect ongoing improvement. On the project level, this means ongoing process education, experimentation and adjustment, rather than clinging to a notion of the One Right Way to develop software.

                On the problem level, it means keeping track of history, and learning about failure and success over time. Here are some of the elements of using the evolutionary approach:

                • Don't even try to plan everything up front.
                • Converge on good enough in successive, self-contained stages.
                • Integrate early and often.
                • Encourage disciplined evolution of feature set and schedule over the course of the project.
                • Salvage, reuse, or purchase components where feasible.
                • Record and review your experience.

                3. Heroic Teams

                For some reason, the most fundamental key to good enough development also seems to be the most controversial. There is a strong disdain, among many methodologists, for the very word "hero". I'm not sure why that is, since evidence supporting the role of heroes in computing is just a shade less compelling than evidence supporting the role of electricity. I think it's because there are several definitions of hero.

                4. Dynamic Infrastructure

                Dynamic infrastructure means that the company rapidly responds to the needs of the project. It backs up responsibility with authority and resources. Dynamic infrastructure provides life support for the other four key process ideas. Some of its elements are:

                • Upper management pays attention to projects.
                • Upper management pays attention to the market.
                • The organization identifies and resolves conflicts between projects.
                • In conflicts between projects and organizational bureaucracy, projects win.
                • Project experience is incorporated into the organizational memory

                5. Dynamic Processes

                Three other important dynamic process attributes are portability, scalability, and durability. Portability is how the process lends itself to being carried into meetings, shared with others, and applied to new problems. Scalability is how readily the process may be expanded or contracted in scope. A highly scalable process is one that can be operated by one person, manually, or by a hundred people, with tool support, without dramatic redesign. Durability is how well the process tolerates neglect and misuse.

                Associated Course: KI142303BKI142303B


                  Picture of OZZY SECIO RIZA 5116201030
                  by OZZY SECIO RIZA 5116201030 - Thursday, 22 December 2016, 5:52 PM
                  Anyone in the world


                  Istilah software construction didasarkan pada rincian pengerjaannya,yang berarti software melalui kombinasi dari koding,verifikasi,unit testing,testing terintregasi dan debugging. Pengetahuan software construction terhubung dengan dengan pengetahuan yang lain:

                  • • Software Design
                  • • Software Testing
                  • • Software Engineering
                  • • Software Project
                  • • Software Quality

                  Proses Software Construction melibatkan desain software yang signifikan dan aktivitas testing software.Software Consntruction juga menggunakan output design dan menghasilkan salah satu input untuk testing,baik dalam aktivitas desain dan testing. batasan antara desain,konstruksi dan testing akan bervariasi tergantung dalam proses software life cycle yang di gunakan dalam proyek.

                  Software Construction Fundamental

                  1. Minimizing Complexity

                  Faktor kendala utama menggunakan komputer adalah kemampuan terbatas. Hal ini mendorong pembuatan ke sebuah driver yang paling handal dalam SC, yaitu: mengurangi kompleksitas. Dalam SC pengurangan kompleksitasnya pada proses verifikasi dan testing (pembuatan kode yang simple dan mudah dibaca)

                  2. Anticipating Change

                  Software merupakan bagian yang tidak mungkin terhindar dari sebuah perubahan lingkungan luar. Perubahan dari lingkungan luar akan mempengaruhi software dalam banyak hal.

                  3. Constructing for Verification

                  Perancangan dalam rangka verifikasi berarti membangun software dengan mencari suatu kesalahan (error) yang dapat terbaca dengan mudah oleh Software Engineer yang menulis (kode) dari software. Teknik – teknik yang spesifik yang mendukung dalam perancangan untuk verifikasi, termasuk diantaranya yaitu :

                  • - standar pembuatan kode untuk mendukung referensi dari kode, unit testing,
                  • - pengaturan kode untuk mendukung testing secara otomatis,
                  • - menghindari penggunaan struktur bahasa yang kompleks dan sulit dimengerti orang lain.

                  4. Standards in Construction

                  Standar2 yang mempengaruhi perancangan meliputi :

                  • - Bahasa Pemrogaman
                  • - Metode Komunikasi
                  • - Platform
                  • - Tool
                  Associated Course: KI142303BKI142303B


                    Picture of OZZY SECIO RIZA 5116201030
                    by OZZY SECIO RIZA 5116201030 - Thursday, 22 December 2016, 5:51 PM
                    Anyone in the world

                    In requirements engineering, requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as "requirement gathering". The term elicitation is used in books and research to raise the fact that good requirements cannot just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do OR NOT do (for Safety and Reliability). Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases, role playing and prototyping.

                    Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process. Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements. Commonly used elicitation processes are the stakeholder meetings or interviews. For example, an important first meeting could be between software engineers and customers where they discuss their perspective of the requirements.

                    Prepare for Elicitation

                    1. The first step in requirements elicitation is gleaning a comprehensive and accurate understanding of the project’s business need. During the elicitation process, an analyst’s strong understanding of the business need will help her guard against scope creep and gold plating, as well as select the proper stakeholders and elicitation techniques.
                    2. An analyst’s next step in eliciting requirements is ensuring that an adequate amount and mix of stakeholders are secured for the project’s duration. For, as BABOK 2.0 (Business Analysis Body of Knowledge, the definitive guide to all things related to business analysis) notes, a good analyst must “actively engage stakeholders in defining requirements.” According to BABOK, a project’s stakeholders may include customers/end users, suppliers, the project manager, quality analysis, regulators, project sponsors, operational support, domain subject matter experts, and implementation subject matter experts. An analyst must recruit the participation of appropriate stakeholders based on the unique business needs of her project. After an analyst has identified and recruited her stakeholders, and chosen the method(s) by which she will elicit requirements (outlined below), it is advisable for her to schedule the time for conducting those methods with stakeholders as far in advance as possible to ensure adequate participation on their parts.


                    Elicitation Techniques

                    After securing the proper stakeholders, an analyst must determine the best techniques for eliciting requirements. Commonly used requirements elicitation methods (as identified by BABOK) include:

                    • Brainstorming – The purpose of gathering your stakeholders for brainstorming is “to produce numerous new ideas, and to derive from them themes for further analysis [from BABOK].” An analyst should try to secure a representative from each participating stakeholder group in the brainstorming session. If an analyst serves as facilitator of a brainstorming session, she must ensure that while participants feel free to propose new ideas and solutions, they remain focused on the business need at hand and do not engage in scope creep, gold plating, or become distracted with other business issues. All ideas must be recorded so that they are not lost. According to BABOK, the brainstorming method is particularly useful if your project has no clear winning choice for a solution, or if existing proposed solutions are deemed inadequate. The brainstorming process and the resulting follow-up analysis will help ensure that the best possible solution is reached for any business objective.
                    • Document analysis – Document analysis involves gathering and reviewing all existing documentation that is pertinent to your business objective or that may hold data related to a relevant solution. According to BABOK, such documentation may include, “business plans, market studies, contracts, requests for proposal, statements of work, memos, existing guidelines, procedures, training guides, competing product literature, published comparative product reviews, problem reports, customer suggestion logs, and existing system specifications, among others.” In other words, virtually anything that is written related to the project may be useful. This type of elicitation is especially useful when the goal is to update an existing system or when the understanding of an existing system will enhance a new system. However, document analysis alone is rarely enough to thoroughly extract all of the requirements for any given project.
                    • Focus Group – Focus groups consist of a mix of pre-qualified stakeholders who gather to offer input on the business need at hand and its potential solutions. Focus groups are particularly helpful when key stakeholders are not particularly imaginative or forthcoming; a few more vocal stakeholders may help them think through and articulate solutions. Focus groups are also a good way for time-pressed analysts to get a lot of information at once. They may be conducted in person or virtually. (Key project sponsors or business owners should still be interviewed individually for thorough discovery.)
                    • Interface Analysis – An interface analysis carefully analyzes and deconstructs the way that a user interacts with an application, or the way one application interacts with another. According to BABOK, a thorough interface analysis will describe the purpose of each interface involved and elicit high-level details about it, including outlining its content. This type of elicitation is essential for software solutions, which almost always involve applications interacting with one another and/or users interacting with applications. But, according to BABOK, interface analysis can also be useful for non-software solutions (such as defining deliverables by third parties).
                    • Interviews – One-on-one interviews are among the most popular types of requirements elicitation, and for good reason: they give an analyst the opportunity to discuss in-depth a stakeholder’s thoughts and get his or her perspective on the business need and the feasibility of potential solutions. “Research has found that interviews . . . are the most effective way of eliciting requirements.” Whether an analyst chooses to have a structured (with predefined questions) or unstructured interview (with free-flowing, back-and-forth conversation), she must fully understand the business need in order to conduct a successful interview. It is a good practice for an analyst to share her interview notes with the interviewee afterward to ensure there were no misunderstandings and to jog the interviewee’s thoughts for any further insights.
                    • Observation (job shadowing) – Observation is quite helpful when considering a project that will change or enhance current processes. According to BABOK, two basic types of observation are available to an analyst: (1) passive observation, where the analyst merely watches someone working but does not interrupt or engage the worker in any way, and (2) active observation, where an analyst asks questions throughout the process to be sure she understands and even attempts portions of the work. The nature of an analyst’s project will dictate the level of detail an observation should encompass. As with interviews, it is a good practice for an analyst to provide notes from her observations and/or a verbal description of her understanding of the work for the worker to review in order to be sure that there were no misunderstandings of the process.
                    • Prototyping (storyboarding, navigation flow, paper prototyping, screen flows) – Prototyping is especially valuable for stakeholders such as business owners and end users who may not understand all of the technical aspects of requirements, but will better relate to a visual representation of the end product. To quote BABOK, “Stakeholders often find prototyping to be a concrete means of identifying, describing and validating their interface needs.” The prototyping process is normally iterative, improving as more input and evaluation are gleaned from stakeholders. Prototyping may be an interactive screen (normally consisting of hypertext only with no real data behind it), a mock-up (such as a PowerPoint), a navigation flow (such as a Visio diagram), or a storyboard. Simple, throwaway prototypes (such as pencil sketches) may be done in the initial stages of discovery, and more detailed, interactive prototypes may be done once business requirements have been identified. At the latter, more detailed prototype stage,prototype features must fulfill previously identified business needs as outlined in the requirements.
                    • Requirements workshops – A requirements workshop involves gathering a previously identified stakeholders in a structured setting for a defined amount of time in order to elicit, refine, and/or edit requirements. To be successful, requirements workshops must include a recorder (or scribe) to record participants’ input, and a facilitator to direct the discussion. Because participants’ may also brainstorm together and listen to each others’ input, they can provide immediate feedback and refinements to identified business needs, which can ensure a fast, effective elicitation of requirements.
                    • Survey/questionnaire – While they preclude the opportunity for in-person, ad hoc conversations, surveys are useful for quickly gathering data from a large group of participants. Because free online survey software is readily available, surveys are an inexpensive way to gather objective input from customers or potential end users. As with selecting stakeholders, a successful survey or questionnaire must have well-chosen participants. As one researcher notes, questionnaires “can be useful when the population is large enough, and the issues addressed are clear enough to all concerned.” Surveys can be structured to offer a series of finite choices for feedback, or they can offer open-ended input, depending on the needs of the project at hand. Open-ended surveys are useful for a broader discovery of business needs; however, the larger the number of participants in open-ended surveys, the more prohibitive they are to analyze. Survey wording must be unambiguous and precise. It is good practice for an analyst to politely request that survey participants respond by a reasonable deadline and that they keep any proprietary business information contained within the survey confidential.





                    Associated Course: KI142303BKI142303B


                      Page: () 1 ... 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 ... 45 ()