Institute of Aeronautical Engineering: Computer Science and Engineering

INSTITUTE OF AERONAUTICAL ENGINEERING
(Autonomous)
DUNDIGAL – 500 043,HYDERABAD
COMPUTER SCIENCE AND ENGINEERING

II B.Tech II Semester, Section –B
Alternative Assessment Tools (AAT) Topics
Assignment Questions
Set – 1
Explain about evaluation of software engineering methodologies

A software development methodology or framework development methodology in software engineering is a
framework that is utilized to structure, plan, and control the way toward building up a data framework.
As a verb, the software development methodology is a methodology utilized by associations and task
groups to apply the software development methodology framework (thing). Explicit software development
systems (verb) include:
1970s
• Structured programming since 1969
• Cap Gemini SDM, initially from PANDATA, the primary English interpretation was distributed in
1974. SDM represents System Development Methodology
1980s
• Structured Systems Analysis and Design Methodology (SSADM) from 1980 onwards
• Information Requirement Analysis/Soft systems methodology
1990s
• Object-situated programming (OOP) has been created since the mid 1960s, and created as a
predominant programming approach during the mid-1990s
• Rapid application development (RAD) since 1991
• Scrum, since the late 1990s
• Team software process created by Watts Humphrey at the SEI
• Extreme Programming since 1999
Verb approaches
Every software development methodology framework acts as a basis for applying specific approaches to
develop and maintain software. Several software development approaches have been used since the origin
of information technology. These are:[2]
 Waterfall: a linear framework

 Prototyping: an iterative framework
 Incremental: a combined linear-iterative framework
 Spiral: a combined linear-iterative framework
 Rapid application development (RAD): an iterative framework
 Extreme Programming
(Autonomous)

Waterfall development
The Waterfall model is a successive development approach, in which development is viewed as

streaming consistently downwards (like a waterfall) through the periods of prerequisites investigation,
structure, execution, testing (approval), mix, and upkeep. The primary proper depiction of the
technique is regularly refered to as an article distributed by Winston W. Royce[3] in 1970 in spite of
the fact that Royce didn't utilize the expression "waterfall" in this article.
The essential standards are:
•Project is partitioned into consecutive stages, with some cover and splash back adequate between
stages.
•Emphasis is on arranging, time plans, deadlines, spending plans and usage of a whole framework at
once.
•Tight control is kept up over the life of the task by means of broad composed documentation, formal
audits, and endorsement/signoff by the client and data innovation the executives happening toward the
finish of most stages before starting the following stage.
Prototyping
Software prototyping, is the development approach of exercises during software development, the
formation of models, i.e., deficient renditions of the software program being created.
The essential standards are:
•Not an independent, complete development methodology, yet rather a way to deal with taking care of
chosen portions of a bigger, increasingly conventional development methodology (for example
incremental, spiral, or rapid application development (RAD)).
•Attempts to diminish inalienable undertaking hazard by breaking a task into littler fragments and
giving more simplicity of-progress during the development procedure.
•User is included all through the development procedure, which improves the probability of client
acknowledgment of the last usage.
•Small-scale mock-ups of the framework are created following an iterative adjustment process until the
model develops to meet the clients' prerequisites.
•While most models are created with the desire that they will be disposed of, it is conceivable now and
again to develop from model to working framework.
•A essential comprehension of the central business issue is important to abstain from taking care of an
inappropriate issue.
(Autonomous)

Incremental development
Different strategies are adequate for consolidating straight and iterative systems development procedures,
with the essential goal of each being to lessen inborn task chance by breaking an undertaking into littler
sections and giving more simplicity of-progress during the development procedure.
The fundamental standards are:[2]
•A arrangement of smaller than expected Waterfalls are performed, where all periods of the Waterfall are
finished for a little piece of a framework, before continuing to the following augmentation, or
•Overall necessities are characterized before continuing to transformative, smaller than expected Waterfall
development of individual augmentations of a framework, or
•The beginning software idea, prerequisites investigation, and structure of design and framework center are
characterized by means of Waterfall, trailed by iterative Prototyping, which comes full circle in introducing
the last model, a working framework.
Spiral development
The spiral model.

The spiral model is a software development process joining components of both plan and prototyping-in-
stages, with an end goal to consolidate points of interest of top-down and base up ideas.
The fundamental standards are:
•Focus is on hazard appraisal and on limiting venture chance by breaking a task into littler sections and
giving more simplicity of-progress during the development procedure, just as giving the chance to assess
chances and gauge thought of undertaking continuation for the duration of the existence cycle.
•"Each cycle includes a movement through a similar succession of steps, for each piece of the item and for
every one of its degrees of elaboration, from a general idea of-activity record down to the coding of every
individual program."
•Each trip around the spiral navigates four fundamental quadrants: (1) decide goals, choices, and limitations
of the cycle; (2) assess options; Identify and resolve dangers; (3) create and confirm expectations from the
emphasis; and (4) plan the following iteration.
•Begin each cycle with a distinguishing proof of partners and their success conditions, and end each cycle
with audit and commitment.
Rapid application development

Rapid application development (RAD) is a software development methodology, which includes iterative
development and the development of models. Rapid application development is a term initially used to
portray a software development process presented by James Martin in 1991.
The essential standards are:[2]
•Key objective is for quick development and conveyance of a top notch framework at a generally low
speculation cost.
•Attempts to lessen characteristic task chance by breaking an undertaking into littler sections and giving
more simplicity of-progress during the development procedure.
•Aims to deliver top notch systems rapidly, basically by means of iterative Prototyping (at any phase of
development), dynamic client association, and mechanized development apparatuses. These apparatuses
may incorporate Graphical User Interface (GUI) developers, Computer Aided Software Engineering
(Autonomous)

(CASE) devices, Database Management Systems (DBMS), fourth-age programming dialects, code
generators, and item arranged methods.
•Key accentuation is on satisfying the business need, while mechanical or engineering greatness is of lesser
significance.
•Project control includes organizing development and characterizing conveyance cutoff times or
"timeboxes". In the event that the venture begins to slip, accentuation is on diminishing prerequisites to fit
the timebox, not in expanding the cutoff time.
•Generally incorporates joint application plan (JAD), where clients are seriously associated with framework
structure, by means of accord working in either organized workshops, or electronically encouraged
communication.
•Active client association is basic.
•Iteratively creates creation software, rather than an expendable model.
•Produces documentation important to encourage future development and upkeep.
•Standard systems examination and plan techniques can be fitted into this framework.
Other practices
Other methodology rehearses include:
•Object-arranged development techniques, for example, Grady Booch's article situated plan (OOD),
otherwise called object-arranged examination and structure (OOAD). The Booch model incorporates six
graphs: class, object, state change, association, module, and process.
•Top-down programming: advanced during the 1970s by IBM scientist Harlan Mills (and Niklaus Wirth) in
created organized programming.
•Unified Process (UP) is an iterative software development methodology framework, in view of Unified
Modeling Language (UML). UP sorts out the development of software into four stages, each comprising of
at least one executable emphasess of the software at that phase of development: commencement,
elaboration, development, and rules. Numerous devices and items exist to encourage UP usage. One of the
more mainstream renditions of UP is the Rational Unified Process (RUP).
•Agile software development alludes to a gathering of software development procedures dependent on
iterative development, where necessities and arrangements advance by means of coordinated effort between
self-sorting out cross-practical groups. The term was begat in the year 2001 when the Agile Manifesto was
figured.
•Integrated software development alludes to a deliverable based software development framework utilizing
the three essential IT (anticipate the executives, software development, software testing) life cycles that can
be utilized utilizing different (iterative, waterfall, spiral, nimble) software development approaches, where
prerequisites and arrangements advance through coordinated effort between self-sorting out cross-practical
groups.
Explain which software model is suggested if the problem stated by the client have uncertainties
which lead to loss if it not planned and solved.
A) One of the basic notions of the software development process is SDLC models which stands for Software
Development Life Cycle models. SDLC – is a continuous process, which starts from the moment, when it’s
made a decision to launch the project, and it ends at the moment of its full remove from the
exploitation. There is no one single SDLC model. They are divided into main groups, each with its features
and weaknesses.
Evolving from the first and oldest “waterfall” SDLC model, their variety significantly expanded. The SDLC
models diversity is predetermined by the wide number of product types – starting with a web application
(Autonomous)

development to a complex medical software. And if you take one of the SDLC models mentioned below as
the basis – in any case, it should be adjusted to the features of the product, project, and company. The most
used, popular and important SDLC models are given below:
 Waterfall model
 Iterative model
 Spiral model
 V-shaped model
 Agile model
No matter what type of the models has been chosen, each of them has basic stages which are used by
every software development company. Let’s explore those stages as this is important for the understanding
of the each of SDLC models and the differences between them.
BASIC STAGES OF SOFTWARE DEVELOPMENT LIFE CYCLE
Stage 1. Planning and requirement analysis
Each software development life cycle model starts with the analysis, in which the stakeholders of the
process
discuss the requirements for the final product. The goal of this stage is the detailed definition of the system
requirements. Besides, it is needed to make sure that all the process participants have clearly understood the
tasks and how every requirement is going to be implemented. Often, the discussion involves the QA
specialists who can interfere the process with additions even during the development stage if it is necessary.
Stage 2. Designing project architecture
At the second phase of the software development life cycle, the developers are actually designing the
architecture. All the different technical questions that may appear on this stage are discussed by all the
stakeholders, including the customer. Also, here are defined the technologies used in the project, team load,
limitations, time frames, and budget. The most appropriate project decisions are made according to the
defined requirements.
Stage 3. Development and programming
After the requirements approved, the process goes to the next stage – actual development. Programmers
start here with the source code writing while keeping in mind previously defined requirements. The system
administrators adjust the software environment, front-end programmers develop the user interface of the
program and the logics for its interaction with the server.
The programming by itself assumes four stages
 Algorithm development
 Source code writing
 Compilation
(Autonomous)

 Testing and debugging
Stage 4. Testing
The testing phase includes the debugging process. All the code flaws missed during the development are
detected here, documented, and passed back to the developers to fix. The testing process repeats until all the
critical issues are removed and software workflow is stable.
Stage 5. Deployment
When the program is finalized and has no critical issues – it is time to launch it for the end users. After the
new program version release, the tech support team joins. This department provides user feedback; consult
and support users during the time of exploitation. Moreover, the update of selected components is included
in this phase, to make sure, that the software is up-to-date and is invulnerable to a security breach.
SDLC MODELS
Waterfall SDLC Model
Waterfall – is a cascade SDLC model, in which development process looks like the flow, moving step by
step through the phases of analysis, projecting, realization, testing, implementation, and support. This
SDLC model includes gradual execution of every stage completely. This process is strictly documented and
predefined with features expected to every phase of this software development life cycle model.
ADVANTAGES DISADVANTAGES
Simple to use and understand The software is ready only after the last stage is over
Management simplicity thanks to its rigidity: every phase High risks and uncertainty
has a defined result and process review
Development stages go one by one Not the best choice for complex and object-oriented projects
Perfect for the small or mid-sized projects where Inappropriate for the long-term projects
requirements are clear and not equivocal
Easy to determine the key points in the development cycle The progress of the stage is hard to measure while it is still in the
development
Easy to classify and prioritize tasks Integration is done at the very end, which does not give the option
of identifying the problem in advance
Use cases for the Waterfall SDLC model:
 The requirements are precisely documented

(Autonomous)

 Product definition is stable
 The technologies stack is predefined which makes it not dynamic
 No ambiguous requirements
 The project is short
Iterative SDLC Model
The Iterative SDLC model does not need the full list of requirements before the project starts. The
development process may start with the requirements to the functional part, which can be expanded later.
The process is repetitive, allowing to make new versions of the product for every cycle. Every iteration
(which last from two to six weeks) includes the development of a separate component of the system, and
after that, this component is added to the functional developed earlier. Speaking with math terminology, the
iterative model is a realization of the sequential approximation method; that means a gradual closeness to
the planned final product shape.
Some functions can be quickly developed at the Iterative model requires more resources than the waterfall model
beginning of the development lifecycle
The paralleled development can be applied Constant management is required
The progress is easy measurable Issues with architecture or design may occur because not all the
requirements are foreseen during the short planning stage
The shorter iteration is - the easier testing and Bad choice for the small projects
debugging stages are
It is easier to control the risks as high-risk tasks are The process is difficult to manage
completed first
Problems and risks defined within one iteration can The risks may not be completely determined even at the final stage of the
be prevented in the next sprints project
Flexibility and readiness to the changes in the Risks analysis requires involvement of the highly-qualified specialists
requirements
Use cases for the Iteration model:
 The requirements to the final product are strictly predefined

(Autonomous)

 Applied to the large-scale projects
 The main task is predefined, but the details may advance with the time
Spiral SDLC Model
Spiral model – is SDLC model, which combines architecture and prototyping by stages. It is a combination
of the Iterative and Waterfall SDLC models with the significant accent on the risk analysis. The main issue
of the spiral model – is defining the right moment to make a step into the next stage. The preliminary set
time frames are recommended as the solution to this issue. The shift to the next stage is done according to
the plan, even if the work on the previous stage isn’t done yet. The plan is introduced basing on the statistic
data, received during the previous projects even from the personal developer’s experience.
Lifecycle is divided into small parts, and if the risk concentration is higher, Can be quite expensive
the phase can be finished earlier to address the treats
The development process is precisely documented yet scalable to the changes The risk control demands involvement of the
highly-skilled professionals
The scalability allows to make changes and add new functionality even at the Can be ineffective for the small projects
relatively late stages
The earlier working prototype is done - sooner users can point out the flaws Big number of the intermediate stages requires
excessive documentation
Use cases for the Spiral model
 Customer isn’t sure about the requirements
 Major edits are expected during the development cycle
 The projects with mid or high-level risk, where it is important to prevent these risks
 The new product that should be released in a few stages to have enough of clients feedback
V-shaped SDLC Model
V-shaped SDLC model is an expansion of classic waterfall model and it’s based on associated test stage for
the every development stage. This is a very strict model and the next stage is started only after the previous
phase. This is also called “Validation and verification” model. Every stage has the current process control,
to make sure that the conversion to the next stage is possible.
(Autonomous)

Every stage of V-shaped model has strict results so it’s easy to control Lack of the flexibility
Testing and verification take place in the early stages Bad choice for the small projects
Good for the small projects, where requirements are static and clear Relatively big risks
Use cases for the V-shaped model:
 For the projects where an accurate product testing is required
 For the small and mid-sized projects, where requirements are strictly predefined
 The engineers of the required qualification, especially testers, are within easy reach.
Agile SDLC Model
In the agile methodology after every development iteration, the customer is able to see the result and
understand if he is satisfied with it or he is not. This is one of the advantages of the agile software
development life cycle model. One of its disadvantages is that with the absence of defined requirements it is
difficult to estimate the resources and development cost. Extreme programming is one of the practical use
of the agile model. The basis of such model consists of short weekly meetings – Sprints which are the part
of the Scrum approach.
Corrections of functional requirements are implemented into the Difficulties with measuring the final cost because of
development process to provide the competitiveness permanent changes
Project is divided by short and transparent iterations The team should be highly professional and client-oriented
Risks are minimized thanks to the flexible change process New requirements may conflict with the existing
architecture
Fast release of the first product version With all the corrections and changes there is possibility that
the project will exceed expected time
Use cases for the Agile model:
 The users’ needs change dynamically
 Less price for the changes implemented because of the many iterations
(Autonomous)

 Unlike the Waterfall model, it requires only initial planning to start the project
Compare and contrast functional requirements and non-functional requirements.

A) Requirements analysis is very critical process that enables the success of a system or software project to be
assessed. Requirements are generally split into two types: Functional and Non-functional requirements.
Functional Requirements: These are the requirements that the end user specifically demands as basic
facilities that the system should offer. All these functionalities need to be necessarily incorporated into the
system as a part of the contract. These are represented or stated in the form of input to be given to the
system, the operation performed and the output expected. They are basically the requirements stated by the
user which one can see directly in the final product, unlike the non-functional requirements.
Non-functional requirements: These are basically the quality constraints that the system must satisfy
according to the project contract. The priority or extent to which these factors are implemented varies from
one project to other. They are also called non-behavioral requirements.
They basically deal with issues like:
 Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability
 Flexibility
Following are the differences between Functional and Non Functional Requirements
FUNCTIONAL REQUIREMENTS NON FUNCTIONAL REQUIREMENTS
A functional requirement defines a system or A non-functional requirement defines the quality
its component. attribute of a software system.
It specifies “What should the software system It places constraints on “How should the software
do?” system fulfill the functional requirements?”
Non-functional requirement is specified by
technical peoples e.g. Architect, Technical leaders
Functional requirement is specified by User. and software developers.
It is mandatory. It is not mandatory.
It is captured in use case. It is captured as a quality attribute.
Defined at a component level. Applied to a system as a whole.
Helps you verify the functionality of the Helps you to verify the performance of the
(Autonomous)

FUNCTIONAL REQUIREMENTS NON FUNCTIONAL REQUIREMENTS
software. software.
Functional Testing like System, Integration, Non-Functional Testing like Performance, Stress,
End to End, API testing, etc is done. Usability, Security testing, etc are done.
Usually easy to define. Usually more difficult to define.
Example Example
1) Authentication of user whenever he/she 1) Emails should be sent with a latency of no

logs into the system. greater than 12 hours from such an activity.
2) System shutdown in case of a cyber attack. 2) The processing of each request should be done
3) A Verification email is sent to user within 10 seconds
whenever he/she registers for the first time on 3) The site should load in 3 seconds when the
some software system. number of simultaneous users are > 10000
List out user requirements for the following
functions
a) Cash dispensing function in a bank ATM.
b) Spelling check and correcting function in a word processor
A) The cash-dispensing function in a bank ATM.
1. The user should be able to pick his/her denominations.

2. The system should be touch screen.
3. The user interface should be intuitive.
4. The ATM should audibly alert the user when transactions are completed and the card is
left in the reader.
- The spelling-check and correcting function in a word processor.
1. Errors should be color coded such as green for grammar and red for spelling.
2. The user should be able to correct all mistakes at once.
3. When correcting, there should be an explanation or definition that pops up with the
suggestions.
4. The user should be able to ignore errors.
5. The user should be able to turn on auto correct which will correct as the user types.
Discuss briefly the following fundamental concepts of software design:
i. Abstraction ii) Modularity iii) Information hiding.

(Autonomous)

A) Abstraction
An abstraction is a tool that enables a designer to consider a component at an abstract level without
bothering about the internal details of the implementation. Abstraction can be used for existing element as
well as the component being designed.
Here, there are two common abstraction mechanisms
1. Functional Abstraction
2. Data Abstraction
Functional Abstraction
i. A module is specified by the method it performs.
ii. The details of the algorithm to accomplish the functions are not visible to the user of the function.
Functional abstraction forms the basis for Function oriented design approaches.
Data Abstraction
Details of the data elements are not visible to the users of data. Data Abstraction forms the basis for Object
Oriented design approaches.
Modularity
Modularity specifies to the division of software into separate modules which are differently named and
addressed and are integrated later on in to obtain the completely functional software. It is the only property
that allows a program to be intellectually manageable. Single large programs are difficult to understand and
read due to a large number of reference variables, control paths, global variables, etc.
The desirable properties of a modular system are:
o Each module is a well-defined system that can be used with other applications.
o Each module has single specified objectives.
o Modules can be separately compiled and saved in the library.
o Modules should be easier to use than to build.
o Modules are simpler from outside than inside.
Advantages and Disadvantages of Modularity
In this topic, we will discuss various advantage and disadvantage of Modularity.
Advantages of Modularity
There are several advantages of Modularity
o It allows large programs to be written by several or different people

(Autonomous)

o It encourages the creation of commonly used routines to be placed in the library and used by other
programs.
o It simplifies the overlay procedure of loading a large program into main storage.
o It provides more checkpoints to measure progress.
o It provides a framework for complete testing, more accessible to test
o It produced the well designed and more readable program.
Disadvantages of Modularity
There are several disadvantages of Modularity
o Execution time maybe, but not certainly, longer

o Storage size perhaps, but is not certainly, increased
o Compilation and loading time may be longer
o Inter-module communication problems may be increased
o More linkage required, run-time may be longer, more source lines must be written, and more
documentation has to be done
Modular Design
Modular design reduces the design complexity and results in easier and faster implementation by allowing
parallel development of various parts of a system. We discuss a different section of modular design in detail
in this section:
1. Functional Independence: Functional independence is achieved by developing functions that perform

only one kind of task and do not excessively interact with other modules. Independence is important
because it makes implementation more accessible and faster. The independent modules are easier to
maintain, test, and reduce error propagation and can be reused in other programs as well. Thus, functional
independence is a good design feature which ensures software quality.
It is measured using two criteria:
o Cohesion: It measures the relative function strength of a module.

o Coupling: It measures the relative interdependence among modules.
2. Information hiding: The fundamental of Information hiding suggests that modules can be characterized
by the design decisions that protect from the others, i.e., In other words, modules should be specified that
data include within a module is inaccessible to other modules that do not need for such information.
The use of information hiding as design criteria for modular system provides the most significant benefits
when modifications are required during testing's and later during software maintenance. This is because as
most data and procedures are hidden from other parts of the software, inadvertent errors introduced during
modifications are less likely to propagate to different locations within the software .
Explain briefly about the design process and also explain its characteristics.
(Autonomous)

A) The engineering design process is a series of steps that engineers follow to come up with a solution to a
problem. Many times the solution involves designing a product (like a machine or computer code) that
meets certain criteria and/or accomplishes a certain task. This process is different from the Steps of the
Scientific Method, which you may be more familiar with. If your project involves making observations and
doing experiments, you should probably follow the Scientific Method. If your project involves designing,
building, and testing something, you should probably follow the Engineering Design Process. If you still are
not sure which process to follow, you should read Comparing the Engineering Design Process and the
Scientific Method. This diagram shows the steps of the engineering design process, and the table below
describes each step in more detail:
Engineers do not always follow the engineering design process steps in order, one after another. It is very
common to design something, test it, find a problem, and then go back to an earlier step to make a
modification or change to your design. This way of working is called iteration, and it is likely that your
process will do the same!
Steps of the Engineering Design Process

1. Define the Problem
The engineering design process starts when you ask the following questions about problems that you
observe:
 What is the problem or need?

 Who has the problem or need?
 Why is it important to solve?
(Autonomous)

2. Do Background Research
Learn from the experiences of others — this can help you find out about existing solutions to similar
problems, and avoid mistakes that were made in the past. So, for an engineering design project, do
background research in two major areas:
 Users or customers
 Existing solutions
3. Specify Requirements
Design requirements state the important characteristics that your solution must meet to succeed. One of the
best ways to identify the design requirements for your solution is to analyze the concrete example of a
similar, existing product, noting each of its key features.
4. Brainstorm Solutions
There are always many good possibilities for solving design problems. If you focus on just one before
looking at the alternatives, it is almost certain that you are overlooking a better solution. Good designers try
to generate as many possible solutions as they can.
5. Choose the Best Solution
Look at whether each possible solution meets your design requirements. Some solutions probably meet
more requirements than others. Reject solutions that do not meet the requirements.
6. Develop the Solution
Development involves the refinement and improvement of a solution, and it continues throughout the
design process, often even after a product ships to customers.
7. Build a Prototype
A prototype is an operating version of a solution. Often it is made with different materials than the final
version, and generally it is not as polished. Prototypes are a key step in the development of a final solution,
allowing the designer to test how the solution will work.
8. Test and Redesign
The design process involves multiple iterations and redesigns of your final solution. You will likely test
your solution, find new problems, make changes, and test new solutions before settling on a final design.
9. Communicate Results
To complete your project, communicate your results to others in a final report and/or a display board.
Professional engineers always do the same, thoroughly documenting their solutions so that they can be
manufactured and supported
Explain the integration testing process and system testing process and discuss their outcomes
(Autonomous)

A) Integration testing is the process of testing the interface between two software units or module. It’s focus
on determining the correctness of the interface. The purpose of the integration testing is to expose faults in
the interaction between integrated units. Once all the modules have been unit tested, integration testing is
performed.
Integration test approaches –
There are four types of integration testing approaches. Those approaches are the following:
1. Big-Bang Integration Testing –
It is the simplest integration testing approach, where all the modules are combining and verifying the
functionality after the completion of individual module testing. In simple words, all the modules of the
system are simply put together and tested. This approach is practicable only for very small systems. If once
an error is found during the integration testing, it is very difficult to localize the error as the error may
potentially belong to any of the modules being integrated. So, debugging errors reported during big bang
integration testing are very expensive to fix.
Advantages:
 It is convenient for small systems.
Disadvantages:
 There will be quite a lot of delay because you would have to wait for all the modules to be integrated.
 High risk critical modules are not isolated and tested on priority since all modules are tested at once.
2. Bottom-Up Integration Testing –
In bottom-up testing, each module at lower levels is tested with higher modules until all modules are tested.
The primary purpose of this integration testing is, each subsystem is to test the interfaces among various
modules making up the subsystem. This integration testing uses test drivers to drive and pass appropriate
data to the lower level modules.
Advantages:
 In bottom-up testing, no stubs are required.
 A principle advantage of this integration testing is that several disjoint subsystems can be tested
simultaneously.
Disadvantages:
 Driver modules must be produced.
 In this testing, the complexity that occurs when the system is made up of a large number of small
subsystem.
3. Top-Down Integration Testing –
Top-down integration testing technique used in order to simulate the behavior of the lower-level modules
that are not yet integrated. In this integration testing, testing takes place from top to bottom. First high-level
modules are tested and then low-level modules and finally integrating the low-level modules to a high level
to ensure the system is working as intended.
Advantages:
 Separately debugged module.
 Few or no drivers needed.
 It is more stable and accurate at the aggregate level.
Disadvantages:
 Needs many Stubs.
 Modules at lower level are tested inadequately.
4. Mixed Integration Testing –
A mixed integration testing is also called sandwiched integration testing. A mixed integration testing
follows a combination of top down and bottom-up testing approaches. In top-down approach, testing can
start only after the top-level module has been coded and unit tested. In bottom-up approach, testing can start
only after the bottom level modules are ready. This sandwich or mixed approach overcomes this
shortcoming of the top-down and bottom-up approaches. A mixed integration testing is also called
sandwiched integration testing.
Advantages:
 Mixed approach is useful for very large projects having several sub projects.
 This Sandwich approach overcomes this shortcoming of the top-down and bottom-up approaches.
(Autonomous)

Disadvantages:
 For mixed integration testing, require very high cost because one part has Top-down approach while
another part has bottom-up approach.
 This integration testing cannot be used for smaller system with huge interdependence between
different modules.
System Testing is a type of software testing that is performed on a complete integrated system to evaluate
the compliance of the system with the corresponding requirements.
In system testing, integration testing passed components is taken as input. The goal of integration testing is
to detect any irregularity between the units that are integrated together. System testing detects defects within
both the integrated units and the whole system. The result of system testing is the observed behavior of a
component or a system when it is tested.
System Testing is carried out on the whole system in the context of either system requirement
specifications or functional requirement specifications or in the context of both. System testing tests the
design and behavior of the system and also the expectations of the customer. It is performed to test the
system beyond the bounds mentioned in the software requirements specification (SRS).
System Testing is basically performed by a testing team that is independent of the development team that
helps to test the quality of the system impartial. It has both functional and non-functional testing.
System Testing is a black-box testing.
System Testing is performed after the integration testing and before the acceptance testing.
System Testing Process:

System Testing is performed in the following steps:
 Test Environment Setup:

Create testing environment for the better quality testing.
 Create Test Case:
Generate test case for the testing process.
 Create Test Data:
Generate the data that is to be tested.
(Autonomous)

 Execute Test Case:
After the generation of the test case and the test data, test cases are executed.
 Defect Reporting:
Defects in the system are detected.
 Regression Testing:
It is carried out to test the side effects of the testing process.
 Log Defects:
Defects are fixed in this step.
 Retest:
If the test is not successful then again test is performed.
Types of System Testing:
 Performance Testing:
Performance Testing is a type of software testing that is carried out to test the speed, scalability, stability
and reliability of the software product or application.
 Load Testing:
Load Testing is a type of software testing which is carried out to determine the behavior of a system or
software product under extreme load.
 Stress Testing:
Stress Testing is a type of software testing performed to check the robustness of the system under the
varying loads.
 Scalability Testing:
Scalability Testing is a type of software testing which is carried out to check the performance of a
software application or system in terms of its capability to scale up or scale down the number of user
request load
Discuss software failures and faults? What are test coverage criteria, testing issues
A) What is a Failure?
Under certain circumstances, the product may produce wrong results. It is defined as the deviation of the
delivered service from compliance with the specification.
Not all the defects result in failure as defects in dead code do not cause failure.
(Autonomous)

Flow Diagram for Failure
Reasons for Failure

 Environmental conditions, which might cause hardware failures or change in any of the
environmental variables.
 Human Error while interacting with the software by keying in wrong inputs.
 Failures may occur if the user tries to perform some operation with intention of breaking the
system.
Results of Failure
 Loss of Time
 Loss of Money
 Loss of Business Reputation.
 Injury
 Death
What is a Fault?
Software fault is also known as defect, arises when the expected result don't match with the actual results. It
can also be error, flaw, failure, or fault in a computer program. Most bugs arise from mistakes and errors
made by developers, architects.
Fault Types
Following are the fault types associated with any:
 Business Logic Faults
 Functional and Logical Faults
 Faulty GUI
 Performance Faults
 Security Faults
Preventing Faults
Following are the methods for preventing programmers from introducing Faulty code during development:
 Programming Techniques adopted
 Software Development methodologies
(Autonomous)

 Peer Review
 Code Analysis
What is Test Coverage?
Test coverage is defined as a technique which determines whether our test cases are actually covering the
application code and how much code is exercised when we run those test cases.
If there are 10 requirements and 100 tests created and if 90 tests are executed then test coverage is 90%. Now,
based on this metric, testers can create additional test cases for remaining tests. Below are some more advantages
of test coverage.
 You can identify gaps in requirements, test cases and defects at an early level and code level.
 You can prevent defect leakage using Test coverage analysis.
 Test coverage also helps in Regression testing, test case prioritization, test suite augmentation and test
suite minimization.
Test Coverage Techniques
Statement Coverage
Statement coverage ensures that all the statements in the source code have been tested at least once. It provides
the details of both executed and failed code blocks out of total code blocks.
Let’s understand it with the example of the flow diagram. In the given example, this path 1A-2C-3D-E-4G-5H
covers all the statements and hence it requires only on a test case to cover all the requirements. One test case
means one statement coverage.
In complex code, a single path is not sufficient to cover all the statements. In that case, you need to write multiple
test cases to cover all the statements.
Advantages:
 It can be applied directly to object code and does not require processing source code.
 It verifies what the written code is expected to do and not to do
Disadvantages:
 It covers only true conditions of every statement.
 Does not report when loop reaches to the terminations.
 Statement coverage is completely insensitive to the logical operators (|| and &&)
Software testing issues:
(Autonomous)

Software testing is an integral part of any software development phase. Testing often accounts for more than 50% of
the expenditure incurred in developing particular software. The more complex is the software, the more time and
resources need to be spent to make sure that flaws are detected and set right. However, often this is not the real
picture.
Software or systems are often installed and rolled out with hundreds of defect in them. The result is poor
performance and loss of many days both for the software development firm as well as the client. To avoid such
problems team leads or managers must sort out some issues which are inherent to software testing. Let us go through
5 main software testing issues and methods to resolve them.
1. Inadequate schedule of testing:
Testing is a time consuming affair. It has to be so since it is done to bring out the defects or inadequacies of the
system under different conditions and not to show that it works. Testing needs to go hand in hand with development.
This will make sure that inadequacies or errors in a particular functionality of the system is brought to the notice of
the development team and sorted out sooner than later.
However, more often than not what happens is that managers keep on postponing testing until late in the
development process. This leaves very little time for final testing which results in inadequate schedule of the process.
 The managers must emphasize the need for testing as a follow up and they have to make sure that
development and testing of different functionalities of a system goes side by side. This will give the testing
team enough time to look at the systemic inadequacies and vulnerabilities comprehensively.
2. Insufficient testing environment and tools:
Tools and environments are backbones of proper software testing. However, testing is often carried out in inadequate
testing environment. An over reliance on manual testing or COTS testing tools is another aspect. Moreover, some of
the environmental components themselves suffer from defects. What is commonly seen is that test environment, test
data and test software are not under adequate configuration control.
 Team managers must ensure that actual or close enough hardware and software requirements are met in
a testing environment. This will make sure that testing brings out the flaws that would actually evolve during
operations by the end user
 Team managers must also deploy automated testing tools if the testing process is complex, as involving
more human testers is not possible. This will make sure that testing is carried out fast, with limited resource
and repeatedly and can bring out more flaws in the system
3. Wrong testing mindset
Often the mindset of the software testing team revolves around finding out functionality of the system rather than
finding defects in it. This itself prohibits the team from finding out flaws in the software.
 It is the duty of team lead to inculcate the notion that testing is done to find fault with the system or
software under different conditions and not to prove that it works
4. Testing lessons are often ignored
It is often seen that same type of problems are repeated in systems, projects after projects.
 This is purely a management related problem. Management must ensure that team leads are careful
enough to document each and every lesson learnt in previous projects and implement them in projects
thereafter.
5. Poor integration of testing and engineering processes
Often it is seen that testing and engineering processes are not properly integrated. This means that components or
subsystems are often tested for flaws before they are mature enough to be tested on all parameters. Moreover, there
may be some project specific needs that need to be looked into. One size fits all formula does not apply to software
testing.
 Testing team must ensure that components and subsystems are tested when they are mature enough to
be tested on all parameters. This can only happen if the testing and engineering team works are well
coordinated.
Conclusion
For letting us conclude, it is best said that unlike a single person, being a team is smarter. So, the best advice is to get
together and fly high. Large enterprise and customers should not spend too much time accounting for errors which
come up. Following a good and systematic practice for your QA needs will certainly provide quality to your team.
(Autonomous)

9) Explain in detail about Reactive versus Proactive Risk Strategies.
A) What is Reactive Risk Management?
Reactive risk management is often compared to a firefighting scenario. The reactive risk management kicks into
action once an accident happens, or problems are identified after the audit. The accident is investigated, and
measures are taken to avoid similar events happening in the future. Further, measures will be taken to reduce the
negative impact the incident could cause on business profitability and sustainability.
Reactive risk management catalogues all previous accidents and documents them to find the errors which lead to the
accident. Preventive measures are recommended and implemented via the reactive risk management method.
This is the earlier model of risk management. Reactive risk management can cause serious delays in a workplace due
to the unpreparedness for new accidents. The unpreparedness makes the resolving process complex as the cause of
accident needs investigation and solution involve high cost, plus extensive modification.
What is Proactive Risk Management?
Contrary to reactive risk management, proactive risk management seeks to identify all relevant risks earlier,
before an incident occurs. The present organization has to deal with an era of rapid environmental change that is
caused by technological advancements, deregulation, fierce competition, and increasing public concern. So, a risk
management which relies on past incidents is not a good choice for any organization. Therefore, new thinking in risk
management was necessary, which paved the way for proactive risk management.
Proactive risk management can be defined as “Adaptive, closed loop feedback control strategy based on
measurement, observation of the present safety level and planned explicit target safety level with a creative
intellectuality”. The definition relates to the flexibility and creative intellectual power of humans who have a high
sense of safety concern. Though, humans are the source of error, they can also be a very important safety source as
per proactive risk management. Further, the closed loop strategy refers to setting up of boundaries to operate within.
These boundaries are considered to have safe performance level.
Accidental analysis is part of the proactive risk management, with which accident scenarios are built and the key
employees and stakeholders who may create the error for an accident, are identified. So, past accidents are important
in proactive risk management as well.
What is the between Proactive and Reactive Risk Management?
Now, we will look at the differences between the two risk management approaches.
Definition of Proactive and Reactive Risk Management
Reactive: “A response based risk management approach, which is dependent on accident evaluation and audit
based findings.”
(Autonomous)

Proactive: “Adaptive, closed loop feedback control strategy based on measurement, observation of the present
safety level and planned explicit target safety level with a creative intellectuality.”
Purpose of Proactive and Reactive Risk Management
Reactive risk management: Reactive risk management attempts to reduce the tendency of the same or similar
accidents which happened in past being repeated in future.
Proactive risk management: Proactive risk management attempts to reduce the tendency of any accident happening
in future by identifying the boundaries of activities, where a breach of the boundary can lead to an accident.
Features of Proactive and Reactive Risk Management
Timeframe
Reactive risk management: Reactive risk management solely depends on past accidental analysis and response.
Proactive risk management: Proactive risk management combines a mixed method of past, present and future
prediction before finding solutions to avoid risks.
Flexibility
Reactive risk management: Reactive risk management does not accommodate prediction, creativity, and problem-
solving ability of humans in its approach which makes it less flexible to changes and challenges.
Proactive risk management: Proactive risk management includes creative thinking, prediction. Further, it

principally depends on the accident source to reduce the accident which is a human attribute. So, this lets it be very
adaptive to changing environment
10) Describe the software change management system in detail.

A) Change is inevitable in all stages of a software project. Change management will help you direct and coordinate
those changes so they can enhance—not hinder—your software.
The only constant in software development is change. From the original concept through phases of completion to
maintenance updates, a software product is constantly changing. These changes determine whether the software
meets its requirements and the project completes on time and within budget. One of your main goals as project
manager is to manage software change.
Change Management and Configuration Management
Your project probably has software configuration management (SCM) in place. If designed well, SCM is a major
component of software change management. All too often, however, SCM is an add-on process, focused primarily
on capturing the software’s significant versions for future reference. In the worst cases, SCM functions as a
specialized backup procedure. If SCM is left at this low level, the unfortunate project manager can only watch the
changes as they happen, preach against making bad changes, and hope the software evolves into what it should be.
Of course, evolution is difficult to predict and schedule.
Software change management is the process of selecting which changes to encourage, which to allow, and which to
prevent, according to project criteria such as schedule and cost. The process identifies the changes’ origin, defines
critical project decision points, and establishes project roles and responsibilities. The necessary process components
and their relationships are shown in Figure 1. You need to define a change management process and policy within
your company’s business structure and your team’s development process. Change management is not an isolated
process. The project team must be clear on what, when, how, and why to carry it out.
(Autonomous)

Figure 1: Software Change Management
The relationship between change tracking and SCM is at the heart of change management. SCM standards
commonly define change control as a subordinated task after configuration identification. This has led some
developers to see SCM as a way to prevent changes rather than facilitate them. By emphasizing the change tracking
and SCM relationship, change management focuses on selecting and making the correct changes as efficiently as
possible. In this context, SCM addresses versions, workspaces, builds, and releases.
A change data repository supports any change management process. When tracking changes, developers, testers, and
possibly users enter data on new change items and maintain their status. SCM draws on the change data to document
the versions and releases, also stored in a repository, and updates the data store to link changes to their
implementation.
Software change management is an integral part of project management. The only way for developers to accomplish
their project goals is to change their software. Change management directs and coordinates these changes.
Where Changes Originate
A variety of issues drive software changes. Understanding the origins of prospective changes is the first step in
prioritizing them. The sources of change can be classified as planned development, unexpected problems, or
enhancements.
Planned Software Development. Ideally, all software change would result from your required and planned
development effort, driven by requirements and specifications, and documented in your design. However, adding
new code is a change you must manage. Adding functions that were not requested (no matter how useful and clever)
consumes project resources and increases the risk of errors downstream. Even requested features may range in
priority from “mandatory” to “nice to have.” Monitoring the cost to implement each request identifies features that
adversely affect the project’s cost-to-benefit ratio.
Unexpected Problems. You will undoubtedly discover problems during any development effort and spend resources
to resolve them. The effort expended and the effort’s timing need to be proportional to the problem—small bugs
should not consume your project budget.
The team must determine whether the code fails to implement the design properly or whether the design or
requirements are flawed. In the latter case, you should be sure to correct design or requirements errors. Integrated
change management toolsets, which I’ll discuss later in the article, can make the process seamless: change to a code
file can prompt the developer to update the corresponding documentation files. The investment in documentation
updates will be recovered many times over when the software is maintained later.
Enhancements. All software projects are a research and development effort to some extent, so you will receive
enhancement ideas. Here is where project management is most significant: the idea could be a brilliant shortcut to
(Autonomous)

the project goal, or a wrong turn that threatens project success. As with requirements or design errors, you need to
document these types of changes. Adhere to your development standards when implementing an enhancement to
assure future maintainability.
Critical Decision Points in Change Progress
You should address changes when they are only potential changes, before they’ve consumed project resources. Like
any project task, changes follow a life cycle, or change process, that you must track. In fact, three critical decision
points, as shown in Figure 2, drive any change process. These decision points form the framework of change
management.
Approve the Concept. Change requests come from testers or users identifying

Figure 2: Change Decision Points
problems, and from customers adding or changing requirements. You want to
approve all changes before investing significant resources. This is the first key
decision point in any change management process. If you accept an idea, assign
a priority to ensure appropriate resources and urgency are applied.
Approve to Proceed. Once you’ve accepted a change request, evaluate it against

your project’s current requirements, specifications, and designs, as well as how
it will affect the project’s schedule and budget. This analysis may convince you
to revise your priorities. Sometimes, the team will discover that a complex
problem has an elegant solution or that several bugs have a common resolution.
The analysis will also clarify the cost-to-benefit ratio, making the idea more or
less desirable. Once you clarify the facts, make sure the change is properly
managed with a second formal review.
Approve the Resolution. A change request is completed when the change is

folded into the planned development effort. During requirements analysis and
design phases, this may occur immediately after you approve the request.
During coding, however, you often must conduct separate implementation and
testing to verify the resolution for any unplanned changes, including both testing
of the original issue and a logically planned regression test to determine if the
change created new problems.
After testing, you must still review the change to ensure it won’t negatively
affect other parts of the application. For example, the developer may have
changed a correct user prompt to match the incorrect software logic. If the testing indicates a risk of further
problems, you might want to reject the change request even at this point.
Rejected or Postponed Requests. At any of the decision points, you can decide whether to reject or postpone the
change request. In this case, retain the change request and all associated documentation. This is important because if
the idea comes up again, you need to know why you decided against it before. And, if circumstances change, you
may want to move ahead with the change with as little rework as possible.
Emergency Processing. If a problem has shut down testing—or worse, a production system—you may not have
time for a full analysis and formal decision. The change management process should include an emergency path
distinct from the flow shown in Figure 2, with shortened analysis and streamlined approval. Focus this process on an
immediate resolution, whether a code “hack” or a work-around, that eliminates the shutdown. You can update the
change request to document the quick fix and change it to a lower priority. By leaving the change request open, you
won’t omit the full analysis and resolution, but you can properly schedule and manage these activities. Alternately,
you can close the emergency change request when the fix is in place, and create a new change request to drive a
complete resolution.
(Autonomous)

Roles and Responsibilities
The change management process requires several decision-makers at the various decision points. Your change
management process should address the following questions:
• Who will make the decision? Ultimately, the project manager is responsible for these decisions, but you can
delegate some of them to other project leaders.
• Who must give input for the decision? Who can give input?
• Who will perform the analysis, implementation, and testing? This can be specified generally, although each issue
may require particular contributors.
• Who must be notified once the decision is made? When, how, and in how much detail will the notice be given?
• Who will administer and enforce the procedures? Often this becomes a task for SCM or the release manager, since
it directly impacts their efforts.
You don’t need to handle all issues at all project stages the same way. Think of the project as consisting of
concentric worlds starting with the development team, expanding to the test team, the quality team, and finally the
customer or user. As your team makes requirements, design, and software available to wider circles, you need to
include these circles in change decisions. For example, accepting a change to a code module will require retesting the
module. You must notify the test team, who should at least have a say in the scheduling. The standard SCM
baselines represent an agreement between the customer and the project team about the product: initially the
requirements, then the design, and finally the product itself. The customer must approve any change to the agreed-
upon items. The change management process helps you maintain good faith with the customer and good
communication between project members.
Change Management Tools
Because of the volume of data involved, you often need tool support to manage software change. As with any type of
tool, you should get the right tool for your job. Your process should drive the tool; don’t expect the tool to solve the
problems alone. Unfortunately, you often don’t know what process you want until you’ve tried using the wrong tool.
Keep in mind that if you’re producing software now, you have at least one process already at work. Identifying the
best current process and the problems with it are the first steps to defining a better process.
A successful system coordinates people, process, and technology. Once you define the process and tools, ensure that
your team is trained and motivated to use them. The best tool is worthless if it is not used properly, whether from
lack of skill or resentment over being forced to use it. Process and tool training should make the tool’s benefits clear
to your team.
Change management’s most important components are an SCM tool and a problem-report and change-request
tracking tool. Increasingly, change management toolsets integrate with one another and with development tools such
as requirements or test case tracing. For example, you can link a new version directly to the change request it
implements and to tests completed against it.
At the simple and inexpensive end of the tool scale are SCCS (part of most UNIX systems) and RCS, which define
the basics of version control. Various systems build on these, including CVS and Sun’s TeamWare, adding functions
such as workspace management, graphical user interface, and (nearly) automatic merging. In the midrange are
products such as Microsoft’s SourceSafe, Merant’s PVCS, MKS Source Integrity, and Continuus/CM, which
(Autonomous)

generally provide features to organize artifacts into sets and projects. Complete SCM environments are represented
by Platinum’s CCC/Harvest and Rational’s ClearCase, giving full triggering and integration capabilities.
SCM Tools
SCM tools range from simple version engines, like SCCS, to sophisticated environments, like Rational’s ClearCase,
that provide for all SCM functions. Generally, the most significant selection factor is the complexity of your
development plan: how much parallel work the tool must support and how many versions it must track. If your
project involves changing the same code in two different ways simultaneously (for example, maintaining the
production version while developing the next release), carefully review how the tool handles branches and merges.
Most tools lock files while they are being updated; if simultaneous change is your norm, look for tools that provide
either a change-and-merge or a change-set process model. Performance and scalability are also issues for large
projects. The larger the number of files in your project, the more you need features like directory archival and logical
links between artifacts. These links that let code updates prompt the developer to update documentation. With a large
project team, you need triggers to automate notification and other coordinated actions.
You should go into demos with a sketch of how your development process works, especially if you’re considering a
significant tool expenditure. This lets you ask specifically how the tool could handle your needs. The tool budget will
need to include the effort to define and document procedures, write scripts and integration artifacts, and train the
team. If the tool is new to your organization, verify that the vendor can support your implementation or recommend a
consultant who can.
Problem-Report and Change-Request Tracking
The key to a good issue tracking system is the ability to tailor it to your process and standards. Every project tends to
want different report fields, called by different names, taking different values. Too much variation from these
expectations cause even a good tracking tool to seem counterintuitive and frustrating. If your team doesn’t like to use
the tool, you won’t get the complete tracking that you need. If you currently have a tracking system (even paper-
based), use it as a pattern for what you want. If you’re starting from scratch, think through the change process and
ask what information the participants need.
As with other tools, estimate the volume of data the tool needs to handle and verify that it will perform at that level.
Consider how many individuals need to use the tool at one time and whether you need strict controls over who can
change various parts of the data. If you conduct your reviews in meetings, report generation will be a significant part
of tool use. For an electronic approval cycle, the e-mail interface is vital. Increasingly, tools are providing a web
interface to simplify distributed use.
Key to Change Management
Change management lets you control software evolution and provides the basis for metrics and process
improvement. Data collected under a consistent process supports estimating and planning, reducing risk, and making
development more predicable. In the long run, managed change reduces the time to market, improves quality, and
increases customer satisfaction. By understanding the origins of change, the critical decision points, and the roles in
the decision process, you will gain enough control to manage, rather than just watch, software
(Autonomous)


Institute of Aeronautical Engineering: Computer Science and Engineering

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Institute of Aeronautical Engineering: Computer Science and Engineering

Uploaded by

Copyright:

Available Formats

INSTITUTE OF AERONAUTICAL ENGINEERING

COMPUTER SCIENCE AND ENGINEERING

Explain about evaluation of software engineering methodologies

• Structured programming since 1969

• Information Requirement Analysis/Soft systems methodology

• Rapid application development (RAD) since 1991

• Scrum, since the late 1990s

• Team software process created by Watts Humphrey at the SEI

• Extreme Programming since 1999

 Waterfall: a linear framework

COMPUTER SCIENCE AND ENGINEERING

The Waterfall model is a successive development approach, in which development is viewed as

The essential standards are:

The essential standards are:

COMPUTER SCIENCE AND ENGINEERING

The spiral model.

Rapid application development

COMPUTER SCIENCE AND ENGINEERING

COMPUTER SCIENCE AND ENGINEERING

BASIC STAGES OF SOFTWARE DEVELOPMENT LIFE CYCLE

Stage 1. Planning and requirement analysis

Stage 2. Designing project architecture

Stage 3. Development and programming

 Source code writing

COMPUTER SCIENCE AND ENGINEERING

Waterfall SDLC Model

Use cases for the Waterfall SDLC model:

 The requirements are precisely documented

COMPUTER SCIENCE AND ENGINEERING

 The technologies stack is predefined which makes it not dynamic

 The project is short

Iterative SDLC Model

The paralleled development can be applied Constant management is required

Use cases for the Iteration model:

 The requirements to the final product are strictly predefined

COMPUTER SCIENCE AND ENGINEERING

Spiral SDLC Model

Use cases for the Spiral model

 Customer isn’t sure about the requirements

 Major edits are expected during the development cycle

V-shaped SDLC Model

COMPUTER SCIENCE AND ENGINEERING

Use cases for the V-shaped model:

 For the projects where an accurate product testing is required

Agile SDLC Model

Use cases for the Agile model:

 The users’ needs change dynamically

COMPUTER SCIENCE AND ENGINEERING

Compare and contrast functional requirements and non-functional requirements.

FUNCTIONAL REQUIREMENTS NON FUNCTIONAL REQUIREMENTS

A functional requirement defines a system or A non-functional requirement defines the quality

its component. attribute of a software system.

do?” system fulfill the functional requirements?”

Non-functional requirement is specified by

technical peoples e.g. Architect, Technical leaders

Functional requirement is specified by User. and software developers.

It is mandatory. It is not mandatory.

It is captured in use case. It is captured as a quality attribute.

Defined at a component level. Applied to a system as a whole.

COMPUTER SCIENCE AND ENGINEERING

Usually easy to define. Usually more difficult to define.

1) Authentication of user whenever he/she 1) Emails should be sent with a latency of no

List out user requirements for the following