Introduction to Software Engineering

Software engineering is an engineering approach for software development. We can alternatively view it as a systematic collection of past experience. The experience is arranged in the form of methodologies and guidelines. A small program can be written without using software engineering principles. But if one wants to develop a large software product, then software engineering principles are indispensable to achieve a good quality software cost effectively. These definitions can be elaborated with the help of a building construction analogy. Without using software engineering principles it would be difficult to develop large programs. In industry it is usually needed to develop large programs to accommodate multiple functions. A problem with developing such large commercial programs is that the complexity and difficulty levels of the programs increase exponentially with their sizes as shown in fig. 1.3. For example, a program of size 1,000 lines of code has some complexity. But a program with 10,000 LOC is not just 10 times more difficult to develop, but may as well turn out to be 100 times more difficult unless software engineering principles are used. In such situations software engineering techniques come to rescue. Software engineering helps to reduce the programming complexity. Software engineering principles use two important techniques to reduce problem complexity: abstraction and decomposition. Fig.

Fig. 1.3: Increase in development time and effort with problem size

Causes of and solutions for software crisis.

Software engineering appears to be among the few options available to tackle the present software crisis. To explain the present software crisis in simple words, consider the following. The expenses that organizations all around the world are incurring on software purchases compared to those on hardware purchases have been showing a worrying trend over the years (as shown in fig. 1.6) Fig.

Important features of a structured program.

A structured program uses three types of program constructs i.e. selection, sequence and iteration. Structured programming uses single entry, single-exit program constructs such as if-then-else, do-while, etc. Thus, the structured programming principle emphasizes designing neat control structures for programs.

Important advantages of structured programming.

Structured programs are easier to read and understand. Structured programs are easier to maintain. They require less effort and time for development.

Evolution of software design techniques over the last 50 years.

During the 1950s, most programs were being written in assembly language. These programs were limited to about a few hundreds of lines of assembly code, i.e. were very small in size. Every programmer developed programs in his own individual style - based on his intuition. This type of programming was called Exploratory Programming. The next significant development which occurred during early 1960s in the area computer programming was the high-level language programming. Use of high-level language programming reduced development efforts and development time significantly. Languages like FORTRAN, ALGOL, and COBOL were introduced at that time. After structured programming, the next important development was data structureoriented design. Programmers argued that for writing a good program, it is important to pay more attention to the design of data structure, of the program rather than to the design of its control structure. Data structure-oriented design techniques actually help to derive program structure from the data structure of the program. Example of a very popular data structure-oriented design technique is Jackson's Structured Programming (JSP) methodology, developed by Michael Jackson in the1970s. Next significant development in the late 1970s was the development of data floworiented design technique. Experienced programmers stated that to have a good program structure, one has to study how the data flows from input to the output of the program. Every program reads data and then processes that data to produce some output. Once the data flow structure is identified, then from there one can derive the program structure. Object-oriented design (1980s) is the latest and very widely used technique. It has an intuitively appealing design approach in which natural objects (such as employees, pay-roll register, etc.) occurring in a problem are first identified. Relationships among objects (such as composition, reference and inheritance) are determined. Each object essentially acts as a data hiding entity.

1. Identify the problem one would face, if he tries to develop a large software product without using software engineering principles. Ans.: - Without using software engineering principles it would be difficult to develop large programs. In industry it is usually needed to develop large programs to accommodate multiple functions at various levels. The problem is that the complexity and the difficulty levels of the programs increase exponentially with their sizes as shown in fig. 1.3.

Fig. 1.3: Increase in development time and effort with problem size For example, a program of size 1,000 lines of code has some complexity. But a program with 10,000 LOC is not 10 times more difficult to develop, but may be 100 times more difficult unless software engineering principles are used. Software engineering helps to reduce the programming complexity. 2. Identify the two important techniques that software engineering uses to tackle the problem of exponential growth of problem complexity with its size. Ans.: - Software engineering principles use two important techniques to reduce problem complexity: abstraction and decomposition. 3.Identify at least two advantages of using high-level languages over assembly languages. Ans.: - Assembly language programs are limited to about a few hundreds of lines of assembly code, i.e. are very small in size. Every programmer develops programs in his own individual style - based on intuition. This type of programming is called Exploratory Programming.

But use of high-level programming language reduces development efforts and development time significantly. Languages like FORTRAN, ALGOL, and COBOL are the examples of high-level programming languages. 4.State at least five advantages of object-oriented design techniques. Ans.: - Object-oriented techniques have gained wide acceptance because of its: Simplicity (due to abstraction) Code and design reuse Improved productivity Better understandability Better problem decomposition Easy maintenance 1. Which of the following problems can be considered to be contributing to the present software crisis? large problem size lack of rapid progress of software engineering lack of intelligent engineers shortage of skilled manpower 2. Which of the following are essential program constructs (i.e. it would not be possible to develop programs for any given problem without using the construct)? sequence selection jump iteration

Life cycle model

A software life cycle model (also called process model) is a descriptive and diagrammatic representation of the software life cycle.

Different software life cycle models

Many life cycle models have been proposed so far. Each of them has some advantages as well as some disadvantages. A few important and commonly used life cycle models are as follows: Classical Waterfall Model Iterative Waterfall Model Prototyping Model Evolutionary Model

Spiral Model Classical waterfall model divides the life cycle into the following phases as shown in fig.2.1: Feasibility Study Requirements Analysis and Specification Design Coding and Unit Testing Integration and System Testing Maintenance

Feasibility Study

Requirements Analysis and Specification

Design

Coding & Unit testing

Integration & System Testing

Maintenance

Fig 2.1: Classical Waterfall Model

Activities undertaken during feasibility study: - The main aim of feasibility study is to determine whether it would be financially and technically feasible to develop the product. At first project managers or team leaders try to have a rough understanding of what is required to be done by visiting the client side. They study different input data to the system and output data to be produced by the system. They study what kind of processing is needed to be done on these data and they look at the various constraints on the behavior of the system. After they have an overall understanding of the problem they investigate the different solutions that are possible. Then they examine each of the solutions in terms of what kind of resources required, what would be the cost of development and what would be the development time for each solution.

Activities undertaken during requirements analysis and specification: - The aim of the requirements analysis and specification phase is to understand the exact requirements of the customer and to document them properly. This phase consists of two distinct activities, namely Requirements gathering and analysis, and Requirements specification The goal of the requirements gathering activity is to collect all relevant information from the customer regarding the product to be developed. This is done to clearly understand the customer requirements so that incompleteness and inconsistencies are removed. The requirements analysis activity is begun by collecting all relevant data regarding the product to be developed from the users of the product and from the customer through interviews and discussions. Activities undertaken during design: - The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. In technical terms, during the design phase the software architecture is derived from the SRS document. Two distinctly different approaches are available: the traditional design approach and the object-oriented design approach. Traditional design approach Traditional design consists of two different activities; first a structured analysis of the requirements specification is carried out where the detailed structure of the problem is examined. This is followed by a structured design activity. During structured design, the results of structured analysis are transformed into the software design.

Object-oriented design approach In this technique, various objects that occur in the problem domain and the solution domain are first identified, and the different relationships that exist among these objects are identified. The object structure is further refined to obtain the detailed design.

Activities undertaken during coding and unit testing:- The purpose of the coding and unit testing phase (sometimes called the implementation phase) of software development is to translate the software design into source code. Each component of the design is implemented as a program module. The end-product of this phase is a set of program modules that have been individually tested. During this phase, each module is unit tested to determine the correct working of all the individual modules. It involves testing each module in isolation as this is the most efficient way to debug the errors identified at this stage. Activities undertaken during integration and system testing: Integration of different modules is undertaken once they have been coded and unit tested. During the integration and system testing phase, the modules are integrated in a planned manner. The different modules making up a software product are almost never integrated in one shot. Integration is normally carried out incrementally over a number of steps. During each integration step, the partially integrated system is tested and a set of previously planned modules are added to it. Finally, when all the modules have been successfully integrated and tested, system testing is carried out. The goal of system testing is to ensure that the developed system conforms to its requirements laid out in the SRS document. System testing usually consists of three different kinds of testing activities: testing: It is the system testing performed by the development team. testing: It is the system testing performed by a friendly set of customers. acceptance testing: It is the system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivered product. Activities undertaken during maintenance: Maintenance of a typical software product requires much more than the effort necessary to develop the product itself. Many studies carried out in the past confirm this and indicate that the relative effort of development of a typical software product to its maintenance effort is roughly in the 40:60 ratio. Maintenance involves performing any one or more of the following three kinds of activities:

Correcting errors that were not discovered during the product development phase. This is called corrective maintenance. Improving the implementation of the system, and enhancing the functionalities of the system according to the customers requirements. This is called perfective maintenance

Need for a prototype in software development

There are several uses of a prototype. An important purpose is to illustrate the input data formats, messages, reports, and the interactive dialogues to the customer. This is a valuable mechanism for gaining better understanding of the customers needs: how the screens might look like how the user interface would behave how the system would produce outputs

Spiral model
The Spiral model of software development is shown in fig. 2.2. The diagrammatic representation of this model appears like a spiral with many loops. The exact number of loops in the spiral is not fixed. Each loop of the spiral represents a phase of the software process. For example, the innermost loop might be concerned with feasibility study. The next loop with requirements specification, the next one with design, and so on. Each phase in this model is split into four sectors (or quadrants) as shown in fig. 2.2. The following activities are carried out during each phase of a spiral model.

Fig. 2.2: Spiral Model

-First quadrant (Objective Setting) During the first quadrant, it is needed to identify the objectives of the phase. Examine the risks associated with these objectives. - Second Quadrant (Risk Assessment and Reduction) A detailed analysis is carried out for each identified project risk. Steps are taken to reduce the risks. For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed. - Third Quadrant (Development and Validation) Develop and validate the next level of the product after resolving the identified risks. - Fourth Quadrant (Review and Planning) Review the results achieved so far with the customer and plan the next iteration around the spiral. Progressively more complete version of the software gets built with each iteration around the spiral. 1. Identify the definite stages through which a software product undergoes during its lifetime. Ans.: - The definite stages through which a software product undergoes during its lifetime are as follows: Feasibility Study Requirements Analysis and Specification Design Coding and Unit Testing Integration and System Testing, and Maintenance 1. In a classical waterfall model, which phase precedes the design phase ? Coding and unit testing Maintenance Requirements analysis and specification Feasibility study

2. Among development phases of software life cycle, which phase typically consumes the maximum effort? Requirements analysis and specification Design

 Coding Testing 3. Among all the phases of software life cycle, which phase consumes the maximum effort? Design Maintenance Testing Coding 4. In the classical waterfall model during which phase is the Software Requirement Specification (SRS) document produced? Design Maintenance Requirements analysis and specification Coding 5. Which phase is the last development phase of a classical waterfall software life cycle? Design Maintenance Testing Coding 6. Which development phase in classical waterfall life cycle immediately follows coding phase? Design Maintenance Testing Requirement analysis and specification 7. Out of the following life cycle models which one can be considered as the most general model, and the others as specialization of it? Classical Waterfall Model Iterative Waterfall Model Prototyping Model Spiral Model

Role of a system analyst

The analyst starts requirements gathering and analysis activity by collecting all information from the customer which could be used to develop the requirements of the system. He then analyzes the collected information to obtain a clear and thorough understanding of the product to be developed, with a view to removing all ambiguities and inconsistencies from the initial customer perception of the problem. The following basic questions pertaining to the project should be clearly understood by the analyst in order to obtain a good grasp of the problem:

 What is the problem? Why is it important to solve the problem? What are the possible solutions to the problem? What exactly are the data input to the system and what exactly are the data output by the system? What are the likely complexities that might arise while solving the problem? If there are external software or hardware with which the developed software has to interface, then what exactly would the data interchange formats with the external system be?

Parts of a SRS document

The important parts of SRS document are: Functional requirements of the system Non-functional requirements of the system, and Goals of implementation

Identifying functional requirements from a problem description

The high-level functional requirements often need to be identified either from an informal problem description document or from a conceptual understanding of the problem.

Fig. 3.2: Function fi Example:- Consider the case of the library system, where - F1: Search Book function (fig. 3.3) Input: an authors name Output: details of the authors books and the location of these books in the library

Fig. 3.3: Book Function So the function Search Book (F1) takes the author's name and transforms it into book details.

Documenting functional requirements

For documenting the functional requirements, we need to specify the set of functionalities supported by the system. A function can be specified by identifying the state at which the data is to be input to the system, its input data domain, the output data domain, and the type of processing to be carried on the input data to obtain the output data. Let us first try to document the withdraw-cash function of an ATM (Automated Teller Machine) system. The withdraw-cash is a high-level requirement. It has several sub-requirements corresponding to the different user interactions. These different interaction sequences capture the different scenarios. Example: - Withdraw Cash from ATM R1: withdraw cash Description: The withdraw cash function first determines the type of account that the user has and the account number from which the user wishes to withdraw cash. It checks the balance to determine whether the requested amount is available in the account. If enough balance is available, it outputs the required cash, otherwise it generates an error message. R1.1 select withdraw amount option Input: withdraw amount option Output: user prompted to enter the account type R1.2: select account type Input: user option Output: prompt to enter amount R1.3: get required amount Input: amount to be withdrawn in integer values greater than 100 and less than 10,000 in multiples of 100. Output: The requested cash and printed transaction statement. Processing: the amount is debited from the users account if sufficient balance is available, otherwise an error message displayed.

Software design and its activities

Software design deals with transforming the customer requirements, as described in the SRS document, into a form (a set of documents) that is suitable for implementation in a programming language. A good software design is seldom arrived by using a single step procedure but rather through several iterations through a series of steps. Design activities can be broadly classified into two important parts:

 Preliminary (or high-level) design and

Detailed design.

Difference between analysis and design

The aim of analysis is to understand the problem with a view to eliminate any deficiencies in the requirement specification such as incompleteness, inconsistencies, etc. The model which we are trying to build may be or may not be ready. The aim of design is to produce a model that will provide a seamless transition to the coding phase, i.e. once the requirements are analyzed and found to be satisfactory, a design model is created which can be easily implemented.

Items developed during the software design phase

For a design to be easily implemented in a conventional programming language, the following items must be designed during the design phase. Different modules required to implement the design solution. Control relationship among the identified modules. The relationship is also known as the call relationship or invocation relationship among modules. Interface among different modules. The interface among different modules identifies the exact data items exchanged among the modules. Data structures of the individual modules. Algorithms required to implement each individual module.

Characteristics of a good software design

The definition of a good software design can vary depending on the application being designed. For example, the memory size used by a program may be an important issue to characterize a good solution for embedded software development since embedded applications are often required to be implemented using memory of limited size due to cost, space, or power consumption considerations. For embedded applications, one may sacrifice design comprehensibility to achieve code compactness. For embedded applications, factors like design comprehensibility may take a back seat while judging the goodness of design. Therefore, the criteria used to judge how good a given design solution is can vary widely depending upon the application. Not only is the goodness of design dependent on the targeted application, but also the notion of goodness of a design itself varies widely across software engineers and academicians. However, most researchers and software engineers agree on a few desirable characteristics that every good software design for general application must possess. The characteristics are listed below: Correctness: A good design should correctly implement all the functionalities identified in the SRS document. Understandability: A good design is easily understandable. Efficiency: It should be efficient.

 Maintainability: It should be easily amenable to change.