Introduction to Software Engineering

ISE CLASSWORK
Introduction to Software Engineering
(3 C.H)

Mehran University of Engineering & Technology

Bachelor of Engineering (B.E), 1st Year, 2nd Semester, 2021

Muhammad Ahsan
Department of Software Engineering, MUET Jamshoro

[0]
Contents

Table of Contents

1. Introduction to Software Engineering ................................................................3-8

Overview of Software Engineering.........................................................................................
Core Principles of Software Engineering ................................................................................
Types of Practices...................................................................................................................
2. Software Evolution ................................................................................................ 9
Understanding the Software evolution and its laws ..............................................................
3. Software Paradigms ..................................................................................... 10-13
Identify Software Paradigms..................................................................................................
Importance and need of Software Engineering .....................................................................
4. Software Professional Development .......................................................................
Understanding the Software Professional Development .......................................................
Five Worlds of Software Development...................................................................................

5. Software Development Lifecycle ................................................................... 14-15

Understanding the clear concept of Software Development Lifecycle ..................................
6. Software Process Models .................................................................................... 16
Introduction and types of Software Process Models .............................................................
7. Waterfall Model ............................................................................................ 17-19
Explain waterfall methods and its pros and cons ..................................................................
8. Prototyping ................................................................................................... 20-23
Study about Prototyping models and their usage .................................................................
9. Spiral Model .................................................................................................. 24-25
Getting overview about Spiral Model ....................................................................................
10. Requirement Engineering Process ................................................................ 26-35
Overview of Requirement Engineering Process .....................................................................
Feasibility Study .....................................................................................................................
Importance of Requirements Engineering .............................................................................
11. Requirement Engineering Lifecycle .........................................................................
Understanding Requirement Engineering Lifecycle with its diagrammatic view ..................
Types of Requirements ...........................................................................................................
12. Requirement Elicitation...........................................................................................
Requirement Elicitation..................................................................................................... 31
Types and techniques of Requirement Elicitation ........................................................ 32,33
13. Software Reliability ....................................................................................... 36-37
Understanding about the Software Reliability ......................................................................

[1]
Contents

Software Failure Mechanisms ................................................................................................

Software Reliability Measure Techniques .............................................................................
14. Functional Requirements .................................................................................... 38
Understand Functional Requirements of a Software System ................................................
15. Non-Functional Requirements ............................................................................ 39
Understand Non-Functional Requirements of Software System ...........................................
16. Dataflow Diagrams .................................................................................................
Learn to construct Dataflow diagrams ..................................................................................
17. Interaction Models ..................................................................................................
Learn about Interaction Models.............................................................................................
18. Business Process Modeling Techniques ..................................................................
Learn about Business Process Modeling Techniques .............................................................
19. Flowcharts ..............................................................................................................
Learn to construct Flow Charts and their usage ....................................................................
20. Agile Software Development...................................................................................
Principles of Agile & Practices ................................................................................................
21. Agile Testing Methods ............................................................................................
Understand Agile Testing Methods........................................................................................
22. Software Requirement Specification .......................................................................
Software Requirement Specification................................................................................. 34
23. Use Case Diagrams .................................................................................................
Learn to construct Use Case Diagrams ..................................................................................
24. Sequence Diagrams ................................................................................................
Learn to construct Sequence Diagrams .................................................................................
25. Class Diagrams .......................................................................................................
Learn to construct Class Diagrams.........................................................................................
26. Software Testing & Quality Assurance .......................................................... 40-41
Understanding about the Software Testing & Quality Assurance .........................................
27. Types of Software Testing ................................................................................... 42
Understanding about the types of Software Testing, usage and its areas ............................
28. Project Management .......................................................................................... 43
Understanding about the Project Management....................................................................

[2]
Introduction to Software Engineering

Introduction:
Software Engineering is the branch of engineering associated with the development of software
product using well-defined scientific principles, methods, and procedures. The outcome of
Software Engineering is an efficient and reliable software product.
Definition of Software:
A software is a collection of instructions and data that tells a computer how to work. A product
that software professionals build and then support over the long term.

IEEE defines software engineering as:

The application of a systematic, disciplined, quantifiable, approach to the development,
operation, and maintenance of software i.e. the application of engineering to software is called
Software Engineering.

Fritz Bauer, a German computer scientist, defines software engineering as:

Software engineering is the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and work efficiently on real machines.
A Software Encompasses:
1. Instructions 2. Data structures 3. Documentations

Software Product:
A software product consists of the following
design metrics:

1. Maintenance
2. Updates
3. Requirements
4. System Analysis
5. System Design
6. Code Design
7. Code Testing
8. Deployment

There are two main types of software products:

Generic Products: Stand-alone systems that are marketed and sold to any customer who wishes
to buy them i.e. dentists appointment system.
Customized Products: Software that is commissioned by a specific customer to meet their own
requirements i.e. traffic monitoring streams.

[3]
Introduction to Software Engineering

Importance of Software:
The economies of all developed nations are dependent on software. More and more systems are
software controlled i.e. in transportation, medical, telecommunications, military, industry, and
entertainment etc. More and more individuals and society rely on software systems. Therefore,
we need to be able to produce reliable and trustworthy software systems economically and
quickly.
Cost estimation in Software Engineering Field:

Cost estimation in software engineering is typically concerned with the financial spend on the
effort to develop and test the software. This can include requirements review, maintenance,
training, managing, and buying extra equipment, servers and software. Many methods have
been developed for estimating software costs for a given project. Software costs often dominate
computer system costs. In other words, the costs of software on a PC are often greater than the
hardware cost. A software costs more to maintain than it to develop. Software engineering is
concerned with cost-effective software development.
Essential attributes for Good Software:

1. Maintainability
2. Dependency and security
3. Efficiency
4. Acceptability

Software types:

1. System Software
2. Application Software
3. Engineering/ Scientific Software
4. Embedded Software
5. Product-line Software
6. Web Apps and AI based Software

Software new categories:

• Open world computing

• Net sourcing
• Open source
• Data mining
• Grid computing
• Cognitive machines
• Software for nanotechnologies

[4]
Introduction to Software Engineering

Software Project Management:

Software Project Management have wider scope than software engineering process as it
involves communication, pre and post-delivery support etc.

Principles that guide Practice:

Software practice is a broad array of principles, concepts, methods and tools that you must
consider as software is planned and developed. Software process provides everyone with a road
map for getting to a successful destination. Practice provides you with the details you will need
to drive along the road. Where the bridges, the roadblocks, and the forks are located.
Principles Overview:

Principles that Guide Process:

Principle 1: Be agile
Principle 2: Focus on quality at every step

Principle 3: Be ready to adapt

Principle 4: Build on effective team
Principle 5: Establish mechanisms for communication and coordination
Principle 6: Manage Change

Principle 7: Access Risk

Principle 8: Create work products that provide value for others.

Principles that guide Practice:

Principle 1: “Divide and conquer”. Stated in a more technical manner, analysis and
design should always emphasize separation of concerns (SOC).
Principle 2: “Understand the use of abstraction”. At its core, an abstraction is a
simplification of some complex element of a system used to communicate meaning in a
single phrase.

[5]
Introduction to Software Engineering

Principle 3: “Strive for consistency”. A familiar context makes software easier to use.
Stick with same notation.
Principle 4: “Focus on the transfer of information”. Pay special attention to the analysis,
design, construction, and testing of interfaces which make the transfer of information.
Principle 5: “Build software that exhibits effective modularity”. Separation of concerns
(Principle # 1) establishes a philosophy for software. Modularity provides a mechanism
for realizing the philosophy (Well-defined components).

Principle 6: “Look for patterns”. Brad Appleton [Appoo] suggests that: “The goal of
patterns within the software community is to create a body of literature to help software
developers resolve recurring problems encountered throughout all of software
development”.

Principle 7: “When possible, represent the problem and its solution from a number of
different perspectives”. This will eliminate possible errors.
Principle 8: “Remember that someone will maintain the software”

Communication Principles:
Principle 1: “Listen”. Try to focus on the speaker’s words, rather than formulating your
response to those words.
Principle 2: “Prepare before you communicate”. Spend the time to understand the
problem before you meet with others.

Principle 3: “Someone should facilitate the activity”. Every communication meeting

should have a leader (a faciliatory) to keep the conversation moving in a productive
direction; (2) to mediate any conflict that does occur; and (3) to ensure that other
principles are followed.

Principle 4: “Face-to-face communication is best”. But it usually works better when some
other representation of the relevant information is present (like a drawing).
Principle 5: “Take notes and document decisions”. Someone participating in the
communication should serve as a “recorder” and write down all important points and
decisions.
Principle 6: “Strive for collaboration”. Collaboration and consensus occur when the
collective knowledge of members of the team is combined to describe product.
Principle 7: “Stay focused, modularize your discussion”. The more people involved in any
communication, the more likely that discussion will bounce from one topic to the next
(facilitator’s role).
Principle 8: “If someone is unclear, draw a picture”.

[6]
Introduction to Software Engineering

Principle 9: (a) Once you agree to something, move on; (b) If you can’t agree to
something, move on; (c) If a feature or function is unclear and cannot be clarified at the
moment, move on.

Principle 10: “Negotiation is not a contest or a game”. It works best when both parties
win. But still will need compromise from both parties.

Planning Principles:
Principle 1: Understand the scope of the project. It’s impossible to use a roadmap if you
don’t know where you’re going. Scope provides the software team with a destination.
Principle 2: Involves the customer in the planning activity. The customer defines
priorities and establishes project constraints.

Principle 3: Recognize that planning is iterative. A project plan is never engraved in

stone. As work begins, it is very likely that things will change.
Principle 4: Estimate based on what you know. The intent of estimation is to provide an
indication an indication of effort, cost and task duration, based on the team’s current
understanding of the work to be done.
Principle 5: Consider risk as you define the plan. If you have identified risks that have
high impact and high probability, contingency planning is necessary.
Principle 6: Be realistic. People don’t work 100 percent of every day. They can make
mistakes.

Principle 7: Adjust granularity as you define the plan. Granularity refers to the level of
detail that is introduced as a project plan is developed. High and low.
Principle 8: Define how you intend to ensure quality. The plan should identify how the
software team intends to ensure quality (technical review schedule, pair programming,
etc.)
Principle 9: Describe how you intend to accommodate change. Even the best planning
can be obviated by uncontrolled change. Have plans for customer requests.
Principle 10: Track the plan frequently and make adjustments as required. Software
projects fall behind schedule one day at a time. Therefore, look at the plan daily.

[7]
Introduction to Software Engineering

Software Engineering – A layered Technology

A Quality Focus:
Every organization is rest on its “commitment to quality”. The bedrock that supports software
engineering is a quality focus.

Process:
Process is the foundation layer for software engineering (Process – provides the glue that holds
the layers together). It defines a framework for a set of Key Process Areas (KPA) to effectively
manager and deliver quality software in a cost effective manner. The processes define the tasks
to be performed and the order in which they are to be performed.

Methods:
It provides the technical how-to’s for developing software. Methods encompass a broad array of
tasks that includes requirements analysis, design, program, construction, testing and support.

Tools:
Tools provide automated or semi-automated support for the process and the methods –
computer aided software engineering.

[8]
Software Evolution

Software Evolution
The process of developing a
software product using
software engineering principles
and methods is referred to as
“Software Evolution”. This
includes the initial development
of software and its maintenance
and updates, till desired
software product is developed,
which satisfies the expected
requirements. Evolution starts
from requirements gathering process. After which developers create a prototype of the intended
software and show it to the users to get their feedback at the early stage of software product
development. The users suggest changes, on which several consecutive updates and
maintenance keep on changing too. This process changes to the original software, till the
desired software is accomplished. Even after the user has desired software in hand, the
advancing technology and the changing requirements force the software product to change
accordingly. Re-creating software from scratch and go to one-on-one with requirement is not
feasible. The only feasible and economical solution is to update the existing software so that it
matches the latest requirements.

[9]
Software Paradigms

Software Paradigms
Software Paradigms refer to the methods and
steps, which are taken while designing the
software. Programming paradigm is a subset of
software design paradigm which is further a
subset of Software Development Paradigm.
Software Development Paradigm:

This paradigm is known as software engineering

paradigm where all the engineering concepts pertaining the development of software are
applied. It includes various research and requirement gathering which helps the software
product to build. It consists of:

Requirement gathering
Software design
Programming

Software Design Paradigm: This paradigm is a part of software development and includes:

Design
Maintenance
Programming

Programming Paradigm: This paradigm is related closely to programming aspect of software

development. This includes:

Coding
Testing
Integration

Need of Software Engineering

The need of software engineering arises because of higher rate of change in user requirements
and environment on which the software is working.

1. Large Software: It is easier to build a wall than to a house or building, likewise, as the
size of software becomes large, engineering has to step to give it a scientific process.

2. Scalability: If the software process were not based on scientific and engineering
concepts, it would be easier to re-create new software than to scale an existing one.

[10]
Software Paradigms

3. Cost: As hardware industry has shown its skills and huge manufacturing has lower down
the price of computer and electronic hardware. But the cost of software remains high if
proper process is not adapted.

4. Dynamics Nature: The always growing and adapting nature of software hugely depends
upon the environment in which users work. If the nature of software is always changing,
new enhancements need to be done in the existing one. This is where software
engineering plays a good role.

5. Quality Management: Better process of software development provides better and

quality software products.

Characteristics of Good Software: A software product can be judged by what it offers and how
well it can be used. This software must satisfy on the following grounds:

1. Operational
2. Transitional
3. Maintenance

Well-engineered and crafted software is expected to have the following characteristics:

Operational: This tells us how well software works in operations. It can be measured on:
Budget
Usability
Efficiency
Correctness
Functionality
Dependability
Security
Safety

[11]
Software Paradigms

Transitional: This aspect is important when the software is moved from one platform to
another:
Portability
Interoperability
Reusability
Adaptability
Maintenance: This aspect briefs about how well a software has the capabilities to maintain
itself in the ever-changing environment:
Modularity
Maintainability
Flexibility
Scalability

Summary
“Software Engineering is the branch of computer science, which uses well defined-engineering
concepts required to produce efficient, durable, scalable, in-budget and on-time software
products.”

Reduced Complexity: As developers, we spend a lot of time writing code. But we spend even
more time maintaining that code. How often do we go back find that code has become the
tangled mess that we almost can’t understand? It’s probably more often than we want to
admit! We wonder. “How did this happen? How did this code get so messy?” Well, the most
likely culprit is software complexity. Our code became so complex that it became hard to know
what it did. Now, software complexity isn’t a topic that developers are often familiar with when
they start coding. We have other things to worry about. We’re trying to learn a new
programming language or a new framework. We don’t stop and think that complexity could be
making that job harder for us. But it is doing precisely that. We’re creating code that works, but
that’s also hard to maintain and understand. That’s why we often come back and ask ourselves.

[12]
Software Paradigms

“What was I thinking!? This makes no sense”. That’s why leaning about software complexity is
important. It will help you increase the quality of your code so that these situations don’t
happen as often. And this also has the added benefit of making your code less prone to bugs.
(That’s a good thing even if debugging is a great learning tool!)

Software development is time consuming & how can we speed it up? To decrease time,
many developers and project managers measure their pace of performance in lines of code
(LOC). But is LOC really the best way to measure your speed? We don’t think so. Suppose you
wrote 2000 lines of codes on a given day but added value to functionality developed was zero
with lots of bugs. Is this good enough? It’s obvious that the day’s productivity was null. With this
in mind, a better concept for measuring the speed of development was introduced along with
the Agile manifesto in 2002. It’s called “Velocity”. What does Velocity mean when it comes to
Software Development? In agile software development is velocity described as a metric for
measuring the overall performance and productivity of the team delivering application
functionality during software development iterations (which are also called sprint). Put simple,
velocity is a team’s rate of progress. The metric is also used to evaluate team performance
based on the volume of features delivered (also known as “user stories”) within a given period.

Handling Big Projects: Minimize Software Cost:

Assemble the right team Few ways to minimize cost:
Define the Project Scope Plan, Plan and Plan!
Define deadlines and milestone Provide clear requirements
Have an approved decision making Adopt Agile
structure Utilize existing solutions
Be iterative Leverage Testing
Communicate early and often
Make meetings meaningful etc.

Reliable Software: Reliable software is the probability of failure-free software operation for a
specified period of time in a specified environment. Since reliability is one of the most important
aspects of software quality. Software Reliability Engineering (SRE) is the quantitative study of
the operational behavior of software-based systems with respect to user requirements
concerning reliability.

Effectiveness: Effectiveness is the capacity to do the right thing. For example a manual worker
is expected to be efficient. He must perform his task following the orders he was given by his
superiors. His work is judged in terms of the quantity and quality of items he is able to produce
in some unit of time. Software effectiveness means doing the objective effectively (correctly).
Efficiency can be defined as, using the resources optimally where resources could be memory,
CPU, time, files, connections, databases etc. Stressing on efficiency, during the early SDLC
phases, can eliminate lot of problems.

[13]
Software Development Life Cycle

Software Development Life Cycle (SDLC):

SDLC is the acronym of Software Development Life Cycle. It

is also called as Software Development Process. SDLC is a
framework defining tasks performed at each step in the
software development process.
SDLC Overview:

SDLC is a process followed for a software project, withing a

software organization. It consists of a detailed plan
describing how to develop, maintain, replace and alter or
enhance specific software. The life cycle defines a methodology for improving the quality of
software and the overall development process.
Graphical representation of Software Development Life Cycle:
The figure is a graphical representation of the various stages of a typical SDLC.
There are various
software
development life
cycle models defined
and designed which
are followed during
the software
development
process. These
models are also
referred as
“Software
Development
Process Models”.
Each process model
follows a series of
steps unique to its type to ensure success in the process of software development.

[14]
Software Development Life Cycle

Following are the most important and

popular SDLC models followed in the
industry:

• Waterfall Model
• Iterative Model
• Spiral Model
• V-Model
• Big Bang Model

Other related methodologies are Agile

Model, RAD Model, Development and
Prototyping Models.

[15]
Software Process Models

A software process is the set of activities and associated outcome that produce a software
product. Software engineers mostly carry out these activities.
A software process model is an abstract representation of a process that presents a description
of a process from sone particular perspective. There are many different software processes, but
all involve:

• Specifications: defining what system should do.

• Design and implementation: defining the organization of the system and implementing
the system.
• Validation: checking that it does what the customer wants.
• Evolution: changing the system in response to changing customer needs.

Factors in choosing a software Process:

Choosing the right software process
model for your project can be difficult.
If you know your requirements well, it
will be easier to select a model that
best matches your needs. You need to
keep the following factors in mind
when selecting your software process
model.

1. Project Requirements
2. Project Size
3. Project Complexity
4. Cost of Delay
5. Customer Involvement
6. Familiarity with technology
7. Project Resources

[16]
Waterfall Model

Waterfall model
The waterfall model is the classic
model or the oldest model and is
known as mother of all models.
The waterfall model was the first
process model to be introduced. It
is also referred to as a linear-
sequential 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. The waterfall model is a
breakdown of project activities into linear sequential
phases, where each phase depends on the deliverbales
of the previous one. It has following phases:
1. Requirements
2. Design
3. Implementation
4. Testing
5. Deployment
6. Maintenance
The sequential phases in Waterfall model are:

• Requirement gathering and analysis: All possible requirements of the system to be

developed are captures 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 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.

[17]
Waterfall Model

• 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 releases 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.
Note: All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the
defined set of goals are achieved for previous phase and it is signed off, so the name “Waterfall
Model”. In this model, phases do not overlap.
Waterfall Model Application:
Every software developed is different and requires a suitable SDLC approach to be followed
based on the internal and external factors. Some situations where the use of waterfall model is
most appropriate are:
Requirements are very well documented, clear and fixed.
Product definition is stable.
Technology is understood and is not dynamic.
There are no ambiguous requirements.
Ample resources with required expertise are available to support the product.
The project is short.
Advantages (SDLC):
Some of the major advantages of the Waterfall Model are as follows:
Simple and easy to understand and use.
Easy to manage due to 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.

[18]
Waterfall Model

Disadvantages (SDLC):
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.
It is difficult to measure and progress within stages.
Cannot accommodate changing requirements.
Adjusting scope during the life cycle can end a project.

[19]
Prototyping

Prototyping model:
Prototyping model is a software development model in which prototype is built, tested, and
reworked until an acceptable protoype is achieved. It also creates base to produce the final
system or software. It works best in scenarios where the projects requirements are not known in
detail. It is an iterative, trial and error method which takes place between developer and client.
Steps of Prototype Model:
1. Requirment gathering and analyst
2. Quick decision
3. Build a prototype
4. Assessment or user evaluation
5. Protype refinement
6. Engineer Product

A simulation or sample version of a final product, which is used for testing prior to launch. The
goal of a prototype is to test products (and product ideas) before sinking lots of time and money
into the final product. A prototype is a simple experimental model of a proposed solution used
to test or validate ideas, design assumptions and other aspects of its conceptualization quickly
and cheaply, so that the designers involved can make appropriate refinements or possible
changes in direction.

Following is a stepwise approach explained to design a software prototype:

• Basic Requirement Identification: This step involves understanding the very basics
products requirements especially in terms of userinterface. The more intricate details of
the internal design and external aspects like performance and security can be ignored at
this stage.

• Developing the initial Prototype: The initial prototype is developed in this stage, where
the very basic requirements are showcased and user interfaces are provided. These
features may not exactly work in the same manner internally in the actual software

[20]
Prototyping

developed. While, the workarounds are used to give same look and feel to the customer
in the prototype developed.

• Review of the Prototype: The prototype developed is then presented to the customer and
the other important stakeholders in the project. The feedback is collected in an
organized manner and used for further enhancements in the product under
development.

• Revise and Enhance the Prototype: The feedback and the review comments are discussed
during this stage and some negotatiations happen with the customer based on factors
like time and budget constraints and technical feasibility of the actual implementation.
The changes accepted are again incorporated in the new Prototype developed and the
cycle repeats until the customer expectations are met.
Look and Feel (Prototyping):

Stakeholder:
In simple words, anyone having any
type of relation/ interest in the project
is known as stakeholder. The term
Software Project Stakeholder refers to
a person, group or company that is
directly or indirectly involved in the
project and who may affect or get
affected by the outcome of the project.
What is Stakeholder Identification: It is
the process of identifying a person,
group or a company which can affect or get affected by a decision, activity or the outcome of
the software project. It is important in order to identify the exact requirements of the project
and what various stakeholders are expecting from the project outcome.

[21]
Prototyping

When to use Prototyping model:

Prototype model should be used when the
desired system needs to have a lot of
interaction with the end users. Typically,
online systems, web interfaces have a very
high amount of interaction with the end
users, are best suited for Prototype model.
It might take a while for a system to be
built that allows ease of use and needs
minimal training for the user. Prototyping
ensures that the end users constantly work
with the system and provide a feedback
which is incorporated in the prototype to
result in a useable system. They are
excellent for designing good human
computer interface systems.

Advantages of Prototyping Model:

The advantages of the Prototyping
Model are as follows:
Increased user involvement in the product even before its implementation.
Since a working model of the system is displayed, the users get a better
understanding of the system being developed.
Reduces time and cost as the defects can be detected much earlier.
Quicker user feedback is available leading to better solutions.
Missing functionality can be identified easily.
Confusing or difficult functions can be identified.
Disadvantages of Prototyping Model:
The disadvantages of the Prototyping are as follows:

Risk of insufficient requirement analysis owing to too much dependency on the

prototype.
Users may get confused in the prototypes and actual systems.
Practically, this methodology may increase the complexity of the system as scope of
the system may expand beyond original plans.
Developers may try to reuse the existing prototypes to build the actual system, even
when it is not technically feasible.
The effort invested in building prototypes may be too much if it is not monitored
properly.

[22]
Prototyping

Software Prototyping Types:

Following are the major software prototyping used widely:

• Throwaway/ Rapid Prototyping: Throwaway prototyping is also called as rapid or

close ended prototyping. This type of prototyping used very little efforts with
minimum requirement analysis to build a prototype. Once the actual requirements
are understood, the prototype is discarded, and the actual system is developed with
a much clear understanding of user requirements.

• Evolutionary Prototyping: Evolutionary prototyping also called as breadboard

prototyping is based on building actual functional prototypes with minimal
functionality in the beginning. The prototype developed forms the heart of the future
prototypes on top of which the entire system is built. By using evolutionary
prototyping, the well-understood requirements are included in the prototype and the
requirements are added as and when they are understood.

• Incremental Prototyping: Incremental Prototyping refers to building multiple

functional prototypes of the various sub-systems and then integrating all the
available prototypes to form a complete system.

• Extreme Prototyping: Extreme prototyping is used in the web development domain.

It consists of three sequential phases. First, a basic prototype with all the existing
pages is presented in the HTML format. Then the data processing is simulated using
a prototype services layer. Finally, the services are implemented and integrated to
the final prototype. This process is called Extreme Prototyping used to draw attention
to the second phase of the process, where a fully functional UI is developed with very
little regard to the actual services.

[23]
Spiral Model

Spiral Model:
The illustration is a representation of the Spiral Model, listing the activities in each phase. 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 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.

The Four Phases of Spiral Model:

The spiral model has four phases. A software project repeatedly passes through these phases in
iterations called spirals.

• Identification: The 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.

• Design: The design phase starts with the conceptual design in the baseline spiral and
involves architectural design, logical design of modules, physical product design and the
final design in the subsequent spirals.

• Construct or Build: The Construct phase refers to production of the actual software at every
spiral. In the baseline spiral, when the product is just thought of and the design is being
developed a POC (Proof of Concept) is developed in this phase to get customer feedback.
Then in the subsequent spirals with higher clarity on requirements and design details a
working model of the software called build is produced with a version number. These builds
are sent to the customer for feedback.

• Evaluation and Risk Analysis: Risk Analysis includes identifying, estimating and monitoring
the technical feasibility and management risks, such as schedule slippage and cost overrun.

[24]
Spiral Model

After testing the build, at the end of first iteration, the customer evaluates the software and
provides feedback. Based on the customer evaluation, the software development process
enters the next iteration and subsequently follows the linear approach to implement the
feedback suggested by the customer. The process of iterations along the spiral continues
throughout the life of the software.
Spiral Model Application: 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 evolution to get clarity.
New product line which should be released in phases to get enough customer feedback.
Significant changes are expected in the product during the development cycle.
Advantages of Spiral Model:
The advantages of Spiral SDLC Model are as follows:

1. Changing requirements can be accommodated.

2. Allows extensive use of prototype.
3. Requirements can be captured more accurately.
4. Users see the system early.
5. Development can be divided into smaller parts and the risky parts can be
developed earlier which helps in better risk management.
Disadvantages of Spiral Model:
The disadvantages of the Spiral Model are as follow:

1. Management is more complex.

2. End of the project may not be known.
3. Not suitable for small or low risk projects and could be expensive for small
projects.
4. Process is complex.
5. Spiral may go on indefinitely.
Large number of intermediate stages requires excessive documentation.

[25]
Requirement Engineering Process

Requirement is a condition or capability possessed by the software or system component in

order to solve a real-world problem. The problems can be to automate a part of a system, to
correct shortcomings of an existing system, to control a device, and so on.

In the software development process, requirement phase is the first software engineering
activity. This phase is a user-dominated phase and translates the ideas or views into a
requirements document.
Note that defining and documenting the user requirements in a concise and unambiguous
manner is the first major step to achieve a high-quality product.

Requirement Engineering
Requirements Engineering (RE) refers to the process of defining, documenting, and maintaining
requirements in the engineering design process. It provides the appropriate mechanism to
understand what the customer desires, analyzing the needs, and assessing feasibility,
negotiating a reasonable solution, specifying the solution clearly, validating the specifications
and managing the requirements as they are transformed into a working system. Thus,
requirement engineering is the disciplined application of proven principles, methods, tools, and
notation to describe a proposed system’s intended behavior and its associated constraints.
The software requirements are description of features and functionalities of the target system.
Requirements convey the expectations of users from the software product. The requirements
can be obvious or hidden, known or unknown, expected or unexpected from client’s point of
view. The process to gather the software requirements from client, analyze and document them
is known as requirement engineering.
The goal of requirement engineering is to develop and maintain sophisticated and descriptive
System Requirements Specification document.
Example: A Door? What requirements might this system have? How do we phrase them clearly?
What did we under specify? What did we over specify?
Poor requirement management can be the reason behind your project failure.
Requirements engineering activities act as a backbone of software development. The more
efforts devoted during requirements engineering activities guarantee a better software product.
The core concept is to develop a quality product, on time within budget is about capturing
appropriate requirements. The product failure mostly depends on, either by missing important
requirements or capturing irrelevant requirements.
Requirements are categorized logically as:

• Must Have: Software cannot be said operational without them.

• Should have: Enhancing the functionality of software.
• Could have: Software can still properly function with these requirements.

[26]
Requirement Engineering Process

• Wish list: These requirements do not map to any objectives of software.

While developing software, ‘must have’ must be implemented, ‘should have’ is a matter of
debate with stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for
software updates.

Features vs Functionality: How to accurately compare software systems

If you are in a market for boarding management software, it is important that you don’t just
dive into the first one you see or commit to a software product just because it boasts your
checklist of features. When it comes to school software, making the wrong decision can be a
very costly mistake. Not only would you have lost a lot of time, money and resources
implementing the wrong system, but you’d also have to go through the long budget and board
process again to switch systems. Needless to say, the costs involved can be quite significant, but
the thing is that this is 100% available. How? By properly comparing the different systems and
choosing the one that best fits your need.
The problem with checking features:
Relying on a checklist of features is like looking at a car, seeing that it has 4 wheels, an engine,
electric windows, and a bunch of other cool features, and purchasing it without taking it for a
proper test drive. It looks good on paper but when you actually drive the car you might notice
that the electric windows don’t work, the body kit is made of cheap plastic or even worse,
there’s a major engine fault.
Checklists can give you a false impression of a product’s functionality/ caption. The same
principle applies to software. While some software providers will deliver high quality features
that offer a lot of value, others may cut corners and only provide minimal functionality just so
they can check boxes. So, it’s important to remember that just because a product checks all the
boxes on paper, it doesn’t mean that it’s going to work well in practice. To avoid any costly
mistakes, make sure you take it for a test drive and check if those features are actually
Functional.
When you start to think about functionality, you will be able to gain a better understanding of
what the system can actually do instead of what it says it can do. This will put you in a better
position to decide which system will be able to provide you with the most value.

Why to use an SRS Document?

A software requirements specification is the basis for your entire project. It lays the framework
that every team involved in development will follow. It is used to provide critical information to
multiple teams such as development, quality assurance, operations, and maintenance. This
keeps everyone on the same page. Using the SRS helps to ensure requirements are fulfilled, and
it can also help you make decisions about your product’s lifecycle for instance, when to retire a
feature. Writing an SRS can also minimize overall development time and costs.

[27]
Requirement Engineering Process

Prerequisite of Software Requirements

A complete Software Requirements Specifications should be:

• Clear • Verifiable
• Correct • Prioritized
• Consistent • Unambiguous
• Coherent • Traceable
• Comprehensible • Credible source
• Modifiable

Characteristics of Effective Software Requirements and Software Requirements

Specifications (SRS)
How can we distinguish excellent software requirements specifications (SRS) from those that
could cause problems? We will start by discussing several different characteristics that
individual requirements should exhibit. We will then look at the desirable traits a successful SRS
should have as a whole.

Characteristics of Effective Requirements

In an ideal world, every individual user, business, and functional requirement would exhibit the
qualities which are:
1. Complete
Each requirement must fully describe the functionality to be delivered. It must contain all the
information necessary for the developer to design and implement that bit of functionality. If you
know you are lacking certain information, use TBD (to be determined) as a standard flag to
highlight these gaps. Resolve all TBDs in each portion of the requirements before you proceed
with construction of that portion.
2. Unambiguous
All readers of a requirement statement should arrive at a single, consistent interpretation of it,
but natural language is highly prone to ambiguity. Write requirements in simple, concise,
straightforward language appropriate to the user domain “Comprehensible” is a requirement
quality goal related to “unambiguous” readers must be able to understand what each
requirement is saying. Define all specialized terms and those that might confuse readers in a
glossary.
3. Prioritized
Assign an implementation priority to each functional requirement, feature, use case, or user
story to indicate how essential it is to a particular product release. If all the requirements are
considered equally important, it is hard for the project manager to respond to budget cuts,
schedule overruns, personnel losses, or new requirements added during development.
Prioritization is an essential key to successful iterative development.

[28]
Requirement Engineering Process

4. Verifiable
See whether you can devise a few tests or use other verification approaches, such as inspection
or demonstration, to determine whether the product properly implements each requirement. If
a requirement isn’t verifiable, determining whether it was correctly implemented becomes a
matter of opinion, not objective analysis. Requirements that are incomplete, inconsistent,
infeasible, or ambiguous are also unverifiable.
5. Complete
No requirements or necessary information should be absent. Missing requirements are hard to
spot because they aren’t there! Focusing on other user tasks, rather than on system functions,
can help you to prevent incompleteness.
6. Consistent
Consistent software requirements don’t conflict with other requirements of the same type or
with higher-level business, system, or user requirements. Disagreements between requirements
must be resolved before development can proceed. If you spot a pair of conflicting
requirements, you might not know which one (if either) is correct until you do some research.
Recording the originator of each requirement lets you know who to talk to if you discover
conflicts in your software requirements specification.
7. Modifiable
You must be able to revise the SRS when necessary and maintain a history of changes made to
each requirement. This dictates that each requirement be uniquely labeled and expressed
separately from other requirements so that you can refer to it unambiguously. Each requirement
should appear only once in the SRS. It is easy to generate inconsistencies by changing only one
instance of a duplicated requirement. Consider cross-referencing subsequent instances back to
the original statement instead of duplicating the requirement. A table of contents and an index
will make the SRS easier to modify. Storing requirements in a database or a commercial
requirements management solution makes them into reusable objects.
How do you know if your requirements and SRS exhibit these attributes?
The best way to tell whether your requirements have these desired attributes is to have several
project stakeholders carefully review the SRS. Different stakeholders will spot different kinds of
problems. For example, analysts and developers can’t accurately judge completeness or
correctness, whereas users can’t assess technical feasibility.
You will never create an SRS in which all requirements demonstrate all these ideal attributes.
However, if you keep these characteristics in mind while you write and review the requirements,
you will produce better requirements documents and you will build better products.

Feasibility Study
Feasibility describes how easy or difficult it is to do something. The possibility that can be made,
done, or achieved, or is reasonable. When you set a goal at work, think about the long-term
feasibility of accomplishing what you want.

[29]
Requirement Engineering Process

Technical Feasibility involves development of a working model of the product or service. It is not
necessary that the initial materials and components of the working model represent those that
actually will be used in the finished product or service. The purpose of the working model is to
demonstrate, to your own satisfaction, that the product or service is functional and producible.
It also provides a visual means to share your concept with others.
Types of Feasibility Studies
There are 5 types of feasibility studies:

1. Legal Feasibility:
Performed to understand if the proposed plan conforms the legal and ethical
requirements.

2. Economic Feasibility:
Involves a cost benefits analysis to identify how well, or how poorly, a project will be
concluded.

3. Technical Feasibility:
Process of validating the technical resources and capabilities to convert the ideas into
working systems.

4. Operational Feasibility:
Performed to understand well a proposed system solves the problem.

5. Scheduling Feasibility:
Measure of how reasonable the project duration is.

[30]
Requirement Engineering Process

Requirement Engineering Process

It is a four-step process, which includes:

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirements Validation

1. Feasibility Study

The objective behind the feasibility study is

to create the reasons for developing the
software that is acceptable to users, flexible
to change and conformable to established
standards.
Types of Feasibility:

• Technical Feasibility: Technical feasibly evaluates the current technologies, which are
needed to accomplish customer requirements within the time and budget.

• Operational Feasibility: Operational feasibility assesses the range in which the required
software performs a series of levels to solve business problems and customer
requirements.

• Economic Feasibility: Economic feasibility decides whether the necessary software can
generate financial profits for an organization.

2. Requirements Elicitation and Analysis

This is also known as the gathering of

requirements. Here, requirements are
identified with the help of customers and
existing systems processes, if available.
Analysis of requirements starts with
requirement elicitation. The requirements
are analyzed to identify inconsistences,
defects, omission etc. We describe
requirements in terms of relationships and
also resolve conflicts if any.

[31]
Requirement Engineering Process

Problems of Elicitation and Analysis:

• Getting all, and only, the right people involved.
• Stakeholders often don’t know what they want.
• Stakeholder’s express requirements in their terms.
• Stakeholders may have conflicting requirements.
• Requirements change during the analysis process.
• Organizational and political factors may influence system requirements.

Requirement’s elicitation in a nutshell

Requirement’s elicitation is the practices of researching and discovering the requirements of a
system from users, customers, and other stakeholders.

Typically, the elicitation process is divided into the following states:

• Prepare for elicitation – Defining the desired outcomes, collecting documentation,

analyzing stakeholder roles, and choosing the right elicitation techniques.

• Elicit requirements – Drawing out, exploring, and identifying information required to

analyze, model, and specify requirements. Requirement’s elicitation isn’t a ‘phase’, it is
rather an ongoing activity that is conducted throughout different development stages
including discovery, modeling, and quality assurance.

• Confirm elicitation result- Checking whether the information gathered during an

elicitation session is accurate and consistent and meets the stakeholder’s expectations.
You start to work on requirements on the initial stages of collaboration. First, you need to agree
upon them and put them all together.
The role of stakeholders in requirements elicitation
The way to what extent your team is involved in the elaboration of the requirements is also of a
huge importance. It is much more efficient to include the team in this process, because all the
questions asked, and ideas offered to make it possible to write high quality requirements for the
software product. We should pay enough attention to requirements, discussing obvious things
sometimes that some people may see differently though.
How detailed requirements should be?
Another important point is how detailed requirements should be. Every project is unique, and
we try to apply an individual approach to them based on their peculiarities. However, the
practice proves that the more detailed the requirements are the more precise the estimate is
and there are more chances to meet it. We try to be detailed when putting together the
requirements and means of their implementation thus mitigating the possible risks. This
approach also provides an opportunity to see the possible mistakes before the development
stage saving time and money. Experience teaches that the availability of detailed requirements

[32]
Requirement Engineering Process

helps the team to estimate more accurately the time that will be spent on the implementation
of certain features and in addition you will get the estimate which the team is responsible for.
Requirements Elicitation Process
• Requirement gathering: The developer discuss with the client and end user users and
know their expectations from the software.

• Organizing Requirements: The developers prioritize and arrange the requirements in

order of importance, urgency, and convenience.

• Negotiation & discussion: If requirements are ambiguous or there are some conflicts in
requirements of various stakeholders, if they are, it is then negotiated and discussed
with stakeholders. Requirements may then be prioritized and reasonably compromised.

• The requirements come from various stakeholders. To remove the ambiguity and
conflicts, they are discussed for clarity and correctness. Unrealistic requirements are
compromised reasonably.

• Documentation: All formal & informal, functional, and non-functional requirements are
documented and made available for next phase processing.

Requirements Elicitation Techniques

Requirements Elicitation is the process to find out the requirements for an intended software
system by communicating with client, end users, system users and others who have a stake in
the software system development.
There are various ways to discover requirements.

• Interviews
• Surveys
• Questionnaires
• Task analysis
• Domain Analysis
• Brainstorming
• Prototyping
• Observation

[33]
Requirement Engineering Process

3. Software Requirement Specification

Software Requirement Specification is a kind of document which is created by a software
analyst after the requirements collected from the various sources. The requirement received by
the customer written in ordinary language. It is the job of the analyst to write the requirement
in technical language so that they can be understood and beneficial by the development team.
The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.

• Data Flow Diagrams:

Data flow Diagram (DFDs) are widely used for modeling the requirements. DFDs shows the
flow of data through a system. The system may be a company, or an organization, a set of
procedures, a computer hardware system, a software system, or any combination of the
preceding. The DFD is also known as a data flow graph or bubble chart.

• Data Dictionaries:
Data dictionaries are simply repositories to store information about all the data items
defined in DFDs. At the requirements stage, the data dictionary should at least define
customer data items, to ensure that the customer and developers use the same definition
and terminologies.

• Entity-Relationship Diagrams:
Another tool for requirement specification is the entry-relationship diagram, often called an
“E-R diagram”. It is a detailed logical representation of the data for the organization and
uses three main constructs i.e. data entities, relationships, and their associated attributes.

4. Software Requirement Validation

After requirement specifications developed, the requirements discussed in this document are
validated. The user might demand illegal, impossible solution or experts may misinterpret the
needs. Requirements can be checked against the following conditions:
✓ If they can be practically implemented
✓ If they are valid and as per functionality and domain of software.
✓ If there are any ambiguities
✓ If they are complete
✓ If they can be demonstrated.

Requirements Validation Techniques

• Requirement revies/ inspections: systematic manual analysis of the requirements.
• Prototyping: Using an executable model of the system to check requirements.
• Test-case generation: Developing tests for requirements to check testability
• Automated consistency analysis: Checking for the consistency of structured
requirements descriptions.

[34]
Requirement Engineering Process

Conclusion
The requirements are crucial when starting a project if you want to achieve a desirable result at
the finish line. They should include all the features and functions a product should have.
Requirements should be comprehensible for all interested parties (customer, product owner,
development team) and be free of any ambiguities (all the stakeholders should understand
requirements in the same say).
So why exactly are the requirements so important?
Good, detailed requirements are the critical keys to project success. They allow us and the client
to:

• Get a deeper understanding of the future product.

• Reveal hidden and assumed requirements
• Clearly define deliverables and build only relevant functionality
• Lay out predictable project timelines so we can plan accordingly.

[35]
Software Reliability

Overview of Hardware and Software Failures

Software Failure:
Software failures may be due to bugs, ambiguities, oversights or misinterpretation of the
specification that the software is supposed to satisfy, carelessness or incompetence in writing
code, inadequate testing, incorrect or unexpected usage of the software or other unforeseen
problems. Software faults are design faults, which are tough to visualize, classify, detect, and
correct.
Hardware Failure:
Hardware faults are mostly physical faults. Hardware components generally fail due to wear
and tear. In hardware, design faults may also exist, but physical faults generally dominate.

Failure Curve for Hardware: It is called the bathtub curve. Period A, B and C stand for burn-in
phase, useful life phase, and end-of-life phase respectively.

Failure Curve for Software: A possible curve is

shown in the following figure.

[36]
Software Reliability

Differences in Figure (a) and Figure (b):

The two significant differences between the hardware and software curves are:

• One difference is that in the last stage, the hardware does not have an increasing failure
rate as hardware does. In this phase, the software is approaching obsolescence; there
are no motivations for any upgrades or changes to the software. Therefore, the failure
rate will not change.

• The second difference is that in the useful-life phase, the software will experience a
radical increase in failure rate each time an upgrade is made. The failure rate levels off
gradually, partly because of the defects create and fixed after the updates.

[37]
Functional Requirements

Types of Requirements
Largely software requirements must be categorized into two categories:

1. Functional Requirements
Definition:
Requirements, which are related to functional aspect of software fall into this category.
They define functions and functionality within and from the software system.

Examples:
Search option given to user to search from various invoices.
User should be able to mail any report to management.
Users can be divided into groups and groups can be given separate rights.
Should comply business rules and administrative functions.
Software is developed keeping downward compatibility intact.
Functional requirements define a function that a system or system element must be qualified to
perform and must be documented in different forms. The functional requirements are describing
the behavior of the system as it correlates to the system’s functionality.

Functional requirements are the product features or its functions that must be designed directly
for the users and their convenience. They define the functionality of the software, which the
software engineers have to develop so that the users could easily perform their tasks up to the
business requirements.

[38]
Non-Functional Requirements

2. Non-Functional Requirements
Definition:
Requirements, which are not related to functional aspect of software, fall into this
category. They are implicit or expected characteristics of software, which users make
assumption of.
Non-functional requirements include:

Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
Disaster recovery
Accessibility

This can be the necessities that specify the criteria that can be used to decide the operation
instead of specific behaviors of the system. Non-functional requirements are divided into two
main categories:

• Execution qualities – like security and usability, which are observable at run time.

• Evolution qualities – like testability, maintainability, extensibility, and scalability that

embodied in the static structure of the software system.
Non-functional requirements are the quality attributes, certain design or realization constraints
or external interface that directly relate to the product. They act as additional description of the
functions of the product under development, which are important for stakeholders (users or
developers). For example, it may be the ease of use or movement, integrity, efficiency, and fault
tolerance.

[39]
Software Testing & Quality Assurance

Uncompromising Quality
Software products are everywhere today, and tomorrow is being built on technologies as yet
unimagined. That means every enterprise, whether they sell cars or services, must have a full-
fledged software development operation catering to the needs of the present and the future.
This is taxing on even the most robust, high-functioning teams. Without the care and attention
that innovation and high-quality production require, the results can be catastrophic.

What is Software Testing?

Software testing is the process of evaluating and verifying that a software product or
application does what it is supposed to do. A test management plan helps to prioritize which
types of testing provide the most value given available time and resources. Testing effectiveness
is optimized by running the fewest number of tests to find the largest number of detects.

Benefits of Software Testing

The benefits of testing include:

Preventing bugs,
Reducing development costs (costs-effective)
Customer satisfaction
Improving performance (product quality)

The Box Approach

Software testing methods are traditionally divided into white and black-box testing. These two
approaches are used to describe the point of view that the tester takes when designing the test
cases. A hybrid approach called grey-box testing may also be applied to software testing
methodology.

White-Box Testing
White-box testing verifies the internal structures or workings of a program, as supposed to the
functionality exposed to the end-user. In white-box testing, an internal perspective of the system
(the source code), as well as programming skills, are used to design test cases. The tester
chooses inputs to exercise paths through the code and determine the appropriate outputs. This
is analogous to testing nodes in a circuit, i.e. in circuit testing (ICT).

White-box testing is also known as clear box testing, glass box testing, transparent box
testing, and structural testing.

[40]
Software Testing & Quality Assurance

Black-Box Testing
Black box testing also known as functional testing treats the software as a “black box”
examining functionality without any knowledge of internal implementation, without seeing the
source code. The testers are only aware of what the software is supposed to do, not how it does
it. Test cases are built around specifications and requirements, I.e., what the application is
supposed to do. One advantage of the black box technique is that no programming knowledge
is required. This method of test can be applied to all levels of software testing: unit, integration,
system, and acceptance. It typically comprises most if not all testing at higher levels but can also
dominate unit testing as well.

[41]
Types of Software Testing

Types of Software Testing

There are many different types of software tests, each with specific objectives and strategies:

Acceptance testing
Integration Testing
Unit Testing
Functional Testing
Performance testing
Regression testing
Stress testing
Usability testing

Acceptance testing:
Verifying whether the whole system works as intended.
Integration testing:
Ensuring that software components or functions operate together.
Unit testing:
Validating that each software unit performs as expected. A unit is the smallest testable
component of an application.
Functional testing:
Checking functions by emulating business scenarios, based on functional requirements. Black-
box testing is common way to verify functions.
Performance testing:
Testing how the software performs under different workloads. Load testing, for example is used
to evaluate performance under real-life load conditions.
Regression testing:
Checking whether new features break or degrade functionality. Sanity testing can be used to
verify menus, functions, and commands at the surface level, when there is no time for a full
regression test.
Stress testing:
Testing how much strain the system can take before it fails. Considered to be a type of non-
functional testing.
Usability testing:
Validating how well a customer can use a system or web application to complete a task.

[42]
Project Management

Project Management
Project management is the process of leading the work of a team to achieve all project goals
within the given constraints. This information is usually described in project documentation,
created at the beginning of the development process. The primary constraints are scope, time,
and budget.

Purpose of Project Management

The purpose of project management is to foresee or predict as many dangers and problems as
possible, and to plan, organize and control activities. So that the project is completed as
successfully as possible in spite of all the risks.

5 Phases of Project Management

1. Project Initiation
2. Project Planning
3. Project Execution
4. Project Monitoring and Controlling
5. Project Closing
Project managers or the organization can divide projects into above phases to provide better
management control with appropriate links to the ongoing operations of the performing
organization. Collectively, these phases are known as the project life cycle.
Project managers deliver projects while balancing the following constraints:

• Scope
• Schedule
• Quality
• Resources
• Customer Satisfaction
• Risk

These all are so intertwined that a change in one will most often cause a change in at least one
of the others.
For example:

• If time is extended, the cost of the project will increase.

• If time extended with the same cost, then quality of the product will reduce.
• If scope is extended, then cost and time will also extend.

Changes to any of these legs sets off a series of activities that are needed to integrate the
change across the project.

[43]