What are the differences between inter-network routing and intra-network routing?

- The individual networks when combined together form the inter-network. 

- Intermediate inter networking devices are used for making connections between them. 

- All these networking elements combine to work as single large unit. 

- The creation of the internetworking has been made possible because of the packet switching technology. 

- The router is the most common and important device used for performing inter-network routing and intranetwork routing.

- Routing across various networks in the inter network is termed as internetwork routing and routing within the same network is termed intranetwork routing. 

In this article we discuss about the differences between internetwork routing and intranetwork routing. 

- Just like inter-network, intranetwork also uses IP (internet protocol) technology for computing services and sharing information. 

- But what makes it different from internetworking is that it is limited to some organization whereas internetwork extends beyond all i.e., it is not limited.

- Or we can put it in other words: Internetwork is spread across organizations and Intranetwork lies within an organization. 

- In some cases, the term intranetwork might mean only the internal website of the organization, but in other cases it might be a larger part of the IT infrastructure of the organization. 

- Sometimes, it may span over a number of LANs (local area networks). 

- The intranetwork is driven by the goal of minimizing the time, effort and cost of the individual’s desktop in order to make it more competitive, cost efficient, timely as well as productive.

- An intranetwork is capable of hosting multiple websites that are private to organizations and may even constitute an important part of the collaboration and communication between the members of the organization. 

- Intranetwork also makes use of various well known protocols such as the FTP, SMTP and HTTP. 

- The intranets are often incorporated with the technologies for lending a modern interface to the systems that host the corporate data. 

- These systems are known as the legacy systems. 

- We can see intranetwork to be a private analog of the internetwork. 

- It means the internetwork has been simply extended to an organization for its private use. 

- Extranetworks are a modified version of the intranetworks.

- Here, the website might be accessed by the non-members i.e., the suppliers, customers or some other approved third parties and so on. 

- Intranetworks are well equipped with a special protocol called the AAA protocol. 

- The 3 As stand for authentication, authorization and accounting. 

- There are a number of organizations who are concerned about the security of their intranetworks. 

- They have deployed a firewall and a network gateway for controlling the access to their services. 

- The intermediate systems when connect together form the internetwork whereas they may bound together a part of the internetwork which might be an intranetwork. 

- The intranetwork routing involves routing between two routers which lie in the same network whereas in internetwork routing, routing is done between routers which reside across different networks. 

- Intranetwork routing is quite easy when compared to the internetwork routing. 

- Protocols used in both the types of routing are different.

- Interior gateway protocol is responsible for routing in the intranetworks whereas the exterior gateway protocol takes the responsibility of routing across the internetwork. 

- Most common example of interior gateway protocol is the OSPF or the open shortest path first protocol. 

- And most common example of exterior gateway protocol is the border gateway protocol or BGP. 

- Also, the routing graphs for both the types are different. 

- In the intranetwork’s graph, all the routers are simply linked to one another in the same network. 

- There is less mess.

- On the other hand, the inter network’s graph is quite tedious. 

- This is so because routers of different networks have to be inter-linked with one another. 

Explain multicast routing?

- Multicast routing is also known as the IP multicast. 

- For sending the IP (internet protocol) data-grams to a group of receivers who are interested in receiving the data-grams, multicast routing is used.

- The data-grams are sent to all the receivers in just one transmission. 

- Multicast routing has got a special use in the applications that require media streaming on private networks as well as internet. 

- Multicast routing is IP specific version. 

- A more general version is the multicast networking.

- Here, the multicast address blocks are especially reserved in IPv6 and IPv4. 

- Broadcast addressing has been replaced by multicast addressing in IPv6. 

- Broadcast addressing was used in IPv4. 

- RFC 1112 describes the multicast routing and in 1986 it was standardized. 

This technique is used for the following types of real – time communication over the IP infrastructure of the network:

Ø  Many – to – many

Ø  One – to – many

- It scales up to receiving population that is large enough and it does not require either knowledge regarding the receivers and the identity of the receivers. 

- Network infrastructure is used efficiently by the multicast efficiently and requires source sending packet to a large number of receivers only once. 

- The responsibility of the replication of the packet is of the nodes which are nothing but the routers and the network switches.

- The packet has to be replicated till it reaches the multiple receivers. 

- Also, it is important that the message is sent only once over the link.   

- UDP or the user data gram protocol is the mostly used protocol of low level. 

- Even though if this protocol does not guarantees reliability i.e., the packets might get delivered or get lost. 

- There are other multicast protocols available that are reliable such as the PGM or the pragmatic general multicast. 

It has been developed for adding the following two things a top the IP multicast:

Ø  Retransmission and

Ø  Loss detection

The following 3 things are key elements of an IP multicast:

1. Receiver driven tree creation
2. Multicast distribution tree
3. IP multicast group address

- The receivers and the sources use the last for sending as well as receiving the multicast messages. 

- The group address serves as the destination address of the data packets for the sources whereas it is used for informing the network whether or not the receivers want those packets.

- Receivers need a protocol for joining a group. 

- One most commonly used protocol for this purpose is the IGMP i.e., the internet group management protocol. 

- The multicast distribution trees are set up using this protocol. 

- Once a group has been joined by the receiver, the PIM (protocol independent multicast) protocol is used for constructing a multicast distribution tree for this group. 

- The multicast distribution trees set up with the help of this protocol are used for sending the multicast packets to the members of the multicast group. 

PIM can be implemented in any of the following variations:

1. SM or sparse mode
2. DM or dense mode
3. SSM or source specified mode
4. SDM or sparse – dense mode or bidirectional mode (bidir)

- Since 2006, the sparse mode is the most commonly used mode. 

- The last two variations are more scalable and simpler variations of PIM and are also popular. 

- An active source is not required for carrying out an IP multicast operation and knowing about the group’s receivers. 

- The receiver drives the construction of the IP multicast tree. 

- The network nodes which lie closer to receiver are responsible for initiating this construction.

- This multicast then scales to a receiver population that is large enough. 

- It is important for a multicast router to know which all multicast trees can be reached in the network. 

- Rather, it only requires knowledge of its downstream receivers. 

- This is how the multicast – addressed services can be scaled up. 

Infrastructure: Need to do a frequent clean up of old builds from servers ..

This is a constant problems that organizations that have large products face. If your product has a size of around 500 MB or more, and you are in the development face, the chances are quite high that you will be generating a build every day. The build contains new fixes and code changes, so getting a new build every day ensures that there is a quick turnaround in terms of defects closure as well as ensuring that new features done by the developers get to the hands of testers almost as soon as the features are done.
However, there is an infrastructural issue involved with getting so many builds. I am talking of the cases where the typical release cycle of such a product is more than a few months. During this period, the team will generate a number of such builds that need to be hosted on servers so that they are accessible to the team members (and they needed to be transferred to additional servers if the team has members located in different geographical locations, or if there are vendors located in a different location and the vendors can only be given access to a different server outside of the main server that is accessible only to employees). Now, there can be additional builds that are required (for example, you may have the same application that has a different structure for the DVD release vs. the release on the company online store, and if there is distribution to vendors, there might be a different version). In some cases, the different language versions of the product might need to be different applications (builds) which also increases the size considerations.
Now, all these place a lot of constraints on infrastructure. Central servers are typically set up in a RAID kind of configuration which means that space needed is actually much more. Server capacity in terms of hard disk is cheap, but you can be pretty sure that at some point, unless you do some optimization, the additional hard disk capacity required on a regular basis can start becoming costly, not only from the perspective of equipment, but also from the perspective of the staff needed for maintaining this capacity, as well as making it more difficult to find what you want. It always makes sense to do some kind of optimization of the storage needs of the product in terms of builds, since if a build is not being used, the need of storing the build is unnecessary.
A initial thought might show that only recent builds need to be stored, but that is an over simplification. There might be defects that were filed some time back, and for the purpose of evaluating these defects, the builds on which these defects were found need to be accessible. Further, during the process of coding, there could be errors inserted into the code, but not detected for some time (this could be weeks or even months). Even though the code could be checked by doing a differential in the source code repository, it may be necessary to test the performance in the build in which the code change was first detected to see what the code change caused. There could be numerous such reasons as to why a specific build is needed at some point in the future, and hence, there needs to be a process defined that will let the team control which builds need to be deleted from the server, thus leading to an optimization of the server space. Here are some points that could help in this:
- If there are builds from the earlier cycle, then it is probable that those build are not necessary. It might just be enough to retain build that were of significant interest in terms of milestones.
- If a build had a problem in terms of the build either not launching or being rejected for the purpose of testing, those builds need not be retained and can be deleted
- When builds are older than a few months, the team can decide on a policy to check whether such builds can be deleted or not, and so on.

Working with vendors: Telling them the points of focus for the particular version ..

In some of the previous posts, I have been talking about the issues and processes involved in ensuring that the interaction with the vendors (especially when they are involved in testing) is fine. In the last post (Working with vendors to ensure that tools are synchronized), I talked about how the team should be spending time on defining a process for transferring knowledge about the tools used by the team during testing. Now, this is easy for tools that are in generic usage, such as tools for Defect Management, Source Safe, or for capturing the details of Test Plans and Test cases. However, this is more complicated when the tools are specialized such as Fiddler, and other such tools that take time for vendors to learn more.
In this line of thought, there are several other processes that the team needs to transfer to the vendor team and do this in a systematic way to increase the level of efficiency. Some of the processes that the team might need to convey to the vendor team are:
- Certain specific processes such as the dealing with defects that have existed for some time. Consider the case of a defect that has been present in the product for more than one version, and the team has decided that they do not want to make the fix. Similarly, there may be cases where there is a difference of opinion with respect to the functionality, but anybody who needs to do this testing will be able to log a defect. In such cases, the team members know about these defects and do not try to file them, but somebody who is new to that area such as a vendor team member will not know, and will file defects in such areas. It is for the product team to ensure that they have transferred instructions regarding how to handle these defects to the vendor. If this does not happen, there will be wastage of time when the vendors actually do these testing. I saw such a case whereby there were some new members to the vendor team and there was a delay in passing on such information, and suddenly there was a buzz in the team about the vendor finding a number of defects that the team members had not found. There was some pressure on the testing team, but then it was found that most of these defects were of the types that the team already knew about, and there was a sigh of relief in the testing team (they would have come under a lot of pressure if the vendors found a number of defects that the core testing team was not able to find).
- Similarly, there are certain points of focus for every release. Or it could be the case where this is a patch or dot release that is focusing on a certain area, and it is incumbent on the product team to pass on the application focus onto the vendor team. This is needed to ensure that the testing done by the vendor team focuses on the relevant area instead of spending time on other areas which are not relevant. The team needs to decide on the best way to do this, one way to do this is to take the application where test plans and test cases are captured and create a plan that shows the vendor the focus areas where testing needs to be done. However, this pre-supposes that the test cases are written in a way that a subset can be used by the vendors and would make sense.

Working with vendors: Ensuring that tools are synchronized ..

This is part of a series of discussions on how to work with people outside the software development core team, which in most cases are typically vendors. You would be working with vendors for a variety of reasons:
- Part of the testing needed is done by the vendors
- There is a sudden work to be done besides the core work, and the additional work testing is needed to be done by vendors
- The product is being localized into many languages and the testing in various languages is being done by vendors
- Multiple other reasons such as these, all of which raise the need for vendors to take part for testing.

Now, when you have vendors working with the core team for testing purposes, you will be lucky if there is a continuity in terms of the personnel from the vendor side over the years. Our experience has been that unless we are able to provide business to the vendors the year round, people on the vendor side move onto different projects and would not be so easily available the next time when there is a need for the vendor. In addition, there are times when there is a sudden need for testing, and at that time, testers from the vendor side who have experience in the product would not be available.
In previous posts (Process setting, Kickoff and knowledge transfer), I have already been talking about some processes involved in working with vendors who assist in testing, and how to ensure that getting them trained is done as easily as possible. However, there is another area where there is a need for ensuring that knowledge transition happens efficiently, and that is in the area of tools that are used for the process of preparing the data as well as doing the testing.
Applications such as Defect Management systems and source repository systems are easy for vendors to understand, given that even if the vendors have been using a different tool for these functions, the basic concept of using these tools does not change too much, and hence it should be fairly easy for them to pick up a new tool.
However, it gets problematic when the team is using specialized tools, and there is a high chance that the personnel from the vendor site would not have the experience in using such tools. We had this in a previous project, where we were using specific tools such as 'Fiddler' for testing out the flow between the desktop application and an online application. When we spoke to the vendor team around the start of the project, they had no experience in a similar tool, and yet it was necessary for them to do the testing (we could not do the testing of this tool in all the areas where it was the vendor responsibility, and hence it was important for the vendor to learn this tool). So, finally we had to run a project whereby we did a few rounds of web conferencing with the vendor and explained how to use this and other such tools. However, it would have been more efficient to have already prepared such a document for the various tools that the teams use, along with something like a self-learning document.

Read more about working with vendors in the next post (Processes when dealing with vendors)

Infrastructure: Testing, VPN and network issues relating to external teams

When dealing with testing or development by external teams, there are a lot of infrastructural issues to deal with, and in a number of cases, teams have not prepared some kind of process documentation to take care of such needs and processes. Some of the external teams that can be involved in the process of development or testing for a software application include the following:
- External teams that are working as an extension of the testing team. This is getting more and more common, whereby the testing team can be expanded as necessary by adding vendors to the testing resources. However, when the these external vendors need to start their work, they need access to the testing infrastructure such as test cases repository and the defect management software.
- External teams working on the localization (conversion of the software into different languages). Such teams typically work on both development and testing of the application in different languages and need access to the source repository, as well as the testing infrastructure (test plan and case repository, defect management software, and so on).
- Teams working on the documentation of the product typically need access to the defect management software, since there can be several issues that need to be documented which are typically present in the defect management software, and the documentation team would be provided access to the defect management software.

For these 3 teams and others working in a similar area, if they are located outside the organization, then there may be a necessity for them to be provide the required VPN access to get access to all these tools. In modern secure organizations, such access policies would go through an approval process, and to ensure that such a process is accelerated, it makes sense to prep the approving authorities about these requests for approval.

- External testers / pre-release testers. Such pre-release testers typically do not need any access to source code repository or the testing infrastructure. However, these testers do need a platform where the defects they have logged get into the defect management software in an easy and transparent way (and where the testers are not expected to do any additional work - in some cases, it is as simple as providing them a web page where they can enter the defects that they have found, and some additional parameters that testers  are expected to enter but pre-release testers are not expected to enter are entered by default).

For all these teams, there may be other access issues that teams may not have thought about. Typically when a team has any kind of feature that provides access to an online feature, such features are available in staged servers that need some kind of setting or special access. For ensuring that all the teams listed above and similar teams do not get stuck, it is required to plan for such an access. We had a problem in the past whereby an important online feature was rolled out to the press reviewing team, but there was a big screw up relating to the access for these features, and the team was not able to provide access for around 3 days, in which time, some of the press withdrew - a big disaster. So, a great team has plans for all these before they look to execute such features.

What are Software Process Improvement resources?

A supportive and effective infrastructure is required for facilitating the coordination of various activities that place during the course of the whole program. In addition to these qualities the infrastructure should be quite flexible so as to be able to support the changing demands of the software process improvement with time. 

Resources for this program include:

1. Infrastructure and building support
2. Sponsorship
3. Commitment
4. Baseline activities
5. Technologies
6. Coordinate training resources
7. Planning expertise
8. Baseline action plan and so on.

- When this program is initiated, a primitive infrastructure is put in to place for the management of the activities that would be carried out by the organization under SPI. 

- The resources mentioned above are also the initial accomplishments that tell how well the infrastructure has been performing. 

- It is the purpose of the infrastructure to establish a link between the program’s vision and mission, to monitor it and guide it and obtaining resources and allocating them.

- Once the SPI program, a number of improvement activities will be taking place across the different units of the organization. 

- These improvement activities cannot be performed serially rather they take place in parallel. 

- The configuration management, project planning, requirements management and reviews etc. are addressed by the TWGs (technical working groups). 

- But all these activities are tracked by the infrastructure.

- Support for the following issues must be provided by the infrastructure:

1. For a technology that is to be introduced.
2. Providing sponsorship
3. Assessment of the organization impact

- As the program progresses, the functions to be performed by the infrastructure increase. 

- There are 3 major components of the SPI program:

1. SEPG or software engineering process group
2. MSG or management steering group
3. TWG or technical work group

- It is third component from which most of the resources are obtained including:

1. Human resources
2. Finance
3. Manufacturing
4. Development

- However, the most important is the first one and is often called the process group. 

- It provides sustaining support for the SPI and reinforcing the sponsorship. 

- The second component i.e., the MSG charters the SEPG.

- This is actually a contract between the SEPG and the management of the organization. 

- Its purpose is to outline the roles and the responsibilities and not to forget the authority of the SEPG. 

- The third component is also known as the process improvement team or process action team. 

- Different work groups created focus on different issues of the SPI program. 

- A software engineering domain is addressed by the technical work group. 

- It is not necessary for the TWGs to address the technical domains; they can address issues such as software standardization, purchasing, travel reimbursement and so on. 

- The team usually consists of the people who have both knowledge and experiencing regarding the area under improvement. 

- The life of TWGs is however finite and is defined in the charter. 

- Once they complete their duties, they return back to their normal work. 

- In the early stages of SPI program, the TWGs might tend to underestimate the time that would be required for the completion of the objectives assigned to them. 

- So the TWGs have to request to the MSG for allotting them more time. 

- Another important component could be the SPIAC or software process improvement advisory committee. 

- This is created in organizations where there are multiple functioning SEPGs. 

Explain Quick Test Professional (QTP) Testing process?

The quick test professional is a software package that facilitates both the test automation as well as the software testing. To be an expert in quick test professional it is important that you understand both the test automation and software testing using the quick test professional. 

When the software testing process is carried out using the quick test professional it is referred to as the quick test professional test process. By now you must have got it that the emphasis of this article is on the same testing process. 

To say the quick test professional testing process constitutes of the following steps as mentioned below:

1. Configuring of the record and run settings
2. Creating an object repository (this step is optional is many cases)
3. Creating the basic automation scripts
4. Editing or enhancing the script
5. Executing the script
6. Debugging the script
7. Analyzing the results
8. Summarizing the results (this includes tracking the discovered defects and generating the report)

Major stages of the QTP testing process

1. Analyzation of the application

- This is the first test and is aimed at finding your testing needs. 

- This phase involves the type determination of the development environment of your application i.e., whether it is a web application or a windows application. 

- In either of the cases, you will need to load your quick test professional software with appropriate add ins. 

- There are available separated add – ins for both the web type and windows type applications. 

- These add – ins are required since they only give the power to quick test professional to identify as well work with the objects present in the application. - Next thing to determine are the business processes and functionality required. 

- For determining these two things you need to think about what your customer will do with the application. 

- The required business processes are then divided in to smaller groups or units and the actions based on these units are created. 

- This is done so because with smaller modular actions it becomes easy to read, follow and maintain the tests in the long term.

2. Preparation of the testing infrastructure: 

- Based on the needs that you determined in the first phase, the resources required are determined in this second phase. 

- The resources are either obtained or created as required. 

- The resources may include the following:

      a)   Object repositories along with the test objects.

      b)   Function libraries along with the functions that add to functionality of the quick test professional and so on.

- Also in this phase the settings of the quick test professional are configured as per the tasks need to be performed.

3. Building of the tests and addition of the steps to them: 

- By now the testing infrastructure is complete and now you can start developing your tests. 

- Any number of empty tests can be created and actions can be added to them so as to form the testing skeletons. 

- Relevant actions can be associated with the corresponding object repositories.

- Relevant tests can be associated with the function libraries. 

- Steps can be inserted with the help of key words and test preferences are also considered.

4. Enhancement of the test: 

- This phase includes insertion of the checkpoints so that you can easily search for a specific value of object, page or text etc and know whether or not your application is functioning properly.

5. Debugging, execution and analyzation of the test: 

- This phase ensures that the application is working without encountering any interruption. 

- Only if a test is running properly, it can correctly check the behavior of the application.

6. Reporting of the defects: 

- The defects discovered can be reported to the quality center if you have it installed on your machine. 

Architectural Design - Refining the Architecture into Components and Describing Instantiations of the System

Refining the Architecture into Components

As the software architecture is refined into components, structure of the system begins to emerge. Components of the software architecture are derived from three sources:
- the application domain
- the infrastructure domain
- the interface domain
Because analysis modeling does not address infrastructure, one should allocate sufficient design time to consider it carefully.
In order to find the components that are most suitable for refining the software architecture, you need to start by using the classes which were described in the analysis model. The analysis classes in turn are representations of business entities that architecture is trying to describe. You could also base these components on an infrastructure model rather than the business model. If you went purely by the business model, you would not be able to depict many of those infrastructure components such as database components, components used for communication etc.
Whatever interfaces are described in the architecture context diagram imply one or more specialized components that process the data that flow across the interface.

Describing Instantiations of the System

The context of the system has been represented, the archetypes indicating important abstractions are defined, the overall structure of system apparent and major software components are identified, however further refinement is necessary which is accomplished by developing an actual instantiation of architecture. The architecture is applied to a specific problem with the intent of demonstrating that the structure and components are appropriate.

What are different steps while conducting component level designing?

The following steps represent a typical task set for component level design, when it is applied for an object oriented system. If you are working in a non object oriented environment, the first three steps focus on the refinement of data objects and processing functions identified as part of analysis model.

STEP 1: Identify all design classes that correspond to the problem domain.
STEP 2: Identify all design classes that correspond to the infrastructure domain.
STEP 3: Elaborate all design classes that are not acquired as reusable components.
In addition to all interfaces, attributes, operations, design heuristics i.e cohesion and coupling should be considered during elaboration.
- Specify message details when classes or components collaborate.
Structure of messages that are passed between objects within a system are shown as component level design proceeds.
- Identify appropriate interfaces for each component.
Interface is an abstract class that provides a controlled connection between design classes. So interfaces should be identified appropriately.
- Elaborate attributes and define data types and data structures required to implement them.
The programming language that is to be used in the project typically is a factor in the definition of the data structure and types used to describe attributes. When the component level design process is started, the name of attributes is used; as the design proceeds the UML attribute format is increasingly used.
- Describe processing flow within each operation in detail.
There are two ways to do this; through a UML activity diagram or a programming language based pseudocode. The elaboration of each software component is by doing a number of iterations and in each iteration a step-wise refinement concept is used.
STEP 4: Describe persistent data sources and identify the classes required to manage them.
As the design elaboration proceeds, an additional data should be provided about the structure and organization of these data sources which are initially specified as part of architectural design.
STEP 5: Develop and elaborate behavioral representations for a class or component.
In order to depict the externally observable behavior of the system as well as that of individual analysis classes, UML state diagrams are used. As a part of component level design, modeling the behavior of a design class may be sometimes required. The instantiation of a design class a s program executes is also known as the dynamic behavior of the object. This behavior is impacted by the current state of object as well as external events.
STEP 6: Elaborate deployment diagrams to provide additional implementation detail.
When component level design is being done, in order to make deployment diagrams simple to read and comprehend, the location of components(individual components) are generally not depicted.
STEP 7: Factor every component level design representation and always consider alternatives.
The first component level model that is created will not be consistent, complete and accurate as compared to the nth iteration that is applied to the model. It is necessary to re-factor as design work is conducted.

Analysis for Web Applications - The Functional Model and The Configuration Model

The functional model describes two elements of web application :
- User Observable Functions: Delivered by web application to end users. It encompasses any processing functions that are initiated directly by the user. These functions may be implemented using operations within analysis classes but from the point of view of an end-user, the function is the visible outcome.
- Class Operations: Implement behaviors associated with the class. These operations manipulate class attributes and are involved as classes collaborate with one another to accomplish some required behavior.
The UML activity diagram can be used to represent processing details.

The Configuration Model describes the environment that the web application will require on both the server and client side of the system. Although it is very important to consider all configurations that are likely to be used, a web application must be engineered to serve its end-users. Web application resides on a server that provides access via Internet, Intranet or an Extra-net. Server hardware and operating system must be specified. Also, interoperability considerations on the server side should be considered.

Client side software provides an infrastructure that enables access to web application from user's location. Web application content and functionality is delivered by browser software. Each browser has its own peculiarities.