Skip to main content

Skip over site navigation to main content

developerWorks  >   Web development  >   Technical library  >  

Technical library view  RSS for Web development

 developerWorks
 Related links:    Redbooks

Filter your search and/or enter a keyword. If you don't filter your search or enter a keyword, the search results will default to all results.

 
 
 
  1 - 16 of 16 results    Hide Summaries
Title   Type   Date  

Table that contains the results that meet the search criteria.

Quality busters: Single technology solutions
Software professionals often get excited about a new technology, development tool, reference architecture, or approach. That excitement over a new "toy" often influences architects and developers to attempt to solve everything with this single solution. However, applying a single solution approach throughout a distributed application can have significant impact on performance, resource utilization, and other quality attributes. Here's why you need to think before putting all your eggs in a single basket. 		Articles 24 Jan 2006  
 
Quality busters: Reduce application complexity
From a user perspective, the reliability of an application is the perceived degree to which that application delivers the desired service at the desired time with the desired accuracy. If users think that an application is unreliable, they are reluctant to use it. Therefore, an architect must seriously evaluate the application's reliability. One way to improve reliability is to reduce the number of possible failure points in the application's event path. 		Articles 11 Jan 2005  
 
Quality busters: Losing messages
The success of a message-oriented system, regardless of the technology used to implement it, depends upon the consistent and reliable delivery of messages between processes. In this installment of Quality busters, Michael Russell identifies some of the places or failure points along the path between processes where a message can be lost or rejected. If you don't properly address these failure points, the results might include data corruption, out-of-sync conditions, timeouts, and perceived unreliability. 		Articles 28 Dec 2004  
 
Quality busters: Not measuring the risks
Members of the information industry often do not think about safety and risk. They consider these factors to be the domain of life-and-death environments like spacecraft software, nuclear power plant control systems, and medical equipment. But even business software can have safety concerns. An improperly processed financial transaction might cause long-lasting harm to a customer or to the business itself. In this article, I introduce failure modes and effects analysis (FMEA) and risk assessments as important tools for business software architects. 		Articles 15 Dec 2004  
 
Quality busters: Treat everyone equally
Developers sometimes work on systems that are more powerful than the average end user's system. If the developer doesn't recognize the differences between his or her environment and the user's environment, then the end user may reject the developer's work as being unusable. Thus, it is important that enterprise software development implement testing and efficiency measurements with the end user in mind. Development might need to make trade-offs regarding code versions, supported environments, and testing resources. 		Articles 03 Dec 2004  
 
Quality busters: Coding by assumption
Is your application ready for the latest version of the operation system it runs on or the program product on which it depends? Will you have to modify your application to upgrade? Have you made assumptions about the operating environment? These and other questions are easier to answer if you build portability into your application -- even if you do not plan to run it on another platform. One key to portability lies in not making any assumptions. 		Articles 23 Nov 2004  
 
Quality busters: What version is this?
Modern applications are built using many shared components, including dynamic link libraries (DLLs), JAR files, and runtime environments. Keeping track of these components, their versions, and their dependencies creates development and operational issues. This article discusses some of those issues and the considerations that arise from the use of components. 		Articles 02 Nov 2004  
 
Quality busters: Make your error messages meaningful
Many applications treat users as if they were programmers. Messages that report errors are often cryptic, contain meaningless codes, and provide no help regarding what to do next. While the developers who wrote the application can use those messages, most users are left with one option: call the help desk. This article describes a more appropriate kind of error message for users: one that includes description, cause, and recovery steps. 		Articles 20 Oct 2004  
 
Quality busters: A utility program for every occasion
Utility programs are frequently overlooked when releasing an application for production use, which is unfortunate because they support all kinds of essential operations. This month Michael Russell gets you thinking about utility programs and why to include them in your development plan and budget. 		Articles 31 Jan 2007  
 
Quality busters: Who's monitoring the application, anyway?
How do you know when the application you support fails or has a problem? Does an application monitoring utility notify you? Or, does the user support center notify you after frustrated users start complaining? With the large number of components -- systems, application servers, middleware services, database services, network, and more -- that make up modern business applications, a failure in one component can go undetected yet still cause quality of service problems. In this edition of Quality busters, Michael Russell examines the steps you can take to improve application monitoring -- and, by extension, application uptime. 		Articles 22 Sep 2004  
 
Quality busters: Don't violate the principle of locality
Modern applications are highly distributed, with components residing on many systems. These components consist of many application objects, such as program modules, databases, and configuration files. Improperly distributing application objects increases the number of necessary maintenance tasks; this in turn increases the likelihood that a task might be performed incorrectly, which increases the probability of an application failure. In this installment of Quality busters, you'll look at some of the ways in which application objects are improperly distributed. 		Articles 06 Oct 2004  
 
Quality busters: Address temporal issues in distributed and global applications
In this article, survey some of the temporal issues you might encounter as you develop your distributed or global application, including how to handle events, schedules, clock synchronization, interval calculations, local relevance, and cultural significance. 		Articles 29 Aug 2006  
 
Quality busters: Customizing applications
To customize applications and program products for a specific operational environment, you must modify one or more configuration objects. These configuration objects can take many forms, such as text files, XML files, system registries, or a separate service. Managing the operational environment becomes more complex as the number of configuration objects increases. 		Articles 08 Sep 2004  
 
Quality busters: The files that ate the disk
Nearly every application creates by-products which must be managed. These by-products include log files, tracings for debugging problems, intermediate files, data transfer files, temporary tables, and more. Failure to manage these transient objects can result in the application's failure due to limited disk space or other resource conflicts. 		Articles 23 Aug 2004  
 
Quality busters: Forget the environment
The quality of an application depends on more than how well it satisfies user-functional requirements. Even an application that successfully makes it through development and deployment can encounter grumblings from users and system operators if it is hard to use, keeps failing, is difficult to diagnose, or consumes excessive resources. In addition to user-functional requirements, you must also consider how well the application satisfies the non-functional requirements and fits into the organization's operational environment. 		Articles 10 Aug 2004  
 
Quality busters: Compare Web site appearance and functionality
Discover how to shift the priorities of your Web site from appearance to functionality and use Web standards to ensure cross-browser compatibility in this column by Michael Russell. 		Articles 18 Apr 2006  
 
  1 - 16 of 16 results    Hide Summaries
Not finding what you're looking for? Suggest Content