0% found this document useful (0 votes)
22 views

SE-1

This document provides an overview of software engineering, including its definitions, evolution, and the necessity for structured approaches in software development. It discusses the software life cycle models, particularly the classical waterfall model, and outlines the phases involved in software development from feasibility study to maintenance. Additionally, it highlights the differences between programs and software products, emphasizing the importance of systematic design and documentation in software engineering.

Uploaded by

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

SE-1

This document provides an overview of software engineering, including its definitions, evolution, and the necessity for structured approaches in software development. It discusses the software life cycle models, particularly the classical waterfall model, and outlines the phases involved in software development from feasibility study to maintenance. Additionally, it highlights the differences between programs and software products, emphasizing the importance of systematic design and documentation in software engineering.

Uploaded by

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

UNIT-1

UNDERSTAND THE BASICS OF SOFTWARE ENGINEERING DESIGNS & LIFE CYCLE MODELS

1.0 Understand The Basics Of Software Engineering Designs & Life Cycle Models
Reasons For Development Of Software Engineering:
 Computers are commercially being used for over the past sixty years.
 In the early days computers were very slow and lacked sophistication.
 The computational power and sophistication of computers have increased ever since, while
their prices have dropped dramatically.
 The improvements to their speed and reductions to their cost were brought about by several
technological breakthroughs that occurred at regular intervals.
 Therefore every increase in capabilities of computers, software engineers have been called
upon to solve larger and more complex problems and that too in cost-effective and efficient
ways.
 Software engineers have admirably coped with this challenge by innovating and by building
upon their past programming experience.
 All these innovations and experiences have given rise to the discipline of software
engineering.
Software Engineering: The term is made of two words, software and engineering
Software: It is more than just a program code. A program is an executable code, which serves
some computational purpose. Software is considered to be collection of executable programming
code, associated libraries and documentations.
Engineering: It is all about developing product, using well-define scientific principles and methods.
Definition Of Software Engineering:
 Definition Proposed By Fritz Bauer: Software engineering is the establishment and use of sound
engineering principles in order to obtain economically software that is reliable and work
efficient on real machines.
 Definition Proposed By IEEE: Software engineering is the application of a systematic, disciplined
quantifiable approach to the development operation, and maintenance of software, that is the
application of engineering to software.
Need Of Software Engineering:
 Large Software: it is easier to build a wall for building the size of the software becomes large
and large.
 Scalability: it would be easier to re-create new software than to scale an existing one.
 Cost: cost of hardware comes down due to high manufacturing but, cost of software remains
high if proper process is not adapted.
 Quality Management: better process of software development provides better and quality
software product.
Applications Of Software Engineering:
1. System software 5. Education
2. Communication networks 6. Application software
3. Computer graphics 7. Embedded systems
4. E-commerce
Life cycle models of software (or) software development life cycle:
Life cycle model: A life cycle model prescribes the different activities that need to be carried out to
develop a software product and the sequencing of these activities.
Software Life Cycle Model: The software life cycle model can be considered as business
process for software development, and therefore a software life cycle is also often referred
to as a software process.
1.1 Know The Evolution And Impact Of The Software Engineering
1.1.1 Evolution Of An Art To An Engineering Discipline
Evolution Of An Art To An Engineering Discipline:
 Software Engineering principles have evolved over the last 60 years.
 The early programmers used build and fix programming style.
 In build and fix style, normally poor quality program is quickly developed with any plan or design.
 We can consider build and fix style as an art-science it is guided by intuition.
 Programmers in modern software industry develop software by applying some well understood
software engineering principles.
The Evolution Of Software May Be Characterized By Four Era’s:
1. The Early Years(1950 To Mid 1960):
 Batch orientation –simple, task-oriented programs.
 Custom software -written “in-house”.
 Limited distribution -maintained “in-house”.
2. The Second Era(Mid-60’s-Late 70’s):
 Multiuser -VMS,UNIX
 Real time -Increased speed.
 Database -Increased storage capacity.
 Product software - wide spread distribution.
3. The Third Era(Mid-70’s-Mid-80’s):
 Distribution systems –local and global networking.
 Embedded intelligence and low cost hardware.
 Consumer impact-the personal computer.
4. The Fourth Era (Mid-80‘S-Present):
 Powerful desktop systems, client-server architecture.
 Object-oriented technologies.
 Artificial neural networks.
 Parallel computing.

 We can analyse the evolution of software development styles over the last fifty years.
 We can easily notice that it has evolved from a mysterious art from to a craft from, and then
has slowly emerged as an engineering discipline.
 In early days programmers know certain principles that they don’t share with other
programmers.
 Over the years all such good principles along with research have been organized into a form of
knowledge that forms the discipline of S.E.
1.1.2 A Solution To The Software Crisis?
Problems to the software crisis:
 Software crisis is raised due to the following problems
 Projects running over budget.
 Projects running over time.
 Software is in-efficient.
 Software is of low quality.
 Software does not meet requirements.
 Increase skill shortage.
Solution to the software crisis
 The use of high level languages
 The implementation of time sharing to improve the productivity.
 Use wide spread software engineering practice among the engineers for software
development.
 Adopt further advancements in the software engineering discipline
 Application of software engineering practices would significantly minimize the software
costs.

1.2 Know the difference between Programs and Software Products

SNO PROGRAMS SOFTWARE PRODUCTS


1. Programs are developed by Software products have multiple users
individuals for their personal use.
2. Programs are small in size Software products are large in size
3. It does not have good user Interface It does have good user Interface
4 Programs have limited functionality. Software products have unlimited Functionality.
5 Programs have no documentation. Software products have good documentation.
6 Program is set of instructions which Software consists of bundles of programs
are coded in a programming And data files.
language like C, C++,PHP,JAVA ,etc
7 Source code in a program is written Source code in a software products is
for small jobs. written for large jobs.

8. Given number is even or odd , Microsoft word, VLC media player, Firefox,
Prime or not, palindrome or not Windows, Linux, Unix are few examples
are few examples for programs. for system products.
9 Programs are not systematically Software products are Systematically
designed. designed.
10 Software development life cycle SDLC is used to develop every Software.
Is not used to make programs.
1.3 Understand The Evolution Of Software Engineering Design
Evolution Of Software Engineering Design (Or) Emergence Of Software Engineering:
 Software engineering has evolved over many years in the past .This evolution is the result of a
series of writing good programs.
 Let us examine a few of these programming experiences which have contributed to the
development of the software engineering discipline.
1.3.1 Early computer programming:
 Early commercial computers were very slow and too elementary as compared to today’s
standard.
 Even simple processing tasks took considerable computation time on those computers.
 These simple programs were usually written in assembly languages.
 Programs lengths were typically limited to a few hundred lines of assembly code.
 Programmers wrote programs without any proper strategy plan or design.
 We can designate this style of programming as built and fix.
1.3.2 High Level Language Programming:
 Computers became faster with the introduction of the semi-conductor technology in the early
60’s.
 Faster semiconductor transistors replaced the vacuum tubes in a computer.
 With the availability of more powerful computers, it became possible to solve larger and more
complex problems.
 At this time, high-level languages such as FORTRAN, ALGOL and COBOL were introduced.
 High level language programs were limited to around a few thousands of lines of source code.
 High level language provides more user friendly interface.
1.3.3 Control-flow-based design:
 As the size and complexity of programs are increasing, the build and fix style proved to be in
sufficient.
 To solve the problem experienced programmers advised other programmers to pay particular
attention to the design of a programs control flow structure.
 A programs control flow structure indicates the sequence in which the programs instructions are
executed.
 In order to help develop programs having good control flow, the flow charting technique was
developed.
A logical extension: Structured programming:
 It was proven by BOHM and JACOPINI that only three programming constructs: sequence, selection
and iteration here sufficient to express any programming login.
 Gradually everyone accepted that it Is actually possible to solve Any programming problem
without using GOTO statement.
 It discriminate use of GOTO statement should be avoided.
 This formed the basis for the structured programming methodology.
 A program is called structured hen it uses only the sequence, selection and iteration type of
construct.
 Very soon several programming languages such as PASCAL, MODULE, C etc; become available
which support structured programming?
1.3.4 Data structure oriented design:
 Computers become more powerful with the introduction of integrated circuits (ICs) in the
early seventies.
 These could now be used to solve more complex problems.
 Software engineers were developed large software products with several thousands of lines of
source code.
 The control flow –based program development techniques could not be satisfactory to write
more programs.
 It was soon discovered data structures to design program than that of its control structure.
 An example of data structure oriented design technique is the JSP (Jackson’s Structured
Programming) developed by Michael Jackson in 1975.

1.3.5 Data flow oriented design:


 Computers became still faster and more powerful with the introduction of very large scale
integrated (VLSI) circuits.
 Software engineers looked out for more effective techniques for designing software products
and soon data flow-oriented techniques were proposed.
 The data flow-oriented techniques advocate that the major data items handled by a system
must first be identified and then the processing required on these data items to produce the
desired outputs should be determined.
 The functions and the data items that are exchanged between the difference functions are
represented in a diagram known as Data Flow Diagram(DFD)

1.3.6 Object-oriented design


 The data flow oriented techniques evolved into object-oriented design (OOD) technique.
 Object-oriented designed is an naturally approach where the natural objects relevant to a
problem are first identified and then the relationship among the objects such as inheritance,
references are determined.
 Object-oriented design is used in natural objects such as employees, pay-roll – register, etc.
 Each object acts as a data hiding entity. object oriented techniques have gained wide spread
acceptance.
 Object oriented techniques are simplicity, scope of code and design reuse, promise of lower
development time, lower development cost, more robust code, easier maintenance.
1.3.7 Other developments:
 In addition to the advancements made to the software design techniques, several other new
concepts and techniques for effective software development were introduced.
 These new techniques include life cycle models, specifications techniques, project
management techniques, testing techniques, debugging techniques, quality assurance
techniques, software measurement techniques etc.
 The development of these techniques accelerated the growth of software engineering as a
discipline.

1.4 Explain The Software Life Cycle Models


Software life cycle models: The software life cycle model is also sometimes referred to as the
system development life cycle (SDLC).
Life cycle model: A life cycle model prescribes the different activities that need to be carried out to
develop a software product and the sequencing of these activities
Software life cycle:
 A software life cycle is a series of identifiable stages that a software product undergoes during
its lifetime.
 The software life cycle can be considered as business process for software development and
therefore. A software life cycle is also often referred to as a software process.
 The first stage in the life cycle of any software product is usually the feasibility study stage. The
sub sequent stages are requirement analysis, design, coding, testing and maintenance. Each of
this stages is called a life cycle phases.
Why use a life cycle model:
Software Development organization have realized that strictly follow to a suitable well-
defined life cycle model helps to produce good quality products and that too without time and
cost over runs.
Why document a life cycle model:
Good software organizations normally document all the information regarding the outputs
to be adopted etc. into a frame work called the organization software development model. The
organizations expect the fresh engineers recruited to first master the organizations software
development model.
1.4.1 Classical waterfall model
Classical waterfall model:
 All Life cycle models are in some way or other based on the Classical Waterfall Model.
 We need to first understand the classical waterfall model well, to be able to appreciate and
develop proper understanding of other life cycle models.
 The classical waterfall model divides the life cycle into the phases as shown in figure. The
diagrammatic representation of this model resembles a cascade of waterfalls.
PHASES OF CLASSICAL WATERFALL MODEL:
 The waterfall model breaks down the life cycle into set of phases.
 The different phases of this model are feasibility study, requirements analysis and specification,
design, coding and unit testing, integration and system testing and maintenance are shown in
below figure.

FIG: PHASES OF CLASSICAL WATERFALL MODEL

 The phase’s feasibility study to the integration and system testing phase are known as
development phases.
 The maintenance phase commences after completion of the development phase.
 An activity that spans all phases of any software development is project management.
 The amount of effort necessary for completing the activities of different phases for a typical
product is shown in figure.

 On the average about 60% of the total life cycle effort is spent on the maintenance activities
alone.
1) Feasibility Study:
 The main aim of the feasibility study activity is to determine whether it would be financially and
technically feasible to develop the product.
 The feasibility study activity involves analysis of the problem and collect of all relevant
information relating to the product.
 The collected data are analyzed to arrive at the following
a) An abstract problem specification: only important requirements of the customer are captured
details of the requirements are ignored.
b) Formulation of the different strategies or solving a problem: All different ways in which the
problem can be solved is identified.
c) Evaluation of different solution strategies: The different solution strategies are analyzed to
examine their benefits and short comings
2) Requirements Analysis And Specification:
The aim of this phase is to understand the exact requirements of the customer and to
document them properly.
a) Requirements gathering and analysis:
 The goal of requirement gathering is to collect all relevant information regarding the product
to be developed from customer with a view to clearly understand the customer
requirements.
 The goal of requirement analysis is to viewed out the incompleteness and inconsistencies in
the requirements.
b) Requirements specification:
The customer requirements identified during the requirements gathering and analysis activity
are organized in to a Software Requirements specification (SRS) document.
 SRS document contains three contents like functional requirements, Non-functional
requirements and goals of implementation.
 The SRS document is written using end user terminology
 SRS is understandable by customer.
 SRS is reviewed and approved by customer.
3) Design:
The goal of the design phase is to transform the requirements specified in the SRS into
a structure that is suitable for implementation in some programming language. Two design
approaches are
(a)Traditional Design approach: Traditional Design approach consists of structured analysis and
structured design activities.
(b) Object oriented design approach: In this technique various objects that occur in problem
domain and solution domain are first identified and relations that exist among these objects are
indentified.

4) Coding And Unit Testing:


 The coding phase is also sometimes called the implementation phase since design is
implemented into a workable solution. Each component of the design is implemented as a
program module.
 After coding is complete, each module is unit tested. Unit testing involves testing each module
in isolation from other modules, then debugging and documenting it.
5) Integration And Testing:
 Integration of different modules is undertaken once they have been coded and unit tested.
 Integration of various modules are normally carried out incrementally over a number of steps.
 Finally after all modules are integrated and tested, system testing is carried out. it ensure that the
development system conforms to its requirements laid out in the SRS document.
System testing contains 3 types of testing activities:
 Alpha testing: it is system testing performed by the development team.
 Beeta testing: it is a system testing performed by a friendly set of customers.
 Acceptance testing: it is a system testing performed by the customer himself after product
delivery to determine whether to accept the delivered products or to reject it.
6) Maintenence:
Maintenance involves performing any one or more of the following three kinds of activities.
 Corrective Maintenance: this type of maintenance involves correcting errors that were not
discovered during the period development phase.
 Perfective Maintenance: this type of maintenance involves enhancing the functionalities of the
system according to the customer’s requirements.
 Adaptive Maintenance: this type of maintenance usually required for the porting the software
to work in new environment such as new computer platform or with new operating system.
Shortcomings Of The Classical Waterfall Model:
1. The classical waterfall model is an idealistic one since it assumes that no error is ever committed
by the engineer during any of the life cycle phases, and therefore leaves no scope for error
correction.
2. This model assumes that all requirements are defined correctly at the beginning of the project in
real projects customers keep on changing requirements as the development proceeds.
3. Classical Waterfall model assumes that all phases are sequential. However that is rarely the case.

1.4.2 Iterative Water Fall Model


Iterative Waterfall Model:
 In practical software development work, it is not possible to strictly follow the classical
waterfall model. We branched the classical water fall model as an idealistic model.
 We can view the iterative water fall model so that it becomes applicable to practical software
development projects.
 The main change to the classical waterfall model is in the form of providing feedback paths
form every phase to its preceding phase.
 The feedback path allows for correction of the errors committed during phase as and when
these are detected in a later phase.
 This means that the feasibility study error cannot be corrected.
Phase Containment Of Error:
 Errors are expected in almost every phase of development, it is desirable to detect these errors
in the same phase in which they occur.
 This can reduce the effort required for correcting bugs.
 EXAMPLE: if a design problem is defected in the design phase itself , this problem can be taken
care of much more easily than if the error is identified at the end of system testing phase.
 “The principle of detecting errors as close to their point of introduction as possible is known
as phase containment of errors.” This is an important software engineering principle

How can phase containment of errors be achieved:


 An important technique that is frequently used this regard is to conduct review after every
milestone.
 In spite of best effort to detect errors in the same phase still some errors can escape detection
and would be detected in later phase.
 It includes the rework required to the phase later due to errors of that phase detected at the
later phases. This makes different life cycle phases overlap in time
 Another reason for phase overlap is that once a developer completes his assigned work for a
phase, he proceeds with his activities in the subsequent phases rather than idling till the other
developers complete the assigned phase

Short comings:
 The water fall model cannot satisfactorily handle the different types of risks that a real life
software project may suffer from.
 To achieve better efficiency and high productivity, most real life projects find it difficult to
follow the strict phase sequence of waterfall model.
1.4.3 Prototyping Model
Prototyping Model:
 The Prototyping Model requires that before carrying out the development of the actual software,
a working prototype of the system should be built.
 A prototype is usually built using several shortcuts.
 The shortcuts might involve using inefficient, in accurate or dummy functions.
 For many projects, there are several advantages of building a prototype before the actual product
is developed.
 An important use of a prototype can be to illustrate the input data formats, messages, reports,
interactive dialogues to the customer.
 Another important situation where the prototyping model can be useful where the exact
technical solutions to be adopted are unclear to the development team.
 It is impossible to get it right the first time and one must plan to throw away the first product in
order to develop a good product later.

 The first phase is prototype development followed by an iterative development cycle.


 In this model, prototyping starts with an initial requirements gathering phase. A quick design is
carried out and a prototype is built.
 The developed prototype is submitted to the customer for his evaluation. Based on the customer
feedback the requirements are refined and the prototype is modified.
 In spite of availability of working prototype, with SRS document is required to be developed for
traceability analysis, verification.
 The code for prototype is usually thrown away, even though the concentration of a working
prototype might involve additional cost. The overall development cost might turn out to be low in
prototype model.
 By constructing the prototype many customers’ requirements get properly defined. This minimizes
the change requests from the customer and the associated redesign cost.

1.4.4 Evolutionary Model


Evolutionary Model:
 The Life Cycle Model Is also referred to as the successive versions model and sometimes as the
incremental model.
 The evolutionary model is a very natural model used in object oriented software development
projects.
 In this life cycle model, first a sample working system is built, which is subsequently undergoes
many functionality improvements and additions until the desired system is required.
 The evolutionary software development process is sometimes referred to a design a little, built a
little, test a little, and deploy a little model.
Life Cycle Activites:
 In evolutionary life cycle model, the software requirements are first broken down
into several modules (or) units that can be incrementally constructed and delivered.

 The development team first develops the core modules of the system. The core modules that do
not need services from the other modules.
 In the other hand non-core modules need services from other modules.
 the initial product skeleton is refined into increasing levels of Capability by adding new
functionalities in successive versions
 Each evolutionary version may be developed using iterative waterfall model
 The evolutionary model is shown in below figure. each successive version is fully functioning
software capable of performing more work than the previous versions
Advantages:
 In this Model, the users’ gets chance to experiment with partially developed software much
before the complete the version of system is released.
 The Evolutionary model helps to accurately extract user requirements during the delivery of
different versions of the software.
Disadvantages:
 The problems of the successive versions model are that for most practical problems it is difficult
to divide the problem into several versions.
Types of projects for which suitable:
 The Evolutionary model is normally useful for very large products.
 It is used when the customer prefers to receive the product in increments.
 It is used in Object-Oriented software development projects.
1.4.5 Spiral Model
Spiral Model:
 The spiral model of software development is shown in below figure

 The diagrammatic representation of this model appears like a spiral with many loops.
 The exact number of loops of the spiral is not fixed and can vary from product to product.
 Each loop of spiral is called a phase of the software process.
 Over each loop one or more features of the product are elaborated and the analysed and the risk
at that point of time are identified. And are resolved through prototyping, on this based features
are implemented.

Risk handling in spiral model:


 A risk in any adverse circumstance that might block the successful completion of the project.
 Example the risk involved in accessing data from remote database .the risk can be resolved
by building a prototype of data access subsystem and experimenting with the exact access
rate.
Phase of spiral model:
 Each phase in this model is split in to four sectors (or) quadrants.
 In the first quadrant, some features of the product are identified based on the severity of the risk
and how crucial it is to the overall product development. Also alternative solutions possible are
proposed.
 Second quadrant, the alternative solutions are evaluated to select the best possible solution.
 Activities during the third quadrant consist of developing and verifying the next level of the
product.
 Activities during fourth quadrant concern reviewing the results of the stages traversed so far the
customer and planning the next iteration around the spiral.
Pros and cons of spiral model: they are few disadvantages with spiral model.
1. The spiral model usually appears as a complex model to follow.
2. It requires knowledgeable staff.
3. It is not suitable for development of outsourced projects.
Spiral model as a meta model:
 The spiral model can be viewed as a meta model, since it subsume all the discussed models.
 This enables the developers to understand and resolve the risks at each evolutionary
level(iteration along with spiral)
 The spiral model uses prototyping as a risk reduction mechanism and also retains the step wise
approach of the waterfall model.

1.4.6 Comparison of Different Life Cycle Models


Classica
l Iterative Prototy Evolutio
Spiral
SNO FEATURE water waterfall ping nary
model
fall model model model
model
Requirements Frequently
1 Beginning Beginning Beginning Beginning
specification changed
2 Cost Low Low High High Expensive
3 Simplicity simple Simple Simple Intermediate Intermediate
Expertise
4 high high Medium Little High
required
5 Flexibility More flexible More flexible High flexible High flexible Flexible
Risk
6 high high Low Low Low
involvement
Client
7 At beginning At beginning Frequently Frequently Sometimes
interaction
8 Success ratio Low Low High High High
9 Time required Few time Few time More time More time More time
10 Reusability limited Yes Weak Weak High
Simple & easy Better model for It is easy to Good for large
11 advantages It is best model
to understand all implement projects
Doesn’t work
Poor for long No clear mile It is time It is time
12 disadvantages well for smaller
projects stones consuming consuming
projects

You might also like