Site blog

Halaman: () 1 ... 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 ... 41 ()
Gambar dari DINIAL UTAMI NURUL QOMARIAH 5116201026
by DINIAL UTAMI NURUL QOMARIAH 5116201026 - Tuesday, 20 December 2016, 21:39
Anyone in the world

A Sequence diagram is an interaction diagram that shows how objects operate with one another and in what order. It is a construct of a message sequence chart.

A sequence diagram shows object interactions arranged in time sequence. It depicts the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the scenario. Sequence diagrams are typically associated with use case realizations in the Logical View of the system under development. Sequence diagrams are sometimes called event diagrams or event scenarios.

A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner.

Gambar dari DINIAL UTAMI NURUL QOMARIAH 5116201026
by DINIAL UTAMI NURUL QOMARIAH 5116201026 - Tuesday, 20 December 2016, 21:37
Anyone in the world

In software and systems engineering, a use case is a list of actions or event steps, typically defining the interactions between a role (known in the Unified Modeling Language as an actor) and a system, to achieve a goal. The actor can be a human or other external system. In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in the Systems Modeling Language (SysML) or as contractual statements.

Use case analysis is an important and valuable requirement analysis technique that has been widely used in modern software engineering since its formal introduction by Ivar Jacobson in 1992. Use case driven development is a key characteristic of many process models and frameworks such as ICONIX, the Unified Process (UP), the IBM Rational Unified Process (RUP), and the Oracle Unified Method (OUM). With its inherent iterative, incremental and evolutionary nature, use case also fits well for agile development.

Anyone in the world

The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software engineering, that is intended to provide a standard way to visualize the design of a system.[1]

UML was originally motivated by the desire to standardize the disparate notational systems and approaches to software design developed by Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software in 1994–1995, with further development led by them through 1996.[1]

In 1997 UML was adopted as a standard by the Object Management Group (OMG), and has been managed by this organization ever since. In 2005 UML was also published by the International Organization for Standardization (ISO) as an approved ISO standard.[2] Since then it has been periodically revised to cover the latest revision of UML.[3]

Gambar dari DINIAL UTAMI NURUL QOMARIAH 5116201026
by DINIAL UTAMI NURUL QOMARIAH 5116201026 - Tuesday, 20 December 2016, 21:32
Anyone in the world

Kebutuhan efisiensi berkaitan dengan sumber daya perangkat keras atau hardware yang dibutuhkan untuk menjalankan semua fungsi dari sistem software dengan keseuaian terhadap semua kebutuhan.

Anyone in the world

Maintainability is defined as the probability of performing a successful repair action within a given time. In other words, maintainability measures the ease and speed with which a system can be restored to operational status after a failure occurs. This is similar to system reliability analysis except that the random variable of interest in maintainability analysis is time-to-repair rather than time-to-failure. For example, if it is said that a particular component has a 90% maintainability for one hour, this means that there is a 90% probability that the component will be repaired within an hour. When you combine system maintainability analysis with system reliability analysis, you can obtain many useful results concerning the overall performance (availability, uptime, downtime, etc.) that will help you to make decisions about the design and/or operation of a repairable system.


Software Features

BlockSim supports an extensive array of reliability block diagram (RBD) configurations and fault tree analysis (FTA) gates and events, including advanced capabilities to model complex configurations, load sharing, standby redundancy, phases and duty cycles. Using exact computations and/or discrete event simulation, BlockSim facilitates a wide variety of analyses for both repairable and non-repairable systems.

Gambar dari DINIAL UTAMI NURUL QOMARIAH 5116201026
by DINIAL UTAMI NURUL QOMARIAH 5116201026 - Tuesday, 20 December 2016, 21:26
Anyone in the world

Software designers do not arrive at a finished design immediately. They develop design iteratively through number of different versions. The starting point is informal design which is refined by adding information to make it consistent and complete

Software design is the process of implementing software solutions to one or more sets of problems. One of the main components of software design is the software requirements analysis (SRA). SRA is a part of the software development process that lists specifications used in software engineering. If the software is "semi-automated" or user centered, software design may involve user experience design yielding a storyboard to help determine those specifications. If the software is completely automated (meaning no user or user interface), a software design may be as simple as a flow chart or text describing a planned sequence of events. There are also semi-standard methods like Unified Modeling Language and Fundamental modeling concepts. In either case, some documentation of the plan is usually the product of the design. Furthermore, a software design may be platform-independent or platform-specific, depending upon the availability of the technology used for the design.

The main difference between software analysis and design is that the output of a software analysis consists of smaller problems to solve. Additionally, the analysis should not be designed very differently across different team members or groups. In contrast, the design focuses on capabilities, and thus multiple designs for the same problem can and will exist. Depending on the environment, the design often varies, whether it is created from reliable frameworks or implemented with suitable design patterns. Design examples include operation systems, webpages, mobile devices or even the new cloud computing paradigm.

Gambar dari MAURICE NTAHOBARI 5116201702
by MAURICE NTAHOBARI 5116201702 - Tuesday, 20 December 2016, 16:19
Anyone in the world

 The most serious outcome of a poor requirements elicitation process is that :

The developers are solving the wrong problem. This guarantees the failure of the whole project. Even if the developers are solving essentially the right problem, a poor elicitation process can have other negative outcomes. The customers can be dissatisfied; this often happens if the developers did not really listen to them, or if the developers dominated the process and tended to force their own views and interpretations on the customers. Dissatisfaction may result in less effective participation by the stakeholders or customers, resulting in less complete answers to the developer’s questions. The dissatisfaction can continue to affect the project through development and delivery of the software. A poor elicitation process often leads to a chaotic development process. The developers may discover that they are missing important information, resulting in additional meetings with the customers. The developers may make the wrong decisions or tradeoffs because of a lack of understanding of the users’ needs. Requirements may change more often, resulting in greater need for configuration management, or in delays or wasted effort in design and implementation. The result is cost and schedule overruns, and sometimes failed or canceled projects. All of these effects can result in a loss of money for the company developing or buying the software, loss of reputation or credibility for the developers, and a decline in the developers’ morale. s or, in extreme cases, actively sabotage the development effort.

Anyone in the world

Random testing is a kind of black box testing where the testing is done in case there is no enough time to write be conducted. it is characterized by:

  • It is done where the defects are NOT monitored in regular time intervals.

  • Random input is used to test the performance of the system and its reliability to deliver required service.

  •  it is not time-consuming and effort than actual test efforts.

Anyone in the world

software quality assurance are the criteria that are considered to evaluate the quality of a software. those criteria are:

  1. Correctness
  2. Efficiency
  3. Flexibility
  4. Integrity
  5. Interoperability
  6. Maintainability
  7. Portability
  8. Reliability
  9. Reusability
  10. Testability
  11. Usability
[ Mengubah: Tuesday, 20 December 2016, 15:53 ]
Anyone in the world
Pada bagian ini, saya akan membahas tentang Software Construction/Konstruksi Perangkat Lunak. Secara umum, yang dimaksud dengan Konstruksi Perangkat Lunak adalah keseluruhan aktivitas menciptakan perangkat lunak yang berfungsi dan bermanfaat melalui berbagai proses kodifikasi, verifikasi, pengujian dan pemeriksaan-ulang. Konstruksi Perangkat Lunak adalah kompetensi yang terkait dengan disain perangkat lunak dan pengujian perangkat lunak.
Dari sudut pandang akademisi dan praktisi maka konstruksi perangkat lunak merupakan "bagian" proses pengembangan perangkat lunak yang memiliki "highest volume of configuration items" (atau aktivitas-aktivitas konfigurasi yang diutamakan). Konstruksi perangkat lunak berhubungan dengan penulisan kode, pengujian kode dan pemeriksaan-ulang kode sehingga tentu saja berkaitan dengan kualitas perangkat lunak itu sendiri. Secara mendasar, maka kualitas perangkat lunak itu ditentukan oleh kualitas penulisan, pengujuan dan pemeriksaan-ulang kode.
Disamping itu, konstruksi perangkat lunak juga sangat berkaitan dengan "kemampuan komputasi" (terutama pengetahuan algoritma), karena penulisan kode, pengujian kode dan pemeriksaan-kode sangat membutuhkan pemahaman komputasi dasar secara komprehensif dan mendalam.
Berikut adalah beberapa topik bahasan dalam kurikulum Teknik Informatika yang dikeluarkan oleh IEEE Software Engineering Body of Knowlede (SWEBOK IEEE):
1. Dasar-dasar Konstruksi Perangkat Lunak
Dasar-dasar konstruksi perangkat lunak ini termasuk: penyederhanaan kompleksitas; antisipasi perubahan persyaratan perangkat lunak;  konstruksi untuk verifikasi perangkat lunak; guna-ulang (atau disebut "reuse") dan standarisasi konstruksi perangkat lunak.
2. Pengelolaan Konstruksi Perangkat Lunak
Topik bahasan yang termasuk pada bagian ini adalah: 
Model Daur Hidup konstruksi perangkat lunak; Perencanaan Perangkat Lunak dan Pengukuran Konstruksi Perangkat Lunak.
3. Aspek-aspek Praktis Konstruksi Perangkat Lunak
Meliputi pembahasan tentang: Disain konstruksi perangkat lunak, bahasa pemrograman, kodifikasi, pengujian perangkat lunak, konstruksi untuk guna-ulang (dan konstruksi dengan guna-ulang), jaminan kualitas perangkat lunak dan integrasi perangkat lunak.
4. Aspek-aspek Teknis Konstruksi Perangkat Lunak
Topik bahasan bagian ini meliputi: 
Disain API dan Penggunaannya; Object-oriented Run-time; Generalisasi dan Parameterisasi; Assertion, Design by Contract, Defensive Programming; Pengendalian Error, Pengendalian Exception, dan Fault Tolerance; Executable Models; State-based dan Teknik Konstruksi Table Driven; Run-time Configuration dan Internationalization; Grammer-based Input Processing; Concurrency Primitives; Middleware; Metode Konstruksi untuk Distributed Software; Kontruksi Heterogeneous Systems; Analisis Performance dan Tuning; Platform Standards; Test-first programming.
5. Tools Konstruksi Perangkat Lunak
Terkait dengan materi ini adalah: Development Environments; GUI Builders; Unit Testing Tools; Profiling, Performance Analysis dan Slicing Tools.
Associated Kursus: KI142303BKI142303B
Halaman: () 1 ... 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 ... 41 ()