Unit1 Software Engineering(TCS-404)

Unit 1
What is Software 

Software can be defined as :

a. An instructions that when executed provide desired function and performance.
b. Data Structures that enable the program to adequately manipulate information.
c. Documents that describes the operation and use of the programs.

Introduction to Software Engineering:

It has numerious definitions.

“A systematization of the process of software development in order to ensure that best
solution in the most economic way.”

Software Engineering is the establishment and use of sound engineering principles in

order to obtain economical software that is reliable and works efficiently on real
machines.

Typical formal definitions of software engineering are

• "the application of a systematic, disciplined, quantifiable approach to the

development, operation, and maintenance of software".
• "an engineering discipline that is concerned with all aspects of software
production"
• "the establishment and use of sound engineering principles in order to
economically obtain software that is reliable and works efficiently on real
machines.

Prinicples of software engineering:

1. Make quality Number one: Quality must be quantified and mechanisms put
into lace to motivate and reward its achievement.
2. High Quality Software is Possible:
3. Give products to customer Early
4. Determine the problem before writing the requirements
5. Evaluate Design Alternative
6. Use an Appropriate Process Model
7. Minimize Intellectual Distance
8. Good Management is more important than good technology
9. People are the key to success
10. Follow with Care

1
Unit1 Software Engineering(TCS-404)

Software Components :

A software component is a system element offering a predefined service and able to

communicate with other components.

• Multiple-use
• Non-context-specific
• Composable with other components
• Non-investigable through its interfaces
• A unit of independent deployment and versioning

A simpler definition can be: A component is an object written to a specification. It does

not matter what the specification is: COM, Java Beans, etc., as long as the object adheres
to the specification. It is only by adhering to the specification that the object becomes a
component and gains features like reusability and so forth.

Software Crisis:

The causes of the software crisis were linked to the overall complexity of the software
process and the relative immaturity of software engineering as a profession. The crisis
manifested itself in several ways:

Projects running over-budget.

Projects running over-time.

Software was of low quality.

Software often did not meet requirements.

Projects were unmanageable and code difficult to maintain.

Software Process Model:

A software development process is a structure imposed on the development of a

software product. Synonyms include software life cycle and software process. There are
several models for such processes, each describing approaches to a variety of tasks or
activities that take place during the process

2
Unit1 Software Engineering(TCS-404)

Waterfall Model:

Enlarge Image
.

In "The Waterfall" approach, the whole process of software development is divided into
separate process phases. The phases in Waterfall model are: Requirement Specifications
phase, Software Design, Implementation and Testing & Maintenance. All these phases
are cascaded to each other so that second phase is started as and when defined set of
goals are achieved for first phase and it is signed off, so the name "Waterfall Model". All
the methods and processes undertaken in Waterfall Model are more visible.

The stages of "The Waterfall Model" are:

Requirement Analysis & Definition: All possible requirements of the system to be
developed are captured in this phase. Requirements are set of functionalities and
constraints that the end-user (who will be using the system) expects from the system. The
requirements are gathered from the end-user by consultation, these requirements are
analyzed for their validity and the possibility of incorporating the requirements in the
system to be development is also studied. Finally, a Requirement Specification document
is created which serves the purpose of guideline for the next phase of the model.

System & Software Design: Before a starting for actual coding, it is highly important to
understand what we are going to create and what it should look like? The requirement
specifications from first phase are studied in this phase and system design is prepared.
System Design helps in specifying hardware and system requirements and also helps in
defining overall system architecture. The system design specifications serve as input for
the next phase of the model.

Implementation & Unit Testing: On receiving system design documents, the work
is0020divided in modules/units and actual coding is started. The system is first developed
in small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality; this is referred to as Unit Testing. Unit testing

3
Unit1 Software Engineering(TCS-404)

mainly verifies if the modules/units meet their specifications.

Integration & System Testing: As specified above, the system is first divided in units
which are developed and tested for their functionalities. These units are integrated into a
complete system during Integration phase and tested to check if all modules/units
coordinate between each other and the system as a whole behaves as per the
specifications. After successfully testing the software, it is delivered to the customer.

Operations & Maintenance: This phase of "The Waterfall Model" is virtually never
ending phase (Very long). Generally, problems with the system developed (which are not
found during the development life cycle) come up after its practical use starts, so the
issues related to the system are solved after deployment of the system. Not all the
problems come in picture directly but they arise time to time and needs to be solved;
hence this process is referred as Maintenance.

There are some disadvantages of the Waterfall Model.

1) As it is very important to gather all possible requirements during the Requirement
Gathering and Analysis phase in order to properly design the system, not all requirements
are received at once, the requirements from customer goes on getting added to the list
even after the end of "Requirement Gathering and Analysis" phase, this affects the
system development process and its success in negative aspects.

2) The problems with one phase are never solved completely during that phase and in fact
many problems regarding a particular phase arise after the phase is signed off, this results
in badly structured system as not all the problems (related to a phase) are solved during
the same phase.

3) The project is not partitioned in phases in flexible way.

4) As the requirements of the customer goes on getting added to the list, not all the
requirements are fulfilled, this results in development of almost unusable system. These
requirements are then met in newer version of the system; this increases the cost of
system development.

Sprial Model:

The spiral model, illustrated in Fig. combines the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model, therein providing the potential
for rapid development of incremental versions of the software. In this model the software
is developed in a series of incremental releases with the early stages being either paper
models or prototypes. Later iterations become increasingly more complete versions of the
product.

4
Unit1 Software Engineering(TCS-404)

The spiral model, also known as the spiral lifecycle model, is a systems development
method (SDM) used in information technology (IT). This model of development
combines the features of the prototyping model and the waterfall model. The spiral model
is intended for large, expensive, and complicated projects.

The steps in the spiral model can be generalized as follows:

The preceding steps are iterated until the customer is satisfied that the refined
prototype represents the final product desired.

The new system requirements are defined in as much detail as possible. This usually
involves interviewing a number of users representing all the external or internal users and
other aspects of the existing system.

A preliminary design is created for the new system.

A first prototype of the new system is constructed from the preliminary design. This is
usually a scaled-down system, and represents an approximation of the characteristics of
the final product.

A second prototype is evolved by a fourfold procedure: (1) evaluating the first

prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements
of the second prototype; (3) planning and designing the second prototype; (4)
constructing and testing the second prototype.

5
Unit1 Software Engineering(TCS-404)

At the customer's option, the entire project can be aborted if the risk is deemed too great.
Risk factors might involve development cost overruns, operating-cost miscalculation, or
any other factor that could, in the customer's judgment, result in a less-than-satisfactory
final product.

The existing prototype is evaluated in the same manner as was the previous prototype,
and, if necessary, another prototype is developed from it according to the fourfold
procedure outlined above.

The preceding steps are iterated until the customer is satisfied that the refined prototype
represents the final product desired.

The final system is constructed, based on the refined prototype.

The final system is thoroughly evaluated and tested. Routine maintenance is carried out
on a continuing basis to prevent large-scale failures and to minimize downtime.

Advantages of the Spiral Model

• The spiral model is a realistic approach to the development of large-scale software

products because the software evolves as the process progresses. In addition, the
developer and the client better understand and react to risks at each evolutionary
level.
• The model uses prototyping as a risk reduction mechanism and allows for the
development of prototypes at any stage of the evolutionary development.
• It maintains a systematic stepwise approach, like the classic life cycle model, but
incorporates it into an iterative framework that more reflect the real world.
• If employed correctly, this model should reduce risks before they become
problematic, as consideration of technical risks are considered at all stages.

Disadvantages of the Spiral Model

• Demands considerable risk-assessment expertise

• It has not been employed as much proven models (e.g. the WF model) and hence
may prove difficult to ‘sell’ to the client (esp. where a contract is involved) that
this model is controllable and efficient. [More study needs to be done in this
regard]

6
Unit1 Software Engineering(TCS-404)

Rapid Application Development: RAD (rapid application development) is a

concept that products can be developed faster and of higher quality through:

• Gathering requirements using workshops or focus groups

• Prototyping and early, reiterative user testing of designs
• The re-use of software components
• A rigidly paced schedule that defers design improvements to the next product
version
• Less formality in reviews and other team communication

Pros

• Increased speed of development through methods including rapid prototyping,

virtualization of system related routines, and other techniques.
• Decreased end-user functionality (arising from narrower design focus), hence
reduced complexity
• Larger emphasis on simplicity and usability of GUI design

Cons

• Reduced Scalability, and reduced features when a RAD developed application

starts as a prototype and evolves into a finished application
• Reduced features occur due to time boxing when features are pushed to later
versions in order to finish a release in a short amount of time
• The data needed should already exist

Evolutionary Model:

This model is also known as successive version model. In this model , the system is first
broken down into several modules or functional units that can be incrementally
implemented and delivered . The developers first develop the core modules of the system.
This initial product skeleton is refined into increasing levels of capability by adding new
functionalities in successive versions. In this approach, each successive version of the
product is a functioning system capable of performing some more useful work. Therfore
as the user gets a chance to experiment with a partially developed system much before
the fully developed version is released, the evolutionary model facilitates to elicit the
exact requirements of the user for incorporating into the fully developed system.

Evolutionary model is useful for large problems. Where it is easier to identify modules
for incremental implementation, thus obviating the need to commit large resources in one
go for development of the full fledged system.

7
Unit1 Software Engineering(TCS-404)

Prototyping Model:

Software prototyping is the process of creating an incomplete model of the future full
featured software program, which can be used to let the users have a first idea of the

completed program or allow the clients to evaluate the program. This has several
benefits: The software designer and implementer can obtain feedback from the users
early in the project. The client and the contractor can compare if the software made
matches the software specification, according to which the software program is built. It
also allows the software engineer some insight into the accuracy of initial project
estimates and whether the deadlines and milestones proposed can be successfully met.

Advantages of prototyping
There are many advantages to using prototyping in software development.

Reduced time and costs: Prototyping can improve the quality of requirements and
specifications provided to developers. Because changes cost exponentially more to
implement as they are detected later in development, the early determination of what the
user really wants can result in faster and less expensive software.

Improved and increased user involvement: Prototyping requires user involvement and
allows them to see and interact with a prototype allowing them to provide better and
more complete feedback and specifications. The presence of the prototype being
examined by the user prevents many misunderstandings and miscommunications that
occur when each side believe the other understands what they said. Since users know the
problem domain better than anyone on the development team does, increased interaction
can result in final product that has greater tangible and intangible quality. The final
product is more likely to satisfy the users desire for look, feel and performance

Disadvantages of prototyping
Using, or perhaps misusing, prototyping can also have disadvantages

Insufficient analysis: The focus on a limited prototype can distract developers from
properly analyzing the complete project. This can lead to overlooking better solutions,
preparation of incomplete specifications or the conversion of limited prototypes into
poorly engineered final projects that are hard to maintain. Further, since a prototype is
limited in functionality it may not scale well if the prototype is used as the basis of a final
deliverable, which may not be noticed if developers are too focused on building a
prototype as a model.

8
Unit1 Software Engineering(TCS-404)

User confusion of prototype and finished system: Users can begin to think that a
prototype, intended to be thrown away, is actually a final system that merely needs to be
finished or polished. (They are, for example, often unaware of the effort needed to add
error-checking and security features which a prototype may not have.) This can lead them
to expect the prototype to accurately model the performance of the final system when this
is not the intent of the developers. Users can also become attached to features that were
included in a prototype for consideration and then removed from the specification for a
final system. If users are able to require all proposed features be included in the final
system this can lead to feature creep.

Developer attachment to prototype: Developers can also become attached to prototypes

they have spent a great deal of effort producing; this can lead to problems like attempting
to convert a limited prototype into a final system when it does not have an appropriate
underlying architecture. (This may suggest that throwaway prototyping, rather than
evolutionary prototyping, should be used.)

Excessive development time of the prototype: A key property to prototyping is the fact
that it is supposed to be done quickly. If the developers lose sight of this fact, they very
well may try to develop a prototype that is too complex. When the prototype is thrown
away the precisely developed requirements that it provides may not yield a sufficient
increase in productivity to make up for the time spent developing the prototype. Users
can become stuck in debates over details of the prototype, holding up the development
team and delaying the final product.

Expense of implementing prototyping: The start up costs for building a development

team focused on prototyping may be high. Many companies have development
methodologies in place, and changing them can mean retraining, retooling, or both. Many
companies tend to just jump into the prototyping without bothering to retrain their
workers as much as they should.

A common problem with adopting prototyping technology is high expectations

for productivity with insufficient effort behind the learning curve. In addition to
training for the use of a prototyping technique, there is an often overlooked need
for developing corporate and project specific underlying structure to support the
technology. When this underlying structure is omitted, lower productivity can
often result