0% found this document useful (0 votes)
46 views33 pages

20cs4103 Se Unit 1

The document discusses the 20CS4103 - Software Engineering course. It provides the objectives and outcomes of the course which include comparing different process models, concepts of requirements engineering and analysis modeling, applying procedures for software design and deployment, and comparing testing and maintenance approaches. The first unit covers the nature of software, software engineering practices, software myths, and sequential, prototyping, RAD, evolutionary, incremental, spiral and agile development models. Key principles of software engineering like modularity, abstraction and encapsulation are also summarized.

Uploaded by

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

20cs4103 Se Unit 1

The document discusses the 20CS4103 - Software Engineering course. It provides the objectives and outcomes of the course which include comparing different process models, concepts of requirements engineering and analysis modeling, applying procedures for software design and deployment, and comparing testing and maintenance approaches. The first unit covers the nature of software, software engineering practices, software myths, and sequential, prototyping, RAD, evolutionary, incremental, spiral and agile development models. Key principles of software engineering like modularity, abstraction and encapsulation are also summarized.

Uploaded by

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

20CS4103 - SOFTWARE ENGINEERING

OBJECTIVES
To provide the idea of decomposing the given problem into Analysis, Design, Implementation,
Testing and Maintenance phases.

COURSE OUTCOMES

Students will be able to

1. Compare different process models.

2. Concepts of requirements engineering and Analysis Modeling.

3. Apply systematic procedure for software design and deployment.

4. Compare and contrast the various testing and maintenance.


5. Manage project schedule, estimate project cost and effort required
UNIT 1 – SOFTWARE PROCESS AND DEVELOPMENT METHODOLOGY

The Nature of Software - Software Engineering Practice - Software Myths –Sequential Model - Prototyping

Model - RAD Model - Evolutionary Software Process Models - Incremental model - Spiral model, Agile

Development – Extreme Programming(XP) – Scrum

Total Periods :9
Software Engineering :
• Software engineering deals with the design, development, testing, and maintenance
of software applications.
• Software engineers apply engineering principles and knowledge of programming
languages to build software solutions for end users.

Software engineering are driven by new technologies in


• automobiles,
• Aviation (aircraft),
• data management,
• telecommunications,
• factory control,
• robotics,
• defense,
• and security.
• Software engineers may develop computer games, business applications, operating systems,
network control systems
Key Principles of Software Engineering

1.Modularity: Breaking the software into smaller, reusable components that can be developed and
tested independently.
2.Abstraction: Hiding the implementation details of a component and exposing only the necessary
functionality to other parts of the software.
3.Encapsulation: Wrapping up the data and functions of an object into a single unit, and protecting
the internal state of an object from external modifications.
4.Reusability: Creating components that can be used in multiple projects, which can save time and
resources.
5.Maintenance: Regularly updating and improving the software to fix bugs, add new features, and
address security vulnerabilities.
6.Testing: Verifying that the software meets its requirements and is free of bugs.
7.Design Patterns: Solving recurring problems in software design by providing templates for
solving them.
Nature of Software

Software refers to a program that makes the computer to do something meaningful. It is the
planned, step by step instructions required to turn data into information.

Nature of software: Software is a logical entity rather than a physical system entity. Software
characteristics are quite different from that of hardware.

Software is:
(1) instructions (computer programs) that when executed to provide desired features, function,
and performance,
(2) data structures that enable the programs to adequately manipulate information and ,
(3) documentation that describes the operation and use of the programs.
Types of software

i)System Software
Predefined software
e.g notepad, paint,recycle bin.

ii)Utility Software
Supporting software
e.g Wifi adapter

iii) Application Software


Based on the need of user it can be installed
e.g Zoom ,teams photoshop.
Characteristics of software

1.Reliability: The ability of the software to consistently perform its intended tasks without
unexpected failures or errors.
2.Usability: How easily and effectively users can interact with and navigate through the software.
3.Efficiency: The optimal utilization of system resources to perform tasks on time.
4.Maintainability: How easily and cost-effectively software can be modified, updated, or extended.
5.Portability: The ability of software to run on different platforms or environments without requiring
significant modifications.
Software Engineering Practices
Software Engineering Practices are a set of approaches to software development.

To overcome the software development problems.


• Understand the problem (communication and analysis)
• Plan the solution ( Modeling and software design)
• Carry out the plan (code generation)
• Examine the result for accuracy (testing and quality assurance)
Software Myths

Myth 1: Computers are more reliable than the devices they have replaced.

Considering the reusability of the software, it can undoubtedly be said that the software does not fail.

Myth 2: Software is easy to change.


Yes, changes are easy to make – but hard to make without introducing errors. With every change
the entire system must be re-verified.

Myth 3: If software development gets behind scheduled, adding more programmers will put
the development back on track.
Software development is not a mechanistic process like manufacturing. In the words of Brooks:
“adding people to a late software project makes it later”.
(i) Management Myths:
Myth 1:
We have all the standards and procedures available for software development.
Fact:
•Software experts do not know all the requirements for the software development.
•And all existing processes are incomplete as new software development is based on new and
different problem.

Myth 2:
The addition of the latest hardware programs will improve the software development.
Fact:
• The role of the latest hardware is not very high on standard software development; instead
(CASE) Engineering tools help the computer, they are more important than hardware to produce
quality and productivity.
•Hence, the hardware resources are misused.
(ii)Customer Myths:
The customer can be the direct users of the software, the technical team, marketing / sales
department, or other company. Customer has myths leading to false expectations (customer) & that’s
why you create dissatisfaction with the developer.
Myth 1:
A general statement of intent is enough to start writing plans (software development) and details of
objectives can be done over time.
Fact:
• Official and detailed description of the database function, ethical performance, communication,
structural issues and the verification process are important.
• Unambiguous requirements (usually derived iteratively) are developed only through effective and
continuous communication between customer and developer.
Myth 2:

Software requirements continually change, but change can be easily accommodated because software is flexible
Fact:
• It is true that software requirements change, but the impact of change varies with the time at which it is
introduced. When requirements changes are requested early (before design or code has been started), the cost
impact is relatively small. However, as time passes, the cost impact grows rapidly—resources have been
committed, a design framework has been established, and change can cause upheaval that requires additional
resources and major design modification.
(iii)Practitioner’s Myths:
Myths 1:
They believe that their work has been completed with the writing of the plan.
Fact:
•It is true that every 60-80% effort goes into the maintenance phase (as of the latter software
release). Efforts are required, where the product is available first delivered to customers.
Myths 2:
There is no other way to achieve system quality, until it is “running”.
Fact:
• Systematic review of project technology is the quality of effective software verification method.
These updates are quality filters and more accessible than test.
Sequential Model or Waterfall Model

• The Waterfall Model is also referred to as a linear-sequential life cycle model.


• In a waterfall model, each phase must be completed before the next phase can begin and there is no
overlapping in the phases.
• The Waterfall model is the earliest SDLC (software development life cycle )approach that was used for
software development.

Waterfall Model – Design (Classical Life Cycle Model)

Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success
of the project. In "The Waterfall" approach, the whole process of software development is divided into
separate phases.
Requirement Gathering and analysis − All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification document.
• Basic requirements of system must understood by Software Engineer as analyst. Information
domain, function and behavioural requirements.

System Design − Based on requirement the system design is prepared. This system design
helps in specifying hardware and system requirements and helps in defining the overall system
architecture , data structure , interface representation , Algorithmic details.

Implementation − Design is translated into machine – readable form.


With inputs from the system design, the system is first developed in small programs called units,
which are integrated in the next phase
Integration and Testing − It begins when coding is done ,it mainly focuses on logical internals of
software. The testing ensures execution of all the path ,functional behaviour.
The purpose of testing is to uncover errors ,fix the bugs and meet the customer requirements.

Deployment of system − Once the functional and non-functional testing is done; the product is
deployed in the customer environment or released into the market.

Maintenance − It is the longest phase .There are some issues which come up in the client
environment. To fix those issues, patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the customer environment. It
enchance the system services as new requirements are discovered is again maintanence of the
system.
Waterfall Model – Application

Every software developed is different and requires a suitable SDLC approach to be followed based
on the internal and external factors. Some situations where the use of Waterfall model is most
appropriate are −

• Requirements are very well documented, clear and fixed.


• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
The project is short.
Advantages
Simple and easy to understand and use
Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review
process.
Phases are processed and completed one at a time.

Disadvantages
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.
Incremental Model

• Incremental Model is a process of software development where requirements divided into


multiple standalone modules of the software development cycle.
• In this model, each module goes through the requirements, design, implementation and
testing phases.
• It has some of phases similar to Waterfall model but it is iterative in nature.

1. Analysis
2. Design
3. Code
4. Test

Analysis Design Code Test Implementation


1. Requirement analysis: In the first phase of the incremental model, the product analysis expertise
identifies the requirements. And the system functional requirements are understood by the
requirement analysis team. To develop the software under the incremental model, this phase
performs a crucial role.
2. Design & Development: In this phase of the Incremental model of SDLC, the design of the
system functionality and the development method are finished with success. When software develops
new practicality, the incremental model uses style and development phase.
3. Testing: In the incremental model, the testing phase checks the performance of each existing
function as well as additional functionality. In the testing phase, the various methods are used to test
the behavior of each task.
4. Implementation: Implementation phase enables the coding phase of the development system. It
involves the final coding that design in the designing and development phase and tests the
functionality in the testing phase. After completion of this phase, the number of the product working is
enhanced and upgraded up to the final system product
Advantage of Incremental Model

• Errors are easy to be recognized.


• Easier to test and debug
• More flexible.
• Simple to manage risk because it handled during its iteration.
• The Client gets important functionality early.

Disadvantage of Incremental Model

• Need for good planning


• Total Cost is high.
• Well defined module interfaces are needed.
Evolutionary Software Process Models

Evolutionary Model

Prototyping Model Sprial Model

Prototyping Model is a software development model in which prototype is built, tested, and
reworked until an acceptable prototype is achieved. It also creates base to produce the final
system or software. It works best in scenarios where the project’s requirements are not known in
detail. It is an iterative, trial and error method which takes place between developer and client.
• Developer and customer define overall objective ;identify areas needing more requirement
gathering.
• Quick design is prepared, it represents which part will be visible to user in input and output.
• Customer or user evaluates the prototype in order to refine the requirements.

Steps of Prototype Model


• Requirement Gathering and Analyst
• Quick Decision
• Build a Prototype
• Assessment or User Evaluation
• Prototype Refinement
• Engineer Product

Communication with
Building of quick design
customer

Deployment delivery Construction of


and feedback prototype
Advantage of Prototype Model

• Reduce the risk of incorrect user requirement


• Good where requirement are changing/uncommitted
• Regular visible process aids management
• Support early product marketing
• Reduce Maintenance cost.

Disadvantage of Prototype Model

• An unstable/badly implemented prototype often becomes the final product.


• Require extensive customer collaboration
• Costs customer money
• Needs committed customer
• Difficult to know how long the project will last.
• Easy to fall back into the code and fix without proper requirement analysis, design,
customer evaluation, and feedback.
• Prototyping tools are expensive.
The RAD (Rapid Application Development) model is based on prototyping and iterative
development with no specific planning involved. The process of writing the software itself involves
the planning required for developing the product.

RAD is a linear sequential software development process model that emphasizes a concise
development cycle using an element based construction approach.

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 refers design improvements to the next product version
Less formality in reviews and other team communication
The various phases of RAD are as follows:
1.Business Modelling: The information flow among business functions is defined by answering questions
like what data drives the business process, what data is generated, who generates it, where does the
information go, who process it and so on.
2. Data Modelling: The data collected from business modeling is refined into a set of data objects
(entities) that are needed to support the business. The attributes (character of each entity) are identified,
and the relation between these data objects (entities) is defined.
3. Process Modelling: The information object defined in the data modeling phase are transformed to
achieve the data flow necessary to implement a business function. Processing descriptions are created for
adding, modifying, deleting, or retrieving a data object.
4. Application Generation: Automated tools are used to facilitate construction of the software; even they
use the 4th GL techniques.
5. Testing & Turnover: Many of the programming components have already been tested since RAD
emphasis reuse. This reduces the overall testing time. But the new part must be tested, and all interfaces
must be fully exercised.
Advantage of RAD Model

• This model is flexible for change.


• In this model, changes are adoptable.
• Each phase in RAD brings highest priority functionality to the customer.
• It reduced development time.
• It increases the reusability of features.

Disadvantage of RAD Model

• It required highly skilled designers.


• All application is not compatible with RAD.
• For smaller projects, we cannot use the RAD model.
• On the high technical risk, it's not suitable.
• Required user involvement.

You might also like