Unit I

Introduction to Software Engineering

Unit I: Introduction to Software Engineering (06

Hrs.)
Software Engineering Fundamentals: Nature of Software, Software Engineering Principles, The
Software Process, Software Myths. Process Models: Generic Process Model, Prescriptive
Process Models- The Waterfall, Incremental Process (RAD), Evolutionary Process, Unified
Process, Concurrent. Advanced Process Models: Agile Process Model Methods, Plan driven and
agile development, Extreme Programming (XP) Practices.
Self-Study: Agile open source tool.
Detail Notes
1.1 Introduction to Software Engineering
Software:
Software is a set of instructions or programs instructing a computer to do specific task.
Software is considered to be a collection of executable programming code, associated
libraries and documentations.
Engineering:
Engineering on the other hand, is all about developing products, using well-defined,
scientific principles and methods.
Software Engineering:
Software Engineering is about teams and it is about quality. The problems to solve are so
complex or large, that a single developer cannot solve them anymore. Software Engineering
has the objective of solving these problems by producing good quality, maintainable
software, on time, within budget.
Definition
“Software engineering is the technological and managerial discipline concerned with
systematic production and maintenance of software products that are developed and
modified on time and within cost estimates.”
Stephen Schach defined the same as
A discipline whose aim is the production of quality software, software that is delivered on
time, within budget and that satisfies its requirements.

Program versus Software

Software is more than programs. It consists of programs; documentation of any facet of the
program and the procedure used to setup and operate the software system.
The Changing Nature of Software
Software has become integral part of most of the fields of human life. We name a field and we
find the usage of software in that field. Software applications are grouped into eight areas for
convenience as shown in the figure.
 System Software
 Real Time Software
 Embedded Software
 Business Software
 Personal Computer Software
 Artificial Intelligence Software
 Web Based Software
 Engineering and Scientific Software
1. System Software

System Software is a collection of programs written to service other

programs. Infrastructure software comes under this category like compilers,
operating systems, editors, drivers, etc.

System software is software that provides platform to other software‘s. Some

examples can be operating systems, antivirus software, disk formatting software as,
computer language translator etc. These are commonly prepared by the computer
manufactures.

2. Real Time Software

This Software is used to monitor, control and analyze real world events as
 they occur. Real time software deals with changing environment.

An example may be software required for weather forecasting. Such software

will gather and process the status of temperature, humidity and other environmental
parameters to forecast the weather.

3. Embedded Software

Embedded Software resides within a product or system and is used to

implement and control features and functions for the end user and for the system
itself. This type of software is placed in “Read Only Memory (ROM)” of the product
and controls the various functions of the product.

The product could be an aircraft, automobile, security system, signalling

system, control unit of power plants, etc. The embedded software handles hardware
components and is also termed as intelligent software.

4. Business Software

This is the largest application area. The software designed to process business
applications is called business software. Business software could be payroll, file
monitoring system employee management, and account management. It may also be
a data warehousing tool which helps us to take decisions based on available data.

Management information system, Enterprise Resource Planning (ERP) and

such other software are popular example of business software.

5. Personal Computer Software

The Software used in personal computers is covered in this category.

Examples are word processors, computer graphics, and multimedia and animating
tools, database management, personal and financial applications, computer games
etc. This is a very upcoming area and many big organisations are concentrating their
effort here due to large customer base.

6. Artificial Intelligence Software

AI Software makes use of non numerical algorithms to solve complex

problems that are not amenable to computation or straightforward analysis.
Applications within this area include robotics, expert system, pattern recognition
 (image and voice), artificial neural networks, theorem proving, and game playing.

7. Web Based Software

The software related to web applications comes under this category.

Examples are CGI, HTML, Java, Perl, DHTML, etc.

8. Engineering and Scientific Software

Formerly characterized by ―number crunching‖ algorithms,

engineering and scientific software applications range from astronomy to volcano
logy, from automotive stress analysis to space shuttle orbital dynamics, and from
molecular biology to automated manufacturing.

Scientific and engineering application software is grouped in this category.

Huge computing is normally required to process data. Examples are CAD/CAM
packages, SPSS, MATLAB, Engineering pro, Circuit analyzers etc.

1.1 Software Myths

Myth is defined as "widely held but false notation" by the oxford dictionary,
so as in other fields software arena also has some myths to demystify. Pressman
insists "Software myths- beliefs about software and the process used to build it- can
be traced to earliest days of computing.

Myths have a number of attributes that have made them insidious." So

software myths prevail but though they do are not clearly visible they have the
potential to harm all the parties involved in the software development process mainly
the developer team.

Here are number of myths associated with software development community.

Software myths-beliefs about software and process used to build it –can be traced to
the earliest days of computing. Myths have a number of attributes that have made
them insidious.
In developing software, the developers put their extreme dedication and hard
work. A great majority of software related problems arises because of the myths that
formed during the software developments initial stages.
 Software is easy to change
Computers provide greater reliability than the devices they replace

 Testing software or proving ‘software correct can remove all the errors.
 Reusing software increases safety.
  Software can work right the first time.
 Software can be designed thoroughly enough to avoid most integrations
problems.
 Software with more features is better software.
 Addition of more software engineers will make up the delay.
 Aim is to develop working programs.

1. Software is easy to change

It is true that source code files area easy to edit, but that is quite different than
saying that software is easy to change. This is deceptive precisely because source
code is so easy to alter. But making changes without introducing errors is extremely
difficult, particularly in organization with poor process maturity.

Every change requires that the complete system be re-verified. If we do not

take proper care, this will be an extremely tedious and expensive process.

2. Computers provide greater reliability than the devices they replace.

It is true that software does not fail in the traditional sense. There are no
limits to how many times a given piece of code can be exhausted before it
―wears out‖. In any event, the simple expression of this myth is that our general
ledgers are still not perfectly accurate, even though they have been computerized.

Back in the days of manual accounting systems, human error was a fact of
life. Now, we have software error as well.

3. Testing software or „proving‟ software correct can remove all the errors

Testing can only show the presence of errors. It cannot show the absence of
errors. Our aim is to design effective test cases in order to find maximum possible
errors. The more we test, the more we are confident about our design.

4. Reusing software increases safety

This myth is particularly troubling because of the false sense of security that
code re-use can create. Code reuse is a very powerful tool that can yield dramatic
improvement in development efficiency, but it‘s still requires analyses to determine
its suitability and testing tool determine if it works.

5. Software can work right the first time

 If we go to an aeronautical engineer, and ask him to build a jet fighter craft, he will
quote as a
price.

If we demand that it is to be put in production without building a prototype,

he will laugh and may refuse the job. Yet, software engineer‘s area often asked to do
precisely this sort of work, and they often accept the job.

6. Software can be designed thoroughly enough to avoid most integrations problems

There is an old saying among software designers: ―Too bad, there is

no compiler for specifications‖: These points out the fundamental difficulty with
detailed specifications. They always have inconsistencies, and there is no computer
tool to perform consistency checks on these.
Therefore, special care is required to understand the specifications, and if
there is an ambiguity, that should be resolved before proceeding for design.

7. Software with more features is better software

This is, of course, almost the opposite of the truth. The best, most enduring
programs are those which do one thing well.

8. Addition of more software engineers will make up the delay

This is not true in most of the cases. By the process of adding more software
engineers during the project, we may further delay the project. This does not serve
any purpose here, although this may be true for any civil engineering work.

9. Aim is to develop working programs

The aim has been shifted from developing working programs to good quality,
maintainable programs. Maintaining software has become a very critical and crucial
area for software engineering community.

These myths, poor quality of software, increasing cost and delay in the
delivery of the software have been the driving forces behind the emergence of
software engineering as a discipline. Primarily, there are three types of software
myths, all the three are stated below:
 Management Myth
 Customer Myth
 Practitioner/Developer Myth
Management Myth

Managers with software responsibility, like managers in most disciplines, are

often under pressure to maintain budgets, keep schedules from slipping, and improve
quality.
Like a drowning person who grasps at a straw, a software manager often
grasps at belief in a software myth, if those beliefs will lessen the pressure (even
temporarily). Some common managerial myths stated by Roger Pressman include:
 We have standards and procedures for building software, so
developers have everything they need to know.
 We have state-of-the-art software development tools; after all,
we buy the latest computers.
 If we're behind schedule, we can add more programmers to catch up.
 A good manger can manage any project.
The managers completely ignore that fact that they are working on
something intangible but very important to the clients which invites more trouble
than solution.

So a software project manager must have worked well with the software
development process analyzing the minute deals associated with the field learning
the nitty-gritty and the tips and trick of the trade.

Customer Myths

A customer who requests computer software may be a person at the next

desk, a technical group down the hall, the marketing/sales department, or an outside
company that has requested software under contract.

In many cases, the customer believes myths about software because software
managers and practitioners do little to correct misinformation. Myths lead to false
expectations (by the customer) and, ultimately, dissatisfaction with the developer.
Commonly held myths by the clients are:
 A general statement of objectives is sufficient to begin writing
programs - we can fill in the details later.
 Requirement changes are easy to accommodate because software is flexible.
 I know what my problem is; therefore I know how to solve it.
This primarily is seen evidently because the clients do not have a
firsthand experience in software development and they think that it's an easy
 process.

Practitioner/ Developer Myths

Myths that are still believed by software practitioners have been fostered by
over 50 years of programming culture. During the early days of software,
programming was viewed as an art form. Old ways and attitudes die hard.
A malpractice seen is developers are that they think they know everything
and neglect the peculiarity of each problem.
 If I miss something now, I can fix it later.
 Once the program is written and running, my job is done.
 Until a program is running, there's no way of assessing its quality.
The only deliverable for a software project is a working program

Different Models:

Waterfall Model

 It is also called as classic life cycle Model.

 Oldest software lifecycle model and best understood by upper management.

 Here, the work flow is in a linear (i.e., sequential) fashion.

 It suggests a systematic, sequential approach to software development that begins with

customer specification of requirements and progress through planning, modeling,
construction and deployment with ongoing support of the completed softwar

Fig. Waterfall Model

Advantages:
  Used often with well-defined adaptations or enhancements to current software

 Used when requirements are well defined and reasonably stable and risk is low

Disadvantages:

 Doesn't support iteration, so changes can cause confusion.

 Requires customer patience because a working version of the program doesn't occur
until the final phase.

 Problems can be somewhat alleviated in the model through the addition of feedback
loops

Incremental Process Model

 It combines elements of linear and parallel process flows.

 Each linear sequence produces deliverable increments of the software.

 Focuses on delivery of an operational product with each increment.

 The first increment is often a core product with many supplementary features.

 Users use it and evaluate it with more modifications to better meet the needs.

 Increments can be plan to manage Technical Risks. Eg. Word Processing Software

Fig. Incremental Process Model

Evolutionary Models

 Software system evolves over time as requirements often changes development

proceeds. Thus, a straight line to a complete end product is not possible. However, a
limited version must be delivered to meet competitive pressure.

 Usually a set of core product or system requirements is well understood, but the details
and extension have yet to be defined.
  You need a process model that has been explicitly designed to accommodate a product
that evolved over time.

 It is iterative that enables you to develop increasingly more complete version of the
software.

 Two types : Prototyping and Spiral models

Prototyping Model

When it is used:

Customer defines a set of general objectives but does not identify detailed requirements for
functions and features. Or Developer may be unsure of the efficiency of an algorithm, the form
that human computer interaction should take.

Steps:

 Begins with communication by meeting with stakeholders to define the objective,

identify whatever requirements are known, outline areas where further definition is
mandatory.

 A quick plan for prototyping and modeling (quick design) occur. Quick design focuses
on a representation of those aspects the software that will be visible to end users.
( interface and output).

 Design leads to the construction of a prototype which will be deployed and evaluated.

 Stakeholder’s comments will be used to refine requirements.

 Both stakeholders and software engineers like the prototyping paradigm.

 Users get a feel for the actual system, and developers get to build something
immediately. However, engineers may make compromises in order to get a prototype
working quickly.

 The less-than-ideal choice may be adopted forever after you get send to it.
 Fig. Prototyping Model

Disadvantages:

 The customer sees a "working version" of the software, wants to stop all development
and then buy the prototype after a "few fixes" are made.

 Developers often make implementation compromises to get the software running quickly
(e.g., language choice, user interface, operating system choice, inefficient algorithms)

Spiral Model

 It couples the iterative nature of prototyping with the controlled and systematic aspects
of the waterfall model.

 It is a risk-driven process model generator that is used to guide multi-stakeholder

concurrent engineering of software intensive systems.

 Two main distinguishing features:

 One is cyclic approach for incrementally growing a system’s degree of definition

and implementation while decreasing its degree of risk.

 The other is a set of anchor point milestones (Combination of work products and
conditions) for Spiral Model

 In Spiral Model, A series of evolutionary releases are delivered

 During the early iterations, the release might be a model or prototype.

 During later iterations, increasingly more complete version of the engineered

system are reduced.
  The first circuit in the clockwise direction might result in the product specification
subsequent passes around the spiral might be used to develop a prototype and then
progressively more sophisticated versions of the software. Each pass results in
adjustments to the project plan. Cost and schedule are adjusted based on feedback. Also,
the number of iterations will be adjusted by project manager.

 First Circuit around the Spiral represents Concept Development Project

 Starts at the core of spiral and continues for multiple iterations until concept
development is complete.

 If the concept is developed into actual product, the process proceeds outward on the
spiral New Product Development Project starts.

 New product will evolve through a number of iterations.

 Later the circuit around the spiral might be used to represent Product Enhancement
Project.

 The the last round may represent Product Maintenance Project.

Advantages:

 Good to develop large-scale system as software evolves as the process progresses and
risk should be understood and properly reacted to.

 Prototyping is used to reduce risk.

Disadvantages:

 It may be difficult to convince customers that it is controllable as it demands

considerable risk.
RAD Model (Rapid Application Development)

 Is an incremental software development process model that emphasizes an extremely

short development cycle.

 The RAD model is a “high-speed” adaption of the linear sequential model.

 Rapid development is achieved by using component based construction.

 The RAD process model enables a development team to create a “fully functional
system” within very short time periods.

1. Agile Process Model:

 Agile development model is also a type of Incremental model. Software is developed in
incremental, rapid cycles. This results in small incremental releases with each release
building on previous functionality. Each release is thoroughly tested to ensure software
quality is maintained. It is used for time critical applications. Extreme Programming
(XP) and Scrum are currently the most well-known agile development life cycle models.
Extreme Programming:
 XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to
develop software. eXtreme Programming (XP) was conceived and developed to address
the specific needs of software development by small teams in the face of vague and
changing requirements. Extreme Programming is one of the Agile software development
methodologies. It provides values and principles to guide the team behavior. The team is
expected to self-organize. Extreme Programming provides specific core practices where-
Each practice is simple and self-complete. Combination of practices produces more
complex and emergent behavior.

Extreme Programming in a Nutshell Extreme Programming involves-

 Writing unit tests before programming and keeping all of the tests running at all times.
The unit tests are automated and eliminate defects early, thus reducing the costs.
 Starting with a simple design just enough to code the features at hand and redesigning
when required.
 Programming in pairs (called pair programming), with two programmers at one screen,
taking turns to use the keyboard. While one of them is at the keyboard, the other
constantly reviews and provides inputs.
 Integrating and testing the whole system several times a day.
  Putting a minimal working system into the production quickly and upgrading it
whenever required.
 Keeping the customer involved all the time and obtaining constant feedback. Iterating
facilitates the accommodating changes as the software evolves with the changing
requirements.

Advantages:

• Slipped schedules: Short and achievable development cycles ensure timely

deliveries.
• Cancelled projects: Focus on continuous customer involvement ensures
transparency with the customer and immediate resolution of any issues.
• Costs incurred in changes: Extensive and ongoing testing makes sure the changes
do not break the existing functionality. A running working system always ensures
sufficient time for accommodating changes such that the current operations are not
affected.
• Production and post-delivery defects: Emphasis is on the unit tests to detect and
fix the defects early.
• Misunderstanding the business and/or domain: Making the customer a part of
the team ensures constant communication and clarifications.
• Business changes: Changes are considered to be inevitable and are
accommodated at any point of time.
• Staff turnover: Intensive team collaboration ensures enthusiasm and good
will. Cohesion of multi-disciplines fosters the team spirit.

The fundamental principles of Extreme Programming are-

• Rapid feedback
• Assume simplicity
• Incremental change
• Embracing change
• Quality work

Scrum Programming:
Scrum is an agile way to manage a project, usually software development. Agile
software development with Scrum is often perceived as a methodology; but rather than
viewing Scrum as methodology, think of it as a framework for managing a process.
Scrum Overview - Introduction to Scrum Terms
An introduction to Scrum would not be complete without knowing the Scrum terms
you'll be using. This section in the Scrum overview will discuss common concepts in Scrum.

Scrum team: A typical scrum team has between five and nine people, but Scrum projects can
easily scale into the hundreds. However, Scrum can easily be used by one-person teams and
often is. This team does not include any of the traditional software engineering roles such as
programmer, designer, tester or architect. Everyone on the project works together to complete
the set of work they have collectively committed to complete within a sprint. Scrum teams
develop a deep form of camaraderie and a feeling that “we’re all in this together.”

Product owner: The product owner is the project’s key stakeholder and represents users,
customers and others in the process. The product owner is often someone from product
management or marketing, a key stakeholder or a key user.

Scrum Master: The Scrum Master is responsible for making sure the team is as productive
as possible. The Scrum Master does this by helping the team use the Scrum process, by
removing impediments to progress, by protecting the team from outside, and so on.

Product backlog: The product backlog is a prioritized features list containing every desired
feature or change to the product. Note: The term “backlog” can get confusing because it’s
used for two different things. To clarify, the product backlog is a list of desired features for
the product. The sprint backlog is a list of tasks to be completed in a sprint.

Sprint planning meeting: At the start of each sprint, a sprint planning meeting is held,
during which the product owner presents the top items on the product backlog to the team.
The Scrum team selects the work they can complete during the coming sprint. That work is
then moved from the product backlog to a sprint backlog, which is the list of tasks needed to
complete the product backlog items the team has committed to complete in the sprint.

Daily Scrum: Each day during the sprint, a brief meeting called the daily scrum is
conducted. This meeting helps set the context for each day’s work and helps the team stay on
track. All team members are required to attend the daily scrum.

Sprint review meeting: At the end of each sprint, the team demonstrates the completed
functionality at a sprint review meeting, during which, the team shows what they
accomplished during the sprint. Typically, this takes the form of a demonstration of the new
features, but in an informal way; for example, PowerPoint slides are not allowed. The
meeting must not become a task in itself nor a distraction from the process.

Sprint retrospective: Also at the end of each sprint, the team conducts a sprint retrospective,
which is a meeting during which the team (including its Scrum Master and product owner)
reflect on how well Scrum is working for them and what changes they may wish to make for
it to work even better.

Scrum is an iterative framework to help teams manage and progress through a

complex project. It is most commonly used in Software Development by teams that
implement the Agile Software Development methodology. However it is not limited to those
groups. Even if your team does not implement Agile Software Development, you can still
benefit from holding regular scrums with your teams.
 Scrum participants fall into the same two categories. They are either Pigs or they are
Participants at scrum are either fully committed to the project or simply participants. Let’s look
at who
these various roles really are.

Pig

Roles
Actual Team Members: These would be the developers, artists or product managers that
comprise the core of the team. These are the people who are actually doing the daily work to
bring the project to fruition. These members are fully committed to the project.

Scrum Master: The scrum master might be one of the team members — or might not be. It
is important to call this person out separately here though because the Scrum master has the
primary role of ensuring that the scrum moves forward without problems and is effective for the
team.

Project Owner: This may be a Product Manager who is also comprised of the team or it may
not. Again it is important to call this persons role out here as this person represents the voice of
the end customer. This person needs to ensure that the product achieves it’s product goals and
provides the necessary end product to the customers.

Chicken Roles

Managers: At first glance you might think that managers are pigs — naturally. However in
the scrum context managers are generally more concerned about the people involved in a
project and their respective health. They are not as focused on the product and it’s particular
customer oriented goals. For this reason they are considered a chicken in the scrum context.

Stakeholders: Stakeholders are individuals who will benefit or have a vested interest in the
project, however do not necessarily have authority to dictate direction or to be held accountable
for the product. They can be consulted for opinions and insight however the product owner
needs to maintain final rights for the decision making process.

Why are the roles important

The chicken and pig roles are vital to scrum because it dictates who in the scrum
should be an active participant Chickens should not be active participants in a scrum meeting.
They may attend, however they should be there as guests only and not required to share
their current statuses. Pigs on
the other hand need to share their current progress and share any blockers that they are
encountering.

over theThe
direction
reason of
thatthe scrum and
Chickens leadnot
should it be
away from
active the goals isofthat
participants the they
entire
tooteam.
easilyItwill
is the
scrum
masters job to ensure that the scrum stays on target and covers the topics that need to be

at hand.
covered. if someone goes off topic (chicken or pig) it is the scrum masters job to bring the
group back to the topic

Advantages of Agile model:

 Customer satisfaction by rapid, continuous delivery of useful software.
 People and interactions are emphasized rather than process and tools.
Customers, developers and testers constantly interact with each other.
 Working software is delivered frequently (weeks rather than months). Face-to-
face conversation is the best form of communication.
 Close, daily cooperation between business people and developers. Continuous
attention to technical excellence and good design.
 Regular adaptation to changing circumstances.
 Even late changes in requirements are welcomed
Disadvantages of Agile model:
 In case of some software deliverables, especially the large ones, it is difficult to
assess the effort required at the beginning of the software development life
cycle.
 There is lack of emphasis on necessary designing and documentation.
 The project can easily get taken off track if the customer representative is not
clear what final outcome that they want.
 Only senior programmers are capable of taking the kind of decisions required
during the development process. Hence it has no place for newbie programmers,
unless combined with experienced resources.

When to use Agile model:

 When new changes are needed to be implemented. The freedom agile gives to change is very
important. New changes can be implemented at very little cost because of the frequency of
new increments that are produced.
 To implement a new feature the developers need to lose only the work of a few days, or
even only hours, to roll back and implement it.
 Unlike the waterfall model in agile model very limited planning is required to get started
with the project. Agile assumes that the end users’ needs are ever changing in a dynamic
business and IT world. Changes can be discussed and features can be newly effected or
removed based on feedback. This effectively gives the customer the finished system they
want or need.
 Both system developers and stakeholders alike, find they also get more freedom of time and
options than if the software was developed in a more rigid sequential way. Having options
gives them the ability to leave important decisions until more or better data or even entire
hosting programs are available; meaning the project can continue to move forward without
fear of reaching a sudden standstill.

Question Bank

Sr. No. Question CO BL Marks

1 CO1
2 CO1
3 CO2