Software Engineering

Paper XVII
Few words before we start
• Lets’ not only study Software Engineering
• But let’s practice it.
Section – I
Software
• Oxford dictionary defines software as:

“The programs and other operating information used by a computer.”

Software - Characteristics
• Functionality: Refers to the degree of performance of the software
against its intended purpose.
• Reliability: Refers to the ability of the software to provide desired
functionality under the given conditions.
• Usability: Refers to the extent to which the software can be used with
ease.
• Efficiency: Refers to the ability of the software to use system
resources in the most effective and efficient manner.
… Contd
• Maintainability: Refers to the ease with which the modifications can
be made in a software system to extend its functionality, improve its
performance, or correct errors.
• Portability: Refers to the ease with which software developers can
transfer software from one platform to another, without (or with
minimum) changes. In simple terms, it refers to the ability of software
to function properly on different hardware and software platforms
without making any changes in it.
Software - Components
• Software components are parts of a system or application.
• Components are a means of breaking the complexity of software into
manageable parts.
• Each component hides the complexity of its implementation behind an
interface.
• Components can be swapped in and out like the interchangeable parts of a
machine.
• This reduces the complexity of software development, maintenance,
operations and support and allows the same code to be reused in many places.
…Contd
• Views
• User interface components for different requests, views and scenarios. For example, difficult components can be used
to display the same information in a web page and mobile app.
• Models
• Components that handle requests or events including business rules and data processing. For example, a model might
handle a bill payment request for an internet banking website.
• Controllers
• A controller is a component that decides what components to call for a particular request or event. For example, a
controller might dynamically load different views for a bill payment based on factors such as language, transaction
status or channel.
• Data Access Objects
• A data access object provides an abstract interface for databases. In theory, this allows you to switch to a different
database without the application needing to know.
…Contd
• Services
• A service is a component that is deployed independently. For example, a bank might deploy a market data
service to cloud infrastructure. This service would provide stock market data to a variety of stock trading
systems and applications. Services allow for extremely resilient applications. For example, if an application
doesn't get a response from a service, it can try again and be directed to a completely different instance.
• Plugins
• Components designed to extend the functionality of an application or system. For example, a plugin for a
media player to visualize music.
• APIs
• A component that can be reused across multiple systems and applications can be packaged and distributed
as an API. For example, an open source API to connect to a particular database.
Software – Applications

• This is your assignment

Process
• A successful project is the one that satisfies the expectations on all the three goals of
cost, schedule, and quality (we are including functionality or features as part of quality.)
• Consequently, when planning and executing a software project, the decisions are
mostly taken with a view to ultimately reduce the cost or the cycle time, or for
improving the quality.
• Software projects utilize a process to organize the execution of tasks to achieve the
goals on the cost, schedule, and quality fronts.
• A project's process specification defines the tasks the project should perform, and the
order in which they should be done.
… Contd
• The actual process exists when the project is actually executed.
• Although process specification is distinct from the actual process.
• But, we shall consider the process specification for a project and the
actual process of the project as one and the same, and will use the
term process to refer to both of them.
Process Model
• A process model specifies a general process, usually as a set of stages in which a
project should be divided, the order in which the stages should be executed,
and any other constraints and conditions on the execution of stages.
• The basic premise behind a process model is that, in the situations for which
the model is applicable, using the process model as the projects process will
lead to low cost, high quality, or reduced cycle time.
• In other words, a process is a means to reach the goals of high quality, low cost,
and low cycle time, and a process model provides generic guidelines for
developing a suitable process for a project.
Software Process – An Overview
• In software engineering, the phrase software process refers to the
methods of developing software.
• A software process is a set of activities, together with ordering
constraints among them, such that if the activities are performed
properly and in accordance with the ordering constraints, the desired
result is produced.
• The basic desired result is, as stated earlier, high quality and productivity.
• The process that deals with the technical and management issues of
software development is called a software process.
Software Process – Components
• We now know that the development process is the central process
which specifies the tasks to be done in a project.
• Planning and scheduling the tasks and monitoring their execution fall
in the domain of project management process.
• Hence, there are clearly two major components in a software process
• A development process and
• A project management process
…contd
• The development process specifies the development and quality
assurance activities that need to be performed.
• Whereas the management process specifies how to plan and control
these activities so that cost, schedule, quality, and other objectives
are met.
Software Process – Characteristics
• Predictability
• Predictability of a process determines how accurately the outcome of following
that process in a project can be predicted before the project is completed.
• Predictability can be considered a fundamental property of any process.
• Support Testability and Maintainability
• In the life of software the maintenance costs generally exceed the development
costs.
• If we want to reduce the overall cost of software or achieve "global" optimality
in terms of cost rather than "local" optimality in terms of development cost
only, the goal of development should be to reduce the maintenance effort.
…Contd
• Support Change
• Software changes for a variety of reasons.
• As organizations and businesses change, the software supporting the business has to change.
• Hence, any model that builds software and makes change very hard will not be suitable in
many situations.
• Early Defect Removal
• The notion that programming is the central activity during software development is largely
due to programming being considered a difficult task and sometimes an "art.“
• Another consequence of this kind of thinking is the belief that errors largely occur during
programming, as it is the hardest activity in software development and offers many
opportunities for committing errors.
…contd
• It is now clear that errors can occur at any stage during development.
• The greater the delay in detecting an error after it occurs, the more expensive it is to correct it.
• The reason for this is fairly obvious, if there is an error in the requirements,
• then the design and the code will be affected by it.

• Process Improvement and Feedback

• A process is not a static entity.
• Improving the quality and reducing the cost of products are fundamental goals of any
engineering discipline.
• Process improvement can be done by taking feedback from the early parts of the project can be
used to improve the execution of the rest of the project or from older projects in the newer
ones.
Software Process Models
• In the software development process we focus on the activities directly
related to production of the software, for example, design, coding, and
testing.
• As the development process specifies the major development and quality
control activities that need to be performed in the project, the
development process really forms the core of the software process.
• The management process is decided based on the development process.
• Due to the importance of the development process, various models have
been proposed.
Various Software Process Models
• Waterfall Model
• Spiral Model
• Prototyping Model
• Fourth Generation Technique
Waterfall Model
• The simplest process model is the waterfall model, which states that
the phases are organized in a linear order.
• The model was originally proposed by Royce in 1970.
• Though variations of the model have evolved depending on the
nature of activities and the flow of control between them.
• In this model, a project begins with feasibility analysis.
• Upon successfully demonstrating the feasibility of a project, the
requirements analysis and project planning begins.
Waterfall Model

• The design starts after the requirements analysis is complete, and coding
begins after the design is complete.

• Once the programming is completed, the code is integrated and testing is

done.

• Upon successful completion of testing, the system is installed.

• After this, the regular operation and maintenance of the system takes place.
Waterfall Model
Advantages of Waterfall Model

• It is conceptually straightforward and divides the large task of building

a software system into a series of cleanly divided phases, each phase
dealing with a separate logical concern.

• It is also easy to administer in a contractual setup—as each phase is

completed and its work product produced, some amount of money is
given by the customer to the developing organization.
Limitations of Waterfall Model
• It assumes that the requirements of a system can be frozen (i.e., baselined) before the design
begins. This is possible for systems designed to automate an existing manual system. But for new
systems, determining the requirements is difficult as the user does not even know the
requirements. Hence, having unchanging requirements is unrealistic for such projects.

• Freezing the requirements usually requires choosing the hardware (because it forms a part of
the requirements specification). A large project might take a few years to complete. If the
hardware is selected early, then due to the speed at which hardware technology is changing, it is
likely that the final software will use a hardware technology on the verge of becoming obsolete.
This is clearly not desirable for such expensive software systems.
Limitations of Waterfall Model

• It follows the "big bang" approach—the entire software is delivered in

one shot at the end. This entails heavy risks, as the user does not know
until the very end what they are getting. Furthermore, if the project runs
out of money in the middle, then there will be no software. That is, it
has the "all or nothing" value proposition.

• It is a document-driven process that requires formal documents at the

end of each phase.
Prototyping Model

• The goal of a prototyping-based development process is to counter the first two

limitations of the waterfall model.

• The basic idea here is that instead of freezing the requirements before any design or
coding can proceed, a throwaway prototype is built to help understand the
requirements.

• This prototype is developed based on the currently known requirements.

• Development of the prototype obviously undergoes design, coding, and testing, but
each of these phases is not done very formally or thoroughly.
Prototyping Model

• By using this prototype, the client can get an actual feel of the system,
because the interactions with the prototype can enable the client to better
understand the requirements of the desired system.

• This results in more stable requirements that change less frequently.

• Prototyping is an attractive idea for complicated and large systems for

which there is no manual process or existing system to help determine the
requirements.
Prototyping Model
Spiral Model
• The iterative development process model counters the third limitation of the waterfall
model and tries to combine the benefits of both prototyping and the waterfall model.

• The basic idea is that the software should be developed in increments, each increment
adding some functional capability to the system until the full system is implemented.

• At each step, extensions and design modifications can be made.

• An advantage of this approach is that it can result in better testing because testing each
increment is likely to be easier than testing the entire system as in the waterfall model.
Spiral Model
• Furthermore as in prototyping, the increments provide feedback to the client that is
useful for determining the final requirements of the system.

• The spiral model is one of the spiral models.

• As the name suggests, the activities in this model can be organized like a spiral that has
many cycles as shown in figure in the next slide.

• Each cycle in the spiral begins with the identification of objectives for that cycle, the
different alternatives that are possible for achieving the objectives, and the constraints
that exist.
Spiral Model
Spiral Model
• The next step in the cycle is to evaluate these different alternatives
based on the objectives and constraints.
• The focus of evaluation in this step is based on the risk perception for
the project.
• The next step is to develop strategies that resolve the uncertainties
and risks.
• This step may involve activities such as benchmarking, simulation, and
prototyping.
• Next, the software is developed, keeping in mind the risks.
Fourth Generation Techniques
• The term fourth generation techniques compasses a broad array of software tools that
have one thing in common: each enables the software engineer to specify some
characteristic of the software at a higher level. The tool then automatically generates
source code based on the developer’s specifications.

• Currently, a software development environment that supports the 4GT model includes
some or all of the following tools: nonprocedural languages for database query, report
generation, data manipulation, screen interaction and definition, code generation,
high-level graphics.
Fourth Generation Techniques
• Like all other models, 4GT begins with a requirements gathering phase. Ideally, the customer would
describe the requirements, which are directly translated into an operational prototype. Practically,
however, the client may be unsure of the requirements, may be ambiguous in his specs or may be
unable to specify information in a manner that a 4GT tool can use. Thus, the client/developer dialog
remains an essential part of the development process.

• For small applications, it may be possible to move directly from the requirements gathering phase to

the implementation phase using a nonprocedural fourth generation language. However for larger

projects a design strategy is necessary. Otherwise, the same difficulties are likely to arise as with

conventional approaches.
Fourth Generation Technique
Fourth Generation Technique

• Advantages:
• Dramatic reduction in software development time.

• Improved productivity for software developers.

• Disadvantages:
• Not much easier to use as compared to programming languages.
Concept of Project
Management
Project Management Process
• Proper management is an integral part of software development.
• A large software development project involves many people working
for a long period of time.
• We have seen that a development process typically partitions the
problem of developing software into a set of phases.
• To meet the cost, quality, and schedule objectives, resources have to
be properly allocated to each activity for the project, and progress of
different activities has to be monitored and corrective actions taken, if
needed.
Project Management Process
• All these activities are part of the project management process.
• The project management process specifies all activities that need to
be done by the project management to ensure that cost and quality
objectives are met.
• Its basic task is to ensure that, once a development process is chosen,
it is implemented optimally.
• The focus is on issues like planning a project, estimating resource and
schedule, and monitoring and controlling the project.
Project Management Process

• For a large project, a proper management process is essential for

success.
• The activities in the management process for a project can be
grouped broadly into three phases: planning, monitoring and control,
and termination analysis.
Role of Metrics and
Measurement
Software Metrics
• Software metrics are quantifiable measures that could be used to
measure different characteristics of a software system or the software
development process.
• There are two types of metrics used for software development:
• product metrics and

• process metrics.
Product Metrics

• Product metrics are used to quantify characteristics of the product

being developed, i.e., the software.
Process Metrics

• Process metrics are used to quantify characteristics of the process

being used to develop the software.

• Process metrics aim to measure such considerations as productivity,

cost and resource requirements, effectiveness of quality assurance
measures, and the effect of development techniques and tools
More on Metrics and Measurements

• Metrics and measurement are necessary aspects of managing a software

development project.

• For effective monitoring, the management needs to get information about the
project:
• how far it has progressed,

• how much development has taken place,

• how far behind schedule it is,

• and the quality of the development so far.

Software Project Planning
Software Project Planning -
Overview
• For a successful project, both good project management and good
engineering are essential.
• Lack of either one can cause a project to fail.
• We have seen that project management activities can be viewed as
having three major phases:
• project planning
• project monitoring and control,
• Project termination.
Software Project Planning –
Overview
• Broadly speaking, planning entails all activities that must be
performed before starting the development work.
• Once the project is started, project control begins.
• In other words, during planning all the activities that management
needs to perform are planned, while during project control the plan is
executed and updated.
Software Project Planning –
Overview
• Planning may be the most important management activity.
• Without a proper plan, no real monitoring or controlling of the
project is possible.
• Often projects are rushed toward implementation with not enough
time and effort spent on planning.
• No amount of technical effort later can compensate for lack of careful
planning.
• Lack of proper planning is a sure ticket to failure for a large software
project.
Software Project Planning –
Overview
• The basic goal of planning is to look into the future, identify the
activities that need to be done to complete the project successfully,
and plan the scheduling and resources.
• The inputs to the planning activity are the requirements specification
and the architecture description.
• A very detailed requirements document is not essential for planning,
but for a good plan all the important requirements must be known,
and it is highly desirable that architecture decisions have been taken.
Software Project Planning -
Objective
• The objective of software project planning is to provide a framework that enables
the manager to make reasonable estimates of resources, cost, and schedule.

• In addition, estimates should attempt to define best-case and worst-case

scenarios so that project outcomes can be bounded.

• Although there is an inherent degree of uncertainty, the software team embarks

on a plan that has been established as a consequence of these tasks.

• Therefore, the plan must be adapted and updated as the project proceeds.
Decomposition Techniques
• Decomposition techniques are one of the software project estimation
methods.
• Decomposition techniques take a divide-and-conquer approach to
software project estimation.
• By decomposing a project into major functions and related software
engineering activities, cost and effort estimation can be performed in
a stepwise fashion.
Software Sizing
• The accuracy of a software project estimate is predicated on a number of things:
1. The degree to which you have properly estimated the size of the product to be built.

2. The ability to translate the size estimate into human effort, calendar time, and dollars (a
function of the availability of reliable software metrics from past projects).

3. The degree to which the project plan reflects the abilities of the software team.

4. The stability of product requirements and the environment that supports the software
engineering effort.
Software Sizing
• Because a project estimate is only as good as the estimate of the size
of the work to be accomplished, software sizing represents your fi st
major challenge as a planner.
• In the context of project planning, size refers to a quantifiable
outcome of the software project.
• If a direct approach is taken, size can be measured in lines of code
(LOC).
• If an indirect approach is chosen, size is represented as function
points (FP).
Software Sizing

• Size can be estimated by considering the type of project and its

application domain, the functionality delivered (i.e., the number of
function points), the number of components to be delivered, the
degree to which a set of existing components must be modified for
the new system.
Problem Based Estimation
• In previous slides lines of code and function points were described as
measures from which productivity metrics can be computed.
• LOC and FP data are used in two ways during software project
estimation:
1. as estimation variables to “size” each element of the software and
2. as baseline metrics collected from past projects and used in conjunction
with estimation variables to develop cost and effort projections.
Process Based Estimation

• The most common technique for estimating a project is to base the estimate on
the process that will be used.

• That is, the process is decomposed into a relatively small set of activities,
actions, and tasks and the effort required to accomplish each is estimated.

• Like the problem-based techniques, process-based estimation begins with a

delineation of software functions obtained from the project scope.

• A series of framework activities must be performed for each function.

Cost Estimation Models
COCOMO Model
• In his classic book on software engineering economics, Barry Boehm introduced a
hierarchy of software estimation models bearing the name COCOMO, for COnstructive
COst MOdel.

• The original COCOMO model became one of the most widely used and discussed
software cost estimation models in the industry.

• It has evolved into a more comprehensive estimation model, called COCOMO II.

• Like its predecessor, COCOMO II is actually a hierarchy of estimation models that

address different “stages” of the software process.
COCOMO Model

• Like all estimation models for software, the COCOMO II models

require sizing information.

• Three different sizing options are available as part of the model

hierarchy: object points, 10 function points, and lines of source code.
The Software Equation

• The software equation is a dynamic multivariable model that assumes

a specific distribution of effort over the life of a software development
project.

• The model has been derived from productivity data collected for over
4,000 contemporary software projects.

• Based on these data, we derive an estimation model of the form

The Software Equation
• Where,
• E= effort in person-months or person-years
• t = project duration in months or years
• B = “special skills factor”
• P = “productivity parameter” that reflects: overall process maturity and
management practices, the extent to which good software engineering
practices are used, the level of programming languages used, the state of the
software environment, the skills and experience of the software team, and
the complexity of the application
The Software Equation
• Typical values might be P = 2,000 for development of real-time
embedded software, P = 10,000 for telecommunication and systems
software, and P = 28,000 for business systems applications.
• The productivity parameter can be derived for local conditions using
historical data collected from past development efforts.
Section – II
Principles of Structured Analysis
Requirement Analysis
• IEEE defines a requirement as "(1) A condition of capability needed by
a user to solve a problem or achieve an objective; (2) A condition or a
capability that must be met or possessed by a system ... to satisfy a
contract, standard, specification, or other formally imposed
document."
• The basic aim of problem analysis is to obtain a clear understanding of
the needs of the clients and the users, what exactly is desired from
the software, and what the constraints on the solution are.
Software Requirement Specification

• A high-quality SRS is a prerequisite to high-quality software.

Characteristics of SRS

1. Correct 5. Consistent

2. Complete 6. Ranked for importance and/or

3. Unambiguous stability

4. Verifiable 7. Modifiable

8. Traceable
Components of SRS
• Completeness of specifications is difficult to achieve and even more
difficult to verify.
• Having guidelines about what different things an SRS should specify
will help in completely specifying the requirements.
• The basic issues an SRS must address are:
• Functionality
• Performance
• Design constraints imposed on an implementation
• External interfaces
Functional Requirements
• The functional requirements for a system describe the functionalities
or services that the system is expected to provide.
• They provide how the system should react to particular inputs and
how the system should behave in a particular situation.
Performance Requirements

• In this component of SRS all the performance constraints on the

system should be specified such as response time, throughput
constraints, number of terminals to be supported, number of
simultaneous users to be supported etc.
Design Constraints
• Here design constraints such as standard compliance, hardware limitations, Reliability, and security
should be specified.

• There may be a requirement that system will have to use some existing hardware, limited primary
and/or secondary memory.

• There may be some standards of the organization that should be obeyed such as the format of
reports.

• Security requirements may be particularly significant in defense systems.

• It imposes a restriction sometimes on the use of some commands, control access to data, require
the use of passwords and cryptography techniques etc.
External Interface Requirements

• Software has to interact with people, hardware, and other software.

• All these interfaces should be specified.

• User interface has become a very important issue now a day.

• So the characteristics of user interface should be precisely specified

and should be verifiable.
Data Flow Diagram
• Data flow diagrams (also called data flow graphs) are commonly used
during problem analysis.
• Data flow diagrams (DFDs) are quite general and are not limited to
problem analysis for software requirements specification.
• They were in use long before the software engineering discipline
began.
• DFDs are very useful in understanding a system and can be effectively
used during analysis.
…contd

• A DFD shows the flow of data through a system.

• It views a system as a function that transforms the inputs into desired outputs.

• Any complex system will not perform this transformation in a "single step," and
a data will typically undergo a series of transformations before it becomes the
output.

• The DFD aims to capture the transformations that take place within a system to
the input data so that eventually the output data is produced.
Symbol Used in DFD
• The agent that performs the transformation of data from one
state to another is called a process (or a bubble).

• Data flows are represented by named arrows entering or

leaving the bubbles.

• A rectangle represents a source or sink and is a net originator

or consumer of data. A source or a sink is typically outside the
main system of study.

• External Files used for storing data is shown as open

rectangle.
Remember
• DFD is not a flowchart.
• A DFD represents the flow of data, while a flowchart shows the flow
of control.

• A DFD does not represent procedural information.

• So, while drawing a DFD, one must not get involved in procedural
details, and procedural thinking must be consciously avoided.
Suggestions for constructing DFD
• Work your way consistently from the inputs to the outputs, or vice versa.

• Start with a high-level data flow graph with few major transforms describing the entire
transformation from the inputs to outputs and then refine each transform with more detailed
transformations.

• Never try to show control logic. If you find yourself thinking in terms of loops and decisions, it is
time to stop and start again.

• Label each arrow with proper data elements. Inputs and outputs of each transform should be
carefully identified.

• Try drawing alternate data flow graphs before settling on one.

Leveled DFD

• Many systems are too large for a single DFD to describe the data
processing clearly.

• It is necessary that some decomposition and abstraction mechanism be

used for such systems.

• DFDs can be hierarchically organized, which helps in progressively

partitioning and analyzing large systems. Such DFDs together are called a
leveled DFD set.
Entity Relationship Diagram

• An Entity Relationship Diagram (ERD) is a data model describing how

entities (or concepts or things) relate to one another.

• When created by business analysts, ERDs can be used to understand

the business domain, clarify business terminology, and connect
business concepts to database structures.
Data Dictionary
Software Design
Software Design – Objectives
• The purpose of the design phase is to plan a solution of the problem
specified by the requirements document.
• This phase is the first step in moving from the problem domain to the
solution domain.
• In other words, starting with what is needed, design takes us toward
how to satisfy the needs.
• The design of a system is perhaps the most critical factor affecting the
quality of the software; it has a major impact on the later phases,
particularly testing and maintenance.
Software Design – Principles

• The design of a system is correct if a system built precisely according to the

design satisfies the requirements of that system.

• Clearly, the goal during the design phase is to produce correct designs.

• However, correctness is not the sole criterion during the design phase, as
there can be many correct designs.

• The goal of the design process is not simply to produce a design for the
system.
Software Design – Principles
• The software design model is the equivalent of an architect’s plans for
a house.
• It begins by representing the totality of the thing to be built (e.g., a
three-dimensional rendering of the house) and slowly refines the
thing to provide guidance for constructing each detail (e.g., the
plumbing layout).
• Similarly, the design model that is created for software provides a
variety of different views of the system.
Software Design – Principles

• Design should be traceable to the requirements model.

• Always consider the architecture of the system to be built.

• Design of data is as important as design of processing functions.

• Interfaces (both internal and external) must be designed with care.

• User interface design should be tuned to the needs of the end user.
However, in every case, it should stress ease of use.
Software Design - Principles

• Component-level design should be functionally independent.

• Components should be loosely coupled to one another and to the

external environment.

• Design representations (models) should be easily understandable.

• The design should be developed iteratively.

• Creation of a design model does not preclude an agile approach.

Software Design - Concepts
• Software design encompasses the set of principles, concepts, and
practices that lead to the development of a high-quality system or
product.
• Design principles establish an overriding philosophy that guides the
design work you must perform.
• Design concepts must be understood before the mechanics of design
practice are applied, and design practice itself leads to the creation of
various representations of the software that serve as a guide for the
construction activity that follows.
Design Methodologies (Mythologies)

• A design methodology is an approach to design that may include a set

of philosophies, principles, processes and techniques. In some cases,
they are associated with a type of design such as architecture or
graphic design.
Types of Design Methodologies

• Data Design

• Architecture Design

• Procedural Design

• Object Oriented Design

Data Design

• Like other software engineering activities, data design (sometimes referred to

as data architecting ) creates a model of data and/or information that is
represented at a high level of abstraction (the customer/user’s view of data).

• This data model is then refined into progressively more implementation-

specific representations that can be processed by the computer-based system.

• In many software applications, the architecture of the data will have a

profound influence on the architecture of the software that must process it.
Data Design
• The structure of data has always been an important part of software design.

• At the program-component level, the design of data structures and the associated algorithms
required to manipulate them is essential to the creation of high- quality applications.

• At the application level, the translation of a data model (derived as part of requirements
engineering) into a database is pivotal to achieving the business objectives of a system.

• At the business level, the collection of information stored in disparate databases and reorganized
into a “data warehouse” enables data mining or knowledge discovery that can have an impact on the
success of the business itself.

• In every case, data design plays an important role.

Architecture Design

• Requirements of the software should be transformed into an architecture that

describes the software's top-level structure and identifies its components. This
is accomplished through architectural design (also called system design),
which acts as a preliminary 'blueprint' from which software can be developed.

• IEEE defines architectural design as 'the process of defining a collection of

hardware and software components and their interfaces to establish the
framework for the development of a computer system.'
Architectural Design Representation
Architectural design can be represented using the following models:
• Structural model: Illustrates architecture as an ordered collection of program components
• Dynamic model: Specifies the behavioral aspect of the software architecture and indicates
how the structure or system configuration changes as the function changes due to change in
the external environment
• Process model: Focuses on the design of the business or technical process, which must be
implemented in the system
• Functional model: Represents the functional hierarchy of a system
• Framework model: Attempts to identify repeatable architectural design patterns encountered
in similar types of application. This leads to an increase in the level of abstraction.
Procedural Design
Object – Oriented Concepts
Testing Fundamentals
Objectives
• To demonstrate to the developer and the customer that the software meets its requirements. For
custom software, this means that there should be at least one test for every requirement in the
requirements document.

• For generic software products, it means that there should be tests for all of the system features,
plus combinations of these features, that will be incorporated in the product release.

• To discover situations in which the behavior of the software is incorrect, undesirable, or does not
conform to its specification. These are a consequence of software defects.

• Defect testing is concerned with rooting out undesirable system behavior such as system crashes,
unwanted interactions with other systems, incorrect computations, and data corruption.
Principles

1. Testing shows presence of defects

2. Exhaustive testing is impossible

3. Early Testing

4. Defect Clustering

5. Pesticide Paradox

6. Testing is context dependent

7. Absence of errors - fallacy

Testability
• James Bach provides the following definition for testability: “Software testability is simply how easily
a computer program can be tested.”

• The following characteristics lead to testable software:

• Operability

• Observability

• Controllability

• Decomposability

• Simplicity

• Stability

• Understandability
Test Cases
• Having test cases that are good at revealing the presence of faults is
central to successful testing.
• The reason for this is that if there is a fault in a program, the program
can still provide the expected behavior for many inputs.
• Only for the set of inputs that exercise the fault in the program will
the output of the program deviate from the expected behavior.
• Hence, it is fair to say that testing is as good as its test cases.
Test Cases
• Having test cases that are good at revealing the presence of faults is
central to successful testing.
• The reason for this is that if there is a fault in a program, the program
can still provide the expected behavior for many inputs.
• Only for the set of inputs that exercise the fault in the program will
the output of the program deviate from the expected behavior.
• Hence, it is fair to say that testing is as good as its test cases.
White Box Testing

• White-box testing, sometimes called glass-box testing or structural testing, is a test-

case design philosophy that uses the control structure described as part of
component-level design to derive test cases.

• Using white-box testing methods, you can derive test cases that
1) guarantee that all independent paths within a module have been exercised at least once,

2) exercise all logical decisions on their true and false sides,

3) execute all loops at their boundaries and within their operational bounds,

4) exercise internal data structures to ensure their validity.

Black Box Testing

• Black-box testing , also called behavioral testing or functional testing, focuses

on the functional requirements of the software.

• That is, black-box testing techniques enable you to derive sets of input
conditions that will fully exercise all functional requirements for a program.

• Black-box testing is not an alternative to white-box techniques.

• Rather, it is a complementary approach that is likely to uncover a different class

of errors than white-box methods.
Black Box Testing

Black-box testing attempts to find errors in the following categories:

1) incorrect or missing functions,

2) interface errors,

3) errors in data structures or external database access,

4) behavior or performance errors, and

5) initialization and termination errors.

Testing Strategies
Verification

• Once a programmer has written the code for a module, it has to be verified before
it is used by others.

• So far we have assumed that testing is the means by which this verification is done.

• Though testing is the most common method of verification, there are other
effective techniques also.

• It should be pointed out that by verification we do not mean proving correctness of

programs, which for our purposes is only one method for program verification.
Verification

• Here we will focus on techniques that are now widely used in practice
— inspections (including code reading), unit testing, and program
checking.

• Though we are focusing on verifying individual programs written by

programmers, some of the techniques like program checking are
applicable at the complete system level also.
Validation
• Validation can be defined in many ways, but a simple definition is that validation
succeeds when software functions in a manner that can be reasonably expected by
the customer.

• At this point a battle-hardened software developer might protest: “Who or what is

the arbiter of reasonable expectations?”

• If a Software Requirements Specification has been developed, it describes all user-

visible attributes of the software and contains a Validation Criteria section that forms
the basis for a validation-testing approach.
Unit Testing
• Unit testing is the process of testing program components, such as methods or object
classes.

• Individual functions or methods are the simplest type of component.

• The tests should be calls to these routines with different input parameters.

• You can use the approaches to test case design to design the function or method tests.

• When you are testing object classes, you should design your tests to provide coverage of
all of the features of the object.
Integration Testing

• Integration testing tests the interface between modules of the software

application.

• The different modules are first testing individually and then combined to make
a system.

• Testing the interface between the small units or modules is integration testing.

• It is usually conducted by software integration tester and in continuation to the

development.
Validation Testing

• The process of evaluating software during the development process or at

the end of the development process to determine whether it satisfies
specified business requirements.

• Validation Testing ensures that the product actually meets the client's
needs. It can also be defined as to demonstrate that the product fulfills its
intended use when deployed on appropriate environment
System Testing

• System testing during development involves integrating components to create a

version of the system and then testing the integrated system.

• System testing checks that components are compatible, interact correctly and
transfer the right data at the right time across their interfaces.

• When you integrate components to create a system, you get emergent behavior.

• This means that some elements of system functionality only become obvious
when you put the components together.
Extras
Coupling and Cohesion
Introduction

• The purpose of Design phase in the Software Development Life Cycle is to produce
a solution to a problem given in the SRS(Software Requirement Specification)
document. The output of the design phase is Sofware Design Document (SDD).

• Basically, design is a two-part iterative process. First part is Conceptual Design that
tells the customer what the system will do. Second is Technical Design that allows
the system builders to understand the actual hardware and software needed to
solve customer’s problem.
Conceptual Design of System

• Written in simple language i.e. customer understandable language.

• Detail explanation about system characteristics.

• Describes the functionality of the system.

• It is independent of implementation.

• Linked with requirement document.

Technical Design of System

• Hardware component and design.

• Functionality and hierarchy of software component.

• Software architecture

• Network architecture

• Data structure and flow of data.

• I/O component of the system.

• Shows interface.
Modularization

• Modularization is the process of dividing a software system into

multiple independent modules where each module works
independently.

• There are many advantages of Modularization in software

engineering.
Advantages of Modularization

• Easy to understand the system.

• System maintenance is easy.

• A module can be used many times as their requirements, hence, no

need to write it again and again.
Coupling

• Coupling is the measure of the degree of interdependence between

the modules.

• A good software will have low coupling.

Cohesion

• Cohesion is a measure of the degree to which the elements of the

module are functionally related.

• It is the degree to which all elements directed towards performing a

single task are contained in the component.

• Basically, cohesion is the internal glue that keeps the module together.

• A good software design will have high cohesion.

Coupling vs Cohesion
Cohesion Coupling
Cohesion is the concept of intra module. Coupling is the concept of inter module.
Cohesion represents the relationship within Coupling represents the relationships
module. between modules.
Increasing in cohesion is good for software. Increasing in coupling is avoided for
software.
Cohesion represents the functional strength Coupling represents the independence
of modules. among modules.
Highly cohesive gives the best software. Whereas loosely coupling gives the best
software.
In cohesion, module focuses on the single In coupling, modules are connected to the
thing. other modules.