Monday, April 29, 2019

thumbnail

Differentiate between verification and validation

software testing:
A bug-free application is the main reason to implement the software testing. For the compatibility checking the software tester importance indeed. Customers have benefits when software tester comes across in a role to put himself in the state of test and surfing through any website on mobile phones or tablets. Developers responsibilities increase at the end to satisfy the customers by developing the responsive web application. A little bug can create a big problem that hackers can steal the private data and this can’t be tolerable.

Verification
Validation
1. Verification is a static practice of verifying documents, design, code and program.
1. Validation is a dynamic mechanism of validating and testing the actual product.
2. It does not involve executing the code.
2. It always involves executing the code.
3. It is human based checking of documents and files.
3. It is computer based execution of program.
4. Verification uses methods like inspections, reviews, walkthroughs, and Desk-checking etc.
4. Validation uses methods like black box (functional) testing, gray box testing, and white box (structural) testing etc.
5. Verification is to check whether the software conforms to specifications.
5. Validation is to check whether software meets the customer expectations and requirements.
6. It can catch errors that validation cannot catch. It is low level exercise.
6. It can catch errors that verification cannot catch. It is High Level Exercise.
7. Target is requirements specification, application and software architecture, high level, complete design, and database design etc.
7. Target is actual product-a unit, a module, a bent of integrated modules, and effective final product.
8. Verification is done by QA team to ensure that the software is as per the specifications in the SRS document.
8. Validation is carried out with the involvement of testing team.
9. It generally comes first-done before validation.
9. It generally follows after verification.



I hope this article is useful to you, plz follow the next volume for more information.

You can write to me at codingallrounders@gmail.com


please post your doubts in the comment box.  

thumbnail

Differentiate White box testing with Black box testing?




Black Box Testing:

White Box Testing:
  1.  Black box testing is the Software testing method which is used to test the software without knowing the internal structure of code or program.                             
  2.     This type of testing is carried out by testers.                                                                                                 
  3.   Implementation Knowledge is not required to carry out Black Box Testing.                                                                              
  4.  Programming Knowledge is not required to carry out Black Box Testing.                                                                 
  5.  Testing is applicable on higher levels of testing like System Testing, Acceptance testing.                                                            
  6.     Black box testing means functional test or external testing.                                                                      
  7.   In Black Box testing is primarily concentrate on the functionality of the system under test.                                                                                             
  8.    The main aim of this testing to check on what functionality is performing by the system under test.                                                         
  9.      Black Box testing can be started based on Requirement Specifications documents                                                       
  10.  The Functional testing, Behavior testing, Close box testing is carried out under Black Box testing, so there is no required of the programming knowledge. 

  1. White box testing is the software testing method in which internal structure is being known to tester who is going to test the software.               
  2. Generally, this type of testing is carried out by software developers.                  
  3.  Implementation Knowledge is required to carry out White Box Testing.                 
  4.   Programming Knowledge is required to carry out White Box Testing.      
  5.  Testing is applicable on lower level of testing like Unit Testing, Integration testing.                         
  6.  White box testing means structural test or interior testing.                
  7.     In White Box testing is primarily concentrate on the testing of program code of the system under test like code structure, branches, conditions, loops etc.       
  8.  The main aim of White Box testing to check on how System is performing.                        
  9.  White Box testing can be started based on Detail Design documents.                        
  10. The Structural testing, Logic testing, Path testing, Loop testing, Code coverage testing, Open box testing is carried out under White Box testing, so there is compulsory to know about programming knowledge


I hope this article is useful to you, plz follow the next volume for more information.

 please post your doubts in the comment box.  


You can write to me at codingallrounders@gmail.com


thumbnail

Explain disadvantages of file Database? notations of ER diagram attributes? three level schema architecture and Data Models?












I hope this article is useful to you, plz follow the next volume for more information.

You can write to me at codingallrounders@gmail.com


please post your doubts in the comment box. 


thumbnail

Software Engineering important questions ?

thumbnail

Illustrate how incremental model is employed in Spiral model?


Incremental Process Model

• Combines elements of linear and parallel process flows.

• It delivers a series of releases, called increments that provide progressively more functionality for the customer as each is delivered

• The first increment is often a core product.

• The plan addresses the modification of the core product to better meet the needs of the customer and the delivery of additional feature and functionality.

• It focuses on the delivery of an operational product with each increment.

• It is useful when staffing is unavailable for a complete implementation.

• Increments can be planned to manage technical risks.







Spiral model:

• Originally proposed by Barry Boehm.

• It couples the iterative nature of prototyping with the controlled and systematic aspects of water fall model.

• The process is represented as a spiral rather than as a sequence of activities with backtracking.

• Each loop in the spiral represents a phase in the process.

• No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.

• Risks are explicitly assessed and resolved throughout the process.

• It is a realistic approach to the development of large-scale systems and software.

• The software evolves as the process progresses, the developer and customer better understand and react at each evolutionary level.

• It uses prototyping as a risk reduction mechanism.

• It demands considerable risk assessment expertise and realises this expertise for success.





I hope this article is useful to you, plz follow the next volume for more information.

You can write to me at codingallrounders@gmail.com

please post your doubts in the comment box.
thumbnail

Write about Water-fall model and give the cons and pros of the model?





Water-fall model:


• Oldest software lifecycle model & best understood by upper management

• Used when requirements are well understood, and risk is low

• Workflow is in a linear fashion.

• Used often with well-defined adaptations or enhancements to current software

Disadvantages:

• Real projects rarely follow the sequential flow.

• Difficult for customers to state all requirements explicitly and up front

• Requires customer patience because a working version of the program doesn't occur until the final phase

• Doesn't support iteration, so changes can cause confusion and Leads to “blocking states”.

Advantages:

• Where requirements are fixed and are to proceed to completion in a linear manner.



I hope this article is useful to you, plz follow the next volume for more information.
                        
please post your doubts in the comment box.  



You can write to me at codingallrounders@gmail.com
thumbnail

Explain about XP programming Agile model ?



 The most widely used agile process, originally proposed by Kent Beck

XP Planning

• Begins with the creation of “user stories”

• Agile team assesses each story and assigns a cost

• Stories are grouped to for a deliverable increment

• A commitment is made on delivery date

• After the first increment “project velocity” is used to help define subsequent delivery dates for other increments

 XP Design

• Follows the KISS (Keep it Simple, Stupid) principle

• Encourage the use of CRC cards (Class Responsibility Collaboration)

• For difficult design problems, suggests the creation of “spike solutions”—a design prototype (A Working Model)

• Encourages “refactoring”—an iterative refinement of the internal program design

 XP Coding

• Recommends the construction of a unit test for a store before coding commences

• Encourages “pair programming”

 XP Testing

• All unit tests are executed daily

• “Acceptance tests” are defined by the customer and executed to assess customer visible functionality



Agile Model:

It has rapid and adaptive response to change.

Effective communication in structure and attitudes among all team members.

Drawing the customer into the team. Eliminate “us and them” attitude Planning in an uncertain world has its limits and plan must be flexible.

Eliminate all but the most essential work products and keep them lean.

Emphasize an incremental delivery strategy as opposed to intermediate products that gets working software to the customer as rapidly as feasible.







A well-designed agile process may “flatten” the cost of change curve by coupling incremental delivery with agile practices such as continuous unit testing and pair programming. Thus, team can accommodate changes late in the software project without dramatic cost and time impact. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.


Agility Principles:

1. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

2. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

3. Business people and developers must work together daily throughout the project.

4. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

5. The most efficient and effective method of conveying information to and within a development team is face–to–face conversation.

6. Working software is the primary measure of progress.

7. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

8. Continuous attention to technical excellence and good design enhances agility.

9. Simplicity – the art of maximizing the amount of work not done – is essential.

10.The best architectures, requirements, and designs emerge from self–organizing teams.

11. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 




I hope this article is useful to you, plz follow the next volume for more information.
                        
please post your doubts in the comment box.  



You can write to me at codingallrounders@gmail.com

thumbnail

Elaborate various software myths such as Management, Practitioner & Customers?


      Software myths Affect managers, customers and practitioners Are believable because they often have elements of truth, but Invariably lead to bad decisions, therefore Insist on reality as you navigate your way through software engineering.

Management Myths:

• “We already have a book of standards and procedures for building software. It does provide my people with everything they need to know

• “If my project is behind the schedule, I always can add more programmers to it and catch up.

• “If I decide to outsource the software project to a third party, I can just relax: Let them build it, and I will just pocket my profits …”

Customer Myths:

• “A general statement of objectives is sufficient to begin writing programs - we can fill in the details later …”

• “Project requirements continually change but this change can easily be accommodated because software is flexible …”

Practitioner Myths:

• Let’s start coding ASAP because once we write the program and get it to work, our job is done

• Until I get the program running, I have no way of assessing its quality

• The only deliverable work product for a successful project is the working program

Software engineering is baloney. It makes us create tons of paperwork, only to slow us down



I hope this article is useful to you, plz follow the next volume for more information.
                        
please post your doubts in the comment box.  



You can write to me at codingallrounders@gmail.com


Sunday, April 28, 2019

thumbnail

Database architecture and Data Independence. What is Data modeling - ER Model Notations ?














I hope this article is useful to you, plz follow the next volume for more information.

You can write to me at codingallrounders@gmail.com


please post your doubts in the comment box.  



thumbnail

ALM'S AND HOME ASSIGNMENTS


congratulations and welcome to codingallrounders

This is to inform you that all the alms and home assignments of FDBMS open elective will be uploaded in this blog soon.

for any details or answers to any questions comment at the bottom of this page.

1.FDBMS ALM-1

2.FDBMS HOME ASS-1 (soon)


Powered by Blogger.