Software Engineering: A Systematic Approach to Software Development

Unit -1 Software :-- • Software is not just collection of programs, but it is a Programming Systems Product. • A program is: • Generally complete, & used by only the author of program. • There is only small documentation to help other users. • If there is any error, the author will himself remove that error, & start using it again. • Thus, there is no concept of Reliability, Portability & Usability in program.

Software Engineering:- It is the systematic approach to the Development, Operation, Maintenance and Retirement of software. • Another definition according to Boehm is: • Software Engineering is the application of science and mathematics by which the capabilities of computer equipment are made useful to man via computer programs, procedures and its documentation. • From the above definitions, • “Systematic approach” or “science & mathematics” means that the software development should be near to the scientific method. I.e. this process is a science and not an “art”. • “Usable to man” means the user interface should be such that they are able to interact with software easily.

1.1 The Software Problem • Software is not simply a collection of computer programs. • There is a distinction between a program and a programming system product (PSP). • A program is generally complete in itself and is generally used only by the author of the program. There is usually little documentation or other aids to help other people use the program. Because the author is the user, the presence of “bugs” is not a major concern; if the program crashes, the author will fix the program and start it again. These programs are not designed with such issues as portability, reliability, and usability in mind.

A Programming System Product (PSP), on the other hand, is used largely by people other than the developers of the system. The users may be from different backgrounds, so a proper user interface is provided. There is sufficient documentation to help these diverse users use the system. Programs are thoroughly tested before operational use, because users do not have luxury of fixing bugs that may be detected.

1.1.1 Software is Expensive Over the past decades, with the advancement of technology, the cost of hardware has consistently decreased. On the other hand, the cost of software is increasing. The main reason for the high cost of software is that software development is still labor-intensive.

Software Engineering Problem :-- SE is the application of science and mathematics by which the capabilities of computer equipment are made useful to man via computer programs, procedures, and associated documentation. SE provides methodologies for developing the software as close to the scientific method as possible. That is, these methodologies are repeatable, and if it is applied by different people, similar software will be produced. In essence, the goal of SE is to take software development closer to science and away from being an art. The focus is on developing methods that can be used by various software projects.

1.2.1 The Problem of Scale A fundamental problem of SE is the problem of scale; development of a very large system requires a very different set of methods compared to developing a small system. In other words, the methods that are used for developing small system generally do not scale up to large systems.

Formal Complex Project Project Mgt. Small Project Development Methods Formal formal Informal

Phases Of Software Development :-- The basic phases are as following: Requirement Analysis Software Design Coding Testing

1. Requirement Analysis :-- Requirement Analysis is done in order to understand the problem. The problem could be automating an existing manual process, developing a new automated system, or a combination of the two. Understanding the requirements of the large and complex system is a major task. The emphasis in requirement analysis is on identifying what is needed from the system, not how the system will achieve its goals. The goal of the requirement specification phase is to produce the software requirement specification document

There are 2 major activities in this phase:- 1. Problem understanding (analysis) 2. Requirement Specification. In problem analysis, the analyst has to understand the problem and its context. Such analysis typically requires through understanding of the existing system, parts of which have to be automated. This requires interfacing with clients and end users, as well as studying the existing manuals and procedures. The goal of this activity is to understand the requirements of new system that is to be developed. Understanding the properties of a system that does not exist is more difficult and requires creative thinking.

2. Software Design :-- The purpose of the design phase is to plan a solution of the problem specified by the requirement document. This phase is the first step in moving from the problem domain to the solution domain. In other words, starting with what is needed; design takes us toward how to satisfy the needs. The design of the system is perhaps the most critical factor affecting the quality of the software. The output of this phase is the design document. This document is similar to a blueprint or plan for the solution and is used later during implementation, testing and maintenance.

The design activity is often divided into two separate phases: System Design & Detailed Design. System design : which is sometimes also called top-level design, aims identify the modules that should be in the system, the specifications of these modules, and how they interact with each other to produce the desired results. At the end of system design all the major data structures, file formats, output formats, and the major modules in the system and their specifications are decided. During detailed design, the internal logic of each of the modules specified in system design is decided.

3. Coding :--Once the design is complete, most of the major decisions about system have been made. However, many of the details about coding the designs, which often depend on the programming language chosen, are not specified during design. The goal of coding phase is to translate the design of the system into code in a given programming language. For a given design, the aim in this phase is to implement the design in the best possible manner. The coding phase affects both testing and maintenance profoundly (greatly). Well-written code can reduce the testing and maintenance effort. Because the testing and maintenance costs are much higher than the coding cost, the goal of coding should be to reduce the testing and maintenance effort

4. Testing :-- Testing is the major quality control measure used during software development. Its basic function is to detect errors in the software. After the coding phase, computer programs are available that can be executed for testing purposes. This implies that testing not only has to uncover errors introduced during coding, but also errors introduced during the previous phases. The starting point of testing is unit testing. In this, a module is tested separately and is often performed by the coder himself simultaneously along with the coding of the module.

After the system is put together, system testing is performed. Here the system is tested against the system requirements to see if all the requirements are met and if the system performs as specified by the requirements. The final output of testing phase is the test report and the error report, or a set of such reports (one for each unit tested). Each test report contains the set of test cases and the result of executing the code with these test cases. The error report describes the errors encountered and the action taken to remove the errors.

Software Metrics :-- Software metrics are quantifiable measures that could be used to measure different characteristics of a software system or the software development process. There are two types of metrics used for software development: Process MetricsandProduct Metrics Product Metrics are used to quantify characteristics of the product being developed, i.e. the software. Process Metrics are used to quantify characteristics of the process being used to develop the software. It aims to measure such considerations as productivity, cost and resource requirements, effectiveness of quality assurance measures, and the effect of development techniques and tools. Metrics and measurement are necessary aspects of managing a software development project. For effective monitoring, the management needs to get information about the project : how far it is progressed, how much development has taken place, how far behind schedule it is, the quality of the development so far, etc.

Software Development Process Models :-- The concept of process is at the heart of the SE approach. The term process means “a particular method of doing something, generally involving a number of steps or operations.” In SE, the phrase software process refers to the method of developing software. A software process is a set of activities, together with ordering constraints among them, such that if the activities are performed properly and in accordance with the ordering constraints, the desired result is produced.

2.1 Software Processes A software process specifies a method of developing software. A software project is a development project in which a software process is used. Software products are outcomes of a software project.

Characteristics of a Software Process :-- The fundamental objectives of a process are same as that of SE namely, optimality and scalability. Optimality means that the process should be able to produce high quality software at low cost .Scalability means that it should also be applicable for large software projects. 1) Predictability :-- Predictability of a process determines how accurately the outcome of following a process in a project can be predicted before the project is completed. Predictability can be considered a fundamental property of any process.

If we want to use the past experience to control costs and ensure quality, we must use a process that is predictable. With low Predictability, the experience gained through projects is of little value. A predictable process said to be under statistical control. A process is under statistical control if following the same process produces similar results. This is shown in figure; y-axis represents property (quality, productivity etc.) and x-axis represents projects. The dark line is the expected value of the property for this process. Statistical control implies that projects will be within a bound around the expected value. Property Projects

2) Support Testability and Maintainability In development, coding is frequently given more importance. We have seen that a process consists of phases and a process generally includes requirements, design, coding and testing phases. Of the development cost, an example of distribution of effort with the different phases is shown in table 2.1 Table: 2.1: Effort distribution with phases

The exact numbers will differ with organization and nature of process. First observation is that coding consumes only a small percentage of development effort. Second observation from data about effort distribution with phases is that testing consumes (i.e. 50%) most resources during development, which considers is side activity that is often not planned. We can say that goal of process should not be to reduce the effort of design and coding, but to reduce the cost of testing and maintenance.

3) Early defect removal and Defect Prevention :-It is clear that errors can occur at any stage during development. An example distribution of error occurrences by phase is: Requirement analysis 20% Design 30% Coding 50% Errors occurs throughout the development process. However, the cost of correcting errors of different phases is not same depends on when the errors is detected and corrected. The relative cost of correcting requirement errors as a function of where they are detected is shown in figure.

The greater the delay in error in detecting an error after it occurs, the more expensive it is to correct it. As the figure shows, an error that occurs requirements phase , if corrected during acceptance testing , can cost up to 100 times more than correcting the error during requirement phase itself. 1000 Relative cost 100 2 Req design code devlop Accept operation Test test Phase in which error was detected

Software Development Process :-- In the software development process focus is on the activities directly related to production of the software, for example, design, coding and testing. A development process model specifies some activities that, according to the model, should be performed, and the order in which they should be performed. As stated earlier, for cost, quality, and project management reasons, development processes are generally phased. As the development process specifies the major development and quality assurance activities that need to be performed in the project, the development process really forms the core of the software process.

A) Waterfall Model The simplest process model is the waterfall model, which states that the phases are organized in a linear order. There are various variations of the waterfall model depending on the nature of activities and the flow of control between them. In a typical model, a project begins with feasibility analysis. On successfully demonstrating the feasibility of a project, the requirements analysis is complete, and coding begins after the design is complete. Once the programming is completed, the code is integrated and testing is done. On successful completion of testing, the system is installed. After this, the regular operation and maintenance of the system takes place. The model is shown in Figure .

WATER-FALL MODEL

The waterfall model is using the linear order because of the following two assumptions: For making the project (& product) successful, all the steps given in this model must be performed. If the ordering of the phases is different, then the software product developed is less successful. Initially it is required to check that development is required or not, which is termed as System Feasibility. At the end of each phase, we have validation/verification to confirm that output of each phase is correct.

PROJECT OUTPUTS IN WATERFALL MODEL • Requirements documents • Project plan • System design document • Test plan and test reports • Final code • Software manuals (e.g., user, installation, etc.) • Review reports

LIMITATIONS OF WATERFALL MODEL :-- • This model assumes that the requirements can be frozen i.e. fixed, before designing. This is possible for the system which is designed for the existing manual systems, but for the new system, requirements may be changed. So, we cannot freeze it. • Due to freezing of requirement, the hardware specification is also fixed. Software projects may take many years in development and when we use hardware technology, specified in RA, it may be obsolete (old) because technology is changing very fast. • This model suggests that requirement must be completely specified before the development, but the developers may want to develop general systems, in which they may make changes in the requirement at anytime for different clients.

It 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 to many applications, particularly interactive applications, where developing elaborate documentation of the user interfaces is not feasible. Also, if the development is done using fourth-generation languages or modern development tools, elaborate specifications before implementation is sometimes unnecessary. LIMITATIONS OF WATERFALL MODEL Continue……

B) PROTOTYPING • Goal: To remove the first two limitations of waterfall model. • In this model, requirements are not freeze, but a prototype is created as per requirement. By this model, the clients can get the ‘actual feel’ of a system, and they can understand the requirement more precisely.

Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determine the requirements.

The development of the prototype starts when the preliminary version of requirements specification document has been developed. At this stage, there is a reasonable understanding of the system and its needs and of which needs are unclear or likely to change. After the prototype has been developed, the end users and clients are given an opportunity to use the prototype and play with it.

Based on their experience, they provide feedback to the developers regarding the prototype: what is correct, what needs to be modified, what is missing, what is not needed, etc. • This cycle repeats until, in the judgment of the prototypers and analysts, the benefit from further changing the system and obtaining the feedback is compensate by the cost and time involved in making the changes and obtaining the feedback. Based on the feedback, the initial requirements are modified to produce the final requirements specification, which is then used to develop the production quality system.

Prototyping is not used, as it is feared that development costs may become large. However, in some situations, the cost of software development without prototyping may be more than with prototyping. There are two major reasons for this. • The experience of developing the prototype might reduce the cost of the later phases when the actual software development is done. • In many projects the requirements are constantly changing, particularly when development take as long time.

Overall, in projects where requirements are not properly understood in the beginning, using the prototyping process model can be the most effective method for developing the software. It is an excellent technique for reducing some types of risks associated with a project.

C) ITERATIVE ENHANCEMENT MODEL

The iterative enhancement model counters the third limitation of the waterfall model The basic idea is that the software should be developed in increments, each increment adding some functional capability to the system until the full system is implemented. At each step, extensions and design modifications can be made. • An advantage of this approach is that it can result in better testing because testing each increment is likely to be easier than testing the entire system as in the water fall model. • Furthermore, as in prototyping, the increments provide feedback to the developer and user that is useful for determining the final requirements of the system.

In the first step of this model, a simple initial implementation is done for a subset of the overall problem. • This subject is one that contains some of the key aspects of the problem that are easy to understand and implement and which form a useful and usable system. • A project control listis created that contains, all the tasks that must be performed to obtain the final implementation. This project control list gives an idea of how far the project is at any given step from the final system. • These three phases are called the design phase, implementation phase and analysis phase. The process is iterated until the project control list is empty, at which time the final implementation of the system will be available.

The project control list guides the iteration steps and keeps track of all tasks that must be done. • Based on the analysis, one of the tasks in the list can include redesign of defective components or redesign of the entire system. • However, redesign of the system will generally occur only in the initial steps. In the later steps, the design would have stabilized and there is less chance of redesign. • Each entry in the list is a task that should be performed in one step of the iterative enhancement process and should be simple enough to be completely understood. • Selecting tasks in this manner will minimize the chances of error and reduce the redesign work. • The design and implementation phases of each step can be performed in a top-down manner or by using some other technique.

One effective use of this type of model is for product development, in which the developers themselves provide the specifications and therefore have a lot of control on what specifications go in the system and what stay out. In fact, most products undergo this type of development process. • First, a version is released that contains some capability. Based on the feedback from users and experience with this version, a list of additional desirable features and capabilities is generated. These features form the basis of enhancement of the software, and are included in the next version. • In order words, the first version contains some core capability. And then more features are added to later version.

D) SPIRAL MODEL

In a typical application of the spiral model, one might start with an extra round zero, in which • the feasibility of the basic project objectives is studied. These project objectives may or may not lead to a development/enhancement project. • Such high level objectives include increasing the efficiency of code generation of a compiler, producing a new full –screen text editor and developing an environment for improving productivity. • The alternatives considered in this round are also typically very high-level, such as whether the organization should go for in-house development, or contract it out, or buy an existing product. • In round one, a concept of operation might be developed. The objectives are stated more precisely and quantitatively and the cost and other constraints are defined precisely.

The risks here are typically whether or not the goals can be met within the constraints. The plan for the next phase will be developed, which will involve defining separate activities for the project. • In round two the top-level requirements are developed. In succeeding rounds the actual development may be done. • This is relatively new model; it can encompass different development strategies. In addition to the development activities, it incorporates some of the management and planning activities into the model. • For high-risk projects this might be a preferred model.

The steps performed in this model can be summarized as below: • Identify the objectives of that cycle, and different alternatives possible to achieve it, and its constraints. • Analyze (evaluate) all alternatives found and find the risk & uncertainty. • Find out the strategies, which remove the uncertainty & risk, like benchmarking, simulation, etc. • Develop the software and plan the next phase. • Advantage: Each cycle is this model is completed by the review of the product as well as the plans. Thus it is useful for Development (new) as well as Enhancement (existing to new) projects. • For a typical project using this model, it starts with the round zero of feasibility study, and continue with round one, and so on until the actual development is over.

Software Engineering: A Systematic Approach to Software Development