Chapter 1

What is Software. Write the characteristics of Software

Answer: Software is a collection of codes, documents, and triggers that does a specific
job and fills a specific [Link] we can say,Software is a set of instructions,
data or programs used to operate computers and execute specific tasks.

Characteristics of Software / Q. Essential Attributes of Software

Engineering:

Define Software Engineering:

Software engineering is an engineering discipline that is concerned with all
aspects of software production from the early stages of system
specification through to maintaining the system after it has gone into use.

Q. Explain the term “Software doesn’t wear out”

Answer: The phrase “software doesn’t wear out” draws attention to the difference between
software and hardware maintenance.
Hardware that has moving parts wears out. The teeth on gears wear down, brake pads wear
out, imperfections in ball bearings get worse over time, materials degrade and so on.

Software, on the other hand, is a collection of 0s and 1s and stays the same forever. And yet
80% or more of the money spent on software is spent on maintenance. Business
requirements or regulatory environments change, new features are needed, workflows need
to be modified, old data must be purged to prevent the database becoming inefficient, and
so on.

So as we can see that software needs maintaining mostly because of changes outside
[Link] we can say that “Software doesn’t wear out”

What are the generic process framework activities for

developing software? Explain.
Answer:
[Link] five important general skills and traits of a good
software engineer.
Answer:
Here are the top five qualities that all successful software engineers should possess.

● Knowledge of the full stack

● Ability to learn, adapt and grow
● Business acumen
● Time management
● Interpersonal skills
OR,
1. Positive Attitude
A great programmer is ambitious and eager to do their best. They step up when there’s a
deadline to hit, take feedback without getting defensive, and take care of their company’s
product.
2. Good Communication Skills
Programming is a linguistic skill, so being a good communicator is directly related to being a
good developer. In fact, great offshore developers usually speak more than one language, as
well as having great English. You need to be able to ask the right questions, understand
concepts without needing a written specification document, and turn problems into theories and
theories into coherent solutions.
3. Time and Task Management
Having a good work ethic and being punctual is important, but beyond that, you also need to be
able to predict how long things will take you and to “manage up”, setting expectations with your
boss or clients instead of leaving them to manage you.
4. Quick Learning
Great developers are committed to their own development. They’re self-learners who can pick
up new technologies independently and aren’t afraid to ask when they don’t know the answer.
5. Technical Experience
Great developers have experience that’s both deep and broad, and have a good grasp of best
practices like agile development, task management tools like Jira and Trello, version control,
and working in different environments.
6. A Good Team Player
Good developers aren’t just committed to their own development, they also care about helping
other developers improve. They’re willing to teach, answer questions, and write documentation
that favors teammates both in their business and in the wider developer community.
7. End-User Focus
A great programmer doesn’t just do what they’re asked – they think about the end user’s wants
and needs and work to solve problems, create high value, and cut features that don’t create
value.

Importance of Software engineering:

1. Reduces complexity
Big softwares are always complex and difficult to develop. Software engineering has a great
solution to decrease the complexity of any project. Software engineering divides big
problems into several small problems. And then start solving each small problem one by
one. All these small problems are solved independently to each other.

2. To minimize software cost

Software requires a lot of hardwork and software engineers are highly paid professionals. A
lots of man force is required to develop software with millions of codes. But in software
engineering, programmers plan everything and reduce all those things that are not required.
In turn, cost for software productions becomes less as compared to any software that does
not use software engineering approach.

3. To decrease time

Anything that is not made according to the plan always wastes time. And if you are making
big software then you may need to run a lot of code to get the ultimate running code. This is
a very time consuming process and if it is not well managed then this can take a lot of time.
So if you are making your software according to software engineering approach then it will
reduce a lot of time.
4. Handling big projects

Big projects are not made in few days and they require lots of patience, planning and
management. And to invest six and seven months of any company, it requires lots of
planning, direction, testing and maintenance. No one can say that he has given four months
of company to the project and the program is still in its first stage. Because company has
given many resources to the projects and it should be completed. So to handle big projects
without any problem, company has to go for software engineering approach.

5. Reliable software

Software should be reliable, means if you have delivered the software then it should work
for at least it’s given time span or subscription. And if any bugs come in the software then
company is responsible for solving all these bugs. Because in software engineering, testing
and maintenance is provided so there is no worry of its reliability.

6. Effeteness

Effectiveness comes if anything has made according to the standards. Software standards
are the big focus of companies to make it more effective. So Software becomes more
effective in performance with the help of software engineering.

Fundamental Activities of Software Engineering

1. Software specification, where customers and engineers define the

software that is to be produced and the constraints on its operation.
2. Software development, where the software is designed and programmed.
3. Software validation, where the software is checked to ensure that it is
what the customer requires.
4. Software evolution, where the software is modified to reflect changing
customer and market requirements.
Relation of Software Engineering with Computer Science and
System Engineering

1. Computer science is concerned with the theories and methods that

underlie computers and software systems, whereas software engineering
is concerned with the practical problems of producing software. Some
knowledge of computer science is essential for software engineers in the
same way that some knowledge of physics is essential for electrical
engineers. Computer science theory, however, is often most applicable to
relatively small programs. Elegant theories of computer science are rarely
relevant to large, complex problems that require a software solution.

2. System engineering is concerned with all aspects of the development and

evolution of complex systems where software plays a major role.
System engineering is therefore concerned with hardware development,
policy and process design, and system deployment, as well as software
engineering. System engineers are involved in specifying the system,
defining its overall architecture, and then integrating the different parts to
create the finished system.

What are the key challenges facing Software Engineering?

Ans 1:Major Challenges in Software Development

● Rapid technology advancement.

○ Every technology advancement is a blessing for the IT industry. But at the
same time, technology evolving at a phenomenal rate leads to an added
pressure for software development professionals to leverage these
upcoming technology trends in software product development to gain a
cutting edge over competitors and stand out in the market.
● Increasing customer demands.
○ Software projects are generally conceptual and are aimed at designing
and developing software products that meet varied customer demands.
 To develop even the simplest application or product, developers must
clearly understand the underlying business concept and bring in the
required features to satisfy the growing customer demands.
● Time limitations.
○ Software development is a time-game. Developers work under pressured
environments and strive to complete project requirements within strict and
scanty timelines. This is especially a challenge when working with
international clients on multiple time-zones. Time constraints often bring
down efficiencies of development teams and lead to mediocre quality
software products in the end.
● Limited infrastructure/resources.
○ Another challenge faced by the majority of software development
companies is a lack of resources or IT infrastructure to execute projects
effectively. This could mean a lack of high performance software
development tools, powerful computing platforms, inefficient data storage
architectures or improper networks and connectivity. Such hindrances
bring down productivity and performance of software development teams
and impact the overall result.
● Conflicts with software testing teams.
○ In a classic software development project, interpersonal conflicts occur
inevitably between software development and testing teams. Several
factors contribute to such conflicts like working under high performance
pressure, different mindsets, difference in job roles and the very opposite
nature of development and testing. If not controlled and managed
effectively, these conflicts could hamper the overall project adversely.

Ans 2: Issues that affect different types of software:

1. Heterogeneity Increasingly, systems are required to operate as distributed sys-
tems across networks that include different types of computer and mobile
devices. As well as running on general-purpose computers, software may also
have to execute on mobile phones and tablets. You often have to integrate new
software with older legacy systems written in different programming languages.
The challenge here is to develop techniques for building dependable software
that is flexible enough to cope with this heterogeneity.
2. Business and social change Businesses and society are changing incredibly
quickly as emerging economies develop and new technologies become availa-
ble. They need to be able to change their existing software and to rapidly develop
 new software. Many traditional software engineering techniques are time
consuming, and delivery of new systems often takes longer than planned. They
need to evolve so that the time required for software to deliver value to its
customers is reduced.
3. Security and trust As software is intertwined with all aspects of our lives, it is
essential that we can trust that software. This is especially true for remote soft-
ware systems accessed through a web page or web service interface. We have
to make sure that malicious users cannot successfully attack our software and
that information security is maintained.
4. Scale Software has to be developed across a very wide range of scales, from
very small embedded systems in portable or wearable devices through to
Internet-scale, cloud-based systems that serve a global community.

Software Engineering Ethics:

1. Confidentiality You should normally respect the confidentiality of your employ-
ers or clients regardless of whether or not a formal confidentiality agreement has
been signed.
2. Competence You should not misrepresent your level of competence. You should
not knowingly accept work that is outside your competence.
3. Intellectual property rights You should be aware of local laws governing the
use of intellectual property such as patents and copyright. You should be careful
to ensure that the intellectual property of employers and clients is protected.

Types of application/ Diversity of software engineering

There are many different types of application, including:

Stand-alone applications These are application systems that run on a personal

computer or apps that run on a mobile device. They include all necessary functionality
and may not need to be connected to a network. Examples of such applications are
office applications on a PC, CAD programs, photo manipula- tion software, travel apps,
productivity apps, and so on.

Interactive transaction-based applications These are applications that execute on a

remote computer and that are accessed by users from their own computers, phones, or
tablets. Obviously, these include web applications such as e-commerce applications
where you interact with a remote system to buy goods and services. This class of
application also includes business systems, where a business provides access to its
systems through a web browser or special-purpose client program and cloud-based
services, such as mail and photo sharing. Interactive applications often incorporate a
large data store that is accessed and updated in each transaction.

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. Examples of embedded systems include the software in
a mobile (cell) phone, software that controls antilock braking in a car, and software
in a microwave oven to control the cooking process.

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. Examples of batch systems are periodic billing systems, such as
phone billing systems, and salary payment systems.

Entertainment systems These are systems for personal use that are intended to
entertain the user. Most of these systems are games of one kind or another, which may
run on special-purpose console hardware. The quality of the user interaction offered is
the most important distinguishing characteristic of enter- tainment systems.

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. These are often computationally intensive and
require high-performance parallel systems for execution.

Data collection and analysis systems Data collection systems are systems that
collect data from their environment and send that data to other systems for pro- cessing.
The software may have to interact with sensors and often is installed in a hostile
environment such as inside an engine or in a remote location. “Big data” analysis may
involve cloud-based systems carrying out statistical analysis and looking for
relationships in the collected data.

Systems of systems These are systems, used in enterprises and other large organ-
izations, that are composed of a number of other software systems. Some of these may
be generic software products, such as an ERP system. Other systems in the assembly
may be specially written for that environment.
Software Engineering for web based systems:
1. Software reuse has become the dominant approach for constructing web-based
systems. When building these systems, you think about how you can assemble
them from preexisting software components and systems, often bundled together
in a framework.

2. It is now generally recognized that it is impractical to specify all the require-

ments for such systems in advance. Web-based systems are always developed
and delivered incrementally.

3. Software may be implemented using service-oriented software engineering,

where the software components are stand-alone web services. I discuss this
approach to software engineering in Chapter 18.

4. Interface development technology such as AJAX (Holdener 2008) and HTML5

(Freeman 2011) have emerged that support the creation of rich interfaces within
a web browser.
 Chapter 2

Define Software Process:

A software process is a set of related activities that leads to the production of a software
system.

Define Software process Model aka Software Development Lifecycle

aka SDLC:

a software process model (sometimes called a Software Development Life Cycle or

SDLC model) is a simplified representation of a software process.

Define Plan-Driven-Process:

Plan-driven processes are processes where all of the process activities are planned in
advance and progress is measured against this plan.

Define Agile Process:

In agile processes planning is incremental and continuous as the software is developed.

It is therefore easier to change the process to reflect changing customer or product
requirements.
Difference Between Agile and Plan-Driven approach:

Agile Plan Driven

Planning is incremental and continuous All the activities are planned in advance
as the software is developed

Suitable for small to medium systems and Suitable for large systems and teams
teams

Can accommodate change during Can’t change during development.

development

The process is not visible The process is visible

Required experienced agile personnel Required experienced personnel at the

from throughout the life-cycle beginning

Appropriate for dynamic development Appropriate for stable development

platform platform

Success achieved through freedom and Success achieved through structure and
chaos order

Some models are Scrum, Xtreme Some models are Waterfall, Incremental
Programming

Some generic Software Process Model:

1. The waterfall model This takes the fundamental process activities of specifica- tion,
development, validation, and evolution and represents them as separate process
phases such as requirements specification, software design, implemen- tation, and
testing.

2. Incremental development This approach interleaves the activities of specification,

development, and validation. The system is developed as a series of versions
(increments), with each version adding functionality to the previous version.

[Link] and configuration This approach relies on the availability of reusable

components or systems. The system development process focuses on configuring
these components for use in a new setting and integrating them into a system.
The Waterfall model(plan driven):

1. Requirements analysis and definition The system’s services, constraints, and

goals are established by consultation with system users. They are then defined in
detail and serve as a system specification.
2. System and software design The systems design process allocates the
requirements to either hardware or software systems. It establishes an overall
system architecture. Software design involves identifying and describing the
funda- mental software system abstractions and their relationships.
3. Implementation and unit testing During this stage, the software design is
realized as a set of programs or program units. Unit testing involves verifying that
each unit meets its specification.
4. Integration and system testing The individual program units or programs are
integrated and tested as a complete system to ensure that the software
requirements have been met. After testing, the software system is delivered to
the customer.
5. Operation and maintenance Normally, this is the longest life-cycle phase. The
system is installed and put into practical use. Maintenance involves correcting
errors that were not discovered in earlier stages of the life cycle, improving the
implementation of system units, and enhancing the system’s services as new
requirements are discovered.

Write out the reasons for the failure of Water Fall Model.
● One way street: This model is just like the one-way street
● Overlapping: The waterfall model has lacked an overlapping among phase
● Interaction
 ● Support delivery of system
● Feedback path
● Not Flexible

List three major shortcomings that we might face, if we use the

classical waterfall model for developing all types of software
products.
● High amounts of risk and uncertainty.
● Not a good model for complex and object-oriented projects.
● Poor model for long and ongoing projects.

The Incremental Development Model(agile/plan driven):

Define Incremental development Model:

Incremental development is based on the idea of developing an initial implementation,

getting feedback from users and others, and evolving the software through several
versions until the required system has been developed
Advantages of Incremental development model:

1. The cost of implementing requirements changes is reduced. The amount of

analysis and documentation that has to be redone is significantly less than is
required with the waterfall model.
2. 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. Customers find it difficult to judge progress from
software design documents.
3. Early delivery and deployment of useful software to the customer is possible,
even if all of the functionality has not been included. Customers are able to use
and gain value from the software earlier than is possible with a waterfall process.

Disadvantages of Incremental development problem

1. The process is not visible. Managers need regular deliverables to measure

pro- gress. If systems are developed quickly, it is not cost effective to produce
docu- ments that reflect every version of the system.
2. System structure tends to degrade as new increments are added. Regular
change leads to messy code as new functionality is added in whatever way is
possible. It becomes increasingly difficult and costly to add new features to a
system. To reduce structural degradation and general code messiness, agile
methods suggest that you should regularly refactor (improve and restructure) the
software.

Integration and configuration

[Link] Process stages of re-use oriented software engineering [mid 17]
[Link] specification The initial requirements for the system are pro- posed. These do
not have to be elaborated in detail but should include brief descriptions of essential
requirements and desirable system features.

[Link] discovery and evaluation Given an outline of the software require- ments, a search is
made for components and systems that provide the func- tionality required. Candidate
components and systems are evaluated to see if they meet the essential requirements and if
they are generally suitable for use in the system.

[Link] refinement During this stage, the requirements are refined using information
about the reusable components and applications that have been discovered. The requirements
are modified to reflect the available compo- nents, and the system specification is re-defined.
Where modifications are impossible, the component analysis activity may be reentered to
search for alternative solutions.

[Link] system configuration If an off-the-shelf application system that meets the

requirements is available, it may then be configured for use to create the new system.

[Link] adaptation and integration If there is no off-the-shelf system, indi- vidual reusable
components may be modified and new components developed. These are then integrated to
create the system.

Requirement Engineering:
There are 3 main activities in the requirement Engineering Process:

1. Requirements elicitation and analysis This is the process of deriving the system
requirements through observation of existing systems, discussions with poten- tial users
and procurers, task analysis, and so on. This may involve the development of one or
more system models and prototypes. These help you understand the system to be
specified.

2. Requirements specification Requirements specification is the activity of trans-

lating the information gathered during requirements analysis into a document that
defines a set of requirements. Two types of requirements may be included in this
document. User requirements are abstract statements of the system requirements
for the customer and end-user of the system; system requirements are a more detailed
description of the functionality to be provided.

3. Requirements validation This activity checks the requirements for realism,

consistency, and completeness. During this process, errors in the requirements
document are inevitably discovered. It must then be modified to correct these problems.

Software design and implementation

Testing

The stages in the testing process are:

Component testing The components making up the system are tested by the people developing the
system. Each component is tested independently, without other system components. Components may
be simple entities such as functions or object classes or may be coherent groupings of these entities. Test
automation tools, such as JUnit for Java, that can rerun tests when new versions of the component are
created, are commonly used (Koskela 2013).

System testing System components are integrated to create a complete system. This process is
concerned with finding errors that result from unanticipated interactions between components and
component interface problems. It is also concerned with showing that the system meets its functional and
non-functional requirements, and testing the emergent system properties. For large systems, this may be
a multistage process where components are integrated to form subsystems that are individually tested
before these subsystems are integrated to form the final system.

Customer testing This is the final stage in the testing process before the system is accepted for
operational use. The system is tested by the system customer (or potential customer) rather than with
simulated test data. For custom-built software, customer testing may reveal errors and omissions in the
system requirements definition, because the real data exercise the system in different ways from the test
data. Customer testing may also reveal requirements problems where the system’s facilities do not really
meet the users’ needs or the system performance is unacceptable. For products, customer testing shows
how well the software product meets the customer’s needs.

Testing phases in plan driven process

Software Evolution:

Prototyping
A prototype is an early version of a software system that is used to demonstrate
concepts, try out design options, and find out more about the problem and its possible
solutions.
Q. Main objective of prototype development? [mid 17]
A software prototype can be used in a software development process to help anticipate
changes that may be required:

1. In the requirements engineering process, a prototype can help with the elicitation and
validation of system requirements.

2. In the system design process, a prototype can be used to explore software solutions
and in the development of a user interface for the system.

Incremental delivery
Incremental delivery is an approach to software development where some of the developed increments
are delivered to the customer and deployed for use in their working environment.
 1. Customers can use the early increments as prototypes and gain experience that informs their
requirements for later system increments. Unlike prototypes, these are part of the real system, so
there is no relearning when the complete system is available.
2. Customers do not have to wait until the entire system is delivered before they can gain value from
it. The first increment satisfies their most critical require- ments, so they can use the software
immediately.
3. The process maintains the benefits of incremental development in that it should be relatively easy
to incorporate changes into the system.

4. As the highest priority services are delivered first and later increments then inte- grated, the most
important system services receive the most testing. This means that customers are less likely to
encounter software failures in the most impor- tant parts of the system.

How does a process improvement cycle work?

Process development cycle

Process improvement means understanding existing processes and changing these
processes to increase product quality and/or reduce costs and development time.

Two quite different approaches to process improvement and change are used:

1. The process maturity approach, which has focused on improving process and
project management and introducing good software engineering practice into an
organization. The level of process maturity reflects the extent to which good
technical and management practice has been adopted in organizational software
development processes. The primary goals of this approach are improved prod-
uct quality and process predictability.
2. The agile approach, which has focused on iterative development and the reduc-
tion of overheads in the software process. The primary characteristics of agile
methods are rapid delivery of functionality and responsiveness to changing cus-
tomer requirements. The improvement philosophy here is that the best processes
are those with the lowest overheads and agile approaches can achieve this. I
describe agile approaches in Chapter 3.
The general process improvement process underlying the process maturity approach is
a cyclical process, as shown in Figure 2.11. The stages in this process are:

1. Process measurement You measure one or more attributes of the software pro-
cess or product. These measurements form a baseline that helps you decide if process
improvements have been effective. As you introduce improvements, you remeasure the
same attributes, which will hopefully have improved in some way.

2. Process analysis The current process is assessed, and process weaknesses and
bottlenecks are identified. Process models (sometimes called process maps) that
describe the process may be developed during this stage. The analysis may be focused
by considering process characteristics such as rapidity and robustness.

3. Process change Process changes are proposed to address some of the identified
process weaknesses. These are introduced, and the cycle resumes to collect data
about the effectiveness of the changes.
 Chapter 3

Agile methods share some common characteristics:

1. The processes of specification, design and implementation are interleaved.

There is no detailed system specification, and design documentation is mini-
mized or generated automatically by the programming environment used to
implement the system. The user requirements document is an outline definition
of the most important characteristics of the system.
2. The system is developed in a series of increments. End-users and other
system stakeholders are involved in specifying and evaluating each increment.
They may propose changes to the software and new requirements that should be
implemented in a later version of the system.
3. Extensive tool support is used to support the development process. Tools that
may be used include automated testing tools, tools to support configuration man-
agement, and system integration and tools to automate user interface production.

Q. The principle of agile method? [mid 17]

Principle of Agile Development:
Agile methods have been particularly successful for two kinds of system development.

1. Product development where a software company is developing a small or

medium-sized product for sale. Virtually all software products and apps are
now developed using an agile approach.
2. Custom system development within an organization, where there is a clear com-
mitment from the customer to become involved in the development
process and where there are few external stakeholders and regulations that
affect the software.

Explain how the principles underlying agile methods lead to the

accelerated development and deployment of software.

Q. Principles/Practice of XP method? [mid 17]

Q. How XP satisfy the agile principle?
Ans.
1. Incremental development is supported through small, frequent releases of the sys- tem.
Requirements are based on simple customer stories or scenarios that are used as a basis for
deciding what functionality should be included in a system increment.
2. Customer involvement is supported through the continuous engagement of the customer in the
development team. The customer representative takes part in the development and is
responsible for defining acceptance tests for the system.
3. People, not process, are supported through pair programming, collective owner- ship of the
system code, and a sustainable development process that does not involve excessively long
working hours.
4. Change is embraced through regular system releases to customers, test-first development,
refactoring to avoid code degeneration, and continuous integra- tion of new functionality.
5. Maintaining simplicity is supported by constant refactoring that improves code quality and by
using simple designs that do not unnecessarily anticipate future changes to the system.

Extreme programming expresses user requirements as stories, with

each story written on a card. Discuss the advantages and
disadvantages of this approach to requirements description.

Scrum

Scrum agile method was developed to provide a framework for organizing agile projects
and, to some extent at least, provide external visibility of what is going on.

Q. Briefly Describe the Scrum Sprint Cycle [mid 17]

Sprint Cycle:

1. The starting point for the Scrum sprint cycle is the product backlog—the list of
items such as product features, requirements, and engineering improvement that
have to be worked on by the Scrum team. Each sprint cycle lasts a fixed length
of time, which is usually between 2 and 4 weeks. At the beginning of each cycle,
the Product Owner prioritizes the items on the product backlog to define which
are the most important items to be developed in that cycle.
2. The whole team is then involved in selecting which of the highest priority items
they believe can be completed. They then estimate the time required to complete
these items. To make these estimates, they use the velocity attained in previous
sprints, that is, how much of the backlog could be covered in a single sprint. This
leads to the creation of a sprint backlog—the work to be done during that sprint.
The team self-organizes to decide who will work on what, and the sprint begins.
3. During the sprint, the team holds short daily meetings (Scrums) to review pro-
gress and, where necessary, to re-prioritize work.
4. Everyone participates in this short-term planning; there is no top-down direction
from the ScrumMaster.
5. the daily interactions among Scrum teams may be coordinated using a Scrum
board. This is an office whiteboard that includes information and post-it notes
about the Sprint backlog, work done, unavailability of staff, and so on.
6. At the end of each sprint, there is a review meeting, which involves the whole
team. This meeting has two purposes.
a. it is a means of process improvement. The team reviews the way they
have worked and reflects on how things could have been done better.
b. it provides input on the product and the product state for the product
backlog review that precedes the next sprint.

Q. Major disadvantages of agile method in software maintenance [mid + final

17]

1. Lack of product documentation: the most important docu- ment is the system
requirements document, which tells the software engineer what the system is
supposed to do. Without such knowledge, it is difficult to assess the impact of
proposed system changes. Many agile methods collect requirements informally
 and incrementally and do not create a coherent requirements document. The use
of agile methods may therefore make subsequent system maintenance more
difficult and expen- sive. This is a particular problem if development team
continuity cannot be maintained.

2. Keeping customers involved: A key challenge in using an agile approach to

maintenance is keeping customers involved in the process. While a customer
may be able to justify the full-time involve- ment of a representative during
system development, this is less likely during mainte- nance where changes are
not continuous. Customer representatives are likely to lose interest in the system.
Therefore, it is likely that alternative mechanisms, such as change proposals,
discussed in Chapter 25, will have to be adapted to fit in with an agile approach.

3. Development team continuity: Another potential problem that may arise is

maintaining continuity of the devel- opment team. Agile methods rely on team
members understanding aspects of the system without having to consult
documentation. If an agile development team is broken up, then this implicit
knowledge is lost and it is difficult for new team mem- bers to build up the same
understanding of the system and its components. Many programmers prefer to
work on new development to software maintenance, and so they are unwilling to
continue to work on a software system after the first release has been delivered.
Therefore, even when the intention is to keep the development team together,
people leave if they are assigned maintenance tasks.
 Chapter 4

Define Requirements:

The requirements for a system are the descriptions of the services that a system should
provide and the constraints on its operation.

Define Requirement Engineering:

The process of finding out, analyzing, documenting and checking these services and
constraints is called requirements engineering (RE).

User requirement:

User requirements are statements, in a natural language plus diagrams, of what ser-
vices the system is expected to provide to system users and the constraints under
which it must operate. The user requirements may vary from broad statements of the
system features required to detailed, precise descriptions of the system functionality.

System Requirement:

System requirements are more detailed descriptions of the software system’s functions,
services, and operational constraints. The system requirements docu- ment (sometimes
called a functional specification) should define exactly what is to be implemented. It may
be part of the contract between the system buyer and the software developers.
What are functional and non-functional requirements?
Functional Requirements:

Functional requirements These are statements of services the system should provide,
how the system should react to particular inputs, and how the system should behave in
particular situations. In some cases, the functional requirements may also explicitly
state what the system should not do.

Non-Functional Requirements:

Non-functional requirements These are constraints on the services or functions offered

by the system. They include timing constraints, constraints on the development process,
and constraints imposed by standards. Non-functional require- ments often apply to the
system as a whole rather than individual system features or services.

Q. Non-Functional requirements sometimes creates

functional requirements [final 17, mid 17]
Non-functional requirements, as the name suggests, are requirements that are not
directly concerned with the specific services delivered by the system to its users. These
non-functional requirements usually specify or constrain characteristics of the system as
a whole. They may relate to emergent system properties such as reliability, response
time, and memory use. Alternatively, they may define constraints on the system
implementation, such as the capabilities of I/O devices or the data represen- tations
used in interfaces with other systems.

Non-functional requirements are often more critical than individual functional

requirements.

The functional requirements for a system describe what the system should do. These
requirements depend on the type of software being developed, the expected users of
the software, and the general approach taken by the organization when writing
requirements.
An individual non-functional requirement, such as a security requirement, may generate
several, related functional requirements that define new system ser- vices that are
required if the non-functional requirement is to be implemented. In addition, it may also
generate requirements that constrain existing require- ments; for example, it may limit
access to information in the system.

Q. Spiral View [final/mid 17]

● The output of the RE process is a system requirements document.

● Early in the process, most effort will be spent on understanding high-level business and
non-functional requirements, and the user requirements for the system.
● Later in the process, in the outer rings of the spiral, more effort will be devoted to eliciting and
understanding the non-functional requirements and more detailed system requirements.
● This spiral model accommodates approaches to development where the requirements are
developed to different levels of detail.
● The number of iterations around the spiral can vary so that the spiral can be exited after some or
all of the user require- ments have been elicited.
Q. Requirements elicitations process [final/mid 17]

The aims of the requirements elicitation process are to understand the work
that stakeholders do and how they might use a new system to help support
that work.

1. Requirements discovery and understanding This is the process of interacting

with stakeholders of the system to discover their requirements. Domain
requirements from stakeholders and documentation are also discovered during
this activity.
2. Requirements classification and organization This activity takes the
unstructured collection of requirements, groups related requirements and
organizes them into coherent clusters.
3. Requirements prioritization and negotiation Inevitably, when multiple stake-
holders are involved, requirements will conflict. This activity is concerned with
prioritizing requirements and finding and resolving requirements conflicts through
negotiation. Usually, stakeholders have to meet to resolve differences and agree
on compromise requirements.
4. Requirements documentation The requirements are documented and input
into the next round of the spiral. An early draft of the software requirements docu-
ments may be produced at this stage, or the requirements may simply be main-
tained informally on whiteboards, wikis, or other shared spaces.

Mention some problems those may occur while expressing user

requirements using natural language.
Find answer
What is a SRS document and why is it required?

List down with short notes the common sections of an SRS

document structure.

Using your knowledge of how an ATM (automated teller machine)

develop a set of use cases that could serve as a basis for
understanding the requirements for an ATM system.

Chapter 5
Define system modeling.
System modeling is the process of developing abstract models of a system, with each
model presenting a different view or perspective of that system. System modeling now
usually means representing a system using some kind of graphical notation based on
diagram types in the Unified Modeling Language (UML).

5 UML diagram types:

1. Activity diagrams, which show the activities involved in a process or in data

Processing and the flow of control from one activity to another.
2. Use case diagrams, which show the interactions between a system and its
environment.
3. Sequence diagrams, which show interactions between actors and the system
and between system components.
4. Class diagrams, which show the object classes in the system and the associa-
tions between these classes.
5. State diagrams, which show how the system reacts to internal and external
events.
Context Model:

Context models normally show that the environment includes several other automated
systems. However, they do not show the types of relationships between the systems in
the environment and the system that is being specified.

Interaction Model:

All systems involve interaction of some kind. This can be user interaction, which
involves user inputs and outputs; interaction between the software being developed and
other systems in its environment; or interaction between the components of a software
system.

[Link] case modeling, which is mostly used to model interactions between a sys-
tem and external agents (human users or other systems).

2. Sequence diagrams, which are used to model interactions between system

components, although external agents may also be included.

Q. Draw a sequence diagram to show the information of a

particular student in a Student Information System.
Student Information System will be just like that one. Change the values associated
Another example:
Q. Draw a Sequence diagram showing the interactions of objects
in the gas filing station system when a driver wants to take 50 lite
of gasoline using credit card.

Structural Model:
Structural models of software display the organization of a system in terms of the
components that make up that system and their relationships. Structural models may be
static models, which show the organization of the system design, or dynamic models,
which show the organization of the system when it is executing.

Class Diagram:

Class diagrams are used when developing an object-oriented system model to show the
classes in a system and the associations between these [Link],an object
class can be thought of as a general definition of one kind of system [Link]
association is a link between classes indicating that some relationship exists between
these classes.
Q. Using the UML graphical notation for object classes, design
the following object classes, identifying attributes and operations.
Use your own experience to decide on the attributes and
operations that should be associated with these objects.
(1) A cellphone. (2) a printer for a personal computer, (3) a bank account
Q. Draw an activity diagram of Airline reservation system.
Activity Diagram for ATM:

Chapter 6
4 Fundamental Views:

1. A logical view, which shows the key abstractions in the system as objects or
object classes. It should be possible to relate the system requirements to entities
in this logical view.
2. A process view, which shows how, at runtime, the system is composed of inter-
acting processes. This view is useful for making judgments about non-func- tional
system characteristics such as performance and availability.
3. A development view, which shows how the software is decomposed for develop-
ment; that is, it shows the breakdown of the software into components that are
implemented by a single developer or development team. This view is useful for
software managers and programmers.
4. A physical view, which shows the system hardware and how software compo-
nents are distributed across the processors in the system. This view is useful for
systems engineers planning a system deployment.
Architectural Pattern:

You can think of an Architectural pattern as a stylized, abstract description of good

practice, which has been tried and tested in different systems and environments.

[Link] is software architectural design and why is it required?

Architectural design is a creative process in which you design a system organization
that will satisfy the functional and non-functional requirements of a system.

Architectural design is concerned with understanding how a software system should be

organized and designing the overall structure of that system. Software architecture is
important because it affects the performance, robustness, distributability, and
maintainability of a system. Individual components implement the functional system
requirements, but the dominant influence on the non-functional system characteristics is
the system’s architecture. Bass et al. suggest that explicitly designing and documenting
software architecture has three advantages:

1. Stakeholder communication The architecture is a high-level presentation of the

sys- tem that may be used as a focus for discussion by a range of different
stakeholders.
2. System analysis Making the system architecture explicit at an early stage in the
system development requires some analysis. Architectural design decisions have
a profound effect on whether or not the system can meet critical require- ments
such as performance, reliability, and maintainability.
3. Large-scale reuse An architectural model is a compact, manageable description
of how a system is organized and how the components interoperate. The system
architecture is often the same for systems with similar requirements and so can
support large-scale software reuse.
[Link] design pattern and its necessity in designing a software
solution.
You can think of an Architectural pattern as a stylized, abstract description of good
practice, which has been tried and tested in different systems and environments.

Q. What do you know about MVC Architecture? Briefly discuss

the architecture of What do web application using MVC patterns.

Q. Clearly and concisely describe the foliowing

1. The components of the MVC software architecture.
2. The interaction between the components of the MVC architecture.
3. The mapping from this MVC architecture to the client server computing
architecture.
Q. What do you know about layered architecture? Discuss and
visualize the layered architecture of a Library Management
System.

Couldn’t find an actual solution, take idea from following diagrams

Or,
My solution:
Describe pipe and filter architectural pattern and two suitable use
cases with proper diagrams.

4.

Chapter 7
Define:
Software design and implementation is the stage in the software engineering process at
which an executable software system is developed
Briefly explain the working strategies in Host-target development.

Most professional software development is based on a host-target model (Figure 7.15). Software is
developed on one computer (the host) but runs on a separate machine (the target). More generally, we
can talk about a development platform (host) and an execution platform (target). A platform is more than
just hardware. It includes the installed operating system plus other supporting software such as a
database manage- ment system or, for development platforms, an interactive development environment.
Sometimes, the development platform and execution platform are the same, mak- ing it possible to
develop the software and test it on the same machine. Therefore, if you develop in Java, the target
environment is the Java Virtual Machine. In princi- ple, this is the same on every computer, so programs
should be portable from one machine to another. However, particularly for embedded systems and mobile
systems, the development and the execution platforms are different. You need to either move your
developed software to the execution platform for testing or run a simulator on your development machine.

Simulators are often used when developing embedded systems. You simulate hardware devices, such as
sensors, and the events in the environment in which the system will be deployed. Simulators speed up
the development process for embed- ded systems as each developer can have his or her own execution
platform with no need to download the software to the target hardware. However, simulators are
expensive to develop and so are usually available only for the most popular hardware architectures.

Describe Observer design pattern with proper diagrams showing

how the display of a object's store can be separated from the
object itself.[i don't think this is important]
Answer:

Pattern name: Observer

Description: Separates the display of the state of an object from the object itself
and allows alternative displays to be provided. When the object state changes, all
displays are automatically notified and updated to reflect the change.

Problem description: In many situations, you have to provide multiple displays

of state information, such as a graphical display and a tabular display. Not all of
these may be known when the information is specified. All alternative
presentations should support interaction and, when the state is changed, all
displays must be updated.
This pattern may be used in situations where more than one display format for
state information is required and where it is not necessary for the object that
maintains the state information to know about the specific display formats used.

Solution description: This involves two abstract objects, Subject and Observer,
and two concrete objects,ConcreteSubject and ConcreteObject, which inherit the
attributes of the related abstract objects. The abstract objects include general
operations that are applicable in all situations. The state to be displayed is
maintained in ConcreteSubject, which inherits operations from Subject allowing it
to add and remove Observers(each observer corresponds to a display) and to
issue a notification when the state has changed.
The ConcreteObserver maintains a copy of the state of ConcreteSubject and
implements the Update() interface of Observer that allows these copies to be
kept in step. The ConcreteObserver automatically displays the state and reflects
changes whenever the state is updated.
Consequences: The subject only knows the abstract Observer and does not
know details of the concrete [Link] there is minimal coupling between
these objects. Because of this lack of knowledge, optimizations that enhance
display performance are impractical. Changes to the subject may cause a set of
linked updates to observers to be generated, some of which may not be
necessary.
 Figure: A UMLmodel of the Observer pattern

Chapter-8
17 Batch Final Question:

Section A:

3.b)Define alpha and beta [Link] the differences

between them. (2+3=5 marks)
Answer:
Alpha Testing: This test is the first stage of testing and will be performed
amongst the teams (developer and QA teams). Unit testing, integration
testing and system testing when combined together is known as alpha
testing.( according to Sir sheet)

/ Alpha testing is a type of testing that is done on an application towards the

end of a development process when the product is almost in a usable state.(
google theke neya)
Beta Testing: This test is performed after alpha testing has been successfully
performed. In beta testing, a sample of the intended audience tests the
application. Beta testing is also known as pre-release testing. Beta test
versions of software are ideally distributed to a wide audience on the Web,
partly to give the program a "real-world" test and partly to provide a preview
of the next release.

/ Beta testing is one of the final steps in your software development

lifecycle (SDLC) before a product goes live. Also referred to as user testing
or customer validation, beta testing aims to ensure that end users are satisfied
with a software product before you make it generally available.

Alpha Testing Beta Testing

Alpha testing involves both the
white box and black box testing. Beta testing commonly uses black box testing.

Alpha testing is performed by

testers who are usually internal Beta testing is performed by clients who are not
employees of the organization. part of the organization.

Alpha testing is performed at Beta testing is performed at end-user of the

developer’s site. product.

Reliability and security testing are Reliability, security and robustness are checked
not checked in alpha testing. during beta testing.

Beta testing also concentrates on the quality of

Alpha testing ensures the quality the product but collects users input on the product
of the product before forwarding and ensures that the product is ready for real time
to beta testing. users

Alpha testing requires a testing Beta testing doesn’t require a testing

environment or a lab. environment or lab.

Alpha testing may require long Beta testing requires only a few weeks of
execution cycle. execution.

Developers can immediately Most of the issues or feedback collected from

address the critical issues or fixes in beta testing will be implemented in future
alpha testing. versions of the product.
c)What is acceptance testing?Write down difference stages in the
acceptance testing. (1+4=5 marks)
Answer:
Acceptance testing, a testing technique performed to determine whether or
not the software system has met the requirement specifications.(google theke
neya)
The 6 Steps of Testing to get to “Final Acceptance”

● Stage 1: Factory Acceptance Test.

● Stage 2: Customer Acceptance Test.
● Stage 3: Site Acceptance Test.
● Stage 4: Coverage Verification Test.
● Stage 5: Final System Acceptance Test.
● Stage 6: Burn In Period.

Section B:
2.c) What are the differences between software validation and
verification.
Answer: Software testing sheet e ache

3.b)Define Software [Link] short notes on i)Unit

testing and ii) System testing.
Answer: Sheet
Other Batches Final Questions:

Why is it necessary to detect as many errors as possible during

code review and code inspection stages?

[Link] and explain different types of testing done during the testing
phases. (6mark)
Answer: Sheet e [Link] gulo testing (functional and non functional)
er 2-1 line kore likhte hobe

[Link] is acceptance testing? Explain different testings in user

acceptance testing. (2+4=6 marks)
Answer:
Acceptance testing, a testing technique performed to determine whether or
not the software system has met the requirement specifications.(google theke
neya)
User Acceptance Testing is a process to check the system accepts the
requirements of a user or not. It's performed at a time when the system
used by actual users. User acceptance testing comes after –
Unit Testing--->Integration Testing--->System Testing---->Acceptance
Testing in the process of testing.

Then unit,integration,system,acceptance testing er 2-3 line detail dibe sheet

theke.
[Link] why boundary value analysis is so important for the
design of black box test suite for a problem.(4 mark)
Answer: Boundary value analysis is one of the widely used case design
technique for black box testing. It is used to test boundary values because the
input values near the boundary have higher chances of error.
Whenever we do the testing by boundary value analysis, the tester focuses
on, while entering boundary value whether the software is producing correct
output or not.
Boundary values are those that contain the upper and lower limit of a
variable. Assume that, age is a variable of any function, and its minimum
value is 18 and the maximum value is 30, both 18 and 30 will be considered
as boundary values.
The basic assumption of boundary value analysis is, the test cases that are
created using boundary values are most likely to cause an error.
There is 18 and 30 are the boundary values that's why tester pays more
attention to these values, but this doesn't mean that the middle values like 19,
20, 21, 27, 29 are ignored. Test cases are developed for each and every value
of the range.
Testing of boundary values is done by making valid and invalid partitions.
Invalid partitions are tested because testing of output in adverse condition is
also essential.

[Link] is regression testing? Why is regression testing

necessary? (3 mark)
Answer: Sheet e ache.
[Link] why testing can only detect the presence of errors,not
their absence. (4 marks)
Answer: Testing can detect only the presence of errors, not their absence
because the main goal of the testing is to observe the behavior of the
particular software and to check whether it meet its requirement expectation
or not.
Testing is a part of broader process of software verification and validation. It
consists of a set of activities, where the testers try to make the software
behave anomalous in order to detect or anomaly to be later fix. Testing cannot
demonstrate the faults other than specified in every circumstance. It is always
possible that an overlooked test case could conceal further problem with the
system.
Assume that exhaustive testing of a program, where every possible valid
input is checked, is impossible (true for all but trivial programs). Test cases
either do not reveal a fault in the program or reveal a program fault. If they
reveal a program fault then they demonstrate the presence of an error. If they
do not reveal a fault, however, this simply means that they have executed a
code sequence that – for the inputs chosen – is not faulty. The next test of the
same code sequence – with different inputs – could reveal a fault.

[Link] is unit testing? Explain why unit testing should be

automated (use a framework) to ensure regression testing.
(2+2=4 marks)

Answer: Definition sheet e dekho

/
Unit testing is a type of software testing where individual units or
components of a software are tested.(from google)
Unit tests are typically automated tests written and run by software
developers to ensure that a section of an application (known as the "unit")
meets its design and behaves as intended. In procedural programming, a unit
could be an entire module, but it is more commonly an individual function or
procedure. In object-oriented programming, a unit is often an entire interface,
such as a class, or an individual method.
Unit testing allows the programmer to refactor code or upgrade system
libraries at a later date, and make sure the module still works correctly (e.g.,
in regression testing). The procedure is to write test cases for all functions
and methods so that whenever a change causes a fault, it can be quickly
identified. Unit tests detect changes which may break a design contract.

7. Explain the term integration testing. Describe different

approaches of integration testing. (6 marks)
Answer: Sheet e integration testing er purotai answer.

8. Explain the term testing. Distinguish among error, fault and

failure. Which of these conditions is detected by testing. Justify
your answer. (6 Mark)
Answer:
Fault : It is a condition that causes the software to fail to perform its required
function.

Error : Refers to difference between Actual Output and Expected output.

Failure : It is the inability of a system or component to perform required
function according to its specification.

IEEE Definitions

● Failure: External behavior is incorrect

● Fault: Discrepancy in code that causes a failure.
● Error: Human mistake that caused fault

The testing process involves evaluating the features of the software product
for requirements in terms of any missing requirements, bugs or errors,
security, reliability and performance

[Link] Unit testing is so important? Explain the concept of unit

testing in detail. (4 mark)
Answer: Definition deya question 6 er answer e.

Unit testing, a testing technique using which individual modules are tested to
determine if there are any issues by the developer himself. It is concerned with
functional correctness of the standalone modules.
The main aim is to isolate each unit of the system to identify, analyze and fix the
defects.
Advantages:

● Reduces Defects in the Newly developed features or reduces bugs when

changing the existing functionality.
● Reduces Cost of Testing as defects are captured in very early phase.
● Improves design and allows better refactoring of code.
 ● Unit Tests, when integrated with build gives the quality of the build as well.

[Link] between White box testing and Black box testing.

(3 mark)
Answer: Sheet

[Link] the goal of quality assurance. (2 mark)

Answer: Sheet

[Link] about Bottom-Up testing (3 marks)

Answer: Bottom-up Testing is a type of incremental integration testing
approach in which testing is done by integrating or joining two or more
modules by moving upward from bottom to top through control flow of
architecture structure. In these, low-level modules are tested first, and then
high-level modules are tested. This type of testing or approach is also known
as inductive reasoning and is used as a synthesis synonym in many cases.
Bottom-up testing is user-friendly testing and results in an increase in overall
software development. This testing results in high success rates with
long-lasting results.