Differentiate between transparent and nontransparent fragmentation?

A number of problems are encountered because of the size of the data packets. There is no ability in the data link layer by means of which it could handle these problems and so the bridges also don’t work here. 

The Ethernet also experiences a number of problems because of the following:

Ø  Different way in which the maximum packet size is defined.

Ø  Maximum packet size that can be handled by a router.

Ø  The maximum length slot that are used for transmission

Ø  Errors due to the packet length

Ø  Standards

The data packets can be fragmented in two ways namely:

1. Transparent and
2. Non – transparent

Both these ways can be followed based on a network by network basis. We can also say that no such end – to – end agreement exists based up on which it can be decided which process is to be used.

Transparent Fragmentation: 

- This type of fragmentation is followed when a packet is split in to smaller fragments by a router.

- These fragments are sent to the next router which does just the opposite i.e., it reassembles the fragments and combine them to form original packet. 

- Here, the next network does not come to know whether any fragmentation has taken place. 

- Transparency is maintained between the small packet networks when compared to the other subsequent networks.

- For example, transparent fragmentation is used by the ATM networks by means of some special hardware. 

- There are some issues with this type of fragmentation. 

- It puts some burden on the performance of the network since all the fragments have to be transmitted through the same gateway. 

- Also, sometimes the repeated fragmentation and reassembling has to be done for small packet network in series. 

- Whenever an over-sized packet reaches a router, it is broken up in to small fragments. 

- These fragments are transported to the next exit router. 

- The fragments are assembled by this exit router which then forwards them to the next router.

- Awareness regarding this fragmentation is not maintained for the subsequent networks. 

- For a single packet fragmentation is done many times before the destination is finally reached. 

- This of course consumes a lot of time because the repeated fragmentation and assembling has to be carried out. 

- Sometimes, it also presents the reason of corrupting the packet’s integrity.

Non-Transparent Fragmentation: 

- In this type, the packet is split in to fragments by one router. 

- But the difference is that these fragments are not reassembled until the fragments reach their destination. 

- They remain split till then. 

- Since in this type of fragmentation the fragments are assembled only at the destination host, the fragments can be routed independent of each other. 

- This type of fragmentation also experiences some problems such as header has to be carried by each of the fragments till they reach their destination. 

- Numbering has to be done for all the fragments so that no problem is experienced in reconstructing the data stream.

Whichever type of fragmentation we use, one thing has to be made sure which is that later we should be able to form the original packets using the fragments. This insists on having some type of labeling for the fragments. 

Segmentation is another name for the fragmentation. A packet is injected in to the data link layer by the IP layer but it is not responsible for reliable transmission of the packets. Some maximum value on the size of the packets is imposed by each layer for their reasons. For a large packet that travels through the network for which the MTU is small, fragmentation is very much needed. 

When to re-estimate? What is a better way to estimate : Story points or Ideal Days?

When to Re-estimate?

Story points and ideal days are estimates of the size of a feature which helps you to know when to re-estimate. Re-estimate is done only when your opinion of the relative size of one or more stories has changed. One should not re-estimate just because progress is not coming as rapidly as expected.

Velocity should be allowed to take care of most estimation inaccuracies. Velocity is considered to be a great equalizer. The reason behind this is that the estimate for each feature is made relative to the estimates for other features, it does not matter if our estimates are correct, a little incorrect, or a lot incorrect. What matters is that they are consistent. As long as we are consistent with the estimates, measuring velocity over the first few iterations will allow us to have a reliable schedule.

At the end of an iteration, it is not recommended giving partial credit for partially finished user stories. The preference is for the team to count the entire estimate towards their velocity (if they completely finished and the feature has been accepted by the product owner) or for them to count nothing toward their story otherwise.

However, the team may choose to re-estimate partially complete user stories. Typically, this will mean estimating a user story representing the work that was completed during the iteration and one or more user stories that describe the remaining work. The sum of these estimates does not need to equal the initial estimate.

A team can choose to estimate either through story points or ideal days. Each has its advantages.


Benefits of Story Points
1. They help drive cross functional behavior.
2. The estimates derived by story points do not decay.
3. Story points are a pure measure of size.
4. Estimation through story points is faster.
5. Unlike ideal days, story points can be compared among team members. If one team member thinks that it will take him 4 ideal days, and another member thinks that it will take him 1 ideal day, both of them may be right yet there is no basis on which to argue and establish a single estimate.

Benefits of Ideal Days
1. They are more easily explained to those outside the team.
2. They are easier to get started with.

The advantages of story points are more compelling as compared to benefits of ideal days. one way is if a team is struggling with estimating the pure size, they can start off with estimating with ideal days and gradually switching to estimating by story points.

How does agile teams estimate the size of the project?

Agile teams separate estimates of size from estimates of duration. There are two measures of size:
1. Story points
2. Ideal time

Estimating Size with Story Points

- Story points are a relative measure of the size of a user story.
- A point value is assigned to each item when we estimate story points.
- Relative values are more important than raw values.
- A user story estimated as ten story points is twice as big, complex, or risky as a story estimated as five story points.
- A ten-point story is similarly half as big, complex or risky as a twenty-point story.
- The most important thing that matters are the relative values assigned to different stories.
- Velocity is a measure of a team's rate of progress per iteration.

- At the end of each iteration, a team can look at the stories they have completed and calculate their velocity by summing the story point estimates for each completed story.

- Story points are purely an estimate of the size of the work to be performed.
- The duration of a project is not estimated as much as it is derived by taking the total number of story points and dividing it by the velocity of the team.

There are two approaches to start with:
1. First Approach: Select a story that you think is one of the smallest story and say that story is estimated at one story point.
2. Second Approach: Select a story that seems somewhat medium and give it a number somewhere in the middle of the range you expect to use.

Estimating Size in Ideal Time

Ideal time and elapsed time are different. The reason for the difference, of course, is all the interruptions that may occur during any project.
- The amount of time a user story will take to develop can be more easily estimated in ideal days than in elapsed days.
- Estimating in elapsed days require us to consider all the interruptions that might occur while working on the story.
- If we instead estimate in ideal days, we consider only the amount of time the story will take.
- In this way, ideal days are an estimate of size, although less strictly so than story points.
- When estimating in ideal days, it is best to associate a single estimate with each user story.
- Rather than estimating that a user story will take 4 programmer days, 2 tester days, and 3 product owner days, it is better to sum those and say the story as a whole will take nine ideal days.

Does automation replace manual testing? What are the main benefits of test automation?

Test automation has proved to be quite useful in reducing the night mares of the testers regarding the testing of very complex, complicated and large software systems or applications. Almost all the manual testing processes that make use of the formalized testing processes have been automated. Although manual testing involves intense concentration and can root many of the defects and faults in the software systems and applications, it requires a hell lot of patience, efforts and time.

Can automation testing replace manual testing?

- In today’s fast paced software world, test automation has undoubtedly become one of the most strategic and critical necessity of the software development. 

- In the past years, the level of testing was considered to quite sufficient since the software systems and applications were not so dynamic.

But in today’s world we have explosive software systems and applications and we need to test them? Here the manual testing alone cannot suffice! 

- There are many classes of defects that cannot be traced without automated testing and there are several other types of errors and bugs that can be discovered using manual testing only. 

- So, we will say the automation testing cannot replace manual testing though it can be considered as a surplus to the manual testing. 

With rising demands for qualitative testing two things are possible:

(i) Either we increase the number of people involved in testing or

(ii) We increase the level of test automation.

- The rising demands for the rapidly developing web clients have made the need for test automation much critical. 

- The most unfortunate thing is that the testers are not full time to hone their software testing skills and the testers remain testers and do not become programmers.

- As a consequence of this, the simplicity of the software systems and application has been ruined and made far too complex and difficult to implement. 

- In order to get the most out of the test automation process, it should be implemented to the maximum extent it is possible. 

- If it is not used appropriately you can even face a failure in the long term development. 

To reap the full benefits of the test automation you need to keep the following things in mind:

1. Test automation is not a sideline rather it is a full time effort.
2. You should not confuse the test framework and test design as same entities.
3. The frame work that is to be used for the test automation should be application independent.
4. The frame work to be used must be maintainable and quite perpetual.
5. The test design as well as the strategy must be independent of the frame work.

Benefits of Test Automation

1. Test automation reduces the population of the staff required to carry out the testing.
2. Consumes less time.
3. Fewer efforts required.
4. Much preferable option when it comes to the size and complexity of today’s software systems and applications.
5. Testing is a repetitive process and this drudgery of the testers is taken by the test automation.
6. Test automation allows the machines to complete tedious task of repetitive testing while in the meantime the testers can take care of the other chores.
7. The testing costs are reduced.
8. Using test automation the load testing and stress testing can be performed very effectively.

What causes browser display differences?

Most of the time while browsing the same over many browsers you might have noticed considerable differences between the displays across the various browsers. These differences cause a lot of annoyance to the users.

There are various reasons why there occur differences across the different browsers. This article is focussed up on such browser display differences and errors as well as suggestions to avoid them.

ABOUT WEB BROWSER DISPLAY DIFFERENCES

- Earlier it was quite difficult and time consuming task to compare the web sites displays under many different browsers but nowadays several tools have been developed that have proven to be quite effective in testing the appearance of a web site on various browsers.

- These tools help in checking out the differences by taking the snap shots of the web site across the various browsers and then comparing them.

- You can even have the snap shots of your web page under different computers and screen resolutions.

- An HTML tool box is incorporated in these tools which tell whether the differences have occurred due to the incompatibility of the HTML code used in the web site or are they because of the browser incompatibility.

- The HTML tool box in some of the tools has also the capability for repairing off the code errors in just a few clicks.

Some of the most common factors that causes browser display differences are:
1. Browser bugs
2. Browser incompatibility
3. HTML errors
4. Different font sizes
5. Different computer types
6. Different screen sizes
7. Different versions of the browsers

RARE CASES
- In some very rare cases, the problem of differences might also occur due to certain features of a web site that have been exclusively designed for certain browsers and are not meant for others.

- Usually a web site is developed so that all of its features are accessible by all the web sites.

- For example, the web site for downloading Google chrome extensions and tools has been designed exclusively for the Google chrome browser.

- Though this web site can be viewed in any other browser but, one cannot download extensions through that browser.

STEPS FOR ELIMINATING DISPLAY DIFFERENCES ARE:

There are several steps that one can take for eliminating such differences:
1. Avoiding using cutting edge HTML as far as possible.
2. Set some goals for your web site.
3. Always check for the browsers incompatibilities.
4. Follow the trial and error debugging method.
5. Never forget to validate your web pages.

WHAT WEB BROWSERS ACTUALLY DO?

- They translate the web site code in to the formatted web pages.

- Every individual web browser has its own way of translating the web pages.

- This can be compared to the following example: you give a sentence written in German to a few people and ask them to translate it in to English. Checking the results, you will observe that all of them though have translated the sentence but their ways of translation are different i.e., the have used different words and grammar composition.

- Though the rules and standards for using HTML have been stated by the World Wide Web consortium, web site designers have their own way of implementing it.

- There is a fact that you should know which is that there is no such an effective browser that supports the hundred percent of the HTML, though there are certain browsers that come a little far away than their counterparts.

- If your browser does not supports a part of the code, it is sure to affect the display of your web site.

- This problem is further exaggerated by the HTML extensions that are specific to certain browsers.

- Such problems have forced the designers to put a label on their web site stating on which browser their web site can be viewed.

Automated Estimation Techniques and Tools - Functions and types of tools

Automated estimation techniques and tools allows the planner to estimate the cost and effort and to perform what-if analysis for important project variables such as delivery date or staffing. If applying different estimation tools on the same project data, variation in estimated results are encountered. Sometimes, the predicted values are different from the actual values. The output of estimation tools should be used as one data point from which estimates are derived.

The six functions performed by the automated estimation tools are:

- Sizing of project deliverable.
- Selecting project activities.
- Predicting staffing levels.
- Predicting software effort.
- Predicting software cost.
- Predicting software schedules.

These automated tools require an estimate of project size for example LOC and FP. They require qualitative project characteristics such as complexity, reliability, or business criticality. They also require description of the development staff and/or development environment.

- Tools like BYL (Before You Leap) and WICOMO (Wang Institute Cost Model) require the user to provide lines of code estimates and these estimates are categorized by programming language and type. These tools produces estimated elapsed project duration (in months), effort in staff-months, average staffing per month, average productivity in LOC/pm, and cost per month.
- SLIM is an automated costing system based on the Rayleigh-Putnam Model.
- ESTIMACS uses function point estimation method. It helps the planner to estimate system development effort, cost and staff, the risk and the hardware configuration.
- SPQR/20 developed by Software Productivity Research Inc. It has the user complete a simple set of multiple choice questions.

Project Estimation - Decomposition techniques - Estimating the software size

In the estimation of software cost and effort, many variables that include human, technical, environmental, political can affect final cost and effort applied to software. It is a complex process. Decomposing the problem and re-characterization it into a set of smaller problems is an approach for software project estimation.

Decomposition approach has two point of views :
- problem decomposition
- process decomposition

Before estimating, estimating the size of the software is very important. The size of the software to be built can be estimated using lines of code which is a direct measure or through function point which is an indirect measure. Estimating software size is a major challenge. Size is the quantifiable outcome of software project.

Approaches to sizing problems are:
- Fuzzy logic sizing: Identify the application, its magnitude and refining the magnitude within original range.
- Function point sizing: Estimates of information domain characteristics are developed.
- Standard component sizing: The number of occurrences of each standard component
is estimated and project data is used to calculate the delivered size per standard component.
- Change sizing: Suppose an existing software is modified in some way. In this approach, the number and type of modifications are estimated.

These approaches were suggested by Putnam and Myers.

How are strings and arrays defined in C?

A string can be defined as a group of characters, usually letters of the alphabet. When C is either to compare a string with another string, output it, copy it to another string, or whatever, the functions are intended to do what they are called to do until a null, which is a zero, is detected. Such strings are often called an ASCII-Z string. C treats a string as an array termination with a NULL character. C does not have a separate data type for strings and so strings exist as the arrays of characters. An extra byte must be left to store the NULL “\0”. Strings are declared as the arrays of characters. For example:

char name[25];

Strings can be fully or partially initialized depending on the requirements of the user. For example:
char fill[10] = { ‘a’, ‘ ‘, ‘r’,’o’,’p’,’l’,’a’,’n’,’e’,’\0’ };

There exist certain predefined functions for modifying strings. The library cstring.h houses all these functions. Strcpy() is used to copy one string into another string. Strlen() is used to determine the length of the string. Strcmp() is function for comparing two strings i.e., which one is bigger in terms of length. Strcat() is used to concatenate two strings. The second string is appended to the end of the first string. Strrev() is used to reverse a string alphabetically.

An array is a C derived data type and can be defined as a collection of variables of the same data type that are referenced by a common name. All arrays consist of contiguous memory locations where the lowest address corresponds to the first element and highest address corresponds to the last element. Arrays are useful when quite many elements of the same data type are needed to be stored and processed. The numbers in [ ] are called indices or subscripts. A string itself is an array of characters. Arrays are of two types namely one- dimensional arrays and multi dimensional arrays. Multi dimensional array comprises of elements which themselves are arrays. The general form of an array declaration is as follows:

Type array-name [size];

Here type states the data type of the array elements. The array name declares the name of the array, and finally the size defines how many elements will be there in the array. The data type of the array is called the base type.

A multidimensional array consists of M*N elements where M is the number of rows and N is the number of columns. It can be declared as follows:

Type array-name [rows][columns];

Where single dimensional arras can be read using a single loop, it takes nested loops to read and access the elements of a multi dimensional array. One loop is used to process the rows and the other one is used to process the columns. The arrays can be initialized during the run time as follows:

Type array-name [size 1]……….[size N]= {value list};

The value list consists of the array elements. C allows you to skip the size of arrays in an initialization statement. These types of arrays are called unsized arrays. For example:
Int abc[ ] = {1,2,3,5,7};

The best way to assign values to an array is using a "for" or "while" loop because it’s not affordable to write a separate initialization for every element. Arrays can be passed s parameters to the functions to maintain a structured design. Always keep in mind that in C subscripts start from 0. A string from an array of strings can be accessed by using pointers. But keep in mind that pointers hold only address of the strings. From there it is able to obtain the whole chunk of the contiguous memory.

What are different web engineering project metrics?

The objective of a good web application is that it delivers a combination of good content and appropriate functionality for the end user. Web engineering project metrics are defined that assess its internal productivity and quality are:

- Number of static web pages measure provides an indication of the overall size of the application and the effort required to develop it. This measure has less complexity and requires less effort to get construct.
- Number of dynamic web pages measure high complexity and more effort to get construct. It provides an indication of the overall size of the application and effort required to develop it.
- Number of internal page links measure gives an indication of degree of architectural coupling within the web application. Effort on navigation and construction increases as the number of page links increase.
- As Number of persistent data objects increases, the complexity and effort to implement it also grows.
- As Number of external systems interfaced increases, the complexity of the system and effort required for the development also increases.
- Number of static content objects includes static text, graphics, video, animation and audio within the application. Multiple content objects appear on single web page.
- Number of dynamic content objects includes objects based on end user action and includes text, graphic, video, animation and audio within the application. Multiple content objects appear on single web page.
- As the Number of executable functions increases, the modeling and construction effort also increases. A metric can be defined reflecting the degree of end user customization required for web application. An executable function provides a computational service to end user.

Web application metrics can be computed and correlated with measures like effort, errors and defects uncovered, models or documentation pages produced.

Software Development Metrics : Product and Productivity Metrics

Metrics are needed to understand the level of process performance, project performance and product performance. They are needed to set goals and measure the trend and rate of improvement. Criteria for effective metrics are:
- Simple.
- Keep them to a minimum.
- Base them on business objectives and the business process - avoid those that cause dysfunctional behavior.
- Keep them practical.

Product Metrics

One accepted method of estimating the size of the product is using the metric KDSI (Kilo or Thousand Delivered Source Instruction) or Kilo Lines of Code (KLOC) - how many thousands of lines of code are required for the project excluding the comments. Based on KDSI, a project can be categorized as small, intermediate, medium, large or very large.
- Small <= 2 KDSI
- Intermediate >2 and <=8 KDSI
- Medium >8 and <=32 KDSI
- Large >32 and <=128 KDSI
- Very large >128 KDSI

Productivity Metrics

Another metric that can be used for measuring the productivity of the programmer is counting the number of lines that can be written by a programmer in one hour i.e. the Delivered Source Instructions (DSI) per hour.
Time required for execution of a project(in hours) = Total KDSI of the project/average KDSI per hour.