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.
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
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].
