Software engineering 2023 Previous Year Solved | GGSIPU

Q.1 (A) What are the characteristics of software

• Intangibility: Software is not a physical entity; it cannot be touched or seen, but it can be experienced through its functionality and performance.
• Complexity: Software systems can be highly complex,
• consisting of numerous interrelated components and modules that interact with each other in intricate ways.
• Scalability: Well-designed software should be scalable, capable of
• handling increased workload and accommodating growth in terms of users, data, or functionality.
• Maintainability: Software should be designed and developed in a way that facilitates easy maintenance, including bug fixes, updates, and enhancements.
• Flexibility: Software should be adaptable to changing requirements,
• allowing for modifications and extensions without requiring extensive rework or causing disruptions to existing functionality.

(B) What is software re-engineering?

• Software re-engineering is the process of modifying and restructuring existing
• software systems to improve their performance, maintainability, scalability, and overall quality. It involves the following steps:
• Reverse Engineering: Analyzing the existing software system to understand its structure, design, and functionality.
• Restructuring: Modifying the software's structure and architecture to improve its organization, modularity, and maintainability.
• Code Transformation: Optimizing and refactoring the codebase to enhance its efficiency, readability, and adherence to coding best practices.
• Documentation: Updating or creating comprehensive documentation to facilitate understanding and future maintenance of the re-engineered software.
• Testing: Thorough testing of the re-engineered software to ensure its functionality, performance, and compatibility with existing systems.
• Deployment: Deploying the re-engineered software into the production environment and monitoring its performance and stability.

(C) Write short notes on DFD and ER diagrams.

• DFDs are graphical representations of how data flows through a system.
• They consist of four main elements: processes, data stores, external entities, and data flows.
• DFDs help in understanding the system's functionality, identifying data inputs and outputs, and visualizing the flow of information.
• They are commonly used in structured systems analysis and design to model the logical flow of data within a system.

• ER diagrams are used to model the data structure and relationships in a database system.
• Entities represent real-world objects or concepts, while attributes describe the properties or characteristics of entities.
• Relationships depict the associations or connections between entities.
• ER diagrams help in conceptual database design, providing a clear representation of the data model and its constraints.

(D) What is software review and software inspection?

• Software Review: A software review is a systematic examination of a software product or its associated documents to assess its quality, identify defects, etc.
• It involves a team of reviewers evaluating the software artifacts and providing feedback for improvement.
• Objectives: The main objectives of a software review are to find and remove defects early in the development process,
• improve the overall quality of the software, and ensure that it meets the specified requirements and standards.
• Types: There are different types of software reviews, including code reviews, design reviews, requirements reviews,
• and test plan reviews, each focusing on specific aspects of the software development process.
• Software Inspection: Software inspection is a formal, structured process of examining software artifacts to detect and remove defects.
• It follows a well-defined procedure and involves a team of inspectors with clearly defined roles and responsibilities.
• Inspection Process: The inspection process typically includes planning, overview, individual preparation,
• inspection meeting, rework, and follow-up stages. Each stage has specific activities and deliverables.

(E) What is the difference between validation and verification?

• Validation is the process of evaluating a software system or component to
• determine whether it satisfies the specified requirements and meets the user's actual needs.
• Validation activities may include requirement reviews, user acceptance testing, beta testing, and stakeholder feedback analysis.
• The goal of validation is to ensure that the software being developed aligns with the user's expectations and business objectives.
• Example: A banking application undergoes user acceptance testing where real
• users interact with the system to ensure that it meets their banking needs, such as account management, money transfers, and bill payments.

• Verification is the process of evaluating a software system or component to
• determine whether it meets the specified design specifications and requirements.
• Verification activities may include code reviews, unit testing, integration testing, and static code analysis.
• The goal of verification is to identify and fix defects, errors, and inconsistencies in the software implementation.
• Example: During the development of a mobile application, unit tests are written to verify that individual functions and modules are working correctly, etc.

UNIT 1

Q.2 (A) What do you mean by requirements elicitation? Discuss in brief different requirement elicitation techniques.

• Requirements elicitation, also known as requirements gathering, is the process of identifying, capturing, and documenting the needs, expectations,
• and constraints of stakeholders for a software system or product. It involves actively collaborating with stakeholders,
• including users, customers, domain experts, and other relevant parties

Interviews

• Conducted one-on-one or in small groups with stakeholders.
• Allows for in-depth exploration of requirements and understanding of user perspectives.
• Provides an opportunity for clarification and follow-up questions.
• Suitable for gathering detailed and specific requirements.

Questionnaires and Surveys

• Consists of predefined questions or prompts to elicit responses.
• Useful for gathering general information, preferences, and opinions.
• Provides quantitative data that can be analyzed and summarized.

Focus Groups

• Involves bringing together a group of stakeholders to discuss and explore requirements.
• Facilitates open discussions, brainstorming, and idea generation.
• Allows for different perspectives and viewpoints to be shared and debated.
• Helps in identifying common themes, concerns, and priorities.

Observation

• Involves observing users or stakeholders in their natural work environment.
• Helps in understanding how users interact with existing systems or perform tasks.
• Provides insights into user behavior, workflows, and challenges.
• Useful for identifying usability issues and gathering contextual requirements.

Document Analysis

• Involves reviewing and analyzing existing documents, such as business processes, user manuals, and system specifications.
• Helps in understanding the current state of the system or domain.
• Provides background information and context for requirements elicitation.
• Useful for identifying gaps, inconsistencies, and areas for improvement.

Q.3 (A) Draw and label well described Use Case Diagram and Level 1 DFD for hotel management system. Make assumptions as required.

Q.3 (B) What is SRS? Describe the nature and characteristics of SRS. Why is it important?

• A Software Requirements Specification (SRS) is a comprehensive document that outlines the detailed requirements for a software system or product.
• It serves as a formal agreement between the development team
• and the stakeholders, defining what the software should do, how it should behave, and what constraints it should adhere to.

• The SRS should be written in clear, concise, and unambiguous language.
• Requirements should be stated precisely, avoiding vague or subjective terms.
• Each requirement should be easily understandable by all stakeholders.

• The SRS should cover all the necessary requirements for the software system.
• It should include functional requirements, non-functional requirements, constraints, and assumptions.
• No essential requirements should be missing or left unspecified.

• The requirements in the SRS should be consistent with each other.
• There should be no contradictions or conflicts between requirements
• Consistency ensures that the system can be developed and implemented without ambiguity.

• Each requirement in the SRS should be uniquely identifiable and traceable.
• Traceability allows for tracking the implementation and testing of each requirement.
• It helps in managing changes and ensuring that all requirements are addressed.

• The requirements in the SRS should be verifiable and testable.
• It should be possible to determine whether a requirement has been met through testing or other verification methods.
• Verifiable requirements enable effective quality assurance and acceptance testing.

• The SRS clearly defines the boundaries and scope of the software project.
• It helps in preventing scope creep and ensures that all stakeholders have a shared understanding of what the system will and will not do.

• The SRS serves as a communication bridge between stakeholders, including clients, users, developers, and testers.
• It provides a common language and reference point for discussions and decision-making.

UNIT 2

Q.4 (A) Explain Halstead Software Science metrics?

1. Program Length (N)

• This metric represents the total number of tokens (operators and operands) in the program. It is denoted by NN.
• The tokens can include operators (e.g., arithmetic operators, logical operators) and operands (e.g., variables, constants).

2. Program Vocabulary (n)

3. Program Length (N1)

4. Program Length (N2)

• This metric represents the total number of distinct operands in the program. It is denoted by N2N2​.
• From these basic metrics, Halstead defined the following derived metrics

5. Volume (V)

• The volume is a measure of the size of the program and is calculated using the formula:
• V=N∗log⁡2(n)V=N∗log2​(n)
• It reflects the total information content of the program.

6. Difficulty (D)

• Difficulty is a measure of how hard it is to understand the program logic. It is calculated using the formula:
• D=N12∗N2n2D=2N1​∗n2​N2​

7. Effort (E)

• Effort represents the amount of mental effort required to understand and develop the software. It is calculated using the formula:
• E=D∗VE=D∗V

8. Time (T)

• Time represents the estimated time required to develop the software. It is calculated using the formula:
• T=E18T=18E​
• Here, 18 is a constant derived from empirical studies.

9. Number of Delivered Bugs (B)

• It estimates the number of bugs present in the software after development and is calculated using the formula:
• B=V3000B=3000V​
• Here, 3000 is a constant derived from empirical studies.

Q.4 (B) Compute the function point value for a project with the following domain

1Number of user inputs	=	32
2
3Number of user outputs	=	60
4
5Number of user inquires	=	24
6
7Number of files	=	08
8
9Number of external interfaces	=	2
10
11Assign Complexity Weights:
12
13Number of user inputs (UFP): 32 * 4 = 128
14
15Number of user outputs (UFP): 60 * 5 = 300
16
17Number of user inquiries (UFP): 24 * 4 = 96
18
19Number of files (UFP): 8 * 10 = 80
20
21Number of external interfaces (UFP): 2 * 7 = 14
22
23Calculate Unadjusted Function Points (UFP):UFP = 128 + 300 + 96 + 80 + 14 = 618

• Adjust the Unadjusted Function Points:Adjustments are made based on factors such as complexity, performance, and other project-specific attributes.
• For simplicity, let's assume no adjustment is needed in this case.Adjusted Unadjusted Function Points (AFP) = UFP = 618

Q.5 (A) For a program with the number of unique operator’s n1=40 and number of unique operands n2=60, n1=16 and n2=21 compare the followings:

1Let's calculate these metrics for both sets of values:
2For n1 = 40, n2 = 60:
31.Program Volume: V=(40+60)×log⁡2(40+60)=100×log⁡2(100)≈337.55V=(40+60)×log2​(40+60)=100×log2​(100)≈337.55
42.Potential Volume: V∗=(2×60)×log⁡2(2×60)=120×log⁡2(120)≈400.87V∗=(2×60)×log2​(2×60)=120×log2​(120)≈400.87
53.Program Level: L=260×40100=415≈0.267L=602​×10040​=154​≈0.267
64.Program Difficulty: D=402×10060=33.33D=240​×60100​=33.33
75.Effort: E=33.33×337.55≈11251.32E=33.33×337.55≈11251.32
86.Time: T=11251.3218≈625.07T=1811251.32​≈625.07

1For n1 = 16, n2 = 21:
21.Program Volume: V=(16+21)×log⁡2(16+21)=37×log⁡2(37)≈126.23V=(16+21)×log2​(16+21)=37×log2​(37)≈126.23
32.Potential Volume: V∗=(2×21)×log⁡2(2×21)=42×log⁡2(42)≈140.19V∗=(2×21)×log2​(2×21)=42×log2​(42)≈140.19
43.Program Level: L=221×16100=8105≈0.076L=212​×10016​=1058​≈0.076
54.Program Difficulty: D=162×10021≈38.10D=216​×21100​≈38.10
65.Effort: E=38.10×126.23≈4809.29E=38.10×126.23≈4809.29
76.Time: T=4809.2918≈267.18T=184809.29​≈267.18

• The COCOMO (Constructive Cost Model) is a well-known software cost estimation model developed by Barry Boehm.
• It helps in estimating the effort, time, and cost required to develop a software project. COCOMO has evolved over time, resulting in different models to suit various project types and complexities. Here are the main models:

1. Basic COCOMO (Composite Cost Model)

• Basic COCOMO is the simplest version and is primarily used for early project estimates when only limited information about the project is available.
• It estimates effort as a function of program size and a set of cost drivers.
• It provides an estimation equation of the form: Effort=a×(KLOC)bEffort=a×(KLOC)b, where KLOC is the estimated size of the software in thousands of lines of code, and 'a' and 'b' are constants derived from historical data.
• Basic COCOMO does not consider detailed factors such as personnel experience, project complexity, or development environment.

2. Intermediate COCOMO

• Intermediate COCOMO extends Basic COCOMO by incorporating additional cost drivers to account for project-specific attributes.
• It introduces 15 cost drivers categorized into product, platform, personnel, and project attributes.
• Intermediate COCOMO provides a more accurate estimation by considering factors like development flexibility, required reliability, complexity, etc.

3. Detailed COCOMO

• Detailed COCOMO is the most comprehensive version of the model, providing a highly detailed estimation process.
• It considers a broader set of cost drivers (about 60) compared to Intermediate COCOMO.
• Detailed COCOMO provides separate scales for each cost driver, allowing for a for a more fine-grained estimation based on specific project characteristics.
• This model requires extensive data collection and analysis, making it suitable for large and complex projects where accuracy is crucial.

UNIT 3

Q.6 (A) Explain different types of coupling

• In software engineering, coupling describes the level of interdependence between modules or components within a system.
• There are several types of coupling, each indicating a different level of dependency between modules. Here are some common types of coupling:

1. Content Coupling

• This is considered the strongest form of coupling and is often indicative of poor design
• because it tightly couples modules together, making them highly dependent on each other's implementation details.

2. Common Coupling

• Common coupling exists when multiple modules share the same global data.
• Changes to the shared data can impact multiple modules, leading to unintended side effects and potentially making the system more difficult to understand and maintain.

3. Control Coupling

• Control coupling occurs when one module passes control information (e.g., flags or status variables) to another module.
• This type of coupling can lead to dependencies between modules based on the control flow of the program, making the system harder to understand and debug.

4. Stamp Coupling

• Stamp coupling happens when modules share a composite data structure and only use a subset of the structure's elements.
• This can lead to unnecessary dependencies between modules and may result in inefficient or unclear code.

5. Data Coupling

• Data coupling is the most desirable type of coupling. It occurs when modules communicate by passing data through parameters or return values.
• In this type of coupling, modules are independent of each other's internal implementation and only interact through well-defined interfaces, making the system more modular, flexible, and easier to maintain.

6. Message Coupling

• Message coupling happens when modules communicate by sending messages to each other, typically through message passing mechanisms like message queues or event handlers.
• This type of coupling is similar to data coupling but emphasizes communication through messages rather than direct data exchange.

Q.6 (B) Explain software quality assurance and its activities.

• Software Quality Assurance (SQA) is a systematic process that ensures that software products and processes conform to specified requirements,

• standards, and procedures throughout the software development life cycle.

• The primary goal of SQA is to improve the quality of software products and increase customer satisfaction by preventing defects and identifying areas for improvement early in the development process.
• SQA involves a range of activities aimed at verifying and validating software products and processes.

Quality Planning

• Quality planning involves establishing the quality objectives, processes, and standards that will be used throughout the software development life cycle.
• It includes defining quality metrics, setting quality goals, and developing plans to achieve those goals.

2. Quality Assurance Process Adherence

• SQA ensures that the defined processes and standards are followed consistently throughout the software development life cycle.
• This involves monitoring and auditing development activities to verify compliance with established processes and standards.

3. Reviews and Audits

• Reviews and audits are conducted to assess the quality of software products and processes.
• Reviews involve examining software artifacts (e.g., requirements documents, etc) to identify defects and inconsistencies.
• Audits involve evaluating adherence to defined processes and standards,
• both internally within the organization and externally with respect to industry standards and regulations.

4. Testing

• Testing is a crucial aspect of SQA and involves executing software to uncover defects and verify that it meets specified requirements.
• SQA encompasses various types of testing, including unit testing, integration testing, system testing, and acceptance testing.

5. Configuration Management

• Configuration management involves managing changes to software products and ensuring the integrity and consistency.
• SQA activities in configuration management include version control, change management, and configuration identification.

6. Defect Tracking and Management

• SQA involves tracking defects identified during testing and other quality assurance activities and managing them through resolution.
• Defect tracking includes recording, prioritizing, assigning, and tracking the status of defects to ensure timely resolution and closure.

7. Process Improvement

• SQA aims to continually improve software development processes to enhance product quality and efficiency.
• This involves analyzing quality metrics, identifying areas for improvement, and implementing process enhancements.

Q.7 (A) Explain different types of Cohesion.

• In software engineering, cohesion refers to the degree to which the elements within a module or component are related to each other.
• Cohesion measures how closely the responsibilities of a module or component are related to each other.
• There are several types of cohesion, each representing a different level of relationship among the elements within a module. Here are the main types of cohesion:

1. Coincidental Cohesion

• Coincidental cohesion occurs when elements within a module are grouped together arbitrarily with no meaningful relationship among them.
• This is the weakest form of cohesion and typically indicates poor design, as the module's responsibilities are not well-defined or cohesive.

2. Logical Cohesion

• Logical cohesion occurs when elements within a module are grouped together because they perform similar operations or share a common logical function.
• Although the elements are related conceptually, there may still be unrelated or loosely related responsibilities within the module.

3. Temporal Cohesion

• Temporal cohesion occurs when elements within a module are grouped together because they are related by the timing of their execution.
• For example, a module might contain functions that are only executed during initialization or cleanup tasks, but these functions may have different purposes or responsibilities.

4. Procedural Cohesion

• Procedural cohesion occurs when elements within a module are grouped together because they are related by a sequence of steps in a specific procedure or algorithm.
• This type of cohesion is common in modules that perform a series of related operations or tasks in a specific order.

5. Communicational Cohesion

• Communicational cohesion occurs when elements within a module are grouped together because they operate on the same input data or share the same output data.
• This type of cohesion is often seen in modules that perform multiple operations on the same data structure or dataset.

6. Sequential Cohesion

• Sequential cohesion occurs when elements within a module are grouped together because they are related by a sequential flow of control.
• This type of cohesion is similar to procedural cohesion but focuses specifically on the order of execution rather than the procedural steps themselves.

7. Functional Cohesion

• Functional cohesion is the most desirable type of cohesion.
• It occurs when elements within a module are grouped together because they contribute to a single, well-defined function or responsibility.
• Modules with functional cohesion have clear, focused responsibilities, making them easier to understand, maintain, and reuse.

Q.7 (B) What do you understand by Configuration Management?

• Configuration Management (CM) is a discipline within software engineering that focuses on managing changes to software products,
• systems, and related documents throughout the software development life cycle.

Version Control

• Version control, also known as revision control or source control, is a fundamental component of configuration management.
• It involves tracking and managing changes to source code, documentation, and other artifacts over time.
• Version control systems (e.g., Git, Subversion) enable developers to collaborate effectively, manage different versions of files, and track the history of changes.

Change Management

• Change management involves controlling and managing changes to software and related artifacts in a systematic manner.
• It includes processes for requesting, evaluating, approving, and implementing changes to software products and systems.

Configuration Identification

• Configuration identification involves uniquely identifying and defining the configuration items (CIs) that make up a software product or system.
• CIs may include source code files, executable binaries, documentation, libraries, configuration files, and other related artifacts.

Configuration Control

• Configuration control is the process of controlling changes to configuration items and ensuring that only authorized changes are implemented.
• It involves establishing change control boards (CCBs) or similar decision-making bodies to review and approve proposed changes.
• Configuration control helps maintain the stability and reliability of software products by ensuring that changes are properly evaluated and managed.

Configuration Status Accounting

• Configuration status accounting involves recording and reporting the status and history of configuration items and changes throughout their lifecycle.
• It provides visibility into the current state of software configurations,
• including information such as version numbers, release dates, and change histories.

Configuration Auditing

• Configuration auditing involves reviewing and validating software configurations
• and associated documentation to ensure compliance with established standards, policies, and procedures.

UNIT 4

Q.8 (A) What is software maintenance? Describe different categories of software maintenance.

• Software maintenance refers to the process of modifying, updating, enhancing,
• and managing software after it has been delivered to the customer.
• It encompasses all activities aimed at ensuring that software continues to meet the needs of its users,
• remains compatible with evolving environments, and remains reliable and efficient over time.

Corrective Maintenance

• Corrective maintenance involves fixing defects, errors, or problems identified in the software after it has been deployed.
• It includes activities such as debugging, troubleshooting, and patching to address issues reported by users or discovered during testing.
• The goal of corrective maintenance is to restore the software to its intended functionality and reliability.

Adaptive Maintenance

• Adaptive maintenance involves modifying software to accommodate changes in the environment,
• such as changes to hardware, operating systems, or third-party software components.
• It includes activities such as updating software to support new hardware platforms,
• migrating to new operating system versions, or integrating with updated libraries or APIs.

Perfective Maintenance

• Perfective maintenance involves enhancing or improving the software to add new features, functionalities, or performance optimizations.
• It includes activities such as adding new modules,
• enhancing existing features, optimizing algorithms, or improving usability based on user feedback.

Preventive Maintenance

• Preventive maintenance involves proactively identifying and addressing potential issues or risks in the software to prevent future problems.
• It includes activities such as refactoring code to improve maintainability,
• enhancing documentation, conducting code reviews, or implementing additional error checking and validation.

Q.8 (B) Explain Functional Testing with example.

• Functional testing is basically defined as a type of testing that verifies that
• each function of the software application works in conformance with the requirement and specification.
• This testing focuses on checking the user interface, APIs, database, security, client or server application,
• and functionality of the Application Under Test. Functional testing can be manual or automated.

Functional Test Cases

Verify Product Search Functionality

• Test Case: Search for a specific product using the search bar.
• Expected Result: The search results page should display relevant products matching the search query.
• Example: Search for "iPhone 12" should display iPhone 12 models in the search results.

Verify Add to Cart Functionality

• Test Case: Add a product to the shopping cart.
• Expected Result: The product should be added to the cart, and the cart icon should display the correct count of items.
• Example: Clicking the "Add to Cart" button for a product should add it to the cart, and the cart icon should update to show the total number of items.

Q.9 (A) Explain maintenance tools and its techniques.

• Maintenance tools and techniques refer to the various tools and methods
• used by software maintenance teams to manage and perform maintenance activities effectively.
• These tools and techniques help streamline the maintenance process, track changes, etc. Here are some common maintenance tools and techniques:

Version Control Systems (VCS)

• Version control systems, such as Git, Subversion (SVN) are essential tools for managing changes to source code and other project files.
• VCS allows developers to track changes, collaborate on code, and revert to previous versions if needed.

Issue Tracking Systems

• Issue tracking systems, such as JIRA, Bugzilla, and Trello, are used to manage and track defects,
• enhancements, and other tasks throughout the software maintenance life cycle.
• These systems allow teams to report issues, assign tasks, prioritize work, and track the status of ongoing maintenance activities.

Automated Testing Tools

• Automated testing tools, such as Selenium, JUnit, and Postman, help
• automate the execution of tests to validate the functionality, performance, and reliability of software systems.
• Automated tests can be used for regression testing, integration testing,
• unit testing, and other types of testing to ensure that changes do not introduce new defects or regressions.

Code Analysis Tools

• Code analysis tools, such as SonarQube, FindBugs, and PMD, analyze source code to identify potential defects,
• security vulnerabilities, coding standards violations, and performance issues.
• These tools help maintain code quality, identify areas for improvement, and ensure compliance with coding standards and best practices.

Code Review Tools

• Code review tools, such as GitHub Pull Requests, Bitbucket Code Review, and Crucible,
• facilitate code reviews by providing a platform for reviewing, commenting, and discussing code changes.
• Code reviews help maintain code quality, share knowledge among team members
• and ensure that changes are aligned with coding standards and design principles.

Q.9 (B) Explain Structural Testing using example.

• Structural testing, also known as white-box testing or glass-box testing, is a
• software testing technique that focuses on testing the internal structure of the software application.
• It involves examining the code structure, control flow, and data flow to ensure that all paths and conditions are tested thoroughly.
• Structural testing aims to uncover defects in the implementation of the
• software, such as logic errors, boundary cases, and missing or incorrect code.
• Example: Calculator Application
• Scenario: Let's consider a simple calculator application that performs basic arithmetic operations such as addition, subtraction, multiplication, and division.

Structural Testing Techniques

Statement Coverage

• Statement coverage involves testing each statement in the code at least once.
• Example: In the calculator application, we can create test cases to ensure
• that every line of code in the addition, subtraction, multiplication, and division functions is executed.

Branch Coverage

• Branch coverage involves testing all possible branches or decision points in the code.
• Example: In the calculator application, we can create test cases to cover different scenarios,
• such as positive and negative numbers, zero values, and edge cases, for each arithmetic operation.

Example Test Cases

Addition Function

• Test Case 1: Test addition of two positive integers (e.g., 5 + 3).
• Test Case 2: Test addition of two negative integers (e.g., -5 + (-3)).
• Test Case 3: Test addition of a positive integer and zero (e.g., 5 + 0).
• Test Case 4: Test addition of a positive integer and a negative integer (e.g., 5 + (-3)).
• Test Case 5: Test addition of two large integers to check for overflow.

Subtraction Function

• Test Case 1: Test subtraction of two positive integers (e.g., 5 - 3).
• Test Case 2: Test subtraction of two negative integers (e.g., -5 - (-3)).
• Test Case 3: Test subtraction of a positive integer and zero (e.g., 5 - 0).
• Test Case 4: Test subtraction of a positive integer and a negative integer (e.g., 5 - (-3)).
• Test Case 5: Test subtraction of two large integers to check for overflow.