Unit 1: Introduction

- RAD (Rapid Application Development) Model

- RAD is a linear sequential software development process model that emphasizes a concise
development cycle using an element based construction approach. If the requirements are well
understood and described, and the project scope is a constraint, the RAD process enables a
development team to create a fully functional system within a concise time period.
- RAD (Rapid Application Development) is a concept that products can be developed faster and of
higher quality through:
- Gathering requirements using workshops or focus groups
- Prototyping and early, reiterative user testing of designs
- The re-use of software components
- A rigidly paced schedule that refers design improvements to the next product version
- Less formality in reviews and other team communication

-
- The various phases of RAD are as follows:
- 1.Business Modelling: The information flow among business functions is defined by answering
questions like what data drives the business process, what data is generated, who generates it,
where does the information go, who process it and so on.
- 2. Data Modelling: The data collected from business modeling is refined into a set of data
objects (entities) that are needed to support the business. The attributes (character of each
entity) are identified, and the relation between these data objects (entities) is defined.
- 3. Process Modelling: The information object defined in the data modeling phase are
transformed to achieve the data flow necessary to implement a business function. Processing
descriptions are created for adding, modifying, deleting, or retrieving a data object.
- 4. Application Generation: Automated tools are used to facilitate construction of the software;
even they use the 4th GL techniques.
- 5. Testing & Turnover: Many of the programming components have already been tested since
RAD emphasis reuse. This reduces the overall testing time. But the new part must be tested, and
all interfaces must be fully exercised.
- The waterfall model is a software development model used in the context of large, complex
projects, typically in the field of information technology. It is characterized by a structured,
sequential approach to project management and software development.
- Features of the Waterfall Model
- Sequential Approach: The waterfall model involves a sequential approach to software
development, where each phase of the project is completed before moving on to the next one.
- Document-Driven: The waterfall model relies heavily on documentation to ensure that the
project is well-defined, and the project team is working towards a clear set of goals.
- Quality Control: The waterfall model places a high emphasis on quality control and testing at
each phase of the project, to ensure that the final product meets the requirements and
expectations of the stakeholders.
- Rigorous Planning: The waterfall model involves a rigorous planning process, where the project
scope, timelines, and deliverables are carefully defined and monitored throughout the project
lifecycle.

-
- Disadvantages of the Classical Waterfall Model
- The Classical Waterfall Model suffers from various shortcomings. Basically, we can’t use it in real
projects, but we use other software development lifecycle models which are based on the
classical waterfall model. Below are some major drawbacks of this model.
- No Feedback Path: In the classical waterfall model evolution of software from one phase to
another phase is like a waterfall. It assumes that no error is ever committed by developers
during any phase. Therefore, it does not incorporate any mechanism for error correction.
- Difficult to accommodate Change Requests: This model assumes that all the customer
requirements can be completely and correctly defined at the beginning of the project, but
actually customer’s requirements keep on changing with time. It is difficult to accommodate any
change requests after the requirements specification phase is complete.
- No Overlapping of Phases: This model recommends that a new phase can start only after the
completion of the previous phase. But in real projects, this can’t be maintained. To increase
efficiency and reduce cost, phases may overlap.
- Limited Flexibility: The Waterfall Model is a rigid and linear approach to software development,
which means that it is not well-suited for projects with changing or uncertain requirements.
Once a phase has been completed, it is difficult to make changes or go back to a previous phase.
- Limited Stakeholder Involvement: The Waterfall Model is a structured and sequential approach,
which means that stakeholders are typically involved in the early phases of the project
(requirements gathering and analysis) but may not be involved in the later phases
(implementation, testing, and deployment).
- Late Defect Detection: In the Waterfall Model, testing is typically done toward the end of the
development process. This means that defects may not be discovered until late in the
development process, which can be expensive and time-consuming to fix.
- Lengthy Development Cycle: The Waterfall Model can result in a lengthy development cycle, as
each phase must be completed before moving on to the next. This can result in delays and
increased costs if requirements change or new issues arise.
- Not Suitable for Complex Projects: The Waterfall Model is not well-suited for complex projects,
as the linear and sequential nature of the model can make it difficult to manage multiple
dependencies and interrelated components.
- Spiral Model

-
- The Spiral Model is one of the most important Software Development Life Cycle models, which
provides support for Risk Handling. In its diagrammatic representation, it looks like a spiral with
many loops. The exact number of loops of the spiral is unknown and can vary from project to
project. Each loop of the spiral is called a Phase of the software development process.
- The exact number of phases needed to develop the product can be varied by the project
manager depending upon the project risks. As the project manager dynamically determines the
number of phases, the project manager has an important role to develop a product using the
spiral model.
- The Spiral Model is a Software Development Life Cycle (SDLC) model that provides a systematic
and iterative approach to software development. It is based on the idea of a spiral, with each
iteration of the spiral representing a complete software development cycle, from requirements
gathering and analysis to design, implementation, testing, and maintenance.
- Software Crisis is a term used in computer science for the difficulty of writing useful and
efficient computer programs in the required time.
- Causes of Software Crisis
- The cost of owning and maintaining software was as expensive as developing the software.
- At that time Projects were running overtime.
- At that time Software was very inefficient.
- The quality of the software was low quality.
- Software often did not meet user requirements.
- The average software project overshoots its schedule by half.
- At that time Software was never delivered.
- Non-optimal resource utilization.
- Challenging to alter, debug, and enhance.
- The software complexity is harder to change.
- Factors Contributing to Software Crisis
- Poor project management.
- Lack of adequate training in software engineering.
- Less skilled project members.
- Low productivity improvements.
-
• Software project management:
1. Software Metrics
- A software metric is a measure of software characteristics which are measurable or countable.
Software metrics are valuable for many reasons, including measuring software performance,
planning work items, measuring productivity, and many other uses.
- Within the software development process, many metrics are that are all connected. Software
metrics are similar to the four functions of management: Planning, Organization, Control, or
Improvement.
- Classification of Software Metrics
- Software metrics can be classified into two types as follows:
- 1. Product Metrics: These are the measures of various characteristics of the software product.
The two important software characteristics are:
- Size and complexity of software.
- Quality and reliability of software.
- These metrics can be computed for different stages of SDLC.
- 2. Process Metrics: These are the measures of various characteristics of the software
development process. For example, the efficiency of fault detection. They are used to measure
the characteristics of methods, techniques, and tools that are used for developing software.
- Types of Metrics
- Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed
to be of greater importance to a software developer. For example, Lines of Code (LOC) measure.
- External metrics: External metrics are the metrics used for measuring properties that are viewed
to be of greater importance to the user, e.g., portability, reliability, functionality, usability, etc.
- Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource
metrics. For example, cost per FP where FP stands for Function Point Metric.
- Project metrics: Project metrics are the metrics used by the project manager to check the
project's progress. Data from the past projects are used to collect various metrics, like time and
cost; these estimates are used as a base of new software. Note that as the project proceeds, the
project manager will check its progress from time-to-time and will compare the effort, cost, and
time with the original effort, cost and time. Also understand that these metrics are used to
decrease the development costs, time efforts and risks. The project quality can also be
improved. As quality improves, the number of errors and time, as well as cost required, is also
reduced.
- Advantage of Software Metrics
- Comparative study of various design methodology of software systems.
- For analysis, comparison, and critical study of different programming language concerning their
characteristics.
- In comparing and evaluating the capabilities and productivity of people involved in software
development.
- In the preparation of software quality specifications.
- In the verification of compliance of software systems requirements and specifications.
- In making inference about the effort to be put in the design and development of the software
systems.
- In getting an idea about the complexity of the code.
- In taking decisions regarding further division of a complex module is to be done or not.
- In guiding resource manager for their proper utilization.
- In comparison, making design tradeoffs between software development and maintenance cost.
- In providing feedback to software managers about the progress and quality during various
phases of the software development life cycle.
- In the allocation of testing resources for testing the code.
-
1. Project management concepts
- Effective software project management focuses on the four P’s: people, product, process, and
project.
- The People - the cultivation of motivated, highly skilled software people, the people
management maturity model defines the following key practice areas for software people:
recruiting, selection, performance management, training, compensation, career development,
organization and work design, and team/culture development. Organizations that achieve high
 levels of maturity in the people management area have a higher likelihood of implementing
effective software engineering practices.
- The Product Before a project can be planned, product1 objectives and scope should be
established, alternative solutions should be considered, and technical and management
constraints should be identified. Without this information, it is impossible to define reasonable
(and accurate) estimates of the cost, an effective assessment of risk, a realistic breakdown of
project tasks, or a manageable project schedule that provides a meaningful indication of
progress.
- The Process A software process provides the framework from which a comprehensive plan for
software development can be established. A small number of framework activities are
applicable to all software projects, regardless of their size or complexity. A number of different
task sets—tasks, milestones, work products, and quality assurance points—enable the
framework activities to be adapted to the characteristics of the software project and the
requirements of the project team. Finally, umbrella activities—such as software quality
assurance, software configuration management, and measurement—overlay the process model.
Umbrella activities are independent of any one framework activity and occur throughout the
process.
- The Project We conduct planned and controlled software projects for one primary reason—it is
the only known way to manage complexity.
2. Project estimation Techniques
- In the early days of computing, software costs constituted a small percentage of the overall
computer-based system cost. An order of magnitude error in estimates of software cost had
relatively little impact.
- Today, software is the most expensive element of virtually all computer-based systems. For
complex, custom systems, a large cost estimation error can make the difference between profit
and loss. Cost overrun can be disastrous for the developer.
- Software cost and effort estimation will never be an exact science. Too many variables—human,
technical, environmental, political—can affect the ultimate cost of software and effort applied
to develop it.
- software project estimation can be transformed into a series of systematic steps that provide
estimates with acceptable risk. To achieve reliable cost and effort estimates, a number of
options arise:
I. Base estimates on similar projects that have already been completed.
II. Use relatively simple decomposition techniques to generate project cost and effort estimates.
III. Use one or more empirical models for software cost and effort estimation.
a. Decomposition techniques
- 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.
- Automated estimation tools implement one or more decomposition techniques or empirical
models. When combined with a graphical user interface, automated tools provide an attractive
option for estimating. In such systems, the characteristics of the development organization (e.g.,
experience, environment) and the software to be developed are described. Cost and effort
estimates are derived from these data.
- Empirical estimation model is based on experience (historical data) and takes the form d = f (vi)
where d is one of a number of estimated values (e.g., effort, cost, project duration) and vi are
selected independent parameters (e.g., estimated LOC or FP).
- COCOMO- COnstructive COst MOdel is a regression model based on LOC, i.e number of Lines of
Code. It is a procedural cost estimate model for software projects and is often used as a process
of reliably predicting the various parameters associated with making a project such as size,
effort, cost, time, and quality. It was proposed by Barry Boehm in 1981.
- The necessary steps in this model are:
I. Get an initial estimate of the development effort from evaluation of thousands of delivered lines
of source code (KDLOC).
II. Determine a set of 15 multiplying factors from various attributes of the project.
III. Calculate the effort estimate by multiplying the initial estimate with all the multiplying factors
i.e., multiply the values in step1 and step2.
- The initial estimate (also called nominal estimate) is determined by an equation of the form
used in the static single variable models, using KDLOC as the measure of the size. To determine
the initial effort Ei in person-months the equation used is of the type;

Ei=a*(KDLOC)b

- Different models of Cocomo have been proposed to predict the cost estimation at different
levels, based on the amount of accuracy and correctness required. All of these models can be
applied to a variety of projects, whose characteristics determine the value of the constant to be
used in subsequent calculations.
- These characteristics pertaining to different system types are mentioned below.
I. Organic – A software project is said to be an organic type if the team size required is adequately
small, the problem is well understood and has been solved in the past and also the team
members have nominal experience regarding the problem.
II. Semi-detached – A software project is said to be a Semi-detached type if the vital
characteristics such as team size, experience, and knowledge of the various programming
environment lie in between that of organic and Embedded. The projects classified as Semi-
Detached are comparatively less familiar and difficult to develop compared to the organic ones
and require more experience and better guidance and creativity. Ex: Compilers or different
Embedded Systems can be considered Semi-Detached types.
III. Embedded – A software project requiring the highest level of complexity, creativity, and
experience requirement fall under this category. Such software requires a larger team size than
the other two models and also the developers need to be sufficiently experienced and creative
to develop such complex models.
- Basic COCOMO Model –

Effort (E) = a(KLOC)b

Time(t) = c(E)d

Person Required = E/t

 The above formula is used for the cost estimation of for the basic COCOMO model, and also is
used in the subsequent models. The constant values a, b, c, and d for the Basic Model for the
different categories of the system:

Software a b c d
Projects

Organic 2.4 1.05 2.5 0.38

Semi-Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

- The effort is measured in Person-Months and as evident from the formula is dependent on Kilo-
Lines of code. The development time is measured in months. These formulas are used as such in
the Basic Model calculations, as not much consideration of different factors such as reliability,
and expertise is taken into account, henceforth the estimate is rough.
- Intermediate Model – The basic Cocomo model assumes that the effort is only a function of the
number of lines of code and some constants evaluated according to the different software
systems. In reality, no system’s effort and schedule can be solely calculated on the basis of Lines
of Code. For that, various other factors such as reliability, experience, and Capability. These
factors are known as Cost Drivers and the Intermediate Model utilizes 15 such drivers for cost
estimation. Classification of Cost Drivers and their Attributes:
I. Product attributes –
i. Required software reliability extent
ii. Size of the application database
iii. The complexity of the product
iv. Run-time performance constraints
v. Memory constraints
vi. The volatility of the virtual machine environment
vii. Required turnabout time
viii. Analyst capability
ix. Software engineering capability
x. Applications experience
xi. Virtual machine experience
xii. Programming language experience
xiii. Use of software tools
xiv. Application of software engineering methods
xv. Required development schedule
- Detailed Model – Detailed COCOMO incorporates all characteristics of the intermediate version
with an assessment of the cost driver’s impact on each step of the software engineering
 process. The detailed model uses different effort multipliers for each cost driver attribute. In
detailed cocomo, the whole software is divided into different modules and then we apply
COCOMO in different modules to estimate effort and then sum the effort. The Six phases of
detailed COCOMO are:
I. Planning and requirements
II. System design
III. Detailed design
IV. Module code and test
V. Integration and test
3. Risk analysis and management
- "risk" is a problem that could cause some loss or threaten the progress of the project, but which
has not happened yet.
- These potential issues might harm cost, schedule or technical success of the project and the
quality of our software device, or project team morale.
- Risk Management is the system of identifying, addressing and eliminating these problems
before they can damage the project.
- We need to differentiate risks, as potential issues, from the current problems of the project.
- Different methods are required to address these two kinds of issues.
- For example, staff storage, because we have not been able to select people with the right
technical skills, is a current problem, but the threat of our technical people being hired away by
the competition is a risk.
- Risk Management
- A software project can be concerned with a large variety of risks. In order to be adept to
systematically identify the significant risks which might affect a software project, it is essential to
classify risks into different classes. The project manager can then check which risks from each
class are relevant to the project.
- There are three main classifications of risks which can affect a software project:
- Project risks
- Technical risks
- Business risks
- 1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel, resource,
and customer-related problems. A vital project risk is schedule slippage. Since the software is
intangible, it is very tough to monitor and control a software project. It is very tough to control
something which cannot be identified. For any manufacturing program, such as the
manufacturing of cars, the plan executive can recognize the product taking shape.
- 2. Technical risks: Technical risks concern potential methods, implementation, interfacing,
testing, and maintenance issue. It also consists of an ambiguous specification, incomplete
specification, changing specification, technical uncertainty, and technical obsolescence. Most
technical risks appear due to the development team's insufficient knowledge of the project.
- 3. Business risks: This type of risks contain risks of building an excellent product that no one
need, losing budgetary or personnel commitments, etc.
- Other risk categories
- 1. Known risks: Those risks that can be uncovered after careful assessment of the project
program, the business and technical environment in which the plan is being developed, and
more reliable data sources (e.g., unrealistic delivery date)
- 2. Predictable risks: Those risks that are hypothesized from previous project experience (e.g.,
past turnover)
- 3. Unpredictable risks: Those risks that can and do occur but are extremely tough to identify in
advance.
- Principle of Risk Management
- Global Perspective: In this, we review the bigger system description, design, and
implementation. We look at the chance and the impact the risk is going to have.
- Take a forward-looking view: Consider the threat which may appear in the future and create
future plans for directing the next events.
- Open Communication: This is to allow the free flow of communication between the client and
the team members so that they have certainty about the risks.
- Integrated management: In this method risk management is made an integral part of project
management.
- Continuous process: In this phase, the risks are tracked continuously throughout the risk
management paradigm.
- Risk management consists of three main activities, as shown in fig:

- Risk Assessment
- The objective of risk assessment is to division the risks in the condition of their loss, causing
potential. For risk assessment, first, every risk should be rated in two methods: The possibility of
a risk coming true (denoted as r).
- The consequence of the issues relates to that risk (denoted as s).
- Based on these two methods, the priority of each risk can be estimated:
- p=r*s
- Where p is the priority with which the risk must be controlled, r is the probability of the risk
becoming true, and s is the severity of loss caused due to the risk becoming true. If all identified
 risks are set up, then the most likely and damaging risks can be controlled first, and more
comprehensive risk abatement methods can be designed for these risks.
- 1. Risk Identification: The project organizer needs to anticipate the risk in the project as early as
possible so that the impact of risk can be reduced by making effective risk management
planning.
- A project can be of use by a large variety of risk. To identify the significant risk, this might affect
a project. It is necessary to categories into the different risk of classes.
- There are different types of risks which can affect a software project:
- Technology risks: Risks that assume from the software or hardware technologies that are used
to develop the system.
- People risks: Risks that are connected with the person in the development team.
- Organizational risks: Risks that assume from the organizational environment where the software
is being developed.
- Tools risks: Risks that assume from the software tools and other support software used to create
the system.
- Requirement risks: Risks that assume from the changes to the customer requirement and the
process of managing the requirements change.
- Estimation risks: Risks that assume from the management estimates of the resources required
to build the system
- 2. Risk Analysis: During the risk analysis process, you have to consider every identified risk and
make a perception of the probability and seriousness of that risk.
- There is no simple way to do this. You have to rely on your perception and experience of
previous projects and the problems that arise in them.
- It is not possible to make an exact, the numerical estimate of the probability and seriousness of
each risk. Instead, you should authorize the risk to one of several bands:
- The probability of the risk might be determined as very low (0-10%), low (10-25%), moderate
(25-50%), high (50-75%) or very high (+75%).
- The effect of the risk might be determined as catastrophic (threaten the survival of the plan),
serious (would cause significant delays), tolerable (delays are within allowed contingency), or
insignificant.
- Risk Control
- It is the process of managing risks to achieve desired outcomes. After all, the identified risks of a
plan are determined; the project must be made to include the most harmful and the most likely
risks. Different risks need different containment methods. In fact, most risks need ingenuity on
the part of the project manager in tackling the risk.
- There are three main methods to plan for risk management:
- Avoid the risk: This may take several ways such as discussing with the client to change the
requirements to decrease the scope of the work, giving incentives to the engineers to avoid the
risk of human resources turnover, etc.
- Transfer the risk: This method involves getting the risky element developed by a third party,
buying insurance cover, etc.
- Risk reduction: This means planning method to include the loss due to risk. For instance, if there
is a risk that some key personnel might leave, new recruitment can be planned.
 - Risk Leverage: To choose between the various methods of handling risk, the project plan must
consider the amount of controlling the risk and the corresponding reduction of risk. For this, the
risk leverage of the various risks can be estimated.
- Risk leverage is the variation in risk exposure divided by the amount of reducing the risk.
- Risk leverage = (risk exposure before reduction - risk exposure after reduction) / (cost of
reduction)
- 1. Risk planning: The risk planning method considers each of the key risks that have been
identified and develops ways to maintain these risks.
- For each of the risks, you have to think of the behavior that you may take to minimize the
disruption to the plan if the issue identified in the risk occurs.
- You also should think about data that you might need to collect while monitoring the plan so
that issues can be anticipated.
- Again, there is no easy process that can be followed for contingency planning. It relies on the
judgment and experience of the project manager.
- 2. Risk Monitoring: Risk monitoring is the method king that your assumption about the product,
process, and business risks has not changed.
4. Project scheduling and tracking

Unit 2: Requirements Analysis and specification requirements engineering

1. System Modeling and simulation
- System engineering is a modeling process, the engineer creates models that -
I. Define the processes that serve the needs of the view under consideration.
II. Represent the behavior of the processes and the assumptions on which the behavior is based.
III. Explicitly define both exogenous and endogenous input to the model.
IV. Represent all linkages (including output) that will enable the engineer to better understand the
view
- To construct a system model, the engineer should consider a number of restraining factors;
i. Assumptions that reduce the number of possible permutations and variations, thus enabling a
model to reflect the problem in a reasonable manner.
ii. Simplifications that enable the model to be created in a timely manner.
iii. Limitations that help to bound the system.
iv. Constraints that will guide the manner in which the model is created, and the approach taken
when the model is implemented.
v. Preferences that indicate the preferred architecture for all data, functions, and technology.
2. Analysis principles modeling
- All analysis methods are related by a set of operational principles:
I. The information domain of a problem must be represented and understood.
II. The functions that the software is to perform must be defined.
III. The behavior of the software (as a consequence of external events) must be represented.
IV. The models that depict information, function, and behavior must be partitioned in a manner
that uncovers detail in a layered (or hierarchical) fashion.
V. The analysis process should move from essential information toward implementation detail.
- Analysis principles require that we build models of function and behavior.
I. Functional models. Software transforms information, it must perform at least three generic
functions: input, processing, and output. When functional models of an application are created,
the software engineer focuses on problem specific functions. The functional model begins with a
single context level model (i.e., the name of the software to be built). Over a series of iterations,
more and more functional details are provided, until a thorough delineation of all system
functionality is represented.
II. Behavioral models. Most software responds to events from the outside world. This
stimulus/response characteristic forms the basis of the behavioral model. A computer program
always exists in some state—an externally observable mode of behavior (e.g., waiting,
computing, printing, polling) that is changed only when some event occurs.
- Models created during requirements analysis serve a number of important roles:
I. The model aids the analyst in understanding the information, function, and behavior of a
system, thereby making the requirements analysis task easier and more systematic.
II. The model becomes the focal point for review and, therefore, the key to a determination of
completeness, consistency, and accuracy of the specifications.
III. The model becomes the foundation for design, providing the designer with an essential
representation of software that can be "mapped" into an implementation context.
- Partitioning: problems are often too large and complex to be understood as a whole. For this
reason, we tend to partition (divide) such problems into parts that can be easily understood and
establish interfaces between the parts so that overall function can be accomplished.
- The fourth operational analysis principle suggests that the information, functional, and
behavioral domains of software can be partitioned. In essence, partitioning decomposes a
problem into its constituent parts. Conceptually, we establish a hierarchical representation of
function or information and then partition the uppermost element by
I. exposing increasing detail by moving vertically in the hierarchy or
II. functionally decomposing the problem by moving horizontally in the hierarchy.
- Software prototyping: requirements elicitation is conducted, analysis principles are applied, and
a model of the software to be built, called a prototype, is constructed for customer and
developer assessment.
- Prototyping methods and tools: For software prototyping to be effective, a prototype must be
developed rapidly so that the customer may assess results and recommend changes. To conduct
rapid prototyping, three generic classes of methods and tools are available:
I. Fourth generation techniques. Fourth generation techniques (4GT) encompass a broad array of
database query and reporting languages, program and application generators, and other very
high-level nonprocedural languages. Because 4GT enables the software engineer to generate
executable code quickly, they are ideal for rapid prototyping.
II. Reusable software components. Another approach to rapid prototyping is to assemble, rather
than build, the prototype by using a set of existing software components. Melding prototyping
and program component reuse will work only if a library system is developed so that
components that do exist can be cataloged and then retrieved. It should be noted that an
existing software product can be used as a prototype for a "new, improved" competitive
product. In a way, this is a form of reusability for software prototyping.
 III. Formal specification and prototyping environments. A few formal specification languages and
tools have been developed as a replacement for natural language specification techniques.
developers of these formal languages are in the process of developing interactive environments
that
I. enable an analyst to interactively create language-based specifications of a system or software
II. invoke automated tools that translate the language-based specifications into executable code
III. enable the customer to use the prototype executable code to refine formal requirements
- Specification Principles: Several specification principles, can be proposed:
I. Separate functionality from implementation.
II. Develop a model of the desired behavior of a system that encompasses data and the functional
responses of a system to various stimuli from the environment.
III. Establish the context in which software operates by specifying the manner in which other
system components interact with software.
IV. Define the environment in which the system operates and indicate how “a highly intertwined
collection of agents reacts to stimuli in the environment (changes to objects) produced by those
agents”.
V. Create a cognitive model rather than a design or implementation model. The cognitive model
describes a system as perceived by its user community.
VI. Recognize that “the specifications must be tolerant of incompleteness and augmentable.” A
specification is always a model—an abstraction—of some.
- Representation: a simple set of guidelines is well worth following
I. Representation format and content should be relevant to the problem. A general outline for the
contents of a Software Requirements Specification can be developed. However, the
representation forms contained within the specification are likely to vary with the application
area.
II. Information contained within the specification should be nested.
III. Diagrams and other notational forms should be restricted in number and consistent in use.
IV. Representations should be revisable. The content of a specification will change. Ideally, CASE
tools should be available to update all representations that are affected by each change.
- The software requirements specification

The Software Requirements Specification is produced at the culmination of the analysis task.
proposed candidate formats for software requirements specifications-

i. The Introduction of the software requirements specification states the goals and objectives of
the software
ii. The Information Description provides a detailed description of the problem that the software
must solve
iii. A description of each function required to solve the problem is presented in the Functional
Description.
iv. Behavioral Description section of the specification examines the operation of the software as a
consequence of external events and internally generated control characteristics.
v. Specification of validation criteria acts as an implicit review of all other requirements.
- Specification review: A review of the Software Requirements Specification (and/or prototype) is
conducted by both the software developer and the customer.
- The review is first conducted at a macroscopic level; that is, reviewers attempt to ensure that
the specification is complete, consistent, and accurate when the overall information, functional,
and behavioral domains are considered.
- Once the review is complete, the Software Requirements Specification is "signed off" by both
the customer and the developer. The specification becomes a "contract" for software
development.
3. Analysis Modelling
- The analysis model, actually a set of models, is the first technical representation of a system and
a comprehensive design representation for the software to be built.
- The analysis model must achieve three primary objectives:
I. to describe what the customer requires,
II. to establish a basis for the creation of a software design
III. to define a set of requirements that can be validated once the software is built.
- Data Modeling: The data model consists of three interrelated pieces of information: the data
object, the attributes that describe the data object, and the relationships that connect data
objects to one another.
a. Data objects. A data object is a representation of almost any composite information that must
be understood by software. By composite information, we mean something that has a number
of different properties or attributes. Therefore, width (a single value) would not be a valid data
object, but dimensions (incorporating height, width, and depth) could be defined as an object.
b. Attributes. Attributes define the properties of a data object and take on one of three different
characteristics. They can be used to
I. name an instance of the data object,
II. describe the instance, or
III. make reference to another instance in another table.

In addition, one or more of the attributes must be defined as an identifier—that is, the identifier
attribute becomes a "key" when we want to find an instance of the data object.

c. Relationships. Data objects are connected to one another in different ways.

d. Cardinality. Cardinality is the specification of the number of occurrences of one [object] that can
be related to the number of occurrences of another [object].
Taking into consideration all combinations of 'one' and 'many,' two [objects] can be related as
i. One-to-one (1:1)—An occurrence of [object] 'A' can relate to one and only one occurrence of
[object] 'B,' and an occurrence of 'B' can relate to only one occurrence of 'A.'
ii. One-to-many (1: N)—One occurrence of [object] 'A' can relate to one or many occurrences of
[object] 'B,' but an occurrence of 'B' can relate to only one occurrence of 'A.'
iii. Many-to-many (M: N)—An occurrence of [object] 'A' can relate to one or more occurrences
of 'B,' while an occurrence of 'B' can relate to one or more occurrences of 'A.' Cardinality defines
“the maximum number of objects that can participate in a relationship”
e. Modality. The modality of a relationship is 0 if there is no explicit need for the relationship to
occur or the relationship is optional. The modality is 1 if an occurrence of the relationship is
mandatory
- Entity/Relationship Diagrams: The object/relationship pairs can be represented graphically using
the entity/relationship diagram. s. A set of primary components are identified for the ERD: data
 objects, attributes, relationships, and various type indicators. The primary purpose of the ERD is
to represent data objects and their relationships.
- Data objects are represented by a labeled rectangle. Relationships are indicated with a labeled
line connecting objects. In some variations of the ERD, the connecting line contains a diamond
that is labeled with the relationship. Connections between data objects and relationships are
established using a variety of special symbols that indicate cardinality and modality
- Function Modeling and information flow: we can create a flow model for any computer-based
system, regardless of size and complexity.
I. A rectangle is used to represent an external entity; that is, a system element (e.g., hardware, a
person, another program) or another system that produces information for transformation by
the software or receives information produced by the software.
II. A circle (sometimes called a bubble) represents a process or transform that is applied to data (or
control) and changes it in some way.
III. An arrow represents one or more data items (data objects). All arrows on a data flow diagram
should be labeled.
IV. The double line represents a data store—stored information that is used by the software. The
simplicity of DFD notation is one reason why structured analysis techniques are widely used.
- It is important to note that no explicit indication of the sequence of processing or conditional
logic is supplied by the diagram. Procedure or sequence may be implicit in the diagram, but
explicit logical details are generally delayed until software design
- Data Flow Diagrams: As information moves through software, it is modified by a series of
transformations. A data flow diagram is a graphical representation that depicts information flow
and the transformations that are applied as data move from input to output.

- The data flow diagram may be used to represent a system or software at any level of
abstraction. In fact, DFDs may be partitioned into levels that represent increasing information
flow and functional detail. Therefore, the DFD provides a mechanism for functional modeling as
well as information flow modeling.
- Behavioral Modeling: Behavioral modeling is an operational principle for all requirements
analysis methods.
- A state is any observable mode of behavior. Each of these states represents a mode of behavior
of the system. A state transition diagram indicates how the system moves from state to state.
4. The mechanics of structured analysis
- To be used effectively in software requirements analysis, this notation must be combined with a
set of heuristics that enable a software engineer to derive a good analysis model.
- Creating an Entity/Relationship Diagram the ERD is constructed in an iterative manner. The
following approach is taken:
I. During requirements elicitation, customers are asked to list the “things” that the application or
business process addresses. These “things” evolve into a list of input and output data objects as
well as external entities that produce or consume information.
II. Taking the objects one at a time, the analyst and customer define whether or not a connection
(unnamed at this stage) exists between the data object and other objects.
III. Wherever a connection exists, the analyst and the customer create one or more
object/relationship pairs.
IV. For each object/relationship pair, cardinality and modality are explored.
V. Steps 2 through 4 are continued iteratively until all object/relationships have been defined. It is
common to discover omissions as this process continues. New objects and relationships will
invariably be added as the number of iterations grows.
VI. The attributes of each entity are defined.
VII. An entity relationship diagram is formalized and reviewed.
VIII. Steps 1 through 7 are repeated until data modeling is complete.
- Creating a Data Flow Model: A few simple guidelines can aid immeasurably during derivation of
a data flow diagram-
I. the level 0 data flow diagram should depict the software/system as a single bubble;
II. primary input and output should be carefully noted;
III. refinement should begin by isolating candidate processes, data objects, and stores to be
represented at the next level;
IV. all arrows and bubbles should be labeled with meaningful names;
V. information flow continuity must be maintained from level to level, and
VI. one bubble at a time should be refined.
- Creating a Control Flow Model: To review the approach for creating a CFD, a data flow model is
"stripped" of all data flow arrows. Events and control items (dashed arrows) are then added to
the diagram and a "window" (a vertical bar) into the control specification is shown. An event or
control item is implemented as a Boolean value (e.g., true or false, on or off, 1 or 0) or a discrete
list of conditions (empty, jammed, full). To select potential candidate events, the following
guidelines are suggested:
I. List all sensors that are "read" by the software.
II. List all interrupt conditions.
III. List all "switches" that are actuated by an operator.
IV. List all data conditions.
V. Recalling the noun/verb parse that was applied to the processing narrative, review all "control
items" as possible CSPEC inputs/outputs.
VI. Describe the behavior of a system by identifying its states; identify how each state is reached;
and define the transitions between states.
VII. Focus on possible omissions—a very common error in specifying control.
- The Control Specification: The control specification (CSPEC) represents the behavior of the
system (at the level from which it has been referenced) in two different ways. The CSPEC
contains a state transition diagram that is a sequential specification of behavior. It can also
contain a program activation table—a combinatorial specification of behavior.
- The Process Specification The process specification (PSPEC) is used to describe all flow model
processes that appear at the final level of refinement. The content of the process specification
can include narrative text, a program design language (PDL) description of the process
algorithm, mathematical equations, tables, diagrams, or charts. By providing a PSPEC to
accompany each bubble in the flow model, the software engineer creates a "mini spec" that can
serve as a first step in the creation of the Software Requirements Specification and as a guide
for design of the software component that will implement the process.
5. The data dictionary
- The data dictionary is an organized listing of all data elements that are pertinent to the system,
with precise, rigorous definitions so that both user and system analyst will have a common
understanding of inputs, outputs, components of stores and [even] intermediate calculations.
- The format of dictionaries varies from tool to tool, most contain the following information:
I. Name—the primary name of the data or control item, the data store or an external entity.
II. Alias—other names used for the first entry.
III. Where-used/how-used—a listing of the processes that use the data or control item and how it
is used (e.g., input to the process, output from the process, as a store, as an external entity.
IV. Content description—a notation for representing content.
V. Supplementary information—other information about data types, preset values (if known),
restrictions or limitations, and so forth.
• System Design:
1. Design concepts and principles
- Basic design principles enable the software engineer to navigate the design process. A set of
principles for software design-
i. The design process should not suffer from “tunnel vision.” A good designer should consider
alternative approaches.
ii. The design should be traceable to the analysis model. Because a single element of the design
model often traces to multiple requirements, it is necessary to have a means for tracking how
requirements have been satisfied by the design model.
iii. The design should not reinvent the wheel, Systems are constructed using a set of design
patterns, many of which have likely been encountered before. These patterns should always be
chosen as an alternative to reinvention.
iv. The design should “minimize the intellectual distance” between the software and the problem
as it exists in the real world. That is, the structure of the software design should (whenever
possible) mimic the structure of the problem domain.
v. The design should exhibit uniformity and integration. A design is uniform if it appears that one
person developed the entire thing.
vi. • The design should be structured to accommodate change. The design concepts discussed in
the next section enable a design to achieve this principle. • The design should be structured to
 degrade gently, even when aberrant data, events, or operating conditions are encountered.
Well-designed software should never “bomb.” It should be designed to accommodate unusual
circumstances, and if it must terminate processing, do so in a graceful manner. • Design is not
coding, coding is not design. Even when detailed procedural designs are created for program
components, the level of abstraction of the design model is higher than source code. The only
design decisions made at the coding level address the small implementation details that enable
the procedural design to be coded. • The design should be assessed for quality as it is being
created, not after the fact. A variety of design concepts (Section 13.4) and design measures
(Chapters 19 and 24) are available to assist the designer in assessing quality. • The design should
be reviewed to minimize conceptual (semantic) errors. There is sometimes a tendency to focus
on minutiae when the design is reviewed, missing the forest for the trees. A design team should
ensure that major conceptual elements of the design (omissions, ambiguity, inconsistency) have
been addressed before worrying about the syntax of the design model.
vii. The design should be structured to accommodate change.
viii. The design should be structured to degrade gently, even when aberrant data, events, or
operating conditions are encountered. It should be designed to accommodate unusual
circumstances, and if it must terminate processing, do so in a graceful manner.
ix. Design is not coding; coding is not design. The only design decisions made at the coding level
address the small implementation details that enable the procedural design to be coded.
x. The design should be assessed for quality as it is being created, not after the facts.
- Fundamental software design concepts provide the necessary framework for "getting it right."
- Abstraction: psychological notion of "abstraction" permits one to concentrate on a problem at
some level of generalization without regard to irrelevant low-level details; use of abstraction
also permits one to work with concepts and terms that are familiar in the problem environment
without having to transform them to an unfamiliar structure.
I. A procedural abstraction is a named sequence of instructions that has a specific and limited
function.
II. A data abstraction is a named collection of data that describes a data object
III. Control abstraction is the third form of abstraction used in software design. Like procedural and
data abstraction, control abstraction implies a program control mechanism without specifying
internal details.
- Refinement Stepwise refinement is a top-down design strategy. A program is developed by
successively refining levels of procedural detail. A hierarchy is developed by decomposing a
macroscopic statement of function (a procedural abstraction) in a stepwise fashion until
programming language statements are reached.
- In each step (of the refinement), one or several instructions of the given program are
decomposed into more detailed instructions. This successive decomposition or refinement of
specifications terminates when all instructions are expressed in terms of any underlying
computer or programming language.
- As tasks are refined, the data may have to be refined, decomposed, or structured, and it is
natural to refine the program and the data specifications in parallel. Every refinement step
implies some design decisions. It is important that the programmer be aware of the underlying
criteria (for design decisions) and of the existence of alternative solutions.
- Modularity: software is divided into separately named and addressable components, often
called modules, that are integrated to satisfy problem requirements. It has been stated that
"modularity is the single attribute of software that allows a program to be intellectually
manageable" five criteria that enable us to evaluate a design method with respect to its ability
to define an effective modular system:
I. Modular decomposability. If a design method provides a systematic mechanism for
decomposing the problem into subproblems, it will reduce the complexity of the overall
problem, thereby achieving an effective modular solution.
II. Modular composability. If a design method enables existing (reusable) design components to be
assembled into a new system, it will yield a modular solution that does not reinvent the wheel.
III. Modular understandability. If a module can be understood as a stand-alone unit (without
reference to other modules), it will be easier to build and easier to change.
IV. Modular continuity. If small changes to the system requirements result in changes to individual
modules, rather than systemwide changes, the impact of change-induced side effects will be
minimized.
V. Modular protection. If an aberrant condition occurs within a module and its effects are
constrained within that module, the impact of error-induced side effects will be minimized
- Software architecture alludes to “the overall structure of the software and the ways in which
that structure provides conceptual integrity for a system” architecture is the hierarchical
structure of program components (modules), the manner in which these components interact
and the structure of data that are used by the components.
- describe a set of properties that should be specified as part of an architectural design:
I. Structural properties. This aspect of the architectural design representation defines the
components of a system (e.g., modules, objects, filters) and the manner in which those
components are packaged and interact with one another. For example, objects are packaged to
encapsulate both data and the processing that manipulates the data and interact via the
invocation of methods.
II. Extra-functional properties. The architectural design description should address how the design
architecture achieves requirements for performance, capacity, reliability, security, adaptability,
and other system characteristics.
III. Families of related systems. The architectural design should draw upon repeatable patterns that
are commonly encountered in the design of families of similar systems. In essence, the design
should have the ability to reuse architectural building blocks.
- Control hierarchy, also called program structure, represents the organization of program
components (modules) and implies a hierarchy of control.
- The control hierarchy also represents two subtly different characteristics of the software
architecture: visibility and connectivity. Visibility indicates the set of program components that
may be invoked or used as data by a given component, even when this is accomplished
indirectly.
- Connectivity indicates the set of components that are directly invoked or used as data by a given
component. For example, a module that directly causes another module to begin execution is
connected to it.
- Structural Partitioning If the architectural style of a system is hierarchical, the program structure
can be partitioned both horizontally and vertically.
a. horizontal partitioning defines separate branches of the modular hierarchy for each major
program function. Control modules, represented in a darker shade, are used to coordinate
communication between and execution of the functions. The simplest approach to horizontal
partitioning defines three partitions—input, data transformation (often called processing) and
output. Partitioning the architecture horizontally provides a number of distinct benefits:
I. software that is easier to test
II. software that is easier to maintain
III. propagation of fewer side effects
IV. software that is easier to extend
b. Vertical partitioning, often called factoring, suggests that control (decision making) and work
should be distributed top-down in the program structure. Top level modules should perform
control functions and do-little actual processing work. Modules that reside low in the structure
should be the workers, performing all input, computation, and output tasks.
- Data structure is a representation of the logical relationship among individual elements of data.
- Data structure dictates the organization, methods of access, degree of associativity, and
processing alternatives for information.
- The organization and complexity of a data structure are limited only by the ingenuity of the
designer.
- A scalar item is the simplest of all data structures. A scalar item represents a single element of
information that may be addressed by an identifier; that is, access may be achieved by
specifying a single address in memory.
- When scalar items are organized as a list or contiguous group, a sequential vector is formed.
Vectors are the most common of all data structures and open the door to variable indexing of
information. When the sequential vector is extended to two, three, and ultimately, an arbitrary
number of dimensions, an n-dimensional space is created. The most common n-dimensional
space is the two-dimensional matrix. In many programming languages, an n-dimensional space
is called an array.
- Items, vectors, and spaces may be organized in a variety of formats. A linked list is a data
structure that organizes noncontiguous scalar items, vectors, or spaces in a manner (called
nodes) that enables them to be processed as a list. Each node contains the appropriate data
organization (e.g., a vector) and one or more pointers that indicate the address in storage of the
next node in the list. Nodes may be added at any point in the list by redefining pointers to
accommodate the new list entry.
- Other data structures incorporate or are constructed using the fundamental data structures.
- Software Procedure Program structure defines control hierarchy without regard to the sequence
of processing and decisions. Software procedure focuses on the processing details of each
module individually. Procedure must provide a precise specification of processing, including
sequence of events, exact decision points, repetitive operations, and even data organization and
structure.
- Information Hiding: modules should be specified and designed so that information (procedure
and data) contained within a module is inaccessible to other modules that have no need for
such information. Hiding implies that effective modularity can be achieved by defining a set of
independent modules that communicate with one another only that information necessary to
 achieve software function. Hiding defines and enforces access constraints to both procedural
detail within a module and any local data structure used by the module
2. Effective modular design:
- Functional Independence is achieved by developing modules with "single-minded" function and
an "aversion" to excessive interaction with other modules.
- Software with effective modularity, that is, independent modules, is easier to develop because
function may be compartmentalized, and interfaces are simplified (consider the ramifications
when development is conducted by a team). Independent modules are easier to maintain (and
test) because secondary effects caused by design or code modification are limited, error
propagation is reduced, and reusable modules are possible.
- Independence is measured using two qualitative criteria: cohesion and coupling. Cohesion is a
measure of the relative functional strength of a module. Coupling is a measure of the relative
interdependence among modules.
- Coupling refers to the degree of interdependence between software modules. High coupling
means that modules are closely connected and changes in one module may affect other
modules. Low coupling means that modules are independent and changes in one module have
little impact on other modules.
- Types of Coupling:
- Data Coupling: If the dependency between the modules is based on the fact that they
communicate by passing only data, then the modules are said to be data coupled. In data
coupling, the components are independent of each other and communicate through data.
Module communications don’t contain tramp data. Example-customer billing system.
- Stamp Coupling In stamp coupling, the complete data structure is passed from one module to
another module. Therefore, it involves tramp data. It may be necessary due to efficiency factors-
this choice was made by the insightful designer, not a lazy programmer.
- Control Coupling: If the modules communicate by passing control information, then they are
said to be control coupled. It can be bad if parameters indicate completely different behavior
and good if parameters allow factoring and reuse of functionality. Example- sort function that
takes comparison function as an argument.
- External Coupling: In external coupling, the modules depend on other modules, external to the
software being developed or to a particular type of hardware. Ex- protocol, external file, device
format, etc.
- Common Coupling: The modules have shared data such as global data structures. The changes in
global data mean tracing back to all modules which access that data to evaluate the effect of the
change. So, it has got disadvantages like difficulty in reusing modules, reduced ability to control
data accesses, and reduced maintainability.
- Content Coupling: In a content coupling, one module can modify the data of another module, or
control flow is passed from one module to the other module. This is the worst form of coupling
and should be avoided.
- Temporal Coupling: Temporal coupling occurs when two modules depend on the timing or order
of events, such as one module needing to execute before another. This type of coupling can
result in design issues and difficulties in testing and maintenance.
- Sequential Coupling: Sequential coupling occurs when the output of one module is used as the
input of another module, creating a chain or sequence of dependencies. This type of coupling
can be difficult to maintain and modify.
- Communicational Coupling: Communicational coupling occurs when two or more modules share
a common communication mechanism, such as a shared message queue or database. This type
of coupling can lead to performance issues and difficulty in debugging.
- Functional Coupling: Functional coupling occurs when two modules depend on each other’s
functionality, such as one module calling a function from another module. This type of coupling
can result in tightly coupled code that is difficult to modify and maintain.
- Data-Structured Coupling: Data-structured coupling occurs when two or more modules share a
common data structure, such as a database table or data file. This type of coupling can lead to
difficulty in maintaining the integrity of the data structure and can result in performance issues.
- Interaction Coupling: Interaction coupling occurs due to the methods of a class invoking
methods of other classes. Like with functions, the worst form of coupling here is if methods
directly access internal parts of other methods. Coupling is lowest if methods communicate
directly through parameters.
- Component Coupling: Component coupling refers to the interaction between two classes where
a class has variables of the other class.
- Cohesion refers to the degree to which elements within a module work together to fulfill a
single, well-defined purpose. High cohesion means that elements are closely related and
focused on a single purpose, while low cohesion means that elements are loosely related and
serve multiple purposes.
- Types of Cohesion:
- Functional Cohesion: Every essential element for a single computation is contained in the
component. A functional cohesion performs the task and functions. It is an ideal situation.
- Sequential Cohesion: An element outputs some data that becomes the input for other element,
i.e., data flow between the parts. It occurs naturally in functional programming languages.
- Communicational Cohesion: Two elements operate on the same input data or contribute
towards the same output data. Example- update record in the database and send it to the
printer.
- Procedural Cohesion: Elements of procedural cohesion ensure the order of execution. Actions
are still weakly connected and unlikely to be reusable. Ex- calculate student GPA, print student
record, calculate cumulative GPA, print cumulative GPA.
- Temporal Cohesion: The elements are related by their timing involved. A module connected
with temporal cohesion all the tasks must be executed in the same time span. This cohesion
contains the code for initializing all the parts of the system. Lots of different activities occur, all
at unit time.
- Logical Cohesion: The elements are logically related and not functionally. Ex- A component reads
inputs from tape, disk, and network. All the code for these functions is in the same component.
Operations are related, but the functions are significantly different.
- Coincidental Cohesion: The elements are not related(unrelated). The elements have no
conceptual relationship other than location in source code. It is accidental and the worst form of
cohesion. Ex- print next line and reverse the characters of a string in a single component.
- Procedural Cohesion: This type of cohesion occurs when elements or tasks are grouped together
in a module based on their sequence of execution, such as a module that performs a set of
related procedures in a specific order. Procedural cohesion can be found in structured
programming languages.
- Communicational Cohesion: Communicational cohesion occurs when elements or tasks are
grouped together in a module based on their interactions with each other, such as a module
that handles all interactions with a specific external system or module. This type of cohesion can
be found in object-oriented programming languages.
- Temporal Cohesion: Temporal cohesion occurs when elements or tasks are grouped together in
a module based on their timing or frequency of execution, such as a module that handles all
periodic or scheduled tasks in a system. Temporal cohesion is commonly used in real-time and
embedded systems.
- Informational Cohesion: Informational cohesion occurs when elements or tasks are grouped
together in a module based on their relationship to a specific data structure or object, such as a
module that operates on a specific data type or object. Informational cohesion is commonly
used in object-oriented programming.
- Functional Cohesion: This type of cohesion occurs when all elements or tasks in a module
contribute to a single well-defined function or purpose, and there is little or no coupling
between the elements. Functional cohesion is considered the most desirable type of cohesion as
it leads to more maintainable and reusable code.
- Layer Cohesion: Layer cohesion occurs when elements or tasks in a module are grouped
together based on their level of abstraction or responsibility
- Advantages of low coupling:
- Improved maintainability: Low coupling reduces the impact of changes in one module on other
modules, making it easier to modify or replace individual components without affecting the
entire system.
- Enhanced modularity: Low coupling allows modules to be developed and tested in isolation,
improving the modularity and reusability of code.
- Better scalability: Low coupling facilitates the addition of new modules and the removal of
existing ones, making it easier to scale the system as needed.
- Advantages of high cohesion:
- Improved readability and understandability: High cohesion results in clear, focused modules
with a single, well-defined purpose, making it easier for developers to understand the code and
make changes.
- Better error isolation: High cohesion reduces the likelihood that a change in one part of a
module will affect other parts, making it easier to
- isolate and fix errors. Improved reliability: High cohesion leads to modules that are less prone to
errors and that function more consistently,
- leading to an overall improvement in the reliability of the system.
- Disadvantages of high coupling:
- Increased complexity: High coupling increases the interdependence between modules, making
the system more complex and difficult to understand.
- Reduced flexibility: High coupling makes it more difficult to modify or replace individual
components without affecting the entire system.
 - Decreased modularity: High coupling makes it more difficult to develop and test modules in
isolation, reducing the modularity and reusability of code.
- Disadvantages of low cohesion:
- Increased code duplication: Low cohesion can lead to the duplication of code, as elements that
belong together are split into separate modules.
- Reduced functionality: Low cohesion can result in modules that lack a clear purpose and contain
elements that don’t belong together, reducing their functionality and making them harder to
maintain.
- Difficulty in understanding the module: Low cohesion can make it harder for developers to
understand the purpose and behavior of a module, leading to errors and a lack of clarity.

Unit 3: Architectural Design

• Software architecture
- The software architecture of a program or computing system is the structure or
structures of the system, which comprise software components, the externally visible
properties of those components, and the relationships among them.
- The architecture is not operational software. Rather, it is a representation that enables a
software engineer to
I. analyze the effectiveness of the design in meeting its stated requirements,
II. consider architectural alternatives at a stage when making design changes is still relatively easy,
and
III. reducing the risks associated with the construction of the software.
- three key reasons that software architecture is important:
I. Representations of software architecture are an enabler for communication between all parties
(stakeholders) interested in the development of a computer-based system.
II. The architecture highlights early design decisions that will have a profound impact on all
software engineering work that follows and, as important, on the ultimate success of the system
as an operational entity.
III. Architecture “constitutes a relatively small, intellectually graspable model of how the system is
structured and how its components work together”.
1. Data Design
- Data design 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. 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.
2. Data Modeling, Data Structures, Databases, and the Data Warehouse
- A data warehouse is a large, independent database that encompasses some, but not all, of the
data that are stored in databases that serve the set of applications required by a business. But
many characteristics differentiate a data warehouse from the typical database.
- a. Subject orientation - A data warehouse is organized by major business subjects, rather than
by business process or function. This leads to the exclusion of data that may be necessary for a
particular business function but is generally not necessary for data mining.
b. Integration - Regardless of the source, the data exhibits consistent naming conventions, units
and measures, encoding structures, and physical attributes, even when inconsistency exists
across different application-oriented databases.
c. Time variance - For a data warehouse, data can be accessed at a specific moment in time. The
typical time horizon for a data warehouse is five to ten years.
d. Nonvolatility -Unlike typical business application databases that undergo a continuing stream
of changes (inserts, deletes, updates), data are loaded into the warehouse, but after the original
transfer, the data does not change. These characteristics present a unique set of design
challenges for a data architect.
3. Analyzing alternative Architectural Designs
- we consider two different approaches for the analysis of alternative architectural designs-
a. An Architecture Trade-off Analysis Method the Software Engineering Institute (SEI) has
developed an architecture trade-off analysis method that establishes an iterative evaluation
process for software architectures. The design analysis activities that follow are performed
iteratively-
I. Collect scenarios. A set of use-cases is developed to represent the system from the user’s point
of view.
II. Elicit requirements, constraints, and environment description. This information is required as
part of engineering requirements and is used to be certain that all customer, user, and
stakeholder concerns have been addressed.
III. Describe the architectural styles/patterns that have been chosen to address the scenarios and
requirements. The style(s) should be described using architectural views such
as
• Module view for analysis of work assignments with components and the degree to which
information hiding has been achieved.

• Process view for analysis of system performance.

• Data flow view for analysis of the degree to which the architecture meets functional
requirements

IV. Evaluate quality attributes by considering each attribute in isolation. The number of quality
attributes chosen for analysis is a function of the time available for review and the degree to
which quality attributes are relevant to the system at hand. Quality attributes for architectural
 design assessment include reliability, performance, security, maintainability, flexibility,
testability, portability, reusability, and interoperability.
V. Identify the sensitivity of quality attributes to various architectural attributes for a specific
architectural style. This can be accomplished by making small changes in the architecture and
determining how sensitive a quality attribute, say performance, is to the change. Any attributes
that are significantly affected by variation in the architecture are termed sensitivity points.
VI. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in
step 5. The SEI describes this approach in a manner that architectural sensitivity points have
been determined, finding trade-off points is simply the identification of architectural elements
to which multiple attributes are sensitive.
b. Quantitative Guidance for Architectural Design
- spectrum analysis, assesses an architectural design on a “goodness” spectrum from the best to
worst possible designs. Once the software architecture has been proposed, it is assessed by
assigning a “score” to each of its design dimensions. These dimension scores are summed to
determine the total score, S, of the design. Worst-case scores are then assigned to a
hypothetical design, and a total score, Sw, for the worst-case architecture is computed. A best-
case score, Sb, is computed for an optimal design.
- We then calculate a spectrum index, Is, using the equation Is = [(S - Sw)/ (Sb - Sw)] x 100 The
spectrum index indicates the degree to which a proposed architecture approaches an optimal
system within the spectrum of reasonable choices for a design.

If modifications are made to the proposed design or if an entirely new design is proposed, the
spectrum indices for both may be compared and an improvement index, Imp, may be
computed: Imp = Is1 - Is2

This provides a designer with a relative indication of the improvement associated with
architectural changes or a newly proposed architecture. If Imp is positive, then we can conclude
that system 1 has been improved relative to system 2.

- Design selection analysis is another model that requires a set of design dimensions to be
defined. The proposed architecture is then assessed to determine the number of design
dimensions that it achieves when compared to an ideal (best-case) system. For example, if a
proposed architecture would achieve excellent component reuse, and this dimension is required
for an idea system, the reusability dimension has been achieved. If the proposed architecture
has weak security and strong security is required, that design dimension has not been achieved.
We calculate a design selection index, d, as d = (Ns/Na) x 100

where Ns is the number of design dimensions achieved by a proposed architecture and Na is the
total number of dimensions in the design space. The higher the design selection index, the more
closely the proposed architecture approaches an ideal system.

- Contribution analysis “identifies the reasons that one set of design choices gets a lower score
than another” value analysis is conducted to determine the relative priority of requirements
determined during function deployment, information deployment, and task deployment. A set
of “realization mechanisms” (features of the architecture) are identified. All customer
requirements (determined using QFD) are listed, and a cross-reference matrix is created. The
cells of the matrix indicate the relative strength of the relationship (on a numeric scale of 1 to
 10) between a realization mechanism and a requirement for each alternative architecture. This
is sometimes called a quantified design space (QDS). The QDS is relatively easy to implement as
a spreadsheet model and can be used to isolate why one set of design choices gets a lower score
than another.
4. Architectural complexity
- A useful technique for assessing the overall complexity of a proposed architecture is to consider
dependencies between components within the architecture. These dependencies are driven by
information/control flow within the system.
- Three types of dependencies:
I. Sharing dependencies represent dependent relationships among consumers who use the same
resource or producers who produce for the same consumers. For example, for two components
u and v, if u and v refer to the same global data, then there exists a shared dependence
relationship between u and v.
II. Flow dependencies represent dependent relationships between producers and consumers of
resources. For example, for two components u and v, if u must complete before control flows
into v (prerequisite), or if u communicates with v by parameters, then there exists a flow
dependence relationship between u and v.
III. Constrained dependencies represent constraints on the relative flow of control among a set of
activities. For example, for two components u and v, u and v cannot execute at the same time
(mutual exclusion), then there exists a constrained dependence relationship between u and v.
5. Mapping requirements into a software architecture
- The mapping technique to be presented enables a designer to derive reasonably complex call
and return architectures from data flow diagrams within the requirements model. The
technique, sometimes called structured design.
- Structured design is often characterized as a data flow-oriented design method because it
provides a convenient transition from a data flow diagram to software architecture.7 The
transition from information flow (represented as a DFD) to program structure is accomplished as
part of a six-step process:
I. the type of information flow is established;
II. flow boundaries are indicated;
III. the DFD is mapped into program structure;
IV. control hierarchy is defined;
V. resultant structure is refined using design measures and heuristics;
VI. The architectural description is refined and elaborate.
- The type of information flow is the driver for the mapping approach required in step 3. In the
following sections we examine two flow types.
a. Transform flow
- Externalized data must be converted into an internal form for processing.
- Information enters the system along paths that transform external data into an internal form.
These paths are identified as incoming flow.
- At the kernel of the software, a transition occurs. Incoming data are passed through a transform
center and begin to move along paths that now lead "out" of the software.
 - Data moving along these paths are called outgoing flow. The overall flow of data occurs in a
sequential manner and follows one, or only a few, "straight line" paths. When a segment of a
data flow diagram exhibits these characteristics, transform flow is present.
b. Transaction Flow
- Information flow is often characterized by a single data item, called a transaction, that triggers
other data flow along one of many paths.
- Transaction flow is characterized by data moving along an incoming path that converts external
world information into a transaction. The transaction is evaluated and based on its value, flow
along one of many action paths is initiated. The hub of information flow from which many action
paths emanate is called a transaction center.

6. Transform Mapping
- Transform mapping is a set of design steps that allows a DFD with transform flow characteristics
to be mapped into a specific architectural style.
- Design Steps.

The steps begin with a re-evaluation of work done during requirements analysis and then move to the
design of the software architecture.

i. Review the fundamental system model. This includes understanding the system's purpose, its
environment, and its users.
ii. Review and refine data flow diagrams for the software. This includes identifying the transforms
(processes) and the data flows (data that is passed between transforms).
iii. Determine whether the DFD has transform or transaction flow characteristics. Transform flow
occurs when a single transform receives data from one or more sources, transforms it, and then
sends it to one or more destinations. Transaction flow occurs when a single transform receives
data from one source, transforms it, and then sends it to a single destination.
iv. Isolate the transform center by specifying incoming and outgoing flow boundaries. The
transform center is the central part of the DFD where the transforms are located. The incoming
flow boundaries are the data flows that enter the transform center, and the outgoing flow
boundaries are the data flows that exit the transform center.
v. Perform "first-level factoring." This involves dividing the transform center into smaller modules.
The modules are identified by the data flows that enter and exit them.
vi. Perform "second-level factoring." This involves dividing the modules into even smaller modules.
The modules are identified by the data flows that enter and exit them.
vii. Refine the first-iteration architecture using design heuristics for improved software quality. This
involves applying design heuristics to the architecture to improve its quality. Design heuristics
are guidelines that can be used to improve the quality of software architecture.
• Testing and maintenance
- The development of software systems involves a series of production activities where
opportunities for injection of human fallibilities are enormous.
1. Software testing fundamentals
- Testing Objectives states a number of rules that can serve well as testing objectives:
I. Testing is a process of executing a program with the intent of finding an error.
II. A good test case is one that has a high probability of finding an as-yet undiscovered error.
III. A successful test is one that uncovers an as-yet-undiscovered error.
- Testing Principles
I. All tests should be traceable to customer requirements.
II. Tests should be planned long before testing begins.
III. The Pareto principle applies to software testing.
IV. Testing should begin “in the small” and progress toward testing “in the large.”
V. Exhaustive testing is not possible.
VI. To be most effective, testing should be conducted by an independent third party.
- Testability

The checklist that follows provides a set of characteristics that lead to testable software.

i. Operability. "The better it works, the more efficiently it can be tested."

• The system has few bugs (bugs add analysis and reporting overhead to the test process).
• No bugs block the execution of tests.
• The product evolves in functional stages (allows simultaneous development and testing).
ii. Observability. "What you see is what you test."
• Distinct output is generated for each input.
• System states and variables are visible or quarriable during execution.
• Past system states and variables are visible or quarriable (e.g., transaction logs).
• All factors affecting the output are visible.
• Incorrect output is easily identified.
• Internal errors are automatically detected through self-testing mechanisms.
• Internal errors are automatically reported.
• Source code is accessible.
iii. Controllability. "The better we can control the software, the more the testing can be automated
and optimized."
• All possible outputs can be generated through some combination of input.
 • All code is executable through some combination of input.
• Software and hardware states and variables can be controlled directly by the test engineer.
• Input and output formats are consistent and structured.
• Tests can be conveniently specified, automated, and reproduced.
iv. Decomposability. "By controlling the scope of testing, we can more quickly isolates problems
and perform smarter retesting."
• The software system is built from independent modules.
• Software modules can be tested independently.
v. Simplicity. "The less there is to test, the more quickly we can test it."
• Functional simplicity (e.g., the feature set is the minimum necessary to meet requirements).
• Structural simplicity (e.g., architecture is modularized to limit the propagation of
faults).
• Code simplicity (e.g., a coding standard is adopted for ease of inspection and maintenance).
vi. Stability. "The fewer the changes, the fewer the disruptions to testing."
• Changes to the software are infrequent.
• Changes to the software are controlled.
• Changes to the software do not invalidate existing tests.
• The software recovers well from failures.
vii. Understandability. "The more information we have, the smarter we will test."
• The design is well understood.
• Dependencies between internal, external, and shared components are well understood.
• Changes to the design are communicated.
• Technical documentation is instantly accessible.
n • Technical documentation is well organized, specific
and detailed.
2. Test case design
- Any engineered product (and most other things) can be tested in one of two ways:
I. Knowing the specified function that a product has been designed to perform, tests can be
conducted that demonstrate each function is fully operational while at the same time searching
for errors in each function;
II. Knowing the internal workings of a product, tests can be conducted to ensure that "all gears
mesh," that is, internal operations are performed according to specifications and all internal
components have been adequately exercised.
a. White-box testing
- Also, glass-box testing is a test case design method that uses the control structure of the
procedural design to derive test cases. Using white-box testing methods, the software engineer
can derive test cases that
I. guarantee that all independent paths within a module have been exercised at least once
II. exercise all logical decisions on their true and false sides
III. execute all loops at their boundaries and within their operational bounds.
IV. exercise internal data structures to ensure their validity.
b. Basis path testing
- Basis path testing is a technique of selecting the paths in the control flow graph, that provide a
basis set of execution paths through the program or module. Since this testing is based on the
 control structure of the program, it requires complete knowledge of the program’s structure. To
design test cases using this technique, four steps are followed :
- Construct the Control Flow Graph
- Compute the Cyclomatic Complexity of the Graph
- Identify the Independent Paths
- Design Test cases from Independent Paths
- . 1. Control Flow Graph – A control flow graph (or simply, flow graph) is a directed graph which
represents the control structure of a program or module. A control flow graph (V, E) has V
number of nodes/vertices and E number of edges in it. A control graph can also have :
- Junction Node – a node with more than one arrow entering it.
- Decision Node – a node with more than one arrow leaving it.
- Region – area bounded by edges and nodes (area outside the graph is also counted as a region.).
- Below are the notations used while constructing a flow graph :
- Sequential Statements –

-
- If – Then – Else -
- Do – While –
- While – Do –

- Switch – Case –
- Cyclomatic Complexity – The cyclomatic complexity V(G) is said to be a measure of the logical
complexity of a program. It can be calculated using three different formulae:
- Formula based on edges and nodes :
- V(G) = e - n + 2*P
- Where, e is number of edges, n is number of vertices, P is number of connected components.
For example, consider first graph given above,
- where, e = 4, n = 4 and p = 1

So,
Cyclomatic complexity V(G)
=4-4+2*1
=2
- Formula based on Decision Nodes :
- V(G) = d + P
- where, d is number of decision nodes, P is number of connected nodes. For example, consider
first graph given above,
- where, d = 1 and p = 1

So,
Cyclomatic Complexity V(G)
=1+1
=2
- Formula based on Regions :
- V(G) = number of regions in the graph
- For example, consider first graph given above,
- Cyclomatic complexity V(G)
= 1 (for Region 1) + 1 (for Region 2)
=2
- Hence, using all the three above formulae, the cyclomatic complexity obtained remains same.
All these three formulae can be used to compute and verify the cyclomatic complexity of the
flow graph. Note –
- For one function [e.g. Main( ) or Factorial( ) ], only one flow graph is constructed. If in a
program, there are multiple functions, then a separate flow graph is constructed for each one of
them. Also, in the cyclomatic complexity formula, the value of ‘p’ is set depending of the
number of graphs present in total.
- If a decision node has exactly two arrows leaving it, then it is counted as one decision node.
However, if there are more than 2 arrows leaving a decision node, it is computed using this
formula :
- d=k-1
- Here, k is number of arrows leaving the decision node.
- Independent Paths : An independent path in the control flow graph is the one which introduces
at least one new edge that has not been traversed before the path is defined. The cyclomatic
complexity gives the number of independent paths present in a flow graph. This is because the
cyclomatic complexity is used as an upper-bound for the number of tests that should be
 executed in order to make sure that all the statements in the program have been executed at
least once. Consider first graph given above here the independent paths would be 2 because
number of independent paths is equal to the cyclomatic complexity. So, the independent paths
in above first given graph :
- Path 1:
- A -> B
- Path 2:
- C -> D
- Note – Independent paths are not unique. In other words, if for a graph the cyclomatic
complexity comes out be N, then there is a possibility of obtaining two different sets of paths
which are independent in nature. Design Test Cases : Finally, after obtaining the independent
paths, test cases can be designed where each test case represents one or more independent
paths.
-
c. Control structure testing
- Control structure testing is used to increase the coverage area by testing various control
structures present in the program. The different types of testing performed under control
structure testing are as follows-
- 1. Condition Testing
2. Data Flow Testing
3. Loop Testing
- 1. Condition Testing: Condition testing is a test cased design method, which ensures that the
logical condition and decision statements are free from errors. The errors present in logical
conditions can be incorrect boolean operators, missing parenthesis in a booleans expression,
error in relational operators, arithmetic expressions, and so on. The common types of logical
conditions that are tested using condition testing are-
- A relation expression, like E1 op E2 where ‘E1’ and ‘E2’ are arithmetic expressions and ‘OP’ is an
operator.
- A simple condition like any relational expression preceded by a NOT (~) operator. For example,
(~E1) where ‘E1’ is an arithmetic expression and ‘a’ denotes NOT operator.
- A compound condition consists of two or more simple conditions, Boolean operator, and
parenthesis. For example, (E1 & E2)|(E2 & E3) where E1, E2, E3 denote arithmetic expression
and ‘&’ and ‘|’ denote AND or OR operators.
- A Boolean expression consists of operands and a Boolean operator like ‘AND’, OR, NOT. For
example, ‘A|B’ is a Boolean expression where ‘A’ and ‘B’ denote operands and | denotes OR
operator.
- 2. Data Flow Testing : The data flow test method chooses the test path of a program based on
the locations of the definitions and uses all the variables in the program. The data flow test
approach is depicted as follows suppose each statement in a program is assigned a unique
statement number and that theme function cannot modify its parameters or global variables.
For example, with S as its statement number.
- DEF (S) = {X | Statement S has a definition of X}
USE (S) = {X | Statement S has a use of X}
- If statement S is an if loop statement, them its DEF set is empty and its USE set depends on the
state of statement S. The definition of the variable X at statement S is called the line of
statement S’ if the statement is any way from S to statement S’ then there is no other definition
of X. A definition use (DU) chain of variable X has the form [X, S, S’], where S and S’ denote
statement numbers, X is in DEF(S) and USE(S’), and the definition of X in statement S is line at
statement S’. A simple data flow test approach requires that each DU chain be covered at least
once. This approach is known as the DU test approach. The DU testing does not ensure coverage
of all branches of a program. However, a branch is not guaranteed to be covered by DU testing
only in rare cases such as then in which the other construct does not have any certainty of any
variable in its later part and the other part is not present. Data flow testing strategies are
appropriate for choosing test paths of a program containing nested if and loop statements. 3.
Loop Testing: Loop testing is actually a white box testing technique. It specifically focuses on the
validity of loop construction. The following are the types of loops.
- Simple Loop – The following set of test can be applied to simple loops, where the maximum
allowable number through the loop is n.
- Skip the entire loop.
- Traverse the loop only once.
- Traverse the loop two times.
- Make p passes through the loop where p<n.
- Traverse the loop n-1, n, n+1 times.
- Concatenated Loops – If loops are not dependent on each other, contact loops can be tested
using the approach used in simple loops. If the loops are interdependent, the steps are followed
in nested loops.
- Nested Loops – Loops within loops are called as nested loops. when testing nested loops, the
number of tested increases as level nesting increases. The following steps for testing nested
loops are as follows-
- Start with inner loop. set all other loops to minimum values.
- Conduct simple loop testing on inner loop.
- Work outwards.
- Continue until all loops tested.
- Unstructured loops – This type of loops should be redesigned, whenever possible, to reflect the
use of unstructured the structured programming constructs.
-
d. Black box testing
- Black-box testing is a type of software testing in which the tester is not concerned with the
internal knowledge or implementation details of the software but rather focuses on validating
the functionality based on the provided specifications or requirements.
- Black box testing can be done in the following ways:
- 1. Syntax-Driven Testing – This type of testing is applied to systems that can be syntactically
represented by some language. For example, language can be represented by context-free
grammar. In this, the test cases are generated so that each grammar rule is used at least once.
- 2. Equivalence partitioning – It is often seen that many types of inputs work similarly so instead
of giving all of them separately we can group them and test only one input of each group. The
idea is to partition the input domain of the system into several equivalence classes such that
 each member of the class works similarly, i.e., if a test case in one class results in some error,
other members of the class would also result in the same error.
- The technique involves two steps:
- Identification of equivalence class – Partition any input domain into a minimum of two sets:
valid values and invalid values. For example, if the valid range is 0 to 100 then select one valid
input like 49 and one invalid like 104.
- Generating test cases – (i) To each valid and invalid class of input assign a unique identification
number. (ii) Write a test case covering all valid and invalid test cases considering that no two
invalid inputs mask each other. To calculate the square root of a number, the equivalence
classes will be (a) Valid inputs:
- The whole number which is a perfect square-output will be an integer.
- The entire number which is not a perfect square-output will be a decimal number.
- Positive decimals
- Negative numbers (integer or decimal).
- Characters other than numbers like “a”,”!”,”;”, etc.
- 3. Boundary value analysis – Boundaries are very good places for errors to occur. Hence, if test
cases are designed for boundary values of the input domain, then the efficiency of testing
improves and the probability of finding errors also increases. For example – If the valid range is
10 to 100 then test for 10,100 also apart from valid and invalid inputs.
- 4. Cause effect graphing – This technique establishes a relationship between logical input called
causes with corresponding actions called the effect. The causes and effects are represented
using Boolean graphs. The following steps are followed:
- Identify inputs (causes) and outputs (effects).
- Develop a cause-effect graph.
- Transform the graph into a decision table.
- Convert decision table rules to test cases.
- 5. Requirement-based testing – It includes validating the requirements given in the SRS of a
software system.
- 6. Compatibility testing – The test case results not only depends on the product but is also on
the infrastructure for delivering functionality. When the infrastructure parameters are changed
it is still expected to work properly. Some parameters that generally affect the compatibility of
software are:
- Processor (Pentium 3, Pentium 4) and several processors.
- Architecture and characteristics of machine (32-bit or 64-bit).
- Back-end components such as database servers.
- Operating System (Windows, Linux, etc).
- Black Box Testing Type
The following are the several categories of black box testing:
- Functional Testing
- Regression Testing
- Nonfunctional Testing (NFT)
- Functional Testing: It determines the system’s software functional requirements.
Regression Testing: It ensures that the newly added code is compatible with the existing code. In
other words, a new software update has no impact on the functionality of the software. This is
 carried out after a system maintenance operation and upgrades.
Nonfunctional Testing: Nonfunctional testing is also known as NFT. This testing is not functional
testing of software. It focuses on the software’s performance, usability, and scalability.
- What can be identified by Black Box Testing
- Discovers missing functions, incorrect function & interface errors
- Discover the errors faced in accessing the database
- Discovers the errors that occur while initiating & terminating any functions.
- Discovers the errors in performance or behaviour of software.
- Features of black box testing:
- Independent testing: Black box testing is performed by testers who are not involved in the
development of the application, which helps to ensure that testing is unbiased and impartial.
- Testing from a user’s perspective: Black box testing is conducted from the perspective of an end
user, which helps to ensure that the application meets user requirements and is easy to use.
- No knowledge of internal code: Testers performing black box testing do not have access to the
application’s internal code, which allows them to focus on testing the application’s external
behaviour and functionality.
- Requirements-based testing: Black box testing is typically based on the application’s
requirements, which helps to ensure that the application meets the required specifications.
- Different testing techniques: Black box testing can be performed using various testing
techniques, such as functional testing, usability testing, acceptance testing, and regression
testing.
- Easy to automate: Black box testing is easy to automate using various automation tools, which
helps to reduce the overall testing time and effort.
- Scalability: Black box testing can be scaled up or down depending on the size and complexity of
the application being tested.
- Limited knowledge of application: Testers performing black box testing have limited knowledge
of the application being tested, which helps to ensure that testing is more representative of how
the end users will interact with the application.
3. Software Testing Strategies
- Verification refers to the set of activities that ensure that software correctly implements a
specific function. Validation refers to a different set of activities that ensure that the software
that has been built is traceable to customer requirements.
- Verification and validation encompass a wide array of SQA activities that include formal
technical reviews, quality and configuration audits, performance monitoring, simulation,
feasibility study, documentation review, database review, algorithm analysis, development
testing, qualification testing, and installation testing.
- Unit testing focuses verification effort on the smallest unit of software design—the software
component or module. Using the component-level design description as a guide, important
control paths are tested to uncover errors within the boundary of the module. The relative
complexity of tests and uncovered errors is limited by the constrained scope established for unit
testing. The unit test is white-box oriented, and the step can be conducted in parallel for
multiple components.
4. System testing
- System testing is actually a series of different tests whose primary purpose is to fully exercise
the computer-based system. Although each test has a different purpose, all work to verify that
system elements have been properly integrated and perform allocated functions.
- Recovery testing is a system test that forces the software to fail in a variety of ways and verifies
that recovery is properly performed. If recovery is automatic (performed by the system itself),
reinitialization, checkpointing mechanisms, data recovery, and restart are evaluated for
correctness. If recovery requires human intervention, the mean-time-to-repair (MTTR) is
evaluated to determine whether it is within acceptable limits.
- Security testing attempts to verify that protection mechanisms built into a system will, in fact,
protect it from improper penetration. To quote Beizer [BEI84]: "The system's security must, of
course, be tested for invulnerability from frontal attack—but must also be tested for
invulnerability from flank or rear attack."
- Stress testing executes a system in a manner that demands resources in abnormal quantity,
frequency, or volume. For example, (1) special tests may be designed that generate ten
interrupts per second, when one or two is the average rate, (2) input data rates may be
increased by an order of magnitude to determine how input functions will respond, (3) test
cases that require maximum memory or other resources are executed, (4) test cases that may
cause thrashing in a virtual operating system are designed, (5) test cases that may cause
excessive hunting for disk-resident data are created. Essentially, the tester attempts to break
the program. A variation of stress testing is a technique called sensitivity testing.
- Performance testing is designed to test the run-time performance of software within the
context of an integrated system. Performance testing occurs throughout all steps in the testing
process. Even at the unit level, the performance of an individual module may be assessed as
white-box tests are conducted.
5. The art of debugging
- Debugging occurs as a consequence of successful testing. That is, when a test case uncovers an
error, debugging is the process that results in the removal of the error.
- Debugging Process: The steps involved in debugging are:
- Problem identification and report preparation.
- Assigning the report to the software engineer defect to verify that it is genuine.
- Defect Analysis using modeling, documentation, finding and testing candidate flaws, etc.
- Defect Resolution by making required changes to the system.
- Validation of corrections.
- The debugging process will always have one of two outcomes:
- The cause will be found and corrected.
- The cause will not be found.
- Later, the person performing debugging may suspect a cause, design a test case to help validate
that suspicion, and work toward error correction in an iterative fashion.
- During debugging, we encounter errors that range from mildly annoying to catastrophic. As the
consequences of an error increase, the amount of pressure to find the cause also increases.
Often, pressure sometimes forces a software developer to fix one error and at the same time
introduce two more.
- Debugging Approaches/Strategies:
- Brute Force: Study the system for a longer duration to understand the system. It helps the
debugger to construct different representations of systems to be debugged depending on the
need. A study of the system is also done actively to find recent changes made to the software.
- Backtracking: Backward analysis of the problem which involves tracing the program backward
from the location of the failure message to identify the region of faulty code. A detailed study of
the region is conducted to find the cause of defects.
- Forward analysis of the program involves tracing the program forwards using breakpoints or
print statements at different points in the program and studying the results. The region where
the wrong outputs are obtained is the region that needs to be focused on to find the defect.
- Using A debugging experience with the software debug the software with similar problems in
nature. The success of this approach depends on the expertise of the debugger.
- Cause elimination: it introduces the concept of binary partitioning. Data related to the error
occurrence are organized to isolate potential causes.
- Static analysis: Analyzing the code without executing it to identify potential bugs or errors. This
approach involves analyzing code syntax, data flow, and control flow.
- Dynamic analysis: Executing the code and analyzing its behavior at runtime to identify errors or
bugs. This approach involves techniques like runtime debugging and profiling.
- Collaborative debugging: Involves multiple developers working together to debug a system. This
approach is helpful in situations where multiple modules or components are involved, and the
root cause of the error is not clear.
- Logging and Tracing: Using logging and tracing tools to identify the sequence of events leading
up to the error. This approach involves collecting and analyzing logs and traces generated by the
system during its execution.
- Automated Debugging: The use of automated tools and techniques to assist in the debugging
process. These tools can include static and dynamic analysis tools, as well as tools that use
machine learning and artificial intelligence to identify errors and suggest fixes.
6. Software Reengineering
- Software Re-Engineering is the examination and alteration of a system to reconstitute it in a
new form. The principle of Re-Engineering when applied to the software development process is
called software re-engineering. It positively affects software cost, quality, customer service, and
delivery speed. In Software Re-engineering, we are improving the software to make it more
efficient and effective.
- It is a process where the software’s design is changed, and the source code is created from
scratch. Sometimes software engineers notice that certain software product components need
more upkeep than other components, necessitating their re-engineering.
- A Software Reengineering Process Model.

- Software Reverse Engineering is a process of recovering the design, requirement specifications,

and functions of a product from an analysis of its code. It builds a program database and
generates information from this.
- The purpose of reverse engineering is to facilitate the maintenance work by improving the
understandability of a system and producing the necessary documents for a legacy system.
- Reverse engineering can extract design information from source code, but the abstraction level,
the completeness of the documentation, the degree to which tools and a human analyst work
together, and the directionality of the process are highly variable.
- Reverse Engineering Goals:
- Cope with Complexity.
- Recover lost information.
- Detect side effects.
- Synthesis higher abstraction.
- Facilitate Reuse.
- Reverse Engineering to Understand Data
- Reverse engineering of data occurs at different levels of abstraction. It is often the first
reengineering task.
- 1. At the program level, internal program data structures must often be reverse engineered as
part of an overall reengineering effort.
- 2. At the system level, global data structures (e.g., files, databases) are often reengineered to
accommodate new database management paradigms (e.g., the move from flat file to relational
or object-oriented database systems).
- Internal data structures: Reverse engineering techniques for internal program data focus on the
definition of classes of objects. This is accomplished by examining the program code with the
intent of grouping related program variables. In many cases, the data organization within the
code identifies abstract data types.
- For example, record structures, files, lists, and other data structures often provide an initial
indicator of classes.
- Database structures: A database allows the definition of data objects and supports some
method for establishing relationships among the objects. Therefore, reengineering one
database schema into another requires an understanding of existing objects and their
relationships.
The following steps define the existing data model as a precursor to reengineering a new
database model:
- (1) build an initial object model.
- (2) determine candidate keys (the attributes are examined to determine whether they are used
to point to another record or table; those that serve as pointers become candidate keys).
- (3) refine the tentative classes.
- (4) define generalizations,
- Reverse Engineering to Understand Processing: To understand processing begins with an
attempt to understand and then extract procedural abstractions represented by the source
code.
- To understand procedural abstractions, the code is analyzed at varying levels of abstraction:
system, program, component, pattern, and statement.
- Each of the programs that make up the application system represents a functional abstraction at
a high level of detail. A block diagram, representing the interaction between these functional
abstractions, is created.
- Each component performs some subfunction and represents a defined procedural abstraction. A
processing narrative for each component is developed.
- For large systems, reverse engineering is generally accomplished using a semiautomated (partial
automation) approach. Automated tools can be used to help you understand the semantics of
existing code.
- The output of this process is then passed to restructuring and forward engineering tools to
complete the reengineering process.
- Steps of Software Reverse Engineering:
-
- Collection Information:
This step focuses on collecting all possible information (i.e., source design documents, etc.)
about the software.
-
- Examining the information:
The information collected in step-1 is studied so as to get familiar with the system.
-
- Extracting the structure:
This step concerns identifying program structure in the form of a structure chart where each
node corresponds to some routine.
-
- Recording the functionality:
During this step processing details of each module of the structure, charts are recorded using
structured language like decision table, etc.
-
- Recording data flow:
From the information extracted in step-3 and step-4, a set of data flow diagrams is derived to
show the flow of data among the processes.
-
- Recording control flow:
The high-level control structure of the software is recorded.
-
- Review extracted design:
The design document extracted is reviewed several times to ensure consistency and
correctness. It also ensures that the design represents the program.
-
- Generate documentation:
Finally, in this step, the complete documentation including SRS, design document, history,
overview, etc. is recorded for future use.
- Software restructuring modifies source code and/or data in an effort to make it amenable to
future changes.
- Data reconstruction; Code restructuring. The most common type of reengineering (actually, the
use of the term reengineering is questionable in this case) is code restructuring. Some legacy
systems have a relatively solid program architecture, but individual modules were coded in a
way that makes them difficult to understand, test, and maintain. In such cases, the code within
the suspect modules can be restructured. To accomplish this activity, the source code is
analyzed using a restructuring tool. Violations of structured programming constructs are noted,
and code is then restructured (this can be done automatically). The resultant restructured code
is reviewed and tested to ensure that no anomalies have been introduced. Internal code
documentation is updated.
- Data restructuring. A program with weak data architecture will be difficult to adapt and
enhance. In fact, for many applications, data architecture has more to do with the long-term
viability of a program than the source code itself. Unlike code restructuring, which occurs at a
relatively low level of abstraction, data structuring is a full-scale reengineering activity. In most
cases, data restructuring begins with a reverse engineering activity. The current data
architecture is dissected, and necessary data models are defined (Chapter 12). Data objects and
attributes are identified, and existing data structures are reviewed for quality. When data
structure is weak (e.g., flat files are currently implemented, when a relational approach would
greatly simplify processing), the data is reengineered. Because data architecture has a strong
influence on program architecture and the algorithms that populate it, changes to the data will
invariably result in either architectural or code-level changes.
- Forward Engineering is a method of creating or making an application with the help of the given
requirements. Forward engineering is also known as Renovation and Reclamation. Forward
engineering requires high proficiency skills. It takes more time to construct or develop an
 application. Forward engineering is a technique of creating high-level models or designs to make
in complexities and low-level information. Therefore this kind of engineering has completely
different principles in numerous package and information processes. Forward Engineering
applies of all the software engineering process which contains SDLC to recreate associate
existing application. It is near to full fill new needs of the users into re-engineering.
- Forward engineering and reverse engineering are two approaches to software development,
with different goals and processes. Here are some key differences between the two:
- Goal: The goal of forward engineering is to develop new software from scratch, while the goal of
reverse engineering is to analyze and understand an existing software system.
- Process: Forward engineering involves designing and implementing a new software system
based on requirements and specifications. Reverse engineering involves analyzing an existing
software system to understand its design, structure, and behavior.
- Tools and Techniques: Forward engineering often involves the use of software development
tools, such as IDEs, code generators, and testing frameworks. Reverse engineering often
involves the use of reverse engineering tools, such as decompilers, disassemblers, and code
analyzers.
- Focus: Forward engineering focuses on the creation of new code and functionality, while reverse
engineering focuses on understanding and documenting existing code and functionality.
- Output: The output of forward engineering is a new software system, while the output of
reverse engineering is documentation of an existing software system, such as a UML diagram,
flowchart, or software specification.
- In summary, forward engineering is focused on the creation of new software systems, while
reverse engineering is focused on understanding and documenting existing software systems.
Both approaches use different tools and techniques to achieve their goals and produce different
outputs.
- Characteristics of forward engineering:
- Forward engineering is a variety of engineering that has different principles in numerous
packaging and information processes.
- Forward engineering is vital in IT as a result of it represents the ‘normal’ development process.
- Forward engineering deals with the conversion of business processes, services, and functions
into applications.
- In this method a business model is developed first. Then, a top-to-down approach is followed to
urge the package from the model developed.
- Forward engineering tools are accustomed to moving from implementation styles and logic to
the event of supply code.
- It essentially permits the user to develop a business model which may then be translated into
data system components.
- These tools basically follow the top-to-down approach. System creator and visual Analyst is a
forward engineering CASE tool.