Unit 1

1. **Difference between Program and Software:**

- A program is a set of instructions written in a programming language to perform a specific task on

a computer. It's a single executable file or a collection of files that can be executed.

- Software refers to a collection of programs, data, and instructions that enable a computer system
to perform specific tasks. It encompasses everything from operating systems and applications to
games and utilities.

2. **Failure Curve of Hardware and Software:**

- The failure curve of hardware typically follows a "bathtub" shape, characterized by high initial
failure rates (early-life failures), followed by a period of relatively low failure rates (useful life), and
ending with an increasing failure rate as the hardware ages (wear-out failures).

- The failure curve of software is different. Software failures often occur due to design flaws or bugs
rather than wear and tear. Software failure rates tend to be more constant over time, with occasional
spikes due to newly introduced bugs or changes in the operating environment.

3. **Nature of Software:**

- Software is intangible and doesn't wear out with use like hardware.

- It can be easily modified and updated.

- Software is complex, often involving numerous interactions and dependencies.

4. **Changes in Software:**

- Changes in software can include bug fixes, feature enhancements, performance improvements,
and security updates.

- Software changes are often iterative and incremental, with new versions released regularly.

5. **Common Software Myths:**

- "Once it's built, it's done": Software requires ongoing maintenance and updates.

- "More features mean better software": Quality is more important than quantity.

- "Software development is quick and easy": Developing high-quality software takes time and
effort.

6. **Myths in Software Engineering:**

 - "Adding more people to a late project makes it faster": Often leads to communication overhead
and decreased productivity.

- "Testing can ensure bug-free software": Testing can uncover bugs, but it's impossible to guarantee
their absence.

- "Good developers don't need documentation": Documentation is crucial for understanding and
maintaining software.

7. **Software Engineering with Layered Technology:**

- Software engineering can be conceptualized with a layered approach, consisting of:

1. **Process Layer**: Defines the methodologies, frameworks, and processes used in software
development.

2. **Methods Layer**: Specifies the techniques and tools used to analyze, design, implement,
test, and maintain software.

3. **Tools Layer**: Encompasses the actual software tools used in the development process, such
as compilers, debuggers, and version control systems.

1. Software engineering with layered technology:

 Software engineering involves applying engineering principles to the
development of software systems.
 Layered technology refers to organizing software development into
distinct layers, such as requirements, design, implementation, testing,
and maintenance.

8. **Capability Maturity Model Integrated (CMMI) Framework:**

- CMMI is a framework used to improve the processes involved in developing and maintaining
software.

- It provides a structured approach for organizations to assess and improve their software
development processes.

9. **Importance of CMMI Model:**

- Helps organizations identify strengths and weaknesses in their processes.

- Provides a roadmap for continuous process improvement.

- Enhances the quality and reliability of software products.

10. **Process Pattern:**

 - A process pattern is a reusable solution to a recurring problem in software development.

- Example: The "Iterative Development" pattern involves breaking down the development process
into small, manageable iterations, allowing for continuous feedback and improvement.

11. **Types of Process Patterns:**

- Incremental Development

- Test-Driven Development

- Agile Development

- Waterfall Development

12. **Process Assessment:**

- Process assessment involves evaluating the effectiveness and maturity of an organization's

software development processes.

- It helps identify areas for improvement and benchmarks against industry standards.

13. **Approach to Software Process Assessment:**

- Define assessment goals and objectives.

- Select appropriate assessment models and criteria.

- Collect and analyze data on existing processes.

- Identify strengths and weaknesses.

- Develop improvement recommendations.

14. **Differentiating Personal and Team Process Models:**

- Personal process models focus on individual developers' activities and practices.

- Team process models consider the interactions and collaboration among team members in
executing software development tasks.

15. **Stages in Personal Software Process (PSP):**

- Planning

- High-Level Design

- Detailed Design

- Coding
 - Compile & Test

- Postmortem

are the three layers of software engineering?

https://medium.com/agileactors/software-engineering-a-layered-approach-3caa573febad

2 marks

1. **Evolving Role of Software:**

- The role of software is continuously evolving due to advancements in technology and changing
user needs.

- Software is transitioning from being a tool for automation to becoming integral to various aspects
of life, including communication, entertainment, healthcare, and transportation.

2. **Dual Nature of Software:**

- Software has a dual nature in that it consists of both tangible and intangible aspects.

- Tangible aspects include the code, data, and documentation, while intangible aspects encompass
its functionality, usability, and user experience.

3. **Managing Changes in Software:**

- Changes in software can be managed through version control systems, rigorous testing
procedures, and agile development methodologies.

- Continuous integration and deployment practices also help in managing changes efficiently.

4. **System Software:**

- System software is a type of software designed to provide a platform for other software to run on.

- It includes operating systems, device drivers, and utilities necessary for managing hardware
resources and providing essential services to applications.

5. **Software Myth Explanation:**

- A software myth is a commonly held belief about software development that is untrue or
misleading.
 - These myths often arise from misconceptions about the nature of software development and its
complexities.

6. **Three Software Myths:**

- "The best software is developed quickly": Quality software requires thorough planning, design,
and testing.

- "More developers equals faster development": Adding more developers can lead to
communication overhead and decreased productivity.

- "Testing can ensure bug-free software": Testing is essential but cannot guarantee the absence of
all bugs.

7. **Five Generic Software Engineering Framework Activities:**

- Communication

- Planning

- Modeling

- Construction

- Deployment

8. **Layers in Software Layered Technology:**

- Software layered technology typically consists of three layers:

1. Process Layer

2. Methods Layer

3. Tools Layer

9. **Five Maturity Levels within CMMI Model:**

- Initial

- Managed

- Defined

- Quantitatively Managed

- Optimizing

10. **Four Main Elements in Capability Maturity Model:**

 - Process Areas

- Goals

- Practices

- Maturity Levels

11. **PSP and TSP in Software Engineering:**

- PSP (Personal Software Process) is a structured methodology for individual software developers
to improve their personal development processes.

- TSP (Team Software Process) extends PSP principles to teams, emphasizing collaboration and
coordination among team members.

12. **Process Pattern Provides:**

- Process patterns provide reusable solutions to common problems encountered during software
development.

- They offer guidance on how to structure and execute various development activities.

13. **Four Main Steps in the Assessment Process:**

- Planning and Preparation

- Data Collection

- Analysis and Evaluation

- Reporting and Action Planning

14. **Main Focus Areas of Process Assessment:**

- Process Capability

- Process Maturity

- Process Improvement Opportunities

15. **Three Steps in PSP:**

- Planning

- Time Recording

- Quality Management
16. **Framework Activities Used During PSP:**

- Planning

- High-Level Design

- Detailed Design

- Coding

- Compile & Test

- Postmortem

unit 4

1. **Test Case:**

- A test case is a set of conditions or actions performed on a software application to determine its
functionality and ensure that it behaves as expected.

- Example: For a login feature of a website, a test case could be:

- Test Case Name: Verify Successful Login

- Test Steps:

1. Open the website login page.

2. Enter valid username and password.

3. Click on the login button.

4. Verify that the user is redirected to the dashboard page.

2. **Positive vs. Negative Test Case:**

- Positive Test Case: Validates that the system behaves correctly when provided with valid input.

- Example: In the login scenario, a positive test case would verify successful login with correct
credentials.

- Negative Test Case: Tests the system's ability to handle invalid input or unexpected behavior.

- Example: A negative test case would verify that the system displays an error message when
provided with incorrect login credentials.

3. **Validation Testing Techniques:**

- Validation testing techniques ensure that the software meets the user's requirements and
expectations.
 - Techniques include:

- Acceptance Testing

- System Testing

- User Acceptance Testing (UAT)

4. **Levels Required for Validation Testing:**

- Generally, validation testing is performed at two levels:

1. System Level: Ensures the entire system meets user requirements.

2. Acceptance Level: Validates that the system meets user acceptance criteria.

5. **Four Types of Systems Tests:**

- Functional Testing

- Performance Testing

- Security Testing

- Compatibility Testing

6. **Test Methods Used in System Testing:**

- Black Box Testing

- White Box Testing

- Regression Testing

- User Acceptance Testing

7. **Smoke Testing:**

- Smoke testing is a preliminary testing phase to check whether the most crucial functionalities of
the software work without major issues.

- Example: After installing a software application, a smoke test would ensure that the application
launches successfully and essential features like login and navigation work as expected.

8. **Challenges in White Box Testing:**

- Requires knowledge of the internal structure and implementation of the software.

- Testing all possible code paths can be time-consuming and complex.

- Changes in code may necessitate frequent updates to test cases.

9. **Common Black Box Testing Techniques:**

- Equivalence Partitioning

- Boundary Value Analysis

- Decision Table Testing

- State Transition Testing

10. **Advantages of Black Box Testing:**

- Tests from the user's perspective.

- Doesn't require knowledge of internal code.

- Can uncover errors that may not be apparent from examining the code.

11. **Importance of Software Product Metrics:**

- Helps quantify the quality and performance of software products.

- Provides insights for decision-making during development and maintenance.

- Facilitates comparison with industry standards and benchmarks.

12. **Five Components of Function Point:**

- External Inputs

- External Outputs

- External Inquiries

- Internal Logical Files

- External Interface Files

13. **Challenges in Software Quality:**

- Changing requirements and scope.

- Tight project deadlines.

- Budget constraints.

- Maintaining consistency across different platforms and devices.

14. **Techniques for Improving Software Quality:**

 - Test-Driven Development (TDD)

- Continuous Integration and Continuous Deployment (CI/CD)

- Code Reviews

- Automated Testing

15. **Four Types of Software Metrics:**

- Product Metrics

- Process Metrics

- Project Metrics

- Quality Metrics

16. **Limitations of Software Metrics:**

- Metrics may not accurately represent the true quality or performance of the software.

- Overemphasis on metrics may lead to gaming the system or focusing on metrics at the expense of
other important aspects.

- Some aspects of software development may be difficult to quantify or measure accurately.

2 marks

1. **Three Types of Testing:**

- Unit Testing

- Integration Testing

- System Testing

2. **Why Testing is Required:**

- Testing is required to identify defects or bugs in software.

- It ensures that the software meets the specified requirements.

- Testing helps in delivering a reliable and high-quality product to end-users.

3. **Why Validation Testing is Needed:**

- Validation testing ensures that the software meets the user's requirements and expectations.
 - It verifies that the software performs its intended functions correctly within the context of the
user's environment.

4. **Goal of Validation Testing:**

- The goal of validation testing is to confirm that the software satisfies the user's needs and
requirements and is fit for its intended purpose.

5. **Performers of System Testing:**

- System testing is typically performed by dedicated testing teams or quality assurance engineers.

6. **System Testing Timing:**

- System testing can be conducted at various stages of the software development lifecycle, such as
after integration testing or before deployment.

7. **White Box Testing Performers:**

- White box testing is typically performed by software developers who have access to the source
code of the software.

8. **Dynamic Nature of White Box Testing:**

- Yes, white box testing is dynamic as it involves executing code and analyzing the internal logic and
structure of the software during runtime.

9. **Difference between Alpha and Beta Testing:**

- Alpha Testing: Conducted by the development team internally before releasing the software to
external users.

- Beta Testing: Involves testing the software by real end-users in a real environment before the
official release.

10. **Other Name for Black Box Testing:**

- Functional Testing

11. **Measuring Quality of a Product:**

- Quality of a product can be measured using various metrics such as defect density, reliability,
usability, performance, and customer satisfaction.
12. **Transactional Functional Types in Function Point Calculation:**

- External Inputs

- External Outputs

- External Inquiries

13. **Elements of Software Quality:**

- Reliability

- Efficiency

- Maintainability

- Usability

- Portability

14. **Zero Defect Software:**

- Achieving zero-defect software is extremely challenging and often impractical due to the
complexity of software systems and the limitations of human capabilities.

15. **Need for Metrics in Projects:**

- Metrics provide objective measurements to track progress, identify issues, and make data-driven
decisions.

- They help in estimating project effort, identifying areas for improvement, and managing risks.

16. **Goal of Software Metrics:**

- The goal of software metrics is to provide quantitative insights into various aspects of the
software development process and product quality, facilitating informed decision-making and
continuous improvement.
UNIT-2

4m

Let's address each of your questions:

1. **SDLC process model for developing technically challenging software products:**

- For technically challenging software products, the Spiral Model is often preferred. It allows for
iterative development with risk analysis and mitigation at each iteration. This model accommodates
changing requirements and technical complexities effectively.

2. **SDLC process model if requirements of a Software Project are not well understood:**

- In situations where requirements are not well understood, an Agile approach such as Scrum or
Extreme Programming (XP) is suitable. These Agile models emphasize iterative development,
frequent collaboration with stakeholders, and flexibility to accommodate evolving requirements.

3. **SDLC process model for developing large projects which can be decomposed into a set:**

- For large projects that can be decomposed into a set of smaller manageable components, the
Incremental or Iterative Model is a good choice. It allows for incremental development and
integration of modules, reducing risks and improving manageability.

4. **SDLC process model if requirements of a Software Project are well understood:**

- When requirements are well understood, the Waterfall Model is often used. It follows a
sequential approach with distinct phases for requirements gathering, design, implementation,
testing, and deployment. This model is suitable for projects with stable and clear requirements
upfront.

5. **Spiral Model as a meta model:**

- The Spiral Model is called a meta model because it combines elements of other SDLC models,
such as the Waterfall Model, Iterative Model, and Prototyping Model. It integrates risk analysis,
prototyping, and iterative development in a spiral fashion, making it adaptable to various project
scenarios.

6. **Comparison of Prototyping model and Incremental process model:**

- The Prototyping Model focuses on creating a working prototype to gather user feedback and
refine requirements. It is suitable for projects with evolving or unclear requirements.
 - The Incremental Process Model involves dividing the project into increments or phases, with each
increment delivering a subset of functionality. It is suitable for projects with well-defined
requirements that can be developed incrementally.

7. **XP in Agile process model:**

- Extreme Programming (XP) is an Agile process model that emphasizes collaboration, feedback,
simplicity, and flexibility. It includes practices such as continuous integration, test-driven
development, pair programming, and frequent releases to deliver high-quality software iteratively.

8. **Component-Based Software Development (CBSD) for rapid development:**

- CBSD allows developers to reuse pre-built components or modules, reducing development time
and effort. By assembling components like building blocks, developers can focus on integrating and
customizing functionalities, leading to faster development and time-to-market.

9. **Sequence diagram for ticket-issuing system actions:**

- Sequence diagrams can depict actions such as user input (selecting ticket type, quantity), system
processing (checking availability, calculating price), payment processing (choosing payment method,
processing payment), and issuing the ticket (generating ticket, printing).

10. **User requirements for spelling-checking and correcting function in a word processor:**

- Natural language processing capabilities for identifying spelling errors, suggesting corrections,
providing grammar suggestions, supporting multiple languages, offering customizable dictionaries,
and integrating seamlessly with the word processor interface.

11. **Functional and Non-Functional requirements of an ATM Cash Withdrawal System:**

- Functional requirements include ATM user authentication, cash withdrawal processing, balance
inquiry, receipt printing, error handling.

- Non-functional requirements include system availability (uptime), response time, security (data
encryption, PIN protection), usability (user interface design), and reliability (fault tolerance, backup
systems).

12. **Functional and Non-Functional requirements of an ATM Cash Deposit System:**

- Functional requirements include ATM user authentication, cash deposit processing, envelope
validation, receipt printing, error handling.

- Non-functional requirements include system availability (uptime), response time, security (data
encryption, transaction validation), usability (user interface design), and reliability (fault tolerance,
audit trails).
13. **System requirements for Fingerprint Biometric system for attendance monitoring:**

- System requirements include fingerprint recognition capabilities, attendance tracking, user

enrollment, access control, real-time data processing, audit logs, and integration with attendance
management software.

14. **System requirements for online ticket booking system:**

- System requirements include user authentication, ticket availability checking, seat selection,
payment processing, booking confirmation, email notifications, cancellation handling, and reporting
capabilities.

**Characteristics of a bad SRS (Software Requirements Specification):**

- Ambiguity or vagueness in requirements.

- Inconsistencies or contradictions within requirements.

- Lack of clarity in functional or non-functional requirements.

- Unrealistic or unachievable requirements.

- Missing or incomplete requirements documentation.

15. **Difference between SRS and design document:**

- SRS (Software Requirements Specification) defines what the software should do, focusing on user
needs, functionalities, constraints, and specifications.

- Design documents (e.g., architecture design, detailed design) describe how the software will be
implemented, including system architecture, modules, components, interfaces, algorithms, and data
structures.

16. **One thing assumed for rapid development in RAD model:**

- The RAD (Rapid Application Development) model assumes the existence of pre-built components
or reusable modules that can be quickly integrated to accelerate development.

17. **Process adaptations required if prototype evolves into a deliverable system:**

- The prototype may need refactoring, optimization, and scalability enhancements to meet
production-level performance and reliability standards.

- Quality assurance and testing efforts must be expanded to ensure robustness, security, and
compatibility.

- Documentation, training materials, and user support systems need to be developed for the final
product.
18. **Combining process models:**

- It is possible to combine process models, such as using a hybrid approach that combines
elements of Agile (e.g., Scrum) for iterative development with aspects of Waterfall for initial planning
and documentation.

- The choice of combined process models depends on project requirements, team dynamics,
organizational culture, and development context.

These answers cover various aspects of software development methodologies, requirements

engineering, system design, and process models. Let me know if you need further clarification on any
topic!

2m

Let's go through each of these questions:

1. **States in a concurrent process model:**

- States in a concurrent process model represent different stages or conditions of execution within
concurrent or parallel processes. These states can include active execution, waiting for resources or
synchronization, ready to execute, and completed or terminated states.

2. **Emphasizing development speed over software quality:**

- Emphasizing development speed over software quality can lead to several consequences:

- Increased risk of introducing bugs, defects, and errors.

- Reduced code maintainability and readability.

- Decreased customer satisfaction due to poor quality or unreliable software.

- Higher long-term costs for bug fixes, rework, and technical debt.

3. **Cross-cutting concerns in process models:**

- Cross-cutting concerns in process models refer to aspects or functionalities that affect multiple
components or modules across the software system. Examples include security, logging, error
handling, performance optimization, and authentication mechanisms.

4. **Difference between user requirements and functional system requirements:**

 ![User Requirements vs Functional System Requirements](https://i.ibb.co/MVn8zMD/User-
Requirements-vs-Functional-System-Requirements.png)

- User requirements focus on what the users need and expect from the system in terms of features,
functionalities, and user interactions.

- Functional system requirements specify how the system should behave or perform specific
functions to meet user requirements.

5. **User requirements vs. functional system requirements:**

- User requirements describe what the system should do from the user's perspective, focusing on
user needs, goals, tasks, and interactions.

- Functional system requirements detail specific functionalities, behaviors, operations, and

constraints that the system must implement to fulfill user requirements.

6. **Why non-functional requirements arise:**

- Non-functional requirements arise to specify qualities, characteristics, constraints, and properties

of the system that are not related to specific functionalities but are crucial for overall system
performance, usability, security, and reliability.

7. **Four non-functional external requirements:**

- Compliance with industry standards or regulations.

- Compatibility with external systems or platforms.

- Performance benchmarks (e.g., response time, throughput).

- Security requirements (e.g., data encryption, access control).

8. **Example of a non-functional requirement without metrics:**

- "The system must provide a seamless user experience."

- This requirement emphasizes a quality aspect (user experience) without specifying quantifiable
metrics.

9. **Requirement for a standard interface to all databases:**

- This requirement is a technical requirement related to interoperability and consistency across

database interactions within the application. It ensures that all database interactions follow a
standardized interface for ease of maintenance and scalability.
10. **Domain requirements in a lift system:**

- Domain requirements for a lift system might include safety regulations compliance, maximum
weight capacity, floor navigation logic, emergency procedures, user interface accessibility, and energy
efficiency.

11. **Structural natural language vs. standard natural language:**

- Structural natural language refers to a structured format or syntax used to specify requirements,
such as using templates, diagrams, and models to describe system behaviors and interactions.

- Standard natural language refers to conventional written or spoken language used to express
requirements, often without specific structural constraints or formalisms.

12. **Example of a procedural interface:**

- A procedural interface specifies step-by-step instructions or procedures for interacting with a

system or component. For example, a procedural interface for a banking system might include steps
for account login, balance inquiry, fund transfer, and transaction history retrieval.

13. **Level of detail in a requirements document and system type:**

- The level of detail in a requirements document depends on the complexity, scope, and nature of
the system being developed. For complex systems, detailed requirements with clear specifications,
use cases, scenarios, and acceptance criteria are necessary.

14. **Requirements spiral and activities overview:**

- The requirements spiral represents iterative refinement of requirements throughout the software
development life cycle, including activities such as elicitation, analysis, prioritization, validation, and
documentation.

15. **Requirements process activities in the requirements spiral:**

- Requirements process activities include:

- Eliciting requirements from stakeholders.

- Analyzing and prioritizing requirements.

- Validating requirements with stakeholders.

- Documenting requirements in a clear, structured format.

- Managing changes and updates to requirements throughout the project.

16. **Requirements Engineering process with a diagram:**

![Requirements Engineering Process](https://i.ibb.co/qrq8wK8/Requirements-Engineering-

Process.png)

- The Requirements Engineering process involves activities such as:

- Requirements Elicitation: Gathering requirements from stakeholders.

- Requirements Analysis: Analyzing and understanding requirements.

- Requirements Specification: Documenting requirements in a formal format.

- Requirements Validation: Ensuring requirements are complete, consistent, and feasible.

- Requirements Management: Managing changes, traceability, and version control of

requirements documents.

These answers cover a wide range of topics related to software requirements, process models,
quality considerations, and system development activities. Let me know if you need more details on
any specific aspect!