Software Life Cycles, Methodologies and Tools

1 PURPOSE...................................................................................................................................2 2 SCOPE........................................................................................................................................2 3 OVERVIEW.................................................................................................................................2 4 DETAILS ....................................................................................................................................2 5 SOFTWARE PROCESS MODELS..............................................................................................2 5.1 INTRODUCTION .....................................................................................................................2 5.2 REFERENCES.........................................................................................................................3 5.3 THE LINEAR SEQUENTIAL MODEL......................................................................................3 5.4 THE PROTOTYPING MODEL .................................................................................................6 5.5 THE INCREMENTAL MODEL .................................................................................................6 5.5.1 THE SPIRAL MODEL ...........................................................................................................7 5.5.2 COMPONENT BASED DEVELOPMENT..............................................................................9 5.6 THE RAD MODEL .................................................................................................................10 6 METHODOLOGIES ..................................................................................................................11 6.1 EFFECTIVE METHODS FOR REQUIREMENT ANALYSIS .................................................11 6.1.1 MODELING .........................................................................................................................11 6.1.2 PARTITIONING ..................................................................................................................12 6.1.3 SPECIFICATION ................................................................................................................12 6.1.4 PROTOTYPING ..................................................................................................................13 6.2 DESIGN METHODS ............................................................................................................14 6.2.1 DATA DESIGN ....................................................................................................................14 6.2.2 ARCHITECTURE DESIGN .................................................................................................15 6.2.2.1 Transform Mapping - ........................................................................................................15 6.2.2.2 Transaction Mapping ........................................................................................................16 6.2.2.3 Design Post processing ...................................................................................................16 6.2.2.4 Architectural Design Optimization ....................................................................................16 6.2.3 INTERFACE DESIGN .........................................................................................................17 6.2.3.1 Internal And External Interface Design..............................................................................17 6.2.3.2 Information Display. .........................................................................................................19 6.2.4 PROCEDURAL DESIGN ....................................................................................................20 6.2.4.1 Structured Programming ..................................................................................................20 6.2.4.2 Graphical Design Notation ...............................................................................................20 6.2.4.3 Tabular Design Notation ..................................................................................................20 6.2.4.4 Program Design Languages (PDL) ..................................................................................21 6.3 TAILORING OF SOFTWARE LIFE CYCLE MODELS ..........................................................21 7 TOOLS .....................................................................................................................................21

1PURPOSE
Use this guideline to help provide a set of development life cycle models and methodologies that can be analyzed and adopted by software development project during the project planning stage. It also provides a pointer to the tools used in the organization.

2SCOPE
This document is applicable to software development projects.

3OVERVIEW
The software development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in a software development project, from an initial feasibility study through maintenance of the completed application.

4DETAILS
Details of various SDLC Models and methodologies are given in following sections.

5SOFTWARE PROCESS MODELS

5.1 INTRODUCTION

The software development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in a software development project, from an initial feasibility study through maintenance of the completed application. Various SDLC methodologies have been developed to guide the processes involved, including the waterfall model (which was the original SDLC method); rapid application development (RAD); the agile model; the spiral model; build and fix and so on. Frequently, several models are combined into some sort of hybrid methodology. In general, an SDLC methodology follows the following steps: 1. The wants and needs for the software are evaluated and the requirements are thrashed out of these needs. 2. The proposed software is designed. Plans are laid out concerning the high level design, architecture modeling and the low level design. 3. The new software is developed. The new components and programs are tested at various levels to validate its conformance to the requirements. 4. Once the new system is up and running for a while, it is exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system are kept up-to-date concerning the latest modifications and procedures. The below section captures some life cycle models Linear Sequential Model

Prototyping Incremental Model (including Spiral Model a variation of Incremental model and the Component based model for object oriented applications) Rapid Application Development

5.2

REFERENCES

[1] IEEE Standard for Developing Software Lifecycle Processes (1996) [2] Software Engineering- A practitioners Approach Roger S Pressman 5th Edition [3] CMMI for Development 1.2 [5] Process Definition Procedure

5.3

THE LINEAR SEQUENTIAL MODEL

The linear sequential model for software engineering is also sometimes called the "classic life cycle" or the "waterfall model". The linear sequential model suggests a systematic, sequential approach to software development that begins at the system level and progresses through Software requirements analysis, design, coding & testing, integration & testing, and maintenance. Modeled after the conventional engineering cycle, the linear sequential model encompasses the following activities:

SE & PI

SRA D CT IT M

System/information engineering and Project Initiation (SE & PI). Because software is always part of the larger system (or business), work begins by establishing requirements for all system elements and then allocating some subset of these requirements to software. This system view is essential when software must interface with other elements such as hardware, people, and gathering at the system level with a small amount of top-level analysis and design. Information engineering encompasses requirements gathering at the strategic business level and at the business area level, estimating size, effort and cost of the software project and planning the execution of the project. Software requirements analysis (SRA). The requirements gathering process is intensified and focused specifically on software. To understand the nature of the program(s) to be built, the software engineer ("analyst") must understand the information domain for the software, as well as required function, behavior, performance, and interfacing. Requirements for both the system and the software are documented and reviewed with the customer. Design (D). Software design is actually a multi-step process that focuses on four distinct attributes of a program: data structure, software architecture, interface representations, and procedural (algorithmic) detail. The design process translates requirements into a representation of the software that can be assessed for quality before code generation begins. Like requirements, the design is documented and becomes part of the software configuration. The design document is reviewed against the requirements document for completeness and correctness. Code generation and Testing (CT). The design must be translated into a machine-readable form. The code generation step performs this task. If design is performed in a detailed manner, code generation can be accomplished mechanically. Once the code has been generated, the smallest testable part is grouped as a unit, and unit testing begins. Each unit is tested against the design specification. The testing process focuses on the logical internals of the software, assuring that all statements have been tested, and on the functional externals - that is, conducting tests to uncover errors and ensure that defined input will produce actual results that agree with required results. Integration & Testing (IT). Once units are tested, they are integrated into modules and/or system, Integration and / or system testing begins as mentioned oboe. The system is tested against the requirements specification. Maintenance (M). Software will undoubtedly undergo change after it is delivered to the customer (a possible exception is embedded software). Change will occur because errors have been encountered, because the software must be adapted to accommodate changes in its external environment (e.g. a change required because of a new operating system or peripheral device), or because the customer requires functional or performance enhancements. Software maintenance reapplies each of the preceding phases to an existing program rather than a new one. The linear sequential model is the oldest and the most widely used paradigm for software engineering. Among the problems that are sometimes encountered when the linear sequential model is applied are: 1. Real projects rarely follow the sequential flow that the model proposes. Although the linear model can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the project team proceeds. 2. It is often difficult for the customer to state all requirements explicitly. The linear sequential model requires this and has difficulty accommodating the uncertainty that exists at the beginning of many projects. 3. The customer must have patience. A working version of the program(s) will not be available until late in the project time-span. A major blunder, if undetected until the working

program is reviewed, can be disastrous. 4. Developers are often delayed unnecessarily. The linear nature of the classic life cycle leads to "blocking states" where some project team members must wait for other members of the team to complete dependent tasks. The time spent waiting can exceed the time spent on productive work. The blocking states tend to be more prevalent at the beginning and end of a linear sequential process. Each of these problems is real. However, the classic life cycle paradigm has a definite and important place in software engineering work. It provides a template into which methods for analysis, design, coding, testing, and maintenance can be placed. The classic life cycle remains one of the most widely used process model for software engineering.

5.4

THE PROTOTYPING MODEL

Often, a customer defines a set of general objectives for software but does not identify details input, processing, or output requirements. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human-machine interaction should take. In these and many other situations, a prototyping paradigm may offer the best approach. The prototyping paradigm begins with initiating a project and requirements gathering. The developer and customer meet to define the overall objectives for the software. They identify whatever requirements are known, and outline areas where further definition is mandatory. A "quick design" then occurs. The quick design focuses on a representation of those aspects of the software that will be visible to the customer / user (e.g., input approaches and output formats). The quick design leads to construction of a prototype. The prototype is evaluated by the customer / user and is used to refine requirements for the software to be developed.. Ideally, the prototype serves as a mechanism for identifying software requirements. If a working prototype is built, the developer attempts to make use of existing program fragments or applies tools (e.g., report generators, window managers, etc.) that enable working programs to be generated quickly. Although problems can occur, prototyping can be an effective paradigm for software engineering. The key is to define the rules of the game at the beginning; that is, the customer and developer must both agree that the prototype is built to serve as a mechanism for defining requirements. It is then discarded (at least in part), and the actual software is engineered with an eye toward quality and maintainability.

5.5

THE INCREMENTAL MODEL

INCREMENTAL LIFE CYCLE REQUIREMENTS

SYSTEM DESIGN
S R A D S R A D S R A D

S R A D

C T

C T

C T

C T

M FINAL SYSTEM

I T

IT

IT

IT

The incremental model combines elements of the linear sequential model (applied repetitively) with the iterative philosophy of prototyping; the incremental model applies linear sequences in a staggered fashion as calendar time progresses. Each linear sequence produces a deliverable "increment" of the software. For example, wordprocessing software developed using the incremental paradigm might deliver basic file management, editing, and document production functions in the first increment; more sophisticated editing and document production capabilities in the second increment. Spelling and grammar checking in the third increment; and advanced page layout capability in the fourth increment. It should be noted that the process flow for any increment could incorporate the prototyping paradigm. When an incremental model is used, the first increment is often a core product. Basic requirements are addressed, but many supplementary features (some known, others unknown) remain undelivered. The core product is used by the customer (or undergoes detailed review). As a result of use and/or evaluation, a plan is developed for the next increment. The plan addresses the modification of the core product to better meet the needs of the customer and the delivery of additional features and functionality. This process is repeated following the delivery of each increment, until the complete product is produced. The incremental process model, like prototyping and other evolutionary approaches, is iterative in nature. But unlike prototyping, the incremental model focuses on the delivery of an operational product with each increment. Early increments are "stripped down" versions of the final product but they do provide capability that serves the user and also provide a platform for evaluation by the user. Incremental development is particularly useful when staffing is unavailable for complete implementation by the business dealings that has been established for the project. Early increments can be implemented with fewer people. If the core product is well received then additional staff (if required) can be added to implement the next increment. In addition, increments can be planned to manage technical risks. For example, a major system might require the availability of new hardware that is under development and whom delivery dates is uncertain. It might be possible to plan early increments in a way that avoids the use of this hardware, thereby enabling partial functionality to be delivered to the end users without inordinate delay. 5.5.1 THE SPIRAL MODEL

The spiral model is a variation of the incremental model (both being evolutionary in nature) that couples the iterative nature of prototyping with the controlled and systematic aspect of the linear sequential model. It provides the potential for rapid development of incremental versions of the software. In the spiral model, software is developed in a series of incremental releases. During early iterations, the incremental release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced. The spiral model is divided into a number of framework activities, also called task regions. Typically, there are between three and six task regions.

Planning Customer Communication Project Entry Customer Evaluation Engineering Risk Analysis Concept Development Projects New Product Development Projects Product Enhancement Projects Product Maintenance Projects Construction and Release

Customer communication - tasks required to establish effective communication between developer and customer. Planning-tasks required defining resources, timelines, and other project related information. Risk analysis-tasks required to assess both technical and management risks Engineering-tasks required to build one or more representations of the application Construction & release-tasks required to construct, test, install and provide user support (e.g., documentation and training) Customer evaluation-tasks required in obtaining customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.

Each of the regions is populated by a series of work tasks that are adapted to the characteristics of the project to be undertaken. For small projects, the number of work tasks and their formality is low. For larger, more critical projects, each task region contains more work tasks that are defined to achieve a higher level of formality. In all cases, the umbrella activities (e.g., software configuration management and software quality assurance) are applied. As this evolutionary process begins, the software engineering team moves around the spiral in a clockwise direction, beginning at the core. The first circuit around the spiral might result in the development of a product specification. Subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software. Each pass through the planning region results in adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from customer evaluation. In addition, the project manager adjusts the planned number of iterations required to complete the software. In essence, the spiral, when characterized in this way, remains operative until the software is retired. There are times when the process is dormant, but whenever a change is initiated, the process starts at the appropriate entry point (e.g., product enhancement). The spiral model is a realistic approach to the development of large-scale systems and software. Because software evolves as the process progresses, the developer and customer better understand and react to risks at each evolutionary level. The spiral model uses prototyping as a risk reduction mechanism, but more important, enables the developer to apply the prototyping approach at any stage in the evolution of the product. It maintains the systematic stepwise approach suggested by the classic life cycle, but incorporates it into an iterative framework that more realistically reflects the real word. The spiral model demands a direct consideration of technical risks at all stages of the project, and if properly applied, should reduce risks before they become problematic. 5.5.2 COMPONENT BASED DEVELOPMENT

The component based development (CBD) incorporates many characteristics of the spiral model it is evolutionary in nature, demanding an iterative approach to the creation of the software. However, the CBD based model composes the applications from prepackaged software components (called classes). Classes created in past projects are stored in class library, and reused for the new projects. If a candidate class does not reside in the class library, it is engineered using the object oriented methods. The first iteration of the application to be built is composed, using classes extracted from the library and any new classed built to meet the unique needs of the application. Process flow then returns to the spiral and will ultimately re-enter the component assembly iteration during subsequent passes through the engineering activity.

The CBD based model leads to the software reuse.

5.6

THE RAD MODEL

Rapid Application Development (RAD) is a linear sequential software development process model that emphasizes an extremely short development cycle. The RAD model is a "highspeed" adaptation of the linear sequential model in which rapid development is achieved by using a component-based construction approach. If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a "fully functional system" within very short time periods (e.g. 60 to 90 days) Used primarily for Business applications; the RAD approach encompasses the following phases

Business Modeling

Data Modeling

Process Modeling

Application Generation

Testing Turnover

&

60 90 Days Business modeling. The information flow among business functions is modeled in a way that answers the following questions: What information drives the business process? What information is generated? Who generates it? Where does the information go? Who processes it? Data modeling. The information flow defined as part of the business-modeling phase is refined into a set of data objects that are needed to support the business. The characteristics (called attributes) of each object are identified and the relationships between these objects are defined.

Process modeling. The data objects defined in the data-modeling phase are transformed to achieve the information flow necessary to implement a business functions. Processing descriptions are created for adding, modifying, deleting, or retrieving a data object. Application generation. RAD assumes the use of fourth generation techniques. Rather than creating software using conventional third generation programming languages, the RAD process work to reuse existing program components (when possible) or create reusable components (when necessary). In all cases, automated tools are used to facilitate construction of the software. Testing and turnover. Since the RAD process emphasizes reuse, many of the program components have already been tested. This reduces overall testing time. However, new components must be tested and all interfaces must be fully exercised. Obviously, the time constraints imposed on a RAD project demand "scaleable scope" If a business application can be modularized in a way that enables each major function to be completed in less than three months (using the approach described above), it is a candidate for RAD. Each major function can be addressed by a separate RAD team and then integrated to form a whole. Like all process models, the RAD approach has drawback For large, but scaleable projects, RAD requires sufficient human resources to create the right number of RAD teams. RAD requires developers and customers who are committed to the rapid-fire activities necessary to complete a system in a much-abbreviated time frame. If commitment is lacking from either constituency, RAD projects will fail.

Not all types of applications are appropriate for RAD. If a system cannot be properly modularized, building the components necessary for RAD will be problematic. If high performance is an issue, and performance is to be achieved through tuning the interfaces to system components, the RAD approach may not work. RAD is not appropriate when technical risks are high. This occurs when a new application makes heavy use of new technology or when the new software requires a high degree of interoperability with existing computer programs.

6METHODOLOGIES
6.1
6.1.1

EFFECTIVE METHODS FOR REQUIREMENT ANALYSIS

MODELING

We create models to gain a better understanding of the actual entity to be built. When the entity is physical thing (a building, a plane, a machine), we can build a model that is identical in form and shape, but smaller in scale. However, when the entity to be built is software, our model must take a different form. It must be capable of modeling the information that software transforms, the functions (and sub functions) that enable the transformation to occur, and the behavior of the system as the transformation is taking place. During software requirements analysis, we create models of the software to be built. The models focus on what the system must do, not on how it does it. In many cases, the model that we create makes 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. Descriptive information can be provided using a natural language or a specialized language for describing requirements. The second and third operational analysis principles require that we build model of function and behavior. Functional models. Software transforms information, and in order to accomplish this, it must perform at least three generic functions: input, processing, and output. When functional models of an application are created, the software engineer focuses on problem-specific functions. The functional model begins with a single context level model (i.e., the name of the software to be built). Over a series of iterations, more and more functional details are provided, until a thorough delineation of all system functionality is represented. Behavioral model. Most software responds to events from the outside world. This stimulus response characteristic forms the basis of the behavioral model. A computer program always exists in some state - an externally observable mode of behavior (e.g., waiting, computing, printing, polling) that is changed only when some event occurs. For example software will remain in the wait state until (1) an internal clock indicates that some time interval has passed, (2) an external event (e.g., a mouse movement) causes an interrupt, or (3) an external system signals the software to act in some manner. A behavioral model creates a representation of the states of the software and the events that cause software to change state. Models created during requirements analysis serve a number of important roles: The model aids the analyst in understanding the information, function, and behavior of a system, thereby making the requirements analysis task easier and more systematic. The model becomes the focal point for review and therefore the key to a determination of completeness, consistency, and accuracy of the specification. The model becomes the foundation for design, providing the designer with an essential representation of software that can be translated into an implementation context. 6.1.2 PARTITIONING

Problems are often too large and complex to be understood as a whole. For this reason, we tend to partition (divide) such problems into parts that can be easily understood and establish interfaces between the parts so that overall function can be accomplished. The information, both functional, and behavioral domains of software can be partitioned. In essence, partitioning decomposes a problem into its constituent parts. Conceptually, we establish a hierarchical representation of information or function and then partition the uppermost element by (1) exposing increasing detail by moving vertically in the hierarchy or (2) decomposing the problem by moving horizontally in the hierarchy. 6.1.3 SPECIFICATION

There is no doubt that the mode of specification has much to do with the quality of solution. Software engineers who have been forced to work with incomplete, inconsistent, or misleading specification have experienced the frustration and confusion that invariably results. The quality, timeliness, and completeness of the software suffer as a consequence. Specification Principles Specification, regardless of the mode through which we accomplish it, may be viewed as a representation process. Requirements are represented in a manner that ultimately leads to successful software implementation. 1. Separate functionality from implementation.

2. Develop a model of the desired behavior of a system that encompasses data and the functional responses of a system to various stimuli from the environment. 3. Establish the context in which software operates by specifying the manner in which other system components interact with software. 4. Define the environment in which the system operates and indicate hows highly intertwined collection of agents react to stimuli in the environment (changes to objects) produced by those agents" 5. Create a cognitive model rather than a design or implementation model. The cognitive model describes a system as perceived by its user community. 6. Recognize that "the specification must be tolerant of incompleteness and augmentable." A specification is always a model - an abstraction - of some real (or envisioned) situation that is normally quite complex. Hence, it will be incomplete and will exist at many levels of details. 7. Establish the content and structure of specification in a way that will enable it to be amenable to change. Representation We have already seen that software requirements may be specified in a variety of ways. However, if requirements are committed to paper or an electronic presentation medium (and they almost always should be!) a simple set of guidelines is well worth following: Representation format and content should be relevant to the problem. A general outline for the content of a software requirements specification can be developed. However, the representation forms contained within the specification are likely to vary with the application area. For example, a specification of a manufacturing automation system would use different zymology, diagrams, and language than the specification for a programming language compiler. Information contained within the specification should be nested. Representations should reveal layers of information so that a reader can move to the level of detail that is required. Paragraph and diagram numbering schemes should indicate the level of detail that is being presented. It is sometimes worthwhile to present the same information at different levels of abstraction to aid in understanding. Diagrams and other notational forms should be restricted in number and consistent in use. Confusing or inconsistent notation, whether graphical or symbolic, degrades understanding and fosters errors. Representations should be revisable, as the content of a specification will change. A CASE tool may be used so that all representations that are affected by each change can be updated when they occur. 6.1.4 PROTOTYPING

This is used in analysis phase when model is the only means by which requirements can be effectively derived. Then this model evolves into production software. Prototyping can be close-ended or open-ended. The close ended is developed only to confirm the requirements and after that is it discarded and the software is developed afresh. Open ended is also called evolutionary proto-typing where the prototype developed in analysis phase is enhanced during design and construction into the final product. The following Table Throwaway type will guide in selection of suitable approach:

Question

Evolutionary type open-ended

More Preliminary analysis required

close -ended Is the application domain understood yes yes No

Can the yes problem be Modeling? Is customer certain of basic requirements Are requirements established and stable? Are requirements ambiguous Are there contradictions in requirements yes/no

yes

No

yes/no

No

No

Yes

Yes

Yes

No

Yes

Yes

No

Yes

6.2

DESIGN METHODS

Design has been described as a multi-step process in which representations of data structure, program structure, interface characteristics, and procedural details are synthesized from information requirements. Software design methods are derived from consideration of each of the three domains of the analysis model - the data, functional, and behavioral domains. Each design method gives steps to produce data design, architectural design, interface design and a procedural design. 6.2.1 DATA DESIGN

The primary activity during data design is to select logical representations of data objects identified during requirements definition and specifications phase. A well-designed data can lead to better program structure and modularity and reduce procedural complexity. The following principles apply to data specifications The systematic analysis principles that is applied to function and behavior is applied to data. All data structures and operations that are to be performed should be identified. A data dictionary should be established and used to define both data and program design. Low-level design decisions should be deferred until late in the design process The representation of data structure should be known only to those modules that must

direct the use of data contained within the structure A library of useful data structure and the operations that can be applied to them should be developed. A software design and programming language should support the specification and realization of abstract data type. ARCHITECTURE DESIGN

6.2.2

The primary objective of architectural design is to develop a modular program structure and represent control relationships between modules. In addition, architectural design also melds the program structure and data structure, defining interfaces that enable data to flow throughout the program. Dataflow oriented design is an architectural design method that allows a convenient transformation from analysis model to design description of program structure. This transformation from information flow (represented as dataflow) to structure is accompanied as part of 5-step process. The type of information flow that is established. Flow boundaries are indicated. Design Flow Diagram (DFD) is mapped into program structure. Control hierarchy is defined by factoring The resultant structure is refined using design measures and heuristics. Transform Mapping -

6.2.2.1

Transform mapping is set of design steps that allow DFD with transform flow characteristics to be mapped into a predefined template for program structure. It has the following design steps. Step 1. Review the fundamental system model. The fundamental system model encompasses the level 0 DFD and supporting information. In actuality the design steps begins with an evaluation of both the system specification and the software requirements specification. Step 2. Review and refine data flow diagrams for the software. Information obtained from analysis model contained in the software requirements specification is refined to produce greater detail. Step 3. Determine whether the DFD has transform or transaction flow characteristics. In general, information flow within a system can always be represented as a transform. Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries. Step 5. Perform "first-level factoring." Program structure represents a top-down distribution of control. Factoring results in a program structure in which top-level modules perform decisionmaking and low-level modules perform most input, computational, and output work. Middlelevel modules perform some control and do moderate amounts of work. Step 6. Perform "second-level factoring". Second level factoring is accomplished by mapping individual transforms (bubbles) of a DFD into appropriate modules within the program structure. Information that passes into and out of the module (an interface description); Information that is retained by a module, e.g., data stored in a local data structure; A procedural narrative that indicates major decisions points and tasks; and A brief discussion of restrictions and special features (e.g., file I/O, hardware dependent characteristics, special timing requirements.)

6.2.2.2

Transaction Mapping

In many software applications, a single data item triggers one or a number of information flows that affect a function implied by the triggering data item. The data item is called a transaction. Design Steps Step 1. Review the fundamental system model. Step 2. Review and refine data flow diagrams for the software. Step 3 Determine whether the DFD has transform or transaction flow characteristics. Step 4 Identify the transaction center and the flow characteristics along each of the action paths. Step 5 Map the DFD in a program structure amendable to transaction processing. Step 6 Factor and refine the transaction structure and the structure of each action path. Step 7. Refine the first iteration program structure using design heuristics for improved software quality. 6.2.2.3 Design Post processing After structure has been developed and refined, the following tasks must be completed: A processing narrative must be developed for each module. An interface description is provided for each module. Local and global data structures are defined. All design restrictions/limitations are noted. A design review is conducted. "Optimization" is considered (if required and justified). A processing narrative is (ideally) an unambiguous, bounded description of processing that occurs within a module. The narrative described processing tasks, decisions, and I/O. The interface description requires the design of internal module interfaces, external system interfaces and the human - computer interface. The design of data structures can have a profound impact on program structure and the procedural details for each module. Restrictions and/or limitations for each module are also documented. Typical topics for discussion include restriction of data type or format, memory or timing limitations, bounding values or quantities of data structures, special cases not considered, and specific characteristics of an individual module. The purpose of a restrictions/ limitations section is to reduce the number of errors introduced because of assumed functional characteristics. Once design documentation has been developed for all modules, a design review is conducted. The review emphasizes traceability to software requirements, quality of program structure, interface descriptions, data structure descriptions, implementation and test practicality, and maintainability. 6.2.2.4 Architectural Design Optimization 1. Develop and refine program structure without concern for performance critical optimization. 2. Use CASE tools that simulate run-time performance to isolate areas of inefficiency. 3. During later design interactions, select modules that are suspect "time hogs" and carefully develop procedures (algorithms) for time efficiency. 4. Code in an appropriate programming language. 5. Instrument the software to isolate modules that account for heavy processor utilization. 6. If necessary, redesign or recode in machine-dependent language to improve efficiency.

6.2.3

INTERFACE DESIGN

Interface design focuses on three areas of concern: 1. the design of interfaces between software modules; 2) the design of interfaces between the software and other nonhuman producers and consumers of information (i.e., other external entities); and 3) the design of the interface between a human (i.e., the user) and the computer. 6.2.3.1 Internal And External Interface Design The design of internal program interfaces sometimes called intermodular interface design, is driven by the data that must flow between modules and the characteristics of the programming language in which the software is to be implemented. User Interface Design 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. A design model of the entire system incorporates data, architectural interface, and procedural representations of the software. The requirements specification may establish certain constraints that help to define the user of the system, but the interface design is often only incidental to the design model. The user model depicts the profile of end users of the system. To build an effective user interface, "all design should begin with an understanding of the intended users. Novices - no syntactic knowledge of the system and little semantic knowledge of the application or computer usage in general; Knowledgeable, intermittent users - reasonable semantic knowledge of the application, but relatively low recall of syntactic information necessary to use the interface; and Knowledgeable, frequent users - good semantic and syntactic knowledge that often leads to the "power-user syndrome," that is, individuals who look for shortcuts and abbreviated modes of interaction.

The system perception (users model) is the image of the system that an end user carries in his or her head. For example, if the user of a particular word processor were asked to describe its operation, the system perception would guide the response. The accuracy of the description will depend upon the users profile (e.g., novices would provide a sketchy response at best) and overall familiarity with software in the application domain. A user who understands word processors fully, but has only worked with the specific word processor once, might actually be able to provide a more complete description of its function that the novice who has spent weeks trying to learn the system. Design Issues System response time is the primary complaint for many interactive E-Systems. In general, system response time is measured from the point at which the user performs some control action (e.g., hits the return key or clicks a mouse) until the software responds with desired output or action. System response time has two important characteristics, length and variability. If the length of time for system response is too long, user frustration and stress is the inevitable result. However, a very brief response time can also be detrimental if the user is being paced by the interface. A rapid response may force the user to rush and therefore make mistakes. Variability refers to the deviation from average response time, and in many ways, it is the

more important of the response time characteristics. Low variability enables the user to establish a rhythm, even if response time is relatively long. For example, one-second response to a command is preferable to a response that values from 0.1 to 2.5 seconds. The user is always off balance, always wondering whether something "different" has occurred behind the scenes. Two different types of help facilities are encountered: integrated and add-on. An integrated help facility is designed into the software from the beginning. It is often context sensitive, enabling the user to select from these topics that are relevant to the actions currently being performed. Obviously this reduces the time required for the user to obtain help and increases the "friendliness" of the interface. An add-on help facility is added to the software after the system has been built. In many ways, it is really an on-line users manual with limited query capability. The user may have to search through a list of hundreds of topics to find appropriate guidance, often making many false starts and receiving much irrelevant information. There is little doubt that the integrated help facility is preferable to the add-on approach. The number of design issues must be addressed when a help facility is considered: Will help be available for all system functions and at all times during system interaction? Options include help only for a subset of all functions and actions, and help for all functions. How will the user request help? Options include a help menu, a special function key, and a HELP command. How will help be represented? Options include a separate window, a reference to a printed document (less than ideal), and a one or two line suggestion produced in a fixed screen location. How will the user return to normal interaction? Options include a return button displayed on the screen and a function key or control sequence. How will help information be structured? Option include a "flat" structure in which all information is accessed through a keyword, a layered hierarchy of information that provides increasing detail as the user proceeds into the structure, and the use of hypertext. The message should describe the problem in jargon that the user can understand. The message should provide constructive advice for recovering from the error. The message should indicate any negative consequences of the error (e.g., potentially corrupted data files) so that the user can check to ensure that they have not occurred (or correct them if they have). The message should be accompanied by an audible or visual cue. That is, a beep might be generated to accompany the display of the message, or the message might flash momentarily or be displayed in a color that is easily recognizable as the "error color." The message should be "nonjudgmental". That is, the wording should never place blame on the user. Will every menu option have a corresponding command? What form will commands take? Options include a control sequence (e.g., ^P), function keys, and a typed word. How difficult will it be to learn and remember the commands? What can be done if a command is forgotten? Can commands be customized or abbreviated by the user? Interface Design Guidelines Be consistent. Use consistent formats for menu selection, command input, data display, and the myriad other functions that occur in a HCI.

Offer meaningful feedback. Provide the user with visual and auditory feedback to ensure that two-way communication (between user and interface) is established. Ask for verification of any nontrivial destructive action. If a user requests the deletion of a file, indicates that substantial information is to be overwritten, or asks for the termination of a program, an "Are you sure." message should appear. Permit easy reversal of most actions. UNDO or REVERSE functions have saved tens of thousands of end users from millions of hours of frustration. Reversal should be available in every interactive application. Reduce the amount of information that must be memorized between actions. The user should not be expected to remember a list of numbers or names so that he or she can reuse them in a subsequent function. Memory load should be minimized. Seek efficiency in a dialog, motion and thought. Keystrokes should be minimized, the distance a mouse must travel between picks should be considered in designing screen layout, and the user should rarely encounter a situation where he or she asks, "Now what does this mean?" Forgive mistakes. The system should protect itself from errors that might cause it to fail. Categorize activities by function and organize screen geography accordingly. One of the key benefits of the pull-down menu is the ability to organize commands by type. In essence, the designer should strive for "cohesive" placement of commands and actions. Provide help facilities that are context sensitive. Use simple action verbs or short verb phrases to name commands. A lengthy command name is more difficult to recognize and recall. It may also take up unnecessary space in menu lists. 6.2.3.2 Information Display. Display only that information that is relevant to the current context. The user should not have to wade through extraneous data, menus, and graphics to obtain information relevant to a specific system function. Dont bury the user with data; use a presentation format that enables rapid assimilation of information. Graphs or charts should replace voluminous tables. Use consistent labels, standard abbreviations, and predictable colors. The meaning of a display should be obvious without reference to some outside source of information. Allow the user to maintain visual context. If graphical representations are scaled up and down, the original image should be displayed constantly (in reduced form at the corner of the display) so that the user understands the relative location of the portion of the image that is currently being viewed. Produce meaningful error messages. Use upper and lower case, indentation, and text grouping to aid in understanding. Much of the information imparted by a HCI is textual, and the layout and form of the text has a significant impact on the case with which the user assimilates information. Use windows to compartmentalize different types of information. Windows enable the user to "keep" many different types of information within easy reach. Use analog displays to represent information that is more easily assimilated with this form of representation. For example, a display of holding tank pressure in an oil refinery would have little impact if a numeric representation were used. However, if a thermometer-like display were used, vertical motion and color changes could be used to indicate dangerous pressure conditions. This would provide the user with both absolute and relative information.

Consider the available geography of the display screen and use it efficiently. When multiple windows are to be used, space should be available to show at least some portion of each. In addition, screen size (a system engineering issue) should be selected to accommodate the type of application that is to be implemented. Data Input Minimize the number of input actions required of the user. Above all, reduce the amount of typing that is required. This can be accomplished by using the mouse to select from predefined sets of input, using a "sliding scale" to specify input data across a range of values, and using macros that enable a single keystroke to be transformed into a more complex collection of input data. Maintain consistency between information display and data input. The visual characteristics of the display (e.g., text size, color, and placement) should be carried over to the input domain. Allow the user to customize input. An expert user might decide to create custom commands or dispense with some types of warning messages and action verification. The HCI should allow this. Interaction should be flexible but also tuned to the users preferred mode of input. The user model will assist in determining which mode of input is preferred. A clerical worker might be very happy with keyboard input, while a manager might be more comfortable using a point and pick device such as a mouse. Deactivate commands that are inappropriate in the context of current actions. This protects the user from attempting some action that could result in an error. Let the user control the interactive flow. The user should be able to jump unnecessary actions, change the order of required actions (when possible in the context of an application), and recover from error conditions without exiting from the program. Provide help to assist with all input actions. Eliminate "Mickey mouse" input. Do not require the user to specify units for engineering input (unless there may be ambiguity). Do not require the user to type .00 for whole number dollar amounts, provide default values whenever possible, and never require the user to enter information that can be acquired automatically or computed within the program. 6.2.4 PROCEDURAL DESIGN

Procedural design occurs after data, architectural, and interface design has been established. Following gives different modes for representing procedural detail: 6.2.4.1 Structured Programming Structured programming uses a set of logical constructs from which any program could be formed. The constructs are sequence, condition, and repetition. Sequence implements processing steps that are essential in the specification of any algorithm, condition provides the facility for selected processing based on some logical occurrence, and repetition provides for looping. 6.2.4.2 Graphical Design Notation Graphical design notation provides excellent pictorial patterns that readily depict procedural details. The graphical tools commonly used are Flowchart 6.2.4.3 Tabular Design Notation Tabular design Notations like decision table helps to evaluate a complex combination of

conditions and select appropriate actions. Decision tables provide a notation that translates actions and conditions into a tabular form. 6.2.4.4 Program Design Languages (PDL) Program Design Languages also called Structured English or pseudo-code, looks something like any modern programming language but uses narrative text like English embedded directly within PDL statements.

6.3

TAILORING OF SOFTWARE LIFE CYCLE MODELS

Two or more models can be combined together depending on the project deliverables, customer involvement, etc. In cases where the lifecycle models are tailored the identified phases will be captured in the Project Management System Summary (ENG 339).

7TOOLS
Refer to the Organization Reference Document (ORD) of respective organization for recommended tools. These tools comprise the work environment also.