VPMP POLYTECHNIC 5. Explain waterfall model.

4. Software layer technology.

COMPUTER DEPARTMENT
SUBJECT: FUNDAMENTALS OF SOFTWARE
DEVELOPMENT (4th semester)
SUBJECT CODE: 3341603

1. Explain “Software doesn’t wear out but it does deteriorate” .

 Software engineering can be viewed as a layered technology.
 It contains process, methods, and tools that enables software product to be
built in a timely manner.
 A Quality Focus Layer
 Software engineering mainly focuses on quality product.  Feasibility Study:
 The above figure shows the software failure rate.  Aim of this phase is to determine whether the system would be
 It checks whether the output meets with its requirement specification
 Software is not highly affected by environmental effects. financially and technically feasible to develop the product.
or not.
 In the early stage, due to many errors, software could have high failure.  Requirement Analysis and Specification:
 Every organization should maintain its total quality management.
 But it becomes reliable as time passes instead of wearing out. Once software  Aim of this phase is to understand the exact requirements of the
 Process Layer
is made it has a longer life span.
 It is the heart of software engineering. customer and to document them properly.
 In actual curve, we can see that software may have increased failure rate as it  Design:
 It is also work as foundation layer.
may become obsolete as the environment in which it was developed,  The goal of design phase is to transform the requirements specified in
 Software process is a set of activities together if ordered and
changes. SRS document into a structure that is suitable for implementation in
performed properly, then the desired result would be produced.
 Spike in the curve if due to chance of maintenance and side effects.
 It defines framework activities. some programming language.
 Software may be retired due to new requirement.  Coding and Unit Testing
 The main objective of this layer is to deliver software in time.
 So, software doesn’t wear out, but it may be deteriorate.  It is also called as implementation phase.
 In figure, the relationship between time and failure called “bath-tub curve”.  Method Layer
 It indicates that hardware exhibits relatively high failure rates early in its  It describes ‘how-to’ build software product.  Aim of this phase is to translate the software design into source code
2. Explain SDLC Model.
life, then defects are corrected and the failure rate drops to a steady-state  It creates software engineering environment to software product using and unit testing is done module wise.
 Every system has a life cycle.  Integration and System Testing
level for some period of time. CASE tools
 It begins when a problem is recognized, after then system is developed,  Once all the modules are coded and tested individually, integration of
 As time passes, however, the failure rate rises again as hardware components  Tools Layer
grows until maturity and then maintenance needed due to change in the
suffer from the affects of dust, vibration, temperature extremes, and many  It provides support to below layers. different modules is undertaken.
nature of the system. So, it died and new system or replacement of it taken  Goal of this phase is to ensure that the developed system works well
other environmental factors.  Due to this layer, process is executed in proper manner.
place. to its requirements described in the SRS document.
 So, simply, we can say hardware begins to wear out.
 Maintenance

 SDLC is a framework that describes the activities performed at each stage of  It requires maximum efforts to develop software product.  It requires maximum efforts to develop software product.  Complete
a software development project.  This phase is needed to keep system operational.  This phase is needed to keep system operational. It should be complete regarding to the project. So, it can be easily
 General maintenance is needed due to change in the environment or  General maintenance is needed due to change in the environment or understood by the analyst and developer.
the requirement of the system. the requirement of the system.  Consistent
An SRS should be consistent through the project development.
3. Discuss Software characteristics . 6. Explain Requirement Gathering Technique. Requirement may not conflict at later stage..
The characteristics of software decide whether the software is good or bad.  Structured
 Understandability  Requirement gathering is the first activity performed during the software SRS should be well structured to understand and to implement.
Software should be easy to understand development.  Black-Box View
It should be efficient to use.  The goal of requirement gathering activity is to collect all relevant SRS should have block box view means, there should not be much detailing
 Cost information from the customer regarding the product to be developed. of the project in it.
Software should be cost effective as per its usage.  In this phase, meeting with customers, analyzing market demand and  Verifiable
 Maintainability features of the product are mainly focused. It should be verifiable by the clients or the customers for whom the project is
 Correctness  Requirement gathering activities are being made.
 Feasibility Study: Software should be correct as per its requirements.  Studying the existing documents  Adaptable
 Aim of this phase is to determine whether the system would be  Documentation  Interview with end users It should be adaptable in both sides from the clients as well as from the
financially and technically feasible to develop the product. Software should be properly documented so that we can re-refer it in  Task analysis developers.
 Requirement Analysis and Specification: future.  Scenario analysis  Maintainable
 Aim of this phase is to understand the exact requirements of the  Reusability  Brainstorming SRS should be maintainable so in the future change can be made easily.
customer and to document them properly. It should be reusable, or its code or logic should be reusable in future.  questionnaires  Portable
 Design:  Interoperability  It should be portable as we can use the contents of it for the same types of
 The goal of design phase is to transform the requirements specified in Software should be able to communicate with various devices using 7. Define SRS ? characteristics of good SRS . development.
SRS document into a structure that is suitable for implementation in standard bus structure and protocol.  Unambiguous
some programming language. Software should be easily maintainable and modifiable in future  SRS is the output of requirement gathering and analysis activity. There should not be any alternates of SRS that creates ambiguity.
 Coding and Unit Testing  Modularity  SRS is a detailed description of the software that is to be developed.  Traceable
 It is also called as implementation phase. Software should have modular approach so it can be handled easily  It describe the complete behavior of the system. Each of the requirements should be clear and refer to the future
 Aim of this phase is to translate the software design into source code for testing.  SRS describe what the proposed system should do without describing how development.
and unit testing is done module wise.  Functionality the software will do.
 Integration and System Testing Software should be functionally capable to meet user requirements.  It is working as a reference document for the developer. 8. Differentiate : Functional & Non-Functional requirement .
 Once all the modules are coded and tested individually, integration of  Reliability  The SRS translate the ideas of the customer into the formal documents.
different modules is undertaken. It should have the capability to provide failure-free service.  The SRS document is prepared by system analyst.  Functional requirement:
 Goal of this phase is to ensure that the developed system works well  Portability characteristics The functional requirement are the services which the end users
to its requirements described in the SRS document. Software should have the capability to be adapted for different  Concise expect the final product to provide.
 Maintenance environments. SRS should contain brief and concise information regarding the project; no  Non-Functional requirement:
more detailed description of the system should be there.
 The non functional requirements describe the characteristics of the system  Temporal Cohesion  During counting, the comments and blank lines should not be counted.  Number of Files
that can’t be expresses functionality.  Determining the LOC count at the end of a project is very simple. But,  Number of Interfaces.
 It is same as logical cohesion except that the elements are related in
Ex: portability, maintainability, usability, security etc. accurate estimation of the LOC count at the beginning of a project is
time and are executed together.
very difficult. 13.Explain Project Estimation Technique.
9. Explain Cohesion with their types .  A module is in temporal cohesion when a module contains functions Disadvantage of LOC :
that must be executed in the same time span.  Size can vary with coding style.  Estimation of various parameters is a basic project planning activity.
 Cohesion is a measure of function strength of a module.  Focuses on coding activity alone.  The important project parameters that are estimated include: project
 Example: modules that perform activities like initialization, cleanup,
 Cohesion keeps the internal module together and represent the function  Correlates poorly with quality and efficiency of code. size, effort required to develop the software, project duration and cost.
strength. startup and shut down.  Penalizes higher level programming languages, code reuse, etc.  There are three categories of estimation techniques:
 Cohesion of a module represent how tightly bound the internal element of a  Procedural cohesion  Measures lexical/textual complexity only. Empirical estimation techniques
module are to one another.  does not address the issues of structural or logical complexity.  This technique based on making an educated guess of the project
 Classification of cohesion (Types)  A module has procedural cohesion when it contains elements that  Difficult to estimate LOC from problem description. parameters.
 Coincidental(Low) belongs to common procedural unit.  So not useful for project planning  While using this technique, prior experience with development of
 Logical  A module is said to have procedural cohesion, if the set of the module Function point metric similar products is helpful.
 Temporal and all the part of a procedure in which certain sequence of steps are  The function point metric overcomes many of the shortcomings of  There are two most popular empirical techniques:
 Procedural carried out achieve an objective. the LOC metric. o Expert judgement.
 Communicational  The advantages of using the function point metric is that it can be o Delphi estimation technique.
 Sequential  Communicational Cohesion used to easily estimate the size of a software product directly from Expert judgement technique
 Functional(High)  A module is said to have communicational cohesion, if all functions the problem specification.  In this technique, an expert makes an educated guess of the problem
of the module refer to or update the same data structure.  But in LOC, the size can be accurately determined only after the size after analyzing the problem thoroughly.
 Coincidental cohesion
product has fully been developed.  Usually, the expert estimates the cost of the different components that
 It is lowest cohesion .  Sequential Cohesion.  In function point metric, the size of a software product is directly would make up the system and then combines the estimates for the
dependent on the number of different functions or features it individual modules to arrive at the overall estimate.
 It occurs when there are no meaningful relationship between the  When the output of one element in a module forms the input to
supports.  However, this technique is subject to human errors and individual bias.
element . another module, we get sequential cohesion.
 Each function when invokes reads some input data and transforms it  A more refined form of expert judgement is the estimation made by a
 A module is said to have coincidental cohesion if it perform a set of  Sequential cohesion does not provide any guideline how to combine to the corresponding output data. group of experts.
task that relate each other very loosely. these elements into modules.  Equation to count UFP Delphi estimation technique
 UFP = (Number of inputs)*4 + (Number of outputs)*5 +  Delphi cost estimation technique tries to overcome some of the
 Logical Cohesion  Functional Cohesion
(Number of Inquiries)*4 + (Number of Files)*10 + (Number of shortcomings of the expert judgment approach.
 A module is said to be logically cohesive if there is some logical  Functional cohesion is the strongest cohesion. Interfaces)*10  Delphi estimation is carried out by a team comprising of a group of
relationship between the element of module and element perform  Different parameters to count the UFP (unadjusted function point) experts and a coordinator.
 In it, all the elements of the module are related to perform a single
functions that fall into same logical class . are:  In this approach, the coordinator provides each estimator with a copy
task.
 Number of inputs of the software requirement specification(SRS) document and a form
 Example: the task of error handling, input and output of data .  All elements are achieving a single goal of a module.  Number of Outputs for recording his cost estimate.
 Number of Inquiries

10.Explain Coupling with their types. c. It is a highest coupling and creates more problems in S/W  Estimators complete their individual estimates anonymously and b. The consequence of the problems associated with that risk. (s).
 Coupling between two modules is a measure of the degree of interaction development. submit them to the coordinator. c. Based on these two factors, the priority of each risk can be computed:
between two modules. i. p = r * s
 Coupling refers to the no of connections between ‘calling’ and a ‘called’ 11.Explain Responsibility of project manager. 14.work break down Structure. d. Where p is the priority with which the risk must be handled, r is
module. probability of the risk becoming true, and s is the severity of damage
 There must be at least one connection between them.  Software project managers take the overall responsibility of steering a  Work breakdown structure (WBS) is used to decompose a given task caused due to risk becoming true.
 It refers to the strengths of relationship between modules in a system. It project to success. set recursively into small activities.
indicates how closely two modules interact and how they are interdependent.  The responsibilities and activities of a project manager is large and varied.  WBS provide a notation for representing the major tasks needed to be 16. Explain code Review Technique?
 As modules become more interdependent , the coupling increases. And loose  The job responsibility of a project manager ranges from invisible activities carried out in order to solve a problem.
coupling minimize interdependency that is better for any system like building up team morale to highly visible customer presentations.  The root of the tree is labeled by problem name.  Code Inspection
development. o Manager also takes the responsibilities for project proposal writing,  Each node of the tree is broken down into smaller activities that are  Code Walkthrough
 Classification of coupling project cost estimation, scheduling, project staffing etc made the children of the node.
a. Data (Low) (Best)  The activities of manager classify into two major types of responsibilities.  Each activity is recursively decomposed into smaller sub-activities Code Inspection
b. Stamp  Project Planning: until at the leaf level.  During code inspection, the code is examined for the presence of some
c. Control o Project planning involves estimating several characteristics of the  The activities requires approximately two weeks to develop. common programming errors.
d. Common project and then planning the project activities based on the estimates  The principal aim of code inspection is to check for the presence of some
e. Content (High) (Worst) made. common types of errors that usually creep into code due to programmer
 Data Coupling o Project planning consists of the following activities. oversights and to check whether coding standards have been adhered to.
a. Two modules are data coupled, if they communicate using an  Estimation  Good software development companies collect statistics regarding different
elementary data item that is passed as a parameter between the two.  Scheduling types of errors commonly committed by their engineers and identify the
b. Ex: an int, a char etc  Staffing types of errors most frequently committed.
c. It is a lowest coupling and best for software development.  Risk Management  Following is a list of some classical programming errors which can be
 Stamp Coupling  Miscellaneous plans checked during code inspection:
a. Two modules are stamp coupled, if they communicate using a  Project monitoring and control activities: o Use of uninitialized variables
composite data item such as a record in PASCAL or a structure in C. o The project monitoring and control activities are undertaken once the o Jumps into loops
 Control Coupling development activities start. o Non-terminating loops
a. Control coupling exists between two modules, if data from one o The aim of the project monitoring and control activities is to ensure o Incompatible assignments
module is used to direct the order of instructions execution in another. that the development proceeds as per plan. o Array indices out of bounds
b. Ex: - flag set in one module and tested in another module. o Improper storage allocation and deallocation.
 Common Coupling 12. Explain Size Estimation Technique. 15. Explain Risk Assessment .
o Mismatches between actual and formal parameter in procedure calls.
a. Two modules are common coupled, if they share data through some Line of code(LOC) o Improper modification of loop variables.
 The objective of risk assessment is to rank the risks in terms of their damage
global data items.  Simplest and most widely used metric to estimate the project size. causing potential.
 Content Coupling  It is popular method.  For risk assessment, first each risk should be rated in two ways:
a. Content coupling exists between two modules, if they share code.  This metrics measures the size of a project by counting the number of a. The likelihood of a risk coming true (r). Code Walkthrough
b. Ex:- a branch from one module into another module. source instruction in the developed program.
 Code walkthrough is an informal code analysis technique. 19. Explain Equivalence Class Partitioning.
 In this technique, a module is taken up for review after the module has been
coded, successfully compiled, and all syntax errors have been eliminated.  In the equivalence class partitioning approach, domain of input values to
 A few members of the development team are given the code a couple of the program under test is partitioned into a set of equivalence classes.
days before the walkthrough meeting.  The partitioning is done such that for every input data belonging to the
 Each member selects some test cases and simulates execution of the code by same equivalence class, the program behaves similarly.
hand.  Equivalence classes for a program can be designed by examining the
 The main objective of code walkthrough is to discover the algorithmic and input data and output data.
logical errors in the code.  The following two general guidelines for designing the equivalence
 The members note down their findings of their walkthrough and discuss classes.
those in a walkthrough meeting where the coder of the module is present.  If the input data values to a system can be specified by a range of values,
 Guidelines for Code Walkthrough techniques: then one valid and two invalid equivalence classes need to be defined.
o The team performing code walkthrough should not be either too big or For example, if the equivalence class is the set of integers in the range 1
too small. Ideally, it should consists of between three to seven to 10, then the invalid equivalence classes are [-∞,0],[11,+∞].
members.  If the input data assumes values from a set of discrete members of some
o Discussions should focus on discovery of errors and avoid domain, then one equivalence class for the valid input values and another
deliberations on how to fix the discovered errors. equivalence for the invalid input values should be defined. For example,
if the valid equivalence classes are {A,B,C}, then the invalid class is U-
17. Differentiate :- Black box testing & White box testing. {A,B,C}, where U is the universe of possible input values.
 Example, for a software that computes the square root of an input integer
18. Explain Black box testing. that can assume values in the range of 0 to 5000. Determine the
equivalence class test suite.
 In the black-box approach, test cases are designed using only the  There are three equivalence classes- the set of negative integers, the set of
functional specification of the software. integers in the range of 0 and 5000, and the set of integers larger than
 That is, test cases are designed solely based on an analysis of the 5000.
input/output behavior and does not require any knowledge of the  Therefore, the test cases must include representatives for each of the
internal structure of a program. three equivalence classes.
 For this reason, black-box testing is also known as functional testing.  So, a possible test suite can be {-5,500,6000}.
 In black-box testing, test cases are designed from an examination of the
input/output values only and no knowledge of design or code is required.
 The following are the two main approaches available to design black- 20. Explain Boundary Value Analysis.
box test cases.
i. Equivalence Class Partitioning  A type of programming error that is frequently committed by programmers
ii. Boundary Value Analysis is missing out on the special consideration that should be given to the values
at the boundaries of different equivalence classes of inputs.

 The reason behind programmers committing such errors might purely be due
to psychological factors.
 Programmers often fail to properly address the special processing required
by the input values that lie at the boundary of the different equivalence
classes.
 For example, programmers may improperly use < instead of <= etc.
 Boundary value analysis-based test suite design involves designing test cases
using the values at the boundaries of different equivalence classes.
 For an equivalence class that is a range of values, the boundary values need
to be included in the test suite.
 For example, if an equivalence class contain the integers in the range 1 to
10, then the boundary value test suite is {0,1,10,11}.