PART A
1. List four design principles of a good design:
• The software must be modular (logically partitioned).
• Each design component must be functionally independent.
• Design must follow a repeatable method.
• Interface should reduce complexity of connections between components.
2. How do you apply modularization criteria for a monolithic software?
You break the software into logically nameable and addressable components (modules). These
modules must follow principles such as abstraction, functional independence, and information
hiding. Each module should perform a specific task and have limited interaction with others to
improve maintainability and reduce complexity.
3. What is the design quality attribute ‘FURPS’ meant?
FURPS stands for:
• Functionality: Features and capabilities.
• Usability: Human factors, aesthetics, consistency.
• Reliability: Frequency of failure, MTTF, accuracy.
• Performance: Speed, throughput, efficiency.
• Supportability: Extensibility, adaptability, serviceability, testability.
4. What are the different types of Cohesion?
Types of cohesion (from least to most desirable):
• Coincidental
• Logical
• Temporal
• Procedural
• Communicational
• Sequential
• Functional (most desirable)
Each type refers to how closely the operations within a module are related to one another.
5. Define software testing. What are the objectives of testing?
Definition: Software testing is the process of identifying the correctness of software by evaluating all
its attributes to find bugs or defects.
Objectives:
• Ensure software correctness
• Identify bugs or errors
• Verify reliability, usability, and performance.
6. Why does software fail after it has passed from acceptance testing?
Software may fail due to:
• Environmental differences (e.g., hardware, OS)
• Real-world usage not fully replicated during testing
• Latent bugs not discovered earlier
• Misunderstood or evolving user requirements
These issues cause the software to behave unexpectedly post-deployment.
7. What are the conditions that exist after performing validation testing?
After validation testing:
• The system should fulfil all user requirements.
• It should be ready for acceptance testing.
• Any defects or failures found must be corrected before final release.
8. Define error, fault, and failure:
• Error: A human mistake in coding or logic.
• Fault (Bug): The manifestation of an error in the software.
• Failure: The deviation of software behaviour from expected results when a fault is executed.
9. Differentiate between size-oriented and function-oriented metrics:
Size-Oriented Metrics Function-Oriented Metrics
Based on lines of code (LOC) Based on functionality delivered
Measures physical size Measures functionality and complexity
Easy to calculate Better for early project estimation
E.g., LOC, number of modules E.g., Function Points, DFD complexity
10. An organic software occupies 15,000 LOC. How many programmers are needed to complete it?
KLOC = LOC/1000 = 15000/1000 = 15
Effort (E) = Ab (KLOC)Bb = 2.4 (15) 1.05 = 41.219 person-months
Time deviation (TD) = Cb (E) Db = 2.5 (41.219) 0.38 = 10.272 months
Number of people (P) = E / TD = 41.219 / 10.272 = 4 people
PART B
11. What is software architecture? Describe in detail different types
of software architectural styles with illustrations.
Software Engineering | Architectural Design
Introduction: The software needs the architectural design to represents the design of software. IEEE
defines architectural design as “the process of defining a collection of hardware and software
components and their interfaces to establish the framework for the development of a
computer system.” The software that is built for computer-based systems can exhibit one of these
many architectural styles.
Each style will describe a system category that consists of :A set of components(eg: a database,
computational modules) that will perform a function required by the system.
The set of connectors will help in coordination, communication, and cooperation between the
components.
Conditions that how components can be integrated to form the system.
Semantic models that help the designer to understand the overall properties of the system. The
use of architectural styles is to establish a structure for all the components of the system. Taxonomy
of Architectural styles:
1. Data centred architectures:
A data store will reside at the center of this architecture and is accessed frequently by the other
components that update, add, delete or modify the data present within the store.
The figure illustrates a typical data centered style. The client software access a central repository.
Variation of this approach are used to transform the repository into a blackboard when data related
to client or data of interest for the client change the notifications to client software.
This data-centered architecture will promote integrability. This means that the existing components
can be changed and new client components can be added to the architecture without the permission
or concern of other clients.
Data can be passed among clients using blackboard mechanism.
2. Data flow architectures:
This kind of architecture is used when input data to be transformed into output data through a
series of computational manipulative components.
The figure represents pipe-and-filter architecture since it uses both pipe and filter and it has a set
of components called filters connected by pipes.
Pipes are used to transmit data from one component to the next.
Each filter will work independently and is designed to take data input of a certain form and
produces data output to the next filter of a specified form. The filters don’t require any knowledge of
the working of neighboring filters.
If the data flow degenerates into a single line of transforms, then it is termed as batch sequential.
This structure accepts the batch of data and then applies a series of sequential components to
transform it.
3. Call and Return architectures: It is used to create a program that is easy to scale and modify. Many
sub-styles exist within this category. Two of them are explained below.
Remote procedure call architecture: This components is used to present in a main program or sub
program architecture distributed among multiple computers on a network.
Main program or Subprogram architectures: The main program structure decomposes into number
of subprograms or function into a control hierarchy. Main program contains number
4. Object Oriented architecture: The components of a system encapsulate data and the operations
that must be applied to manipulate the data. The coordination and communication between the
components are established via the message passing.
5. Layered architecture:
A number of different layers are defined with each layer performing a well-defined set of
operations. Each layer will do some operations that becomes closer to machine instruction set
progressively.
At the outer layer, components will receive the user interface operations and at the inner layers,
components will perform the operating system interfacing(communication and coordination with OS)
Intermediate layers to utility services and application software functions
12. Discuss the process of translating the analysis model into a
software design. List the golden rules of user interface design
1. Translating the Analysis Model into Software Design:
Translating an analysis model into a software design is a critical step in the software development life
cycle. It bridges the gap between understanding the problem (analysis) and developing a solution
(design). The process involves:
a) Understanding Requirements Clearly:
The analysis model includes use case diagrams, class diagrams, sequence diagrams, and data flow
diagrams (DFDs).
Each element of the analysis model is carefully examined to determine the structure and behavior
required in the final system.
b) Creating the Architectural Design:
This involves defining the high-level structure of the system.
It includes the selection of architectural patterns (e.g., MVC, layered architecture).
Components, their interactions, and data flow are decided at this stage.
c) Developing Component-Level Design:
Each class or module identified in the analysis model is converted into a software component.
Detailed design includes attributes, methods, and interaction among classes.
d) Interface Design:
Based on use cases and user requirements, interface design specifies how the system will interact
with users or other systems.
Wireframes or mockups may be created.
e) Data Design:
From the analysis data model (like ER diagrams or DFDs), relational database schemas or data
structures are derived.
This ensures efficient storage, retrieval, and manipulation of data.
f) Behavioral Design:
Sequence and activity diagrams are used to define object interactions and the logic behind
functionalities.
Algorithms and workflows are finalized here.
g) Validation and Iteration:
Design is reviewed and validated against the analysis model to ensure consistency.
Iterative refinement is done based on feedback or technical constraints.
13. What is unit testing? Why is it important? Explain the unit test
consideration and test procedure.
A software development-approach known as unit testing involves checking the functionality of the
smallest testable components or units, of an application one by one. Unit tests are carried out by
software developers and sometimes by QA personnel. A unit is a single testable part of a software
system and tested during the development phase of the application software. Unit testing's primary
goal is to separate written code for testing to see whether it functions as intended.
Unit tests should be run often by teams, whether manually or more frequently automatically.
Automated methods often create test cases using a testing framework. In addition to presenting a
summary of the test cases, these frameworks are also configured to flag and report any failed test
cases.
Unit Test Lifecycle:
The life cycle of a unit test is to plan, implement, review and maintain
1. Review the code written:. According to the unit test life cycle, you first outline the requirements
of your code and then attempt to create a test case for each of them. You review the code written.
2. Check in code from repository : The reviewed unit is put into the repository for further testing
3. Check out code from repository : Select the Unit for which the testing has to be done
4. Make suitable changes: When the time comes, make suitable changes to the unit, after analyzing
each function or method . This will give the tester insight into what is going on in that piece of code.
Here is an example:
Parameters being passed in
Code doing its job
Code returning something
5. Execute the test and compare the expected and actual results: This phase of the Unit testing life
cycle involves developing a test by creating a test object, selecting input values to execute the test,
executing the test, and comparing the expected and actual results
6. Fix the detected bugs in the code: It also gives developers peace of mind when adding or
modifying code because they know if they break something, they will be notified immediately during
testing. This way, you can fix problems before they ever reach production and cause issues for end
users
Re-execute the tests to verify them: Unit testing is a great way for developers to keep track of their
changes, which can be especially important when it comes to life cycle methods that may not have a
visual representation. Re-executing the tests to verify them after each change can help ensure
everything is still working as expected.
Unit testing advantages:
There are many advantages to unit testing, including the following:
Compound mistakes happen less often the sooner an issue is discovered.
Fixing issues as they arise is often less expensive than waiting until they become serious
Simplified debugging procedures.
The codebase can be modified easily by developers,
Code may be transferred to new projects and reused by developers.
Unit testing disadvantages:
While unit testing is integral to any software development and testing strategy; there are some
aspects to be aware of. Disadvantages to unit testing include the following:
Not all bugs will be found during tests.
Unit testing does not identify integration flaws; it just checks data sets and their functionality.
To test one line of code, more lines of test code may need to be developed, which might require
additional time.
To successfully apply unit testing, developers may need to pick up new skills, such as how to utilize
certain automated software tools.
14. What is black box testing? Explain the different types of black
box testing strategies with examples.
Testing a system in a "black box" is doing so without knowing anything about how it operates within.
ie It is a form of testing that is performed with no knowledge of a system's internals. A tester inputs
data and monitors the output produced by the system being tested. This allows for the identification
of the system's reaction time, usability difficulties and reliability concerns as well as how the system
reacts to anticipated and unexpected user activities.)
Because it tests a system from beginning to finish, black box testing is a powerful testing method. A
tester may imitate user action to check if the system fulfills its promises. A black box test assesses
every important subsystem along the route, including the UI/UX, database, dependencies and
integrated systems, as well as the web server or application server.
1.2.2.1 Black Box Testing Pros and Cons
Advantages:
1. Testers do not require technical knowledge, programming of IT skills.
2. Testers do not need to learn implementation details of the system
3. Tests can be executed by outsourced testers.
4. Low chance of false positives.
5. Tests have lower complexity, since they simply model common user behavior
Dis-Advantages:
1. Difficult to automate.
2. Requires prioritization, typically infeasible to tests all user paths.
3. Difficult to calculate test coverage.
4. If a test fails, it can be difficult to understand the root cause of the issues.
5. Tests may be conducted at low scale or on a non-production like environment
1.2.2.2 Types of Black Box Testing
Black box testing can be applied to three main types of tests: Functional, non- functional and
regression testing.
1. Functional Testing:
Specific aspects or operations of the program that is being tested may be tested via black box testing.
For instance, make sure that the right user credentials may be used to log in and that the incorrect
ones cannot.
Functional testing concentrate on the most important features of the program on how well the
system works as a whole (system testing) with the integration of its essential components.
2. Non-functional Testing:
Beyond features and functioning, black box testing allows for the inspection of extra software
components. A non-functional test examines "how" rather than "if" the program can carry out a
certain task.
Black box testing may determine whether software is:
a) Usable and simple for its users to comprehend;
b) Performance under predicted or peak loads; Compatible with relevant devices, screen sizes,
browsers or operating systems;
c) Exposed to security flaws or frequent security threats.
3. Regression Testing:
To determine if a new software version displays a regression or a decrease in capabilities, from one
version to the next, black box testing may be employed. Regression testing may be used to evaluate
both functional and non-functional features of the program, such as when a particular feature no
longer functions as anticipated in the new version or when a formerly fast-performing action
becomes much slower in the new version.
1.2.2.3 Black Box Testing Techniques
1. Equivalence partitioning:
Testing professionals may organize potential inputs into "partitions" and test just one sample input
from each category. For instance, it is sufficient for testers to verify one birth date in the "under 18"
group and one date in the "over 18" group if a system asks for a user's birth date and returns the
same answer for users under the age of 18 and a different response for users over 18.
2. Boundary value analysis:
Testers can determine if a system responds differently around a certain boundary value. For instance,
a particular field could only support values in the range of 0 and 99. Testing personnel may
concentrate on the boundary values (1, 0, 99 and 100) to determine if the system is appropriately
accepting and rejecting inputs.
3. Decision Table Testing
Numerous systems provide results depending on a set of parameters. Once rules that are
combinations of criteria have been identified, each rule's conclusion can then be determined and
test cases may then be created for each rule.
15. Describe the steps involved in the project scheduling process,
project timeline chart, and task network.
Project schedule simply means a mechanism that is used to communicate and know about that tasks
are needed and has to be done or performed and which organizational resources will be given or
allocated to these tasks and in what time duration or time frame work is needed to be performed.
Effective project scheduling leads to success of project, reduced cost, and increased customer
satisfaction. Scheduling in project management means to list out activities, deliverables, and
milestones within a project that are delivered. It contains more notes than your average weekly
planner notes. The most common and important form of project schedule is Gantt chart.
Steps Involved in the Project Scheduling Process:
1. Define Activities: List all tasks or work items required to complete the project.
2. Sequence Activities: Determine the order of tasks based on dependencies (what needs to be done
before what).
3. Estimate Resources and Duration: Assign resources (people, tools, materials) and estimate time for
each task.
4. Develop Schedule: Use the above data to create a timeline, often using Gantt charts or CPM/PERT
techniques.
5. Optimize Schedule: Adjust for resource conflicts, parallel tasks, or critical path changes.
6. Baseline the Schedule: Finalize and document the schedule as a reference.
7. Monitor and Control: Track progress, update the schedule, and manage changes.
Project Timeline Chart (Gantt Chart):
A Gantt chart is a bar chart that represents the project timeline visually.
Features:
Horizontal axis: Time (days/weeks/months).
Vertical axis: Tasks or activities.
Bars: Show start date, duration, and end date of each task.
Dependencies: May be shown with arrows connecting tasks.
Uses:
Visualizes the schedule.
Tracks task progress.
Identifies overlapping or sequential tasks.
Task Network (Network Diagram):
A Task Network (also known as Activity Network Diagram) shows the logical relationship among
tasks.
Components:
Nodes: Represent activities/tasks.
Arrows: Show dependencies (precedence relationships).
Types:
PERT (Program Evaluation Review Technique): Includes uncertainty using optimistic, pessimistic, and
expected durations.
CPM (Critical Path Method): Focuses on the longest path through the network—critical path—which
determines the shortest project duration.
Purpose:
Identify task sequences and dependencies.
Determine critical and non-critical tasks.
Optimize scheduling and resource allocation.
16. (a) Suppose you have a budgeted cost of a project as Rs.
9,00,000. The project is to be completed in 9 months. After a
month, you have completed 10% of the project at a total expense of
Rs. 1,00,000. The planned completion should have been 15%.
Determine whether the project is on time and budget using Earned
Value Analysis. Interpret the result.
Consider the following function point components and their
complexity. If the total degree of influence is 52, find the estimated
function points:
• FED – 2 (Complexity: 7)
• GHD – 4 (Complexity: 10)
• HJI – 22 (Complexity: 4)
• BU – 16 (Complexity: 5)
• BJ – 24 (Complexity: 4)
