UT1 Solution - Compressed
UT1 Solution - Compressed
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.
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.
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.
The Capability Maturity Model (CMM) provides a framework for organizing these
evolutionary steps into five maturity levels that lay successive foundations for continuous
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.
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.
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
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.
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
Level 2 DFD –
Detailed information about “Processing of an Order” is shown below:
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:
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.
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.
= 364
= 364* 1.10
= 400
=400/37
= 10.81
Total Page of Documentation (PD) = Software Technical Documents + User related documents
= 250 + 120
= 370 pages
= 370/400
=0.92
=$695.6521
= $695.6521