UNIT 1. INTRODUCTION TO SOFTWARE ENGINEERING AND PROCESS MODELS
             1. INTRODUCTION TO SOFTWARE ENGINEERING

1..1.1 DEFINATION 

                            Software engineering is the study and an application of engineering to thedesign, development, and maintenance of software.^[1][2][3]

Typical formal definitions of software engineering are:

• "research, design, develop, and test operating systems-level software, compilers, and network distribution software for medical, industrial, military, communications, aerospace, business, scientific, and general computing applications."^[4]
• "the systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software";^[5]
• "the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software";^[6]
• "an engineering discipline that is concerned with all aspects of software production";^[7]
• and "the establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines."^[8]

           

1.2 NEED  

      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. Suppose you have a friend who asked you to build a small wall . You would be able to do that using your common sense. You will get building materials like bricks; cement etc. and you will then build the wall. But what would happen if the same friend asked you to build a large multistoried building . You don't have a very good idea about building such a huge complex. It would be very difficult to extend your idea about a small wall construction into constructing a large building. Even if you tried to build a large building, it would collapse because you would not have the requisite knowledge about the strength of materials, testing, planning, architectural design, etc. Building a small wall and building a large building are entirely different ball games. You can use your intuition and still be successful in building a small wall, but building a large building requires knowledge of civil, architectural and other engineering
principles.

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. 

ABSTACTION 

The principle of abstraction (in fig.1.4) implies that a problem can be simplified by omitting rrelevant details. In other words, the main purpose of abstraction is to consider only those aspects of the problem that are relevant for certain purpose and suppress other aspects that are not relevant for the given purpose. Oncethe simpler problem is solved, then the omitted details can be taken into
consideration to solve the next lower level abstraction, and so on. Abstraction is
a powerful way of reducing the complexity of the problem.

DECOMPOSITION

The other approach to tackle problem complexity is decomposition. In this technique, a complex problem is divided into several smaller problems and then the smaller problems are solved one by one. However, in this technique any random decomposition of a problem into smaller parts will not help. The problem has to be decomposed such that each component of the decomposed problem
can be solved independently and then the solution of the different components can be combined to get the full solution. A good decomposition of a problem as shown in fig.1.5 should minimize interactions among various components. If the different subcomponents are interrelated, then the different components cannot be solved separately and the desired reduction in complexity will not be realized.

1.1.3 SOFTWARE ENGINEERING PROBLEMS 

          The Problem of scale:    A fundamental problem of software engineering 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 systems generally do not scale up to large systems. A different set of methods has to be used for developing large software. Any large project involves the use of technology and project management.

For software projects, by technology we mean the methods, procedures, and tools that are used. In small projects, informal methods for development and management can be used. However, for large projects, both have to be much more formal.

While dealing with a small software project, the technology requirement is low and the project management requirement is also low. However, when the scale changes to large systems, to solve such problems properly, it is essential that we move in both directions-the methods used for development need to be more formal, and the project management for the development project also needs to be more formal.

            Cost, schedule and quality: The cost of developing a system is the cost of the resources used for the system, which, in the case of software, are the manpower, hardware, software, and the other support resources. Generally, the manpower component is predominant, as software development is largely labor-intensive and the cost of the computing systems is now quite low.

Hence, the cost of software project is measured in terms of person-months, i.e. the cost is considered to be the total number of person-months spent in the project. Schedule is an important factor in many projects. Business trends are dictating that the time to market of a product should be reduced; that is, the cycle time from concept to delivery should be small. Any business with such a requirement will also require that the cycle time for building a software needed by the business be small.

One of the major factors driving any production discipline is quality. We can view quality of a software product as having three dimensions:

             Product Operation
             Product Transition
             Product Revision        

The Problem of consistency: Though high quality, low cost and small cycle time are the primary objectives of any project, for an organization there is another goal: consistency. An organization involved in software development does not just want low cost and high quality for a project, but it wants these consistently.                                               

1.1.4 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. 1.6: Change in the relative cost of hardware and software over time Organizations are spending larger and larger portions of their budget on software. Not only are the software products turning out to be more expensive than hardware, but they also present a host of other problems to the customers:
software products are difficult to alter, debug, and enhance; use resources nonoptimally; often fail to meet the user requirements; are far from being reliable; frequently crash; and are often delivered late. Among these, the trend of increasing software costs is probably the most important symptom of the present software crisis. Remember that the cost we are talking of here is not on account of increased features, but due to ineffective development of the product characterized by inefficient resource usage, and time and cost over-runs. There are many factors that have contributed to the making of the present software crisis. Factors are larger problem sizes, lack of adequate training in software  engineering, increasing skill shortage, and low productivity improvements. It is believed that the only satisfactory solution to the present software crisis can possibly come from a spread of software engineering practices among the engineers, coupled with further advancements to the software engineering discipline itself.

1.1.5 Program vs. software product

Programs are developed by individuals for their personal use. They are therefore,
small in size and have limited functionality but software products are extremely
large. In case of a program, the programmer himself is the sole user but on the
other hand, in case of a software product, most users are not involved with the
development. In case of a program, a single developer is involved but in case of
a software product, a large number of developers are involved. For a program,
the user interface may not be very important, because the programmer is the
sole user. On the other hand, for a software product, user interface must be
carefully designed and implemented because developers of that product and
users of that product are totally different. In case of a program, very little
documentation is expected, but a software product must be well documented. A
program can be developed according to the programmer’s individual style of
development, but a software product must be developed using the accepted
software engineering principles.

1.1.6 A software   Life cycle model

A software life cycle model (also called process model) is a descriptive and diagrammatic representation of the software life cycle. A life cycle model represents all the activities required to make a software product transit through its life cycle phases. It also captures the order in which these activities are to be undertaken. In other words, a life cycle model maps the different activities performed on a software product from its inception to retirement. Different life cycle models may map the basic development activities to phases in different ways. Thus, no matter which life cycle model is followed, the basic activities are included in all life cycle models though the activities may be carried out in different orders in different life cycle models. During any life cycle phase, more
than one activity may also be carried out. For example, the design phase might consist of the structured analysis activity followed by the structured design activity.
The need for a software life cycle model
The development team must identify a suitable life cycle model for the particular project and then adhere to it. Without using of a particular life cycle model the development of a software product would not be in a systematic and disciplined manner. When a software product is being developed by a team there must be a clear understanding among team members about when and what to do.
Otherwise it would lead to chaos and project failure. This problem can be illustrated by using an example. Suppose a software development problem is divided into several parts and the parts are assigned to the team members. From then on, suppose the team members are allowed the freedom to develop the parts assigned to them in whatever way they like. It is possible that one member might start writing the code for his part, another might decide to prepare the test documents first, and some other engineer might begin with the design phase of the parts assigned to him. This would be one of the perfect recipes for project failure. A software life cycle model defines entry and exit criteria for every phase. A phase can start only if its phase-entry criteria have been satisfied. So without software life cycle model the entry and exit criteria for a phase cannot be recognized. Without software life cycle models (such as classical waterfall model, iterative waterfall model, prototyping model, evolutionary model, spiral model etc.) it becomes difficult for software project managers to monitor the progress of the project.

1.2 Process Models

1.2.1What is Waterfall model- advantages, disadvantages and when to use it?

The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model.  It is very simple to understand and use.  In a waterfall model, each phase must be completed fully before the next phase can begin. This type of model is basically used for the for the project which is small and there are no uncertain requirements. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. In this model the testing starts only after the development is complete. In waterfall model phases do not overlap.

Diagram of Waterfall-model: 

Advantages of waterfall model:

§  This model is simple and easy to understand and use.

§  It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.

§  In this model phases are processed and completed one at a time. Phases do not overlap.

§  Waterfall model works well for smaller projects where requirements are very well understood.

 Disadvantages of waterfall model:

§  Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.

§  No working software is produced until late during the life cycle.

§  High amounts of risk and uncertainty.

§  Not a good model for complex and object-oriented projects.

§  Poor model for long and ongoing projects.

§  Not suitable for the projects where requirements are at a moderate to high risk of changing.

When to use the waterfall model:

§  This model is used only when the requirements are very well known, clear and fixed.

§  Product definition is stable.

§  Technology is understood.

§  There are no ambiguous requirements

§  Ample resources with required expertise are available freely

§  The project is short.

Very less customer enter action is involved during the development of the product. Once the product is ready then only it can be demoed to the end users. Once the product is developed and if any failure occurs then the cost of fixing such issues are very high, because we need to update everywhere from document till the logic.

1.2.2 What is Iterative model- advantages, disadvantages and when to use it?

An iterative life cycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model.

For example:

In the diagram above when we work iteratively we create rough product or product piece in one iteration, then review it and improve it in next iteration and so on until it’s finished. As shown in the image above, in the first iteration the whole painting is sketched roughly, then in the second iteration colors are filled and in the third iteration finishing is done. Hence, in iterative model the whole product is developed step by step.

Diagram of Iterative model:

Advantages of Iterative model:

§  In iterative model we can only create a high-level design of the application before we actually begin to build the product and define the design solution for the entire product. Later on we can design and built a skeleton version of that, and then evolved the design based on what had been built.

§  In iterative model we are building and improving the product step by step. Hence we can track the defects at early stages. This avoids the downward flow of the defects.

§  In iterative model we can get the reliable user feedback. When presenting sketches and blueprints of the product to users for their feedback, we are effectively asking them to imagine how the product will work.

§  In iterative model less time is spent on documenting and more time is given for designing.

 Disadvantages of Iterative model: 

§  Each phase of an iteration is rigid with no overlaps

§  Costly system architecture or design issues may arise because not all requirements are gathered up front for the entire lifecycle

When to use iterative model:

§  Requirements of the complete system are clearly defined and understood.

§  When the project is big.

§  Major requirements must be defined; however, some details can evolve with time.

To speed up development, parallelism between the different iterations can be employed. That is, a new iteration commences before the system produced by the current iteration is released, and hence development of a new release happens in parallel with the development of the current release. By starting an iteration before the previous iteration has completed, it is possible to reduce the average delivery time for iterations. However, to support parallel execution, each iteration has to be structured properly and teams have to be organized suitably. The timeboxing model proposes an approach for these [60, 59].

1.2.3 What is Prototype model- advantages, disadvantages and when to use it?

 ?

The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements. This prototype is developed based on the currently known requirements. By using this prototype, the client can get an “actual feel” of the system, since the interactions with prototype can enable the client to better understand the requirements of the desired system.  Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements. The prototype are usually not complete systems and many of the details are not built in the prototype. The goal is to provide a system with overall functionality.

Diagram of Prototype model:

Advantages of Prototype model:

§  Users are actively involved in the development

§  Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed.

§  Errors can be detected much earlier.

§  Quicker user feedback is available leading to better solutions.

§  Missing functionality can be identified easily

§  Confusing or difficult functions can be identified
Requirements validation, Quick implementation of, incomplete, but
functional, application.

Disadvantages of Prototype model:

§  Leads to implementing and then repairing way of building systems.

§  Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.

§  Incomplete application may cause application not to be used as the
full system was designed
Incomplete or inadequate problem analysis.

When to use Prototype model:  

§  Prototype model should be used when the desired system needs to have a lot of interaction with the end users.

§  Typically, online systems, web interfaces have a very high amount of interaction with end users, are best suited for Prototype model. It might take a while for a system to be built that allows ease of use and needs minimal training for the end user.

§  Prototyping ensures that the end users constantly work with the system and provide a feedback which is incorporated in the prototype to result in a useable system. They are excellent for designing good human computer interface systems.

1.2.4 What is Spiral model- advantages, disadvantages and when to use it?

The spiral model is similar to the incremental model, with more emphasis placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral.

Planning Phase: Requirements are gathered during the planning phase. Requirements like ‘BRS’ that is ‘Bussiness Requirement Specifications’ and ‘SRS’ that is ‘System Requirement specifications’.

Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and alternate solutions.  A prototype is produced at the end of the risk analysis phase. If any risk is found during the risk analysis then alternate solutions are suggested and implemented.

Engineering Phase: In this phase software is developed, along with testing at the end of the phase. Hence in this phase the development and testing is done.

Evaluation phase: This phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.

Diagram of Spiral model:

Advantages of Spiral model:

§  High amount of risk analysis hence, avoidance of Risk is enhanced.

§  Good for large and mission-critical projects.

§  Strong approval and documentation control.

§  Additional Functionality can be added at a later date.

§  Software is produced early in the software life cycle.

Disadvantages of Spiral model:

§  Can be a costly model to use.

§  Risk analysis requires highly specific expertise.

§  Project’s success is highly dependent on the risk analysis phase.

§  Doesn’t work well for smaller projects.

 When to use Spiral model:

§  When costs and risk evaluation is important

§  For medium to high-risk projects

§  Long-term project commitment unwise because of potential changes to economic priorities

§  Users are unsure of their needs

§  Requirements are complex

§  New product line

§  Significant changes are expected (research and exploration)

1.2.5 What is RAD model- advantages, disadvantages and when to use it?

 ?

RAD model is Rapid Application Development model. It is a type of incremental model. In RAD model the components or functions are developed in parallel as if they were mini projects. The developments are time boxed, delivered and then assembled into a working prototype.  This can quickly give the customer something to see and use and to provide feedback regarding the delivery and their requirements.

Diagram of RAD-Model:

The phases in the rapid application development (RAD) model are:

Business modeling: The information flow is identified between various business functions.
Data modeling: Information gathered from business modeling is used to define data objects that are needed for the business.
Process modeling: Data objects defined in data modeling are converted to achieve the business information flow to achieve some specific business objective. Description are identified and created for CRUD of data objects.
Application generation: Automated tools are used to convert process models into code and      the       actual            system.
Testing and turnover: Test new components and all the interfaces.

Advantages of the RAD model:

§  Reduced development time.

§  Increases reusability of components

§  Quick initial reviews occur

§  Encourages customer feedback

§  Integration from very beginning solves a lot of integration issues.

Disadvantages of RAD model:

§  Depends on strong team and individual performances for identifying business requirements.

§  Only system that can be modularized can be built using RAD

§  Requires highly skilled developers/designers.

§  High dependency on modeling skills

§  Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.

 When to use RAD model:

§  RAD should be used when there is a need to create a system that can be modularized in 2-3 months of time.

§  It should be used if there’s high availability of designers for modeling and the budget is high enough to afford their cost along with the cost of automated code generating tools.

§  RAD SDLC model should be chosen only if resources with high business knowledge are available and there is a need to produce the system in a short span of time (2-3 months)

1.2.6 Timeboxing  Model

In the timeboxing model, the basic unit of development is a time box, which is of fixed duration. Since the duration is fixed, a key factor in selecting the requirements or features to be built in a time box is what can be fit into the time box. This is in contrast to regular iterative approaches where the functionality is selected and then the time to deliver is determined. Timeboxing changes the perspective of development and makes the schedule a nonnegotiable and a high-priority commitment.

Each time box is divided into a sequence of stages, like in the waterfall model. Each stage performs some clearly defined task for the iteration and produces a clearly defined output. The model also requires that the duration of each stage, that is, the time it takes to complete the task of that stage, is approximately the same. Furthermore, the model requires that there be a dedicated team for each stage. That is, the team for a stage performs only tasks of that stage—tasks for other stages are performed by their respective teams. This is quite different from other iterative models where the implicit assumption is that the same team performs all the different tasks of the project or the iteration.

Having time-boxed iterations with stages of equal duration and having dedicated teams renders itself to pipelining of different iterations. (Pipelining is a concept from hardware in which different instructions are executed in parallel, with the execution of a new instruction starting once the first stage of the previous instruction is finished.)

To illustrate the use of this model, consider a time box consisting of three stages: requirement specification, build, and deployment. The requirement stage is executed by its team of analysts and ends with a prioritized list of requirements to be built in this iteration along with a high-level design. The build team develops the code for implementing the requirements, and performs the testing. The tested code is then handed over to the deployment team, which performs predeployment tests, and then installs the system for production use. These three stages are such that they can be done in approximately equal time in an iteration.

With a time box of three stages, the project proceeds as follows. When the requirements team has finished requirements for timebox-1, the requirements are given to the build team for building the software. The requirements team then goes on and starts preparing the requirements for timebox-2. When the build for timebox-1 is completed, the code is handed over to the deployment team, and the build team moves on to build code for requirements for timebox- 2, and the requirements team moves on to doing requirements for timebox-3. This pipelined execution of the timeboxing process is shown in Figure 2.8 [59].

 

Figure 2.8: Executing the timeboxing process model

With a three-stage time box, at most three iterations can be concurrently in progress. If the time box is of size T days, then the first software delivery will occur after T days. The subsequent deliveries, however, will take place after every T/3 days. For example, if the time box duration T is 9 weeks (and each stage duration is 3 weeks), the first delivery is made 9 weeks after the start of the project. The second delivery is made after 12 weeks, the third after 15 weeks, and so on. Contrast this with a linear execution of iterations, in which the first delivery will be made after 9 weeks, the second after 18 weeks, the third after 27 weeks, and so on.

There are three teams working on the project—the requirements team, the build team, and the deployment team. The teamwise activity for the 3-stage pipeline discussed above is shown in Figure 2.9 [59].

It should be clear that the duration of each iteration has not been reduced.

Figure 2.9: Tasks of different teams

The total work done in a time box and the effort spent in it also remains the same—the same amount of software is delivered at the end of each iteration as the time box undergoes the same stages. If the effort and time spent in each iteration also remains the same, then what is the cost of reducing the delivery time? The real cost of this reduced time is in the resources used in this model. With timeboxing, there are dedicated teams for different stages and the total team size for the project is the sum of teams of different stages. This is the main difference from the situation where there is a single team which performs all the stages and the entire team works on the same iteration.

Hence, the timeboxing provides an approach for utilizing additional manpower to reduce the delivery time. It is well known that with standard methods of executing projects, we cannot compress the cycle time of a project substantially by adding more manpower. However, through the timeboxing model, we can use more manpower in a manner such that by parallel execution of different stages we are able to deliver software quicker. In other words, it provides a way of shortening delivery times through the use of additional manpower.

Timeboxing is well suited for projects that require a large number of features to be developed in a short time around a stable architecture using stable technologies. These features should be such that there is some flexibility in grouping them for building a meaningful system in an iteration that provides value to the users. The main cost of this model is the increased complexity of project management (and managing the products being developed) as multiple developments are concurrently active. Also, the impact of unusual situations in an iteration can be quite disruptive. Further details about the model, as well as a detailed example of applying the model on a real commercial project, are given in [60, 59].