# Enlist and explain software characteristics (ANS) # State need of software requirement

1. Software is developed or engineered; it is not specification (SRS) (ANS) The need of SRS
manufactured in the classical sense :-  document is to provide  A detailed overview of
Although some similarities exist between software product, its parameters and goals.  The
software development and hardware description regarding the project's target
manufacture, the two activities are audience and its user interface hardware and
fundamentally different  In both activities, high software requirements.  How client, team and
quality is achieved through good design, but the audience see the product and its functionality
manufacturing phase for hardware can introduce # Define Reactive Risk strategies (ANS) A
quality problems that are non-existent (or easily reactive risk strategy monitors the project for
corrected) for software likely risks. Resources are set aside to deal with
2. Software doesn’t “wear out.” :-  This them, should they become actual problems.
contradiction can best be explained by More commonly, the software team does nothing
considering the “actual curve” shown in Figure.  about risks until something goes wrong. Then,
During its life, software will undergo change the team flies into action in an attempt to correct
(maintenance). As changes are made, it is likely the problem rapidly. This is often called a fire-
that some new defects will be introduced, fighting mode. When this fails, “crisis
causing the failure rate curve to spike as shown in management” takes over and the project is in
Figure real jeopardy
# Define software on engineering (ANS) Software # Hardware attributes (ANS)  Run-time
engineering is the establishment and use of performance constraints  Memory constraints 
sound engineering principles in order to obtain The volatility of the virtual machine environment
economically software that is reliable and works  Required turnabout time
efficiently on real machines
#  Product attributes (ANS)  Required software
reliability extent  Size of the application
database  The complexity of the product

Software Quality Software Quality # Define Software Quality Assurance (ANS)

Assurance (QA) Control (QC)  Quality assurance consists of the auditing and
 It is a procedure  It is a procedure reporting functions of management.  The goal of
that focuses on that focuses on quality assurance is to provide management with
providing assurance fulfilling the quality the data necessary to be informed about product
that quality requested requested quality, thereby gaining insight and confidence
will be achieved that product quality is meeting its goals
 QA aims to prevent  QC aims to identify
the defect and fix defects

 It is a method to  It is a method to
manage the quality- verify the quality-
Verification Validation
 It does not involve  It always involves
executing the executing a program
program
 It's a Preventive  It's a Corrective
technique technique

 It's a Proactive  It's a Reactive

measure measure
 It is the procedure  It is the procedure
to create the to verify that
deliverables deliverables
# Explain Software Engineering as layered 2. Process Layer: The foundation for software
technology approach (ANS) engineering is the process layer. Software
Software engineering is a layered technology. The Engineering process is the glue that holds the
layers of software engineering as shown in the technology layers together and enables rational
above diagram are :- and timely development of computer software.
Process defines a framework that must be
established for effective delivery of software
engineering technology. The software process
forms the basis for management control of
software projects and establishes the context in
which technical methods are applied, works
products (models, documents, data, reports,
forms etc.) are produced, milestones are
established, quantity is ensured and change is
properly managed
1. A Quality Focus: Any engineering approach 3. Methods: Software Engineering methods
(including software engineering) must rest on an provide the technical ―how to building software.
organizational commitment to quality. Total Methods encompass a broad array of tasks that
quality management, six sigma and similar include communication, requirements analysis,
philosophies foster a continuous process design modeling, program construction, testing
improvement culture, and it is this culture that and support
ultimately leads to the development of 4. Tools: Software Engineering tools provide
increasingly more effective approaches to automated or semi-automated support for the
software engineering. The bedrock that supports process and the methods. When tools are
software engineering is a quality focus integrated so that information created by one
tool can be used by another, a system for the
support of software development, called
computer–aided software engineering is
established
# Explain with example Decision table (ANS) Decision Table:-
 Decision table is a software testing technique Conditions Rule Rule Rule Rule
used to test system behaviour for different input 1 2 3 4
combinations.  This is a systematic approach Username(T/F F T F T
where the different input combinations and their )
corresponding system behaviour (Output) are Password(T/F) F F T T
captured in a tabular form. That is why it is also
Output(E/H) E E E H
called as a Cause-Effect table where Cause and
effects are captured for better test coverage.  Legend: T – Correct username/password F –
 Example 1: Decision Base Table for Login Screen Wrong username/password E – Error message is
displayed H – Home screen is displayed
 Interpretation:  Case 1 – Username and
password both were wrong. The user is shown an
error message.  Case 2 – Username was correct,
but the password was wrong. The user is shown
an error message.  Case 3 – Username was
wrong, but the password was correct. The user is
shown an error message.  Case 4 – Username
 The condition is simple if the user provides
and password both were correct, and the user
correct username and password the user will be
navigated to homepage
redirected to the homepage. If any of the input is
wrong, an error message will be displayed
# i. People ii. Process iii. Product iv. Project (ANS) (3) The Process: 1. A software process provides
(1). The People: 1. The “people factor” is so the framework from which a comprehensive plan
important that the Software Engineering Institute for software development can be established. 2.
has developed a People Capability Maturity A small number of framework activities are
Model (People CMM) to continually improve its applicable to all software projects, regardless of
ability to attract, develop, motivate, organize, their size or complexity. 3. A number of different
and retain the workforce needed to accomplish task sets—tasks, milestones, work products, and
its strategic business objectives. 2. The people quality assurance points enable the framework
capability maturity model defines the following activities to be adapted to the characteristics of
key practice areas for software people: a. the software project and the requirements of the
Staffing b. communication and coordination c. project team. 4. Finally, umbrella activities—such
work environment d. performance management as software quality assurance, software
(2). The Product: 1. Before a project can be configuration management, and measurement
planned, product objectives and scope should be occur throughout the process
established, alternative solutions should be (4) The Project: 1. To manage complexity, we
considered and technical and management conduct planned and controlled software
constraints should be identified. 2. Without this projects. 2. The success rate for present-day
information, it is impossible to define reasonable software projects may have improved but our
(and accurate) estimates of the cost, an effective project failure rate remains much higher than it
assessment of risk, a realistic breakdown of should be. 3. To avoid project failure, a software
project tasks, or a manageable project schedule project manager and the software engineers who
that provides a meaningful indication of progress. build the product must avoid a set of common
3. Objectives identify the overall goals for the warning signs, understand the critical success
product (from the stakeholders’ points of view) factors that lead to good project management,
without considering how these goals will be and develop a common-sense approach for
achieved. 4. Scope identifies the primary data, planning, monitoring, and controlling the project
functions, and behaviors that characterize the
product
# List and explain basic principles of project (Prescriptive process (agile process mode)
scheduling (ANS) Basic Principles:- model)
 Compartmentalization: The project must be It is Process oriented It is people oriented
compartmentalized into a number of manageable
activities and tasks.  Interdependency: The It follows Life cycle It follows Iterative
interdependency of each compartmentalized model (waterfall, and Incremental
activity or task must be determined.  Time spiral) development development model
allocation: Each task to be scheduled must be model
allocated some number of work units.  Effort Documentation Documentation
validation: Every project has a defined number of required is to be required is to be
staff members.  Defined responsibilities: Every comprehensive and minimal and evolving
task that is scheduled should be assigned to a constant
specific team member.  Defined outcomes: Predictive planning is Adaptive planning is
Every task that is scheduled should have a required required
defined outcome.
Customers role is Customers role is
important critical

Formal Informal
communication is communication is
required required
# Describe any four principles of communication Principle 4 Face-to-face communication is best: 
for software engineering (ANS) It usually works better when some other
Principle 1 Listen:  Try to focus on the speaker‘s representation of the relevant information is
words, rather than formulating your response to present.  For example, a participant may create
those words.  Ask for clarification if something is a drawing /document that serve as a focus for
unclear, but avoid constant interruptions.  discussion.
Never become contentious in your words or # Explain RMMM plan with example (ANS)
actions (e.g., rolling your eyes or shaking your A risk management plan or plan risk management
head) as a person is talking is a document that a prepares to foresee risks,
Principle 2 Prepare before you communicate:  estimate impacts, and define responses to risks.
Spend the time to understand the problem It also contains a risk matrix. A risk is "an
before you meet with others. If necessary, uncertain event or condition that, if it occurs, has
perform some research to understand business a positive or negative effect on a project's
domain.  If you have responsibility for objectives." Risk is inherent with any and project
conducting a meeting, prepare an agenda in manager should assess risks continually and
advance of the meeting. develop plans to address them. The risk
Principle 3 someone should facilitate the activity: management plan contains an analysis of likely
 Every communication meeting should have a risks with both high and low impact, as well as
leader (a facilitator)  To keep the conversation mitigation strategies to help the project avoid
moving in a productive direction,  To mediate being derailed should common problems arise.
any conflict that does occur, and  To ensure that Risk management plans should be periodically
other principles are followed. reviewed by the project team to avoid having the
analysis become stale and not reflective of actual
potential project risks
# Draw proper labelled “LEVEL 1 Data Flow
Diagram” (DFD) for student attendance system
(ANS)

Level 0 Context Level

Level 1 For Admin

Level 1 DFD student

# Describe Extreme programming with proper 2. The Second Principle: KISS (Keep It Simple,
diagram (ANS) Extreme programming is a Stupid!)  All design should be as simple as
lightweight, efficient, low-risk, flexible, possible, but no simpler. This facilitates having a
predictable, scientific, and fun way to develop a more easily understood and easily maintained
software. eXtreme Programming (XP) was system.  It doesn’t mean that features should be
conceived and developed to address the specific discarded in the name of simplicity
needs of software development by small teams in 3. The Third Principle: Maintain the Vision  A
the face of vague and changing requirements. clear vision is essential to the success of a
Extreme Programming is one of the Agile software project.  If you make compromise in
software development methodologies. It the architectural vision of a software system, it
provides values and principles to guide the team will weaken and will eventually break even the
behavior. The team is expected to self organize. well designed systems.  Having a powerful
Extreme Programming provides specific core architect who can hold the vision helps to ensure
practices where-  Each practice is simple and a very successful software project.
self-complete.  Combination of practices
produces more complex and emergent behavior
Extreme Programming is based on the following
values-  Communication  Simplicity  Feedback
 Courage  Respect
# List and explain any four principles of “Core
Principles” of Software Engineering (ANS)
1. The First Principle: The Reason It All Exists
 A software system exists for one reason: to
provide value to its users. All decisions should be
made with this in mind.  Before specifying a
system requirement, system functionality, before
determining the hardware platforms, first
determine, whether it adds value to the system

White box testing Black Box Testing Statement Coverage, Equivalence

Branch coverage, and partitioning,
The tester needs to This technique is used
Path coverage are Boundary value
have the knowledge to test the software
White Box testing analysis are Black Box
of internal code or without the
technique testing technique
program knowledge of internal
Can be based on Can be based on
code or program
detailed design Requirement
It aims at testing the It aims at testing the
documents specification
structure of the item functionality of the
document
being tested software

It is also called It also known as data

structural testing, driven, box testing,
clear box testing, data-, and functional
code-based testing, or testing
glass box testing
Testing is best suited This type of testing is
for a lower level of ideal for higher levels
testing like Unit of testing like System
Testing, Integration Testing, Acceptance
testing testing
# Draw and explain Transition diagram from requirement model The data design transforms the information domain model
to design model (ANS) created during analysis into the data structures that will be
required to implement the software. The data objects and
relationships defined in the entity relationship diagram and
the detailed data content depicted in the data dictionary
provide the basis for the data design activity. Part of data
design may occur in conjunction with the design of software
architecture. More detailed data design occurs as each
software component is designed. The architectural design
defines the relationship between major structural elements
of the software, the design pattern that can be used to
achieve the requirements that have been defined for the
system, and the constraints that affect the way in which
architectural design patterns can be applied
Software requirements, manifested by the data, functional, and The architectural design representation the framework of a
behavioural models, feed the design task. Using one of a number computer based system can be derived from the system
of design methods, the design task produces a data design, an specification, the analysis model, and the interaction of
architectural design, an interface design, and a component subsystems defined within the analysis model. The interface
design. Each of the elements of the analysis model provides design describes how the software communicates within
information that is necessary to create the four design models itself, with systems that interoperate with it, and with
required for a complete specification of design. humans who use it. An interface implies a flow of information
Design is a meaningful engineering representation of something (e.g., data and/or control) and a specific type of behavior.
that is to be built. It can be traced to a customer’s requirements Therefore, data and control flow diagrams provide much of
and at the same time assessed for quality against a set of the information required for interface design. The
predefined criteria for ―good‖ design. In the software component-level design transforms structural elements of
engineering context, design focuses on four major areas of the software architecture into a procedural description of
concern: data, architecture, interfaces, and components Design software components. Information obtained from the PSPEC,
begins with the requirements model CSPEC, and STD serve as the basis for component design

# Describe CMMI. Give significance of each level (ANS) Level 1: Initial. The software process is characterized as ad hoc
The Capability Maturity Model Integration (CMMI), a and occasionally even chaotic. Few processes are defined, and
comprehensive process meta-model that is predicated on a set success depends on individual effort
of system and software engineering capabilities that should be Level 2: Repeatable. Basic project management processes are
present as organizations reach different levels of process established to track cost, schedule, and functionality. The
capability and maturity. The CMMI represents a process meta- necessary process discipline is in place to repeat earlier
model in two different ways: ( 1) Continuous model and (2) successes on projects with similar applications.
Staged model. The continuous CMMI meta-model describes a Level 3: Defined. The software process for both management
process in two dimensions. Each process area (e.g. project and engineering activities is documented, standardized, and
planning or requirements management) is formally assessed integrated into an organization wide software process. All
against specific goals and practices and is rated according to the projects use a documented and approved version of the
following capability levels: organization's process for developing and supporting software.
This level includes all characteristics defined for level 2
Level 4: Managed. Detailed measures of the software process
and product quality are collected. Both the software process
and products are quantitatively understood and controlled
using detailed measures. This level includes all characteristics
defined for level 3 Level 5: Optimizing. Continuous process
improvement is enabled by quantitative feedback from the
process and from testing innovative ideas and technologies.
This level includes all characteristics defined for level 4