0% found this document useful (0 votes)
69 views24 pages

Module-1: Software Engineering

The document provides an introduction to key concepts in software engineering: 1. It defines software and discusses its characteristics, including that it is engineered not manufactured. It also defines software engineering as applying scientific principles and methods to develop software products. 2. It outlines the changing nature of software, including categories like system software, application software, embedded software, and web applications. 3. It discusses common "software myths" that are false beliefs about software development, including management myths about schedules/outsourcing, customer myths about requirements, and practitioner myths about quality assurance. 4. It introduces the concept of software engineering being a "layered technology" focused on quality.

Uploaded by

fruit99punch
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)
69 views24 pages

Module-1: Software Engineering

The document provides an introduction to key concepts in software engineering: 1. It defines software and discusses its characteristics, including that it is engineered not manufactured. It also defines software engineering as applying scientific principles and methods to develop software products. 2. It outlines the changing nature of software, including categories like system software, application software, embedded software, and web applications. 3. It discusses common "software myths" that are false beliefs about software development, including management myths about schedules/outsourcing, customer myths about requirements, and practitioner myths about quality assurance. 4. It introduces the concept of software engineering being a "layered technology" focused on quality.

Uploaded by

fruit99punch
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/ 24

MODULE-1

EID303
SOFTWARE ENGINEERING

A.NAVYA SREE
ASSISTANT PROFESSOR

DEPARTMENT OF CSE
SYLLABUS

Introduction to Software Engineering: Software, software


engineering, the changing nature of software, software myths.
A Generic view of process: Software engineering, a layered
technology, a process framework, CMMI.
Process models: The waterfall model, incremental process models,
evolutionary process models.
SOFTWARE
Is defined as:
(1) Set of instructions (or) collection of computer programs that when executed gives (or)
provides desired features, function, and performance.
(2) Data structures that enable the programs to adequately manipulate information.
(3) Descriptive information in both hard copy and virtual forms that describes the
operation and use of the programs.

 Who builds software?


Software engineers build, support it and maintain it.
 Who uses it?
Everyone in the industrialized world uses it either directly or indirectly, it affects
nearly every aspect of our lives and has become pervasive in our commerce, our culture,
and our everyday activities.
 What is work product?
From developer (or) software engineer point of view, the work product is the
programs, documents, and data. But from the user’s point of view, the work product is
the resultant information (or) end product that makes the user’s world better.

 Characteristics of Software:
(1)Software is developed or engineered. It is not manufactured.
-Some similarities exist between software development and hardware
development (or) manufacturing, but two activities are different.
- In both activities high quality is achieved through good design.
-Quality problems occur in hardware manufacturing which are difficult to
remove.
-During software development it can be easily rectified.
-In both activities developers are responsible for providing quality products.
(2)Software doesn’t wear out.
- In hardware development process the failure rate is very high because of
manufacturing defects.
-If the defects are corrected the failure rate reduces.
-As the time passes the failure rate increases due to the environmental maladies
[Eg: temperature, dust and vibrations].
In software there will be no environmental maladies (or) changes so the
curve should be idealized. But due to the changes and undiscovered errors the failure rate
will be high and when errors are corrected it drops.

Hardware Curve Software Curve

Figure : Bathtub Curve

(3)The industry is moving toward component-based construction, most software


continues to be custom built.
-A software component should be designed and implemented so that it can be
reused in many different programs.
-Example: In today’s software industry, GUI is built using the reusable
components such as message windows, pull down menus and many more such
components.

 Software Product:
Software when developed (or) made for a specific requirement.
 Engineering:
Developing products using certain principles and methods.

DEFINITIONS OF SOFTWARE ENGINEERING


(1)Software engineering is an engineering branch associated with development of
software product using well defined scientific principles, methods and procedures.
(2)Software engineering is the process of solving customer’s problem by the systematic
development and evolution of large, high quality software systems within cost, time and
other constraints.

THE CHANGING NATURE OF SOFTWARE


 System software:

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


programs.
-System software area is characterized by the heavy interaction with computer
hardware that requires scheduling, resource sharing, and sophisticated process
management.
-For example, an operating system is system software, which controls the
hardware, manages memory and multitasking functions, and acts as an interface between
application programs and the computer.

 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.

 Engineering/scientific software:
-This software is used to facilitate the engineering/scientific functions and tasks.
-Computer-aided design, system simulation, and other interactive applications
have begun to take real-time and even system software characteristic.

 Embedded software:

-Embedded software is a type of software which is directly embedded into the


hardware (read only memory).
-It is used to implement and control features and functions for the end-user.
-Examples of embedded software or system are washing machines, satellite
systems like weather satellite, and microwave oven, etc.

 Product line software:

- Designed to provide a specific capability for use by many different customers.


-Example:word-processor,spreadsheets,multimedia-software,database
applications.

 Web -applications:

-It is a client-server computer program which the client runs on the web
browser.
-Data on the Internet is in the form of text, audio, or video format, linked with
hyperlinks.
-Web browser is a software that retrieves web pages from the Internet.
 Artificial intelligence software:

-Artificial intelligence software makes use of a non-numerical algorithm to solve


a complex problem.
-Application within this area includes robotics, expert system, pattern
recognition, artificial neural network etc.

 Software - New Categories:

-Ubiquitous computing - wireless networks


-Net sourcing - the Web as a computing engine
-Open source – “free” source code open to the computing community (a blessing,
but also a potential curse!)
-Data mining
➢ Grid computing
➢ Cognitive machines
➢ Software for nanotechnologies

SOFTWARE MYTHS
 Myth:
A widely held but false belief or idea, typically involving supernatural beings or
events. Myths appear to be reasonable statement of fact but when comes to reality it
changes.
 Software Myths:
False beliefs about software and the process that is used to build it. Software
myths are of three types:
➢ Management myths
➢ Customer myths
➢ Practitioner’s myths
(1) Management myths:
 Myth- We already have a book that’s full of standards and procedures which are
enough for building software.
Reality- Standards are often incomplete. If they are complete, developers may not be
aware of all the established standards. It doesn’t reflect modern software engineering
practices.

 Myth- If we get behind schedule, we can add more programmers and catch up.
Reality- Adding new people to the project, further delays the project as people who are
already working must spend time educating the newcomers. People can be added but only
in a planned and well coordinated manner.

 Myth - Outsourcing the software project to third party, we can relax and let that them
build it.
Reality- Outsourcing software to a third party does not help the organization, which is
incompetent in managing and controlling the software project internally.

(2)Customer myths:
 Myth- General Statement of objective is enough to begin writing programs, the details
can be filled in later.
Reality- Incomplete and ambiguous requirements often lead to software failure. A formal
and detailed description of the functions, behavior, performance, interfaces, design
constraints, and validation criteria is essential.

 Myth - Software changes can be done easily because it is flexible.


Reality- The impact of changing requirements at earlier in the development process costs
lesser than those that occurs at later stages.

(3)Practitioner’s myths:
 Myth - Once the program is written, the job has been done.
Reality- All the efforts are expended after the software is delivered to the user, for
maintaining, adding new requirements and so on.

 Myth - Until the program is running, there is no way of assessing the quality.
Reality- The quality of software can be measured during any phase of development
process by applying some quality assurance mechanism. One such mechanism is formal
technical review.
 Myth - The only deliverable work product is the working program
Reality- A successful project which is delivered includes not only the working program
but also the documentation to guide the users for using the software.

 Myth- Software Engineering creates voluminous and unnecessary documentation and


invariably slows down software development.
Reality- Software engineering is about creating quality at every level of the software
project. Proper documentation enhances quality which results in reducing the amount of
rework.

SOFTWARE ENGINEERING – A LAYERED TECHNOLOGY


 Quality focus:
-Engineering approaches rest on quality considering the requirements given by
the customer as the customer wants the product to be reliable, efficient and the developer
also have standards to meet (reusability, maintainability)
- Bedrock that supports software Engineering is “Quality Focus”.
 Process:
-Foundation for software Engineering is the process layer.
-Software engineering process is the glue that holds all the technology layers
together.
- The software process forms the basis for management control of software
projects and establishes the context in which technical methods are applied, work
products are produced, milestones are established, quality is ensured, and change is
properly managed.

 Methods:
- Provide technical how-to’s for building software.
- Methods contain a broad array of tasks that include communication requirement
analysis, design modeling, program construction testing and support.

 Tools:
- Provide semi-automatic and automatic support to process and methods. [ i.e.,
CAD]
Figure: Layers of Software Engineering

DEFINITIONS:
 Process: Collection of activity, action, task that are performed when some work product
is created.
 Activity: An activity strives to achieve a broad objective and is applied regardless of the
application domain, size of the project, complexity with which software engineering is to
be applied.
 Action: An action encompasses a set of tasks that produces a major work product.
 Task: A task focuses on a small, but well-defined objective that produces a tangible
outcome.

A PROCESS FRAMEWORK
 Establishes the foundation for a complete software process.
 Identifies a number of framework activities applicable to all software projects.
 Also include a set of umbrella activities that are applicable across the entire software
process.
 Used as a basis for the description of process models.
Figure: A Software Process Framework

 Generic process activities:


➢ Communication: In this activity, heavy communication with customers and other
stakeholders, requirement gathering is done.
➢ Planning: It describes the technical tasks to be conducted, the risks, the
resources that will be required, the work products to be produced and work
schedule.
➢ Modeling: In this activity, a model is created in order to better understand
software requirements and the design by the developer and customer.
➢ Construction: This activity combines code generation and the testing that is
required to uncover errors in the code.
➢ Deployment: The software (as a complete entity or as a partially completed
increment) is delivered to the customer who evaluates the delivered product and
provides feedback based on the evaluation.

 Umbrella activities:
➢ Software project tracking and control:

-In this activity, the developing team accesses project plan and compares it with
the predefined schedule.
-If these project plans do not match with the predefined schedule, then the
required actions are taken to maintain the schedule.

➢ Risk management:
- Assesses risks that may affect the outcome of the project or the quality of the
product.

➢ Software quality assurance:


- It defines and conducts the activities required to ensure software quality.
- For example, during the software development meetings are conducted at every
stage of development to find out the defects and suggest improvements to produce good
quality software.

➢ Formal technical reviews:


- Assesses software engineering work products in an effort to uncover and
remove errors before they are propagated to the next activity.

➢ Measurement:
- Defines and collects process, project, and product measures.
- Measures like cost, lines of code, size of software, quality of software etc.
➢ Software configuration management:

- Manages the effects of change throughout the software process.


➢ Reusability management:
- Defines criteria for work product reuse and establishes mechanisms to achieve
reusable components.
➢ Work product preparation and production:

- The activities required to create work products such as models, documents, logs,
forms, and lists.

THE CAPABILITY MATURITY MODEL INTEGRATION (CMMI)


-Developed by SEI (Software Engineering institute)
-Assess the process model followed by an organization and rate the organization with
different levels.
-A set of software engineering capabilities should be present as organizations reach
different levels of process capability and maturity.
-CMMI process Meta model can be represented in different ways:
➢ A Continuous Model.
➢ A Staged Model.

 Continuous Model:

-Lets organization select specific improvement that best meet its business objectives and
minimize risk
-Levels are called capability levels.
-Describes a process in 2 dimensions.
-Each process area is assessed against generic, specific goals and practices and is rated
according to the following capability levels.
-Set of activities (or) areas that are clubbed together.

 Levels of CMMI

-Level 0: Incomplete: Process is adhoc .Objectives and goals of process areas are not
achieved.
-Level 1: Performed: All the specific goals of the process area have been satisfied.
-Level 2: Managed: Activities are monitored, reviewed, evaluated and controlled.
-Level 3: Defined: Activities are standardized, integrated and documented.
-Level 4: Quantitatively Managed: Metrics and indicators are available to measure the
process and quality.

-Level 5: Optimized: Continuous process improvement based on quantitative feedback


from the user. Use of innovative ideas and techniques, statistical quality control and other
methods for process improvement.

 Staged Model:

-This model is used if you have no clue of how to improve the process for quality
software.
-It gives a suggestion of what things other organizations have found helpful to work first.
-Levels are called maturity levels.
 CMMI currently addresses three areas of interest:

-Product and service development — CMMI for Development (CMMI-DEV),


-Service establishment, management, — CMMI for Services (CMMI-SVC), and
-Product and service acquisition — CMMI for Acquisition (CMMI-ACQ).
 Process Areas required to achieve a Maturity Model:
LEVEL FOCUS PROCESS AREA

PROCESS FLOW

Linear process flow: A linear process flow executes each of the five framework activities in
sequence.
Iterative process flow: The five framework activities are done in iterative fashion.
Evolutionary process flow: An evolutionary process flow executes the activities in a “circular”
manner (combination of iterative and linear).Each circuit leads to a more complete version of the
software.
Parallel process flow: A parallel process flow executes one or more activities in parallel with
other activities.

PROCESS MODELS
Process model is a diagrammatic representation, description of each phase and various
activities required to make a software product. Various process models are:
➢ The Waterfall Model
➢ Incremental Process Models
➢ Evolutionary Process Models

(1) The Waterfall Model:


-It is also called as linear/sequential model/classic life cycle.
-It is the oldest software paradigm.
-Used when requirements are well understood in the beginning.
-A systematic, sequential approach to Software development.
-Begins with customer specification of Requirements and progresses through
planning, modeling, construction and deployment.

Figure: The waterfall model

-A variation in the representation of the waterfall model is called the V-model.


-The V-model depicts the relationship of quality assurance actions to the actions
associated with communication, modeling, and early construction activities.
-Once code has been generated, the team moves up the right side of the V,
essentially performing a series of tests (quality assurance actions) that validate
each of the models created as the team moved down the left side.
- In reality, there is no fundamental difference between the classic life cycle and
the V-model.
-The V-model provides a way of visualizing how verification and validation
actions are applied to earlier engineering work.
Figure: The V-model

Advantages:
-Simple to implement.
-For implementing small systems waterfall model is useful.
- Easy to arrange tasks.
Disadvantages:
-Real projects rarely follow the sequential flow that the model proposes.
-It is difficult for the customer to state all the requirements explicitly.
- Users can only judge quality at the end.
- Risk and uncertainty is high with this process model.
-Waterfall model leads to “blocking states”.

(2) Incremental Process Models:


In this model, the initial model with limited functionality is created for user’s
understanding about the software product and then this model is refined and
expanded in later releases.
 The Incremental Model:
-The incremental model combines elements of the waterfall model applied in an
iterative fashion.
-The incremental model delivers series of releases to the customer. These releases
are called increments.
-More and more functionality is associated with each increment.
-The first increment is called “core product”.

Figure: The incremental model

When to choose it?


-When requirements are reasonably well-defined.
-When limited set of software functionalities are needed.
Advantages:
-The incremental model can be adopted when there are less number of people
involved in the project.
-Technical risks can be managed with each increment.
-For a very small time span, atleast core product can be delivered to the customer.
Disadvantages:

-Needs good planning and design.


-Needs a clear and complete definition of the whole system before it can be
broken down and built incrementally.
 The RAD Model:
-The RAD model is a type of incremental process model in which there is
extremely short development cycle.
- High-speed adoption of the waterfall model using a component based
construction approach.
-Creates a fully functional system within a very short span time of 60 to 90 days.
-Multiple software teams work in parallel on different functions.
-Modeling encompasses three major phases: Business modeling, Data modeling
and process modeling.
-Construction uses reusable components, automatic code generation and testing.

Figure: The RAD model

Advantages:
- Productivity with in short time.
- Progress can be measured.
- Cycle time can be short with use of powerful RAD tools.
Disadvantages:
-For the project, large number of people or sufficient human resources is required
to create the teams.
-Heavy commitment of the developers and customers is required otherwise RAD
project fails.
-High performance is an issue.
-RAD may not be appropriate when technical risks are high.
-If a system cannot be properly modularized, building the components necessary
for RAD will be problematic.

When to choose it?


-When time span is short for producing the project
-When requirements are well known
-When user will be involved throughout the cycle
-When technical risks are less
-When budget is high
(3)Evolutionary Process Models
-Software evolves over a period of time.
-Business and product requirements often change as development proceeds making a
straight-line path to an end product unrealistic.
-Evolutionary models are iterative and as such are applicable to modern day applications.
-Types of evolutionary models
➢ Prototyping
➢ The Spiral model
➢ The Concurrent Development Model
 Prototyping:
The Prototyping Model is a systems development method (SDM) in which a prototype is
built, tested, and then reworked as necessary until an acceptable prototype is finally achieved
from which the complete system or product can now be developed.

-Used when customer defines a set of objective but does not identify input, output, or
processing requirements.
-Developer is not sure of:
➢ Efficiency of an algorithm.
➢ Adaptability of an operating system.
➢ Human/machine interaction.

-The prototyping paradigm begins with communication.


-The software engineer and customer meet and identify whatever requirements are
known.
- Outline areas where further definition is mandatory.
- A prototyping iteration is planned quickly and modeling occurs.
-The quick design focuses on a representation of those aspects of the software that will
be visible to the customer.
- Quick design leads to the construction of prototype.
-The prototype is deployed and evaluated by the customer.
-Feedback is used to refine requirements for the software.
-Iteration occurs as the prototype is turned to satisfy the needs of customer.
-Ideally, the prototype serves as a mechanism for identifying software requirements.

Figure: The prototyping model


Advantage:
- Improved and increased user involvement.
Disadvantages:
-User confusion of prototype and finished system.
-Developer attachment to prototype.
-Excessive development time of the prototype.
-Expense of implementing prototyping.
-The developer often makes implementation compromises in order to get a
prototype working quickly.
-There may be too much variation in requirements each time the prototype is
evaluated by the customer.
-Poor Documentation due to continuously changing customer requirements.
Limitation of Prototyping:

-In a rush to get it working, overall software quality or long term maintainability
are generally overlooked.
-Use of inappropriate Operating system or programming language.
-Use of inefficient algorithm
 The Spiral Model:

-The spiral model is an evolutionary software process model that couples the
iterative nature of prototyping with the controlled and systematic aspects of the
waterfall model.
-The spiral model is divided into a number of framework activities.
-These framework activities are denoted by task regions.
-Starts in middle and continually visits the basic tasks of communication,
planning, modeling, construction and deployment.
-Realistic approach to the development of large scale system and software.
-Software evolves as process progresses.
-Better understanding between developer and customer.
-The first circuit might result in the development of a product specification.
-Subsequent circuits develop a prototype and sophisticated version of software.
Unlike other process models that end when software is delivered, the
spiral model can be adapted to apply throughout the life of the computer software.
Therefore, the first circuit around the spiral might represent a “concept
development project” that starts at the core of the spiral. The process proceeds
outward on the spiral and a “new product development project” commences.
Later, a circuit around the spiral might be used to represent a “product
enhancement project”. Later, a circuit around the spiral might be used to
represent a “product maintenance project”.

Figure: The spiral model


Advantages:
- Changing requirements can be accommodated.
-Risks can be identified and rectified before they get problematic.
- Project estimates in terms of schedule, costs become more and more realistic as
the project moves forward, and loops in spiral get completed.

Disadvantages:

-Management is more complex.


-End of project may not be known early.
-Not suitable for small or low risk projects (expensive for small projects).
-Process is complex.
-Spiral may go indefinitely.
-Large number of intermediate stages requires excessive documentation.

 The Concurrent Development Model:

-The concurrent development model is also called as “concurrent engineering”.


-In this model, the framework activities or software development tasks are
represented as “states”.
-The communication activity has completed in the first iteration and exits in the
awaiting changes state.
-The modeling activity completed its initial communication and then goes to the
underdevelopment state.
-If the customer specifies the change in the requirement, then the modeling
activity moves from the under development state into the awaiting change state.
-The concurrent process model activities moving from one state to another state.
-Concurrent modeling defines a series of events that will trigger transitions from
state to state for each of the software engineering activities, actions, or tasks.
Figure: One element of the concurrent process model
Advantages:

-This model is applicable to all types of software development processes.


-It is easy for understanding and use.
-Each activity or task can be carried out concurrently.
-It provides an accurate picture of the current state of a project.
Problems in Evolutionary Process

-Difficult in project planning.


-Speed of evolution is not known. The evolutions occur too fast, without a period of
relaxation, it is certain that the process will fail or more errors. On the other hand if the
speed is too slow then productivity could be affected.
-Does not focus on flexibility and extensibility.

You might also like