0% found this document useful (0 votes)
86 views13 pages

Software Engineering

This is my software engineering class notes

Uploaded by

reddycoder2007
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
86 views13 pages

Software Engineering

This is my software engineering class notes

Uploaded by

reddycoder2007
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

COURSE HANDOUT

CHAPTER – 1

1.0 Understand the basics of Software Engineering Designs & Life Cycle Models

1.1 Know the Evolution and Impact of the Software Engineering

1.1.1 Evolution of software engineering

In the early days of computer evolution, people used to work directly with the hardware
components of computer.(e.g. With vacuum tubes..) As we know that difficulty of working with
hardware components. The users of computer were expected same type interface mechanism.
Hence the rich user set of computers were planned to develop that interface mechanism in the form
of software. But they were not aware of the development process of software. So they tried without
any guidelines or predefined rule set to develop software.
Because of the lack of proper development strategies, documentations and maintenance plans, the
software system that was developed was costlier than before and also it took more time to develop
the entire system. The lines of codes were increased to a very large number, large code increasing
the complexity of the software and also there were no proper procedure to identify and rectify the
bugs or errors. So most of the times the system that was developed unusable by the customer
because of the complexity involving to use. Due to lack of maintenance after delivering to the
customer, no plans to overcome the bugs or errors occurred while in use. This situation is called
Software Crisis.

1.1.2 A Solution to the software Crisis?

Software Crisis was a mess situation for software developers. So they have to redeem their
development process. By observing other department development structure,[e.g. Automobile
Industry..] various levels or stages in their development structure, the same type of approach had
been applied (or) implemented in software also. Hence, people were compelled to think about the
systematic approach to the development of software. This systematic approach given an
engineering perspective view to the software development, hence it is called as “software
engineering” [like Engineering Drawing].
A solution to the software crisis is software engineering.
1
Definition: “Software engineering is the application of disciplined, quantifiable approach to the
development Operation and maintenance of software”.
The following steps are applicable to the majority of software projects:
a) Communication: Involves heavy communication and collaboration with the customer
for requirements gathering and other related information.
b) Planning: Establishes a plan for the software engineering work that follows.
c) Modeling: This activity involves the creation of models that allow the developers and the
customers to better understand software requirements and the design that will achieve those
requirements.
d) Construction: combines the code generation and testing.
e) Deployment: The software is delivered to the customer who evaluates the delivered
product and provides feedback based on the evaluation.

1.2 Programs Vs Software Products:

Program:

a. Programs are developed by individuals for their personal use.


b. Programs are small in size and have limited functionality.
c.The programmer himself is the sole user.
d. A single developer is involved.
e.User interface may not be very important; the programmer is the sole user.
f. Little documentation is expected.
g. A program may be developed according to the programmer’s individual style of
development.

Software product:

a.Software products have multiple users.


b. Software Products are extremely large.
c.Most of actual users are not involved with the development.
d. A large number of developers are involved.
e.Here user interface must be carefully designed and implemented because developers of that
product and users are totally different.
f. Software Product must be well documented.
g. Must be developed using the accepted Software Engineering principles.

2
1.3 Understand the Evolution of Software Engineering design:

1.3.1 Early Computing Programming


As we know that in the early 1950s, computers were slow and expensive. Though the
programs at that time were very small in size, these computers took considerable time to process
them. They relied on assembly language which was specific to computer architecture. Thus,
developing a program required lot of effort. Every programmer used his own style to develop the
programs.

Programming languages are used to specify algorithmic steps in computer understanding format.
Programming languages are broadly classified into three types:

a) High Level Languages


b) Assembly Level or Middle Level Languages
c) Low Level or Machine Level Languages.

A mechanism can understand only 0’s and 1’s that is called machine level language. Working with
machine level language is very difficult.

In Assembly level language coding will be started with Mnemonics. An Assembler converts
Arithmetic Logic program into machine code.

1.3.2 High Level Language Programming:

With the introduction of semiconductor technology, the computers became smaller, faster, cheaper,
and reliable than their predecessors. One of the major developments includes the progress from
assembly language to high-level languages. Early high level programming languages such as
COBOL and FORTRAN came into existence. As a result, the programming became easier and
thus, increased the productivity of the programmers. However, still the programs were limited in
size and the programmers developed programs using their own style and experience.

High Level Languages are made coding closer to human readable. Compiler is to used convert
high level language programs into machine code.

Irrespective of programming languages each program consists two flows:

a) Control Flow
b) Data Flow

3
1.3.3 Control Flow Design:

With the advent of powerful machines and high level languages, the usage of computers grew
rapidly: In addition, the nature of programs also changed from simple to complex. The increased
size and the complexity could not be managed by individual style. It was analyzed that clarity of
control flow (the sequence in which the program’s instructions are executed) is of great
importance. To help the programmer to design programs having good control flow
structure, flowcharting technique was developed. In flowcharting technique, the algorithm is
represented using flowcharts. A flowchart is a graphical representation that depicts the sequence
of operations to be carried out to solve a given problem.
Note that having more GOTO constructs in the flowchart makes the control flow messy, which
makes it difficult to understand and debug. In order to provide clarity of control flow, the use of
GOTO constructs in flowcharts should be avoided and structured constructs-
decision, sequence, and loop-should be used to develop structured flowcharts. The decision
structures are used for conditional execution of statements (for example, if statement). The
sequence structures are used for the sequentially executed statements. The loop structures are
used for performing some repetitive tasks in the program. The use of structured constructs
formed the basis of the structured programming methodology.
Structured programming became a powerful tool that allowed programmers to write moderately
complex programs easily. It forces a logical structure in the program to be written in an efficient
and understandable manner. The purpose of structured programming is to make the software
code easy to modify when required. Some languages such as Ada, Pascal, and dBase are
designed with features that implement the logical program structure in the software code.

1.3.4 Data-structure oriented Design:

The data structure-oriented design approach utilizes the data structures of the input data, internal
data (for example databases) and output data to develop software. In the data structure-oriented
approach, the emphasis is on the object, which is the d ata. The structure of information, called
data structure, has an important impact on the complexity and efficiency of algorithms designed
to process information.

Software design is closely related to the data structure of the system, for example, alternative
data will require a conditional processing element, repetitive data will require a control feature
for repetition and a hierarchical data structure will requ ire a hierarchical software structure. Data
structure-oriented design is best utilized in applications that ave a well-defined, hierarchical
structure of information.

As both data flow and data structure oriented design approaches are based on considerations in
the information domain, there are similarities between both approaches. Both depend on the
analysis step to build the foundation for later steps. Both attemp t to transform information into a
software structure; both are driven by information. In data structure-oriented design information
structure are represented using hierarchical diagrams; DFD has little relevance; transformation
and transaction flows are not considered. Data structure-oriented design have a few tasks -
evaluate the characteristics of the data structure, represent the data in its lowest form such as
repetition, sequence or selection, map the data representation into a control hierarchy fo r
software, refine the control hierarchy and then develop a procedural description of the software.
4
Some examples of the data structure-oriented design approach are the Jackson System
Development (JSD) and the Data Structured Systems Development (DDSD) w hich is also called
the Warnier-Orr methodology.

1.3.5 Data Flow Design:

With the introduction of very Large Scale Integrated circuits (VLSI), the computers became more
powerful and faster. As a result, various significant developments like networking and GUIs came
into being. Clearly, the complexity of software could not be dealt using control flow based design.
Thus, a new technique, namely, data-flow-oriented technique came into existence. In this
technique, the flow of data through business functions or processes is represented using Data-
flow Diagram (DFD). IEEE defines a data-flow diagram (also known as bubble chart and work-
flow diagram) as ‘a diagram that depicts data sources, data sinks, data storage, and processes
performed on data as nodes, and logical flow of data as links between the nodes.’

1.3.6 Object Oriented Design:

Object-oriented design technique has revolutionized the process of software development. It not
only includes the best features of structured programming but also some new and powerful
features such as encapsulation, abstraction, inheritance, and polymorphism. These new features
have tremendously helped in the development of well-designed and high-quality software. Object-
oriented techniques are widely used these days as they allow reusability of the code. They lead to
faster software development and high-quality programs. Moreover, they are easier to adapt and
scale, that is, large systems can be created by assembling reusable subsystems.

5
1.4 Explain the Software Life Cycle Models:
The software life cycle is a general model of the software development process including
all the activities. There are various software development life cycles are there like:
a) Classical Waterfall model
b) Iterative Waterfall model
c) Prototyping model
d) Evolutionary model
e) Spiral model etc..

1.4.1 Waterfall Model:


Classical waterfall model is the basic software development life cycle model. It is very simple
but idealistic. Earlier this model was very popular but nowadays it is not used. But it is very
important because all the other software development life cycle models are based on the classical
waterfall model.
Classical waterfall model divides the life cycle into a set of phases. This model considers that
one phase can be started after completion of the previous phase. That is the output of one phase
will be the input to the next phase. Thus the development process can be considered as a
sequential flow in the waterfall. Here the phases do not overlap with each other. The different
sequential phases of the classical waterfall model are shown in the below figure:

Let us now learn about each of these phases in brief details:


1. Feasibility Study: The main goal of this phase is to determine whether it would be
financially and technically feasible to develop the software.
The feasibility study involves understanding the problem and then determine the various
6
possible strategies to solve the problem. These different identified solutions are analyzed
based on their benefits and drawbacks, The best solution is chosen and all the other phases
are carried out as per this solution strategy.
2. Requirements analysis and specification: The aim of the requirement analysis and
specification phase is to understand the exact requirements of the customer and document
them properly. This phase consists of two different activities.
 Requirement gathering and analysis: Firstly all the requirements regarding
the software are gathered from the customer and then the gathered requirements are
analyzed. The goal of the analysis part is to remove incompleteness (an incomplete
requirement is one in which some parts of the actual requirements have been omitted)
and inconsistencies (inconsistent requirement is one in which some part of the
requirement contradicts with some other part).
 Requirement specification: These analyzed requirements are documented in a
software requirement specification (SRS) document. SRS document serves as a contract
between development team and customers. Any future dispute between the customers
and the developers can be settled by examining the SRS document.
3. Design: The aim of the design phase is to transform the requirements specified in the
SRS document into a structure that is suitable for implementation in some programming
language.
4. Coding and Unit testing: In coding phase software design is translated into source
code using any suitable programming language. Thus each designed module is coded. The
aim of the unit testing phase is to check whether each module is working properly or not.
5. Integration and System testing: Integration of different modules are undertaken soon
after they have been coded and unit tested. Integration of various modules is carried out
incrementally over a number of steps. During each integration step, previously planned
modules are added to the partially integrated system and the resultant system is tested.
Finally, after all the modules have been successfully integrated and tested, the full working
system is obtained and system testing is carried out on this.
System testing consists three different kinds of testing activities as described below :

 Alpha testing: Alpha testing is the system testing performed by the


development team.
 Beta testing: Beta testing is the system testing performed by a friendly set of
customers.
 Acceptance testing: After the software has been delivered, the customer
performed the acceptance testing to determine whether to accept the delivered software
or to reject it.
6. Maintainence: Maintenance is the most important phase of a software life cycle. The
effort spent on maintenance is the 60% of the total effort spent to develop a full software.
There are basically three types of maintenance :
 Corrective Maintenance: This type of maintenance is carried out to correct
errors that were not discovered during the product development phase.
 Perfective Maintenance: This type of maintenance is carried out to enhance the
functionalities of the system based on the customer’s request.
 Adaptive Maintenance: Adaptive maintenance is usually required for porting
the software to work in a new environment such as work on a new computer platform
or with a new operating system.
7
Advantages of Classical Waterfall Model
Classical waterfall model is an idealistic model for software development. It is very simple, so
it can be considered as the basis for other software development life cycle models. Below are
some of the major advantages of this SDLC model:
 This model is very simple and is easy to understand.
 Phases in this model are processed one at a time.
 Each stage in the model is clearly defined.
 This model has very clear and well undestood milestones.
 Process, actions and results are very well documented.
 Reinforces good habits: define-before- design,
design-before-code.
 This model works well for smaller projects and projects where requirements are well
understood.
Drawbacks of Classical Waterfall Model
Classical waterfall model suffers from various shortcomings, basically we can’t use it in real
projects, but we use other software development lifecycle models which are based on the
classical waterfall model. Below are some major drawbacks of this model:
 No feedback path: In classical waterfall model evolution of a software from one phase
to another phase is like a waterfall. It assumes that no error is ever committed by
developers during any phases. Therefore, it does not incorporate any mechanism for error
correction.
 Difficult to accommodate change requests: This model assumes that all the customer
requirements can be completely and correctly defined at the beginning of the project, but
actually customers’ requirements keep on changing with time. It is difficult to
accommodate any change requests after the requirements specification phase is complete.
 No overlapping of phases: This model recommends that new phase can start only after
the completion of the previous phase. But in real projects, this can’t be maintained. To
increase the efficiency and reduce the cost, phases may overlap.

1.4.3 Iterative Waterfall Model:

In a practical software development project, the classical waterfall model is hard to use. So,
Iterative waterfall model can be thought of as incorporating the necessary changes to the
classical waterfall model to make it usable in practical software development projects. It is
almost same as the classical waterfall model except some changes are made to increase the
efficiency of the software development.
The iterative waterfall model provides feedback paths from every phase to its preceding
phases, which is the main difference from the classical waterfall model.
Feedback paths introduced by the iterative waterfall model are shown in the figure below.

8
When errors are detected at some later phase, these feedback paths allow correcting errors
committed by programmers during some phase. The feedback paths allow the phase to be
reworked in which errors are committed and these changes are reflected in the later phases.
But, there is no feedback path to the stage – feasibility study, because once a project has been
taken, does not give up the project easily.
It is good to detect errors in the same phase in which they are committed. It reduces the effort
and time required to correct the errors.
Phase Containment of Errors: The principle of detecting errors as close to their points of
commitment as possible is known as Phase containment of errors.
Advantages of Iterative Waterfall Model
 Feedback Path: In the classical waterfall model, there are no feedback paths, so there
is no mechanism for error correction. But in iterative waterfall model feedback path from
one phase to its preceding phase allows correcting the errors that are committed and these
changes are reflected in the later phases.
 Simple: Iterative waterfall model is very simple to understand and use. That’s why it is
one of the most widely used software development models.
Drawbacks of Iterative Waterfall Model
 Difficult to incorporate change requests: The major drawback of the iterative
waterfall model is that all the requirements must be clearly stated before starting of the
development phase. Customer may change requirements after some time but the iterative
waterfall model does not leave any scope to incorporate change requests that are made after
development phase starts.
 Incremental delivery not supported: In the iterative waterfall model, the full software
is completely developed and tested before delivery to the customer. There is no scope for
any intermediate delivery. So, customers have to wait long for getting the software.
 Overlapping of phases not supported: Iterative waterfall model assumes that one
phase can start after completion of the previous phase, But in real projects, phases may
overlap to reduce the effort and time needed to complete the project.
 Risk handling not supported: Projects may suffer from various types of risks. But,
Iterative waterfall model has no mechanism for risk handling.
 Limited customer interactions: Customer interaction occurs at the start of the project
at the time of requirement gathering and at project completion at the time of software
9
delivery. These fewer interactions with the customers may lead to many problems as the
finally developed software may differ from the customers’ actual requirements.

1.4.4 Prototyping Life Cycle Model:

Prototyping is defined as the process of developing a working replication of a product or system


that has to be engineered. It offers a small scale facsimile of the end product and is used for
obtaining customer feedback as described below:

The Prototyping Model is one of the most popularly used Software Development Life Cycle
Models (SDLC models).This model is used when the customers do not know the exact project
requirements beforehand. In this model, a prototype of the end product is first developed,
tested and refined as per customer feedback repeatedly till a final acceptable prototype is
achieved which forms the basis for developing the final product.
In this process model, the system is partially implemented before or during the analysis phase
thereby giving the customers an opportunity to see the product early in the life cycle. The
process starts by interviewing the customers and developing the incomplete high-level paper
model. This document is used to build the initial prototype supporting only the basic
functionality as desired by the customer. Once the customer figures out the problems, the
prototype is further refined to eliminate them. The process continues until the user approves
the prototype and finds the working model to be satisfactory.

There are four types of model available:

A) Rapid Throwaway Prototyping


B) Evolutionary Prototyping
C) Incremental Prototyping
D) Extreme Prototyping

10
1.4.5 The Spiral Model:

Spiral model is one of the most important Software Development Life Cycle models, which
provides support for Risk Handling. In its diagrammatic representation, it looks like a spiral
with many loops. The exact number of loops of the spiral is unknown and can vary from
project to project. Each loop of the spiral is called a Phase of the software development
process. The exact number of phases needed to develop the product can be varied by the
project manager depending upon the project risks. As the project manager dynamically
determines the number of phases, so the project manager has an important role to develop a
product using the spiral model.
The Radius of the spiral at any point represents the expenses(cost) of the project so far, and the
angular dimension represents the progress made so far in the current phase.
The below diagram shows the different phases of the Spiral Model: –

Each phase of the Spiral Model is divided into four quadrants as shown in the above figure.
The functions of these four quadrants are discussed below-

1. Objectives determination and identify alternative solutions: Requirements are


gathered from the customers and the objectives are identified, elaborated, and analyzed at
the start of every phase. Then alternative solutions possible for the phase are proposed in
this quadrant.

2. Identify and resolve Risks: During the second quadrant, all the possible solutions are
evaluated to select the best possible solution. Then the risks associated with that solution
are identified and the risks are resolved using the best possible strategy. At the end of this

11
quadrant, the Prototype is built for the best possible solution.

3. Develop next version of the Product: During the third quadrant, the identified features
are developed and verified through testing. At the end of the third quadrant, the next
version of the software is available.

4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate
the so far developed version of the software. In the end, planning for the next phase is
started.

Risk Handling in Spiral Model


A risk is any adverse situation that might affect the successful completion of a software
project. The most important feature of the spiral model is handling these unknown risks after
the project has started. Such risk resolutions are easier done by developing a prototype. The
spiral model supports coping up with risks by providing the scope to build a prototype at every
phase of the software development.
The Prototyping Model also supports risk handling, but the risks must be identified
completely before the start of the development work of the project. But in real life project risk
may occur after the development work starts, in that case, we cannot use the Prototyping
Model. In each phase of the Spiral Model, the features of the product dated and analyzed, and
the risks at that point in time are identified and are resolved through prototyping. Thus, this
model is much more flexible compared to other SDLC models.

Why Spiral Model is called Meta Model?


The Spiral model is called a Meta-Model because it subsumes all the other SDLC models. For
example, a single loop spiral actually represents the Iterative Waterfall Model . The spiral
model incorporates the stepwise approach of the Classical Waterfall Model . The spiral model
uses the approach of the Prototyping Model by building a prototype at the start of each phase
as a risk-handling technique. Also, the spiral model can be considered as supporting the
evolutionary model – the iterations along the spiral can be considered as evolutionary levels
through which the complete system is built.

Advantages of Spiral Model:


Below are some advantages of the Spiral Model.

1. Risk Handling: The projects with many unknown risks that occur as the development
proceeds, in that case, Spiral Model is the best development model to follow due to the risk
analysis and risk handling at every phase.

2. Good for large projects: It is recommended to use the Spiral Model in large and
complex projects.

3. Flexibility in Requirements: Change requests in the Requirements at later phase can


be incorporated accurately by using this model.

4. Customer Satisfaction: Customer can see the development of the product at the early
phase of the software development and thus, they habituated with the system by using it
before completion of the total product.

12
Disadvantages of Spiral Model:
Below are some main disadvantages of the spiral model.

1. Complex: The Spiral Model is much more complex than other SDLC models.

2. Expensive: Spiral Model is not suitable for small projects as it is expensive.

3. Too much dependability on Risk Analysis: The successful completion of the project
is very much dependent on Risk Analysis. Without very highly experienced experts, it is
going to be a failure to develop a project using this model.

4. Difficulty in time management: As the number of phases is unknown at the start of


the project, so time estimation is very difficult.

1.4.6 Comparison of different life cycles:

Classical Waterfall Model: The Classical Waterfall model can be considered as the basic
model and all other life cycle models are based on this model. It is an ideal model. However,
the Classical Waterfall model cannot be used in practical project development, since this model
does not support any mechanism to correct the errors that are committed during any of the
phases but detected at a later phase. This problem is overcome by the Iterative Waterfall model
through the inclusion of feedback paths.

Iterative Waterfall Model: The Iterative Waterfall model is probably the most used software
development model. This model is simple to use and understand. But this model is suitable
only for well-understood problems and is not suitable for the development of very large
projects and projects that suffer from a large number of risks.

Prototyping Model: The Prototyping model is suitable for projects, which either the customer
requirements or the technical solutions are not well understood. This risks must be identified
before the project starts. This model is especially popular for the development of the user
interface part of the project.

Evolutionary Model: The Evolutionary model is suitable for large projects which can be
decomposed into a set of modules for incremental development and delivery. This model is
widely used in object-oriented development projects. This model is only used if incremental
delivery of the system is acceptable to the customer.

Spiral Model: The Spiral model is considered as a meta-model as it includes all other life
cycle models. Flexibility and risk handling are the main characteristics of this model. The
spiral model is suitable for the development of technically challenging and large software that
is prone to various risks that are difficult to anticipate at the start of the project. But this model
is more complex than the other models.

------ 0 --------

13

You might also like