CSC 403: SOFTWARE ENGINEERING

OUTLINE
• Introduction
• Software Processes and Software Process Models
• Software Design
• Object Oriented Analysis and Design
• Software Architecture
• Design Patterns
• Design for Re-use
• Software tools and environment
• Requirement Analysis tools
• Design Modelling tools
• Testing tools
• Using API
• API programming class
• Component based computing
 Introduction

What is a Software?

What is Software Engineering?

Introduction
What is a Software?
• Computer and computer-based (e.g. tablet, mobile) programs and their
associated documentations and configuration are called Software
• Software is considered to be a collection of executable programming code,
associated libraries and documentations.
• Software refers to a collection of programs, instructions, and data that
enable a computer system to perform specific tasks or functions. It
encompasses all the intangible components of a computer system, including
the programs, applications, operating systems, and utilities that enable the
hardware to function and perform desired operations.
• Software is not just programs themselves but also all associated
documentation, libraries, support for various platforms, configuration and
even customer service.
Introduction
• Software has a dual role:
Software is a product: it produces, manages, modifies and transmits information.
Software is a vehicle for delivering a product: it controls other programs.
• Some features of Software include:
Software does not wear out (i.e. does not expire)
Software costs more to maintain than it does to develop
Software does not fail
There is no universally agreed standard to develop and maintain a software
• Essential attributes of a good Software
 Maintainability
 Dependability and Security
 Efficiency
 Acceptability
Other attributes may include:
 Reusability
 Distributability
 Portability
 Inter-operability
Introduction
What is Software Engineering?

• Software Engineering is composed of two words:

SOFTWARE and ENGINEERING
• Engineering is all about developing products, using well-defined, scientific
principles and methods.
• So, we can define software engineering as an engineering branch associated with
the development of software product using well-defined scientific principles, methods
and procedures. The outcome of which is an efficient and reliable software product.
• Software engineering is a discipline that involves the systematic approach to the design,
development, testing, and maintenance of software systems. It combines principles from
computer science, mathematics, and engineering to create reliable, efficient, and high-
quality software.
• Software engineering aims to apply engineering principles and methodologies to software
development, treating it as an engineering process rather than an ad hoc activity
• Software Engineering is a discipline that covers all aspects of software production from
early stages of system specification to maintaining the system after its use.
• Software Engineering presents a disciplined and a practical approach to design,
development and maintenance of software.
Why Software Engineering is needed?
Why Software Engineering is needed?
The need of software engineering arises because of higher rate of
change in user requirements and environment on which the software is
working.
• Large Software
• Scalability
• Cost
• Dynamic Nature
• Quality Management
 Software Process Model
• A software process is a set of related activities that lead to the production of a software product.
There are four generic software processes :
• Specification-what the system should do and its development constraints.
• Development-production of the software system.
• Validation-checking that the software is what the customer wants.
• Evolution-changing the software in response to changing demands.

• It is a simplified representation of a software process, presented from a specific perspective.

The perspectives include:
• Workflow perspective -sequence of activities
• Data-flow perspective -information flow
• Role/action perspective-who does what
 Software Process Model
• Software Process Model is a set of activities specifically focussed on the development and
evolution of software.
• A process model is roughly an anticipation of what the process will look like.
• There are two types of Software Process Model: Generic and Iterative Process Models

GENERIC PROCESS MODELS INCLUDE:

• Waterfall
• Evolutionary Development
• Re-use Oriented Development
 Software Process Model
WATERFALL:
• This takes the processes of specification, development, validation, and evolution and represents
them as separate process phases such as requirements specification, software design,
implementation, testing, and so on.
• This model got its name because of the cascade from one phase to another.
• It is a plan-driven process.
• The main drawback of the waterfall model is the difficulty of accommodating change after the
process is underway.
• Others include: Inflexibility and difficulty in responding to changing customer requirements.
• It is appropriate when the requirements are well understood.
 Software Process Model
EVOLUTIONARY DEVELOPMENT
• This approach interleaves rather than separates the activities of specification, development, and
validation.
• There is a rapid feedback across the activities.
• The system is developed as a series of versions (increments), with each version adding functionality to
the previous version.
• Objective is to work with customers and to evolve a final system from an initial set of specification
(either precise or poorly written)
• It is flexible compared to waterfall model but has the drawback of often being poorly structured and
requires special skills.
 Software Process Model
RE-USE ORIENTED SOFTWARE ENGINEERING

• This approach is based on the existence of a significant number of reusable components. The system
development process focuses on integrating these components into a system rather than developing
them from scratch.
• Reuse-oriented approaches rely on a large base of reusable software components and an integrating
framework for the composition of these components.
• Systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems.
 Software Process Model
ITERATIVE PROCESS MODEL
• System requirements change as the business evolves and the system responds to external pressures.
• Management priorities change. As new technologies become available, design and implementation
change.
• Iterative development is fundamental to software and there are two important process models that
are explicitly designed for this purpose :

 Incremental development
 Spiral development
 Software Process Model
INCREMENTAL DEVELOPMENT
• Rather than deliver the system as a single delivery, the development and delivery is broken down
into increments
• Each increment delivers a different part of the required functionality
• User requirements are prioritised and the highest priority requirements are included in early
increments
• Once the development of an increment is started, the requirements are frozen.
 Software Process Model
ADVANTAGES OF INCREMENTAL DEVELOPMENT

• Customer value can be delivered with each increment so system functionality is available earlier
• Early increments act as a prototype to define requirements for later increments
• Lower risk of overall project failure
• The highest priority system services tend to receive the most testing
 Software Process Model
SPIRAL DEVELOPMENT
• Process is represented as a spiral rather than as a sequence of activities with backtracking
• Each loop in the spiral represents a phase in the process.
• No fixed phases such as specification or design -loops in the spiral are chosen depending on what
is required
• Risks are explicitly assessed and resolved throughout the process
 Software Specification
• The process of establishing what services are required and the constraints on the system’s operation
and development is called Software specification or Software Requirement Specification.
• Requirements are a description of what the system should do.
• Just like the traditional software engineering, the process begins with understanding and
documenting the requirements of the system. This includes identifying the functionalities,
constraints, and desired behaviour of the software. The process of identifying, analysing,
and detailing these functionalities and constraints is called requirement engineering.
• A requirement can be a high-level, abstract statement of a service that a system should
provide (user requirement) or a detailed, formal definition of a system function (system
requirement).
• System requirements are often classified into Functional requirements and Non-functional
requirements.
 Software Specification
• Functional Requirements: These are statements of services the system should provide,
how the system should react to particular inputs, and how the system should behave in
particular situations.
• Non-Functional Requirements: These are constraints on the services or functions provided
by the system.

At the end of requirement engineering a document called SOFTWARE REQUIREMENT

SPECIFICATION is generated.
SRS or Software Requirement document is an official statement of what the developers
should implement.
 Software Specification
• Requirement engineering involves Feasibility study and Requirement analysis and
validation.
• Feasibility study: in this study an estimate is made of whether the identified user needs may be satisfied using
current software and hardware technologies. The study considers whether the proposed system will be cost-effective
from a business point of view and if it can be developed within existing budgetary constraints. A feasibility study
should be relatively cheap and quick. The result should inform the decision of whether or not to go ahead with a more
detailed analysis.
• Requirement Analysis: This is the process of deriving the system requirements through observation of existing
systems, discussions with potential users and procurers, task analysis, and so on. This may involve the development
of one or more system models and prototypes. These help you understand the system to be specified.
• Requirement Validation: This activity checks the requirements for realism, consistency, and completeness. During
this process, errors in the requirements document are inevitably discovered. It must then be modified to correct these
problems
 Object-Oriented Analysis and Design
Object-oriented analysis and design (OOAD) is an approach to software development that focuses on modelling
a system as a collection of interacting objects. It emphasizes the use of object-oriented concepts to design
reusable and maintainable software systems.
Object-Oriented Analysis and Design involves the following steps:
 Requirements Engineering
 Analysis and Design
 Design Pattern and Principles
 Implementation
 Testing
 Analysis and Design
• Analysis and Design phase is the path between requirements and implementation.
• In analysis phase, the requirements are analysed to identify the key objects in the
system.
• While Design is the process of developing abstract model of the system.
• Design is now almost always base on UML
• Five UML diagrams are represent the essentials of a system. They include:

i. Activity diagrams, which show the activities involved in a process or in data processing.
ii. Use case diagrams, which show the interactions between a system and its environment.
iii. Sequence diagrams, which show interactions between actors and the system and between system
components.
iv. Class diagrams, which show the object classes in the system and the associations between these
classes.
v. State diagrams, which show how the system reacts to internal and external events.
 Analysis and Design
Use Case Diagram
• A use case is a methodology used in system analysis to identify, clarify, and organize system
requirements.
• Use case diagram or model represents the different ways in which a system can be used by the
users.
• Use case is used to support requirements elicitation.
• The main purpose of use-case diagrams is to capture the software’s functional requirement
• Each use case represent a task that involves external interaction with the system.
• The use cases do not mention any specific algorithm to be used or the internal data representation,
internal structure of the software
 Analysis and Design

Components used in creating Use Case Diagram include:

The boundary, which defines the system of interest in relation to the world around it.

The actors, usually individuals involved with the system defined according to their roles.

The use cases, which are the specific roles played by the actors within and around the system.

The relationships between and among the actors and the use cases
 Analysis and Design

Example of Use Case Diagram

Patient Management System
 Analysis and Design
SEQUENCE DIAGRAM

• The sequence diagram is used primarily to show the interactions between system components and
actors as well as interactions among system components.
• The interactions in these diagrams have an order and thus they are called sequence diagrams.
• One of the primary uses of sequence diagrams is in the transition from requirements expressed as
use cases to the next and more formal level of refinement.
• Use cases are often refined into one or more sequence diagrams
• There could be multiple objects and components in a sequence diagram. However, each sequence
diagram contains usually one actor.
 Analysis and Design
ACTOR AND OBJECTS

• The actors and the objects are the integral part of sequence diagrams.
• While the actor represents a user of the system, the objects represent a specific component of the
system itself.
• The dashed lines under the objects represents the timeline of the object. The Actor and the objects
can have “active” and “non-active” states.
• During the active state, the actor/object is interacting with other objects. During the non-active
state, the actor/object is not needed.
• By looking at the timeline of objects, it is possible to say which objects are frequently interacting
with the system.
Analysis and Design
 Analysis and Design
ACTIVATION
• The activation displays the “active” and “non-active” state of objects.
• The activation is represented as a vertical bar.
• An object and an actor can have “alive” and “non-alive” states.
• The activation depends on how much interaction happens with the system
 Analysis and Design
MESSAGES
• Messages are written with horizontal arrows with the message name written above/on them.
• Messages display interactions on a sequence diagram.
• There are four types of messages in a Sequence Diagram.
 Analysis and Design
MESSAGES
• Solid arrow heads represent synchronous messages, open arrow heads represent asynchronous
messages, dashed lines represent reply messages and half-rectangular lines represents self
messages.
• If a caller sends a synchronous message, it must wait until the message is done, such as invoking a
method.

• If a caller sends an asynchronous message, it can continue processing and doesn’t have to wait for
a response.
 Analysis and Design

• Reply or return messages are the answers given to synchronous messages. All reply messages
are asynchronous and does not have to wait for a reply as they are the reply themselves.

• Self messages are generally used for validation or self respond. While these messages are generally
used for error handling, they are also used to show response for a specific operation, or when
results from an operation are computed and returned.
 Analysis and Design

Fragments

• There are three types of fragments in sequence diagrams:

• Alternative fragment (used for if…else conditions)
• Loop fragment (user for for, while, for each loop)
• Optional fragment (used for limitations)
 Analysis and Design
Alternative Fragment
• Alternative Fragment is used when validity and invalidity of a scenario is evaluated. The entire
sequence is covered with this fragment to show there is a verification operation.
• Usually this verification is a complicated procedure that leads to different outcomes rather than a
simple error check.
• Alternative fragments should be used when circumstances of an action would lead to different
outcomes. Otherwise, simple error messages can also be displayed by self messages.
Alternative Fragment Example
 Analysis and Design
Examples of Sequence Diagram
 Analysis and Design
Examples of Sequence Diagram
 Analysis and Design

Difference between Use-Case and Sequence Diagrams

• Unlike Use-case diagrams, Sequence Diagrams can be used for error handling (such as for
validation).
• Sequence diagrams show the order of interactions whereas the use-case do not.
• Sequence diagrams are generally created for developers whereas use-cases usually made for
Stakeholders to explain how the system would work.
 Analysis and Design
CLASS DIAGRAM

• A class diagram describes the static structure of a system

• It shows how a system is structured rather than how it behaves.
• The static structure of a system comprises of a number of class diagrams and their
dependencies.
• The main constituents of a class diagram are classes and their relationships:
generalization, aggregation, association, and various kinds of dependencies
SOFTWARE DESIGN STRATEGIES

Software design is a process that conceptualize the software requirements into software
implementation.
There are multiple variants of software design. They include:
• Structured Design
Structured design is a conceptualization of problem into several well-organized
elements of solution. It is basically concerned with the solution design. Benefit of structured
design is, it gives better understanding of how the problem is being solved. Structured
design also makes it simpler for designer to concentrate on the problem more accurately
• Function-oriented Design
In function-oriented design, the system is comprised of many smaller sub-systems
known as functions. These functions are capable of performing significant task in the
system. The system is considered as top view of all functions
SOFTWARE DESIGN STRATEGIES

• Object-Oriented Design: is a method for designing systems using self-contained objects and
object classes which allow the system to be formed of standalone objects and maintainable.
 SOFTWARE DESIGN STRATEGIES
CHARACTERISTICS OF OOD
• Objects are abstractions of real-world or system entities and manage themselves;
• Objects are independent and encapsulate state and representation information;
• System functionality is expressed in terms of object behaviour;
• Objects may be distributed and may execute sequentially or in parallel.

ADVANTAGES OF OOD
• Maintenance: Objects are stand-alone entities and reusable entities.
• Concurrent execution :Objects can be executed in sequence or in parallel(also called multi-
tasking)
• Realism: There is an obvious mapping from real world entities to system objects (every real
entity can be an object).
 SOFTWARE ARCHITECTURE
• Software Architecture defines what connects what is required with how it should be done in a
software project. In a sense, software architecture is not so much different than the genuine
architecture.
• Architectural design is concerned with understanding how a system should be organized and
designing the overall structure of that system
• In the requirements section you defined what to do.
• In system modeling, you draw a path regarding how to reach these requirements.
• The Software Architecture ensures that you can reach those requirements within the path you
identified.
• It is the critical link between the system design and requirements engineering
• Software architecture is important because it affects the performance, robustness, and
maintainability of a system
• Deciding system architecture does not have a de facto standard way of doing it.
• To design a system architecture; you need to understand how data flows within a system.
Data-Driven modeling

• Data Driven modeling is used during System Architecture Design in order to understand
how data flows throughout the system.
• Data Driven modeling is designed using Data-Flow Diagrams also referred to as DFDs.
• The UML does not support data-flow diagrams (DFDs) as they were originally proposed
and used for modeling data processing. The reason for this is that DFDs focus on system
functions and do not recognize system objects.
 Architecture patterns
• It is a description of a system organization
• Architectural patterns are abstract description of a good practice in software engineering which has
been tested and proven to be successful.
• The architectural pattern describes which sort of organization is successful in which type of
system.
• No architectural pattern is perfect and they all have their own strengths and weaknesses.
• Hence, it is imperative to understand these strengths and weakness before selecting an architectural
pattern.
• Patterns are a means of representing, sharing and reusing knowledge.
• An architectural pattern is a stylized description of good design practice, which has been tried and
tested in different environments.
• Patterns should include information about when they are and when they are not useful.
• Patterns may be represented using tabular and graphical descriptions.
 Architecture patterns
Because of the close relationship between non-functional requirements and software architecture, the particular
architectural style and structure that you choose for a system should depend on the non-functional system
requirements:

• PERFORMANCE: If performance is a critical requirement, the architecture should be designed to

localize critical operations within a small number of components, with these components all deployed
on the same computer rather than distributed across the network. This may mean using a few relatively
large components rather than small, fine-grain components, which reduces the number of component
communications. You may also consider run-time system organizations that allow the system to be
replicated and executed on different processors.
• SECURITY: If security is a critical requirement, a layered structure for the architecture should be used,
with the most critical assets protected in the innermost layers, with a high level of security validation
applied to these layers.
• SAFETY: If safety is a critical requirement, the architecture should be designed so that safety-related
operations are all located in either a single component or in a small number of components. This reduces
the costs and problems of safety validation and makes it possible to provide related protection systems
that can safely shut down the system in the event of failure.
• AVAILABILITY: If availability is a critical requirement, the architecture should be designed to include
redundant components so that it is possible to replace and update components without stopping the
system.
• MAINTAINABILITY: If maintainability is a critical requirement, the system architecture should be
designed using fine-grain, self-contained components that may readily be changed. Producers of data
should be separated from consumers and shared data structures should be avoided.
 Architecture patterns
Block Diagrams

• The architectural patterns are represented with Simple Block Diagrams.

• Although the block diagrams have many tools, five main components are used to
demonstrate the architectural pattern of a system.
• Rectangles(Components),
• Rectangles within Rectangles(sub-components),
• Arrows (data flow or control signals)
• Ellipse or Circle(external process or functionality)
• Diamonds(Critical Decisions)
 Architecture patterns

Main architecture patterns used in Software Engineering

• Model –View –Controller

• Layered Architecture (2-tier, 3-tier and 4-tier Architecture)
• Client –Server Architecture
• Repository Architecture
• Pipe and filter Architecture
 Architecture patterns

MODEL VIEW CONTROLLER (MVC)

• Model–view–controller (MVC) is a software architectural pattern that divides a given

software application into three interconnected parts.
• It is one of the most popular software architecture patterns used.
• The MVC consists of three main parts (i.e. model, view, controller) which represent the
information from the ways that information is presented to or accepted from the user.
• MVC is used to separate presentation and interaction from the system data.
• The system is structured into three logical components that interact with one another.
• The model component manages the system data.
• The view component defines and manages how data is presented.
• The controller manages interactions and passes information to the model and the view.
When do we use MCV?

•MVC architecture is triangular: the view sends updates to the controller, the controller updates the
model, and the view gets updated directly from the model.
• ALL COMPONENTS CAN INTERACT WITH EACH OTHER
• It is especially useful when there are multiple ways to view and interact with data.
• It is also a very useful architecture pattern when the future requirements for interaction and
presentation is not known as it provides flexibility over the view of data.

MVC Advantages
•Independency: Allows data to change independently of its presentation.
•Multiple presentation: Supports presentation of data in multiple ways.
•Consistency: A change in the model (i.e. data) is always reflected to controller and the view.

MVC Disadvantages
•Difficult to maintain a clean system: Requires more effort and additional code to provide simplicity of
data model and controller interactions.
•Complexity: Can easily lead to code complexity.
 Architecture patterns

Layered Architecture

• The layered architecture is especially useful when the development is spread across several teams with
each team having a responsibility for a layer of functionality.
• User Interface : GUI Designer team
• Business logic : Developer team
• Management authentication and validation : Q & A Tester team
• System support : Database designer & administrator(s)
 Architecture patterns

Most Commonly used Layered Architectures: 2Tier

•One of the most commonly used Architecture model is 2 Tier Architecture model.

In a Two tiered architecture, a web server is where the business logic and presentation runs and
a database is where the persistency resides. These do not necessarily have to be a database or a
web server. It could also be an XML repository, a cloud account and/or an object repository.
 Architecture patterns

Most Commonly used Layered Architectures: 3Tier

•The other most commonly used Architecture model is 3 Tier Architecture model.
 Architecture patterns

Advantages of Layered Architecture

•Maintenance: Each layer is individual on its own and updates can be done on a layer without affecting
another layer.
•Consistency: Replacement of layers so long as the interface is maintained.
•Multi-level security: e.g. authentication can be provided in each layer to increase security of the system.

Disadvantages of Layered Architecture

•Complexity: A clean separation between the layers is difficult.

•Performance problems: may arise since layers are connected to each other in a linear way. In other words,
multiple levels of interpretation of a service request as it is processed at each layer.
 Architecture patterns
Client-Server Architecture

•Client–Server Architectures are usually used with distributed systems.

•To understand client–server architecture, it is imperative to understand distributed systems.
•A distributed system consists of a collection of independent computers, connected through a
network and distribution middleware, which enables computers to coordinate their activities and to
share the resources of the system, so that users perceive the system as a single, integrated computing
facility.
•As it is well known, the client –server architecture is a computing model in which the server hosts,
delivers and manages most of the resources and services to be consumed by the client.
•This type of architecture has one or more client computers connected to a central server over a
network or Internet connection.
•Client/server architecture may also be referred to as a networking computing model because all the
requests and services are delivered over a network.
 Architecture patterns
Client-Server Architecture Features
•Clients need to know the services they are going to access but servers do not need to know the identity of
clients, or how many clients are accessing their services.
•An important benefit of this structure is independence. The services and servers can be changed without
affecting other parts of the system.
•Client-Server architecture is particularly used with distributed systems.

Client –Server Architecture Advantages

•Independency : services are distributed across the network available to clients independently.
•Maintainability : service can be replaced without affecting other services.

Client –Server Architecture Disadvantages

•Unstable Performance: The efficiency of a software is unpredictable in this architecture as it depends on
the network as well as the system.
•Management problems: many management problems may arise should services are distributed too much
or that servers are owned by different organizations.
 Architecture patterns

Repository Architecture

•Repository architecture is used in systems that produce large volumes of information, generated and used
for a long time. This architecture is also useful when data triggers a tool or an action.
•The information is then becomes available and could be used by other tools.
•With the arise of big data, repository architecture pattern got very popular. Almost all systems today
provide some sort of cloud and management services.

Disadvantages of Repository Architecture

•There is no need to transmit data explicitly from one component to the other.
•However, on the development side, it is not easy to distribute the repository over a number of machines.
•Although a repository can be logically distributed over a number of machines, there may be problems with
data redundancy and inconsistency.
 Architecture patterns

Advantages of Repository Architecture

•Components are independent –They do not need to know of existence of other components.
•All data can be managed consistent as if it is all in one place.
•Changes made by one component on the repository is automatically reflected to all other components.
 Architecture patterns

Pipe and Filter Architecture

•The name « pipe » and « filter» comes from original UNIX system where it was possible to link processes
using « pipes».
•The pipes were in fact text streams frequently used with UNIX commands which then facilitate the control
of UNIX shell.
•The entire workflow of this architecture is based on this as statements are filtered through pipelines.
•The transformation of data is sequential and the data is processed in batches. Hence, the pipe and filter
architecture is in fact a batch sequential model for data processing.
•Most billing systems are designed with this architecture.
•The architecture of an embedded system can be organized as a process pipeline, with each process
executing concurrently.
•In other words, pipe and filter architecture is often used with embedded systems.
•This architecture is particularly displayed with STATE MACHINE Diagrams
 Architecture patterns

Pipe and Filter Architecture Advantages

•Simplicity : easy to understand and supports reuse. Adding transformation is also straightforward.
•Concurrent or Sequential work : supports sequential and parallel working –works well with object
oriented design.

Pipe and Filter Architecture Disadvantages

•Not compatible for all systems:
•Embedded Systems are not meant to be complicated and they have a very specific task. Although simple
textual input and output can be presented this way, the graphical data can have too complicated I/O formats
inevitably making it difficult to translate this into a form compatible with the pipe and filter architecture.
•The data would always needed to be cascaded into a machine readable format so that the embedded
system can understand it.
 Software Testing

• Software testing is the process of finding errors in the developed product. It also checks whether
the real outcomes match the expected results. It also aids in the identification of defects, missing
requirements, or gaps .
• Testing is intended to show that a program does what it is intended to do and to discover program
defects before it is put into use.
• Testing can only show the presence of errors, not there absence.
• Testing is done to achieve two goals. This include:
• To demonstrate that the software meets its requirements. This is achieved through Validation
test.
• To discover situations in which the behaviour of the software is incorrect, undesirable, or does
not conform to its specification. This is achieved through defect test.
 Software Testing

• Testing is part of the broader process of Software Validation and Verification.

• Validation: Are we building the right product?
• Verification: Are we building the product right?
• The main aim of Verification is to check if the software meets its stated functional and non-
functional requirements.
• Validation ensures that the software meets the customer’s expectation.
 Software Testing
Types of Software Testing

• Unit Testing: Unit testing is the process of testing program components, such as methods or object
classes.
• Requirements-based Testing: is a software testing approach where you consider each requirement
and derive a set of tests for it. It is a validation rather than defect test.
• Performance Testing: after a system has been completely integrated, testing for performance and
reliability is very important. Performance tests have to be designed to ensure that the system can
process its intended load.
• Release Testing: is the process of testing a particular release of a system that is intended
for use outside of the development team. Normally, the system release is for customers
and users.
 Software Testing
• User Testing: This is a process where users or customers provide input on system testing. There
are three types of user testing:
• Alpha Testing: in this test, users of the software work with the development team to test the software at
the developer’s site.
• Beta Testing: in this test a release of the software is made available to users to allow them to experiment
and to raise problems that they discover with the system developers.
• Acceptance Testing: in this test the customers test a system to decide whether or not it is ready to be
accepted from the system developers and deployed in the customer environment.
 Software Testing

BLACK BOX TESTING VS WHITE BOX TESTING

Software Tools and Environment
Thank you