Week 1

1. An institution named “A” specializes in training people related to web designing/development

and provides a training program of 2 months costing Rs 25,000. Another institution named “B”
is providing a training course related to Software Engineering for Rs 3,00,000 (for 8 months).
Suppose you are looking forward to working as a programmer/developer in the future. Which
course do you think seems reasonable to join and state your reasons with the necessary
explanation.

2. Discuss 8 attributes of good software in separate points.

Usability
Functionality
Correctness
Maintainability
Reliability
Flexibility
Scalability
Testability
Efficiency
Security

3. With the help of the internet, explore some instances of Software Crisis in the last 10 years and
try to figure out the underlying problems behind that. List those possible reasons.
The term "software crisis" refers to the challenges and failures encountered in software
development, leading to significant issues such as project delays, cost overruns, or complete
project failures. Over the last decade, several notable instances have highlighted these crises.
Here are some key examples and the underlying problems behind them:

Healthcare.gov Launch (2013):

Problems: The website, intended to serve millions of Americans for health insurance enrollment,
faced numerous technical issues, crashes, and slow performance upon launch.
Underlying Reasons:
Poor Project Management: Lack of coordination and oversight among multiple contractors.
Insufficient Testing: Inadequate testing before the launch, leading to undiscovered bugs.
Scope Creep: Frequent changes in requirements leading to rushed development.
Scalability Issues: The system was not adequately designed to handle the expected load.

TCS' National Health Service (NHS) Project (2013-2014):

Problems: Tata Consultancy Services (TCS) was contracted to create a patient care records
system, but the project was eventually abandoned after significant delays and cost overruns.
Underlying Reasons:
Complex Requirements: Difficulty in aligning the system with the diverse needs of various NHS
trusts.
Lack of Stakeholder Engagement: Insufficient involvement of end-users and healthcare
professionals in the development process.
Technological Challenges: Incompatibility with existing NHS systems and data migration issues.

Volkswagen Emissions Software Scandal (2015):

Problems: Volkswagen was found to have installed software in diesel engines to manipulate
emissions tests, leading to legal, financial, and reputational damage.
Underlying Reasons:
Ethical Violations: Deliberate deceit in software design to circumvent regulations.
Management Pressure: Intense pressure to meet performance standards led to unethical
decisions.
Lack of Oversight: Insufficient regulatory oversight and internal controls.

Boeing 737 MAX Crashes (2018-2019):

Problems: Two fatal crashes involving the Boeing 737 MAX were attributed to issues with the
Maneuvering Characteristics Augmentation System (MCAS) software.
Underlying Reasons:
Inadequate Testing: Insufficient testing and simulation of the software under various flight
conditions.
Poor Communication: Lack of clear communication between Boeing and airlines regarding the
software and its functionalities.
Regulatory Failures: Lax oversight and certification processes by the Federal Aviation
Administration (FAA).

Equifax Data Breach (2017):

Problems: A massive data breach exposed the personal information of 147 million consumers
due to vulnerabilities in Equifax’s software.
Underlying Reasons:
Security Flaws: Failure to patch known vulnerabilities in software.
Poor Cybersecurity Practices: Inadequate security measures and monitoring.
Delayed Response: Slow response in identifying and addressing the breach.

Microsoft Windows 10 October Update (2018):

Problems: The update led to data loss for some users, causing significant disruptions and user
dissatisfaction.
Underlying Reasons:
Insufficient Testing: Inadequate testing of the update on different hardware configurations and
use cases.
User Feedback Neglect: Failure to heed feedback from early testers regarding issues.
Rushed Release: Pressure to meet release deadlines led to insufficient quality assurance.

Possible Reasons for Software Crises:

Poor Project Management:

Lack of clear goals and milestones.

Inadequate planning and resource allocation.

Insufficient Testing:

Rushed testing phases.

Inadequate test coverage and failure to identify critical bugs.

Communication Issues:

Poor communication between stakeholders, developers, and end-users.

Misalignment of expectations and requirements.

Scope Creep:

Frequent changes in requirements leading to increased complexity and delays.

Lack of proper change management processes.
Technological Challenges:
Incompatibility with existing systems.
Difficulties in integrating new technologies.

Security Flaws:

Failure to address known vulnerabilities.

Inadequate cybersecurity measures.

Ethical Violations:

Deliberate deceit or cutting corners to meet targets.

Lack of ethical guidelines and enforcement.

Regulatory and Oversight Failures:

Insufficient regulatory oversight.

Lax certification processes.
Week 2
1. Discuss an example or circumstance where the Information system is aiding the decision-
making.

Modern world is incomplete without information system. We rely on Information System on

every step of our life and while making any decision. One of a major example includes,
traditionally, when we had to travel somewhere or plan for a weekend getaway to some
mountains for hiking or trekking, we would rely on the local news. Now, due to the information
system we can view the detailed and up-to-date information of the weather to aid our decision
making.
Hyperlocal forecasts-The weather forecasting app provides specific information about the
specific planned location including hourly breakdowns of temperature, precipitation chance,
and wind speed.
Radar maps- Real-time visualization of rain or snow movement, allowing us to see if there are
any approaching storms that might disrupt out hike or trek.
Historical data- Average weather patterns of that particular area at that time of a year can be
viewed.
According to such information we can make decision about packing, knowing the exact
temperature of the location we it helps us to pack the appropriate amount of clothing for a
comfortable and safe hike or trek. If a heavy rain is predicted, we can reschedule the hike/trek
and choose alternative activity. The weather forecast helps us and warns us about the high wind
or storms, allowing us to decide if it’s safe to proceed with our hike/trek.

Extra answer:

Imagine a clothing store that uses a point-of-sale (POS) system. This system tracks every time
an item is sold. This data can then be used to generate reports that show which items are selling
well and which ones are not. Armed with this information, the store manager can make better
decisions about what to stock and how much to order.
For example, the reports might show that a particular style of jeans is selling very quickly,
while another style is sitting on the shelves. The manager can then decide to order more of the
popular jeans and reduce the amount of the unpopular style. This helps the store to avoid
stockouts and overstocking, both of which can be costly.
In this way, the information system provides the store manager with the data they need to make
informed decisions about inventory management. This can lead to increased sales, reduced
costs, and improved customer satisfaction.
2. Case Study:
A clothing brand is planning to conduct its business in the valley. It has planned to open 7
different outlets in various parts of the valley. Its main products are T-shirts (Round and V-
neck), Pants (Jeans, cotton), Shirts (winter-specific, summer-specific), and shoes (leather,
converse). Apart from the in-site sales, it is also trying to provide customers with the provision
to view products online and order with the availability of home delivery (not fully e-commerce-
based). From the systems perspective, describe and discuss the decisions to be made in the
domain of strategic, managerial, and operational control. What information would be needed
to make such decisions? Carrying out some sensible assumptions, list down some important
decisions to be taken in the above-mentioned domains and also the information needed that
help make those decisions.

1. Strategic Control:
o Location Selection:
▪ Decision: Choosing the best locations for the 7 outlets.
▪ Information Needed: Demographic data (population density,
income levels, lifestyle preferences) for various areas in the valley.
o Product Mix Strategy:
▪ Decision: Determining the right mix of T-shirts, pants, shirts, and
shoes.
▪ Information Needed: Market research on customer preferences,
seasonal trends, and competitor offerings.
o Pricing Strategy:
▪ Decision: Setting prices for different products.
▪ Information Needed: Cost data (production, distribution,
marketing), competitor pricing, and perceived value by customers.
2. Managerial Control:
o Inventory Management:
▪ Decision: How much inventory to stock at each outlet.
▪ Information Needed: Sales history, lead times, demand forecasts,
and storage capacity.
o Staffing Decisions:
▪ Decision: Hiring, scheduling, and training staff.
▪ Information Needed: Staff availability, workload, and skill sets.
o Promotions and Marketing:
▪ Decision: Planning promotions, advertising, and events.
▪ Information Needed: Marketing budget, customer segmentation,
and campaign effectiveness.
3. Operational Control:
o Order Fulfillment:
▪ Decision: Processing online orders and managing home deliveries.
▪ Information Needed: Real-time inventory levels, order tracking, and
delivery logistics.
 o Quality Control:
▪ Decision: Ensuring product quality meets standards.
▪ Information Needed: Inspection reports, customer feedback, and
returns data.
o Supply Chain Coordination:
▪ Decision: Managing relationships with suppliers.
▪ Information Needed: Supplier performance, lead times, and
contract terms.

Assumptions:

• The brand has access to reliable data on customer preferences and market
trends.
• The brand has a centralized information system to track sales, inventory, and
other relevant data.
Week 3
Discuss the aspects where the waterfall model is different from the Prototype model.
The Waterfall model is best suited for projects with well-understood requirements and low
likelihood of changes, while the Prototype model is ideal for projects where requirements are
not well-defined initially and user feedback is crucial to the development process.
Differences between the waterfall model and prototype model can be seen through following
point:
Development Process: Waterfall is linear and sequential, whereas Prototype is iterative and
incremental.
Requirements Gathering: Waterfall requires complete requirements upfront, while Prototype
gathers requirements iteratively.
Customer Involvement: Waterfall has limited customer involvement after requirements
gathering, while Prototype involves continuous customer feedback.
Flexibility: Waterfall is rigid, with changes being difficult to manage, whereas Prototype is
flexible and accommodates changes easily.
Risk Management: Waterfall can be risky if requirements are not well-understood initially,
while Prototype reduces risk by allowing early detection and correction of issues through
iterative feedback.

Explain with examples when incremental and iterative mode of development is preferred.
Advantage OF SPIRAL MODEL.
Incremental Development: In incremental development, the project is divided into small,
manageable modules (increments), and each module is developed and delivered independently.
The complete system is
built step by step by adding these increments.
Example: Consider developing an e-commerce website. Instead of developing the entire website
in one go, the project could be divided into increments such as user registration, product catalog,
shopping cart, payment processing, and order tracking. Each increment is developed and delivered
one at a time. For instance, the team might first develop and release the user registration
functionality, then move on to the product catalog, and so on.
When Preferred:
• When quick delivery of a functional product is required.
• When project funding or resource availability is incremental.
• When requirements are clear for initial increments but might evolve over time for later
increments.
Iterative Development: In iterative development, the project undergoes repeated cycles
(iterations) of development, where each iteration involves refining and expanding the system based
on feedback from the previous iteration. Each iteration produces a more refined version of the
product.
Example: Consider developing a new search engine. The first iteration might focus on basic search
capabilities, the second iteration could improve search algorithms and add advanced filters, and
the third iteration could enhance the user interface and add personalization features.
When Preferred:
• When requirements are not well understood at the beginning and are expected to evolve.
• When risk management is a priority, as iterations allow for regular assessment and
adaptation.
• When early feedback from users is critical to refining the system.

Advantages of the Spiral Model

The Spiral model combines elements of both incremental and iterative development while focusing
heavily on risk management. It is structured as a series of iterative cycles (or spirals) with each
cycle having four main phases: Planning, Risk Analysis, Development, and Evaluation.
Advantages:
Risk Management:
Each iteration begins with identifying and analyzing risks, which helps in mitigating potential
issues early in the development process.
This makes the Spiral model particularly suited for large, complex, and high-risk projects.
Flexibility and Adaptability:
The model accommodates changes in requirements and design. As each cycle includes a planning
phase, the project can adapt to changes based on stakeholder feedback and evolving requirements.
This flexibility helps in aligning the project with business goals and user needs over time.
Customer Feedback:
Frequent customer feedback is obtained at the end of each cycle, ensuring that the product meets
user expectations and requirements.
This continuous interaction with stakeholders improves the chances of delivering a successful
product.
Incremental Releases:
The model allows for incremental releases of the product, providing a partial but functional version
of the system early in the project lifecycle.
This helps in gaining user feedback and making necessary adjustments early on.
Systematic Approach:
The structured approach of the Spiral model ensures thorough documentation and adherence to a
disciplined process.Each phase of the cycle is well-defined, ensuring that critical aspects such as
requirements, design, and testing are systematically addressed.

The Spiral model is especially beneficial for projects where the requirements are complex, and the
risks are high, making it a preferred choice for aerospace, defense, and large-scale system projects.

1. Suppose are a software engineer on your software development team. What would you
recommend if you were to recommend the methodology for following the nature of
projects with reasoning?
a. The first project is a news portal site that requires member registration. Once the user
becomes a member, he is allowed to read the articles and make comments. He is pretty
much certain of the designs and has a clear-cut idea of the overall system that the client is
looking for and the client needs it prepared in a month. At the same time, he is working on
another project (details not necessary) simultaneously for which he has to attend frequent
meetings with the client and has a deadline within a few days.

ANSWER:
 For the news portal site with member registration, reading articles, and commenting
functionalities, I recommend using the Waterfall model. This model is ideal because the
project requirements are well-defined and unlikely to change. The client has a clear
understanding of the system and needs it completed within a month. The Waterfall model's
structured phases—Requirements, Design, Implementation, Verification, and
Maintenance—provide a clear and predictable path, ensuring that each phase is thoroughly
documented and completed before moving to the next. This sequential approach aligns well
with the project's short timeline and the engineer's need to manage time efficiently due to
simultaneous commitments.
Additionally, the Waterfall model reduces the need for frequent client interaction after the
initial requirements phase, which is beneficial given the engineer's need to attend frequent
meetings for another project. By following this model, the development team can focus on
delivering a reliable and well-documented system within the tight deadline. The structured
and disciplined approach of the Waterfall model helps in managing the project effectively,
ensuring that all predefined requirements are met without the complications of
accommodating changes mid-project.

b. Another project is an e-learning system that is very different from other existing e-learning
systems in Nepal. The client has the necessary scripts for all the course contents but is
reluctant to deliver content be it in an animated form or live video teaching form. There
are other numerous details that he must consider but cannot think of it right now. All he
knows is he is determined to own an e-learning system.
ANSWER:
For the e-learning system project, where the client has a vision but uncertain details and
content formats, the Prototype model is highly recommended. This approach is ideal for
projects with unclear and evolving requirements. The Prototype model allows the
development team to build initial prototypes based on basic requirements and gather
detailed feedback from the client. Through iterative refinement, the prototypes help in
clarifying requirements and solidifying the client's vision, ensuring that the final product
aligns with their needs. This method is particularly useful for exploring different content
delivery formats, such as animations and live videos, and making informed decisions based
on tangible prototypes.
The Prototype model facilitates frequent client interaction, providing a platform for
continuous feedback and adjustments. This flexibility is crucial for the client, who is
uncertain about numerous details but determined to develop a unique e-learning system.
By building and refining prototypes iteratively, the development team can manage risks
effectively and ensure that the evolving requirements are incorporated seamlessly. This
approach not only helps in delivering a tailored and high-quality system but also ensures
that the client is actively involved and satisfied with the progress at each stage.
Week 4
1. What are the three constraints that the project manager should concentrate on while
undertaking the project? Explain each of them.
The three constraints that a project manager should focus on are known as the triple constraints
or the project management triangle. They are:

• Scope: This refers to everything that is included (and excluded) from the project. It defines
the features, deliverables, and functionalities of the final product. A well-defined scope
ensures everyone is on the same page about what the project will achieve.

• Cost: This refers to the total financial resources required to complete the project. It includes
labor costs, materials, equipment, and any other expenses incurred during the project
lifecycle. Project managers need to manage the budget effectively to stay within financial
limitations.

• Time: This refers to the total duration required to complete the project. It involves setting
realistic deadlines, scheduling tasks, and managing dependencies between activities.
Meeting deadlines is crucial for project success and keeping stakeholders satisfied.

2. Scholar Academy is a school operating from the year of 2009. It is currently in need of a
School Management System to manage its school operations. The operations include both
academic and management (finance, RTE) related operations and they are looking for
an online system to manage all these operations.
Functions:
• Provision to register different types of users in the system (staff, teachers, students,
etc.
• Provision for students to choose the course and subjects.
• Provision for online enrollment by students themselves.
• Provision for tracking students’ attendance and generating attendance reports.
• Provision for students to see the fees pending and penalties.
• Provision for students to manage the library.
Given the chosen methodology is a Prototype, create a WBS Work Breakdown Structure
as a part of the preliminary scope development. WBS should demonstrate the breakdown
of tasks/activities of the overall project lifecycle.

The key difference between prototype methodology and other methodologies like Waterfall
or Agile lies in their approach to development and how they handle requirements. Here's a
breakdown of the Prototype methodology:

• Focuses on building a functional model with core functionalities first.

• Iterative process: gathers feedback on the prototype, refines it, and repeats.
• Advantages:
o Suitable for projects with unclear requirements or where user input is crucial.
o Reduces risk of development effort going in the wrong direction.
o Enables early user feedback and course correction.
• Disadvantages:
o May not be suitable for projects with well-defined requirements and deadlines.
o Can lead to scope creep if feedback introduces extensive change.
WBS Structure of Scholar Academy using the Prototype methodology:
Week 06:

The 4 P’s:

An effective software project management focuses on the 4 P’s.

• People
• Product
• Process
• Project
1. People
• All the people associated with the project.
• The Stakeholders
Senior Managers-who define the business issues.
Project Managers- plan, motivate and organize and control the practitioners.
Practitioners- Who deliver the technical skills.
Customers- who specify the requirements.
End Users- Who interact with the software.

For maximum effectiveness, the project team must be organized and managed, motivated.
Project Managers must ensure that there is proper collaboration between stakeholders and avoid
miscommunication.

2. Product

• Product Objectives and Scope must be established before project can be planned.
• At the same time, identifying alternative solutions, technical/management constraints.
• Scope (data, functions and behaviors characterizing the product) and objectives(goals what not
how) definition is a must.

3. Process
• Choosing a proper process model is a very important task.
• Selecting a suitable process model is necessary keeping in mind
 - the customers requesting the product and people who will do the work.
- the product characteristics.
- the project environment in which the software team works.
• Also adjusting the process as per need and necessity.

4. Project
• Project get into trouble when:
- Software people don’t understand the project needs.
- The product scope is poorly defined.
- Changes are managed poorly.
- Deadlines are unrealistic.
- Users are resistant.
- The project team lacks people with appropriate skills.
• Project Management is needed in every step and constraint need to be managed to minimize the
risks and ensure success of the project.

Gantt Chart:
• A Gantt Chart is a project management tool assisting in the planning and scheduling of projects
of all sizes.
• It helps in visualizing the project tasks and schedule.

Gantt Chart – Elements

● Task List - Runs vertically down the left - describes project work and may be organized into
groups and subgroups
● Timeline - Runs horizontally across the top - shows years, months, weeks, and days
● Bars - Horizontal markers on the right side - represent tasks and show progress, duration, and
start and end date

Gantt Chart - When to use

● Your project has a hard deadline
● Multiple people or teams are involved in the project and need to be coordinated
● A boss, client, or team member wants to see a visual timeline of the project from beginning to
end
● Your project involves even just a little complexity, such as tasks that need to be done in a
specific order
● Team members work on multiple projects at a time, and you need to manage their workloads
● You have a good idea of roughly how long each task should or can take
Week 7
1. Why requirements understanding process is complex than it looks? Explain your answer.
The requirement’s understanding process is more complex than it looks because to develop an
application, first we have to determine functionalities that need to be included in the
application. We have to analyze what the system must do and how it needs to react in certain
situations. We also must look forward to the performance criteria and quality expectations of
the application. The characteristics of the system concerning its performance, security, and
availability need to carefully be analyzed and listed.

Understanding the requirements of the problem is one of the most challenging tasks. The way
customers describe the system and the way we understand might not always be the same. So,
proper emphasis has to be given to the understanding of the requirements. Various steps need
to be carried out during the requirements understanding process such as:
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirement management
2. Briefly explain the steps of Requirement Engineering.
Various steps need to be carried out during the requirements understanding process such as:

Inception – Carry out a feasibility study and basic understanding of the problem. It checks
system contribution, budget, integration, etc.

Elicitation – Gather requirements, performance, or hardware constraints of an intended

software by communicating with clients. Interviews, questionnaires, observation, studying
existing documentation, scenarios, and prototyping are some of the techniques for requirement
elicitation.

Elaboration – Gathered information from the ahead steps is refined and expanded. The
creation of user scenarios and their interaction with the system is carried out.

Negotiation – Chances of conflicting requirements may arise from different users. Necessary
to prioritize the requirements and assess the cost and risk. Requirements are combined,
modified, or eliminated.

Specification – Carried out after clarity and consistency are achieved in the requirements. All
functional, non-functional, formal & informal requirements are documented. This
documentation is known as SRS (Software Requirements Specification).

Validation – An examination of the specification is needed to ensure all software requirements

have been stated and all inconsistencies, omissions, and errors have been detected and
corrected. A technical review is carried out involving the review team, customers, end-users,
and other stakeholders.

Requirement management – Changes in the requirements happen throughout the project. Set
of activities that help the project team identify, control, and track requirements and changes.
3. Refer to the SRS template (by IEEE) thoroughly and get used to the SRS components.
SRS Components:

a. Introduction: Describes the purpose of the document, the business idea implementation, the
scope of work, and an overview of the future product.
b. General Description: Provides details about the project, including its architecture,
functions, user characteristics, marketplace, features, and benefits.
c. Functional Requirements: Specifies the system’s intended functionalities.
d. Non-functional Requirements: Addresses characteristics that may not be expressed as
functions, such as system maintainability, mobility, usability, reliability, accuracy, and
constraints.
e. Interface Requirements: Explains communication between the future product and related
systems or users.
f. Budget and Schedule: Includes information about development timelines and resource
allocation.
Week 20
a. Write short notes on:
Layered Architecture Pattern, Event-Driven Architecture Pattern, Microkernel
Architecture Pattern, Microservices Architecture Pattern

Layered Architecture: It is also known as Tiered Architecture or N-Tier Architecture. It is

the most common architecture which is usually built around a database. The code is arranged
so the data enters the top layer and works its way down each layer until it reaches the bottom,
which is usually a database. It has 4 Distinct Layers; Presentation, Business, Persistence, and
Database.

Usages:
• Application that needs to be built quickly.
• Enterprise applications that require traditional IT departments and processes.
• Appropriate for teams with inexperienced developers and limited knowledge of
architecture patterns.
• Applications that require strict standards of maintainability and testability.
Downside:
• Performance-wise, it can be inefficient sometimes.
• Skipping previous layers to create tight coupling can lead to a logical mess full of complex
interdependencies.
• Basic modification can require a complete redeployment of the application.

Event-Driven Architecture Pattern: It builds a central unit that accepts all data and then
delegates it to the separate modules that handle the particular type. It is made up of decoupled,
single-purpose event-processing components that asynchronously receive and process events.
It consists of two topologies:
a. Mediator - when multiple steps must be orchestrated within an event bus through a
central mediator.
b. Broker - used to chain events together without using a central mediator.
Usages:
• Application where individual data blocks interact with only a few modules.
• For real time systems and data tracking.
Downside:
• Testing individual modules can only be done if they are independent, otherwise, they
need to be tested in a fully functional system.
• When several modules are handling the same event, error handling becomes
challenging to structure.

Microkernel Architecture Pattern: It basically has two component architecture pattern i.e. a
core system and several plugin modules. The core system works on minimal functionality to
keep the system operational. The plug-in modules are independent components with
specialized processing.
Usages:
• Applications that suit evolutionary design and incremental development.
• Applications that have a fixed set of core routines and dynamic set of rules that needs
frequent updates.
Downside:
• The plugin must have good handshaking code so that the microkernel is aware of the
plugin installation and is ready to work.
• Changing a microkernel is almost impossible if multiple plugins are depending on it.
• It is difficult to choose the right granularity for a kernel function in advance and more
complex at a later stage.

Microservices Architecture Pattern: Instead of building one big program, the goal is to
create a number of different tiny programs and then create a new little program every time
someone wants to add a new feature. The components are developed, deployed, and tested
without interdependency as separate units through an effective, streamlined delivery pipeline.
The pattern’s benefits are enhanced scalability and a high degree of decoupling within the
application.
Usages:
 • For applications where scalability matters.
• Business and web applications that require rapid development and remote has teams
globally.
Downside:
• Designing the right level of granularity for a service component is always a challenge.
• All applications do not include tasks that can be split into independent units.
• Performance can be affected when tasks are spread across different microservices.

b. Carry out a brief online search and write some descriptive reasons why microservices
architecture started to become a popular choice of architecture. While answering, you
can also explore the monolithic architecture and your answers could include comparative
aspects with the monolithic architecture as well.
Microservices Architecture: The Rising Star
1. Isolation and Resilience
Microservices are profitable due to their isolation. If one component fails, developers can use
another service, and the application continues to run independently. This flexibility allows
engineers to build and deploy services without changing the entire app, making it more
resilient.

2. Scalability
Microservices’ architecture, based on small components, enables development teams to scale
up or down as needed for specific elements. Isolation ensures that apps continue to function
correctly even during massive changes.

3. Productivity and Understandability

Microservices make it easier to test, understand, and maintain application builds. Each service
is independent, allowing developers to focus on specific functionality without dealing with the
entire monolithic app. As development teams expand, microservices remain a better choice.
4. Flexibility in Tool Selection
Developers can choose the right tools for each task within the microservices approach. Each
server can be built using the language or framework best suited for the job, without affecting
communication between microservices.

5. Faster Project Development

Microservices work independently. You don’t need to change the entire codebase to modify
features. Modify one component, test it, and deploy it individually. This leads to faster app
delivery.

6. Evolutionary Upgrades
Microservices are ideal for developers who can’t predict the devices their app will run on.
Controlled upgrades can be provided without slowing down or stopping the apps.

Monolithic Architecture: The Old Guard

1. What Is Monolithic Architecture?
A monolithic architecture is a traditional model where a software program is built as a single
unified unit. It couples all business concerns together into one large computing network.
Updates require modifying the entire stack, making them restrictive and time-consuming.

2. Advantages of Monolithic Architecture

Easy Deployment: One executable file or directory simplifies deployment.
Development Speed: Having an application based on one code base allows for fast
development.
Performance: Centralized code repositories often perform functions that would require
multiple APIs in microservices.

The Verdict
Microservices architecture shines in its agility, scalability, and maintainability. It’s a natural
fit for large-scale products and distributed teams. Monolithic architecture, while simpler
initially, can become unwieldy as projects grow. Choose wisely, considering your project’s
size, complexity, and future needs.
Week 21
1. With relevant examples for each, discuss the pillars of Object-Oriented Programming.
1. Abstraction:
Concept: Abstraction focuses on providing a simplified view of an object, hiding unnecessary
details. Users interact with the object's essential functionalities without needing to understand
its complex inner workings.
Example: Imagine a library management system. You, as a user, shouldn't need to know how
the system stores book data in a database or interacts with network protocols. Abstraction
allows you to borrow books, search the catalog, or renew loans by interacting with a user-
friendly interface that hides the underlying complexities.

2. Encapsulation:
Concept: Encapsulation bundles data (attributes) and methods (functions) that operate on that
data together within a single unit called a class. It controls access to the data using access
modifiers (public, private, protected) to ensure data integrity and prevent unintended
modifications.
Example: Consider a social media post class. This class might have attributes like content,
author, and timestamp. It could also have methods like editPost() and sharePost().
Encapsulation ensures the post's content can't be directly changed by unauthorized users.
Instead, the editPost() method would control modifications, potentially requiring
authentication or permission checks.

3. Inheritance:
Concept: Inheritance allows creating new classes (subclasses) that inherit properties and
functionalities from existing classes (superclasses). This promotes code reusability and
simplifies development by leveraging existing code. Subclasses can add new functionalities
specific to their needs.
Example: Think of a vehicle class with attributes like make, model, and color. It might have
methods like startEngine() and stopEngine(). You can create subclasses like Car and Truck
that inherit these attributes and methods. Additionally, Car might have a specific method for
 openTrunk() and Truck might have a method for towTrailer(), utilizing inheritance while
adding functionalities unique to each vehicle type.

4. Polymorphism:
Concept: Polymorphism allows objects of different classes to respond differently to the same
method call. It enables flexible and dynamic behavior based on the object's type at runtime.
This promotes cleaner and more versatile code.
Example: Imagine a shape class with a method called calculateArea(). Inheriting classes like
Square and Circle can define their own versions of calculateArea() to calculate their specific
areas differently. When you call the calculateArea() method on a Square object, it executes the
Square's version of the method, and when you call it on a Circle object, it executes the Circle's
version. This allows for a single method call to handle various object types appropriately.

2. With the help of the internet, explore the following design patterns and explain their
significance with examples:
Observer Pattern (Behavioural)
Adapter pattern (Structural)
Model View Controller(MVC) design pattern.
Week 22
1. Differentiate between Verification and Validation.
Verification Validation
Verification is a process that determines the Validation is a process in which the
quality of software. requirements of the customer are actually
met by the software functionality.
Verification does not involve the execution Validation involves the execution of code
of code.
It is considered static testing. It is considered dynamic testing.
The goal of verification is application and The goal of validation is an actual product.
software architecture and specification
It includes checking documents, designs, It includes testing and validating the actual
codes, and programs. product.
Verification is for prevention of errors. Validation is for detection of errors.

2. Briefly state the purposes of Testing.

• Validate the functionality of the software to ensure it meets the specified requirements and
works as intended.
• Identify and eliminate defects and errors that could negatively impact the software’s
performance and stability.
• Improve the reliability and robustness of the software to provide consistent and accurate
results.
• Enhance the software’s performance, making it more efficient and responsive even under
heavy user loads.
• Ensure the software is user-friendly and intuitive, offering a positive and satisfactory user
experience.
3. Write in short why Regression Testing is necessary.
Regression test is a test that is performed to make sure that previously working functionality still
works, after changes elsewhere in the system.
• Regression testing helps to ensure that changes (due to testing or for other reasons) do not
introduce unintended behavior or additional errors.
• By identifying problems before they become a problem, regression testing helps to reduce the
cost of fixing issues caused by changes in code.
• Regular regression testing mitigates the risk of software failures in production.
• By minimizing regressions, regression testing helps deliver software updates that users can
trust.

4. As a part of the Black-Box Test, you are required to Test a sign-in/login page. Explain
how you would approach this testing. You are free to assume the requirements related
to login.
Week 23
1. Outline some of the differences between White Box Testing and Black Box Testing
methods.
Black Box Testing White Box Testing
It is a way of software testing in which the It is a way of testing the software in which the
internal structure or the program or the code tester has knowledge about the internal
is hidden, and nothing is known about it. structure or the code or the program of the
software.

Black Box testing is applicable on higher White Box testing is application on lower
levels of testing like System Testing, and levels of testing like Unit Testing, and
Accepting Testing Integration Testing.

This testing can be initiated based on the This type of testing of software is started
requirement specifications document. after a detail design document.

Types of Black Box Testing: Types of White Box Testing:

Functional Testing Path Testing
Non-functional testing Loop Testing
Regression Testing Condition testing

It lacks test coverage because it can’t find out It improves test case coverage by checking
small defects of the application code line by line and discovering small
defects.
Programming and implementation Its important to have knowledge of both
programming and implementation to carry
knowledge is not required to carry out Black
out White Box Testing
Box testing.

• Black box testing is carried out by testers, while white box testing is generally carried
out by developers.
 • Black Box testing aims at checking on functionality performed under the test while
While Box testings aims and checking how the system performs.

• Black Box testing means functional test or external test whereas White Box testing
means structural test or interior testing

2. What typically a White Box Testing cover in your opinion?

White Box testing is a way of testing the software in which the tester has knowledge about the
internal structure or the code or the program of the software.
• Security gaps and vulnerabilities
It checks if security best practices were applied when coding the application, and if the code is
vulnerable to known security threats and exploits.
• Broken or poorly structured paths
It identifies conditional logic that is redundant, broken, or inefficient.

• Expected output
It executes all possible inputs to a function to see if it always returns the expected output.

• Loop testing
It checks single loops, concatenated loops and nested loops for efficiency, conditional logic
and correct handling of local and global variables.

• Data Flow testing

It tracks variables and their values as they pass through the code to find variables that are not
correctly initialized, declared but never used, or incorrectly manipulated.
3. What is a good test case?

• A good test case has clear and concise document. It should be easy to understand as any tester
can execute it without needing further explanation.
• A good test case is designed having reusability across different testing cycles and projects
which can save time and efforts in long run.
• A good test case includes detailed steps and expected results which specifies whether the
software behaves as expected.
• A good test case covers all the relevant aspects of functionality being tested, including edge
cases and potential error conditions.
• A good test case doesn’t depend on other test cases for execution.
4. How do you prioritize test cases for execution?
Risk Based Prioritization
Focus on areas with a higher likelihood of failure or those critical to business operations. This
includes complex features, new functionalities, and areas with a history of defects.
Requirement Based Prioritization
This approach prioritizes test cases based on the importance of the requirements they cover.
Functional requirements that are critical to the core functionality of the software are tested
first.Less critical or non-functional requirements might be tested later or with lower priority.
Coverage-Based Prioritization:
This technique focuses on maximizing code coverage as quickly as possible. Here are two sub-
techniques:

• Total Statement Coverage: Test cases covering the most code statements are prioritized
first.
• Additional Statement Coverage: Test cases that cover new, uncovered code sections are
prioritized after each iteration.

5. What is the fundamental difference between Verification and Validation?

Following are some of the activities.
Categorize these activities in terms of verification and validation and also mention the
reason why
- Code inspection.
Verification
 Code inspection is a static analysis technique where the source code is examined for defects
and sticking to coding standards without executing the program. It ensures the correctness and
quality of the code.

- Black Box Testing

Validation
Black box testing focuses on validating the functionality of the software by testing it against
the specified requirements without considering the internal code structure. It involves
executing the software and checking if it behaves as expected.

- Acceptance Testing
Validation
Acceptance testing is conducted to validate the software against business requirements and
user needs. It ensures that the software meets the criteria for acceptance and works correctly
in the user's environment. This often involves executing the system and checking its behavior
in real-world scenarios.

- Requirements specification review

Verification
Reviewing requirements specifications is a verification activity that involves checking the
requirements documents for clarity, completeness, and consistency. It ensures that the
requirements are correctly defined before proceeding with design and development, without
executing any code.