0% found this document useful (0 votes)
51 views21 pages

SE Module 1

Software engineering is the systematic study and approach to designing, developing, operating, and maintaining software systems. It involves designing software to serve a particular purpose and finding cost-effective solutions to problems. The nature of software engineering is always evolving as software needs to be updated over time for reasons such as changing requirements, security risks, and adding new features. Some key challenges for software engineers include developing system software, application software, engineering/scientific software, embedded software, product line software, web applications, and artificial intelligence software. Software engineering is a layered technology consisting of a quality focus, processes, methods, and tools.

Uploaded by

rohithlokesh2912
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)
51 views21 pages

SE Module 1

Software engineering is the systematic study and approach to designing, developing, operating, and maintaining software systems. It involves designing software to serve a particular purpose and finding cost-effective solutions to problems. The nature of software engineering is always evolving as software needs to be updated over time for reasons such as changing requirements, security risks, and adding new features. Some key challenges for software engineers include developing system software, application software, engineering/scientific software, embedded software, product line software, web applications, and artificial intelligence software. Software engineering is a layered technology consisting of a quality focus, processes, methods, and tools.

Uploaded by

rohithlokesh2912
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/ 21

Software Engineering

MVJ20CS33
Chapter 1
1. Introduction to software Engineering:
Software Engineering is a systematic, disciplined, quantifiable study and
approach to the design, development, operation, and maintenance of a software
system.

Software is a program or set of programs containing instructions that provide


desired functionality. And Engineering is the process of designing and
building something that serves a particular purpose and finds a cost-effective
solution to problems.

1.1 The evolving nature of software engineering:


Software Evolution is a term which refers to the process of developing
software initially, then timely updating it for various reasons, i.e., to add new
features or to remove obsolete functionalities etc.

The evolution process includes fundamental activities of change analysis,


release planning, system implementation and releasing a system to customers.

The necessity of Software evolution:


Software evaluation is necessary just because of the following reasons.

a) Change in requirement with time:

With the passes of time, the organization’s needs and modus Operandi of
working could substantially be changed so in this frequently changing time the
tools(software) that they are using need to change for maximizing the
performance.

b) Environment change:

As the working environment changes the things(tools) that enable us to work


in that environment also changes proportionally same happens in the software
world as the working environment changes then, the organizations need

Software engineering Page 1


reintroduction of old software with updated features and functionality to adapt
the new environment.

c) Errors and bugs:

As the age of the deployed software within an organization increases their


preciseness or impeccability decrease and the efficiency to bear the increasing
complexity workload also continually degrades. So, in that case, it becomes
necessary to avoid use of obsolete and aged software. All such obsolete
Software need to undergo the evolution process in order to become robust as
per the workload complexity of the current environment .

d) Security risks:

Using outdated software within an organization may lead you to at the verge
of various software-based cyber attacks and could expose your confidential
data illegally associated with the software that is in use. So, it becomes
necessary to avoid such security breaches through regular assessment of the
security patches/modules are used within the software. If the software isn’t
robust enough to bear the current occurring Cyber attacks so it must be
changed (updated).

e) For having new functionality and features:

In order to increase the performance and fast data processing and other
functionalities, an organization need to continuously evolute the software
throughout its life cycle so that stakeholders & clients of the product could
work efficiently.

1.2 Changing nature of software engineering:


The software is instruction or computer program that when executed provide
desired features, function, and performance.

A data structure that enables the program to adequately manipulate


information and document that describes the operation and use of the program .

Characteristic of software:
There is some characteristic of software which is given below:

1. Functionality
2. Reliability
3. Usability

Software engineering Page 2


4. Efficiency
5. Maintainability
6. Portability

Changing Nature of Software:

Nowadays, seven broad categories of computer software present continuing


challenges for software engineers which are given below:

1. System Software:

System software is a collection of programs which are written to service other


programs. Some system software processes complex but determinate,
information structures. Other system application process largely indeterminate
data. Sometimes when, the system software area is characterized by the heavy
interaction with computer hardware that requires scheduling, resource sharing,
and sophisticated process management.

2. Application Software:

Application software is defined as programs that solve a specific business


need. Application in this area process business or technical data in a way that
facilitates business operation or management technical decision making. In
addition to convention data processing application, application software is
used to control business function in real time.

3. Engineering and Scientific Software:

This software is used to facilitate the engineering function and task.


however modern application within the engineering and scientific area are
moving away from the conventional numerical algorithms. Computer-aided
design, system simulation, and other interactive applications have begun to
take a real-time and even system software characteristic .

4. Embedded Software:

Embedded software resides within the system or product and is used to


implement and control feature and function for the end-user and for the
system itself. Embedded software can perform the limited and esoteric
function or provided significant function and control capability.

5. Product-line Software:

Software engineering Page 3


Designed to provide a specific capability for use by many different
customers, product line software can focus on the limited and esoteric
marketplace or address the mass consumer market.

6. Web Application:

It is a client-server computer program which the client runs on the web


browser. In their simplest form, Web apps can be little more than a set of
linked hypertext files that present information using text and limited
graphics. However, as e-commerce and B2B application grow in
importance. Web apps are evolving into a sophisticate computing
environment that not only provides a standalone feature, computing
function, and content to the end user.

7. Artificial Intelligence Software:

Artificial intelligence software makes use of a non numerical algorithm to


solve a complex problem that is not amenable to computation or
straightforward analysis. Application within this area includes robotics,
expert system, pattern recognition, artificial neural network, theorem
proving and game playing.

1.3 Software engineering layers:


Software engineering is fully a layered technology, to develop software we
need to go from one layer to another. All the layers are connected and each
layer demands the fulfillment of the previous layer.
Layered technology is divided into four parts:
1 .A quality focus
2. Process
3. Method
4. Tools

Software engineering Page 4


1. A quality focus: It defines the continuous process improvement
principles of software. It provides integrity that means providing
security to the software so that data can be accessed by only an
authorized person, no outsider can access the data. It also focuses on
maintainability and usability.

2. Process: It is the foundation or base layer of software engineering. It is


key that binds all the layers together which enables the development of
software before the deadline or on time. Process defines a framework
that must be established for the effective delivery of software
engineering technology. The software process covers all the activities,
actions, and tasks required to be carried out for software development.

3. Method: During the process of software development the answers to all


“how-to-do” questions are given by method. It has the information of all
the tasks which includes communication, requirement analysis, design
modeling, program construction, testing, and support.

4. Tools: Software engineering tools provide a self-operating system for


processes and methods. Tools are integrated which means information
created by one tool can be used by another.

1.4 software myths:


Most, experienced experts have seen myths or superstitions (false beliefs or
interpretations) misleading attitudes (naked users) which creates
Major problems for management and technical people. The opposite Types of
software-related myths are listed below.

Software engineering Page 5


(i) Management Myths :
Myth 1:
We have all the standards and procedures available for software
development i.e. the software developer has all the reqd.
Fact:
 Software experts do not know that there are all of them levels.
 Such practices may or may not be expired at present / modern software
engineering methods.
 And all existing processes are incomplete.
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.
Myth 3:
Managers think that, with the addition of more people and program
planners to Software development can help meet project deadlines (If
lagging behind).
Fact:
 Software development is not, the process of doing things like production;
here the addition of people in previous stages can reduce the time it will be
used for productive development, as the newcomers would take time
existing developers of definitions and understanding of the file project.
However, planned additions are organized and organized It can help
complete the project.
(ii)Customer Myths :

Software engineering Page 6


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.
 It is happening that the complete communication between the customer and
the developer is required.
Myth 2 :
 Project requirements continue to change, but, change, can be easy location
due to the flexible nature of the software.
Fact :
 Changes were made to the final stages of software development but cost
to make those changes grow through the latest stages of
 Development. A detailed analysis of user needs should be done to
minimize change requirement. Figure shows the transition costs in
Respect of the categories of development.
(iii)Practitioner’s Myths :
Myths 1 :
They believe that their work has been completed with the writing of the
plan and they received it to work.
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, behind it done 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.
Myth 3:

Software engineering Page 7


An operating system is the only product that can be successfully
exported project.
Fact:
 A working system is not enough, it is just the right document brochures and
booklets are also reqd. To provide for guidance & software support.
Myth4 :
Engineering software will enable us to build powerful and unnecessary
document & always delay us.
Fact:
 Software engineering does not deal with text building, rather while creating
better quality leads to reduced recycling & this is being studied for rapid
product delivery.

Chapter 2
2.1 process models:
A software process model is an abstraction of the software development
process. The models specify the stages and order of a process. So, think of this
as a representation of the order of activities of the process and the sequence in
which they are performed.

The goal of a software process model is to provide guidance for controlling and
coordinating the tasks to achieve the end product and objectives as effectively
as possible.

A model will define the following:

 The tasks to be performed


 The input and output of each task
 The pre and post conditions for each task
 The flow and sequence of each task

Types of software process models

As we mentioned before, there are multiple kinds of software process


models that each meet different requirements. Below, we will look at the
top seven types of software process models that you should know.

Software engineering Page 8


2.1 A GENERIC PROCESS MODEL:

The Generic process model is an abstraction of the software development


process. It specifies the stages and order of a process

Generic Process Model will define the following:

Generic Process Framework Activities:


It establishes the foundation for a complete software process by identifying a
small number of framework activities.
It also includes a set of umbrella activities that are applicable across the entire
software process.
Each framework activity is populated by a set of software engineering actions.
A Generic Process Framework for Software Engineering encompasses five
activities.

1. Communication: This framework activity involves heavy communication


and collaboration with the customer. It encompasses requirements gathering and
other related activities.

2. Planning: This activity establishes a plan for the software engineering work
that follows. It describes the technical tasks which are conduct. The resource
requires and the work products are producing with a work schedule.

Software engineering Page 9


3. Modeling: It encompasses the creation of models that allow the developer
and the customer. It is easy to better understand Software requirements and the
design that will achieve those requirements.

4. Construction: This activity combines code generation and the testing that is
required to uncover errors in the code.

5. Deployment: The software delivered to the customer who evaluates the


delivered product. It also provides feedback based on the evaluation.

2.2 WATERFALL MODEL:

The Waterfall Model was the first Process Model to be introduced. It is also
referred to as a software life cycle model. It is very simple to understand and
use. 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 approach that was used for software
development.
The waterfall Model illustrates the software development process in a linear
sequential flow. This means that any phase in the development process begins
only if the previous phase is complete. In this waterfall model, the phases do
not overlap.
Waterfall Model – Design:
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. In this
Waterfall model, typically, the outcome of one phase acts as the input for the
next phase sequentially.
The following illustration is a representation of the different phases of the
Waterfall Mode.

The sequential phases in Waterfall model are −


 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.
 System Design − The requirement specifications from first phase are
studied in this phase and the system design is prepared. This system

Software engineering Page 10


design helps in specifying hardware and system requirements and helps
in defining the overall system architecture.
 Implementation − With inputs from the system design, 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,
which is referred to as Unit Testing.
 Integration and Testing − All the units developed in the
implementation phase are integrated into a system after testing of each
unit. Post integration the entire system is tested for any faults and
failures.
 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 − 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.

Software engineering Page 11


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.
Waterfall Model – Advantages:
Some of the major advantages of the Waterfall Model are as follows −
 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.
 Works well for smaller projects where requirements are very well
understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.
Waterfall Model – Disadvantages:
The major disadvantages of the Waterfall Model are as follows −
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high
risk of changing. So, risk and uncertainty is high with this process
model.
Software engineering Page 12
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.
 Integration is done as a "big-bang. at the very end, which doesn't allow
identifying any technological or business bottleneck or challenges early.
2.3 INCREMENTAL PROCESS MODELS:

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. Every subsequent release of the module adds function to the
previous release. The process continues until the complete system achieved.

The various phases of incremental model are as follows:

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.
Software engineering Page 13
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.Java Try Catch

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

Types of incremental model:


1. Staged delivery model: construction of only one part of the project at a
time.
2. Parallel development model: different subsystems are developed at the
same time

Advantage of Incremental Model


o Errors are easy to be recognized.
o Easier to test and debug
o More flexible.
o Simple to manage risk because it handled during its iteration.
o The Client gets important functionality early.

Disadvantage of Incremental Model


o Need for good planning
o Total Cost is high.
o Well defined module interfaces are needed.

2.4 EVOLUTIONARY PROCESS MODELS:

Evolutionary model is also referred to as the successive versions


model and sometimes as the incremental model.
In Evolutionary model, the software requirement is first broken down into
several modules (or functional units) that can be incrementally
constructed and delivered
The development first develops the core modules of the system. The core
modules are those that do not need services from the other modules.
The initial product skeleton is refined into increasing levels of capability
by adding new functionalities in successive versions.

Software engineering Page 14


Each evolutionary model may be developed using an iterative waterfall
model of development.

Evolutionary model is used when the customer prefers to receive the product in
increments so that he can start using the different features as and when they are
developed rather than waiting all the time for the full product to be developed
and delivered.
Advantages of Evolutionary Model
 Large project: Evolutionary model is normally useful for very large products.

 User gets a chance to experiment with a partially developed software much


before the complete version of the system is released.

 Evolutionary model helps to accurately elicit user requirements during the


delivery of different versions of the software.

 The core modules get tested thoroughly, thereby reducing the chances of
errors in the core modules of the final products.

 Evolutionary model avoids the need to commit large resources in one go for
development of the system.

Disadvantages of Evolutionary Model


 Difficult to divide the problem into several versions that would be acceptable
to the customer and which can be incrementally implemented and delivered.
Software engineering Page 15
2.5 SPIRAL MODEL:

The spiral model combines the idea of iterative development with the
systematic, controlled aspects of the waterfall model. This Spiral model is a
combination of iterative development process model and sequential linear
development model i.e. the waterfall model with a very high emphasis on risk
analysis. It allows incremental releases of the product or incremental
refinement through each iteration around the spiral.
Spiral Model - Design
The spiral model has four phases. A software project repeatedly passes through
these phases in iterations called Spirals.

Objectivies determination and identify alternative solutions:

Software engineering Page 16


This phase starts with gathering the business requirements in the baseline
spiral. In the subsequent spirals as the product matures, identification of system
requirements, subsystem requirements and unit requirements are all done in
this phase.
This phase also includes understanding the system requirements by continuous
communication between the customer and the system analyst. At the end of the
spiral, the product is deployed in the identified market.

Identify and resolve risk:

In the risk analysis phase, a process is undertaken to identify risk and alternate
solutions. A prototype is produced at the end of the risk analysis phase. If any
risk is found during the risk analysis then alternate solutions are suggested and
implemented.

Develop next version of the product:

In this phase software is developed, along with testing at the end of the phase.
Hence in this phase the development and testing is done. at the end of the third
quadrant the next version of the software is available.

Review and plan for the next phase:

This phase allows the customer to evaluate the output of the project to date
before the project continues to the next spiral.

Spiral Model Application


The Spiral Model is widely used in the software industry as it is in sync with
the natural development process of any product, i.e. learning with maturity
which involves minimum risk for the customer as well as the development
firms.
The following pointers explain the typical uses of a Spiral Model −
 When there is a budget constraint and risk evaluation is important.
 For medium to high-risk projects.
 Long-term project commitment because of potential changes to economic
priorities as the requirements change with time.
 Customer is not sure of their requirements which is usually the case.
 Requirements are complex and need evaluation to get clarity.
 New product line which should be released in phases to get enough
customer feedback.
Software engineering Page 17
 Significant changes are expected in the product during the development
cycle.
The advantages of the Spiral SDLC Model are as follows −
 Changing requirements can be accommodated.
 Allows extensive use of prototypes.
 Requirements can be captured more accurately.
 Users see the system early.
 Development can be divided into smaller parts and the risky parts can be
developed earlier which helps in better risk management.
The disadvantages of the Spiral SDLC Model are as follows −
 Management is more complex.
 End of the project may not be known early.
 Not suitable for small or low risk projects and could be expensive for
small projects.
 Process is complex
 Spiral may go on indefinitely.
 Large number of intermediate stages requires excessive documentation.
2.6 UNIFIED PROCESS:

Unified Process is based on the enlargement and refinement of a system


through multiple iterations, with cyclic feedback and adaptation. The system

Software engineering Page 18


is developed incrementally over time, iteration by iteration, and thus this
approach is also known as iterative and incremental software development.
The iterations are spread over four phases where each phase consists of one
or more iterations

Phases of the unified process:

Inception—the first and the shortest phase in the project. It is used to


prepare basis for the project, including preparation of business case,
establishing project scope and setting boundaries, outlining key
requirements, and possible architecture solution together with design
tradeoffs, identifying risks, and development of initial project plan—
schedule with main milestones and cost estimates. If the inception
phase lasts for too long, it is like an indicator stating that the project
vision and goals are not clear to the stakeholders. With no clear goals and
vision the project most likely is doomed to fail. At this scenario it is
better to take a pause at the very beginning of the project to refine the
vision and goals. Otherwise it could lead to unnecessary make overs and
schedule delays in further phases.

Elaboration—during this phase the project team is expected to capture a


majority of system’s requirements (e.g., in the form of use cases), to
perform identified risk analysis and make a plan of risk management to
reduce or eliminate their impact on final schedule and product, to
establish design and architecture (e.g., using basic class
diagrams, package diagrams, and deployment diagrams), to create a plan
for the next (construction) phase.

Construction—the longest and largest phase within Unified Process.


During this phase, the design of the system is finalized and refined and
the system is built using the basis created during elaboration phase. The
construction phase is divided into multiple iterations, for each iteration to
result in an executable release of the system. The final iteration of
construction phase releases fully completed system which is to be
deployed during transition phase, and

Transition—the final project phase which delivers the new system to its
end-users. Transition phase includes also data migration from legacy
systems and user trainings.

Each phase and its iteration consists of a set of predefined activities. The
Unified Process describes work activities as disciplines—a discipline is a
set of activities and related artifacts in one subject area (e.g., the activities

Software engineering Page 19


within requirements analysis). The disciplines described by Unified
Process are as follows.

Business modeling—domain object modeling and dynamic modeling of


the business processes,

Requirements—requirements analysis of system under consideration.


Includes activities like writing use cases and identifying nonfunctional
requirements,

Analysis and design—covers aspects of design, including the overall


architecture,

Implementation—programming and building the system (except the


deployment),

Test—involves testing activities such as test planning, development of test


scenarios, alpha and beta testing, regression testing, acceptance testing,
and

Deployment—the deployment activities of developed system.

2.7 PERSONAL AND TEAM PROCESS MODEL:

Personal software process:

The personal software process is a structured software development process thai


is designed to help software engineers. better to understand and improve their
performance by developing of the code.

 It is a systematic application development method intended to help engineers


understand and enhance their output by applying professionalism to the way
they build software and monitoring their expected and actual code creation.

 It indicates developers how to control the value of their assets, what to draw up
a sound plan as well as how to make promises. This also provides them the
evidence to explain their proposals.

 The personal software method focuses on entities to enhance their results. It


consists of methods, types and techniques that orient programmers in their
technical work.

Software engineering Page 20


Team software process:

The team software process guides engineering teams in developing software


intensive products

 The goal of the TSP is to enhance the quality and efficiency of the entire team
application development project, in addition to helping us help meet the expense
and timeline obligations of creating software.

 TSP is designed for use in education environments, concentrating on the process


of creating a project management team, creating team goals, assigning team
tasks, and several other collaboration activities.

 Team software relies on a community of people and seeks to improve team


performance.

2.8 THE CAPABILITY MATURITY MODEL INTEGRATION:

The Capability Maturity Model (CMM) is a procedure used to develop and


refine an organization's software development process.

The model defines a five-level evolutionary stage of increasingly organized and


consistently more mature processes.

Capability Maturity Model is used as a benchmark to measure the maturity of


an organization's software process.

OBJECTIVES OF CMMI:

1. Fulfilling customer needs and expectations.


2. Value creation for investors/stockholders.
3. Market growth is increased.
4. Improved quality of products and services.
5. Enhanced reputation in industry.

Software engineering Page 21

You might also like