RAO’S DEGREE COLLEGE

BCA-DS III YEAR – V SEMESTER

SOFTWARE ENGINEERING
SYLLABUS

UNIT – I
Introduction to Software Engineering: Definitions Size Factors Quality and Productivity
Factors - Managerial Issues.
Planning a software project: Defining the problem - Developing a Solution Strategy -
Planning the Development Process - Planning an Organization structure - Other Planning
Activities.

UNIT – II
Software Cost Estimation: Software cost factors- Software Cost. Estimation Techniques -
Staffing level Estimation-Estimating Software Maintenance Costs - The Software
Requirements, Specification - Formal Specification Techniques - Languages andProcessors
for Requirements Specification.

UNIT – III
Software design: Fundamental Design Concepts - Modules and Modularization Criteria -
Design Notations -Design Techniques - Detailed Design Considerations. Real-Time and
Distributed System Design – Test Plans - Milestones, walk throughs, and inspections.

UNIT – IV
User interface design and real time systems: User interface design - Human factors -
Human computer interaction - Human - Computer Interface design - Interface design -
Interface standards.

UNIT – V
Software quality and testing: Software Quality Assurance - Quality metrics – Software
Reliability - Software testing - Path testing - Control Structures testing - Black Box testing -
Integration, Validation and system testing - Reverse Engineering and Reengineering.
CASE Tools: Projects management, tools - analysis and design tools - programming tools -
integration and testing tool - Case studies.

1 | SOFTWARE ENGINEERING BCA-DS III YEAR – V SEMESTER

 RAO’S DEGREE COLLEGE

UNIT – 1

1. Software:

1. Software can be defined as collection of programs that are used to perform a specific
task.
2. Software takes on a dual role. It is a product, and at the same time, the vehicle for
delivering a product. As a product, it delivers the computing potential from a
computer or by a network of computers
3. As the vehicle used to deliver the product, software acts as the basis for the control
of the computer (operating systems), the communication of information (networks),
and the creation and control of other programs (software tools and environments)
4. Software is information transformer. That is, producing, managing, acquiring,
modifying, displaying, or transmitting information.
5. Software contains -
 instructions (computer programs) - that when executed provide desired
features, function, and performance
 data structures - that enable the programs to adequately manipulate
information, and
 Descriptive information - in both hard copy and virtual forms that describes
the operation and use of the programs.
6. Software can be classified into two types –
 System software – operating system, Language processor, Device driver
 Application software – General purpose software, customized software,
utility software.

2. Software Engineering:

Software engineering is an engineering-based approach to software development.

A software engineer is a person who applies the engineering design process to design,
develop, maintain, test, and evaluate computer software.

Software Engineering (definition) :

1. Software Engineering is the application of systematic, Disciplined, Quantifiable
approach for the development, operation and maintenance of software.
2. Software engineering contains Methods, Tools and Procedures for the
development of computer software.
3. The main goal of Software Engineering is to develop High quality computer software.
4. Software engineering is a layered technology.

2 | SOFTWARE ENGINEERING BCA-DS III YEAR – V SEMESTER

 RAO’S DEGREE COLLEGE

The foundation for software engineering is the process layer. Process defines a framework
that must be established for effective delivery of software engineering technology. The
software process forms the basis for the management control of software projects
and establishes the context in which technical methods are applied.
Software engineering methods provide the technical how-to’s for building software.
Methods contain a broad array of tasks that include communication, requirements
analysis, design modeling,program construction, testing, and support.
Software engineering tools provide automated or semi-automated support for the process
and the methods. The computer-aided software engineering (CASE ) tools are used
in software development.

3,SIZE FACTORS :( Project Size Estimation)

 Project size estimation is used to find the scope and resources required for the
project.
 Project size estimation involves assessing the various aspects of the project to
estimate the effort, time, cost, and resources needed to complete the project.
 Accurate project size estimation is important for effective and efficient project
planning, management, and execution.

Project size estimation is necessary for project management. The following are
the size factors in software development -

1. Financial planning

2. Resource planning

3. Time line creation

4. Identifying risk

5.Detailed planning

6.Planning quality assurance

3 | SOFTWARE ENGINEERING BCA-DS III YEAR – V SEMESTER

 RAO’S DEGREE COLLEGE

1. Financial Planning: Project size estimation helps in planning the financial aspects of the
project, thus helping to avoid financial deficits.
2. Resource Planning: It ensures the necessary resources are identified and allocated
accordingly.
3. Timeline Creation: It allows the development of realistic timelines and milestones for
the project.
4. Identifying Risks: It helps to identify potential risks associated with overall project
execution.
5. Detailed Planning: It helps to create a detailed plan for the project execution, ensuring
all the aspects of the project are considered.
6. Planning Quality Assurance: It helps in planning quality assurance activities and
ensuring that the project outcomes meet the required standards.

Estimating the Size of the Software:

Estimation of the size of the software is an essential part of Software Project Management.
Some of the measures that are used in project size estimation are -
Lines of Code (LOC):
Lines of Code (LOC)-LOC counts the total number of lines of source code
in a project.
The units of LOC are:
1. KLOC: Thousand lines of code
2. NLOC: Non-comment lines of code
3. KDSI: Thousands of delivered source instruction
An estimation of lines of code can be done by analysing the problem definition.

Counting the number of functions (modules) in the software:

Measuring the size of the software also involves counting the number of functions and files.
 External Inputs: Functions related to data entering the system.
 External outputs: Functions related to data exiting the system.
 Internal Files: Logical files maintained within the system. Log files are not included here.
 External interface Files: These are logical files for other applications which are used by
our system.

Key roles in project size estimation:

Key roles involved in project size estimation are – Project Manager, Business Analyst,
Designer, etc.,
Project Manager: Project manager is responsible for the complete work associated with
estimation process.
Business Analyst: Business Analyst helps in understanding and documenting the project
requirements
Methods of project estimation:
The following methods are popularly used in Project size estimation –
1. COCOMO (Constructive Cost Model): It is an algorithmic model that estimates effort,
time, and cost in software development projects.
2. Analogous Estimation: This technique involves estimating the project size based on the
similarities between the current project and previously completed projects.

4 | SOFTWARE ENGINEERING BCA-DS III YEAR – V SEMESTER

 RAO’S DEGREE COLLEGE

4. SOFTWARE QUALITY AND PRODUCTIVITY:

Software quality:
Software quality ensures that a product that is developed must have high standards beyond the
requirements.
The key factors in software quality are –
1. Reliability
2. Portability
3. correctness
4. Usability
5. Efficiency
6. Maintainability

1.Reliability:
The software performs consistently and without failures. If failure occurs, the system can
handle them or can recover easily.
2,Portability:
Software must be transportable that is the software works across different platforms.
3.correctness:
The software produces accurate results and developed according to Software requirements
specification(SRS) document.
4. usability:
A software has smart usability. If all the users can easily work with it the users must find it
native and efficient.
5. efficiency:
It optimizes resource usage. The more efficient software is the less it uses CPU time,
memory and other resources.
Maintainability:
It is easy to maintain and enhance. Errors must be corrected and new features are added
when required.
Software engineering productivity:
1. Software engineering productivity refers to the efficiency and effectiveness of software
development processes.

5 | SOFTWARE ENGINEERING BCA-DS III YEAR – V SEMESTER

 RAO’S DEGREE COLLEGE

2. Programming productivity (also called software productivity or development

productivity) describes the degree of the ability of individual programmers or
development teams to build and evolve software systems.
3. Productivity traditionally refers to the ratio between the quantity of software produced
and the cost spent for it.
4. Software productivity in programming sense , describes the ratio between output and
input.
5. Software productivity is a balance between speed and quality.
Defect Removal Efficiency (DRE):

A quality metric that provides benefit at both the project and process level is Defect
Removal Efficiency (DRE). DRE is a measure of the filtering ability of quality assurance and
control activities as they are applied throughout all process framework activities.

DRE = E / (E + D) Where E = number of errors found before delivery of the software to the
end user,

D = number of defects found after delivery

Strategies used to enhance productivity:

The following strategies are used to enhance productivity –

modular
design
automated
testing
version
software control
productivity code reviews
factors agile
practices
tooling
documentation
1. Modular Design: Break down complex systems into smaller, manageable modules. This
promotes reusability and easier maintenance.
2. Automated Testing: Implementing automated testing ensures code quality and reduces
manual testing efforts. Automated testing generates error free code and there by helps in
quick deployment of software.
3. Version Control: Use version control systems to track changes, collaborate, and manage
codebase versions effectively.
4. Code Reviews: Regular code reviews help catch errors, improve code quality, and share
knowledge among team members.
5. Agile Practices: Adopt agile methodologies (e.g., Scrum, Kanban) to streamline
development, prioritize tasks, and maintain a steady pace. Agile team is a lively team

6 | SOFTWARE ENGINEERING BCA-DS III YEAR – V SEMESTER

 RAO’S DEGREE COLLEGE

able to appropriately respond to changes. Change is what software development

is very much about.
6. Tooling: IDEs, linters, and other development tools to automate repetitive tasks and
improve coding standards. A Linter is a developer tool that analyses source code for errors,
vulnerabilities and to improve code quality.
7. Documentation: Maintain clear and concise documentation for code, APIs, and architectural
decisions.
5. MANAGERIAL ISSUES: (challenges or complexity in software development)

 Software engineering is an application of management activities such as – planning,

coordinating, monitoring, controlling and reporting.
 The primary goal of software project management is to guide a team of developers
to complete a project successfully within a given timeframe.
 Software project management issues refer to various challenges and difficulties
involved in managing software development projects.
The following are the various types of managerial issues in software project management –
1. Time management complexity
2. Cost management complexity
3. Quality management complexity
4. Risk management complexity
5. HR management complexity
6. Communication management complexity
7. Deployment complexity
8. Procurement complexity
1. Time Management Complexity: Complexities to estimate the duration of the project.
It also includes the complexities to make the schedule for different activities and
timely completion of the project.
2. Cost Management Complexity: Estimating the total cost of the project is a very
difficult task. Another thing is to see that the project does not cost over the budget
estimation.
3. Quality Management Complexity: The quality of the project must satisfy the
customer’s requirements. It must assure that the requirements of the customer are
fulfilled.
4. Risk Management Complexity: Risks are the unexpected things that may occur during
any phase of the project. Various difficulties may occur to identify these risks and
make plans to reduce the effects of these risks.
5. Human Resources Management Complexity: It includes all the difficulties related to
employees recruitment, managing, and leading the project team.
6. Communication Management Complexity: All the members must interact with all the
other members and there must be good communication with the customer.
7. Deployment complexity: A Project release or finalized code, has to be installed from
one system to another. Conceptually, such an operation must to be simple. To perform
this installation quickly and securely is difficult.

7 | SOFTWARE ENGINEERING BCA-DS III YEAR – V SEMESTER

 RAO’S DEGREE COLLEGE

8. Procurement Management Complexity: Projects need many infrastructure facilities

and services from third parties to complete the task. These may increase the
complexity of the project to acquire the services.
Software project management is a complex and challenging process that requires a
skilled and experienced project manager to manage effectively. It involves balancing the
conflicting demands of schedule, budget, quality, and stakeholder expectations while
ensuring that the project remains on track and delivers the required results.
Example:

Some common managerial issues with examples -

1. Requirement changes: A project starts with a set of requirements, but as

development progresses, stakeholders frequently change their minds about features
and functionalities.
2. Limited Budget and Resources: A project is allocated a fixed budget, but unexpected
complexities arise, requiring additional resources and funds.

6. PLANNING A SOFTWARE PROJECT:

The software project management process begins with a set of

activities that are collectively called project planning.
The objective of software project planning is to provide a framework
that enables the manager to make reasonable estimates of resources,
cost, and schedule.

steps in Software Project Plan

8 | SOFTWARE ENGINEERING BCA-DS III YEAR – V SEMESTER

 RAO’S DEGREE COLLEGE

The software project planning involves –

 Estimation

 Software scope
Estimation:
The first of these activities is estimation. Estimation of resources, cost,
and schedule for a software development effort requires experience, access
to good historical information. Estimation carries inherent risk and risk leads
to uncertainty. Hence software project estimation must be viewed as an art
and science and must be done as accurately as possible.
These estimates are made within a limited time frame at the
beginning of a software project. Also they should be updated regularly as
the project progresses.

9 | SOFTWARE ENGINEERING BCA-DS III YEAR – V SEMESTER

 RAO’S DEGREE COLLEGE

Software Scope
The Scope is the part of the Project Management that is responsible for the
boundaries, objectives, and deliverables of the Project. In other words, it is the total
amount of activities or tasks that need to be done under the Project Execution.
Software scope describes function, performance, constraints, interfaces,
and reliability. Functions are evaluated and in some cases refined to provide
more details before the beginning of estimation.
Performance considerations include processing and response time
requirements. Constraints identify limits placed on the software by external
hardware, available memory, or other existing systems.
To define scope, it is necessary to obtain the relevant information and
hence get the communication process started between the customer and
the developer.
To accomplish this, a preliminary meeting or interview is to be
conducted. The analyst may start by asking context free questions. That
is, a set of questions that will lead to a basic understanding of the problem
and the nature of the solution that is desired.
The next set of questions enable the analyst to gain a better
understanding of the problem and the customers to give their ideas about a
solution. The final set of questions, known as Meta questions, focus on the
effectiveness of the meeting.
A team-oriented approach, such as the Facilitated Application Specification
Techniques (FAST), helps to establish the scope of a project.
The Resource allocation is very important in software project
development. The development resources needed are:
1. Development Environment (Hardware/Software Tools)

2. Reusable Software Components

3. Human Resources (People)

Each resource is specified with four characteristics –

description of the resource, a statement of availability, chronological
time that the resource will be required, and duration of time that the
resource will be applied.
Human Resources: Both organizational positions s u c h a s -
P r o j e c t Manager, senior software engineer, Programmer etc. are
specified. The number of people required varies for every software
project and it can be determined only after an estimate is made.

7. DEFINING THE PROBLEM:

10 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Most software projects are undertaken to provide solution to

business needs. In the beginning of a software project the business
needs are often expressed informally as part of a meeting or a casual
conversation.

In software engineering, defining the problem often involves creating and

responding to documents like RFPs (Request for Proposals) and RFIs (Request for
Information).

In a more formal approach, a customer could send Request For

Information (RFI) to Software development company(vendor) to know
their area of expertise and domain specifications. The customer puts up
a Request For Proposal (RFP) stating the business needs. The Software
development company(vendor) willing to provide their services will send
proposals and one of the proposals is accepted by the customer.

Request for Information (RFI)

An RFI is used to gather general information about potential solutions and vendors. It
includes questions about the vendor’s capabilities, experience, and potential solutions to
the problem.

Request for Proposal (RFP)

An RFP is a formal document that asks detailed proposals from vendors. It is used when the
problem is well-defined, and specific solutions are needed. It includes detailed
requirements, project scope, evaluation criteria, and submission guidelines.

Defining the problem is first step in software engineering. Some key aspects to consider are
given below –

1. Understanding the Problem Domain

 Problem Domain: This represents the specific area or subject matter the software
intends to address. It includes the scope and context within which the software will
operate.

2. Creating a Problem Statement

 Problem Statement: A concise but complete description of the key business problem
that needs to be solved. It outlines “what has to be done” for a project to succeed
and meet the needs of its stakeholders.

3. Analyzing the Problem

 Identify the Core Issue: Break down the problem into smaller, manageable parts.
Understand the root cause rather than just the symptoms.

11 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

 Gather Information: Collect relevant data and insights that can help in
understanding the problem better.

4. Exploring the Solution Space

 Innovative Solutions: Consider various approaches to solve the problem. Evaluate

the feasibility, risks, and benefits of each solution.
 Decision-Making: Choose the most effective solution based on the analysis and
available resources.

5. Reflecting on the Process

 Review and Learn: After implementing the solution, review the process and
outcomes. Reflect on what worked well and what could be improved for future
projects.

8. DEVELOPING A SOLUTION STRATEGY:

The business needs have to be understood and the role of

software in providing the solution has to be identified.

Developing a solution strategy in software engineering involves several key steps to ensure the
project is successful and meets the desired requirements -

1. Define the Problem and Gather Requirements:

o Clearly understand the problem we are trying to solve.
o Gather detailed requirements from stakeholders to ensure all needs are
addressed.
2. Conduct a Feasibility Study:
o Assess the technical, economic, and operational feasibility of the project.
o Identify potential risks and constraints.
3. Plan and Allocate Resources:
o Develop a project plan outlining tasks, timelines, and resource allocation.
o Ensure you have the necessary team members, tools, and technologies.
4. Choose the Right Development Methodology:
o Select a development methodology that suits our project, such as Agile,
Waterfall,etc.
o This will guide our development process and help manage tasks efficiently.
5. Design the System:
o Create a high-level design that outlines the system architecture, components,
and interfaces.
o Use design strategies like top-down, bottom-up, or iterative design based on
our project needs.
6. Implementation:
o Write the code according to the design specifications.

12 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

o Ensure code quality through regular reviews and testing.

7. Testing and Quality Assurance:
o Conduct thorough testing to identify and fix bugs.
o Perform unit, integration, system, and acceptance testing to ensure the
software meets all requirements.
8. Deployment and Maintenance:
o Deploy the software to the production environment.
o Plan for ongoing maintenance and updates to address any issues and
improve functionality.
9. Continuous Improvement:
o Collect feedback from users and stakeholders.
o Use this feedback to make iterative improvements to the software.

Software development requires a model to be used to drive it and track it to

completion. The model will provide an effective roadmap for the software
team.

9. PLANNING THE DEVELOPMENT PROCESS:

The Software Development Life Cycle (SDLC) is a process used by software development
organizations to plan, design, develop, test, deploy, and maintain software applications.
Planning the software development process involves several important
considerations. The first consideration is to define a product life-cycle model.
A software project goes through various phases before it is ready to be used for
practical purposes. For every project, a framework must be used to define the
flow of activities such as define, develop, test, deliver, operate, and maintain a
software product.
There are many well define models that can be used. There could be variations
to these models also, depending on the deliverables and milestones for the
project.
A model has to be selected and finalized to start a project.
The various process models are -
1. Waterfall Model

2. Incremental process model

3. Prototyping model

4. Spiral Model
The Waterfall model:
The Waterfall model is one of the oldest models available for

13 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

software development and also most widely used. It is also called the
Classic Life Cycle Model. It suggests a systematic and sequential
approach to software development.
It begins with customer specification of requirements and progresses through
planning, modeling, construction, and deployment, concluding in ongoing support of
the completed software.

. The sequential move from one phase to the next gave rise to the name
Waterfall model. The model mandates that each phase will be executed
after the completion of the previous phase.
In the figure, the forward arrow describes the flow between the various
phases of software development.
The waterfall model is ideal in situations where the requirements are well
defined from the beginning.
The problems with the waterfall model are:
1. Real projects rarely follow the sequential flow that the model proposes.
Although the linear model can accommodate iteration, it does so indirectly.
As a result, changes can cause confusion as the project team proceeds.
2. It is often difficult for the customer to state all requirements explicitly. The
waterfall model requires this and has difficulty accommodating the natural
uncertainty that exists at the beginning of many projects.
3. The customer must have patience. A working version of the program(s) will
not be available until late in the project time span. A major blunder, if
undetected until the working program is reviewed, can be disastrous.

The waterfall model is often inappropriate for such work. However, it can serve as a
useful process model in situations where requirements are fixed and work is to
proceed to completion in a linear manner.
The Incremental process model:
The incremental model combines elements of linear and
parallel process flows .The incremental model applies linear sequences in a
staggered fashion as calendar time progresses. Each linear sequence produces
deliverable “increments” of the software in a manner that is similar to the

14 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

increments produced by an evolutionary process flow.

For example, word-processing software developed using the
incremental paradigm might deliver basic file management, editing, and
document production functions in the first increment; more sophisticated
editing and document production capabilities in the second increment; spelling
and grammar checking in the third increment; and advanced page layout
capability in the fourth increment. It should be noted that the process flow for
any increment can incorporate the prototyping paradigm.
When an incremental model is used, the first
increment is often a core product.The core product is used by the customer. As
a result of use and/or evaluation, a plan is developed for the next increment. The
plan addresses the modification of the core product to better meet the needs of
the customer and the delivery of additional features and functionality.

This process is repeated following the delivery of each increment, until the complete
product is produced.

Incremental development is particularly useful when staffing is unavailable for a

complete implementation by the business deadline that has been established for
the project. Early increments can be implemented with fewer people. If the core
product is well received, then additional staff (if required) can be added to
implement the next increment. In addition, increments can be planned to manage

15 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

technical risks.
The Evolutionary process models:
Evolutionary models are iterative. They are characterized in a
manner that enables you to develop increasingly more complete versions of the
software. There are two typesof evolutionary process models.
1. Prototyping model.
2. Spiral model.

Prototyping model:
Although prototyping can be used as a stand-alone process
model, it is more commonly used as a technique that can be implemented within
the context of any one of the process models.
The prototyping paradigm begins with communication. You meet
with otherstakeholders to define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is
mandatory. Prototyping iteration is planned quickly, and modeling occurs. A
quick design focuses on a representation of those aspects of the software that
will be visible to end users.

The quick design leads to the construction of a prototype. The

prototype is deployed and evaluated by stakeholders, who provide feedback that
is used to further refine requirements. Ideally, the prototype serves as a
mechanism for identifying software requirements. If a working prototype is to
be built, you can make use of existing program fragments or apply tools (e.g.,
report generators and window managers) that enable working programs to be
generated quickly.
Both stakeholders and software engineers like the prototyping
paradigm. Users get a feel for the actual system, and developers get to build
something immediately. Yet, prototyping can be problematic for the following
reasons:
1. Stakeholders see what appears to be a working version of the software,

16 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

unaware that the prototype is held together haphazardly, unaware that in the rush to
get it working you haven’t considered overall software quality or long- term
maintainability.
2. As a software engineer, we often make implementation compromises in
order to get a prototype working quickly. An inappropriate operating system or
programming language may beused simply because it is available and known. An
inefficient algorithm may be implemented simply to demonstrate capability.
After a time, you may become comfortable with these choices and forget all the
reasons why they were inappropriate. The less-than-ideal choice has now
become an integral part of the system.

Spiral model:
The spiral model is an evolutionary software process
model that couples the iterative nature of prototyping withthe controlled and
systematic aspects of the waterfall model. It provides the potential for rapid
development of increasingly more complete versions of the software.

A spiral model is divided into a set of framework activities

defined by the software engineering team. Each of the framework activities
represent one segment of the spiral path illustrated in above Figure. As this
evolutionary process begins, the software team performs activities that are
implied by a circuit around the spiral in a clockwise direction, beginning at the
center. Risk is considered as each revolution is made.

The spiral model is a realistic approach to the development of

large-scale systems and software. Because software evolves as the process
progresses, the developer and customer better understand and react to risks at
each evolutionary level.

17 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

The spiral model demands a direct consideration of technical

risks at all stages of the project and, if properly applied, should reduce risks
before they become problematic.
The Spiral model contains six task regions -

❖ Customer communication: tasks required to establish effective

communication between developer and customer.
❖ Planning-tasks required defining resources, timelines, and
other project –related information.
❖ Risk analysis – tasks required to assess both technical and
management risks.
❖ Engineering – tasks required to build one or more representations
of the application.
❖ Construction and release – tasks required to construct, test,
install, and provide user support (e.g., documentation and
training).
❖ Customer evaluation – tasks required to obtain customer
feedback based on evolution of the software representations
created during the engineering.

10. PLANNING AN ORGANIZATION STRUCTURE:

Completing a software project is a team effort. The following options

are available for applying human resources to a project that will require
‘n’ people working for ‘K’ years.
1. ‘n’ individuals are assigned to ‘m’ different functional tasks.

2. ‘n’ individuals are assigned to ‘m’ different functional tasks

(m<n) so that informal teams are established and coordinated
by project manager.
3. ‘n’ individuals are organized into ‘t’ teams and each team is
assigned one/more functional tasks.
Even though the above three approaches have their pros and
cons, option 3 is most productive.
There are several roles within each software project team. Some of
the roles in a typical software project are listed below:

Designation Job Profile

Project Manager Initiates, plans, tracks and manages resources of an

entire project

18 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Module Leader A software engineer who manages and leads the team
working
on a particular module of the software project. The
module leader will conduct reviews and has to ensure the
proper
functionality of the module

Analyst A software engineer who analyzes the requirements

gathered. Analysis of the requirements is done to get a clear
understanding of the requirements.

Domain An expert who knows the system of which the software is a

Consultant part. This would involve the technical knowledge of how the
entities of the domain interface with the software being
developed. For example, a banking domain consultant or
a telecom domain consultant.

Reviewer A software engineer who reviews artifacts like project

documents or code. The review can be a technical review
which scrutinizes the technical details of the artifact. It
could be a review where the reviewer ascertains whether or
not the artifact adheres to a prescribed standard

Architect A software engineer involved in the design of the solution

after the analyst has clearly specified the business
requirements

Developer A software engineer, who writes the code, tests it and

delivers it error free

Tester A software engineer who conducts tests on the completed

software or a unit of the software. If any defects are found
these defects are logged and a report is sent to the owner
of the tested unit.

Programming Team Structure:

Every programming team must have an internal structure. The
best team structure for any particular project depends on the nature
of the project and the product, and on the characteristics of the
individual team members. Basic team structure includes:
a. Democratic team: Team Member participate in all decisions

b. Chief Programmer Team: A chief programmer is assisted

and supported by other team members.

19 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

c. Hierarchical Team: The project leader assigns tasks attend

reviews and walkthrough, detects problem areas, balances the
workload and participates in technical activities.

Democratic Team:
This was first described by Weinberg as the “egoless team”. In an egoless team goals
are set and decisions made by group consensus. Group leadership rotates from
member to member based on the tasks to be performed and the differing abilities
of the team members. Work products (requirements, design, source code, user
manual, etc) are discussed openly and are freely examined by all team
members.
Advantage:
❖ Opportunity for each team member to contribute to decision

❖ Opportunity for team members to learn from one another

❖ Increased Job satisfaction that results from good

communication in open, non-threatening work environments.
The chief programmer team:
1. The chief programmer team consists of -
 The chief programmer
 The project assistant
 The project secretary
 Specialists (language specialists, programmers, test specialists).
2. The chief programmer is actively involved in the planning,
specification and design process and, ideally, in the
implementation process as well.
3. The chief programmer controls project progress, decides all
important questions, and assumes overall responsibility.
4. The qualifications of the chief programmer need to be accordingly high.
5. The project assistant is the closest technical coworker of the chief
programmer.
6. The project assistant supports the chief programmer in all
important activities and serves as the chief programmer's
representative in the latter's absence. This team member's
qualifications need to be as high as those of the chief
programmer.
7. The project secretary relieves the chief programmer and all other
programmers of administrative tasks.

20 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

8. The project secretary administrates all programs and documents

and assists in project progress checks.
9. The chief programmer determines the number of specialists needed.
10. Specialists select the implementation language, implement
individual system components, choose and employ software tools,
and carry out tests.
Hierarchical organizational model:
1. There are many ways to organize the staff of a project. For a long
time the organization of software projects oriented itself to the
hierarchical organization common to other industrial branches.
Special importance is given t o the decomposition of software
development into individual phases. A responsible leader is assigned
to each of the phases, which are led and controlled by the project
leader and which, depending on the size of the project, are led
and controlled either by a single person or by a group leader.
2. The project manager normally also has a project management staff
with advisory and administrative tasks.
3. The larger the project, the greater is the number of hierarchy levels in
the organizational schema.
4. The project manager's tasks and responsibilities are -
 personnel selection,
 assignment and management,
 planning of and division of work for the project,
 project progress checks, and
 appropriate measures in case of cost or schedule overruns.
5. The project management staff includes personnel who advise the
project manager in task-specific questions, provide support in
administrative tasks concerning project progress checks, prepare
project standards, provide the necessary resources, and carry out
training for project team members as needed.
6. The managers at the middle management level are responsible for
planning, execution and control of phase-related activities of the
software life cycle.

11. OTHER PLANNING ACTIVITIES:

Project management is the discipline of defining and achieving

targets while optimizing the use of resources (time, money, people,
materials, energy, space, etc) over the course of a project (a set of

21 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

activities of finite duration).

Project Management is the responsibility of an individual project
manager. This individual rarely participates directly in the activities that
produce the end result, but rather strives to maintain the progress
and productive mutual interaction of various parties in such a way
that overall risk of failure is reduced.

A project is "a temporary effort undertaken to create a unique

product or service." The duration of a project is the time from its
start to its completion, which can take days, weeks, months or even
years.
Project Management is composed of several different types of
activities such as:
 Planning the work
 Assessing risk
 Estimating resources
 Organizing the work
 Acquiring human and material resources
 Assigning tasks
 Directing activities
 Controlling project execution
 Reporting progress
 Analyzing the results based on the facts achieved
Project control variables:
Project Management tries to gain control over five variables:

• time
project • cost
control
• quality
variable
s • scope
• risk

22 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Time - The amount of time required to complete the project. Typically

broken down for analytical purposes into the time required to
complete the components of the project, which is then further broken
down into the time required to complete each task contributing to the
completion of each component.
Cost - Calculated from the time variable. Cost to develop an internal
project is time multiplied by the cost of the team members involved.
When hiring an independent consultant for a project, cost will typically
be determined by the consultant or firm's hourly rate multiplied by an
estimated time to complete.
Quality - The amount of time put into individual tasks determines the
overall quality of the project. Some tasks may require a given amount
of time to complete adequately, but given more time could be
completed exceptionally. Over the course of a large project, quality
can have a significant impact on time and cost (or vice versa).
Scope - Requirements specified for the end result. The overall definition
of what the project is supposed to accomplish, and a specific
description of what the end result should be or accomplish.
Risk - Potential points of failure. Most risks or potential failures can
be overcome or resolved, given enough time and resources.
Three of these variables can be given by external or internal
customers. The value(s) of the remaining variable(s) is/are then set by
project management, ideally based on solid estimation techniques.
The final values have to be agreed upon in a negotiation process
between project management and the customer.

23 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

UNIT - 2

1. SOFTWARE COST ESTIMATION:

The necessity of cost estimation begins from the requirements of

scheduling and cost planning.
For lack of more precise methods, cost estimation for software
development is almost always based on a comparison of the current
project with previous ones. Due to the uniqueness of software systems,
the number of comparable projects is usually quite small, and realistic
data are rarely available.
The technical and organizational conditions are variable parameters,
which makes observed data from comparable projects only an unreliable
basis for estimates.
The time requirement for each task handled in a team consists of two
basic components -
➢ Productive work
➢ Communication and mutual agreement of team members
If no communication were necessary among team members, then the
time requirement t for a project would decline with the number n of team
members
t = 1/n
If each team member must exchange information with one other and that
the average time for such communication is k, then the development time
follows the formula:

t = 1/n + k. n2/2
"Adding manpower to a late software project makes it later."
Most empirical values for cost estimation are internal and unpublished. The
values also depend greatly on the techniques and tools used.
The following options are useful to achieve reliable cost and effort estimates:
1. Delay estimation until late in the project. The longer we wait,
the less likely we are to make errors in our estimates. However
this is not practical. Cost estimates must be provided “up-
front”.
2. Base estimates on similar projects that have already been
completed. This works well if the current project is quite similar
to past efforts. Unfortunately, past experience has not always
been a good indicator of future results.
3. Use “decomposition techniques” to generate project cost and
effort estimates. These techniques use a “divide and conquer”

24 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

approach to estimation. By decomposing a project into major functions

and related software engineering activities, cost and effort
estimation can be performed in a step-wise fashion.
2. SOFTWARE COST FACTORS:

Estimating the cost of software development involves considering various factors that can
significantly impact the overall budget. Some important cost factors are -

1. Project Scope and Complexity:

The complexity and scope of the project significantly impact cost estimation. Projects with
extensive requirements and functionalities may require more resources and,
consequently, higher costs.

The more extensive and complex the project, the higher the cost.

2. Technology Stack:

A technology stack (tech stack) is a combination of programming languages, frameworks,

libraries, tools, and technologies used to develop and deploy a software application. It
consists of two main components: The choice of programming languages, frameworks,
and tools can affect costs. Advanced or specialized technologies may require more
resources and expertise.

3. Team Composition:

The size, skill level, and location of the development team play a crucial role. Highly
skilled professionals or teams in high-cost regions may demand high salaries.

4. Project Timeline:

Tight deadlines can increase costs due to the need for additional resources or
overtime. Conversely, extended timelines may delay product launches and
increase opportunity costs.

5. Testing and Quality Assurance:

Ensuring thorough testing and quality assurance is essential to avoid costly errors
and rework.

6. Risk Management:

Anticipating and mitigating potential risks, such as market volatility or technical

challenges, is integral to accurate cost estimation. This may involve contingency
planning and risk mitigation strategies.

25 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

7. Contractual Terms:

Ownership of the source code and other contractual terms can influence
pricing. For example, if the customer requires the source code, this can
increase the cost.

8. Requirements Volatility:

Frequent changes or unclear requirements can lead to increased costs due to the
need for additional development and adjustments.

Understanding these factors can help to prepare better estimates and manage the
costs associated with software development projects.

3. SOFTWARE COST ESTIMATION TECHNIQUES:

There are several software cost estimation techniques( cost estimation models). The
important software cost estimation techniques are –
1. COCOMO model
2. Function point analysis
3. Program evaluation and review technique(PERT).

1. COCOMO model:

The COCOMO (Constructive Cost Model) is a widely used software cost estimation model
developed by Barry Boehm in 1981. It helps predict the effort, cost, and schedule required
for a software development project based on the project’s size, typically measured in lines
of code (LOC).

COCOMO categorizes projects into three types based on their complexity and size:

1. Organic: Small, simple projects with a well-understood problem domain and

experienced teams.
2. Semi-Detached: Medium-sized projects with a mix of experienced and less
experienced team members.
3. Embedded: Large, complex projects with stringent requirements and constraints

Calculation Process

The COCOMO model uses the following formula to estimate effort:

Effort (E) = a (KLOC)^b

Where:

26 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

 KLOC is the number of thousands of lines of code.

 a and b are constants that vary based on the project type.

In the Basic COCOMO model:

 Organic: (a = 2.4), (b = 1.05)

 Semi-Detached: (a = 3.0), (b = 1.12)
 Embedded: (a = 3.6), (b = 1.20) .

2. Function Point Analysis (FPA):

Function Point Analysis (FPA) is a technique used in software engineering to measure the
size and complexity of a software system based on its functionality. It helps in estimating
the effort, cost, and time required for software development.

Steps in Function Point Analysis -

1. Identify Functions:
o External Inputs (EI): User inputs that provide data to the system (e.g., input
screens, tables).
o External Outputs (EO): Outputs generated by the system for the user (e.g.,
reports, output screens).
o External Inquiries (EQ): User-initiated requests for data (e.g., prompts,
interrupts).
o Internal Logical Files (ILF): Internal data stores maintained by the system
(e.g., databases, directories).
o External Interface Files (EIF): Data stores shared with other systems (e.g.,
shared databases, shared routines).
2. Assign Weights:
o Each function is assigned a weight based on its complexity (Low, Average,
High). For example:
 EI: 3 (Low), 4 (Average), 6 (High)
 EO: 4 (Low), 5 (Average), 7 (High)
 EQ: 3 (Low), 4 (Average), 6 (High)
 ILF: 7 (Low), 10 (Average), 15 (High)
 EIF: 5 (Low), 7 (Average), 10 (High)
3. Calculate Unadjusted Function Points (UFP)
4. Adjust for Complexity

Benefits of Function Point Analysis:

 Language Independent: Measures functionality, not code.

 User-Oriented: Focuses on what the user receives.
 Standardized: Provides a consistent measure across projects.

27 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Function Point Analysis is a valuable tool for project managers to estimate and manage
software development projects effectively.

3. The Program Evaluation and Review Technique (PERT):

The Program Evaluation and Review Technique (PERT) is a project management tool used to plan,
schedule, and control complex projects. It helps in identifying the minimum time required to
complete a project by analyzing the tasks involved and their dependencies. Here’s an
overview of how PERT works in software engineering:

Key Concepts of PERT:

1. Tasks and Milestones:

o Tasks: Individual activities that need to be completed.
o Milestones: Significant points or events in the project timeline.
2. PERT Chart:
o A visual representation of the project’s tasks and milestones, showing the
sequence and dependencies between them.
3. Time Estimates:
o Optimistic Time (O): The shortest time in which a task can be completed.
o Pessimistic Time (P): The longest time a task might take.
o Most Likely Time (M): The best estimate of the time required to complete
the task, assuming everything proceeds as normal.
4. Expected Time (TE):
o Calculated using the formula: [ TE = \frac{O + 4M + P}{6} ]
5. Critical Path:
o The longest path through the PERT chart, determining the minimum project
duration. Tasks on this path are critical and any delay in them will delay the
entire project.

Steps to Create a PERT Chart:

1. List Tasks:
o Identify all tasks required to complete the project.
2. Determine Dependencies:
o Identify which tasks depend on the completion of others.
3. Estimate Times:
o For each task, estimate the optimistic, pessimistic, and most likely times.
4. Draw the PERT Chart:
o Create a network diagram showing tasks as nodes and dependencies as
arrows.
5. Calculate Expected Times:
o Use the formula to calculate the expected time for each task.
6. Identify the Critical Path:
o Determine the longest path through the network diagram.

28 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

4. STAFFING LEVEL ESTIMATION:

Staffing level estimation in software engineering involves determining the number of

personnel needed at different stages of a software development project.

Estimating Staff includes the processes required to make the most

effective use of the people involved with the project.
The number of people required varies for every software project and it
can be determined only after an estimate of development effort is
made.

This process ensures that the project has the right number of people with the right skills at
the right time.

Project Phases:

1. Planning and Analysis: Requires a small group of senior analysts and project
managers.
2. Design: Involves a larger group including architects and senior developers.
3. Implementation and Testing: The largest group is needed here, including
developers, testers, and quality assurance personnel.
4. Deployment and Maintenance: A smaller group for deployment and ongoing
support.

Steps in Staffing Level Estimation:

1. Workload Analysis:
Determine the number and type of tasks required to complete the project.
2. Workforce Analysis:
Assess the current availability of personnel and their skills.
3. Gap Analysis:
Identify the difference between the required and available workforce.
4. Staffing Plan:

Develop a plan to recruit, train, and allocate personnel to fill the gaps.

Example:

Let’s consider a medium-sized software project with the following phases and estimated
durations:

 Planning and Analysis: 2 months

 Design: 3 months
 Implementation: 6 months
 Testing: 3 months
 Deployment and Maintenance: 2 months

29 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Using the Rayleigh-Norden curve method, we can estimate the staffing levels:

 Planning and Analysis: 2-3 senior analysts and project managers.

 Design: 5-6 architects and senior developers.
 Implementation: 10-12 developers and 4-5 testers.
 Testing: 8-10 testers and quality assurance personnel.
 Deployment and Maintenance: 3-4 support staff.

5. Estimating software Maintenance Costs:

Each type of maintenance plays a crucial role in ensuring the software remains functional,
efficient, and secure over its lifecycle.

Software maintenance costs can be categorized based on the type of maintenance activities
performed –

1. corrective maintenance costs

2. Adaptive maintenance costs
3. Perfective maintenance costs
4. Preventive maintenance costs

1. Corrective Maintenance Costs

Costs associated with Fixing bugs and errors that are discovered after the software
has been deployed.

2. Adaptive Maintenance Costs

Costs related to modifying the software to work with new versions of operating
systems, integrating with new hardware, or complying with new regulations.

30 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

3. Perfective Maintenance Costs

costs for adding new features, improving performance, and making the software
more efficient or user-friendly.

4. Preventive Maintenance Costs

Costs associated with refactoring code to reduce complexity, conducting regular

code reviews, and implementing automated testing to catch issues early.

Factors Influencing Maintenance Costs:

 Software Complexity: More complex systems require more effort to maintain.

 User Base: A larger number of users can lead to more feedback and issues to
address.
 Frequency of Updates: Regular updates and patches can increase maintenance
costs.
 Sourcing Model: In-house vs. outsourced maintenance can significantly impact costs.

Estimating software maintenance costs involves considering various factors and using
different models to get accurate predictions. Here are some key points and methods to help
you understand and estimate these costs:

Cost Estimation Models:

1. COCOMO Model:

The Constructive Cost Model (COCOMO) is widely used for estimating

software development and maintenance costs. It considers factors like
software size, complexity, and team experience.

2. Function Point Analysis (FPA):

FPA measures the functionality delivered to the user based on the number of
inputs, outputs, user interactions, files, and interfaces. It helps in estimating
the effort required for maintenance by quantifying the software’s functional
size.

6. THE SOFTWARE REQUIREMENT SPECIFICATION:

1. A complete understanding of the software requirements is

essential to the success of a software development.. Requirements
analysis task is a process of discovery, improvement, modeling, and
specification.
2. The specification produced becomes the foundation for all

31 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

software engineering activities. The final output of the requirements

analysis is the creation of a Software Requirements Specification
(SRS) document.

3. A Software Requirements Specification (SRS) is a complete document that describes

the requirements of a software system to be developed.
4. It serves as a foundation for successful software development by specifying both
functional and non-functional requirements.
5. A good SRS should be understandable, complete, consistent, and
unambiguous.
The Format of Software requirements specification document I contains –

1. Purpose of the Document:

 The SRS document outlines the purpose of the software system, its
scope, and the value it will provide to the customer.
 It also includes information about development costs and the time
required for development.

2. General Description:

This section provides an overview of the product. It includes:

 The product’s functions and objectives.

 User characteristics.
 Features and benefits.
 Importance of the product.
 Features relevant to the user community.
3. Functional Requirements:

 Functional requirements describe the expected behavior of the

system.
 They specify the outcomes resulting from the operation of the
software system.
 These requirements can include calculations, data processing, and
other functionalities.
 Each functional requirement should detail data inputs, their sources,
units of measure, and valid input ranges.

4. Interface Requirements:

 Interface requirements describe how the software system communicates

with other software programs or users.

32 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

 Examples of interfaces include shared memory, data streams, and

communication protocols.

5. Performance Requirements:

 Performance requirements define how the software system should

perform under specific conditions.
 They address desired functions and system behavior.
 For instance, response times, throughput, and resource utilization fall
under performance requirements.

6. Design Constraints:

 Design constraints specify limitations or restrictions related to the

software system’s design.
 These constraints may include hardware limitations, compatibility
requirements, or architectural decisions.

7. Non-Functional Attributes:

 Non-functional requirements cover aspects beyond functionality, such as

reliability, security, usability, and maintainability.
 These attributes contribute to the overall quality of the software system.

8. Preliminary Schedule and Budget:

 This section outlines the estimated development schedule and associated

costs.
 It helps stakeholders understand the project timeline and budget
constraints.

9. Appendices:

Appendices may include additional information, such as glossaries, diagrams, or

supplementary details.

7. FORMAL SPECIFICATION TECHNIQUES:

Formal specifications have the advantage of being brief and clear-cut, they
support formal reasoning about the functional specifications, and they
provide a basis for verification of the resulting software product.
Formal specifications define requirements by using mathematically precise formal logic
languages . The advantage of using mathematics is that it is precise, unlike the more
ambiguous natural language and diagrams which are often used for specifications.
There are two types of formal specifications they are:

33 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

1. Relational Notations
2. State-Oriented Notations
1.Relational Notations:
Relational Notations are based on the concepts of entities and
attributes.
Entities are named elements in a system; the names are chosen to
denote the nature of the elements.
Attributes are specified by applying functions and relations to the name
entities. Attributes specify permitted operations on entities,
relationships among entities, and data flow between entities.
Formal specifications, often based on a textual mathematical notation, can also be
expressed graphically.
A formal specification is simply a description of a system using a mathematical notatios like
-Implicit equations, recurrence relations, algebraic axioms and regular
expressions.

Example:

type ordered_pair = tuple (int ord, int abs)

(1, 2) is an element of type ordered_pair

Example:

<1, 2, 3> || <5> = <1, 2, 3, 5>

State-Oriented Notations:
The state of a system is the information required to summarize the
status of system entities at any particular point in time; given the
current state and the current stimuli, the next state can be determined.
The execution history by which the current state was attained does not
influence the next state; it is only dependent on the current state and
current stimuli.
Example:
Following state diagram example chart represents the user authentication process.

34 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

UML state diagram

There are a total of two states, and the first state indicates that the OTP has to be entered
first. After that, OTP is checked in the decision box, if it is correct, then only state transition
will occur, and the user will be validated. If OTP is incorrect, then the transition will not take
place, and it will again go back to the beginning state until the user enters the correct OTP
as shown in the above state machine diagram example.

8. Languages & Processors for Requirements Specification:

A number of special-purpose languages and processors have been

developed to permit concise statement and automated analysis of
requirements specifications for software.
Some specification languages are graphical in nature, while others are
textual; all are relational in nature. Some specification languages are
manually applied and other has automated processors.
The Problem Statement Language (PSL) was developed by Prof. Daniel
Teichrow at the University of Michigan. The Problem Statement
Analyzer (PSA) is the PSL processor.
The objective of PSL is to permit expression of much of the
information that commonly appears in a Software Requirements
Specification. In PSL, system descriptions can be divided into eight

35 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

major aspects:
1. System input/output flow
2. System structure
3. Data structure
4. Data derivation
5. System size and volume
6. System dynamics
7. System properties
8. Project management
PSL contains a number of types of objects and relationships to permit
description of these eight aspects. The system input/output flow
aspect deals with the iteration between a system and its environment.
The Problem Statement Analyzer (PSA) is an automated analyzer for
processing requirements stated in PSL.
Some of the specification languages are -
1. RSL/REVS:
The Requirements Statement Language (RSL) was developed by the TRW
Defense and Space Systems Group to permit brief and clear-cut
specification of requirements for real-time software systems. The
Requirements Engineering Validation Systems (REVS) processes and
analyzes RSL statements; both RSL and REVS are components of the
Software Requirements Engineering Methodology. Many of the concepts
in RSL are based on PSL.
2. SADT:

Structured Analysis and Design Technique (SADT) was developed by

D.T. Ross and Colleagues at Softech, Inc. SADT incorporates a graphical
language and set of methods and management guidelines for using the
language.
The SADT language is called the language of Structured Analysis (SA).
The SA language and the procedures for using it are similar to the
engineering blueprint systems used in civil and mechanical engineering.
3. SSA:

Structured System Analysis is used primarily in traditional data

processing environments. Like SADT, SSA uses a graphical language to
build models of systems.
There are four basis features in SSA:
 data flow diagrams,

36 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

 data dictionaries,
 procedure logic representation and
 data store structuring techniques.
3. GIST:

Gist is a formal specification language developed at the USC/Information

Sciences Institute by R. Balzar and colleagues. Gist is a textual language
based on a relational model of objects and attributes. A Gist
specification is a formal description of valid behaviors of a system.
A specification is composed of three parts:
a. A specification of object types and relationships between
these types. This determines a set of possible states.
b. A specification of actions which define t r a n s i t i o n
s between possible states.
c. A specification of constraints on states and state transitions.

37 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

UNIT – 3

1. SOFTWARE DESIGN-FUNDAMENTALS OF SOFTWARE DESIGN:

Design is the first step in the development phase. The goal of

design process is to produce a model or representation of a system,
which can be used later to build that system. The produced model is
called the design of the system.
Software design is an iterative process through which
requirements are translated into a model for constructing the
software. Each of the elements of the requirements analysis model
provides information that is required to
create a design model. The flow of information during software
design is shown below -

FUNDAMENTAL DESIGN CONCEPTS :

Fundamental software design concepts provide the necessary
framework for “getting a program right”.
A set of fundamental software design concepts has evolved over
the years and each provides the software designer with a foundation
from which more sophisticated design methods can be applied.
Each concept helps the software engineer to answer the following
questions:
 What criteria can be used to partition software into
individual components?
 How function or data is structure is separated from a
conceptual representation of the software?

38 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

 Are there uniform criteria that define the technical quality of

a software design?
The fundamental design concepts are:
 Abstraction - allows designers to focus on solving a
problem without being concerned about irrelevant
lower level details. (procedural abstraction -
named sequence of events, data abstraction -
named
collection of data objects)
 Refinement - process of elaboration where the designer
provides successively more detail for each design component
 Modularity – Software is divided into different modules that
are integrated. Since the monolithic software is difficult to
grasp, we need to decompose them into modules. But care
should be taken when modularising. Because at one point of
time, recursive modularising will increase the total effort.
 Software architecture - overall structure of the software
components and the ways in which that structure provides
conceptual integrity for a system
 Control hierarchy or program structure - represents the
module organization and implies a control hierarchy, but does
not represent the procedural aspects of the software (e.g.
event sequences)
 Structural partitioning - horizontal partitioning defines three
partitions (input, data transformations, and output); vertical
partitioning (factoring) distributes control in a top-down
manner (control decisions in top level modules and processing
work in the lower level modules).
 Data structure - representation of the logical relationship
among individual data elements (requires at least as much
attention as algorithm design)
 Software procedure - precise specification of processing (event
sequences, decision points, repetitive operations, data
organization/structure)
Information Hiding:
 The principle of information hiding suggests that modules be
“characterized by design decisions that hide from all others”.
 In other words, modules should be specified and designed so
that information 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

39 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

defining a set of independent modules that communicate with one

another only that information that is necessary to achieve software
function.
Procedural Design:
Procedural design occurs after data, architectural, and
interface designs have been established.
The procedural specification required to define algorithmic
details would be stated in a natural language like English.
All members of a software development organization can
understand this common natural language. But the disadvantage in
using this natural language is that we can write a set of procedural
steps in too many different ways.

2. MODULES AND MODULARIZATION CRITERIA :

1. The process of breaking down a software into multiple independent modules
where each module is developed separately is called Modularization.
2. A module is defined as the unique and addressable components of the software
which can be solved and modified independently without disturbing Thus every
software design should follow modularity.
3. Effective modular design can be achieved if the partitioned modules are
separately solvable, modifiable as well as compilable.
4. Architectural design has the goal of producing well-structured,
modular software systems.
5. A software module contains the following characteristics -
 Modules contain instructions, processing logic, and data structures.
 Modules can be separately compiled and stored in a library.
 Modules can be included in a program.
 Module segments can be used by invoking a name
and some parameters.
 Modules can use other modules.
Examples of modules include procedures, subroutines, and functions.
Software Architecture:
Software architecture is 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, the manner in which these components interact, and the
structure of the data that are used by the components.
One goal of software design is to derive an architectural interpretation
of a system. This rendering serves as a framework from

40 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

which more detailed design activities are conducted. A set of

architectural patterns enables a software engineer to reuse design
level concepts.

Control Hierarchy:
Control hierarchy, also called program structure, represents the
organization of program components and implies a hierarchy of
control. It does not represent procedural aspects of software such as
sequence of processes, occurrence/order of decisions, or repetition of
operations.
A tree-like diagram is used to represent the hierarchy. Depth
provides an indication of the number of levels of control. Width indicates
the overall span of control. Fan-out is a measure of the number of
modules that are directly controlled by another module. Fan-in
indicates how many modules directly control a given module. The
control relationship among modules is expressed in the following way:
A module that controls another module is said to be superordinate to it;
conversely, a module controlled by another is said to be subordinate to
the controller.

The control hierarchy 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.
Structural Partitioning:
The program structure should be partitioned both horizontally and vertically.
Horizontal partitioning defines separate branches of the modular
hierarchy for each major program function. The simplest approach to
horizontal partitioning defines three partitions – input, data
transformation, and output.
The benefits of horizontal partitioning are -
• Results in software that is easier to test

41 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

• Leads to software that is easier to maintain

• Results in propagation of fewer side effects
• Results in software
that is easier to
extend

Vertical partitioning, often called factoring, suggests that control and work
should be distributed top-down in the program architecture. Top-level
modules should perform control functions and relatively little
processing work. Low-level modules should perform all input,
computational, and output tasks.

3. DESIGN NOTATIONS:

The commonly used design notations are-

1. Structured Programming

2. Graphical Design Notation (GDN)

3. Tabular Design Notation (TDN)

4. Program Design Language (PDL)

1.Structured Programming:
Structured programming is an important procedural design technique.
The three constructs that are fundamental to structured programming are:
 Sequence – Sequence implements processing steps that are
essential in the specification of any algorithm
 Condition – Condition provides the facility for selected
processing based on some logical occurrence
 Repetition – Repetition provides for looping
Each construct has a predictable logical structure, allowing entry at the
top, and exit at the bottom. This enables a reader to follow procedural
flow more easily.
The use of such structured constructs enhances readability, testability,
and maintainability. Also any program can be designed and
implemented only using the three structured constructs.
2.Graphical Design Notation (GDN):
Graphical tools such as flowchart or box diagram provide
excellent pictorial patterns that readily show procedural detail.
Data Flow Diagram (DFD):
A data flow diagram is a graphical technique that illustrates information
flow.

42 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

The data flow diagram may be used to represent system or software

at any levels.
DFD Levels

 Level 0 (Context Diagram): This is the most abstract representation of the system,
showing only the system boundary and external entities.
 Level 1: This level breaks down the main processes identified in the Level 0 DFD into sub-
processes, providing more detail.
 Level 2: Here, individual sub-processes are further decomposed to reveal lower-level data
flows and stores.

Example: A Level 0 DFD is shown below -

Flowchart:
The flowchart is quite simple pictorially. The symbols used in a flowchart are:
 Rectangle Box – to indicate a processing step
 Diamond – represents a logical condition
 Arrows – show the flow of control

The three structured constructs – sequence, condition, and repetition using

the flowchart symbols are given below -

43 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Flowchart Constructs
Box Diagram:
A box diagram has the following characteristics:
1. functional domain is well defined and clearly visible as a
pictorial representation;
2. arbitrary transfer of control is impossible;
3. the scope of local and/or global data can be easily
determined; and
4. Recursion is easy to represent.
The box diagram constructs are shown below –

Box Diagram Constructs

44 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Tabular Design Notation:

Decision Tables provide a notation that translates actions and
conditions into a tabular form.
The table is difficult to misinterpret and may even be used as
a machine readable input to a table driven algorithm.
A decision table is divided into four sections. The upper left
hand quadrant contains a list of all conditions. The lower left hand
quadrant contains a list of all actions that are possible based on
combinations of conditions. The right hand quadrants form a matrix that
indicates condition combinations and the corresponding actions that
will occur for a specific combination. Therefore, each column of the
matrix may be interpreted as a processing rule.
The decision table i s s h o w n b e l o w -

The following steps are applied to develop a decision table:

1. List all actions that can be associated with a specific procedure.

2. List all conditions during execution of the procedure.

3. Associate specific sets of conditions with specific actions,

eliminating impossible combinations of conditions;
alternatively, develop every possible permutation of
conditions.
4. D
efine rules by indicating what action or actions occur for a set
of conditions.

4. DESIGN TECHNIQUES:

45 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

The design process involves developing a conceptual view of

the system, establishing system structure, identifying data streams
and data stores, decomposing high level functions into sub-functions,
establishing relationships and interconnections among components,
developing concrete data representations, and specifying algorithmic
details.
The design activity must begin with the analysis of the
requirements definition and should not consider implementation
details at first.
Design techniques are typically based on two approaches-
 Top-down design, and
 Bottom-up design.
Top-Down Design:

 The top-down approach to software development involves breaking down a large,

complex problem or system into smaller, more manageable pieces and then working
on each piece individually.
 In this technique, the highest-level module or main module for developing the
software is identified.
 The main module is divided into several smaller and simpler submodules or
segments based on the task performed by each module.
 Then, each submodule is further subdivided into several submodules of next lower
level.
 This process of dividing each module into several submodules continues until the
lowest level modules, which cannot be further subdivided, are not identified.
 This approach is often used to develop software systems because it allows
developers to focus on one part of the system at a time, which can make the
development process more organized and efficient.

46 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Bottom-up design:
 The modules at the most basic or the lowest level are identified.
 These modules are then grouped together based on the function performed by each
module to form the next higher-level modules.
 Then, these modules are further combined to form the next higher-level modules.
 This process of grouping several simpler modules to form higher level modules
continues until the main module of system development process is achieved.
 Object-oriented language such as C++ or java uses a bottom-up approach where
each object is identified first.

5. Detailed Design considerations:

Detailed design is the specification of the internal elements of all major system
components, their properties, relationships, processing, and often their algorithms and
the data structures.

The detailed design may include:

1. Decomposition of Components: Break down major system components into smaller,

manageable program units.
2. Functional Responsibilities: Allocate specific functional responsibilities to each unit.
3. User Interfaces: Design user interfaces with a focus on usability and user experience.
4. State Management: Define unit states and state changes to manage the behavior of
each component.
5. Data and Control Interaction: Specify how data and control signals interact between
different units.

47 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

6. Data Packaging and Implementation: Address issues related to the scope and
visibility of program elements.
7. Algorithm and Data Structures: Define the algorithms and data structures used
within each unit.

The following diagram illustrates the detailed design process, starting from analyzing the
Software Requirements Specification (SRS) and Software Architecture Document (SAD),
generating and evaluating design alternatives, and finalizing the detailed design
document.

This visual representation helps in understanding the iterative nature of refining and
selecting the best design solution.

Detailed Design Document:

The document outlined below can be used as a template for a
design specification.
I. Scope
A. System Objectives

B. Major software requirements

C. Design constraints, limitations

II. Data Design

A. Data objects and resultant data structures

B. File and database structures

1. external file structure

a. logical structure

48 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

b. logical record description

c. access method

2. global data

3. file and data cross reference

III. Architectural Design

A. Review of data and control flow

B. Derived program structure

IV. Interface Design

A. Human-machine interface specification

B. Human-machine interface design rules

C. External interface design

1. Interfaces to external data

2. Interfaces to external systems or devices

D. Internal interface design rules

V. Procedura
l Design
Foreach
module:
A. Processing narrative

B. Interface description

C. Design language (or other) description

D. Modules used

E. Internal data structures

F. Comments/restrictions/limitations

VI. Requirements Cross-Reference

VII. Test Provisions
1. Test guidelines

2. Integration strategy

3. Special considerations

VIII. Special Notes

IX. Appendix

49 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

6. Real-time and distributed system design:

Real-time and distributed system design are crucial aspects of software engineering, especially
for applications that require immediate responses and coordination across multiple
locations.

Real-Time Systems

Real-time systems are designed to respond to inputs or events within a strict time
constraint. They are categorized into three types based on timing constraints:

1. Hard Real-Time Systems: These systems must meet their deadlines without fail.
Missing a deadline can lead to catastrophic consequences. Examples include flight
control systems and medical devices.
2. Soft Real-Time Systems: These systems can tolerate occasional deadline misses
without severe consequences. Examples include multimedia streaming and online
gaming.
3. Firm Real-Time Systems: These systems lie between hard and soft real-time
systems. Missing a deadline is tolerable, but the usefulness of the output decreases
over time. Examples include online trading systems and reservation systems.

Distributed Systems

Distributed systems consist of multiple interconnected computers that work together to achieve a
common goal. They are characterized by:

 Scalability: Ability to handle increasing loads by adding more nodes.

 Fault Tolerance: Capability to continue functioning even when some components
fail.
 Concurrency: Multiple processes run simultaneously, improving performance and
efficiency.

Distributed Real-Time Systems

Combining the principles of real-time and distributed systems, distributed real-time systems are
designed to handle tasks that require immediate responses across multiple locations. Key
features include:

 Real-Time Processing: Handling data and executing commands almost

instantaneously.
 Synchronized Components: Components spread across different locations work
synchronously.
 Critical Decision-Making: Actions are based on immediate data analysis, crucial for
safety and efficiency.

50 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Design Considerations

When designing real-time and distributed systems, several factors need to be considered:

1. Task Scheduling: Ensuring high-priority tasks are completed on time.

2. Communication Protocols: Ensuring data flows quickly and reliably between
components.
3. Time Synchronization: Keeping all components in sync to avoid delays.
4. Resource Management: Efficiently allocating and managing resources to prevent
bottlenecks.
5. Fault Tolerance: Implementing mechanisms to handle failures gracefully.

These systems are widely used in industries like manufacturing, healthcare, and
transportation.

8. Test plan:
A test plan is a document that consists of all future testing-related activities. It is prepared at
the project level and in general, it defines work products to be tested, how they will be tested,
and test type distribution among the testers. Before starting testing there will be a test
manager who will be preparing a test plan.

In any company whenever a new project is taken up before the tester is involved in the
testing the test manager of the team would prepare a test Plan.

 The test plan serves as the blueprint that changes according to the progressions in the
project and stays current at all times.
 It serves as a base for conducting testing activities and coordinating activities among a
QA team.
 It is shared with Business Analysts, Project Managers, and anyone associated with the
project.
Types of Test Plans:
The following are the three types of test plans:
 Master Test Plan: In this type of test plan, includes multiple test strategies and has
multiple levels of testing. It goes into great depth on the planning and management of
testing at the various test levels.
 Phase Test Plan: In this type of test plan, emphasis is on any one phase of testing. It
includes further information on the levels listed in the master testing plan. Information
like testing schedules, benchmarks, activities, templates, and other information that is
not included in the master test plan is included in the phase test plan.
 Specific Test Plan: This type of test plan, is designed for specific types of testing
especially non-functional testing for example plans for conducting performance tests
or security tests.

creating a Test Plan:

Below are the eight steps that can be followed to write a test plan:

51 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Create Test Plan

1. Analyze the product: This phase focuses on analyzing the product, Interviewing clients,
designers, and developers, and performing a product walkthrough.
2. Design the test strategy: The test strategy document is prepared by the manager and
details the following information:
 Scope of testing which means the components that will be tested and the ones that
will be skipped.
 Type of testing which means different types of tests that will be used in the project.
 Risks and issues that will list all the possible risks that may occur during testing.
 Test logistics mentions the names of the testers and the tests that will be run by them.
3. Define test objectives: This phase defines the objectives and expected results of the
test execution. Objectives include:
 A list of software features like functionality, GUI, performance standards, etc.
 The ideal expected outcome for every aspect of the software that needs testing.
4. Define test criteria: Two main testing criteria determine all the activities in the testing
project:
 Suspension criteria: Suspension criteria define the benchmarks for suspending all the
tests.
 Exit criteria: Exit criteria define the benchmarks that signify the successful completion
of the test phase or project. These are expected results and must match before moving
to the next stage of development.
5. Resource planning: This phase aims to create a detailed list of all the resources required
for project completion. For example, human effort, hardware and software requirements,
all infrastructure needed, etc.
6. Plan test environment: This phase is very important as the test environment is where
the QAs run their tests. The test environments must be real devices, installed with real
browsers and operating systems so that testers can monitor software behavior in real user
conditions.

52 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

7. Schedule and Estimation: Create a schedule to complete these tasks in the designated
time with a specific amount of effort.
8. Determine test deliverables: Test deliverables refer to the list of documents, tools, and
other equipment that must be created, provided, and maintained to support testing
activities in the project.

9. WALK THROUGHS AND INSPECTIONS:

The walkthrough is a procedure that is commonly used to
check the correctness of models produced by structured systems
analysis, although its techniques are applicable to other design
methodologies. Such checking has always been necessary in system
life cycle.
A Walkthrough team usually consists of a review and three to five
reviewers. On one-or two-person project it may not be cost-effective
to assemble a review team.
however, the walkthrough technique can be beneficial with only
one or two reviewers. The team must check that the model:
❖ Meets system objectives;

❖ Is a correct representation of the system;

❖ Has no omissions or ambiguities;

❖ Will do the job it is supposed to do; and

❖ Is easy to understand.

Software Reviews:
Software reviews are a filter for the software engineering
process. Reviews are applied at various points during software
development to uncover errors, which can be removed. So Software
reviews help to eliminate defects in the software work products that
occur as a result of improper analysis, design,
and coding.
Any review helps the diversity of a group of people to -
1. identify needed improvements in the product

2. conform those parts in which improvement is neither

desired nor needed
3. achieve work of uniform, or at least predictable, quality
to make technical work more manageable.
Reviews can either be formal or informal. Formal technical reviews are
more effective from a quality assurance standpoint and effective

53 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

means for improving software quality.

Formal Technical Reviews

A Formal Technical Review (FTR) is a software quality assurance
activity that is performed by software engineers. The objectives of
the FTR are:
1. To uncover errors in function, logic or implementation

2. To verify the software under review meets requirements

3. To ensure Software is as per predefined standards

4. To achieve uniform development of software

5. To make projects more manageable

Each FTR is conducted as a meeting, and will be successful only if it

is properly planned, controlled and attended.
The Review Meeting:
Every review meeting should focus on a specific part of the overall
software. It should be:
1. Attended by 3-5 people
2. Should be well planned, but not require more than two hours
of work per person
3. Of less than two hours duration
The focus of the FTR is on a work product – a component
of the software.

The individual who has developed the work product is the

Producer. The Producer informs the Project Leader that the work
product is complete, and a review is required.

The Project Leader contacts a Review Leader who evaluates the

work product for readiness, generates copies, and distributes them
to two or three reviewers for advance preparation. Concurrently, the
Review Leader also reviews the work product and establishes an
agenda for the review meeting.
The Review Leader, all reviewers and the Producer attend the
Review Meeting. The producer presents the work product and the
reviewers raise issues if any.
One of the reviewers takes on the role of recorder. The
recorder records all important issues raised during the review, like
problems and errors.

54 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

After the review, all attendees of the FTR must decide whether to
1. Accept the work product without modification,

2. Reject the work product due to severe errors, or

3. Accept the work product provisionally.

Once the decision is made, all FTR attendees complete a Sign-

off, indicating their participation in the review, and their concurrence
with the review team’s findings.
During the FTR, it is important to summarize the issues and
produce a Review Issues List, and a Review Summery Report. A Review
Summery Report becomes the part of the Project Historical Record,
and contains information about what was reviewed, who reviewed,
and the findings and conclusions of the review. This report is
distributed to the Project Leader, and other interested parties.

Inspections:

Inspections, like walkthroughs, can be used throughout the software

life cycle to asses and improve the quality of the various work products.
Inspection teams consist of one to four members (producer, inspector,
moderator, reader) who are trained for their tasks.
The producer, whose product is under review, inspector who evaluates
the product, and the moderator who controls the review process.
There is also a reader, who may guide inspectors through the product.
Inspections are conducted in a similar manner to walkthrough, but
more structure is imposed on the sessions, and each participant has
a definite role to play.
Each of the roles in an inspection team would have well-defined
responsibilities within the inspection team.
The important steps are -
1. Overview, where the producers of the work explain their work to
inspectors.
2. Preparation, where the inspectors prepare the work and the
associated documentation for inspection.
3. Inspection, which is meeting moderated by the moderator and
guided by a reader who goes through the work with the
inspectors.
4. Rework, which is any work required by the producers to
correct any deficiencies.

55 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

5. Follow-up, where a check is made to ensure that any deficiencies

have been corrected.
The important thing here is that the inspections are formal and
have a report that must be acted on. It is also important that any
recommendations made during inspections be acted upon and followed
up to ensure that any deficiencies are corrected.

56 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

UNIT – 4

User Interface (UI) design and Real time systems

1. User Interface (UI) design:
1. User Interface (UI) defines the way humans interact with the information systems.
The user interface is also known as the front-end application view.
2. User Interface (UI) is a series of pages, screens, buttons, forms, and other visual
elements that are used to interact with the device. Every app and
every website has a user interface.
3. Interface elements consist of input controls (buttons, drop-down menus, data
fields), navigational components (search fields, slider, icons,
tags), and informational components (progress bars, notifications, message
boxes).

4. User Interface (UI) design for real-time systems involves creating interfaces that are
not only user-friendly but also capable of handling the demands of real-time
operations.
5. Real-time systems require timely and deterministic responses to inputs. They are
often used in critical applications like medical devices, automotive systems, and
industrial automation
6. The software becomes more popular if its user interface is:
 Attractive
 Simple to use
 Responsive in a short time
 Clear to understand
 Consistent on all interface screens
Types of UI Design:
There are several types of User Interface (UI) depending upon the interaction between
users and computers or electronic devices in different ways
. Some common types of User Interface(UI) are -
1. GUI (Graphical User Interface): Visual user interface output (keyboard and
monitor) with a tactile user interface input.
2. Menu Driven Interface: An UI that uses a menu of options to navigate a program
or website is known as a menu-driven UI. For instance, ATMs have user interfaces
that are menu-driven and simple to use.
3. Form Based Interface: Form-based user interfaces provide a small number of
options for users to choose from when entering data into a program or application.
For instance, a device’s settings menu is form-based.
4. Touch user interface: Haptic or tactile user interface. Haptic input is used by
most smartphones, tablets, and other devices with touch screens.
5. Voice user interface: voice is used to communicate between humans and
machines. GPS, talk-to-text gadgets, and virtual assistants are a few examples.

User Interface Design Process:

The analysis and design process of a user interface is iterative and can be represented by
a spiral model. The analysis and design process of user interface consists of four

57 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

framework activities.

1. User, Task, Environmental Analysis, and Modeling:

Initially, the focus is based on the profile of users who will interact with the system, i.e.,
understanding, skill and knowledge, type of user, etc., based on the user’s profile users
are made into categories. From each category requirements are gathered.
Based on the requirement’s developer understand how to develop the interface. Once all
the requirements are gathered a detailed analysis is conducted.
In the analysis part, the tasks that the user performs to establish the goals of the system
are identified, described and elaborated. The analysis of the user environment focuses on
the physical work environment.
Among the questions to be asked are:
1. Where will the interface be located physically?
2. Will the user be sitting, standing, or performing other tasks unrelated to the interface?
3. Are there special human factors considerations driven by environmental factors?
2. Interface Design:
The goal of this phase is to define the set of interface objects and actions i.e., control
mechanisms that enable the user to perform desired tasks. Indicate how these control
mechanisms affect the system.
Specify the action sequence of tasks and subtasks, also called a user scenario. Indicate the
state of the system when the user performs a particular task.
Design issues such as response time, command and action structure, error handling, and
help facilities are considered as the design model is refined. This phase serves as the
foundation for the implementation phase.
3. Interface Construction and Implementation:
The implementation activity begins with the creation of a prototype (model) that enables
usage scenarios to be evaluated. As iterative design process continues a User Interface
toolkit that allows the creation of windows, menus, device interaction, error messages,
commands, and many other elements of an interactive environment can be used for
completing the construction of an interface.
4. Interface Validation:

58 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

This phase focuses on testing the interface. The interface should be in such a way that it
should be able to perform tasks correctly, and it should be able to handle a variety of
tasks.
It should achieve all the user’s requirements. It should be easy to use and easy to learn.
Users should accept the interface as a useful one in their work.

2. Human factors:
Human factors play a crucial role in user interface (UI) design, especially in real-time systems
where timely and accurate user interactions are essential.

Human factors in user interface design in real time systems are -

1. Usability and User-Centered Design

 Involving users throughout the design process ensures that the interface meets their
needs and expectations. This approach emphasizes usability, making systems easy to
learn and efficient to use.
 Consistent design elements help users predict system behavior, reducing cognitive
load and improving efficiency.

2. Cognitive Load Management

 Real-time systems should present information in a way that minimizes the mental
effort required to process it. This can be achieved by organizing information logically
and using familiar concepts.
 Providing immediate feedback helps users understand the system’s state and their
actions’ outcomes, which is critical in real-time environments.

3. Error Prevention and Recovery

 Designing interfaces that prevent errors can significantly enhance user experience.
This includes clear instructions, intuitive controls, and confirmation dialogs for
critical actions.
 When errors occur, the system should offer easy ways to recover, such as undo
options or helpful error messages.

4. Accessibility and Ergonomics

 Ensuring that the interface is accessible to all users, including those with disabilities,
is essential. This includes using appropriate color contrasts, font sizes, and
alternative text for images.
 Ergonomics: Designing for physical comfort can reduce strain and fatigue, which is
particularly important in real-time systems where users may interact with the
interface for extended periods.

59 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

5. Emotional Design

 Positive User Experience: Incorporating elements that evoke positive emotions can
enhance user satisfaction and engagement. This includes artistically pleasing designs
and interactive elements that are enjoyable to use.

By focusing on these human factors, designers can create more effective and user-friendly
interfaces for real-time systems.

3. Human Computer Interaction:

HCI (Human Computer Interaction) is a field of study that refers to communication between
the human user and a computer system. Here interface refers to a medium or interaction
between the computer and the end user.

It is also known as CHI (Computer Human Interface) or MMI (Man Machine Interaction). It
is concerned with design, evaluation, and implementation. It is used to provide a user-
friendly environment.
Human uses digital devices to perform various activities. HCI is to design a systems in such
a way that make them efficient, stable, usable and attainable. Lack of communication can
result in poor designed user interfaces.
It provides a ways to reduce design time through various task models.
There are some disciplines contributing to HCI are -

60 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Computer Science
Computer science is a field of computation and information. Computer science plays a
crucial role in modern development of HCI. Smart Television, Voice assistant, are some of
the technology exists in modern world, that are running our day to day life.
Cognitive Psychology
It is a field of HCI which identifies how human interact with systems. It includes Language
based interaction, a set of rules are provided to the system. Based on that rules we create
our model. It also includes Human motor skills, where we identifies physical
characteristics of user and based on that characteristics we create our model.
Fine arts design
An artistic way of thinking always produce creative ideas. E-books and novels, digital
drawings, video games are some of the applications of fine arts contributing to HCI.

Health care
Patients can buy medicines online and book appointments with doctor just with the help
of mobile application. Augmented Reality(AR) and Virtual Reality(VR) are now
transforming surgical process, previously it was very risky.
User-friendly interfaces for devices like MRI machines and patient monitoring systems
enhance usability. Now doctor can use 3D animations to visualize the process. It can be
used to train new surgeons.
Education
There are so many resources available on internet now a days. Class room teaching are
now very interesting with the help of smart classes. AR/VR can really help students to
visualize any concept very easily. Students have option to study online.
Banking
Now common people don’t need to wait in long queues of bank. They can get banking
solution right at their home using Net banking or Mobile banking. ATM machines also

61 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

make Banking more convenient. These application also provides user a secure
environment to avoid cyber crimes.
Networking
Networking is very easy now a days. It includes social media networking and business
networking. Now it is very easy for us to connect and share thoughts with anyone. It
streamlines the process of finding jobs.

Use Cases of HCI:

1. Smart home : Smart homes refers to home amenities that have been fitted with
communication technology enabling some degree of automation or remote
control. It includes control of air conditioning, heating and lighting through voice
activated commands or mobile app. Home security systems are also fitted with
communication technology to alert the residents in case of theft.
2. Biometric Sensors : Biometric sensors are the use of human biometrics in various
technological applications. It can be used in access controls for example granting
access to a computer network or security system.
4. Human-computer interface(HCI) Design:
Human-Computer Interface Design is a multidisciplinary field that puts emphasis on the
interaction between a computer and a human.
It’s about ensuring the smooth interaction between a human and a computer system by
ensuring that the computer systems are user-friendly and efficient.
Some important aspects in Human computer Interface design are given below -
 User-centric Design: The heart of HCI design is to make the computer system user-
friendly, to do that it is recommended to design the computer in the most user-
friendly way possible. This approach takes into account the need of the user and their
preference throughout the entire design process.
 Prototype: Most of the time designers create a prototype of the final product and let
the users try it beforehand and ask them to provide feedback so that they can make
some improvements in the final product and the final product will have fewer
problems.
 Accessibility: HCI designers also need to keep in mind the systems that can be
accessible by everyone, even by the person who has some disabilities. So keeping that
in mind and adhering to the rules, they designed the system in such a way so that
everyone can use that.
 UI Design: The main thing that comes up when using any system is the User Interface
(UI), and a simpler UI makes more people use the application. So the designers use
various design software to come up with a simple yet effective UI that everyone can
use.

There are three principles which are used by the designers for the user-centered
approach:

1. Data based evaluation

2. Early Emphasis on User Needs and Objectives
3. Design in an iterative manner.

62 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

1. Data-Based Evaluation:
Data-based evaluation is a technique that depends upon user feedback and empirical data to
assess the usefulness of a certain design prototype before making the final design. This
process is solely done to ensure that the design meets all the expectations of the main
user or the stakeholders.
2. Early Emphasis on User Needs and Objectives:
Putting an early emphasis on the user needs and objectives makes the design more user- friendly
as well as used to improve the design based on the user’s need, main aim, and context. It also
helps to ensure that the final design is user-centric, fulfills the user’s needs and easy to use
by the user. Usually the designers does this during the early stage of the design, so that they
keep in mind about the user’s needs and aim throughout the entire design process.

3. Design in an Iterative Manner:

Designing in an Iterative manner means that the entire design process from start to end is not
a linear process, In a linear process, the designer starts the design and throughout the entire
process of the design they don’t listen to the user or any others and just delivers the
final product as instructed to him at the start.
 In an iterative approach, the designer creates a certain product (prototype), let the
user test the product and then gathers the feedback from the user
 Using the feedback they make changes in the design and again let the user test it until
and unless the user says that they liked the product and no other change is needed to
do there.
Design Methodologies for Design Process :
There are several Design methodologies that are used in Design Process Some of them are listed
below:

63 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

 User Centric Designs: UCD is an approach whose main goal is to make the user satisfy
with the design and making sure that they don’t face any issues while using the
application. Designers emphaises on the user’s needs, conducting multiple testing,
releasing prototype and gaining feedback, using those feedbacks to update the
application etc.
 Task Analysis: Task Analysis is an approach used by designers to break a large and
complex task into smaller and easier sub-tasks.
 Cognitive Walkthrough: This approach is used by designers in which they try to imitate
how a person would react with the application and their thought process while doing
various tasks in the application. It is helpful to identify that where the user might get
stuck while using the application.
 Contextual Inquiry: It involves interviewing the user live while they are interacting
with the application and performing some tasks, it helps the designers to understand
the workflow of the users.
 Scenario based Design: Designers create some scenarios in their mind to guess how
the users might interact with the application and how they will react in various
situations. This is helpful to understand the user’s thought process and using that the
application can be improved.

5. HUMAN COMPUTER DESIGN INTERFACE STANDARDS:

Human-Computer Interaction (HCI) is a field of study that focuses on the design and
development of interactive systems that are easy and efficient to use.
Human-computer interface (HCI) design standards are essential for creating user-friendly
and efficient interfaces.
some widely recognized guidelines and standards -
Shneiderman’s Eight Golden Rules
Shneiderman’s Eight Golden Rules are a set of eight guidelines for designing user
interfaces that are easy to learn and use. The rules are:
 Strive for consistency: Use consistent terminology, fonts, and design elements
throughout the interface.

64 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

 Cater to universal usability: Design the interface to be accessible to users with a wide
range of abilities.
 Offer informative feedback: Provide users with feedback on their actions so that they
know what is happening.
 Design dialogs to yield closure: Make sure that users know when a dialog box is
complete and what they need to do to proceed.
 Prevent errors: Design the interface to prevent errors from happening in the first
place.
 Permit easy reversal of actions: Allow users to easily undo their mistakes.
 Support internal locus of control: Make users feel like they are in control of the
system.
 Reduce short-term memory load: Minimize the amount of information that users
need to keep in their heads in order to use the system.
Norman’s Seven Principles
Norman’s Seven Principles are a set of seven guidelines for designing user interfaces that are
easy to use. The principles are:
 Usefulness: The interface should be useful for the tasks that users need to complete.
 Usability: The interface should be easy to learn and use.
 Desirability: The interface should be aesthetically pleasing and motivating to use.
 Findability: Users should be able to easily find the information and features that they
need.
 Accessibility: The interface should be accessible to users with a wide range of abilities.
 Credibility: The interface should be trustworthy and credible.
 Value: The interface should provide users with value that is worth the time and effort
it takes to use it

65 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

UNIT – 5

1. Software Quality Assurance:

 Software Quality Assurance (SQA) is simply a way to assure quality in the

software. It is the set of activities that ensure processes, procedures as well as
standards that are suitable for the project and implemented correctly.
 These defined standards could be one or a combination of anything like ISO
9000, Capability Maturity Model Integration (CMMI) model, etc.

 It focuses on improving the process of development of software so that problems

can be prevented before they become major issues.

 Software Quality Assurance is a kind of Umbrella activity that is applied throughout

the software process.
Elements of Software Quality Assurance (SQA):

Standards

Reviews and audits

Testing

ELEMENTS OF Error collection

SOFTWARE and analysis

QUALITY change
management
ASSURANCE
(SQA) Education

Security
management

safety

Risk management

1. Standards: The IEEE, ISO, and other standards organizations have produced a broad
array of software engineering standards and related documents. The job of SQA is to
ensure that standards that have been adopted are followed and implemented in the
Software Development process.
2. Reviews and audits: Technical reviews are a quality control activity performed by
software engineers for software engineers. Audits are a type of review performed by
SQA personnel (people employed in an organization) with the intent of ensuring that
quality guidelines are being followed for software engineering work.
3. Testing: Software testing is a quality control function that has one primary goal—to
find errors. The job of SQA is to ensure that testing is properly planned and efficiently
conducted for primary goal of software.

66 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

4. Error/defect collection and analysis : SQA collects and analyzes error and defect data
to better understand how errors are introduced and what software engineering
activities are best suited to eliminating them.
5. Change management: SQA ensures that adequate change management practices have
been instituted.
6. Education: Every software organization wants to improve its software engineering
practices. A key contributor to improvement is education of software engineers, their
managers, and other stakeholders. The SQA organization takes the lead in software
process improvement which is key proponent and sponsor of educational programs.
7. Security management: SQA ensures that appropriate process and technology are used
to achieve software security.
8. Safety: SQA may be responsible for assessing the impact of software failure and for
initiating those steps required to reduce risk.
9. Risk management: The SQA organization ensures that risk management activities are
properly conducted and that risk-related contingency plans have been established.
Benefits of Software Quality Assurance (SQA):
 SQA produces high quality software.
 Improving the process of creating software, Improves the quality of the software.
 High quality application saves time and cost.
 SQA is beneficial for better reliability.
 High quality commercial software increase market share of company.
 The Software release is completed within the time. It cuts maintenance costs.

2. QUALITY METRICS:
In Software Engineering, Software Measurement is done based on some Software Metrics
where these software metrics are referred to as the measure of various characteristics of a
Software.
In Software engineering Software Quality Assurance (SQA) assures the quality of the software.
A set of activities in SQA is continuously applied throughout the software process.
Software Quality is measured based on some software quality metrics.

The most essential Software quality metrics are –

1. Code Quality
2. Reliability
3. Performance
4. Usability
5. Correctness
6. Maintainability
7. Integrity
8. Security

1. Code Quality – Code quality metrics measure the quality of code used for software
project development. Maintaining the software code quality by writing Bug-free and
semantically correct code is very important for good software project development. In
code quality, both Quantitative metrics like- the number of lines, complexity, functions,

67 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

rate of bugs generation, etc, and Qualitative metrics like -readability, code clarity, efficiency,
and maintainability, etc are measured.
2. Reliability – Reliability metrics express the reliability of software in different conditions.
The software is able to provide exact service at the right time or not checked. Reliability
can be checked using Mean Time Between Failure (MTBF) and Mean Time To Repair
(MTTR).
3. Performance – Performance metrics are used to measure the performance of the
software. Each software has been developed for some specific purposes. Performance
metrics measure the performance of the software by determining whether the software is
fulfilling the user requirements or not, by analyzing how much time and resource it is
utilizing for providing the service.
4. Usability – Usability metrics check whether the program is user-friendly or not. Each
software is used by the end-user. So it is important to measure that the end-user is happy
or not by using this software.
5. Correctness – Correctness is one of the important software quality metrics as this
checks whether the system or software is working correctly without any error by satisfying
the user. Correctness gives the degree of service each function provides as per
developed.
6. Maintainability – Each software product requires maintenance and up-gradation.
Maintenance is an expensive and time-consuming process. So if the software product
provides easy maintainability then we can say software quality is up to mark.
Maintainability metrics include the time required to adapt to new features/functionality,
Mean Time to Change (MTTC), performance in changing environments, etc.
7. Integrity – Software integrity is important in terms of how much it is easy to integrate
with other required software which increases software functionality and what is the
control on integration from unauthorized software’s which increases the chances of
cyberattacks.
8. Security – Security metrics measure how secure the software is. In the age of cyber
terrorism, security is the most essential part of every software. Security assures that there
are no unauthorized changes, no fear of cyber attacks, etc when the software product is in
use by the end-user.

EXAMPLE:

Mean Time Between Failures (MTBF) is a reliability metric used to measure the average time
elapsed between two consecutive failures of a system or component.

is a reliability metric that measures the average expected time between two consecutive
failures of a system or component under normal operating conditions.

It represents the average operating time of a system or component before it fails.

The Mean Time Between Failures (MTBF) is calculated using the following formula:

MTBF = Mean Time to Failure(MTTF) + Mean Time to Repair (MTTR)

68 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

3. Software reliability:
 Software reliability is a important aspect of software engineering. It refers to the
probability that software will function without failure under specified conditions for
a specified period of time.
 Reliability attributes(metrics) are the measure of software reliability.
 Reliability metrics express the reliability of software in different conditions. The
software is able to provide exact service at the right time or not checked.

Some reliability metrics which can be used to quantify the reliability of the software product
are as follows -

1. Mean Time to Failure (MTTF)

MTTF is described as the time interval between the two successive failures.

To measure MTTF, we can evidence the failure data for n failures. Let the failures appear at
the time instants t1,t2 tn.

MTTF can be calculated as

69 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

2. Mean Time to Repair (MTTR)

Once failure occurs, some-time is required to fix the error. MTTR measures the average time
it takes to track the errors causing the failure and to fix them.

3. Mean Time Between Failure (MTBR):

We can merge MTTF & MTTR metrics to get the MTBF metric.

MTBF = MTTF + MTTR

Thus, an MTBF of 300 denoted that once the failure appears, the next failure is expected to
appear only after 300 hours. In this method, the time measurements are real-time & not the
execution time as in MTTF.

4. Rate of occurrence of failure (ROCOF):

It is the number of failures appearing in a unit time interval. The number of unexpected
events over a specific time of operation. ROCOF is the frequency of occurrence with which
unexpected role is likely to appear. A ROCOF of 0.02 mean that two failures are likely to
occur in each 100 operational time unit steps. It is also called the failure intensity metric.

5. Probability of Failure on Demand (POFOD):

POFOD is described as the probability that the system will fail when a service is requested. It
is the number of system deficiency given several systems inputs.

POFOD is the possibility that the system will fail when a service request is made.

A POFOD of 0.1 means that one out of ten service requests may fail. POFOD is an essential
measure for safety-critical systems.

6. Availability (AVAIL):

Availability is the probability that the system is applicable for use at a given time. It takes
into account the repair time & the restart time for the system. An availability of 0.995
means that in every 1000 time units, the system is feasible to be available for 995 of these.
The percentage of time that a system is applicable for use, taking into account planned and
unplanned downtime. If a system is down an average of four hours out of 100 hours of
operation, its AVAIL is 96%.

4. software testing:

70 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Software testing is a critical phase in the software development lifecycle, ensuring that the
software is reliable, functional, and meets the end users' requirements.
“Testing is a set of activities, whose objective is to find out the errors, thatwere made
unknowingly while designing and constructing the software.”

Verification and Validation:

Software testing is one element of a broader topic that is often referred to as
verification and validation (V&V).
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.

In general terms Verification and Validation are defined as -

 Verification : Are we building the product right?

 Validation : Are we building the right product?

A Software testing strategy provides a road map that describes the steps to be
conducted in testing. Therefore, any testing strategy must contain test planning,
test case design, test execution and resultant data collection and evaluation.
A software testing strategy should be flexible enough to promote a customized
testing approach. At the same time, it must be rigid enough to encourage
reasonable planning and management tracking as the project progresses.
Testing is a set of activities that can be planned in advance and conducted
systematically. A number of software testing strategies have been proposed. All
provide the software developer with a template for testing.

The Testing strategies have the following generic characteristics -

 Testing begins at the component level and works "outward" toward the
integration computer-based system.
 Different testing techniques are appropriate at different points in time.
 Testing is conducted by the developer of the software and an
independent testgroup.
 Testing and debugging are different activities , but
debugging mustbe accommodated in any testing strategy.

Organizing for software testing:

For every software project, there is an inherent conflict of interest that
occurs as testing begins. The people who built the software are now asked to test the
software.
The software developer is responsible for testing the individual units of the
program, ensuring that each performs the function or exhibits the behavior for which it
was designed.
In many cases the developer also conducts integration testing. Only after

71 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

the software architecture is completed, an independent test group (ITG) involves in

testing.
The role of Independent Test Group is to remove the inherent problems
associated with letting the builder test the thing that has been built. The developer and
the ITG work closely throughout a software project to ensure that thorough tests will be
conducted. While testing is conducted, the developer must be available to correct errors
that are uncovered.
Types of software testing:
There are various types of software testing, each serving a specific purpose and providing
unique insights into the software's quality and performance.

Functional Testing:
Funtional testing is a testing technique that is used to test the features and
functionalities of the software. There are two types of functional testing techniques -
1. Black Box (or) Behavioural testing.
2. White Box (or) Glass Box (or) Structural testing.

Functional testing

Black-box testing (or) White box testing(or)

Behavioral testing Glass-box (or)
Structural testing

5. White Box (or) Glass Box (or) Structural testing:

“This testing technique mainly focuses on the internal mechanism of the system.”
It derives the following test cases-
 Independent paths with in a module, have been executed at least once.
 Execute all logical decisions on their true and false values.
 Execute all loops at their boundaries..
There are two types of white box testing techniques. They are -
1. Basis path testing technique.
2. Control structures testing technique.

1. Basis path testing method:

Basis Path Testing in software engineering is a White Box Testing method in which test
cases are defined based on flows or logical paths that can be taken through the program.

72 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

The objective of basis path testing is to define the number of independent paths, so the
number of test cases needed can be defined explicitly to maximize test coverage.

Basis path testing is done in two ways -

Flow graph notation or control flow graph(CFG)
Cyclomatic complexity.
Flow graph notation:
The control flow of a program can be represented using a graphical representation known
as a ‘Flow Graph’. It consists of nodes and edges. Using the flow graph, an independent path
can be defined as a path in the flow graph that has at least one edge that has not been
traversed before in other paths.
The flow graph is a directed graph in which nodes are either entire statements or fragments
of a statement. Edges represent the flow of control.
Example:
T he system module flow chart can be converted into flow graph.
Consider the system module flow chart .
An independent path is one that represents a path in the program that traces a new set of
procedural statements or conditions.

Flow graph for the above flow chart is shown below-

73 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

As in the above flow graph, we can observe that the starting or the first node or procedural
statement is node 1 and the termination of the flow graph is node 11. So, all the
independent path that can be traced in the flow graph should start from 1 and end to 11:
• Path 1: 1-11
• Path 2: 1-2-3-4-5-10-1-11
• Path 3: 1-2-3-6-8-9-10-1-11
• Path 4: 1-2-3-6-7-9-10-1-11
Path 1, 2, 3 & 4 are the independent paths as each path introduces a new edge i.e. all the
paths are unique. So, all these paths form a basis set for the above flow graph.

Cyclomatic complexity:

How many independent paths have to be find out is obtained from the cyclomatic
complexity.
It is denoted by V(G).

V (G) = E-N+2

Here, E= number of edges N= number of nodes.

In above graph, V ( G )=11-9+2=13-9=4
Number of independent paths= 4.

In other words , cyclomatic complexity is represented as

V (G)=P+1
Here P=Predicate node, it means a node that contains condition.
In above graph , predicate nodes are: 3
V (G)= 3+1=4
Number of independent paths=4

2. Control structure testing:

Control structure testing is a technique used to enhance test coverage by focusing on

various control structures within a program. Different types of testing performed in control
structure testing are –

1. Condition testing
2. Data flow testing
3. Loop testing

1. Condition Testing:

This method ensures that logical conditions and decision statements are error-free.
Common types of logical conditions tested include:

o Relation expressions (e.g., E1 op E2, where E1 and E2 are arithmetic

expressions and op is an operator).
o Simple conditions with a NOT (~) operator (e.g., ~E1).

74 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

oCompound conditions with Boolean operators and parentheses (e.g., (E1 &
E2) | (E2 & E3)).
o Boolean expressions (e.g., A | B, where A and B are operands).
2. Data Flow Testing:
o This approach selects test paths based on variable definitions and uses
throughout the program.
o Each statement is assigned a unique number, and variables are tracked using
DEF (definition) and USE sets.
o Data flow testing ensures coverage of definition-use (DU) chains, but it may
not cover all branches.
3. Loop Testing:
o Focuses on testing loops (e.g., for, while) to ensure they execute correctly.
o Test cases target loop boundaries, exit conditions, and iteration counts.

Simple loop nested loop concatenated loop

6. Black box testing:

Black box testing is based on an analysis of the specification of a piece of

software without reference to its internal workings. The term black box
indicates that the internal implementation of the program being executed is
not examined by the tester. For this reason black box testing is not normally
carried out by the programmer. In most real-world engineering firms, one
group does design work while a separate group does the testing.
Black Box testing also known as Functional Testing focuses on the

75 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

functional requirements of the software. It allows the tester to derive a set

of input conditions that will fully exercise all functional requirements of a
program. The structure of a program (i.e., code) is not considered for the
design of test cases. Instead the test cases for the entire system are
designed from the requirements specification document for the system.
Black Box Testing attempts to find errors in the following categories:
1. Incorrect or missing functions

2. Interface errors

3. Errors in data structures or external data base access

4. Performance errors

5. Initialization and termination errors

By applying black box testing techniques, we derive a set of test

cases that satisfy the following criteria:
 Test cases that reduce, by a count that is greater than one,
the number of additional test cases that must be designed to
achieve reasonable testing, and
 Test cases that tell us something about the presence or
absence of classes of errors, rather than errors associated only
with the specific test at hand.
The various Black Box Testing techniques are as follows:
1. Graph Based Testing
2. Equivalence Partitioning
3. Boundary Value Analysis
4. Orthogonal array Testing.

1. Graph Based Testing :

Graph-based testing is a technique used in black box testing to represent the relationships
between inputs (causes) and outputs (effects) using graphs. This method helps in identifying
and creating test cases that cover various combinations of input conditions and their
corresponding outputs.

One common approach within graph-based testing is Cause-Effect Graphing. Graph based
technique works as follows -

1. Identify Causes and Effects: Determine the distinct input conditions (causes) and the
resulting output conditions (effects).
2. Create the Graph: Use Boolean expressions to link causes and effects, forming a
cause-effect graph.

76 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

3. Add Constraints: Apply constraints to represent impossible combinations of causes

or effects.
4. Convert to Decision Table: Transform the cause-effect graph into a decision table.
5. Derive Test Cases: Each column in the decision table represents a test case.

2. Equivalence portioning testing method:

This testing method divides the input domain of a program into classes of datafrom which test
case can be derived. For example -

 If an input requires a specific value then three equivalence partitions are

defined,if (i==10) then the three classes are( i<10, i==10,i>10).
 If an input condition requires a range then the three equivalence
partitions are defined, suppose marks[0,100] then Minimum, within a
range, maximum.

3. Boundary value analysis testing method:

In this testing method, that compliments the equivalence partitioning and it leads to the
selection of test cases at the edges of the class.
In an input specify the range [a , b] then the test cases are min-1,min ,min+1,normal
values,max-1,max,max+1.
Ex: i={5,10,12,20}, then the test cases are { 4,5,6,10,12,19,20,21}.

4. Orthogonal array testing method:

Orthogonal Array Testing (OAT) is software testing technique that uses orthogonal arrays to
create test cases.

It is statistical testing approach especially useful when system to be tested has huge data
inputs.

Orthogonal array testing helps to maximize test coverage by pairing and combining the
inputs and testing the system with comparatively less number of test cases for time saving.

Example:
If we have 3 parameters, each can have 3 values then the possible Number of tests using
conventional method is 3^3 = 27
While the same using OAT, it selects only 9 test cases, for time saving.

7. Integration testing :

Integration testing is a crucial phase in software engineering where individual software

modules are combined and tested as a group to identify any issues in their interactions.
The goal of integration testing is to identify any problems or bugs that arise when
different components are combined and interact with each other.
Integration testing is typically performed after unit testing and before system testing. It helps
to identify and resolve integration issues early in the development cycle.

77 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Integration testing can be done by picking module by module. This can be done so that
there should be a proper sequence to be followed.

Integration testing is important because it verifies that individual software modules or

components work together correctly as a whole system.

Integration test approaches:

There are four types of integration testing approaches -

1. Big-Bang Integration Testing :

 It is the simplest integration testing approach, where all the modules are combined
and the functionality is verified after the completion of individual module testing.
 In simple words, all the modules of the system are simply put together and tested.
 This approach is practicable only for very small systems. If an error is found during the
integration testing, it is very difficult to restrict the error as the error may potentially
belong to any of the modules being integrated. So, debugging errors reported during
Big Bang integration testing is very expensive to correct.
2. Bottom-Up Integration Testing :
 In bottom-up testing, each module at lower levels are tested with higher modules
until all modules are tested.
 The primary purpose of this integration testing is that each subsystem tests the
interfaces among various modules making up the subsystem.
 This integration testing uses test drivers to drive and pass appropriate data to the
lower-level modules.
3. Top-Down Integration Testing :
 Top-down integration testing technique is used in order to simulate the behaviour
of the lower-level modules that are not yet integrated.
 In this integration testing, testing takes place from top to bottom.

78 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

 First, high-level modules are tested and then low-level modules and finally
integrating the low-level modules to a high level to ensure the system is working as
intended.

4. Mixed Integration Testing:

 A mixed integration testing is also called sandwiched integration testing. A mixed
integration testing follows a combination of top down and bottom-up testing
approaches.
 In top-down approach, testing can start only after the top-level module has been
coded and unit tested. In bottom-up approach, testing can start only after the
bottom level modules are ready.
 This sandwich or mixed approach overcomes this shortcoming of the top-down and
bottom-up approaches.
 It is also called the hybrid integration testing. also, stubs and drivers are used in
mixed integration testing.

8. Validation testing:

Validation can be defined in many ways, but a simple (albeit harsh)

definition is that validation succeeds when software function in a manner that
can be reasonably expected by the customer.

Validation Test Criteria:

Software validation is achieved through a series of black-box tests
that demonstrate conformity with requirements. A test plan outlines the classes of
tests to be conducted and a test procedure defines specific test cases that will be
used to demonstrate conformity with requirements.

Both the plan and procedure are designed to ensure that all

79 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

functional requirements are satisfied, all behavioral characteristics are achieved, all
performance requirements are attained, documentation is correct , and human-
engineered and other requirements are met.

After each validation test case has been conducted, one of two possible conditions
exists:
 The function or performance characteristics conform to specification and are
accepted or
 a deviation from specification is identified and a deficiency list is created.

Deviation or error discovered at this stage in a project can rarely be corrected prior
to scheduled delivery. It is often necessary to negotiate with the customer to
establish a method for resolving deficiencies.

Configuration Review
An important element of the validation process is a configuration
review. The intent of the review is to ensure that all elements of the software
configuration have been properly developed, are catalogued, and have the
necessary detail to strengthen the support phase of the software life cycle. The
configuration review, sometimes called an audit.

Alpha and Beta Testing

Validation testing in software engineering ensures that a product meets the requirements
and expectations of its users. Two types of validation testing are - alpha testing and beta
testing.

Alpha Testing
 Performed by Internal employees, often the development team or Quality Assurance
testers.
 Conducted in a controlled setting, such as a lab or development environment.
 Identify and fix bugs, defects, and usability issues before releasing the product to
external users.

Beta Testing
 Performed by Real users outside the organization, such as potential customers or
public beta testers.
 Conducted in real-world settings to simulate actual user interactions.
 Gather feedback from real users to identify any remaining issues and improve the
product before its official release.

9. System testing:
System testing is a series of different tests, whose purpose is to verify the system
elements have been properly integrated and performing allocating the functions. In
this testing first the software components are individually tested and finally they are
integrated and tested.

80 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

SOFTWARE TESTING HIERARCHY

As with almost any software engineering process, software testing has a prescribed order in
which things should be done. These are the steps taken to fully test new software -

 Unit testing performed on each module or block of code during development. Unit
Testing is normally done by the programmer who writes the code.
 Integration testing done before, during and after integration of a new module into
the main software package. This involves testing of each individual code module.
One piece of software can contain several modules which are often created by
several different programmers. It is crucial to test each module’s effect on the entire
program model.
 System testing done by a professional testing agent on the completed software
product before it is introduced to the market.
 Acceptance testing – beta testing of the product done by the actual end users.

The following types of system tests are performed. They are -

1. Recovery testing
2. Security testing
3. Stress testing.
4. Performance testing.

 Recovery testing:
This testing focuses, the software to fail in a variety of ways and verifies the
recovery is properly performed or not. If recovery is automatic, re-initialization
and restart are evaluated for correctness.

 Security testing:
This testing mainly focuses, the protection mechanism and it protects the
system from improper functions.
Security testing checks the system for invulnerability from frontal attacks
as well as rear attacks. This testing always protects the sensitive information
from hackers, employees or an individual attempt to enter the system for
information.

81 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

 Stress testing:
This testing checks the system performance in abnormal situation. For
example software is smoothly running, when an average hundred transactions
are done. Suddenly the transaction rises up to thousands or lakhs. In those
situations, some period of time the system may Hault that is called stress
point. The stress testing is to check the stress point is accepted or not.

 Performance testing:
This testing is designed to test the runtime performance of the system and
also thistesting test the both the hardware and software instrumentation.
For example, an application is tested to use proper resources that are
processingspeed, response time, memory usage etc.

10. Reverse Engineering:

1. Software Reverse Engineering is a process of recovering the design, requirement

specifications, and functions of a product from an analysis of its code.
2. Reverse engineering is a process of design recovery.
3. Reverse engineering tools extract data, architectural, and procedural
design information from an existing program.
4. The core of reverse engineering is an activity called extract abstractions.
5. We must evaluate the old program and from the source code, develop a meaningful
specification of the processing that is performed, the user interface that is applied,
and the program data structures or database that is used.

82 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

The following diagram illustrates the process of reverse engineering -

Reverse Engineering to Understand Data:

Reverse engineering of data occurs at different levels of abstraction and is often the first
reengineering task.
Internal data structures: Reverse engineering techniques for internal program data focus
on the definition of classes of objects. 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 structure: Regardless of its logical organization and physical structure, 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.

Reverse Engineering to Understand Processing:

Reverse engineering 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.

Reverse Engineering User Interfaces:

The redevelopment of user interfaces has become one of the most common
types of reengineering activity. But before a user interface can be rebuilt,
reverse engineering should occur.
To fully understand an existing user interface, the structure and behavior of the interface
must be specified.
Three basic questions that must be answered as reverse engineering of the User
Interfaces begins -
 What are the basic actions (e.g., keystrokes and mouse clicks) that the interface
mustprocess?
 What is a compact description of the behavioral response of the system to
theseactions?

83 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

 What is meant by a “replacement,” or more precisely, what concept of

equivalence ofinterfaces is relevant here?

11. Software Re-engineering:

Software Re-engineering is a process of software development that is done to improve the

maintainability of a software system. Re-engineering is the examination and alteration of a
system to reconstitute it in a new form. This process encompasses a combination of sub-
processes like reverse engineering, forward engineering, reconstructing, etc.

1. This can include updating the software to work with new hardware or software
platforms, adding new features, or improving the software’s overall design and
architecture.
2. Software re-engineering, also known as software restructuring or software renovation,
refers to the process of improving or upgrading existing software systems to improve
their quality, maintainability, or functionality.

Steps involved in Re-engineering are -

1. Inventory Analysis
2. Document Reconstruction
3. Reverse Engineering
4. Code Reconstruction
5. Data Reconstruction
6. Forward Engineering

Inventory Analysis:

 List all software components, including source code, libraries and documentation.
 Group components based on functionality, dependencies, and relevance.

84 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

 Assess the quality, performance, and maintainability of each component.

 Rank components for re-engineering based on their importance and complexity.

Document Reconstruction:

 Collect all available documents, such as design documents, user manuals, and code
comments.
 Review and update outdated or missing information.
 Develop new documents to fill any gaps, including technical specifications and user guides.
 Cross-reference documentation with the actual software and review with stakeholders.
 Establish a plan to keep documentation upto date.

Then Reverse engineering , code reconstruction , data reconstruction, forward engineering are
done to complete software reengineering.

12. CASE TOOLS:

CASE stands for Computer Aided Software Engineering. It means, development and
maintenance of software projects with help of various automated software tools.

CASE tools are set of software application programs, which are used to automate Software
Development Life Cycle(SDLC) activities. CASE tools are used by software project managers,
analysts and engineers to develop software system.

There are number of CASE tools available to simplify various stages of Software Development
Life Cycle such as Analysis tools, Design tools, Project management tools, Database
Management tools, Documentation tools are to name a few.

Use of CASE tools speed up the development of project to produce desired result and helps to
reveal errors before moving ahead with next stage in software development.

13. PROJECT MANAGEMENT TOOLS:

Project management tools in Computer-Aided Software Engineering (CASE) are essential for

85 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

effectively managing software development projects. These tools help streamline various
aspects of project management, ensuring that projects are completed on time, within
budget, and to the required quality standards.

project management tools in CASE are -

Scheduling Tools:
Scheduling tools are used to Create and manage project timelines, milestones, and
deadlines.
Examples: Gantt charts, PERT (Program Evaluation Review Technique) charts.
Resource Management Tools:
Resource management tools are used to Allocate and track the use of resources such as
personnel, equipment, and materials.
Examples: Resource Guru, Hub Planner.
Cost and Effort Estimation Tools:
Cost and effort estimation tools are used to Estimate the resources, time, and budget
required for the project.
Examples: COCOMO (Constructive Cost Model)
Collaboration Tools:
Collaboration tools are used to facilitate communication and collaboration among team
members.
Examples: Microsoft Teams, Trello.
Documentation Tools:
Documentation tools are used to Manage project documentation, including requirements,
design documents, and user manuals.
Examples: Confluence, SharePoint.
Risk Management Tools:
Risk management tools are used to Identify, assess, and mitigate project risks.
Examples: RiskWatch, Active Risk Manager.
Quality Management Tools:
Quality management tools are used to Ensure that the project meets quality standards and
requirements.
Examples: JIRA.

14. ANALYSIS AND DESIGN TOOLS:

Computer-Aided Software Engineering (CASE) tools are essential for supporting various
stages of the software development lifecycle (SDLC).
CASE tools used for analysis and design are -
Analysis Tools
Requirement Analysis Tools: These help in gathering and analyzing requirements, ensuring
they are complete and consistent.
Examples:
Accept 360
Accompa
CaseComplete
Structure Analysis Tools: These tools focus on analyzing the structure of the system,
identifying inconsistencies, and ensuring data integrity.

86 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Examples :
Visible Analyst
Design Tools
Diagramming Tools: These assist in creating graphical representations of the system, such
as flowcharts, data flow diagrams(DFD), and entity-relationship diagrams(ERD).
Examples:
Flow Chart Maker
Software Design Tools: These tools help in designing the architecture and components of
the software. They often include features for modeling and simulation.
Examples :
Rational Rose
Enterprise Architect
PROGRAMMING TOOLS:
CASE (Computer-Aided Software Engineering) tools for programming are designed to assist
in the coding phase of software development. These tools can significantly enhance
productivity and ensure code quality.
CASE programming tools -
Integrated Development Environments (IDEs): These provide a comprehensive
environment for coding, debugging, and testing.
Examples:
Eclipse
Visual Studio
Code Generators: These tools automatically generate code based on design specifications,
reducing manual coding effort.
Examples :
Doxygen
DrExplain
Simulation Tools: These help in simulating the execution of code to identify potential issues
before actual deployment.
Examples:
MATLAB Simulink
Simul8
In-Built Module Libraries: These provide pre-written code modules that can be reused in
different parts of the application, saving time and effort.
Examples :
Boost C++ Libraries
Apache Commons
Advantages of CASE Programming Tools:
1. Increased Productivity: Automating repetitive tasks allows developers to focus on
more complex aspects of coding.
2. Improved Code Quality: Automated tools help in maintaining consistency and
reducing human errors.
3. Enhanced Collaboration: Many CASE tools support version control and collaborative
features, making it easier for teams to work together.

15. INTEGRATION TESTING TOOLS:

87 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Integration testing tools are software applications designed to facilitate testing

interactions and communication between software components.

These tools come with user-friendly features that align with best practices in integration
testing. Hence, using such tools, we can accelerate the integration testing process
without worrying about maintenance or reporting.

There are different types of integration testing tools, each aligning with one or more of
the subsequent integration testing approaches:

 Top-down: This method initiates testing with the highest-level modules or components
and progressively integrates lower-level ones.
 Bottom-up: In contrast to top-down, this approach starts testing with the lowest-level
modules or components and gradually integrates higher-level modules.
 Mixed or sandwich: Also termed as hybrid integration testing, this approach combines
elements of both top-down and bottom-up methods to ensure thorough integration
testing.

Benefits of Integration Testing Tools:

Integration testing tools provide numerous advantages that can notably enhance the
efficiency and effectiveness of integration testing. Here are three primary benefits:

 Automation: The automation capabilities of these tools enable the execution of tests
without the need for manual intervention, resulting in time and effort savings.
 Defect Identification: Integration testing tools contribute to the early identification and
detection of bugs associated with component interactions, helping to address issues
proactively.
 Scalability: Intеgration tеsting tasks tеnd to grow quickly as еach nеw componеnt is
added to thе softwarе, bringing in morе intеraction points and potеntial combinations
with еxisting componеnts. A good intеgration tеsting tool should be flеxiblе and scalablе
to handlе this growth еffеctivеly.
 Customization: Somе customization options еnablе еxpеriеncеd tеstеrs to write tеst
scripts for vеry spеcific issuеs. This way, thеy can automatе common scеnarios whilе also
creating tеst casеs to fit uniquе and unplannеd rеquirеmеnts.
 Collaboration and Reporting: By offering a centralized platform for test case
management, execution, and result sharing, integration testing tools foster enhanced
collaboration among development and testing teams. This streamlines communication
and reporting processes
some popular integration testing tools used in software engineering are -
1. Selenium:
Purpose: Web application testing.
Features: Supports multiple browsers and platforms, extensive language support.
2. pytest:

88 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Purpose: Python automation testing.

Features: Simple syntax, powerful fixtures, and plugins.
3. SoapUI:
Purpose: Web service testing.
Features: Functional testing, load testing, and security testing for APIs.
4. Jasmine:
Purpose: JavaScript testing framework.
Features: Behavior-driven development, easy syntax.

16. CASE STUDIES:

Case Study: ABC Organization - Leading Pharmaceutical Company
Context: ABC Organization, a leading pharmaceutical company, faced challenges in their software
development process, particularly in ensuring the quality and reliability of their applications.
Solution: They implemented Selenium for automation testing to streamline their testing
process.
Implementation:
Test Automation: Selenium was used to automate the testing of web applications, reducing the
need for repetitive manual testing.
Integration: Selenium was integrated with other tools like Jenkins for continuous integration and
continuous delivery (CI/CD), ensuring that tests were run automatically with every code
change.
Cross-Browser Testing: Selenium’s ability to support multiple browsers and platforms allowed
the team to ensure their applications worked seamlessly across different environments.
Outcome:
Increased Efficiency: Automation significantly reduced the time required for testing,
allowing the team to focus on more critical tasks.
Improved Quality: Automated tests helped in identifying defects early in the development
cycle, leading to higher quality software.
Cost Savings: The reduction in manual testing efforts translated to cost savings for the
organization.
This case study demonstrates how Selenium can be effectively used to enhance the
software development process, ensuring better quality and efficiency

Selenium is one of the top integration testing tools that is open-source, allowing developers
and testers to automate integration test suites in web applications on a large scale. Its
capabilities extend beyond integration testing, offering the flexibility to test various web
scenarios.

we can perform actions such as button clicks, form completions, page navigation, and more,
which can be scripted and automated with Selenium. When we use Selenium as an

89 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

integration testing tool, it allows to verify the correct functioning of web applications
across different browsers, devices, and platforms.

The following are the key features of Selenium:

 Supports multiple web browsers (Chrome, Firefox, Edge, Safari, etc.).

 Runs seamlessly on different platforms, such as Windows, macOS, and Linux.
 Develops test scripts in languages like Java, Python, C#, or JavaScript.
 Allows the capture of screenshots and videos during test execution, aiding
debugging and improving reporting capabilities.
 Facilitates the execution of parallel tests with different hybrid test data.

Case Study: University Course Registration System

Objective: To design and implement a course registration system for a fictional university
using Rational Rose and UML.
Requirement Analysis:
Use Case Diagrams: Identify the main actors (students, professors, administrators) and their
interactions with the system.
Example: A use case diagram showing students registering for courses, professors managing
course details, and administrators overseeing the process.

System Design:
Class Diagrams: Define the system’s structure by identifying classes, attributes, and
relationships.
Example: Classes such as Student, Course, Professor, and Registration with their respective
attributes and methods.
Behavior Modeling:
Sequence Diagrams: Detail the interactions between objects over time for specific use cases.
Example: A sequence diagram showing the process of a student registering for a course,
including interactions with the Course and Registration classes.
Implementation:
Code Generation: Use Rational Rose to generate code from the UML diagrams for languages
like Java or C++.
Example: Automatically generate skeleton code for the Student and Course classes.
Testing and Validation:
Reverse Engineering: Create UML diagrams from existing code to ensure it aligns with the
design.
Example: Validate that the implemented Registration class matches the original design
specifications.
Rational Rose:
Rational Rose is a sophisticated CASE (Computer-Aided Software Engineering) tool widely
used for visual modeling and designing software systems. It supports the Unified Modeling
Language (UML) and provides a comprehensive environment for creating, analyzing, and
documenting software models.
Key Features of rational rose -

90 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER

 RAO’S DEGREE COLLEGE

Diagramming:
UML Support: Create various UML diagrams such as use case diagrams, class diagrams,
sequence diagrams, and state diagrams.
Visual Modeling: Helps in visualizing the architecture and design of the system.
Code Generation:
Automatic Code Generation: Generates code from UML diagrams for multiple programming
languages like Java, C++, and Visual Basic.
Reverse Engineering: Converts existing code into UML diagrams, aiding in understanding
and documenting legacy systems.
Collaboration:
Team Support: Facilitates collaboration among team members by providing a shared
environment for model development.
Documentation: Allows adding detailed documentation to each element in the model,
improving clarity and communication.

91 | SOFTWARE ENGINEERING BCA II YEAR – III SEMESTER