"The overall process for designing a user interface begins with the creation of different models of system function (as perceived from the outside). The human- and computer-oriented tasks that are required to achieve system function are then delineated; design issues that apply to all interface designs are considered; tools are used to prototype and ultimately implement the design model; and the result is evaluated for quality." 
--Roger S. Pressman

Practice Description
A baseline interface must be agreed upon before the beginning of implementation activities, and the user interface must be made and maintained as an integral part of the system specification. For those projects developing both hardware and software, a separate software specification must be written with an explicit and complete interface description.

Practice Essentials

• The requirements for each external electronic interface should include the items listed in paragraph 3 of the MIL-STD-498 data item description DI-IPSC-81434.
   
• The design specification for each external electronic interface should include the items listed in paragraph 3 of the MIL-STD-498 data item description DI-IPSC-81436.
   
• An interface should be under CM change control before development begins on a software component accessing that interface. 
  
  
• Future user participation in the development of a user interface prototype should be a primary structured method for users to define system requirements.
   
• Application external interfaces, interfaces with middleware and operating systems, and interfaces of COTS products integrated into the application should comply with applicable public, open API standards and data interoperability standards unless there is a compelling reason to do otherwise. 
  
  
  • Comply with JTA interface standards
     
• Do not assume that if two interfacing applications comply with the JTA and DII COE TAFIM interface standards that they will interoperate. 
  
  
  • E.g., JTA and TAFIM include both Microsoft and UNIX interface standards and MS and UNIX design these standards to exclude the other.
     
• For each COTS software product used in your application, carefully analyze, independent of the vendor, the proprietary features of its interfaces.
   
• Do not use COTS interface proprietary features unless there is a compelling reason to do so.
   
• Each interface specification should undergo a formal inspection before it is accepted by CM.
   
• Integration test should include interface test, including tests under a heavy stress load. 

Implementation Guidelines

• All internal and external interfaces will be documented and maintained under CM control.
   
• Changes to interfaces will require concurrence by the interface owners prior to being made.
   
• Milestones related to external interfaces will be tracked in the project activity network.
   
• Subsystem interfaces will be controlled at the program level.
   
• Develop user interface prototype used in system requirements definition with a GUI-builder tool in a way that the prototype, with minimal modification, will be the user interface software of the delivered application.
   
• The user interface prototype used for system requirements definition should include screens and navigation between screens.
   
• Milestones related to external interfaces--such as completion of specifications and completion of system interface-should be included in the project activity network. Keep these milestones off your critical path.
   
• Compliance with open, public standards for APIs should be a major factor in selecting COTS operating system and middleware products and COTS application and service/utility products.
   
• If you plan significant reuse of legacy software, design the software architecture to minimize changes to legacy module interfaces.
   
• Read the book, The Essential Client/Server Survival Guide, for an understanding of middleware, client/server network, and Internet operating system API options and pitfalls. 

Things to Watch Out For

• Systems that have to interface electronically with other systems often do not coordinate their schedules for the development of the interface specifications and implementation on both sides of the interfaces.
   
• Often there is a conflict between the use of COTS and the needs for interoperability between systems.
   
• Programs frequently do not identify all the external interfaces during initial systems requirements definition.
   
• Formal configuration-controlled ICWGs for interfaces between systems seem to be the exception instead of the rule as they should be.
   
• Application developers often do not know which features of middleware and COTS DBMS "open" APIs are proprietary vendor extensions of the standard API. As a result, the proprietary extensions are used in a way that negates many of the advantages of using standard APIs.
   
• Internal interface requirements and design descriptions are often not adequately prepared. When they are, they are not put under CM for change control in a developmental baseline. 

Figuring Out Where You Are - Project QuickLook

Chapter 6 contains a series of detailed questions that can be applied to any program to determine the health of its interface control approach. These questions should be applied on a regular basis. However, there are some quick indicators that can be used to see if the interface control process requires more in-depth examination. Specific "quicklook" questions are:

• Did (or will) future system users participate in the development of the human-machine interface of this system? If so, describe this participation and identify at least one individual from each operational organization that participated, or will participate.
   
• How many internal interfaces are there in the system architecture and each of the software CPCI architectures?
   
• Are there any external interfaces to this system for which there is not a formal interface control working group with participation from all systems that use this interface? If so, name each of these external interfaces. 

An inappropriate answer to any of these questions could indicate a more serious problem and merits further investigation.

Additional Considerations


Three important interface concepts to consider in the definition and control of interfaces are:

• Electronic interfaces connect modules in the architecture: hardware/software, application software/databases, application software and databases/middleware and operating systems, connections between application software modules internal to the application, and connections to software modules external to the application. Interfaces also include the user interface (screens and navigation between screens).
  
  
• Application Programming Interface (API) is defined as the interface between the application software and the application platform: System Services API (including APIs for Software Engineering Services and Operating System Services); Communications Service API (including APIs for Network Services); Information Services API (including APIs for Data Management Services and Data Interchange Services); Human/Computer Interaction Services API (including APIs for User Interface Services and Graphics Services). 
  
  
• External Environment Interface (EEI) contains the external entities with which the application platform exchanges information.
  
  
  • The External Environment Interface (EEI) is the interface between the application platform and the external environment across which information is exchanged. 
    
    
  • EEI may be divided into these groups: Human/Computer Interaction Services EEI, Information Services EEI, and Communications Services EEI. 

top

---