SDLC Guideline

7/29/2019 SDLC Guideline

1/21

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 ................................................................... ...........95.6 THE RAD MODEL .................................................................................................................10

6 METHODOLOGIES ..................................................................................................................11

6.1 EFFECTIVE METHODS FOR REQUIREMENT ANALYSIS .................................................11

6.1.1 MODELING .........................................................................................................................116.1.2 PARTITIONING ..................................................................................................................126.1.3 SPECIFICATION ............................................................................................................ ....126.1.4 PROTOTYPING ..................................................................................................................13

6.2 DESIGN METHODS ............................................................................................................14

6.2.1 DATA DESIGN ....................................................................................................................146.2.2 ARCHITECTURE DESIGN .................................................................................................156.2.2.1 Transform Mapping - ........................................................................................................15

6.2.2.2 Transaction Mapping ........................................................................................................166.2.2.3 Design Post processing .................................................................................................. .166.2.2.4 Architectural Design Optimization ....................................................................................166.2.3 INTERFACE DESIGN .........................................................................................................176.2.3.1 Internal And External Interface Design ..............................................................................176.2.3.2 Information Display. .............................................................................................. ...........196.2.4 PROCEDURAL DESIGN ....................................................................................................206.2.4.1 Structured Programming ................................................................................................. .206.2.4.2 Graphical Design Notation ...............................................................................................206.2.4.3 Tabular Design Notation ..................................................................................................206.2.4.4 Program Design Languages (PDL) ..................................................................................21

6.3 TAILORING OF SOFTWARE LIFE CYCLE MODELS ..........................................................21

7 TOOLS ................................................................................................................................... ..21


2/21

1PURPOSE

Use this guideline to help provide a set of development life cycle models and methodologiesthat can be analyzed and adopted by software development project during the projectplanning 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 projectmanagement 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 projectmanagementthat describes the stages involved in a software development project, from aninitial feasibility study through maintenance of the completed application. Various SDLCmethodologies have been developed to guide the processes involved, including thewaterfallmodel(which was the original SDLC method); rapid application development (RAD); the agilemodel; 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 arethrashed out of these needs.

2. The proposed software is designed. Plans are laid out concerning the high leveldesign, architecture modeling and the low level design.

3. The new software is developed. The new components and programs are tested atvarious 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 keptup-to-date concerning the latest modifications and procedures.

The below section captures some life cycle models

Linear Sequential Model
http://searchsmb.techtarget.com/sDefinition/0,,sid44_gci951200,00.htmlhttp://searchsmb.techtarget.com/sDefinition/0,,sid44_gci951200,00.htmlhttp://searchsmb.techtarget.com/sDefinition/0,,sid44_gci951200,00.htmlhttp://searchsmb.techtarget.com/sDefinition/0,,sid44_gci951200,00.htmlhttp://searchsmb.techtarget.com/sDefinition/0,,sid44_gci951200,00.htmlhttp://searchsmb.techtarget.com/sDefinition/0,,sid44_gci951200,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci519580,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci519580,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci519580,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci519580,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci214246,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci755347,00.htmlhttp://searchsmb.techtarget.com/sDefinition/0,,sid44_gci951200,00.htmlhttp://searchsmb.techtarget.com/sDefinition/0,,sid44_gci951200,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci519580,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci519580,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci214246,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci755347,00.htmlhttp://searchsmb.techtarget.com/sDefinition/0,,sid44_gci951200,00.htmlhttp://searchsmb.techtarget.com/sDefinition/0,,sid44_gci951200,00.html


3/21

Prototyping

Incremental Model (including Spiral Model a variation of Incremental model andthe 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 "classiclife cycle" or the "waterfall model". The linear sequential model suggests a systematic,sequential approach to software development that begins at the system level and progressesthrough Software requirements analysis, design, coding & testing, integration & testing, andmaintenance. Modeled after the conventional engineering cycle, the linear sequential modelencompasses the following activities:

SE& PI

SRA

D

CT

IT

M


4/21

System/information engineering and Project Initiation (SE & PI). Because software isalways part of the larger system (or business), work begins by establishing requirements forall system elements and then allocating some subset of these requirements to software. Thissystem view is essential when software must interface with other elements such ashardware, people, and gathering at the system level with a small amount of top-levelanalysis and design. Information engineering encompasses requirements gathering at the

strategic business level and at the business area level, estimating size, effort and cost of thesoftware project and planning the execution of the project.

Software requirements analysis (SRA). The requirements gathering process is intensifiedand 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 boththe 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 distinctattributes of a program: data structure, software architecture, interface representations, andprocedural (algorithmic) detail. The design process translates requirements into arepresentation of the software that can be assessed for quality before code generationbegins. Like requirements, the design is documented and becomes part of the software

configuration. The design document is reviewed against the requirements document forcompleteness and correctness.

Code generation and Testing (CT). The design must be translated into a machine-readableform. The code generation step performs this task. If design is performed in a detailedmanner, code generation can be accomplished mechanically. Once the code has beengenerated, the smallest testable part is grouped as a unit, and unit testing begins. Each unitis tested against the design specification. The testing process focuses on the logicalinternals of the software, assuring that all statements have been tested, and on thefunctional externals - that is, conducting tests to uncover errors and ensure that defined inputwill 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 testedagainst the requirements specification.

Maintenance (M). Software will undoubtedly undergo change after it is delivered to thecustomer (a possible exception is embedded software). Change will occur because errorshave been encountered, because the software must be adapted to accommodate changes inits external environment (e.g. a change required because of a new operating system orperipheral device), or because the customer requires functional or performanceenhancements. Software maintenance reapplies each of the preceding phases to an existingprogram rather than a new one.

The linear sequential model is the oldest and the most widely used paradigm for softwareengineering. Among the problems that are sometimes encountered when the linearsequential model is applied are:

1. Real projects rarely follow the sequential flow that the model proposes. Although the linearmodel can accommodate iteration, it does so indirectly. As a result, changes can causeconfusion as the project team proceeds.

2. It is often difficult for the customer to state all requirements explicitly. The linear sequentialmodel requires this and has difficulty accommodating the uncertainty that exists at thebeginning of many projects.

3. The customer must have patience. A working version of the program(s) will not beavailable until late in the project time-span. A major blunder, if undetected until the working


5/21

program is reviewed, can be disastrous.

4. Developers are often delayed unnecessarily. The linear nature of the classic life cycleleads to "blocking states" where some project team members must wait for other members ofthe team to complete dependent tasks. The time spent waiting can exceed the time spenton productive work. The blocking states tend to be more prevalent at the beginning and endof a linear sequential process.

Each of these problems is real. However, the classic life cycle paradigm has a definite andimportant place in software engineering work. It provides a template into which methods foranalysis, design, coding, testing, and maintenance can be placed. The classic life cycleremains one of the most widely used process model for software engineering.


6/21

5.4 THE PROTOTYPING MODEL

Often, a customer defines a set of general objectives for software but does not identifydetails 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 formthat human-machine interaction should take. In these and many other situations, aprototyping paradigm may offer the best approach.

The prototyping paradigm begins with initiating a project and requirements gathering. Thedeveloper and customer meet to define the overall objectives for the software. They identifywhatever 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 ofthe software that will be visible to the customer / user (e.g., input approaches and outputformats). The quick design leads to construction of a prototype. The prototype is evaluatedby 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 aworking 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 workingprograms to be generated quickly.

Although problems can occur, prototyping can be an effective paradigm for softwareengineering. The key is to define the rules of the game at the beginning; that is, the customerand developer must both agree that the prototype is built to serve as a mechanism fordefining requirements. It is then discarded (at least in part), and the actual software isengineered with an eye toward quality and maintainability.

5.5 THE INCREMENTAL MODEL

SR

A

D

CT

IT

M

SR

A

D

CT

IT

M

SR

A

D

CT

IT

M

SR

A

D

CT

IT

M

INCREMENTAL LIFE

CYCLE

REQUIREMENTS

SYSTEM DESIGN

M FINAL SYSTEM


7/21

The incremental model combines elements of the linear sequential model(applied repetitively) with the iterative philosophy of prototyping; the incremental modelapplies linear sequences in a staggered fashion as calendar time progresses. Each linearsequence produces a deliverable "increment" of the software. For example, word-processing software developed using the incremental paradigm might deliver basic filemanagement, editing, and document production functions in the first increment; moresophisticated editing and document production capabilities in the second increment.Spelling and grammar checking in the third increment; and advanced page layout capabilityin the fourth increment. It should be noted that the process flow for any increment couldincorporate the prototyping paradigm.

When an incremental model is used, the first increment is often a core product. Basicrequirements are addressed, but many supplementary features (some known, othersunknown) remain undelivered. The core product is used by the customer (or undergoesdetailed review). As a result of use and/or evaluation, a plan is developed for the nextincrement. The plan addresses the modification of the core product to better meet the needsof the customer and the delivery of additional features and functionality. This process isrepeated following the delivery of each increment, until the complete product is produced.

The incremental process model, like prototyping and other evolutionary approaches, isiterative in nature. But unlike prototyping, the incremental model focuses on the delivery ofan operational product with each increment. Early increments are "stripped down" versionsof the final product but they do provide capability that serves the user and also provide aplatform for evaluation by the user.

Incremental development is particularly useful when staffing is unavailable for completeimplementation by the business dealings that has been established for the project. Earlyincrements can be implemented with fewer people. If the core product is well received thenadditional 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 mightrequire 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 thishardware, thereby enabling partial functionality to be delivered to the end users withoutinordinate 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 ofthe linear sequential model. It provides the potential for rapid development of incrementalversions of the software. In the spiral model, software is developed in a series of incrementalreleases. During early iterations, the incremental release might be a paper model orprototype. During later iterations, increasingly more complete versions of the engineeredsystem 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.


8/21

Planning

Customer

Communication

RiskAnalysis

CustomerEvaluation

Construction andRelease

Engineering

ProjectEntry

Concept Development Proje

Product Maintenance Projec

Product Enhancement Proje

New Product Development P


9/21

Customer communication - tasks required to establish effective communicationbetween developer and customer.

Planning-tasks required defining resources, timelines, and other project relatedinformation.

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 usersupport (e.g., documentation and training)

Customer evaluation-tasks required in obtaining customer feedback based onevaluation of the software representations created during the engineering stage andimplemented during the installation stage.

Each of the regions is populated by a series of work tasks that are adapted to thecharacteristics of the project to be undertaken. For small projects, the number of work tasksand their formality is low. For larger, more critical projects, each task region contains morework tasks that are defined to achieve a higher level of formality. In all cases, the umbrellaactivities (e.g., software configuration management and software quality assurance) areapplied.

As this evolutionary process begins, the software engineering team moves around the spiralin a clockwise direction, beginning at the core. The first circuit around the spiral might resultin the development of a product specification. Subsequent passes around the spiral mightbe used to develop a prototype and then progressively more sophisticated versions of thesoftware. 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. Inaddition, the project manager adjusts the planned number of iterations required to completethe software.

In essence, the spiral, when characterized in this way, remains operative until the software isretired. There are times when the process is dormant, but whenever a change is initiated, theprocess starts at the appropriate entry point (e.g., product enhancement).

The spiral model is a realistic approach to the development of large-scale systems andsoftware. Because software evolves as the process progresses, the developer and customerbetter understand and react to risks at each evolutionary level. The spiral model usesprototyping as a risk reduction mechanism, but more important, enables the developer toapply the prototyping approach at any stage in the evolution of the product. It maintains thesystematic stepwise approach suggested by the classic life cycle, but incorporates it into aniterative framework that more realistically reflects the real word. The spiral model demands adirect 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 thesoftware. However, the CBD based model composes the applications from prepackagedsoftware components (called classes). Classes created in past projects are stored in classlibrary, and reused for the new projects. If a candidate class does not reside in the classlibrary, it is engineered using the object oriented methods. The first iteration of theapplication to be built is composed, using classes extracted from the library and any newclassed built to meet the unique needs of the application. Process flow then returns to thespiral and will ultimately re-enter the component assembly iteration during subsequentpasses through the engineering activity.


10/21

The CBD based model leads to the software reuse.

5.6 THE RAD MODEL

Rapid Application Development (RAD) is a linear sequential software development processmodel that emphasizes an extremely short development cycle. The RAD model is a "high-

speed" adaptation of the linear sequential model in which rapid development is achieved byusing a component-based construction approach. If requirements are well understood andproject scope is constrained, the RAD process enables a development team to create a "fullyfunctional system" within very short time periods (e.g. 60 to 90 days) Used primarily forBusiness applications; the RAD approach encompasses the following phases

Business modeling. The information flow among business functions is modeled in a waythat answers the following questions: What information drives the business process? Whatinformation is generated? Who generates it? Where does the information go? Whoprocesses it?

Data modeling. The information flow defined as part of the business-modeling phase isrefined 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 objectsare defined.

BusinessModeling

Data Modeling

ProcessModeling

ApplicationGeneration

Testing &Turnover

60 90Days


11/21

Process modeling. The data objects defined in the data-modeling phase are transformed toachieve the information flow necessary to implement a business functions. Processingdescriptions are created for adding, modifying, deleting, or retrieving a data object.

Application generation. RAD assumes the use of fourth generation techniques. Ratherthan creating software using conventional third generation programming languages, the RADprocess work to reuse existing program components (when possible) or create reusablecomponents (when necessary). In all cases, automated tools are used to facilitateconstruction of the software.

Testing and turnover. Since the RAD process emphasizes reuse, many of the programcomponents have already been tested. This reduces overall testing time. However, newcomponents must be tested and all interfaces must be fully exercised.

Obviously, the time constraints imposed on a RAD project demand "scaleable scope" If abusiness application can be modularized in a way that enables each major function to becompleted in less than three months (using the approach described above), it is a candidatefor RAD. Each major function can be addressed by a separate RAD team and thenintegrated 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 theright number of RAD teams.

RAD requires developers and customers who are committed to the rapid-fire activitiesnecessary to complete a system in a much-abbreviated time frame. If commitment islacking from either constituency, RAD projects will fail.

Not all types of applications are appropriate for RAD. If a system cannot be properlymodularized, building the components necessary for RAD will be problematic. If highperformance is an issue, and performance is to be achieved through tuning the interfaces tosystem components, the RAD approach may not work.

RAD is not appropriate when technical risks are high. This occurs when a new applicationmakes heavy use of new technology or when the new software requires a high degree of

interoperability with existing computer programs.

6METHODOLOGIES

6.1 EFFECTIVE METHODS FOR REQUIREMENT ANALYSIS

6.1.1 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 identicalin form and shape, but smaller in scale. However, when the entity to be built is software, ourmodel must take a different form. It must be capable of modeling the information thatsoftware transforms, the functions (and sub functions) that enable the transformation tooccur, 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. Themodels focus on what the system must do, not on how it does it. In many cases, the modelthat we create makes use of a graphical notation that depicts information, processing,system behavior, and other characteristics as distinct and recognizable symbols. Other parts


12/21

of the model may be purely textual. Descriptive information can be provided using a naturallanguage or a specialized language for describing requirements.The second and third operational analysis principles require that we build model of functionand behavior.

Functional models. Software transforms information, and in order to accomplish this, itmust perform at least three generic functions: input, processing, and output. When functionalmodels of an application are created, the software engineer focuses on problem-specificfunctions. The functional model begins with a single context level model (i.e., the name ofthe software to be built). Over a series of iterations, more and more functional details areprovided, 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 alwaysexists 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 willremain in the wait state until (1) an internal clock indicates that some time interval haspassed, (2) an external event (e.g., a mouse movement) causes an interrupt, or (3) anexternal system signals the software to act in some manner. A behavioral model creates arepresentation 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 asystem, 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 ofcompleteness, consistency, and accuracy of the specification.

The model becomes the foundation for design, providing the designer with an essentialrepresentation 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 andestablish interfaces between the parts so that overall function can be accomplished. Theinformation, both functional, and behavioral domains of software can be partitioned.

In essence, partitioning decomposes a problem into its constituent parts. Conceptually, weestablish a hierarchical representation of information or function and then partition theuppermost 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 invariablyresults. 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 arepresentation process. Requirements are represented in a manner that ultimately leads tosuccessful software implementation.

1. Separate functionality from implementation.


13/21

2. Develop a model of the desired behavior of a system that encompasses data and thefunctional responses of a system to various stimuli from the environment.

3. Establish the context in which software operates by specifying the manner in which othersystem components interact with software.

4. Define the environment in which the system operates and indicate hows highlyintertwined 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) situationthat is normally quite complex. Hence, it will be incomplete and will exist at many levelsof details.

7. Establish the content and structure of specification in a way that will enable it to beamenable 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 forthe content of a software requirements specification can be developed. However, therepresentation forms contained within the specification are likely to vary with the applicationarea. For example, a specification of a manufacturing automation system would use differentzymology, diagrams, and language than the specification for a programming languagecompiler.

Information contained within the specification should be nested. Representations shouldreveal 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 beingpresented. 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 understandingand fosters errors.

Representations should be revisable, as the content of a specification will change. A CASEtool may be used so that all representations that are affected by each change can beupdated when they occur.

6.1.4 PROTOTYPING

This is used in analysis phase when model is the only means by which requirements can beeffectively 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 requirementsand after that is it discarded and the software is developed afresh. Open ended is also calledevolutionary proto-typing where the prototype developed in analysis phase is enhancedduring design and construction into the final product.

The following Table will guide in selection of suitable approach:

Question Throwawaytype

Evolutionary typeopen-ended

More Preliminaryanalysis required


14/21

close -ended

Is theapplicationdomainunderstood

yes yes No

Can theproblem beModeling?

yes yes No

Is customercertain of basicrequirements

yes/no yes/no No

Arerequirementsestablishedand stable?

No Yes Yes

Arerequirementsambiguous

Yes No Yes

Are therecontradictionsinrequirements

Yes No Yes

6.2 DESIGN METHODS

Design has been described as a multi-step process in which representations of datastructure, program structure, interface characteristics, and procedural details are synthesizedfrom information requirements. Software design methods are derived from consideration ofeach of the three domains of the analysis model - the data, functional, and behavioraldomains. 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 objectsidentified during requirements definition and specifications phase. A well-designed data canlead to better program structure and modularity and reduce procedural complexity. Thefollowing principles apply to data specifications

The systematic analysis principles that is applied to function and behavior is applied todata.

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 programdesign.

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


15/21

direct the use of data contained within the structure

A library of useful data structure and the operations that can be applied to them shouldbe developed.

A software design and programming language should support the specification andrealization of abstract data type.

6.2.2 ARCHITECTURE DESIGN

The primary objective of architectural design is to develop a modular program structure andrepresent control relationships between modules. In addition, architectural design also meldsthe program structure and data structure, defining interfaces that enable data to flowthroughout the program.

Dataflow oriented design is an architectural design method that allows a convenienttransformation from analysis model to design description of program structure. Thistransformation from information flow (represented as dataflow) to structure is accompaniedas 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.

6.2.2.1 Transform Mapping -

Transform mapping is set of design steps that allow DFD with transform flow characteristicsto be mapped into a predefined template for program structure. It has the following designsteps.

Step 1. Review the fundamental system model. The fundamental system modelencompasses the level 0 DFD and supporting information. In actuality the design stepsbegins 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 fromanalysis model contained in the software requirements specification is refined to producegreater detail.

Step 3. Determine whether the DFD has transform or transaction flow characteristics. Ingeneral, 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 ofcontrol. Factoring results in a program structure in which top-level modules perform decision-making and low-level modules perform most input, computational, and output work. Middle-level modules perform some control and do moderate amounts of work.

Step 6. Perform "second-level factoring". Second level factoring is accomplished by mappingindividual transforms (bubbles) of a DFD into appropriate modules within the programstructure.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 dependentcharacteristics, special timing requirements.)


16/21

6.2.2.2 Transaction Mapping

In many software applications, a single data item triggers one or a number of informationflows that affect a function implied by the triggering data item. The data item is called atransaction.

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 actionpaths.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 improvedsoftware 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 thatoccurs within a module. The narrative described processing tasks, decisions, and I/O.

The interface description requires the design of internal module interfaces, external systeminterfaces and the human - computer interface.

The design of data structures can have a profound impact on program structure and theprocedural details for each module.

Restrictions and/or limitations for each module are also documented. Typical topics fordiscussion include restriction of data type or format, memory or timing limitations, boundingvalues or quantities of data structures, special cases not considered, and specificcharacteristics of an individual module. The purpose of a restrictions/ limitations section is toreduce the number of errors introduced because of assumed functional characteristics.

Once design documentation has been developed for all modules, a design review isconducted. The review emphasizes traceability to software requirements, quality of programstructure, interface descriptions, data structure descriptions, implementation and testpracticality, and maintainability.

6.2.2.4 Architectural Design Optimization

1. Develop and refine program structure without concern for performance criticaloptimization.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 carefullydevelop 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.


17/21

6.2.3 INTERFACE DESIGN

Interface design focuses on three areas of concern: 1. the design of interfaces betweensoftware modules; 2) the design of interfaces between the software and other nonhumanproducers and consumers of information (i.e., other external entities); and 3) the design ofthe 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, isdriven by the data that must flow between modules and the characteristics of theprogramming 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 differentmodels of system function (as perceived from the outside). The human - and computer -oriented tasks that are required to achieve system function are then delineated; designissues that apply to all interface designs are considered; tools are used to prototype andultimately implement the design model; and the result is evaluated for quality.

A design model of the entire system incorporates data, architectural interface, andprocedural representations of the software. The requirements specification may establishcertain constraints that help to define the user of the system, but the interface design is oftenonly incidental to the design model.

The user model depicts the profile of end users of the system. To build an effective userinterface, "all design should begin with an understanding of the intended users.

Novices - no syntactic knowledge of the system and little semantic knowledge of theapplication 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 oftenleads 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 inhis or her head. For example, if the user of a particular word processor were asked todescribe its operation, the system perception would guide the response. The accuracy of thedescription will depend upon the users profile (e.g., novices would provide a sketchyresponse at best) and overall familiarity with software in the application domain. A user whounderstands word processors fully, but has only worked with the specific word processoronce, might actually be able to provide a more complete description of its function that thenovice 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 controlaction (e.g., hits the return key or clicks a mouse) until the software responds with desiredoutput or action.

System response time has two important characteristics, length and variability. If the lengthof 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 theinterface. 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


18/21

more important of the response time characteristics. Low variability enables the user toestablish a rhythm, even if response time is relatively long. For example, one-secondresponse to a command is preferable to a response that values from 0.1 to 2.5 seconds. Theuser is always off balance, always wondering whether something "different" has occurredbehind the scenes.

Two different types of help facilities are encountered: integrated and add-on. An integratedhelp 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 beingperformed. Obviously this reduces the time required for the user to obtain help and increasesthe "friendliness" of the interface. An add-on help facility is added to the software after thesystem has been built. In many ways, it is really an on-line users manual with limited querycapability. The user may have to search through a list of hundreds of topics to findappropriate guidance, often making many false starts and receiving much irrelevantinformation. There is little doubt that the integrated help facility is preferable to the add-onapproach.

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 aprinted document (less than ideal), and a one or two line suggestion produced in a fixedscreen location.

How will the user return to normal interaction? Options include a return button displayedon the screen and a function key or control sequence.

How will help information be structured? Option include a "flat" structure in which allinformation is accessed through a keyword, a layered hierarchy of information thatprovides increasing detail as the user proceeds into the structure, and the use ofhypertext.

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., potentiallycorrupted data files) so that the user can check to ensure that they have not occurred (orcorrect them if they have).

The message should be accompanied by an audible or visual cue. That is, a beep mightbe generated to accompany the display of the message, or the message might flashmomentarily 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 blameon 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, andthe myriad other functions that occur in a HCI.


19/21

Offer meaningful feedback. Provide the user with visual and auditory feedback to ensure thattwo-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 aprogram, an "Are you sure." message should appear.

Permit easy reversal of most actions. UNDO or REVERSE functions have saved tens ofthousands of end users from millions of hours of frustration. Reversal should be available inevery interactive application.

Reduce the amount of information that must be memorized between actions. The usershould not be expected to remember a list of numbers or names so that he or she can reusethem in a subsequent function. Memory load should be minimized.

Seek efficiency in a dialog, motion and thought. Keystrokes should be minimized, thedistance a mouse must travel between picks should be considered in designing screenlayout, and the user should rarely encounter a situation where he or she asks, "Now whatdoes 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 keybenefits of the pull-down menu is the ability to organize commands by type. In essence, thedesigner 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 commandname is more difficult to recognize and recall. It may also take up unnecessary space inmenu lists.6.2.3.2 Information Display.

Display only that information that is relevant to the current context. The user should not haveto wade through extraneous data, menus, and graphics to obtain information relevant to aspecific system function.

Dont bury the user with data; use a presentation format that enables rapid assimilation ofinformation. Graphs or charts should replace voluminous tables.

Use consistent labels, standard abbreviations, and predictable colors. The meaning of adisplay should be obvious without reference to some outside source of information.

Allow the user to maintain visual context. If graphical representations are scaled up anddown, the original image should be displayed constantly (in reduced form at the corner of thedisplay) so that the user understands the relative location of the portion of the image that iscurrently being viewed.

Produce meaningful error messages.

Use upper and lower case, indentation, and text grouping to aid in understanding. Much ofthe information imparted by a HCI is textual, and the layout and form of the text has asignificant 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 formof representation. For example, a display of holding tank pressure in an oil refinery wouldhave little impact if a numeric representation were used. However, if a thermometer-likedisplay were used, vertical motion and color changes could be used to indicate dangerouspressure conditions. This would provide the user with both absolute and relative information.


20/21

Consider the available geography of the display screen and use it efficiently. When multiplewindows are to be used, space should be available to show at least some portion of each. Inaddition, screen size (a system engineering issue) should be selected to accommodate thetype of application that is to be implemented.

Data Input

Minimize the number of input actions required of the user. Above all, reduce the amount oftyping that is required. This can be accomplished by using the mouse to select frompredefined sets of input, using a "sliding scale" to specify input data across a range ofvalues, and using macros that enable a single keystroke to be transformed into a morecomplex collection of input data.

Maintain consistency between information display and data input. The visual characteristicsof the display (e.g., text size, color, and placement) should be carried over to the inputdomain.

Allow the user to customize input. An expert user might decide to create custom commandsor dispense with some types of warning messages and action verification. The HCI shouldallow this.

Interaction should be flexible but also tuned to the users preferred mode of input. The usermodel will assist in determining which mode of input is preferred. A clerical worker might bevery happy with keyboard input, while a manager might be more comfortable using a pointand pick device such as a mouse.

Deactivate commands that are inappropriate in the context of current actions. This protectsthe 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 unnecessaryactions, change the order of required actions (when possible in the context of anapplication), 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 dollaramounts, provide default values whenever possible, and never require the user to enterinformation 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 beenestablished. 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 beformed. The constructs are sequence, condition, and repetition. Sequence implementsprocessing steps that are essential in the specification of any algorithm, condition providesthe facility for selected processing based on some logical occurrence, and repetitionprovides for looping.

6.2.4.2 Graphical Design Notation

Graphical design notation provides excellent pictorial patterns that readily depict proceduraldetails. 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


21/21

conditions and select appropriate actions. Decision tables provide a notation that translatesactions 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 somethinglike 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 identifiedphases will be captured in the Project Management System Summary (ENG 339).

7TOOLS

Refer to the Organization Reference Document (ORD) of respective organization forrecommended tools. These tools comprise the work environment also.

Documents

SDLC Guideline