Software Design Process

For example: word processing software developed using the incremental paradigm might deliver:

1. Basic file management, editing, and document production functions in the first increment; 2. More sophisticated editing and document production capabilities in the second increment; 3. Spelling and grammar checking in the third increment and; 4. Advanced page layout capability in the fourth increment.

The RAD approach encompasses the following phases:

1. Business modeling: Here we try to find answers to questions like what information drives the business process. What information is generated? Who generates it? Where does the information go? Who processes it? 2. Data modeling: Here the information flow which would have been defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. 3. Process modeling: The data objects defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting, or retrieving a data object. 4. Application generation: RAD assumes the use of fourth generation techniques. Rather than creating software using conventional third generation programming languages the RAD process works 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. 5. 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.

Consists of six task regions or phases:

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

Limitations of the RAD model

1. For large but scalable projects, RAD requires sufficient human resources to create the right number of RAD teams. 2. RAD requires developers and customers who are committed to the rapid-fire activities necessary to get a system complete in a much abbreviated time frame. If commitment is lacking from either, RAD projects will fail. 3. 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. 4. RAD is not appropriate when technical risks are high. This occurs when a new application makes a heavy use of new technology or when the new software requires a high degree of interoperability with existing computer programs.

Limitations of Linear Sequential Model

1. Model assumes the requirement of a system which can be frozen (baseline) before the design begins. This is possible for systems designed to automate an existing manual system. But for a new system, determining the requirements is difficult as the user does not even know the requirements. Hence, having unchanging requirements is unrealistic for such projects. 2. Freezing the requirements usually requires choosing the hardware (because it forms a part of the requirement specifications). A large project might take a few years to complete. If the hardware is selected early, then due to the speed at which hardware technology is changing , it is likely the final software will use a hardware technology on the verge of becoming obsolete. This is clearly not desirable for such expensive software systems. 3. Model stipulates that the requirements be completely specified before the rest of the development can proceed. In some situations it might be desirable to first develop a part of the system completely and then later enhance the system in phases. This is often done for software products that are developed not necessarily for a client, but for general marketing, in which case the requirements are likely to be determined largely by the developers themselves. 4. Model is a document driven process that requires formal documents at the end of each phase. This approach tends to make the process documentation-heavy and is not suitable for many applications, particularly interactive application, where developing elaborate documentation of the user interfaces is not feasible. Also, if the development is done using fourth generation language or modern development tools, developing elaborate specifications before implementations is sometimes unnecessary.

Stages:

1. Software requirement analysis 2. Design: Software design is a multistep 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 coding begins. 3. Code Generation: 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 mechanistically. 4. Testing: Once code has been generated, program testing begins. The testing process focuses on the logical internals of the software, ensuring 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. 5. Support: Software will undergo change after it is delivered to the customer. Change will occur because errors have been encountered, because the software must be adopted to accommodate changes in its external environments or because the customer requires functional or performance enhancements.

Systems can be decomposed into

1. Subsystems and 2. System components

Concurrency is achieved in two ways;

1. System and component activities occur simultaneously and can be modeled using the state - oriented approach 2. Typical client/server application is implemented with many components, each of which can be designed and realized concurrently.

Limitation of the Iterative Development Model

1. This process can not be applied when it comes to customized software development. 2. Generating the business contract - How will the cost of additional features be determined and negotiated, particularly because the client organization is likely to be tied to the original vendor who developed the first version.

Enhancement

As software is used, the customer/user will recognize additional functions that will provide benefit. Perfective Maintenance extends the software beyond its original functional requirements.

Correction:

Even with the best quality assurance activities, it is likely that the customer will uncover defects in the software. Corrective maintenance changes the software to correct defects.

Adaption

Overtime, the original environment for which the software was developed is likely to change. Adaptive Maintenance results in modification to the software to accommodate changes to its external environment.