Site blog

Halaman: () 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ... 46 ()
Gambar dari AMELIA SAHIRA RAHMA 5116201024
by AMELIA SAHIRA RAHMA 5116201024 - Saturday, 7 January 2017, 09:47
Anyone in the world

Once you create an operational user interface prototype, it must be evaluated to determine whether it meets the needs of the user. Evaluation can span a formality spectrum that ranges from an informal “test drive,” in which a user provides impromptu feedback to a formally designed study that uses statistical methods for the evaluation of questionnaires completed by a population of end users.

The user interface evaluation cycle takes the form shown in Figure 1. After the design model has been completed, a first-level prototype is created. The prototype is evaluated by the user, 11 who provides you with direct comments about the efficacy of the interface. In addition, if formal evaluation techniques are used (questionnaires, rating sheets), you can extract information from these data (80 percent of all users did not like the mechanism for saving data files). Design modifications are made based on user input, and the next level prototype is created. The evaluation cycle continues until no further modifications to the interface design are necessary.



Figure 1


The prototyping approach is effective, but is it possible to evaluate the quality of a user interface before a prototype is built? If you identify and correct potential problems early, the number of loops through the evaluation cycle will be reduced and development time will shorten. If a design model of the interface has been created, a number of evaluation criteria can be applied during early design reviews :

  1. The length and complexity of the requirements model or written specification of the system and its interface provide an indication of the amount of learning required by users of the system.
  2. The number of user tasks specified and the average number of actions per task provide an indication of interaction time and the overall efficiency of the system.
  3. The number of actions, tasks, and system states indicated by the design model imply the memory load on users of the system.
  4. Interface style, help facilities, and error handling protocol provide a genera indication of the complexity of the interface and the degree to which it will be accepted by the user.

Once the first prototype is built, you can collect a variety of qualitative and quantitative data that will assist in evaluating the interface. To collect qualitative data, questionnaires can be distributed to users of the prototype. Questions can be :

(1) Simple yes/no response

(2) Numeric response

(3) Scaled (subjective) response

(4) Likert scales (strongly agree, somewhat agree)

(5) Percentage (subjective) response

(6) Open-ended.

If quantitative data are desired, a form of time-study analysis can be conducted. Users are observed during interaction, and data such as number of tasks correctly completed over a standard time period, frequency of actions, sequence of actions, time spent “looking” at the display, number and types of errors, error recovery time, time spent using help, and number of help references per standard time period are collected and used as a guide for interface modification.

Associated Kursus: KI142303BKI142303B
[ Mengubah: Saturday, 7 January 2017, 09:51 ]
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.
Associated Kursus: KI142303KI142303
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
Associated Kursus: KI142303KI142303
Anyone in the world
The overall requirements modeling approach The reading of the specification: The first step for software requirements is the specifications. The extensive reading is essential to establish the first collection of requirements. A requirement refers to a feature of a business rule or describes the properties of an object to be managed by the system, or even expresses a constraint that must comply with the software. At this stage, each requirement identified and endorsed with a description represents the first level of structuring of software features to achieve. Clarifying and refining of requirements Requirements once identified the need for many of them to be clarified, especially if the specifications of the terms are too ambiguous or imprecise. Other requirements for them will need to be thorough or further developed, to make sure to understand the content. This exercise requires direct questioning project stakeholders. For this, workshops are held in the presence of the customer, with the first carrier requirements gathering, a list of questions drawn from reading the specification, and clear goals at the end of each working session. Review and validation of requirements The requirements resulting models can be finally subjected to validation by the customer. This validation ensures that understanding the needs and constraints is shared by both parties customer and developer. It also endorses the scope of functionality of the system to develop. It is important to point out that after a partial or total validation requirements, it should not be excluded in the life of the project, new requirements may need to be added (requirement revealed in analysis or design phase) and validated requirements need to be changed (changing requirements) or eliminated (difficult requirement to implement or reduction in scope of the project).
Associated Kursus: KI142303KI142303
Gambar dari PASCAL MANIRIHO 5116201701
by PASCAL MANIRIHO 5116201701 - Saturday, 24 December 2016, 19:29
Anyone in the world

Modularization is a technique to divide a software system into multiple discrete and independent modules, which are expected to be capable of carrying out task(s) independently. These modules may work as basic constructs for the entire software. Designers tend to design modules such that they can be executed and/or compiled separately and independently.

Modular design unintentionally follows the rules of ‘divide and conquer’ problem-solving strategy this is because there are many other benefits attached with the modular design of a software.

Advantage of modularization

  • Smaller components are easier to maintain
  • Program can be divided based on functional aspects
  • Desired level of abstraction ca n be brought in the program
  • Components with high cohesion can be re-used again.
  • Concurrent execution can be made possible
  • Desired from security aspect
Associated Kursus: KI142303BKI142303B
Gambar dari PASCAL MANIRIHO 5116201701
by PASCAL MANIRIHO 5116201701 - Saturday, 24 December 2016, 19:29
Anyone in the world

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

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

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

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

Associated Kursus: KI142303BKI142303B
Gambar dari PASCAL MANIRIHO 5116201701
by PASCAL MANIRIHO 5116201701 - Saturday, 24 December 2016, 19:28
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 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 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.

Associated Kursus: KI142303BKI142303B
Anyone in the world
Technical Issues There are many other difficulties that we might characterize as technical that must be overcome by the requirements elicitation process if it is to be successful. Some of the more important of these are summarized below. 1. Problems to be solved by software systems are becoming increasingly complex. The requirements of these systems are based on increasingly detailed knowledge of the user’s domain. The impact of the systems on society must be considered, but neither the users nor the developers may be skilled at identifying that impact. 2. Requirements change over time. The requirements elicitation process itself is a learning experience for users, and ideas discussed at one point may cause them to change their minds about prior decisions. We must be careful to avoid having a set of requirements that is obsolete by the time the elicitation process is completed. 3. Software and hardware technologies are changing rapidly. A technological advance may make feasible a requirement that was unacceptably complex or expensive yesterday. 4. There are many sources of requirements. The users of a system are not necessarily aware of all the requirements that the system must satisfy. There may be requirements best elicited from computer operators or users’ support personnel. Corporate management may have guidelines for performing certain tasks or constraints that must be satisfied. There may be government regulations or industry standards for particular aspects of a system. 5. The nature or novelty of the system often imposes constraints on the elicitation process. A new system that is very similar to several other systems previously built by the development team may be able to benefit from previous requirements elicitation efforts and feedback from users of the previous systems. An unprecedented system requires a much more substantial requirements elicitation effort. Requirements elicitation for a one-of-a-kind system built for a specific customer can normally assume that the customer is the ultimate authority on what is needed. On the other hand, if the system will be offered for sale to customers other than the original buyer, the developers should look also at competing systems and additional or different requirements from those other customers. Requirements elicitation for a typical shrink-wrapped, personal productivity software package depends heavily on market research, examination of competing products, and some kind of communication with a sample of typical users. A software system that goes through many versions over many years needs a continuing elicitation process to identify defects in the current version and to track users’ requests for enhancements. For a real-time control system, requirements elicitation often includes detailed collaboration with hardware and systems engineers to decide what functionality will be implemented in hardware (computer or otherwise) and what in software.
Associated Kursus: KI142303KI142303
Gambar dari PASCAL MANIRIHO 5116201701
by PASCAL MANIRIHO 5116201701 - Saturday, 24 December 2016, 19:25
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 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
Associated Kursus: KI142303BKI142303B
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.

Associated Kursus: KI142303BKI142303B
Halaman: () 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ... 46 ()