3m q/a:

### 1. Distinguish generic and customized software products with examples for each.

- **Generic Software Products**: These are designed to be used by a wide range of users
with broadly similar needs. They are typically off-the-shelf solutions that require little to no
customization. Example: Microsoft Office Suite, which is used by many organizations for
tasks such as word processing, spreadsheet management, and presentations.

- **Customized Software Products**: These are tailored to meet the specific requirements
of a particular organization or user. They are developed to address unique business
processes or challenges. Example: A custom Customer Relationship Management (CRM)
system developed for a specific company to manage its unique sales processes and customer
interactions.

### 2. Distinguish functional and non-functional requirements.

- **Functional Requirements**: These specify what the system should do, describing the
functions and features it must have. They detail the expected behavior of the system in
particular situations. Example: "The system shall allow users to log in using their email and
password."

- **Non-Functional Requirements**: These define how the system performs a function,

describing system attributes such as performance, usability, reliability, and security. They are
often constraints or quality attributes. Example: "The system shall respond to user inputs
within 2 seconds," emphasizing performance rather than specific functionality.

### 3. List and explain any two of the fundamental software development activities.

- **Requirements Analysis**: This activity involves gathering and analyzing the requirements
from stakeholders to ensure a thorough understanding of what the software needs to do. It
serves as the foundation for the entire development process, ensuring that all stakeholder
needs are addressed.

- **Design**: This phase involves defining the architecture, components, interfaces, and
data for a system to satisfy specified requirements. It translates requirements into a
blueprint for building the software, detailing how each component will function and interact
within the system.

### 4. List and explain any two attributes of good software.

- **Reliability**: Good software consistently performs its intended functions under specified
conditions without failure. It must handle errors gracefully and operate without unexpected
interruptions, ensuring users can rely on it for critical tasks.

- **Usability**: Good software is user-friendly, easy to learn, and efficient to use. It provides
a good user experience by having an intuitive interface and clear instructions, reducing the
learning curve and increasing productivity and satisfaction.

### 5. Summarize the key challenges facing software engineering.

- **Complexity Management**: Modern software systems are increasingly complex,

integrating multiple technologies and components. Managing this complexity to ensure the
software is maintainable, scalable, and reliable is a significant challenge.

- **Quality Assurance**: Ensuring software meets high standards of performance, security,

and reliability is essential. Balancing time and budget constraints while delivering quality
software that satisfies user requirements and withstands real-world conditions is a
persistent challenge for software engineers.

### 6. How has the web impacted software engineering development?

The web has profoundly impacted software engineering development by facilitating global
collaboration, enabling remote work, and fostering the open-source movement. It has
shifted development towards web-based applications accessible from any location, which
has introduced new security and performance considerations. Agile and DevOps
methodologies have become more prevalent, leveraging continuous integration and
continuous deployment (CI/CD) pipelines. Additionally, the web has democratized software
distribution, allowing developers to reach a global audience quickly and efficiently, and has
accelerated the pace of innovation through rapid feedback and iteration cycles.
### 7. As a software developer, list some of the ethical considerations you should take into
account when developing healthcare software.

- **Privacy and Confidentiality**: Ensuring that patient data is protected and only accessible
to authorized individuals.
- **Accuracy and Reliability**: Ensuring the software is accurate and reliable to prevent
medical errors that could harm patients.
- **Compliance**: Adhering to healthcare regulations and standards, such as HIPAA in the
United States.
- **Transparency**: Being clear about how data is collected, used, and shared.
- **Usability and Accessibility**: Ensuring the software is user-friendly and accessible to all
users, including those with disabilities.
- **Security**: Implementing robust security measures to protect against breaches and
cyber-attacks.

### 8. Write the differences between functional and non-functional requirements.

- **Functional Requirements**:
- Define what the system should do.
- Describe specific behaviors or functions.
- Example: "The system shall allow users to create and edit profiles."

- **Non-Functional Requirements**:
- Define how the system performs its functions.
- Describe system attributes such as performance, usability, and reliability.
- Example: "The system shall handle up to 10,000 concurrent users."

### 9. Describe prototyping model with an example.

The prototyping model involves creating an early, simplified version of the final system
(prototype) to understand user requirements better. It allows users to interact with the
prototype, providing feedback that guides further development. This iterative process
continues until the final system meets user needs.

**Example**: Developing a new mobile banking app. A prototype is created to demonstrate

basic functionalities like login, account balance viewing, and fund transfers. Users interact
with this prototype and provide feedback, which is used to refine and enhance the app until
it fully meets the users' expectations.

### 10. How do the principles of the IEEE/ACM Code of Software Engineering Ethics guide
software engineers in their professional activities?

- **Public Interest**: Software engineers should act in the best interest of the public,
ensuring their work benefits society and minimizes harm.
- **Client and Employer**: Engineers must act in the best interests of their clients and
employers, consistent with the public interest, ensuring honesty and fairness in all dealings.
- **Product**: Engineers should ensure the products they develop meet the highest
professional standards possible, emphasizing quality and reliability.
- **Judgment**: They should maintain integrity and independence in their professional
judgment, making decisions based on professional principles rather than personal gain.
- **Management**: Ethical management practices should be promoted, including fairness,
transparency, and respect for all team members.
- **Profession**: Engineers should advance the integrity and reputation of the profession,
supporting professional development and ethical behavior among peers.

### 11. List any 6 ethical principles that must be followed by a software developer.

1. **Public Interest**: Act consistently with the public interest and welfare.
2. **Client and Employer**: Act in the best interest of clients and employers, consistent
with the public interest.
3. **Product**: Ensure the software product meets the highest professional standards
possible.
4. **Judgment**: Maintain integrity and independence in professional judgment.
5. **Management**: Promote an ethical approach to the management of software
development and maintenance.
6. **Profession**: Advance the integrity and reputation of the profession consistent with
the public interest.

### 12. Why is it important for software engineers to follow a code of ethics?

Following a code of ethics is crucial for software engineers because it builds trust and
credibility with clients, employers, and the public. It ensures high-quality, reliable, and safe
software products. Adherence to ethical standards promotes professional integrity and
accountability, preventing malpractice and ensuring that the work benefits society. It also
guides engineers in making decisions that balance competing interests and navigate complex
ethical dilemmas.

### 13. Why is requirements gathering and analysis considered a critical phase in software
engineering?

Requirements gathering and analysis are critical because they form the foundation for the
entire software development process. This phase ensures that the developers understand
the stakeholders' needs and expectations, leading to a product that meets user
requirements and business goals. Proper requirements analysis helps identify potential
issues early, reducing the risk of costly changes and rework later. It also facilitates clear
communication among stakeholders, developers, and project managers.

### 14. What is the purpose of a data flow diagram (DFD) in software engineering?

A data flow diagram (DFD) serves to visualize the flow of data within a system, illustrating
how data is processed and transferred between different parts of the system. It helps in
understanding the functional aspects of the system, identifying data sources, destinations,
and processes. DFDs are valuable for communicating system design to stakeholders and
ensuring that all data handling requirements are understood and addressed during
development.

### 15. List three characteristics of a good SRS.

1. **Complete**: The SRS should include all necessary requirements and information,
leaving no aspect of the system unaddressed.
2. **Consistent**: It should be free of contradictions, with requirements and information
harmoniously aligned.
3. **Unambiguous**: The SRS should be clear and precise, avoiding vague language to
prevent misinterpretations and ensure everyone has a common understanding of the
requirements.

### 16. Identify three critical non-functional requirements for a banking application and
explain why they are important.

1. **Security**: Essential to protect sensitive financial data from unauthorized access and
breaches. Ensuring robust authentication, encryption, and access control mechanisms is
critical to maintaining user trust and regulatory compliance.
2. **Performance**: Crucial for handling a high volume of transactions efficiently. The
system must provide quick response times to ensure a seamless user experience and
prevent frustration, especially during peak usage times.
3. **Reliability**: The application must be highly reliable with minimal downtime to ensure
users can access banking services whenever needed. This is vital for maintaining customer
satisfaction and trust in the bank's services.

### 17. What information is conveyed by a sequence diagram in software design?

A sequence diagram conveys the sequence of interactions between objects or components

in a system over time. It shows the order in which messages are exchanged, the interactions
between different system parts, and the flow of control. This helps in understanding the
dynamic behavior of the system, visualizing how different components collaborate to
perform a function, and identifying potential issues in the interaction flow.

### 18. Create a simple sequence diagram for the "Login" use case in a web application.

```plaintext
User Login Page Server Database
| | | |
|---Enter Login--> | | |
| |---Send Credentials--> |
| | |--Query--> |
| | |<--User Data--- |
| |<--Success/Fail Response--| |
|<--Display Message| | |
| | | |
```

### 19. How do use case models contribute to the requirements analysis process?

Use case models contribute by providing a clear and structured way to capture functional
requirements. They describe the interactions between users (actors) and the system,
illustrating different scenarios and user goals. This helps identify and document what the
system should do from the user's perspective, facilitating better understanding and
communication among stakeholders. Use case models also help uncover hidden
requirements and ensure that all user needs are considered during development.

### 20. How would you document the interface specifications for a travel booking system
in the SRS?

To document the interface specifications for a travel booking system in the SRS, you should
include:

- **Interface Description**: Provide a detailed description of each interface, including its

purpose and functionality.
- **Data Inputs and Outputs**: Specify the data required for each interface and the
expected outputs.
- **Interaction Diagrams**: Use UML diagrams, such as sequence or activity diagrams, to
visualize interactions.
- **Protocols and Formats**: Define the communication protocols (e.g., HTTP, SOAP) and
data formats (e.g., JSON, XML) used.
- **Constraints and Limitations**: Document any constraints, such as performance
limitations or security requirements.
- **Error Handling**: Describe how errors will be handled and communicated to the user or
other systems.
UNT1:
Application types
 Stand-alone applications
 These are application systems that run on a local computer, such
as a PC. They include all necessary functionality and do not need
to be connected to a network.
 Interactive transaction-based applications
 Applications that execute on a remote computer and are accessed
by users from their own PCs or terminals. These include web
applications such as e-commerce applications.
 Embedded control systems
 These are software control systems that control and manage
hardware devices. Numerically, there are probably more
embedded systems than any other type of system.
 Batch processing systems
 These are business systems that are designed to process data in
large batches. They process large numbers of individual inputs to
create corresponding outputs.
 Entertainment systems
 These are systems that are primarily for personal use and which
are intended to entertain the user.
 Systems for modeling and simulation
 These are systems that are developed by scientists and engineers
to model physical processes or situations, which include many,
separate, interacting objects.
 Data collection systems
 These are systems that collect data from their environment using a
set of sensors and send that data to other systems for processing.
 Systems of systems
 These are systems that are composed of a number of other
software systems.
Software engineering fundamentals
 Some fundamental principles apply to all types of software system, irrespective of
the development techniques used:
 Systems should be developed using a managed and understood development
process. Of course, different processes are used for different types of
software.
 Dependability and performance are important for all types of system.
 Understanding and managing the software specification and requirements
(what the software should do) are important.
 Where appropriate, you should reuse software that has already been
developed rather than write new software.

Key points:
 Software engineering is an engineering discipline that is concerned with all aspects of
software production.
 Essential software product attributes are maintainability, dependability and security,
efficiency and acceptability.
 The high-level activities of specification, development, validation and evolution are
part of all software processes.
 The fundamental notions of software engineering are universally applicable to all
types of system development.
 There are separate identified phases in the waterfall model:
 Requirements analysis and definition

 System and software design

 Implementation and unit testing

 Integration and system testing

 Operation and maintenance

 The main drawback of the waterfall model is the difficulty of accommodating change after
the process is underway. In principle, a phase has to be complete before moving onto the
next phase.

 Inflexible partitioning of the project into distinct stages makes it difficult to respond
to changing customer requirements.
 Therefore, this model is only appropriate when the requirements are well-understood and
changes will be fairly limited during the design process.

 Few business systems have stable requirements.

 The waterfall model is mostly used for large systems engineering projects where a
system is developed at several sites.
 In those circumstances, the plan-driven nature of the waterfall model helps
coordinate the work.
 The cost of accommodating changing customer requirements is reduced.
 The amount of analysis and documentation that has to be redone is much
less than is required with the waterfall model.
 It is easier to get customer feedback on the development work that has been done.
 Customers can comment on demonstrations of the software and see how
much has been implemented.
 More rapid delivery and deployment of useful software to the customer is possible.
 Customers are able to use and gain value from the software earlier than is
possible with a waterfall process.
 The process is not visible.
 Managers need regular deliverables to measure progress. If systems are
developed quickly, it is not cost-effective to produce documents that reflect
every version of the system.
 System structure tends to degrade as new increments are added.
 Unless time and money is spent on refactoring to improve the software,
regular change tends to corrupt its structure. Incorporating further software
changes becomes increasingly difficult and costly.
Reuse-oriented software engineering
 Based on systematic reuse where systems are integrated from existing components or COTS
(Commercial-off-the-shelf) systems.

 Process stages

 Component analysis;

 Requirements modification;

 System design with reuse;

 Development and integration.

 Reuse is now the standard approach for building many types of business system

 Reuse covered in more depth in Chapter 16.

 Development or component testing

 Individual components are tested independently;

 Components may be functions or objects or coherent groupings of these entities.

 System testing

 Testing of the system as a whole. Testing of emergent properties is particularly

important.

 Acceptance testing

 Testing with customer data to check that the system meets the customer’s needs.
System evolution

Reducing the costs of rework

 Change avoidance, where the software process includes activities that can anticipate
possible changes before significant rework is required.

 For example, a prototype system may be developed to show some key features of
the system to customers.

 Change tolerance, where the process is designed so that changes can be accommodated at
relatively low cost.

 This normally involves some form of incremental development. Proposed changes

may be implemented in increments that have not yet been developed. If this is
impossible, then only a single increment (a small part of the system) may have be
altered to incorporate the change.

The process of prototype development

Incremental delivery
 Rather than deliver the system as a single delivery, the development and delivery is broken
down into increments with each increment delivering part of the required functionality.

 User requirements are prioritised and the highest priority requirements are included in early
increments.

 Once the development of an increment is started, the requirements are frozen though
requirements for later increments can continue to evolve.

 Incremental development

 Develop the system in increments and evaluate each increment before proceeding to
the development of the next increment;

 Normal approach used in agile methods;

 Evaluation done by user/customer proxy.

 Incremental delivery

 Deploy an increment for use by end-users;

 More realistic evaluation about practical use of software;

 Difficult to implement for replacement systems as increments have less functionality

than the system being replaced.
 Process is represented as a spiral rather than as a sequence of activities with backtracking.

 Each loop in the spiral represents a phase in the process.

 No fixed phases such as specification or design - loops in the spiral are chosen depending on
what is required.

 Risks are explicitly assessed and resolved throughout the process.

1. Outline the activities in requirements engineering with a neat diagram.
Activities in Requirements Engineering:
1. Elicitation: Gathering requirements from stakeholders.
2. Analysis: Analyzing and refining requirements to ensure clarity and
feasibility.
3. Specification: Documenting the requirements in a detailed and
structured format.
4. Validation: Ensuring that the requirements accurately reflect stakeholder
needs.
 5. Management: Handling changes to requirements throughout the project
lifecycle.
Diagram:
plaintext
Copy code
+-------------+ +------------+ +-------------+ +-------------+ +-------------+
| | | | | | | | | |
| Elicitation | -> | Analysis | -> | Specification | -> | Validation | -> |
Management |
| | | | | | | | | |
+-------------+ +------------+ +-------------+ +-------------+ +-------------+
2. Compare user requirements with system requirements.
 User Requirements:
o Nature: High-level, abstract statements describing what the users
need from the system.
o Audience: Intended for stakeholders, including non-technical
users.
o Detail: Less detailed; focuses on goals and tasks.
o Example: "The system should allow users to book tickets online."
 System Requirements:
o Nature: Detailed, precise specifications of system functionality and
constraints.
o Audience: Intended for developers and technical staff.
o Detail: Highly detailed; includes specific functions, performance
criteria, and design constraints.
o Example: "The system shall enable users to book tickets by
entering travel dates, selecting flights, and making payments
through a secure gateway."
3. Discuss why various application types demand specialized software
engineering techniques to facilitate their design and development, providing
examples based on your understanding of different application types.
Different application types have unique requirements and constraints,
necessitating specialized software engineering techniques:
 Real-time Systems: Require techniques for ensuring timely and
deterministic responses. Example: Embedded systems in medical
devices, which must respond to inputs within a critical time frame.
 Distributed Systems: Need methods for managing communication,
consistency, and fault tolerance across networked components. Example:
Cloud-based services like Google Drive, which must handle data
synchronization and availability.
 Web Applications: Require techniques for handling scalability, security,
and user experience. Example: E-commerce sites like Amazon, which
need to manage high traffic, secure transactions, and intuitive interfaces.
 Mobile Applications: Demand approaches for resource optimization and
responsive design. Example: Mobile banking apps, which must be
efficient with limited device resources and provide a smooth user
experience on various screen sizes.
4. Infer how the universal use of the Web has changed software systems and
their development.
The universal use of the Web has significantly transformed software systems
and their development:
 Increased Collaboration: Facilitates global collaboration through tools
like version control systems (e.g., GitHub) and project management
platforms (e.g., Jira).
 Shift to Web-based Applications: Emphasis on developing web
applications accessible via browsers, reducing the need for platform-
specific versions.
 Agile and DevOps: Adoption of Agile and DevOps methodologies for
faster, iterative development and continuous integration/continuous
deployment (CI/CD).
  Scalability and Cloud Computing: Leveraging cloud platforms (e.g., AWS,
Azure) for scalable, on-demand resources.
 Security and Privacy: Heightened focus on cybersecurity and data
privacy due to widespread web access and regulations like GDPR.
5. How should a software engineer handle a conflict of interest according to
the IEEE/ACM code of ethics?
According to the IEEE/ACM code of ethics, a software engineer should handle a
conflict of interest by:
 Disclosure: Fully disclosing any potential conflicts to relevant parties.
 Transparency: Being transparent about the nature and extent of the
conflict.
 Avoidance: Avoiding situations where personal interests could
compromise professional judgment or integrity.
 Prioritizing Professionalism: Ensuring that decisions are made based on
professional standards and the best interest of stakeholders, rather than
personal gain.

Sure, let's go through each of these points one by one:

### 6. Attributes of a Good Software

A good software typically exhibits the following attributes:

1. **Functionality**: The software should fulfill the specified requirements and

perform the tasks it is designed to do effectively.
2. **Reliability**: The software should function consistently and accurately
over time, providing correct outputs without failure.
3. **Usability**: The software should be easy to use and understand, with an
intuitive user interface.
4. **Efficiency**: The software should use system resources such as memory
and processing power efficiently.
5. **Maintainability**: The software should be designed in a way that it is easy
to modify and update to fix bugs or add new features.
6. **Portability**: The software should be able to run on various platforms and
operating systems without requiring significant rework.
7. **Security**: The software should protect against unauthorized access and
data breaches, ensuring the confidentiality, integrity, and availability of data.
8. **Scalability**: The software should be able to handle increasing amounts
of work or be easily expanded to accommodate growth.
9. **Interoperability**: The software should be able to interact and exchange
data with other systems or software.
10. **Robustness**: The software should be able to handle errors and
unexpected situations gracefully without crashing.

### 7. Significance of SRS Document in Software Development

An SRS (Software Requirements Specification) document is crucial in software

development for several reasons:

1. **Clear Requirements**: It provides a clear and detailed description of the

software's intended functionality and constraints, ensuring that all stakeholders
have a mutual understanding of the requirements.
2. **Foundation for Development**: It serves as a foundation for system
design, development, and testing, guiding the entire software development
lifecycle.
3. **Communication Tool**: It acts as a communication tool between clients,
developers, and other stakeholders, facilitating effective communication and
reducing misunderstandings.
4. **Project Planning**: It aids in project planning by helping to estimate costs,
resources, and time required for the project.
5. **Legal Agreement**: It can serve as a contractual agreement between the
client and the development team, detailing what is to be delivered.
6. **Traceability**: It helps in tracing the requirements throughout the
development process, ensuring that the final product meets the specified
requirements.

### 8. Addressing a Security Flaw According to IEEE/ACM Code of Software

Engineering Ethics

When a software engineer discovers a potential security flaw, they should

adhere to the IEEE/ACM code of ethics by following these steps:

1. **Immediate Action**: Act promptly to address the issue, prioritizing the

safety and security of users.
2. **Reporting**: Report the flaw to the appropriate authorities within the
organization, such as the security team or senior management.
3. **Confidentiality**: Maintain confidentiality and avoid disclosing the flaw to
unauthorized parties to prevent potential exploitation.
4. **Cooperation**: Work collaboratively with the relevant teams to develop
and implement a fix for the flaw.
5. **Documentation**: Document the flaw, the steps taken to address it, and
any recommendations for preventing similar issues in the future.
6. **Responsibility**: Accept responsibility for ensuring that the software is
secure and reliable, and follow through to ensure the flaw is properly resolved.
7. **Ethical Conduct**: Act with integrity and professionalism, adhering to the
ethical standards set forth by the IEEE/ACM code of ethics.

### 9. Ambiguities or Omissions in the Statement of Requirements

The statement of requirements for the hotel booking system has some
ambiguities and omissions:

1. **Room Types**: It does not specify if users can search for specific types of
rooms (e.g., single, double, suite).
2. **Payment Process**: It omits details about the payment process, such as
payment methods, transaction security, and confirmation.
3. **Modification/Cancellation**: It does not mention whether users can
modify or cancel their reservations after confirmation.
4. **Guest Details**: It lacks details on what guest information is required for
the reservation (e.g., names, contact details).
5. **Error Handling**: It does not specify how the system handles errors or
unavailability of rooms.
6. **User Accounts**: It does not mention if users need to create an account
or can book as guests.
7. **Special Requests**: It omits whether users can make special requests
(e.g., extra beds, late check-out).

### 10. Functional and Non-Functional Requirements for a Medical Records

Management System

**Functional Requirements**:
1. **Patient Registration**: The system should allow for the registration of new
patients, capturing personal and medical information.
2. **Appointment Scheduling**: The system should enable scheduling,
rescheduling, and cancellation of appointments.
3. **Medical Records**: The system should maintain detailed medical records
for each patient, including history, diagnoses, treatments, and medications.
4. **Access Control**: The system should provide role-based access control,
allowing different levels of access for doctors, nurses, and administrative staff.
5. **Billing and Payments**: The system should manage billing, invoicing, and
payment processing for medical services.

**Non-Functional Requirements**:
1. **Security**: The system must ensure data privacy and security, complying
with relevant regulations like HIPAA.
2. **Performance**: The system should have fast response times, handling
large volumes of data and multiple simultaneous users efficiently.
3. **Reliability**: The system should be reliable, with minimal downtime and
robust backup and recovery mechanisms.
4. **Usability**: The system should be user-friendly, with an intuitive interface
that can be easily used by medical staff with varying levels of technical
expertise.
5. **Scalability**: The system should be scalable, able to accommodate
growing numbers of patients and expanding hospital services.
6. **Interoperability**: The system should be able to integrate with other
hospital systems and external healthcare providers for seamless data exchange.

### 11. Key Sections in an SRS (IEEE Format) for a CRM System

1. **Introduction**: Purpose, scope, definitions, acronyms, and references.

2. **Overall Description**: Product perspective, product functions, user
characteristics, constraints, assumptions, and dependencies.
3. **Specific Requirements**: Functional requirements, interface
requirements, performance requirements, design constraints, and attributes.
4. **External Interface Requirements**: User interfaces, hardware interfaces,
software interfaces, and communication interfaces.
5. **System Features**: Detailed description of all features and functionalities.
6. **Other Non-functional Requirements**: Performance, security, reliability,
and maintainability.
7. **Appendices**: Glossary, analysis models, and references.

### 12. Functional vs. Non-Functional Requirements

- **Functional Requirements**: Define specific behavior or functions. Example:

"The CRM system must allow users to add new customer records."
- **Non-Functional Requirements**: Define system attributes such as
performance, security, or usability. Example: "The system should load the
customer database within 2 seconds."

### 13. Format for SRS Document

1. **Title Page**
2. **Table of Contents**
3. **Introduction**
- Purpose
- Scope
- Definitions, Acronyms, and Abbreviations
- References
- Overview
4. **Overall Description**
- Product Perspective
- Product Functions
- User Classes and Characteristics
- Operating Environment
 - Design and Implementation Constraints
- Assumptions and Dependencies
5. **Specific Requirements**
- External Interface Requirements
- Functional Requirements
- Performance Requirements
- Logical Database Requirements
- Design Constraints
- Software System Attributes
6. **Appendices**

### 14. Rationale for Comprehensive SRS

A comprehensive Software Requirements Specification (SRS) enhances clarity

by providing a detailed and structured outline of the system's requirements.
This mitigates misinterpretations by ensuring that all stakeholders have a
shared understanding of the system's functions and constraints. Consequently,
it elevates the overall quality of the final product by providing a clear roadmap
for development, reducing ambiguities, and facilitating better communication
and verification processes.

### 15. Real-World Scenario for ACM/IEEE Code of Ethics

1. **Public**: Developing user-friendly government websites for accessibility.

2. **Client and Employer**: Delivering software updates on time and within
budget.
3. **Product**: Ensuring rigorous testing for a medical software application.
4. **Judgment**: Providing honest estimates and feasibility reports.
5. **Management**: Encouraging ethical decision-making within the team.
6. **Profession**: Contributing to open-source projects.
7. **Colleagues**: Mentoring junior developers.
8. **Self**: Engaging in continuous professional development.

### 16. Ethics of Developing Citizen Tracking Systems

The development of citizen tracking systems for counter-terrorism raises

significant privacy concerns. Ethically, software engineers must balance
national security interests with individuals' right to privacy. Transparency,
consent, and data protection are crucial. Engineers should advocate for ethical
use and ensure robust safeguards against misuse, adhering to principles such
as those in the ACM/IEEE Code of Ethics to protect civil liberties.

### 17. SRS Document for an Online Movie Booking System

**Title Page**

**Table of Contents**

**Introduction**
- Purpose: Outline the objectives.
- Scope: Define the boundaries.
- Definitions, Acronyms, Abbreviations: Clarify terminology.
- References: Cite sources.
- Overview: Summarize content.

**Overall Description**
- Product Perspective: Context and interactions.
- Product Functions: Booking, payment, cancellations.
- User Classes and Characteristics: Regular users, admins.
- Operating Environment: Web-based, mobile support.
- Design and Implementation Constraints: Technology stack.
- Assumptions and Dependencies: Internet connectivity.

**Specific Requirements**
- **Functional Requirements**:
- User Registration and Authentication.
- Movie Listings and Search.
- Seat Selection and Booking.
- Payment Gateway Integration.
- Booking Confirmation and Notifications.
- **Non-Functional Requirements**:
- Performance: Load time < 3 seconds.
- Security: Data encryption, secure payment.
- Usability: Intuitive interface.
- Reliability: 99.9% uptime.

**External Interface Requirements**

- User Interfaces: Web and mobile interfaces.
- Hardware Interfaces: Servers, user devices.
- Software Interfaces: APIs for payment gateways.
- Communication Interfaces: Internet protocols.
**System Features**
- Detailed features such as movie search, booking management.

**Other Non-functional Requirements**

- Scalability, maintainability, compliance with standards.

**Appendices**
- Glossary, diagrams, additional references.

### 18. Fundamental Characteristics for High-Quality Software

1. **Functionality**: The software must fulfill the specified requirements and

perform the intended tasks correctly.
2. **Reliability**: The software should operate without failures under specified
conditions for a specified period.
3. **Usability**: The software should be user-friendly, with an intuitive
interface that is easy to navigate.
4. **Efficiency**: The software should make optimal use of resources,
including memory, processing power, and bandwidth.
5. **Maintainability**: The software should be easy to modify and update,
allowing for quick bug fixes and enhancements.
6. **Portability**: The software should be adaptable to different environments
and platforms with minimal changes.

### 19. Importance of Interface Specification in Software Development

Interface specification is crucial because it defines how software components
interact with each other and with external systems. Clear interface
specifications ensure:
- **Consistency**: Developers have a shared understanding of how
components should interact, reducing integration issues.
- **Modularity**: Components can be developed, tested, and maintained
independently, enhancing maintainability and scalability.
- **Interoperability**: Well-defined interfaces facilitate communication
between different systems and technologies, ensuring seamless integration.
- **Error Reduction**: Precise specifications reduce the likelihood of errors
during development and integration phases.

### 20. Non-Functional Requirements with Real-Time Examples

1. **Performance**:
- **Example**: An e-commerce website must handle 10,000 simultaneous
users during peak shopping seasons with page load times under 2 seconds.
2. **Security**:
- **Example**: A banking application must use multi-factor authentication
and encrypt all sensitive user data to protect against unauthorized access and
data breaches.
3. **Reliability**:
- **Example**: A cloud storage service must ensure 99.99% uptime and
provide data redundancy to prevent data loss in case of hardware failures.

Unit 2:
  Rapid development and delivery is now often the most important requirement for software
systems

 Businesses operate in a fast –changing requirement and it is practically impossible to

produce a set of stable software requirements

 Software has to evolve quickly to reflect changing business needs.

 Rapid software development

 Specification, design and implementation are inter-leaved

 System is developed as a series of versions with stakeholders involved in version

evaluation

 User interfaces are often developed using an IDE and graphical toolset.

Agile methods
 The aim of agile methods is to reduce overheads in the software process
(e.g. by limiting documentation) and to be able to respond quickly to
changing requirements without excessive rework.
The Sprint cycle
 Sprints are fixed length, normally 2–4 weeks. They correspond to the development of
a release of the system in XP.
 The starting point for planning is the product backlog, which is the list of work to be
done on the project.
 The selection phase involves all of the project team who work with the customer to
select the features and functionality to be developed during the sprint.
### 1. Key Factors Influencing the Choice of a Software Development Model

1. **Project Requirements**: Clear, well-defined requirements may suit the

Waterfall model, while evolving requirements fit incremental or Agile models.
2. **Project Size and Complexity**: Large, complex projects might benefit from
iterative models to manage complexity gradually.
3. **Resource Availability**: Limited resources might favor incremental or
Agile models, allowing gradual resource allocation.
4. **Risk Management**: Projects with high uncertainty might choose models
like Agile for better risk handling.
5. **Time Constraints**: Time-sensitive projects might prefer Agile for quicker
iterations and feedback.

**Choosing Incremental Model vs. Waterfall Model**:

- **Incremental Model**: Preferred when requirements are expected to
change, allowing for gradual development, testing, and integration.
- **Waterfall Model**: Suitable for projects with stable, well-understood
requirements, providing a structured, sequential approach.

### 2. Effective Software Development Model for Insufficient Resources

**Incremental Model**: This model allows the project to be developed in

small, manageable increments. It enables the team to start with limited
resources, delivering partial functionalities and gradually building the complete
system as more resources become available. This approach helps manage
scope and allows for better resource allocation over time.

### 3. Agile Process Methodology Contribution

**Agile Methodology** enhances flexibility and effectiveness by:

- **Frequent Iterations**: Regular iterations allow continuous feedback and
improvements.
- **Customer Collaboration**: Ongoing customer involvement ensures the
product meets evolving needs.
- **Adaptive Planning**: Agile responds to changes quickly, adapting plans and
priorities.

**Key Principles and Practices**:

- **Individuals and Interactions**: Over processes and tools.
- **Working Software**: Over comprehensive documentation.
- **Customer Collaboration**: Over contract negotiation.
- **Responding to Change**: Over following a plan.

### 4. Alignment of Agile Principles with Software Engineering Process

Activities

1. **Requirements Gathering**: Agile involves continuous collaboration with

stakeholders to gather and refine requirements through user stories and
backlogs.
2. **Design and Development**: Agile promotes iterative development with
design evolving based on feedback and testing.
3. **Testing**: Continuous integration and testing ensure early detection of
issues and maintain high-quality standards.
4. **Deployment**: Frequent releases and deployments enable quick delivery
of value to customers.
5. **Maintenance**: Agile's iterative nature allows for ongoing maintenance
and improvements based on user feedback.

### 5. Ride-Sharing System Scenario

#### i. Main Actors

1. **Passenger**
2. **Driver**
3. **Administrator**

#### ii. Core Functionalities

1. **Passenger**:
- Request Ride
- View Ride Details
- Track Ride
- Make Payment
- Rate Driver

2. **Driver**:
- Accept Ride
- View Ride Details
- Start/Complete Ride
- Update Availability
- Rate Passenger

3. **Administrator**:
- Manage Users (Passengers and Drivers)
- Monitor Rides
 - Handle Complaints
- Generate Reports

#### iii. Use Case Model

```plaintext
[Use Case Diagram]

+-------------+ +-------------+
| Passenger | | Driver |
+------+------+ +------+------+
| |
+-----------+-----------+ +-----------+-----------+
| | | |
+------+ +-----------+ +------+ +-----------+ +------+
|Request|<->| Accept | | View |<->| Start/End | | Rate |
| Ride | | Ride | | Ride | | Ride | | Driver |
+------+ +-----------+ +------+ +-----------+ +------+
^ ^ ^ ^
| | | |
+----+-------------+ +-------------+
| |
+------+-----------+ +-------------+
| Track Ride | | Make Payment |
+------------------+ +-------------+
+----------------+
 | Rate Ride |
+----------------+

```

This diagram visually represents the interactions between the main actors
(Passenger, Driver, Administrator) and the core functionalities they perform
within the ride-sharing system.

6. Situations for Choosing Rapid Application Development (RAD) Model

1. Short Timeframes: When there is a need to deliver the product quickly
due to market or business pressures.
2. Well-Defined Requirements: When requirements are clear and stable,
allowing for focused, rapid development.
3. Frequent User Feedback: When continuous user feedback is essential to
refine and improve the product.
4. Prototyping Needs: When visualizing and prototyping the product early
is crucial to validate requirements and design.
5. Resource Availability: When sufficient resources (skilled developers,
tools, technology) are available to support the rapid development
process.
7. Non-Traditional Process Model for Rapid Development in Competitive
Market
Lean Startup Methodology:
1. Build-Measure-Learn: Emphasizes building a minimum viable product
(MVP) quickly, measuring its performance and user feedback, and
learning from this data to make informed decisions.
2. Customer Development: Focuses on understanding customer needs and
iterating the product based on direct feedback.
 3. Continuous Deployment: Regularly releasing updates to quickly respond
to market demands and user feedback.
4. Pivot or Persevere: Decision-making process to either pivot the product
direction based on feedback or continue with the current strategy.
8. Process Model for Developing a Digital Payment Solution
Agile Development Model:
1. Flexibility: Agile’s iterative approach allows for adapting to changing
requirements and evolving market conditions.
2. Customer Collaboration: Continuous interaction with stakeholders
ensures that the product meets user expectations and regulatory
standards.
3. Incremental Delivery: Regular releases allow the product to be tested
and validated in real-world scenarios.
4. Cross-Functional Teams: Encourages collaboration across development,
testing, and business teams to deliver high-quality solutions.
### 6. Situations to Choose Rapid Application Development (RAD)

**Rapid Application Development (RAD)** is suitable when:

1. **Short Timeframe**: Projects needing quick delivery with tight
deadlines.
2. **Evolving Requirements**: Requirements are expected to change or are
not well-defined initially.
3. **User Involvement**: High user involvement is possible for continuous
feedback.
4. **Prototyping Benefits**: Visualizing and refining requirements through
prototypes is beneficial.
5. **Component-Based Architecture**: Projects that can be broken down
into smaller, manageable components.

### 9. Appropriateness of Throwaway Prototyping for Travel App

**Throwaway Prototyping** is appropriate when:
1. **Experimentation**: Allows rapid exploration of different design
concepts and functionalities.
2. **User Feedback**: Facilitates quick feedback from users, helping refine
requirements and design.
3. **Requirement Refinement**: Helps finalize requirements before full-
scale development.

**Key Characteristics**:
- **Rapid Iterations**: Develop multiple prototypes quickly to test different
ideas and gather feedback.
- **Quick Feedback**: Engage users and stakeholders to provide immediate
feedback on prototypes.
- **Limited Lifespan**: Prototypes are disposable; once requirements are
finalized, they are discarded in favor of a more robust solution.

**Benefits**:
- **Risk Reduction**: Identifies potential issues early in the development
process.
- **Flexibility**: Adapts easily to changing requirements and user needs.
- **Cost-Effectiveness**: Saves resources by avoiding extensive rework later
in the project.

**Challenges**:
- **Resource Allocation**: Requires sufficient resources for rapid
development cycles.
- **User Engagement**: Continuous user involvement is necessary to
maximize benefits.
### 10. Structural Modelling in Software Design Process

**Structural Modelling** involves creating a blueprint of the system's

architecture and components. Common models include:

1. **Class Diagram**:
- **Purpose**: Represents the static structure of a system by showing its
classes, attributes, operations, and relationships.
- **Example**:
```plaintext
+---------------------+
| Passenger |
+---------------------+
| - name |
| - email |
+---------------------+
| + requestRide() |
| + trackRide() |
+---------------------+
|
|
+---------------------+
| Ride |
+---------------------+
| - origin |
| - destination |
 | - fare |
+---------------------+
| + startRide() |
| + endRide() |
+---------------------+
```

2. **Component Diagram**:
- **Purpose**: Describes how a software system is split up into
components and shows the dependencies among these components.
- **Example**:
```plaintext
+---------------------+
| User Interface |
+---------------------+
|
v
+---------------------+
| Business Logic |
+---------------------+
|
v
+---------------------+
| Data Access |
+---------------------+
|
v
 +---------------------+
| Database |
+---------------------+
```

### 11. Behaviour Modelling in Software Design Process

**Behaviour Modelling** focuses on the dynamic aspects of the system,

showing how it behaves over time. Common models include:

1. **Use Case Diagram**:

- **Purpose**: Represents the functional requirements of a system and
the interactions between actors and the system.
- **Example**:
```plaintext
+-------------------+
| Passenger |
+-------------------+
| ^
| |
v |
+-------------------+ +----------------+
| Request Ride |<------->| Driver |
+-------------------+ +----------------+
| ^
v |
+-------------------+
 | Track Ride |
+-------------------+
| ^
v |
+-------------------+
| Make Payment |
+-------------------+
```

2. **Sequence Diagram**:
- **Purpose**: Shows how objects interact in a particular sequence to
accomplish a specific goal.
- **Example**:
```plaintext
Passenger System Driver
| | |
| requestRide | |
|-------------->| |
| | findDriver |
| |--------------->|
| | |
| rideDetails |<---------------|
|<--------------| |
| | |
| makePayment | |
|-------------->| |
| | |
 ```

### 12. Non-Traditional Process Model for Real-Time Communication

Platform

**Agile Methodology** is suitable, emphasizing continuous feedback and

iterative development:
- **Frequent Iterations**: Short development cycles allow for continuous
improvements.
- **User Feedback**: Regular feedback ensures the platform meets user
needs.
- **Flexibility**: Adapts to changing requirements and market conditions.

### 13. Process Model for Rapid Prototyping and User Feedback

**Lean Startup Model** is ideal for startups with limited resources:

- **Build-Measure-Learn Cycle**: Quickly build prototypes, measure user
responses, and learn from feedback.
- **Minimum Viable Product (MVP)**: Launch a basic version of the
product to test the market and gather feedback.
- **Pivot or Persevere**: Based on feedback, decide whether to continue
with the current approach or pivot to a new direction.

### 14. Recommended Process Model for Mission-Critical Software System

**V-Model (Verification and Validation Model)** is highly recommended for

Mr. Kumar's mission-critical software system due to its structured approach,
which ensures thorough testing and verification at each stage of
development.
**Illustration of V-Model**:

1. **Requirements Analysis**:
- Capture detailed and well-defined requirements.
- Verification: Requirements Review.

2. **System Design**:
- Create system architecture.
- Verification: System Design Review.

3. **High-Level Design**:
- Define modules and their interfaces.
- Verification: HLD Review.

4. **Low-Level Design**:
- Detailed design of individual modules.
- Verification: LLD Review.

5. **Implementation**:
- Code the modules.
- Verification: Code Review.

6. **Unit Testing**:
- Test individual modules.
- Validation: Unit Test Plan.
7. **Integration Testing**:
- Combine modules and test as a group.
- Validation: Integration Test Plan.

8. **System Testing**:
- Test the entire system.
- Validation: System Test Plan.

9. **User Acceptance Testing (UAT)**:

- Validate system against user requirements.
- Validation: UAT Plan.

### 15. Incremental Development for Business Software Systems

**Effectiveness for Business Software Systems**:

- **Flexibility**: Adapts to changing business requirements.
- **Continuous Feedback**: Allows for user feedback and iterative
improvements.
- **Reduced Risk**: Divides the project into manageable increments,
reducing overall risk.
- **Early Delivery**: Provides partial functionalities early in the
development cycle.

**Less Appropriate for Real-Time Systems Engineering**:

- **Complex Dependencies**: Real-time systems often have complex
interactions and dependencies that need comprehensive integration testing.
- **Timing Constraints**: Incremental development may not address
stringent timing and synchronization requirements.
- **Stability**: Real-time systems demand high stability and predictability,
which can be challenging to achieve incrementally.

### 16. Use Case Modelling for Library Management System

**Application of Use Case Modelling**:

1. **Identify Actors**:
- **Librarian**: Manages books, members, and transactions.
- **Member**: Borrows and returns books.
- **Administrator**: Manages the system settings and user roles.

2. **Define System Functionalities**:

- **Manage Books**: Add, update, and delete book records.
- **Manage Members**: Register and update member information.
- **Borrow Books**: Check out books to members.
- **Return Books**: Process book returns.
- **Generate Reports**: Create reports on book status, member activity,
etc.

3. **Ensure Alignment with User Requirements and Business Objectives**:

- Align functionalities with user needs and streamline library operations.
- Use case diagrams and descriptions help in visualizing and validating
requirements.
**Example Use Case Diagram**:
```plaintext
+------------+
| Member |
+-----+------+
|
+------+-------+
| Borrow Books |
+------+-------+
|
+-----v------+
| Return Books|
+-------------+

+------------+
| Librarian |
+-----+------+
|
+------+-------+
| Manage Books |
+------+-------+
|
+-----v------+
| Manage Members|
+-------------+
```
### 17. Use Case Modelling for Airline Ticket Reservation System

**Application of Use Case Modelling**:

1. **Identify Actors**:
- **Passenger**: Searches for flights, books tickets, and checks in.
- **Agent**: Assists passengers in booking and managing reservations.
- **System Administrator**: Manages system settings and ensures
smooth operation.
- **Payment Gateway**: Processes payments for bookings.

2. **Define System Functionalities**:

- **Search Flights**: Find available flights based on criteria.
- **Book Tickets**: Reserve seats and generate tickets.
- **Make Payments**: Process payment transactions.
- **Check-in**: Allow passengers to check-in online.
- **Manage Bookings**: Modify or cancel existing reservations.

3. **Ensure Seamless Booking Experience and Operational Efficiency**:

- Detailed use case descriptions ensure comprehensive coverage of all
interactions.
- Ensures the system meets user expectations and integrates well with
external systems like payment gateways and flight databases.

**Example Use Case Diagram**:

```plaintext
+-----------+
| Passenger |
+-----+-----+
|
+------+------+
| Search Flights|
+------+------+
|
+------+------+
| Book Tickets |
+------+------+
|
+------+------+
| Make Payment |
+------+------+
|
+------+------+
| Check-in |
+-------------+

+-----------+
| Agent |
+-----+-----+
|
+------+------+
| Manage Bookings|
 +-------------+
```

### 18. Prototype Model with Example

**Prototype Model**: Develops an initial version of the system to gather

user feedback and refine requirements before full-scale development.

**Example**:
1. **Initial Requirements Gathering**:
- Collect basic requirements for an e-commerce website.
2. **Develop Prototype**:
- Create a simple version with key features like product listings, shopping
cart, and checkout.
3. **User Feedback**:
- Gather feedback from potential users about usability and functionality.
4. **Refine Requirements**:
- Update requirements based on feedback.
5. **Develop Full System**:
- Proceed with full-scale development incorporating refined requirements.

### 19. Comparison of Waterfall and Incremental Models

**Waterfall Model**:

**Advantages**:
- **Structured Approach**: Clear, sequential phases.
- **Easy Management**: Each phase has specific deliverables.
- **Documentation**: Comprehensive documentation at each stage.

**Disadvantages**:
- **Inflexible**: Hard to accommodate changes once the process has
started.
- **Late Testing**: Testing phase comes late, potentially missing earlier
issues.
- **Requirement Inflexibility**: Assumes well-defined requirements from
the start.

**Incremental Model**:

**Advantages**:
- **Flexibility**: Accommodates changes and evolving requirements.
- **Early Delivery**: Delivers parts of the system early.
- **Reduced Risk**: Smaller, manageable increments.

**Disadvantages**:
- **Integration Complexity**: Combining increments can be complex.
- **Resource Intensive**: Requires continuous testing and integration.
- **Incomplete System**: Initial increments may not provide full
functionality.

### 20. Benefits of Using Data Flow Diagrams (DFDs) in Software

Engineering

**Requirements Analysis**:
- **Clarity**: Clearly depict the flow of information within the system.
- **Communication**: Facilitate communication between stakeholders by
visualizing system processes and data flows.

**System Design**:
- **Structure**: Help in structuring the system's design by identifying key
processes and data stores.
- **Modularity**: Promote modular design by breaking down the system
into smaller, manageable components.

**Documentation**:
- **Comprehensive Documentation**: Provide a visual representation of
the system for documentation purposes.
- **Reference**: Serve as a reference for developers and maintainers,
ensuring consistency and understanding of the system.

**Example DFD for an Order Processing System**:

```plaintext
+---------------------+
| Customer |
+---------+-----------+
|
+---------v-----------+
| Order System |
+---------+-----------+
|
+---------v-----------+
| Inventory |
 +---------+-----------+
|
+---------v-----------+
| Shipping System |
+---------------------+
```
Unit 3:
1. Importance of System Testing for a New Banking Application
Scenario: A bank is about to release a new mobile banking application that
allows users to transfer funds, check balances, pay bills, and manage accounts.
Importance of System Testing:
 Security: Ensures that sensitive user data, such as account information
and transaction details, is protected from unauthorized access.
 Functionality: Verifies that all features, like fund transfers, bill payments,
and account management, work correctly.
 Performance: Tests the application's performance under various
conditions, including peak usage times, to ensure it can handle high
traffic without crashing.
  Usability: Checks that the user interface is intuitive and user-friendly,
ensuring a positive user experience.
 Compliance: Ensures that the application meets regulatory and
compliance requirements specific to the banking industry.
2. Testing Strategy in Software Product Development
Testing Strategy:
1. Requirement Analysis: Understand the requirements to define test
objectives.
2. Test Planning: Develop a test plan that outlines the testing scope,
objectives, resources, schedule, and deliverables.
3. Test Design: Create test cases and test scripts based on requirements
and design documents.
4. Test Environment Setup: Set up the testing environment, including
hardware, software, network, and tools.
5. Test Execution: Execute the test cases, report defects, and track them to
closure.
6. Test Reporting: Document the test results, providing insights into the
quality of the product.
7. Test Closure: Ensure all test cases are executed, defects are resolved, and
test objectives are met. Archive test artifacts for future reference.
3. Levels of Testing in Software Product Development
1. Unit Testing:
o Need: Validates individual components or units of code for
correctness.
o Focus: Checks the functionality of specific sections of code, usually
functions or methods.
2. Integration Testing:
o Need: Ensures that combined units work together as expected.
o Focus: Tests interactions between integrated components or
systems.
 3. System Testing:
o Need: Validates the complete and integrated software system.
o Focus: Ensures the system meets functional and non-functional
requirements.
4. Acceptance Testing:
o Need: Validates the software in a real-world scenario to ensure it
meets business needs.
o Focus: Conducted by end-users or clients to ensure the system is
ready for deployment.
4. Applying Boundary Value Analysis to an Online Form for Age Input
Boundary Value Analysis (BVA):
 Test Cases:
o Lower Boundary: Test with ages 17 (just below), 18 (exact
boundary), and 19 (just above).
o Upper Boundary: Test with ages 64 (just below), 65 (exact
boundary), and 66 (just above).
Example:
 Valid Tests: 18, 19, 64, 65.
 Invalid Tests: 17, 66.
5. Differences Between Blackbox and Whitebox Testing
Blackbox Testing:
 Focus: Tests functionality without knowing the internal code structure.
 Example:
o Test: Checking if the login functionality works by entering valid and
invalid credentials.
Whitebox Testing:
 Focus: Tests internal code logic, structure, and paths.
 Example:
 o Test: Unit testing a function to ensure it correctly handles all
branches of conditional statements.
6. Approach to Reengineering an Old Software Application
Reengineering Approach:
1. Assessment:
o Evaluate the current state of the software, focusing on user
feedback and performance metrics.
2. Requirement Gathering:
o Collect new requirements to improve user experience and
interface design.
3. Design:
o Redesign the user interface to make it modern, intuitive, and user-
friendly.
4. Implementation:
o Refactor or rewrite the codebase to incorporate the new design
and improve performance.
5. Testing:
o Conduct thorough testing, including usability, functionality, and
performance tests.
6. Deployment:
o Deploy the reengineered application in stages, gathering user
feedback and making necessary adjustments.
Focus Areas:
 User Interface: Enhance visual design and usability.
 Performance: Optimize for speed and responsiveness.
 Functionality: Ensure all features work correctly and meet user needs.
 Security: Strengthen security to protect user data.
7. Implementing Version Control and Configuration Management
Version Control:
1. Adopt a Version Control System (VCS):
o Use a system like Git, which tracks changes, branches, and merges.
2. Establish a Branching Strategy:
o Use branches for features, fixes, and releases. Implement a
strategy such as Gitflow for managing branches.
3. Enforce Code Reviews:
o Require pull requests and peer reviews before merging code to the
main branch to ensure quality and consistency.
4. Use Meaningful Commit Messages:
o Write clear and descriptive commit messages to enhance
traceability of changes.
5. Regularly Merge Changes:
o Frequently merge changes from different branches to minimize
integration issues.
Configuration Management:
1. Centralize Configuration Files:
o Store configuration files in a version-controlled repository to track
changes and maintain consistency.
2. Automate Configuration Deployment:
o Use tools like Ansible, Puppet, or Chef to automate and manage
configurations across environments.
3. Document Configuration Changes:
o Keep detailed documentation of configuration settings, changes,
and their impact.
4. Implement Configuration Baselines:
 o Define and maintain baseline configurations to ensure consistency
across environments.
8. Boundary Value Analysis for Search Functionality
Boundary Value Analysis (BVA):
 Upper Bound: Test with a keyword of exactly 50 characters.
 Lower Bound: Test with an empty keyword (0 characters).
 Just Below and Above Boundaries:
o Test with 49 characters (just below the upper bound).
o Test with 51 characters (just above the upper bound).
Example Test Cases:
1. Keyword with 0 characters.
2. Keyword with 49 characters.
3. Keyword with 50 characters.
4. Keyword with 51 characters.
Purpose:
 Ensures that the search functionality handles keywords at the
boundaries and just outside them, verifying that input length constraints
are properly enforced.
9. Unit Testing a Function for Total Price Calculation
Steps to Create and Execute Unit Tests:
1. Understand the Function:
o Review the function's requirements and expected behavior for
calculating the total price.
2. Create Test Cases:
o Normal Cases: Test with typical shopping cart items.
o Edge Cases: Test with an empty cart or a cart with items priced at
zero.
o Boundary Cases: Test with very high item prices or quantities.
Examples:
o Cart with items costing $10 each and quantities 1, 2, and 3.
o Cart with no items.
o Cart with items having high prices (e.g., $1,000 each).
3. Write Unit Tests:
o Use a testing framework like JUnit (for Java), pytest (for Python),
or NUnit (for .NET).
o Implement tests based on the created test cases.
python
Copy code
def test_calculate_total_price():
assert calculate_total_price([10, 20, 30], [1, 2, 3]) == 140
assert calculate_total_price([], []) == 0
assert calculate_total_price([1000], [1]) == 1000
4. Execute Tests:
o Run the unit tests using the chosen framework and review the
results.
o Fix any issues identified during testing.
5. Review and Refactor:
o Based on test results, refactor the function if needed to address
any issues.
10. Code Coverage Calculations
i. Compute Coverage Metrics:
Assumptions (Example Code Snippet):
python
Copy code
def evaluate_score(score):
 if score >= 50:
print("Pass")
else:
print("Fail")
 Statement Coverage: Measures if each line of code is executed.
o Statement Coverage: 100% (Both branches of the if-else are
executed by provided test cases.)
 Decision Coverage: Measures if each decision point has been evaluated
to both true and false.
o Decision Coverage: 100% (Test cases cover both score >= 50 as
true and false.)
 Path Coverage: Measures if all possible paths through the code are
executed.
o Path Coverage: 100% (Since there's only one decision, both paths
are covered.)
ii. Additional Test Cases for 100% Coverage:
For more complex code snippets, you might need additional test cases to cover
all possible paths and decision points. For the given example, the test cases
provided already

### 11. Examination Scenarios

**i. Valid Equivalent Values for Passing the Exam**:

- **Range**: 18 to 40 marks.
- **Examples**: 18, 25, 35, 40.
**ii. Importance of Equivalence Partitioning Testing**:
- **Definition**: Equivalence partitioning divides input data into valid and
invalid partitions to reduce the number of test cases while ensuring coverage.
- **Purpose**: Helps in identifying representative test cases from each
partition, improving test efficiency, and reducing redundancy.
- **Impact on Quality**: Ensures that all input scenarios are tested, which
enhances software reliability and robustness.

**iii. Boundary Analysis and Equivalence Partitioning**:

- **Hand-in-Hand Approach**:
- **Boundary Analysis**: Focuses on testing the edge values of partitions,
ensuring critical boundary conditions are handled.
- **Equivalence Partitioning**: Tests typical values within each partition,
ensuring overall coverage.
- **Justification**: Combining both methods ensures comprehensive testing,
covering both typical and edge cases, leading to higher software quality.

### 12. Coverage Analysis for `evaluate_performance(score)`

**i. Coverage Computation**:

- **Statement Coverage**:
- **Test Cases**: `score = 85`, `score = 40`.
- **Statements Covered**: 1, 2, 3, 4, 5 (all statements are executed).

- **Decision Coverage**:
- **Decision Points**:
- `score >= 90` (False for `score = 85`)
 - `score >= 75` (True for `score = 85`, False for `score = 40`)
- `score >= 50` (True for `score = 85`, True for `score = 40`)
- **Test Cases**: Both `score = 85` and `score = 40` cover all decision
outcomes.

- **Path Coverage**:
- **Paths Covered**:
- Path 1: `score >= 90` is False, `score >= 75` is True, `score >= 50` is True.
- Path 2: `score >= 90` is False, `score >= 75` is False, `score >= 50` is True.
- Paths covered by provided test cases are sufficient for 100% path coverage.

**ii. Additional Test Cases for 100% Coverage**:

- **For 100% Statement Coverage**: Already achieved.
- **For 100% Decision Coverage**: Additional test case for `score >= 90` (e.g.,
`score = 95`).
- **For 100% Path Coverage**: Additional test case for `score < 50` (e.g., `score
= 30`).

### 13. Path Testing Explanation

**Purpose**:
- **Objective**: Ensures that all possible execution paths in a program are
tested to verify correct behavior and uncover potential issues.
- **Focus**: Identifies logical paths and verifies that each path produces
expected results.

**Strategies**:
1. **Identify Paths**: Determine all possible paths through the code based on
conditional statements and loops.
2. **Create Test Cases**: Develop test cases for each path to ensure complete
coverage.
3. **Automate Testing**: Use automated tools to run extensive path tests and
manage complex paths efficiently.
4. **Integrate with Workflow**: Include path testing in the testing phase of the
development lifecycle, ensuring it complements other testing methods like unit
and integration testing.

**Path Testing Example**:

```plaintext
Read A
Read B
IF A+B > 50 THEN
Print "Large"
ENDIF
IF A+B < 50 THEN
Print "Small"
ENDIF
```
- **Paths**:
1. **A+B > 50**: Executes "Large", skips "Small".
2. **A+B < 50**: Executes "Small", skips "Large".
3. **A+B == 50**: Executes neither "Large" nor "Small".

### 14. Test Cases for Age in Registration Form

**Equivalence Partitioning**:
- **Valid Partition**: Ages between 18 and 60.
- **Test Cases**: 18, 30, 60.
- **Invalid Partitions**: Ages below 18 or above 60.
- **Test Cases**: 17, 61.

**Boundary Analysis**:
- **Lower Boundary**: 18 (inclusive), 17 (exclusive).
- **Upper Boundary**: 60 (inclusive), 61 (exclusive).
- **Test Cases**: 18, 17, 60, 61.

### 15. Robust Configuration Management Process

**Steps**:
1. **Document Configuration Items**: Ensure all items are documented with
detailed descriptions.
2. **Implement Configuration Management Tools**: Use tools like Git for
version control and configuration management.
3. **Establish Change Control Procedures**: Define processes for proposing,
reviewing, and approving changes.
4. **Maintain Configuration Baselines**: Regularly update and maintain
baselines to track changes.
5. **Conduct Regular Audits**: Perform audits to ensure documentation and
configurations are up-to-date and accurate.
6. **Training and Communication**: Educate team members on configuration
management practices and importance.

### 16. Common Challenges in Software Maintenance

1. **Legacy Code**: Difficulty in understanding and modifying old code due to
lack of documentation or outdated technology.
2. **Bug Fixing**: Identifying and fixing bugs without introducing new issues
can be complex.
3. **Compatibility Issues**: Ensuring compatibility with new hardware,
software, or operating systems.
4. **Changing Requirements**: Adapting to new or evolving requirements
while maintaining system stability.
5. **Resource Constraints**: Limited resources or budget affecting the ability
to perform comprehensive maintenance.
6. **Technical Debt**: Accumulated technical debt requiring refactoring or
updates to improve code quality.

### 17. Type of Maintenance and Steps to Address Issues

**Type of Maintenance**:
- **Adaptive Maintenance**: This type involves making changes to the
software to adapt it to new environments, such as new versions or
configurations. Since users are facing issues with new features, it's likely that
the software needs adjustments to ensure compatibility and correct
functionality.

**Steps to Address Issues**:

1. **Issue Identification**:
- **Gather Feedback**: Collect detailed reports from users experiencing
issues.
 - **Replicate Issues**: Attempt to reproduce the problems in a controlled
environment.

2. **Analyze Problems**:
- **Code Review**: Examine recent changes to identify potential causes.
- **Check Compatibility**: Ensure that new features are compatible with
existing systems and configurations.

3. **Develop Fixes**:
- **Implement Corrections**: Modify the code or configuration to resolve
identified issues.
- **Test Fixes**: Conduct thorough testing of the fixes to ensure they resolve
the problems without introducing new ones.

4. **Deploy Updates**:
- **Release Patches**: Deploy the corrected code or configuration to users.
- **Monitor Performance**: Track the system post-deployment to ensure
that the issues are resolved and no new problems arise.

5. **Documentation and Feedback**:

- **Update Documentation**: Revise any relevant documentation to reflect
changes made.
- **Collect User Feedback**: Follow up with users to ensure that their issues
have been resolved and gather feedback for further improvements.

### 18. Key Benefits of Reengineering an Existing Software System

1. **Improved Performance**: Enhances system performance by optimizing

code and updating technologies.
2. **Enhanced Functionality**: Adds new features or improves existing ones to
meet current business needs.
3. **Better Maintainability**: Refactors code to make it more readable and
easier to maintain.
4. **Increased Reliability**: Reduces system defects and improves overall
reliability.
5. **User Experience**: Updates the user interface and experience to meet
modern standards and user expectations.
6. **Cost Efficiency**: May reduce long-term maintenance costs by addressing
technical debt and outdated components.

### 19. Steps Involved in the Software Reengineering Process

1. **Assessment and Planning**:

- **Evaluate Existing System**: Analyze the current system’s architecture,
code, and documentation.
- **Define Objectives**: Identify goals for reengineering, such as improving
performance or adding new features.

2. **Reverse Engineering**:
- **Extract Design and Code**: Deconstruct the existing system to
understand its architecture and functionality.
- **Document Findings**: Create detailed documentation of the current
system’s design and code.

3. **Redesign**:
- **Develop New Architecture**: Design a new system architecture based on
the analysis and objectives.
- **Create a Prototype**: Build a prototype to validate the new design
concepts.
4. **Reconstruction**:
- **Implement Changes**: Rewrite or modify the code according to the new
design.
- **Integrate New Features**: Add or improve functionalities as defined in
the objectives.

5. **Testing**:
- **Conduct Thorough Testing**: Test the reengineered system to ensure it
meets the new requirements and performs well.
- **Validate with Users**: Gather feedback from end-users to ensure the
system meets their needs.

6. **Deployment**:
- **Deploy the Reengineered System**: Roll out the updated system to users.
- **Monitor and Support**: Monitor the system for any issues and provide
support as needed.

7. **Documentation and Training**:

- **Update Documentation**: Revise system documentation to reflect
changes.
- **Train Users**: Provide training for users on the new features and
changes.

### 20. Distinguishing Software Reengineering from Software Maintenance

**Software Reengineering**:
- **Objective**: Involves redesigning and reconstructing a software system to
improve its performance, functionality, or maintainability. It is a more
comprehensive process that often includes significant changes or updates to
the system's architecture.
- **Scope**: Focuses on substantial modifications, such as refactoring code,
redesigning architecture, or adding new features.
- **Outcome**: Results in a redefined system that may differ significantly from
the original in structure and functionality.

**Software Maintenance**:
- **Objective**: Involves making incremental changes to a software system to
correct defects, adapt to new environments, or improve performance without
altering its core architecture. It is typically a continuous process that maintains
and improves the existing system.
- **Scope**: Includes activities such as bug fixing, minor updates, and
adaptation to new environments or requirements.
- **Outcome**: Maintains or slightly enhances the existing system without
fundamentally altering its design or structure.

**Key Differences**:
- **Reengineering** involves significant redesign and restructuring, while
**maintenance** focuses on incremental improvements and corrections.
- **Reengineering** is often triggered by major shifts in requirements or
technology, whereas **maintenance** addresses ongoing operational issues
and minor updates.
Unit 4:
Risk = some adverse circumstance that may happen and affect negatively
the project, the product, and/or the business
▶ Categories of risk:
▶ Project risks
▶ Product risks
▶ Business risks
Risk management means anticipating risks and preparing plans to reduce their
effect

Risk analysis:
Estimate risk probability:
▶ Very low (< 10%)
▶ Low (10-25%)
▶ Moderate (25-50%)
▶ High (50-75%)
▶ Very high (> 75%)
Establish risk seriousness:
▶ Insignificant
▶ Tolerable
▶ Serious
▶ Catastrophic

Project portfolio management

The concerns of project portfolio management include:
 Evaluating proposals for projects
 Assessing the risk involved with projects
 Deciding how to share resources between projects
 Taking account of dependencies between projects
 Removing duplication between projects
  Checking for gaps

There are three elements to PPM:
1. Project portfolio definition

 Create a central record of all projects within an organization

 Must decide whether to have ALL projects in the repository or, say, only ICT
projects

 Note difference between new product development (NPD) projects and

renewal projects e.g. for process improvement
2. Project portfolio management
Actual costing and performance of projects can be recorded and assessed
3. Project portfolio optimization
Information gathered above can be used to achieve better balance of projects e.g.
some that are risky but potentially very valuable balanced by less risky but less valuable
projects
You may want to allow some work to be done outside the portfolio e.g. quick fixes
### 1. Impact of Poor People Management on Project Failure

**Impact Analysis**:
- **Team Dynamics**: Ineffective people management can disrupt team
cohesion, leading to miscommunication and lack of collaboration. For instance,
in the case of the FBI's Virtual Case File project, poor communication and
unclear roles led to significant delays and a failed project.
- **Conflict Management**: Unresolved conflicts among team members can
escalate and derail project progress. For example, in the healthcare.gov launch,
internal conflicts and blame-shifting among contractors contributed to the
project's troubled rollout.
- **Communication**: Poor communication can result in misalignment
between team members and stakeholders, impacting project goals. The UK’s
National Health Service (NHS) IT project faced issues due to poor
communication and unclear expectations.

**Actionable Strategies**:
1. **Enhance Communication**: Implement regular team meetings, updates,
and feedback sessions to ensure transparency and alignment.
2. **Conflict Resolution**: Develop a clear conflict resolution process and
provide training on effective conflict management techniques.
3. **Foster Team Building**: Organize team-building activities to strengthen
relationships and improve collaboration.
4. **Define Roles Clearly**: Clearly define and communicate roles and
responsibilities to prevent overlaps and misunderstandings.
5. **Monitor Team Dynamics**: Regularly assess team dynamics and address
issues proactively through coaching and mentoring.

### 2. Risk Prioritization and Management

**Prioritization**:
- **Impact and Likelihood Matrix**: Categorize risks based on their potential
impact and likelihood. Use a risk matrix to classify risks into categories such as
high, medium, or low risk.
- **Example**: A risk with high impact and high likelihood (e.g., critical
technology failure) should be prioritized over a risk with low impact and low
likelihood (e.g., minor scope creep).

**Risk Strategies**:
1. **Risk Avoidance**: Alter plans to avoid the risk. Example: Use proven
technologies to avoid the risk of technology failure.
2. **Risk Mitigation**: Implement measures to reduce the risk’s impact or
likelihood. Example: Regularly update and test backup systems.
3. **Risk Transfer**: Share the risk with third parties, such as through
insurance or outsourcing. Example: Outsource non-core functions to
specialized vendors.
4. **Risk Acceptance**: Acknowledge the risk and prepare contingency plans.
Example: Prepare for potential delays with buffer time in the project schedule.

### 3. Key Performance Indicators (KPIs) and Metrics

**KPIs and Metrics**:
1. **Schedule Performance Index (SPI)**: Measures the efficiency of time
utilization. SPI = Earned Value (EV) / Planned Value (PV).
2. **Cost Performance Index (CPI)**: Measures cost efficiency. CPI = EV /
Actual Cost (AC).
3. **Project Progress**: Percentage of completed tasks compared to the total
tasks.
4. **Defect Density**: Number of defects per unit of code. Indicates code
quality.
5. **Customer Satisfaction**: Feedback from stakeholders and end-users to
assess project success from a user perspective.

### 4. Key Activities for Successful Project Delivery

**Activities**:
1. **Project Planning**:
- **Example**: Develop a detailed project plan with timelines, milestones,
and resource allocation.
- **Contribution**: Provides a roadmap for project execution and helps in
managing scope, schedule, and resources effectively.

2. **Execution**:
- **Example**: Oversee daily project activities, ensuring tasks are completed
as per the plan.
- **Contribution**: Ensures that project work is performed according to the
plan and adjusts as necessary.

3. **Risk Management**:
- **Example**: Identify potential risks and implement mitigation strategies.
 - **Contribution**: Minimizes the impact of risks on project objectives.

4. **Team Coordination**:
- **Example**: Facilitate communication and collaboration among team
members.
- **Contribution**: Ensures that team members work together effectively,
enhancing productivity and morale.

5. **Monitoring and Control**:

- **Example**: Track project performance against KPIs and adjust plans as
needed.
- **Contribution**: Keeps the project on track and ensures timely delivery.

### 5. Importance of Software Project Management

**Definition**:
- **Software Project Management** involves planning, organizing, and
overseeing software projects to ensure successful completion within scope,
time, and budget constraints.

**Significance**:
1. **Ensures Alignment**: Ensures that the project aligns with business goals
and stakeholder expectations.
2. **Manages Risks**: Identifies and mitigates risks to prevent project failures.
3. **Optimizes Resources**: Allocates resources efficiently to maximize
productivity and minimize waste.
4. **Controls Scope and Changes**: Manages scope changes to prevent scope
creep and ensure project objectives are met.
5. **Enhances Communication**: Facilitates effective communication among
stakeholders, team members, and other involved parties.

### 6. Key Principles and Practices for New Project Managers

**Principles**:
1. **Clear Objectives**: Define clear and achievable project goals and
objectives.
2. **Structured Planning**: Develop detailed project plans, including scope,
schedule, and resource plans.
3. **Effective Communication**: Maintain open and regular communication
with stakeholders and team members.
4. **Risk Management**: Identify, assess, and manage risks throughout the
project lifecycle.
5. **Monitoring and Control**: Track project progress and make adjustments
as needed to stay on track.

**Practices**:
1. **Use of Project Management Tools**: Employ tools like Gantt charts,
Kanban boards, and project management software for planning and tracking.
2. **Regular Status Meetings**: Conduct frequent status meetings to review
progress and address issues.
3. **Documentation**: Maintain comprehensive documentation to track
changes, decisions, and progress.

### 7. Estimating Effort for Software Development Projects

**Methods**:
1. **Expert Judgment**: Seek estimates from experienced team members or
industry experts based on their knowledge of similar projects.
2. **Analogous Estimating**: Use data from previous, similar projects to
estimate effort.
3. **Parametric Estimating**: Use statistical relationships between historical
data and project variables (e.g., lines of code) to estimate effort.
4. **Bottom-Up Estimating**: Break the project into smaller tasks, estimate
the effort for each task, and aggregate these estimates.
5. **Function Point Analysis**: Measure the functionality delivered to the user
and estimate effort based on function points.

**Why**:
- **Accuracy**: Combining different methods provides a more accurate and
reliable estimate.
- **Validation**: Cross-checking estimates helps validate assumptions and
refine planning.

### 8. Utilizing Project Management Tools for Remote Teams

**Strategies**:
1. **Communication Tools**:
- **Slack/Teams**: Use for real-time messaging and creating channels for
different teams or projects.
- **Zoom/Google Meet**: Facilitate video conferencing for meetings across
time zones.

2. **Collaboration Tools**:
- **Asana/Trello/JIRA**: Track tasks, assign responsibilities, and manage
workflows. Utilize boards and task lists to keep everyone updated.
 - **Google Drive/Dropbox**: Share and collaborate on documents and files.

3. **Project Management Tools**:

- **Microsoft Project/Smartsheet**: Develop and share project plans,
timelines, and milestones. Ensure all team members have access to the latest
updates.

4. **Time Zone Management**:

- **World Time Buddy/Time Zone Converter**: Schedule meetings and
deadlines considering different time zones.
- **Integrated Calendars**: Use shared calendars to avoid scheduling
conflicts and keep track of important dates.

5. **Regular Check-ins**:
- **Daily Stand-ups**: Hold brief daily meetings to discuss progress and
address any issues.
- **Weekly Syncs**: Schedule more in-depth weekly meetings to review
progress and plan the upcoming week.

### 9. Conducting a Feasibility Study

**Steps**:
1. **Technical Feasibility**:
- **Assess Technology**: Evaluate whether the current technology can meet
project requirements.
- **Example**: Verify if the existing infrastructure supports the new
software's technical demands.

2. **Economic Feasibility**:
 - **Cost-Benefit Analysis**: Compare the projected costs with the potential
benefits to determine if the project is financially viable.
- **Example**: Calculate development costs, maintenance costs, and
potential revenue or cost savings.

3. **Operational Feasibility**:
- **Resource Availability**: Ensure that the organization has the necessary
resources, including personnel and expertise.
- **Example**: Assess if the team has the skills required for the project or if
additional training is needed.

4. **Legal Feasibility**:
- **Compliance**: Check if the project complies with legal and regulatory
requirements.
- **Example**: Ensure that the software adheres to data protection
regulations.

5. **Schedule Feasibility**:
- **Timeline**: Determine if the project can be completed within the desired
timeframe.
- **Example**: Create a project schedule to assess if deadlines are realistic.

### 10. Strategies for Developing and Adhering to a Realistic Project Schedule

**Strategies**:
1. **Define Clear Milestones**:
- **Breakdown Tasks**: Divide the project into smaller, manageable tasks
with clear milestones.
- **Example**: Set milestones for key deliverables and review points.
2. **Estimate Realistically**:
- **Use Historical Data**: Base time estimates on data from similar past
projects.
- **Example**: Apply past project durations to estimate task completion
times.

3. **Buffer Time**:
- **Include Contingency**: Add buffer time to account for unforeseen delays.
- **Example**: Allocate 10-15% additional time to critical tasks.

4. **Regular Monitoring**:
- **Track Progress**: Use project management tools to monitor progress and
adjust the schedule as needed.
- **Example**: Update the Gantt chart regularly to reflect actual progress.

5. **Adjust Plans**:
- **Adapt to Changes**: Be flexible and revise the schedule if necessary
based on progress and feedback.
- **Example**: Reallocate resources or adjust deadlines if project scope
changes.

### 11. Identifying Risks in Software Development

**Risk Identification**:
1. **Project Risks**:
- **Scope Creep**: Changes or additions to project scope without
adjustments to time, cost, and resources.
 - **Example**: A client requests new features mid-project that impact the
timeline.

2. **Product Risks**:
- **Technical Failures**: Issues with software performance or integration.
- **Example**: Incompatibility with existing systems or critical bugs.

3. **Business Risks**:
- **Regulatory Compliance**: Failure to meet legal and regulatory
requirements.
- **Example**: Non-compliance with financial data protection regulations.

**Steps**:
1. **Risk Workshops**: Conduct workshops with stakeholders to identify
potential risks.
2. **Risk Assessments**: Use tools like SWOT analysis or risk checklists to
evaluate risks.

### 12. Prioritizing Risks and Building Strategies

**Prioritization**:
1. **Risk Matrix**: Use a matrix to evaluate risks based on their impact and
likelihood.
2. **Example**: High impact and high likelihood risks should be addressed
first.

**Strategies**:
1. **Mitigation**: Develop strategies to reduce the impact or likelihood of
high-priority risks.
- **Example**: Implement robust testing procedures to mitigate technical
failures.

2. **Transfer**: Shift the risk to another party through contracts or insurance.

- **Example**: Use third-party services for compliance and security.

3. **Acceptance**: Accept the risk when the cost of mitigation is higher than
the impact.
- **Example**: Prepare contingency plans for potential delays.

### 13. Key Activities for Project Success

**Activities**:
1. **Project Planning**:
- **Example**: Develop a detailed project plan with scope, schedule, and
resources.
- **Contribution**: Provides a roadmap and helps manage expectations and
deliverables.

2. **Execution**:
- **Example**: Oversee daily activities and ensure tasks are completed on
time.
- **Contribution**: Ensures that the project stays on track and meets
deadlines.

3. **Risk Management**:
 - **Example**: Identify, assess, and address risks proactively.
- **Contribution**: Reduces the impact of potential issues on project
success.

4. **Team Coordination**:
- **Example**: Facilitate communication and collaboration among team
members.
- **Contribution**: Enhances team productivity and addresses issues
promptly.

5. **Monitoring and Control**:

- **Example**: Track project progress and make adjustments as needed.
- **Contribution**: Ensures that the project adheres to the plan and
addresses deviations.

### 14. Impact of Poor People Management

**Impact**:
- **Case Studies**:
- **Healthcare.gov**: Poor management led to delays and a failed launch due
to lack of coordination and conflict among contractors.
- **FBI’s Virtual Case File**: Miscommunication and unclear roles resulted in
project failure and wasted resources.

**Strategies**:
1. **Improve Communication**: Implement regular updates and feedback
sessions.
2. **Conflict Resolution**: Establish clear conflict resolution processes.
3. **Team Building**: Organize team-building activities to enhance
collaboration.
4. **Define Roles**: Clearly define and communicate team roles and
responsibilities.

### 15. Creating a Gantt Chart

**Steps**:
1. **List Tasks**: Identify all project tasks and milestones.
2. **Set Durations**: Estimate the time required for each task.
3. **Define Dependencies**: Determine which tasks depend on others.
4. **Create Chart**: Use tools like Microsoft Project or Excel to create a visual
representation.
5. **Update Regularly**: Adjust the chart as the project progresses.

**Key Information**:
- **Task Names**: List of all tasks and milestones.
- **Start and End Dates**: Timeline for each task.
- **Dependencies**: Relationships between tasks.
- **Progress**: Percentage completion of each task.

Unit 5:
ISO 9126 Software product quality
Attributes of software product quality

 External qualities i.e. apparent to the user of the deliverable

 Internal qualities i.e. apparent to the developers of the deliverables and the
intermediate products

Quality Models
It is a model of the software:
Constructed with the objective to describe, assess and/or predict quality.

 Popular models:

 Garvin’s model

 Boehm’s model

 ISO 9126

 Dromey’s Model

Using ISO 9126 quality standards – guidelines (development mode)

1. Judge the importance of each quality factor for the application
  for example, safety critical systems - reliability very important

 real-time systems - efficiency important

2. Select relevant external measurements within ISO 9126 framework for these qualities, for
example

 mean-time between failures for reliability

 response-time for efficiency

3. Map measurement onto ratings scale to show degree of user satisfaction – for example response
time

4. Identify the relevant internal measurements and the intermediate products in which they
would appear

 For example, at software design stage the estimated execution time for a
transaction could be calculated
### 1. ISO 9001 Framework Overview

**ISO 9001** is an international standard for Quality Management Systems (QMS) that
outlines a framework for ensuring consistent quality in products and services. It is designed
to help organizations improve their overall performance and meet customer expectations.
The core processes include:

1. **Leadership**:
- **Management Commitment**: Top management must demonstrate commitment to
the QMS, establish a quality policy, and set quality objectives.
- **Customer Focus**: Ensure that customer needs and expectations are met.

2. **Planning**:
- **Risk Management**: Identify and address risks and opportunities.
- **Quality Objectives**: Define clear and measurable quality objectives aligned with the
quality policy.
3. **Support**:
- **Resource Management**: Ensure adequate resources (human, infrastructure, and
environment) are provided.
- **Competence**: Ensure personnel are competent based on education, training, and
experience.

4. **Operation**:
- **Process Management**: Plan and control operational processes to ensure products
and services meet requirements.
- **Product Realization**: Manage product development and delivery processes.

5. **Performance Evaluation**:
- **Monitoring and Measurement**: Regularly monitor, measure, and analyze
performance to ensure compliance and identify areas for improvement.
- **Internal Audits**: Conduct audits to assess the effectiveness of the QMS.

6. **Improvement**:
- **Nonconformity and Corrective Action**: Address and correct nonconformities and
implement corrective actions.
- **Continual Improvement**: Continuously improve the QMS based on performance data
and feedback.

### 2. Comprehensive List of Interface Faults

1. **Inconsistent Data Formats**:

- **Description**: Mismatch in data formats between different systems or components.
- **Importance**: Can cause data corruption or errors during data exchange.

2. **Poor Error Handling**:

- **Description**: Insufficient error messages or lack of graceful degradation.
 - **Importance**: Can lead to user confusion and system instability.

3. **Compatibility Issues**:
- **Description**: Interface components are not compatible with different versions or
platforms.
- **Importance**: May prevent the software from functioning correctly across different
environments.

4. **Latency Problems**:
- **Description**: Delays in data transmission or processing between interfaces.
- **Importance**: Affects system performance and user experience.

5. **Security Vulnerabilities**:
- **Description**: Weaknesses in data transmission or access control mechanisms.
- **Importance**: Can lead to unauthorized access or data breaches.

6. **Inadequate Documentation**:
- **Description**: Poor or missing documentation for interface functionality.
- **Importance**: Hinders maintenance and integration efforts.

7. **Interface Misalignment**:
- **Description**: Mismatched expectations between interfacing components.
- **Importance**: Can cause functionality issues or data inconsistencies.

### 3. Quality Review Process Diagram

**Diagram**:

```
+---------------------+
| Planning Review |
+---------------------+
|
v
+---------------------+
| Requirement Review |
+---------------------+
|
v
+---------------------+
| Design Review |
+---------------------+
|
v
+---------------------+
| Code Review |
+---------------------+
|
v
+---------------------+
| Testing Review |
+---------------------+
|
v
+---------------------+
| Final Review |
+---------------------+
```
**Explanation**:
- **Planning Review**: Define the scope and objectives of the review.
- **Requirement Review**: Ensure requirements are complete and clear.
- **Design Review**: Evaluate design for feasibility and compliance with requirements.
- **Code Review**: Assess code quality and adherence to standards.
- **Testing Review**: Verify testing coverage and results.
- **Final Review**: Conduct a comprehensive review before release.

### 4. Incorporating ISO-9126 into Development Process

**ISO-9126** provides a model for evaluating software quality based on six key
characteristics. To incorporate it:

1. **Functionality**: Ensure the software meets specified requirements and performs

intended functions.
2. **Reliability**: Implement tests to verify the software operates consistently and recovers
from failures.
3. **Usability**: Design user-friendly interfaces and conduct usability testing.
4. **Efficiency**: Optimize performance metrics like response time and resource usage.
5. **Maintainability**: Write clean, modular code and provide comprehensive
documentation.
6. **Portability**: Test software across different environments to ensure compatibility.

**Implementation**:
- **Define Metrics**: Establish metrics for each characteristic.
- **Integrate into Development**: Include quality assessments in design, development, and
testing phases.
- **Continuous Review**: Regularly evaluate and adjust based on feedback.

### 5. Establishing Continuous Improvement Cycle

**Strategies**:
1. **Regular Assessments**:
- Conduct periodic reviews of processes and product quality.
- Use tools like KPIs and performance metrics to gauge effectiveness.

2. **Feedback Mechanisms**:
- Implement channels for team and customer feedback.
- Use feedback to identify areas for improvement.

3. **Training and Development**:

- Provide ongoing training for team members.
- Update skills and knowledge to keep up with industry best practices.

4. **Process Refinement**:
- Analyze current processes and identify inefficiencies.
- Implement changes and monitor their impact.

5. **Benchmarking**:
- Compare performance against industry standards or competitors.
- Use insights to drive enhancements.

### 6. Six Key Quality Characteristics of ISO-9126

1. **Functionality**:
- **Definition**: The degree to which the software meets the specified requirements.
- **Application**: Verify all features work as intended and meet user needs.

2. **Reliability**:
- **Definition**: The ability of the software to maintain its performance under specified
conditions.
 - **Application**: Test for stability and fault tolerance.

3. **Usability**:
- **Definition**: The ease with which users can learn and operate the software.
- **Application**: Evaluate user interfaces and conduct usability tests.

4. **Efficiency**:
- **Definition**: The performance of the software in terms of resource usage and
response time.
- **Application**: Measure performance and optimize resource utilization.

5. **Maintainability**:
- **Definition**: The ease with which the software can be modified to correct defects or
add features.
- **Application**: Assess code modularity and documentation quality.

6. **Portability**:
- **Definition**: The ability of the software to operate in different environments.
- **Application**: Test across various platforms and configurations.

### 7. ISO 9001 Framework Overview (Repeated)

Already provided above in item 1.

If you need further details or additional assistance, feel free to ask!

### 8. Comprehensive List of Interface Faults

1. **Data Mismatch**:
 - **Description**: Discrepancies in data formats or types between interfacing systems.
- **Importance**: Can lead to data corruption or application errors, affecting functionality.

2. **Communication Failures**:
- **Description**: Issues in message exchange, such as lost or delayed messages.
- **Importance**: Disrupts the interaction between components, leading to system
instability.

3. **Protocol Violations**:
- **Description**: Deviations from expected communication protocols or standards.
- **Importance**: Can cause incompatibility and data exchange issues.

4. **Authentication and Authorization Issues**:

- **Description**: Problems with verifying user identities or permissions across interfaces.
- **Importance**: Can lead to security breaches or unauthorized access.

5. **Performance Bottlenecks**:
- **Description**: Slow response times or resource contention in interface operations.
- **Importance**: Degrades system performance and user experience.

6. **Error Handling Deficiencies**:

- **Description**: Inadequate handling of errors or exceptions during data exchange.
- **Importance**: Results in unhandled exceptions or crashes.

7. **Compatibility Issues**:
- **Description**: Incompatibility with different versions of interfacing components.
- **Importance**: Prevents proper integration and operation.

8. **Documentation Gaps**:
- **Description**: Missing or unclear documentation for interface specifications.
 - **Importance**: Hinders development, maintenance, and troubleshooting.

9. **Security Vulnerabilities**:
- **Description**: Weaknesses in interface security measures.
- **Importance**: Exposes the system to potential attacks or data breaches.

### 9. Ensuring and Validating Software Reliability

1. **Implement Fault Tolerance**:

- **Measures**: Design the software to handle faults gracefully, such as redundant
systems or failover mechanisms.
- **Testing**: Simulate faults and verify system recovery.

2. **Conduct Reliability Testing**:

- **Measures**: Perform stress testing, load testing, and longevity testing.
- **Testing**: Validate performance under various conditions and over extended periods.

3. **Monitor System Behavior**:

- **Measures**: Use monitoring tools to track system performance and reliability.
- **Testing**: Analyze logs for error patterns and system behavior.

4. **Perform Failure Mode Analysis**:

- **Measures**: Identify potential failure points and their impact.
- **Testing**: Test failure scenarios to ensure appropriate responses.

5. **Implement Redundancy**:
- **Measures**: Use redundant systems or components to ensure continued operation.
- **Testing**: Validate redundancy mechanisms through failover tests.

### 10. Quality Review Process Diagram

**Diagram**:

```
+--------------------------+
| Planning & Preparation |
+--------------------------+
|
v
+--------------------------+
| Requirements Review |
+--------------------------+
|
v
+--------------------------+
| Design Review |
+--------------------------+
|
v
+--------------------------+
| Code Review |
+--------------------------+
|
v
+--------------------------+
| Testing Review |
+--------------------------+
|
v
+--------------------------+
| Final Review |
+--------------------------+
```

**Explanation**:
- **Planning & Preparation**: Define the scope and objectives of the review.
- **Requirements Review**: Ensure requirements are complete and understood.
- **Design Review**: Evaluate the design for compliance with requirements.
- **Code Review**: Assess code quality and adherence to standards.
- **Testing Review**: Verify that testing is thorough and results are as expected.
- **Final Review**: Conduct a comprehensive review before release.

### 11. Ensuring Compliance with Data Security Regulations

1. **Identify Relevant Regulations**:

- **Steps**: Determine applicable data security regulations (e.g., GDPR, HIPAA).
- **Action**: Review and understand regulatory requirements.

2. **Implement Security Controls**:

- **Steps**: Apply encryption, access control, and secure data storage.
- **Action**: Configure security settings and mechanisms.

3. **Conduct Security Audits**:

- **Steps**: Perform regular security audits and vulnerability assessments.
- **Action**: Identify and address security gaps.

4. **Establish Data Protection Policies**:

- **Steps**: Develop and enforce data protection policies.
 - **Action**: Ensure policies are followed and updated as needed.

5. **Provide Security Training**:

- **Steps**: Train staff on data security practices and regulations.
- **Action**: Conduct regular training sessions and updates.

### 12. Ensuring Software Meets Security Quality Attributes

1. **Define Security Requirements**:

- **Steps**: Specify security requirements based on regulations and best practices.
- **Action**: Document requirements and ensure they are integrated into the
development process.

2. **Conduct Threat Modeling**:

- **Steps**: Identify potential threats and vulnerabilities.
- **Action**: Analyze and address identified threats.

3. **Implement Security Testing**:

- **Steps**: Perform security testing such as penetration testing and static code analysis.
- **Action**: Validate the effectiveness of security measures.

4. **Review and Update Security Measures**:

- **Steps**: Regularly review and update security measures based on new threats and
vulnerabilities.
- **Action**: Implement changes as needed.

### 13. Ensuring Portability Using ISO-9126

1. **Define Portability Requirements**:

- **Steps**: Identify and document the target platforms and environments.
 - **Action**: Ensure requirements are met during development.

2. **Implement Platform Independence**:

- **Steps**: Use cross-platform development tools and frameworks.
- **Action**: Ensure compatibility with various platforms.

3. **Conduct Portability Testing**:

- **Steps**: Test the application on different operating systems and devices.
- **Action**: Validate functionality and performance across platforms.

4. **Document Portability Issues**:

- **Steps**: Identify and document any portability issues encountered.
- **Action**: Address and resolve issues to ensure compatibility.

### 14. Introducing and Enforcing Quality Standards

1. **Educate the Team**:

- **Steps**: Provide training on industry quality standards and best practices.
- **Action**: Conduct workshops and training sessions.

2. **Define Quality Metrics**:

- **Steps**: Establish clear quality metrics and standards.
- **Action**: Communicate metrics to the team and integrate them into the development
process.

3. **Implement Quality Assurance Processes**:

- **Steps**: Develop and enforce QA processes and procedures.
- **Action**: Monitor adherence and provide feedback.

4. **Conduct Regular Reviews**:

 - **Steps**: Perform regular reviews of work products and processes.
- **Action**: Identify and address any deviations from standards.

### 15. Quality Assurance Practices for Client Assurance

1. **Define Quality Standards**:

- **Steps**: Establish and document quality standards and criteria.
- **Action**: Ensure alignment with client expectations.

2. **Implement QA Processes**:
- **Steps**: Develop and follow QA processes, including reviews, testing, and inspections.
- **Action**: Ensure rigorous testing and validation.

3. **Provide Documentation and Reports**:

- **Steps**: Prepare detailed documentation and test reports.
- **Action**: Share with clients to demonstrate compliance.

4. **Conduct Client Reviews**:

- **Steps**: Schedule and conduct reviews with clients.
- **Action**: Address any client concerns and incorporate feedback.

5. **Continuous Improvement**:
- **Steps**: Implement feedback and improve processes.
- **Action**: Demonstrate commitment to quality and client satisfaction.

Feel free to ask if you need more details or further assistance!