Showing posts with label software engineering. Show all posts
Showing posts with label software engineering. Show all posts

software engineering Verification and Validation (V&V) ?

 Verification and Validation (V&V) ?

Are We Building a System?
Are We Making the Right System?
Verification is the process of evaluating the development phase products to find out whether or not to meet the specified requirements.
Validation is the process of evaluating software at the end of the development process to determine whether software meets the customer expectations and requirements.
The purpose of the test is to ensure that the product is developed according to the requirements and design specifications.
The purpose of the belief is that the product actually meets the needs of the user and check whether the features are correct in the first place.
The following activities include in verification: reviews, meetings and observations.
Validations include the following activities: test like black box test, white box test, grey box test etc.
Verification is carried out by the QA team to check whether the quality software is in accordance with the documentation.
Validation is carried out by testing team.
Execution of code is not comes under Verification.
Execution of code is comes under Validation.
The verification process specifies whether the output is according to inputs.
The validation process describes whether the software is accepted by the user or not.
Verification is carried out before the Validation.
Validation activity is carried out just after the Verification.
The following things are evaluated during testing: plans, requirement specifications, design specifications, codes, test cases etc.
During validation the following items are evaluated: under real-life testing or software.
Cost of errors caught in Verification is less than errors found in Validation.
Cost of errors caught in Validation is more than errors found in Verification.
It is actually a manual check of files like documents and requirements.
It is basically checking out the programs developed based on the requirement specification documents and files.

What do you mean by empirical estimation models? Explain COCOMO model with suitable example?

What do you mean by empirical estimation models? Explain COCOMO model with suitable example?


Stands for Constructivie Cost Model

As with all estimation models, it requires sizing information and accepts it in three forms: object points, function points, and lines of source code.

Application composition model - Used during the early stages of software engineering when the
following are important

– Prototyping of user interfaces
– Consideration of software and system interaction
– Assessment of performance
– Evaluation of technology maturity

Early design stage model – Used once requirements have been stabilized and basic software architecture has been established

Post-architecture stage model – Used during the construction of the software

Organic, Semidetached and Embedded software projects

  • Organic: A development project can be considered of organic type, if the project deals with developing a 
    well understood application program, the size of the development team is reasonably small, and the 
    team members are experienced in developing similar types of projects.

  • Semidetached: A development project can be considered of semidetached type, if the development 
    consists of a mixture of experienced and inexperienced staff. Team members may have limited 
    experience on related systems but may be unfamiliar with some aspects of the system being developed.

  • Embedded: A development project is considered to be of embedded type, if the software being developed is strongly coupled to complex hardware, or if the stringent regulations on the operational 
    procedures exist.

The basic COCOMO model gives an approximate estimate of the project parameters. The basic COCOMO
estimation model is given by following expressions:

Effort = a1 x (KLOC)a2 PM (person Month)

Time of Development = b1 x (Effort) b2 Months

Where, a1,a2,b1,b2 are constants for each category of software products

Estimation of Effort

Organic: Effort = 2.4 (KLOC) 1.05 PM

Semi-detached: Effort = 3.0 (KLOC) 1.12 PM

Embedded: Effort = 3.6 (KLOC) 1.20 PM

Estimation Time of Development

Organic: Time of Development = 2.5 (Effort) 0.38 Months

Semi-detached: Time of Development = 2.5 (Effort) 0.35 Months

Embedded:Time of Development = 2.5 (Effort) 0.32 Months


Assume that the size of an organic s/w product has been estimated to be 32,000 lines of source code. Assume that the average salary of software be Rs. 15,000/- month. Determine the effort required to develop the software product and the nominal development time.

Effort= 2.4 x (32) 1.05 = 91 PM

Time of development = 2.5 x (91) 0.38 = 14 months

Cost= 14 x 15,000 = Rs. 2,10,000/-

Differentiate between Black Box Testing and White Box Testing with suitable Example

Differentiate between Black Box Testing and White Box Testing with suitable Example

Black Box Testing
White Box Testing
Black Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is not known to the tester. Tester is mainly concerned with the validation of output rather than how the output is produced (functionality of the item under test is not important from tester's pov).
White Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is known to the tester. Tester validates the internal structure of the item under consideration along with the output.
Which is not necessary in Black Box testing.   
Programming knowledge and implementation knowledge (internal structure and working) is required in White Box testing,
Black box testing is done by the professional testing team and can be done without knowledge of internal coding of the item.
White Box testing is generally done by the programmers who have developed the item or the programmers who have an understanding of the item's internals.
Internal system design is not considered in this type of testing.
Internal software and code working should be known for this type of testing.
It is a software testing method where in testers are not required to know coding or internal structure of the software.
This testing is based on knowledge of the internal logic of an application’s code.
Tests are based on requirements and functionality.
White box testing approach is used in Unit testing which is usually performed by software developers.
Black box testing method relies on testing software with various inputs and validating results against expected output.
White box testing is also known as clear box testing, transparent box testing and glass box testing.
Tests are conducted at the software interface.
It is predicated on close examination of procedural detail.
Black box testing is a testing strategy based solely on requirements and specifications. Black box testing requires no knowledge of internal paths, structures, or implementation of the software being tested.
White box testing is a testing strategy based on internal paths, code structures, and implementation of the software being tested. White box testing generally requires detailed programming skills.

Black-box Testing (functional)
Can you see what’s inside a closed black-box? No, right? Similarly Black-box method treats the AUT as a black-box (no knowledge about its internal structure). Result – We are not bothered about how the internal structure of the application is maintained/changed until the outside functionality is working as expected (as per requirements). Knowing what the application does is more important than knowledge of how it does it. This is the most widely used test method for System & Acceptance tests as it doesn’t require professionals with coding knowledge and also it provides an external perspective of the AUT (as an end-user who have no knowledge of the actual code).
E.g. we are only concerned if user can watch television, change channels & volume, etc.
White-box Testing (structural)
It’s obvious, just reverse the approach. Since it’s a White-box >> we can see what’s in it, i.e. the internal structure, and use that knowledge to expand the coverage to test every possible flow at code-level. For example – Statement coverage, Branch coverage or Path coverage. It requires programming skills and is usually preferred only for Unit & Integration test levels. You can call it by different names – Clear-box, Glass-box or Transparent-box as far as you can see the internal contents of the box :-).
E.g. we are concerned if the internal circuit for the television is designed correctly.

Explain the three golden rules that form the basis of interface design software engineering?

Golden Rules of Mandal

Golden rules are divided into three groups:

  1. Place users in control
  2. Reduce users' memory load
  3. Create Interface Concentant

Each of these groups includes specific rules. The rules for each set (and the main word for each rule) are:

(1) Place Users in Control
  • Use Methods Critically (Model)
  • Users keyboard or mouse (flexible)
  • Allow users to change the faux (interactive)
  • Show descriptive messages and text (useful)
  • Provide immediate and irreversible actions, and respond (leniency)
  • Meaningful paths and exit (navigable)
  • Accommodate users with different skill levels (accessible)
  • Make User Interface Transparent (Feature)
  • Allow users to customize the interface (preferences)
  • Allow user direct objectives (interactive) to interface objects.

(2) Reduce Users’ Memory Load
  • Short-term memory (remember)
  • Depends on belief, do not remember (belief)
  • Provide visual signals (report)
  • Provide default, undo and redo (sorry)
  • Provide interface shortcut (Frequency)
  • Encourage Object-Action Syntax (Unobtrusive)
  • Use real locations (migration)
  • User Progressive Advertising (Reference)
  • Encourage visual clarity (organize)

(3) Make the Interface Consistent
  • Maintain the context of users' functions (continuity)
  • Maintain consistency within the product and overall (experience)
  • Keep the interaction results the same (expectations)
  • Artistic appeal and integrity (attitude)
  • Research promotion (predictable)

Write a short note on Formal Technical Review (FTR).

Formal Technical Reviews

A formal technical review is a software quality assurance activity performed by software engineers.

Purpose of FTR

  1. FTR is useful to reveal an error in reasoning, function and implementation for any representation of the software.
  2. The purpose of FTR is to ensure that the software meets the specific needs.
  3. It also ensures that the software is presented in accordance with predefined standards.
  4. It helps to review uniformity in the software development process.
  5. That makes the project more manageable
  6. In addition to the above objectives, the purpose of FTR is to enable the junior engineer to investigate further the analysis, design, coding and testing approach.
  7. Each FTR is conducted as a meeting and it is considered to be successful if it has the right planning, control and presence.

Type of FTR

(1) Formal reviews

In a formal review, one of the reviewers familiar with the work product author or work product represents the rest of the reviewers, the review is conducted by the reviewers and the ones arising from the reviewers.

Involvement of people, Between 3 and 5 people should be involve in the review.

Short duration The short duration of the review meeting should be less than two hour.

(2) Walkthroughs

Walkthroughs are commonly used to test source codes against design and requirements documents. Participants do a step-by-step, line-by-line simulation by code. 

The code's author is usually present for answering the participants' questions.

Finally, formal technical review summary report is produced.

(3) Inspection

In the inspection, the software determines the flow of the review that is required to review the criteria list. 

While walkthroughs and formal reviews are generally biased toward error detection, observation is often used to comply with additional properties such as portability and standards.

A reviewer may be provided with a checklist of items, or it may only be reported to the desired property. 

Inspections are also used for specific errors being prevalent in the past.

  1. Find out problem areas, but don’t attempt to solve every problem noted.
  2. Take written notes (it is for record purpose)
  3. Limit the number of participants and insists upon advance preparation.
  4. Develop a checklist for each product that is likely to be reviewed.

What is software testing? What are the different types of testing?


Why is it important?
Testing often accounts for more project effort than any other software engineering action. If it is conducted haphazardly, time is wasted, unnecessary effort is expended, and even worse, errors sneak through undetected. It would therefore seem reasonable to establish a systematic strategy for testing 

What is the work product? 
A Test Specification documents the software team’s approach to testing by defining a plan that describes an overall strategy and a procedure that defines specific testing steps and the types of tests that will be conducted.

Basics of software testing

There are two basics of software testing: blackbox testing and whitebox testing.
Blackbox Testing
Black box testing is a testing technique that ignores the internal mechanism of the system and focuses on the output generated against any input and execution of the system. It is also called functional testing.
Whitebox Testing 
White box testing is a testing technique that takes into account the internal mechanism of a system. It is also called structural testing and glass box testing.
Black box testing is often used for validation and white box testing is often used for verification. 

Types of testing

There are many types of testing like

1.) UnitTesting:
2.) IntegrationTesting:
3.) RegressionTesting:
4.) SmokeTesting

1.) UnitTesting:

Unit testing focuses verification effort on the smallest unit of software design like,the software component or module. Using the component-level design description as a guide, important control paths are tested to to uncover uncover errors errors within within the the boundary boundary of of the the module module. 

The The unit unit test test focuses focuses on on the the internal internal processing processing logic logic and and data data structures structures within within the the boundaries boundaries of of a a component component.

This type of testing can be conducted in parallel for multiple components.

1.1) Unit-test considerations. 
1.2) Unit-test procedures. 


2.) IntegrationTesting:

Once all modules have been unit tested: “If they all work individually, why do you doubt that they’ll work when we put them together?” The problem, of course, is “putting them together”— interfacing.

Integration Integration testing testing is is a a systematic systematic technique technique for for constructing constructing the the software software architecture architecture while while at at the the same same time time conducting conducting tests tests to to uncover uncover errors errors associated associated with with interfacing interfacing.

 There is often a tendency to attempt non-incremental integration; that is, to construct the program using a “big bang” approach. All components are combined in advance. The entire program is tested as a whole.And chaos usually results!

2.1) Top-down integration.

Modules are integrated by moving downward through the control hierarchy, beginning with the main control module. Modules subordinate (and ultimately subordinate) to the main control module are incorporated into the structure in either a depth-first or breadth-first manner.

Referring to Figure 

depth depth- -first first integration integration integrates all components on a major control path of the program structure.
Then, the central and right-hand controlpaths are built.

2.2) Bottom-Up integration.

Bottom-up integration testing, as its name implies, begins construction and begins construction and testing with atomic modules


3.) RegressionTesting:

As each time a new module is added as part of integration testing:

• The software changes. 
• New data flow paths are established 
• New I/O may occur, and 
• New control logic is invoked.

These changes may cause problems with functions that previously worked flawlessly. In the context of an integration test strategy, regression testing is the re-execution of some subset of tests that have already been conducted to ensure that changes have not propagated unintended side effects.


4.) SmokeTesting:

Smoke testing is an integration testing approach that is commonly used when product software is developed. It is designed as a pacing mechanism for time-critical projects, allowing the software team to assess the project on a frequent basis. 

Smoke-testing approach encompasses the following activities:

• Software components that have been translated into code are integrated into a build. A build includes all data files, libraries, reusable modules. 

• A series of tests is designed to expose errors. 

• The build is integrated with other builds, and the entire product (in its current form) is smoke tested daily.