GOAL 

BENEFITS 

THE  CS 406/407 PROJECT  

Frame Based Slides   Plain Slides     Intel Project Homepage 

INTEL FACTORY INFORMATION AND CONTROL SYSTEM (IFICS)  

PROJECT MANAGEMENT  
 
 

Many documentation tasks could benefit from a test documentation tool. Test cases could be found using a search tool. Documents could be kept under revision control. Forms could make it easier for testers to create new test documents, log information about test cases that were executed, and submit test incident reports. Reports could show which test cases have revealed the most defects, how many test cases a tester has performed, or which tests have not been executed since the most recent software build.   

Intel and students enrolled in CS 406/407 will both benefit in a special way. Software professionals must improve the state of software engineering as it is practiced today. Intel will encourage solid software engineering practices throughout the life cycle of a software project. Everyone will benefit by the relationships developed and lessons learned as future professionals in the software industry work closely with an industry leader.    
 

Intel will define requirements for a tool. Dr. Mathur will then select groups to work on these requirements, understand them, refine them, and produce a design. The design will be discussed with Intel rep(s). In the spring semester the design will be finalized and coding will begin. Intel rep(s) will be involved (long distance) throughout the project. Less than 60 minutes per week (on the average) is expected of Intel rep(s) on this project.  

The theory in this proposal is based on the book: Software Engineering: A Practitioner's Approach, 4th Edition, Roger S. Pressman,  1997, The Mc-Graw Hill Companies, Inc. 

The way enhancements and revisions to IFICS software are tested evolved over time. In the beginning, a small team of programmers and a manager owned responsibility for designing, coding, and testing software, creating documentation, and providing customer support. The application grew and more programmers were added to the development team. Finally, the system reached a point where it was no longer possible for one or two people to test everything before a new software release was distributed.  

Today, the development process basically consists of three phases: analysis, coding, and testing. After coding is complete and developers have had someone else test their changes, the development team stops what they are doing to test the entire system. A dedicated test facility, test teams, test team leaders, and test coordinators have proven to be crucial to the success of the testing phase of development.  

The development team is currently implementing the IEEE Standard for Software Engineering (ANSI/IEEE Std. 829-1991). First, test coordinators worked to develop test plans. Then features to be tested were identified and expanded upon from release to release. From the beginning, test incident reports played an important role in tracking defects found during testing. Recently, test teams developed detailed test design specifications for the first time. The next step is to specify details of the test cases identified by test design specifications. When the process is mature, test procedure specifications will supplement test case specifications and lead naturally to the creation of "how to" user documentation.  

Testers are using the Web as a tool for publishing and retrieving test documentation. All work is being done by hand using shared drives and HTML editors including Word, Front Page, and Navigator Gold. The goal of this project is to identify ways to improve the way test documentation is created, used, and maintained. To be successful, it must be easy to migrate the current legacy process to new tools.  

For more information about the IEEE Standard for Software Testing, refer to the Aonix Web site, page http://www.aonix.com./Products/Testing/moreless.html 

• Overview of Software Engineering Process
• Initiating the process
• Problem Analysis 
• Modelling
• Data objects: attributes and relationships
• Data objects: specification
• Roles
• Organizational units
• Things
• Places
• Events
• Structures
• Occurrences
• External entities

• What is the problem to be solved?
• What are the characteristics of the entity that is used to solve the problem?
• How will the entity (and the solution) be realized?
• How will the entity be constructed?
• What approach will be used to uncover errors that were made in the design and construction of the entity?
• How will the entity be supported over the long term, when corrections, adaptations, and enhancements are requested by users of the entity?

Initiating the Process

An initial meeting between a representative from Intel and students at Purdue will be held. The information necessary for bridging the gap between the customer (Intel) and the developer (students in CS 406/407) must be defined.  

Ask context free questions. The first set of questions focusing on the customer, the overall goals, and the benefits might include:  
 

• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution?
The next set of questions enable the developer to gain a better understanding of the problem and the customer to voice his or her perceptions about a solution:  
 
• How would you [the customer] characterize "good" output that would be generated by a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the environment in which the solution will be used?
• Are there special performance issues or constraints that will affect the way the solution is approached?
Finally, focus on the effectiveness of the meeting:  
 
• Are you the right person to answer these questions? Are your answers "official?"
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Is there anyone else who can provide additional information?
• Is there anything else that I should be asking you?

Analyzing the Problem: Modeling

Models of the system to be built are created during software requirements analysis, The models focus on what the system must do, not on how it does it. In many cases the models created make use of a graphical notation that depicts information, processing, system behavior, and other characteristics as distinct and recognizable symbols. Other parts of the model may be purely textual.  

For the CS 406/407 project, the customer wants to begin with a series of modeling tasks that lead to a comprehensive specification of requirements and a comprehensive design representation for the software to be built. The analysis model must achieve three primary objectives: (1) describe what the customer requires, (2) establish a basis for the creation of a software design, and (3) define a set of requirements that can be validated once the software is built.  

To accomplish these objectives, the analysis model derived during "structured analysis" might be used. The structured analysis model has the following form.  

At the core of this model lies the data dictionary - a repository that contains descriptions of all data objects consumed or produced by the software. The entity-relationship diagram (ERD) depicts relationships between data objects. The ERD is the notation that is used to conduct the data modeling activity.  

The data flow diagram (DFD) serves two purposes: (1) to provide an indication of how data are transformed as they move through the system, and (2) to depict the functions (and subfunctions) that transform the data flow. The DFD provides additional information that is used during the analysis of the information domain and serves as a basis for the modeling of functions.  
  

• The state-transition diagram (STD) indicates how the system behaves as a consequence of external events. To accomplish this, the STD represents the various modes of behavior (called states) of the system and the manner in which transitions are made from state to state. The STD serves as the basis for beharioral modeling.

A data object is a representation of almost any composite information that must be understood by software. By composite information, we mean something that has a number of different properties or attributes. A data object encapsulates data only - there is no reference within a data object to operations that act on the data.  

A data object can be a/an: 

• external entity (e.g. anything that produces or consumes information)
• thing (e.g. a report or display)
• occurrence (e.g. a telephone call)
• event (e.g. an alarm)
• role (e.g. salesperson)
• organizational unit (e.g. an accounting department)
• place (e.g. a warehouse)
• structure (e.g. a file)