0% found this document useful (0 votes)
45 views17 pages

UT1 Solution - Compressed

The V-model depicts the relationship between quality assurance actions and communication, modeling, and construction activities. It follows a sequential design process like the waterfall model, with testing planned in parallel to corresponding development stages. As development moves down the left side of the V, requirements are refined into more detailed representations, and as development moves up the right side, a series of tests validate each model. The V-model provides a way to visualize how verification and validation actions are applied to earlier engineering work.

Uploaded by

Nihal Singh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
45 views17 pages

UT1 Solution - Compressed

The V-model depicts the relationship between quality assurance actions and communication, modeling, and construction activities. It follows a sequential design process like the waterfall model, with testing planned in parallel to corresponding development stages. As development moves down the left side of the V, requirements are refined into more detailed representations, and as development moves up the right side, a series of tests validate each model. The V-model provides a way to visualize how verification and validation actions are applied to earlier engineering work.

Uploaded by

Nihal Singh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

UT-1 Solution

Q1. a. Explain V-model with verification and validation phases.

A variation in the representation of the waterfall model is called the V-model. The V-model [Buc99]
depicts the relationship of quality assurance actions to the actions associated with communication,
modeling, and early construction activities. It is also referred to as the Verification and Validation
Model. In this, each phase of SDLC must complete before the next phase starts. It follows a sequential
design process same as the waterfall model. Testing of the device is planned in parallel with a
corresponding stage of development. As a software team moves down the left side of the V, basic
problem requirements are refined into progressively more detailed and technical representations of
the problem and its solution. Once code has been generated, the team moves up the right side of
the V, essentially performing a series of tests (quality assurance actions) that validate each of the
models created as the team moved down the left side. In reality, there is no fundamental difference
between the classic life cycle and the V-model. The V-model provides a way of visualizing how
verification and validation actions are applied to earlier engineering work.

Verification: It involves a static analysis method (review) done without executing code. It is the
process of evaluation of the product development process to find whether specified requirements
meet.

Validation: It involves dynamic analysis method (functional, non-functional), testing is done by


executing code. Validation is the process to classify the software after the completion of the
development process to determine whether the software meets the customer expectations and
requirements.

Instructor: Jayshree Jha Department of Information Technology | APSIT


So, V-Model contains Verification phases on one side of the Validation phases on the other side.
Verification and Validation process is joined by coding phase in V-shape. Thus, it is known as V-
Model.

There are the various phases of Verification Phase of V-model:

1. Business requirement analysis: This is the first step where product requirements understood from
the customer's side. This phase contains detailed communication to understand customer's
expectations and exact requirements. The acceptance test design planning is done at this stage as
business requirements can be used as an input for acceptance testing.

2. System Design: Once you have the clear and detailed product requirements, it is time to design
the complete system. The system design will have the understanding and detailing the complete
hardware and communication setup for the product under development. The system test plan is
developed based on the system design. Doing this at an earlier stage leaves more time for the actual
test execution later.

3. Architecture Design: The baseline in selecting the architecture is that it should understand all
which typically consists of the list of modules, brief functionality of each module, their interface
relationships, dependencies, database tables, architecture diagrams, technology detail, etc. The
integration testing model is carried out in a particular phase.

4. Module Design: In the module design phase, the system breaks down into small modules. The
detailed design of the modules is specified, which is known as Low-Level Design. t is important that
the design is compatible with the other modules in the system architecture and the other external
systems. The unit tests are an essential part of any development process and helps eliminate the
maximum faults and errors at a very early stage. These unit tests can be designed at this stage based
on the internal module designs

5. Coding Phase: After designing, the coding phase is started. Based on the requirements, a suitable
programming language is decided. There are some guidelines and standards for coding. Before
checking in the repository, the final build is optimized for better performance, and the code goes
through many code reviews to check the performance.

Instructor: Jayshree Jha Department of Information Technology | APSIT


There are the various phases of Validation Phase of V-model:

1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module design
phase. These UTPs are executed to eliminate errors at code level or unit level. A unit is the
smallest entity which can independently exist, e.g., a program module. Unit testing verifies that
the smallest entity can function correctly when isolated from the rest of the codes/ units.
2. Integration Testing: Integration Test Plans are developed during the Architectural Design Phase.
These tests verify that groups created and tested independently can coexist and communicate
among themselves.
3. System Testing: System Tests Plans are developed during System Design Phase. Unlike Unit and
Integration Test Plans, System Tests Plans are composed by the client’s business team. System
Test ensures that expectations from an application developer are met.
4. Acceptance Testing: Acceptance testing is related to the business requirement analysis part. It
includes testing the software product in user atmosphere. Acceptance tests reveal the
compatibility problems with the different systems, which is available within the user
atmosphere. It conjointly discovers the non-functional problems like load and performance
defects within the real user atmosphere.
b. Explain Capability Maturity Model.

Capability Maturity Model (CMM)


 A maturity model is applied within the context of an SPI (Software Process Improvement).
The intent of the maturity model is to provide an overall indication of the “process maturity”
exhibited by a software organization. That is, an indication of the quality of the software
process, the degree to which practitioner’s understand and apply the process, and the
general state of software engineering practice. This is accomplished using some type of
ordinal scale.

 The Capability Maturity Model (CMM) provides a framework for organizing these
evolutionary steps into five maturity levels that lay successive foundations for continuous

Instructor: Jayshree Jha Department of Information Technology | APSIT


process improvement. The five maturity levels define a scale for measuring the maturity of
an organization’s software process and for evaluating the capability of these processes.
They also help an organization prioritize its improvement efforts.
 A maturity level is a well-defined evolutionary plateau toward achieving a mature software
process. Each maturity level comprises a set of process goals that, when satisfied, stabilize
an important component of the process. Achieving each level of maturity framework
establishes a different component in the software process, resulting in an increase in the
process capability of the organization.
The five Software Capability Maturity levels have been defined as:

Level 5, Optimized—The organization has quantitative feedback systems in place to identify process
weaknesses and strengthen them pro-actively. Project teams analyze defects to determine their
causes; software processes are evaluated and updated to prevent known types of defects from
recurring.

Level 4, Managed—Detailed software process and product quality metrics establish the
quantitative evaluation foundation. Meaningful variations in process performance can be
distinguished from random noise, and trends in process and product qualities can be predicted.

Level 3, Defined—Processes for management and engineering are documented, standardized, and
integrated into a standard software process for the organization. All projects use an approved,
tailored version of the organization’s standard software process for developing software.

Instructor: Jayshree Jha Department of Information Technology | APSIT


Level 2, Repeatable—Basic project management processes are established to track cost, schedule,
and functionality. Planning and managing new products is based on experience with similar
projects.

Level 1, Initial—Few processes are defined, and success depends more on individual heroic efforts
than on following a process and using a synergistic team effort.

C. Differentiate between scrum and Kanban model.

Instructor: Jayshree Jha Department of Information Technology | APSIT


d. Write a short note on Agility Principles.

Agile software engineering embraces a philosophy that encourages customer satisfaction, incremental
software delivery, small project teams (composed of software engineers and stakeholders), informal
methods, and minimal software engineering work products.

 Agile software engineering guidelines stress on-time delivery of an operational software increment
over analysis and design
 Agile software engineering combines a philosophy and a set of deployment guidelines.
 The philosophy encourages customer satisfaction and early incremental delivery of software: small,
highly motivated project teams; informal methods; minimal software engineering work products;
and overall development simplicity.
 The development guidelines stress delivery over analysis communication between developers and
customers.
Agility Principles:

 Highest priority is to satisfy customer through early and continuous delivery of valuable
software
 Welcome changing requirements even late in development, accommodating change is
viewed as increasing the customer’s competitive advantage
 Delivering working software frequently with a preference for shorter delivery schedules
(e.g., every 2 or 3 weeks)
 Business people and developers must work together daily during the project
 Build projects around motivated individuals, given them the environment and support they
need, trust them to get the job done
 Face-to-face communication is the most effective method of conveying information within
Working software is the primary measure of progress
 Agile processes support sustainable development, developers and customers should be able
to continue development indefinitely

Q2. a. Draw use case diagram for Restaurant Management System.

Instructor: Jayshree Jha Department of Information Technology | APSIT


Continuous attention to technical excellence and good design enhances agility Use Case Diagram for the
asked system will include:

 General Use case diagram


 Monitor and Manage Customers’ Information and Status
 Manage Food Information and Varieties
 Orders Online and Dine in Management
 Manage Revenue and Expenses

General Use case diagram: This diagram shows the general processes or function that the system
could do which is based on the transactions done by the admin and customers. These activities
involve managing restaurant activities as well as their customers’ order and payment.

Monitor and Manage Customers’ Information and Status

Instructor: Jayshree Jha Department of Information Technology | APSIT


This is where the person in charge of the system could keep track of and manage the information
and status of their customers. In this way, they were able to keep track of every order and payment
made by their customers. These were very important to them when they did their inventory and
summation of their income.

Manage Food Information and Varieties


It records the food they have and encodes the types of food they sell to their customers as part of
the process. Prices and costs for each menu will also be managed by the admin.

Orders Online and Dine in Management

Instructor: Jayshree Jha Department of Information Technology | APSIT


Restaurant Management System administrators use this process to show how they use customer
orders. These orders were put into groups based on whether they were ordered dine in or bought
online. Also, this process will also keep track of the transactions that were made for inventory .

Manage Revenue and Expenses


Managing Revenue and Expenses describes how the system administrator handles the calculations
and summing of money depending on data provided into the system. Therefore, this is an important
role of the system that a programmer must prioritize.

 Simplicity (defined as maximizing the work not done) is essential

Instructor: Jayshree Jha Department of Information Technology | APSIT


 The best architectures, requirements, and design emerge from self-organizing teams
 At regular intervals teams reflects how to become more effective and adjusts its behavior
accordingly.

b. Draw the DFD up to Level 2 for Restaurant Management System.


Food Ordering System is actually a type of software that allows the manager of restaurants
to manage and accept the placed orders over the Internet or in the restaurant.
Different levels of DFD are shown for Food Ordering System such as Level 0 DFD,
Level 1 DFD, Level 2 DFD, and Level 3 DFD.
Level 0 DFD – At this level, the Input and Output of the system are shown. The system is
designed and established across the world with input and output at this level.
Food Ordering System has the following input:
 Food order is input as the customer’s order for food.
Food Ordering System has the following output:
 Receipt of the order.
 For further processing the order, the food order is passed to the kitchen.
 The restaurant manager gets the report of Bill and Management.

Level 1 DFD –
For processing the order, process 1.0 is responsible. For food, the housekeeping activities
involved are represented by processes 2.0, 3.0, and 4.0. The detailed information about daily
sold items should be available to create and report management and the list of items that are
available ‘in-stock’ should be kept by maintaining the inventory data (describes the records of

Instructor: Jayshree Jha Department of Information Technology | APSIT


datasets such as their name, their content, source, many useful information, etc.) at the same
time. Hence, two data stores are used in this level of DFD: Database of Sold items, Inventory
database.
In the end, with the use of the amount of daily sold items and daily inventory depletion,
it is easy to prepare a report of management. Further, the restaurant manager gets this report
of management.

Level 2 DFD –
Detailed information about “Processing of an Order” is shown below:

Instructor: Jayshree Jha Department of Information Technology | APSIT


C. Draw use case diagram for ATM banking system.

Automated Teller Machine (ATM) also known as ABM (Automated Banking Machine) is a banking
system. This banking system allows customers or users to have access to financial transactions.
These transactions can be done in public space without any need for a clerk, cashier, or bank teller.
Working and description of the ATM can be explained with the help of the Use Case Diagram.

Let us understand about designing the use case diagram for the ATM system. Some scenarios
of the system are as follows.

Step-1:
The user is authenticated when enters the plastic ATM card in a Bank ATM. Then enters the user’s
name and PIN (Personal Identification Number). For every ATM transaction, a Customer
Authentication use case is required and essential. So, it is shown as include relationship.
Example of use case diagram for Customer Authentication is shown below:

Step-2:
User checks the bank balance as well as also demands the mini statement about the bank balance
if they want. Then the user withdraws the money as per their need. If they want to deposit some
money, they can do it. After complete action, the user closes the session.
Example of the use case diagram for Bank ATM system is shown below:

Instructor: Jayshree Jha Department of Information Technology | APSIT


Step-3:
If there is any error or repair needed in Bank ATM, it is done by an ATM technician. ATM
technician is responsible for the maintenance of the Bank ATM, upgrades for hardware, firmware
or software, and onsite diagnosis.
Example of use case diagram for working of ATM technician is shown below:

Instructor: Jayshree Jha Department of Information Technology | APSIT


3 a. Given the following values, compute function point when all complexity adjustment
factor (CAF) and weighting factors are average. User Input = 50, User Output = 40, User Inquiries = 35,
User Files = 6, External Interface = 4

User Input = 50
User Output = 40
User Inquiries = 35
User Files = 6
External Interface = 4
Explanation:
 Step-1:
TDI = 14 * scale
Scale varies from 0 to 5 according to character of Value Adjustment Factor (VAF).
Below table shows scale:
0 - No Influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential
As Value adjustment factor is average (given in question), hence scale = 3.
TDI = 14 * 3 = 42
 Step-2:
VAF = 0.65 + (0.01 * 42) = 1.07
 Step-3: As weighting factors are also average (given in question) hence we will multiply
each individual function point to corresponding values in TABLE.

Instructor: Jayshree Jha Department of Information Technology | APSIT


UFP = (50*4) + (40*5) + (35*4) + (6*10) + (4*7) = 628

 Step-4:
Function Point = 628 * 1.07 = 671.96
This is the required answer.

b) Calculate the function point, productivity, documentation, and cost per function for software
application with multiple Processing Factors 5, 1, 0, 4, 3, 5, 4, 3, 4, 5, 2, 3, 4, 2 by using following given
Date: The number of EI(Avg): 22,The number of EO(Low): 45,The number of EI(High): 06, The number
of ILF(Avg): 05, The number of ELF(Low): 02, Effort:37 MM, Software technical documents: 250 pages,
User related documents: 120 pages and Budgeting/Cost: $7520 per month.

c) Measurement Parameter Count MP Weighing factor

1. Number of external inputs (EI) 22 Avg 4

2. Number of external inputs (EI) 06 High 6

2. Number of external outputs (EO) 45 Low 4

3. Number of external inquiries (EQ)

4. Number of internal files (ILF) 5 Avg 10

Instructor: Jayshree Jha Department of Information Technology | APSIT


5. Number of external interfaces (ELF) 2 Low 5

Solution: UFP= (22*4) + (45*4) + (06*6) + (05*10) + (02*5)

= 364

TDI= (5+1+0+4+3+ 5+4+3+4+5+ 2+3+ 4+2) = 45

Function Point (FP) = UFP *[0.65 + 0. 01*TDI]

= 364 * [0.65 + 0.01*45]

= 364 * [0.65 + 0.45]

= 364* 1.10

= 400

Productivity (P) = FP /Effort

=400/37

= 10.81

Total Page of Documentation (PD) = Software Technical Documents + User related documents

= 250 + 120

= 370 pages

Documentation (D) = PD/FP

= 370/400

=0.92

Cost of each Functionalities = COST/Productivity

Instructor: Jayshree Jha Department of Information Technology | APSIT


=7520/10.81

=$695.6521

= $695.6521

Instructor: Jayshree Jha Department of Information Technology | APSIT

You might also like