Software Design

·A structured set of activities required to develop a software system

1.Specification

2.Design and Implementation

3.Validation

4.Evolution

·A software process model is an abstract representation of a process.

·It presents a description of a process from some particular perspective.

·Software process is a set of activities and associated results which lead to the production of a software product

·These may involve the development of software from scratch although it is increasingly the case that new software is developed by extending and modifying existing systems

·Software processes are complex and, like all intellectual processes are reliable on human judgments

·Because of the need for judgments and creativity, attempts to automate software processes have met with limited success

·CASE tools can support some process activities but there is no possibility, at lest for the next few years, of  more extensive automation where software takes over creative design from the engineers involve in software process

·One reason why there is limited scope for process automation is the immense diversity of software processes

·There is no ideal process and different organizations have developed completely different approaches to software development

·The software process model maybe define

d as a simplified description of a software process, presented from a particular perspective.

·In essence, each stage of the software process is identified and a model is then employed to represent the inherent activities associated within that stage.

·Consequently, a collection of ‘local’ models may be utilised in generating the global picture representative of the software process.

·Examples of models include the workflow model, the data-flow model, and the role model.

1.The workflow model shows the sequence of activities in the process along with their inputs, outputs and dependencies. The activities in the model represent human actions.

2.The dataflow model represents the process as a set of activities each of which carries out some data transformation. It shows how the input to the process such as specification is transformed to an output such as design. The activities here maybe lower than in a workflow model. They may represent transformations carries out by people or computers.

3.The role model represents the roles of people involved in the software process and the activities for which they are responsible.

2.0 Approaches to Software Development

2.1 Traditional approaches

·In this model, ‘traditional’ tends to mean ‘unstructured’ and somewhat non-specific.

·This approach is characterized by the lack of user involvement, the use of text-based, as opposed to diagrammatic, documentation and an emphasis on how things are going to be achieved rather than what is going to be achieved.

·Although there is a stage-by-stage approach, it is difficult to see how the stages link together.

·There is no business case or defined acceptance criteria for the system, which makes it rather difficult to gauge success or failure

·On the other hand, this method of working suited many analysts and users. It allows the analyst to use ‘intuitive’ methods of working and made limited demands on the user’s time. The documentation was relatively easy to understand. Many traditional approaches follow a ‘Waterfall’ style of system development.

2.2 Structured approaches

·Structured methods have largely taken over from the traditional approach in the development of IS projects. Most of these methods offer a set of techniques and tools to carry out the system development work within a defined framework. Structured approaches are largely characterized by: User involvement, Separation of logical & physical work, Emphasis on data, Diagrammatic documentation and Defined structure.

·In general, structured methods are considered to offer improvements over traditional methods but there are drawbacks and criticisms. The users and analysts/ developers need to be trained to understand the documentation. This is important as there is no value whatsoever in producing documentation to be reviewed and signed off if it is not fully understood. The users also need to accept that the amount of time required from them will be much increased. Structured system Analysis & Design Method (SSADM) is an example of a structured method.

·Structured methods use tools such as Data Flow diagram (DFD) to model process, Entity Relationship Diagram (ERD) to model data, Entity Life History (ELH) to model behavior and decision tables / trees to model logic.

2.3 Evolutionary approaches

·This approach has prototyping as a central method that is used to develop systems. The approach interleaves the activities of specification, development and validation. An initial system is rapidly developed from very abstract specifications. This is then refined with customer input to produce a system which satisfies the customer’s needs. The system may then be delivered. Alternatively, it may be re-implemented using a more structured approach to produce a more robust and maintainable system. Example of such approach is the Incremental development and Spiral model.

2.4 Formal transformation

·This approach is based on producing a formal mathematical system specification and transforming this specification, using mathematical methods, to a program. These transformations are ‘correctness-preserving’. This means that it is assured that the developed program meets its specifications.

3.0 Models  

3.1 The ‘Waterfall’ Model

·Also known as the software life-cycle model (classic life-cycle, liner sequential model).

·Cascade from one phase to another. Systematic and sequential approach to software development.

·Presents a highly structured method of software development that starts at the system level and progresses through analysis, design, coding, testing and maintenance.

.The stages of the model are as follows:

 

• gather requirements
• developer & customer define overall objectives, identify areas needing more investigation – risky requirements
• quick design focusing on what will be visible to user – input & output formats
• use existing program fragments, program generators to throw together working version
• prototype evaluated and requirements refined
• process iterated until customer & developer satisfied
• then throw away prototype and rebuild system to high quality
• alternatively can have evolutionary prototyping – start with well understood requirements
• The V-model of a system development process incorporates test plans into it activities.
• Drawbacks:
• Customer may want to hang onto first version, may want a few fixes rather than rebuild.
• First version will have compromises.
• Developer may make implementation compromises to get prototype working quickly.

Later on developer may become comfortable with compromises and forget why they are inappropriate