What are Rational Unified Process building blocks?

Whenever we talk about iterative software development process frame works, the first name that comes to our minds is of the rational unified process. It is not just a single hard coded prescriptive process rather it is quite an adaptable and flexible process frame work. 

This frame work comes with several facilities, the best one being that your organization can tailor it according to their needs. 

What is Rational Unified Process?

- Unified process when specifically implemented is called as the rational unified process. 

- Rational unified process is counted among the best products of IBM and the credit for its development goes to the rational software division.

- The RUP comes with a hyper linked base consisting of the descriptions of several types of activities and a few sample artifacts. 

- A part of the IBM’s rational method composer (RMC) is occupied by the rational unified process.

- It allows the users to customize the process as per their needs. 

What are building blocks of Rational Unified Process?

In this article we are to talk about the building blocks of the rational unified process.

- These basic best practices of the rational unified process were developed as a result of the combination of the experience of many companies. 

- The building blocks are:

1. Iterative development with risk as its primary iteration driver.
2. Management of the requirements.
3. Employment of an architecture based up on components.
4. Visual modeling of the software.
5. Continuous verification of the quality.
6. Controlling the changes

- These best practices are used in the following two ways:

1. For driving the development process of the rational’s products.
2. To be used by the rational’s field teams so as to assist the customers in improving the predictability as well as the quality of the software development efforts.

- The task involves the assembling of the explicit process framework for the field of modern software engineering. 

- The delivery mechanism developed by the objector was based up on the HTML and employed in accomplishing this task.

- This task resulted in the creation of the rational unified process. 

- A set of content elements or the building blocks form the foundation for the rational unified process and give a description of the product that is to be produced and the required necessary skills. 

- They also give a detailed step by step explanation for achieving the specific development goals. 

Now we shall list all the building blocks of the rational unified process and discuss them in detail:

1. Roles: This building block can be defined as set consisting of related skills, responsibilities as well as competencies.
2. Work products: This building block gives the representation of thing that would result when a task would be completed inclusive of all the models and documentation produced during the course of the completion of that task.
3. Tasks: This building block gives a description of the units of works that are assigned to an element from the role which will produce a result that would be meaningful.

There are 9 disciplines in to which the tasks are categorized within each iteration. There are 6 engineering disciplines and 3 supporting disciplines which together make up total 9 disciplines. The 6 engineering disciplines are:

1. Business modeling
2. Requirements
3. Analysis and design
4. Implementation
5. Test and
6. Deployment

The following are the three supporting disciplines:

1. Configuration and change management
2. Environment and
3. Project management

The organization and the management of the above mentioned building blocks need to be solid and flexible in order to make the rational unified process a success which otherwise cannot be achieved. 

List out the advantages and limitations of Silk Test?

Silk test over the years has always been successful in delivering the test automation and that too in an agile development. 

It is considered by most of us that the quality management is just a discrete discipline when it comes to the agile projects, which is wrong. The fact is that the quality management forms an integral part of the code production process in agile projects. 

The rate of flexibility and change associated with the development of agile projects is increasing day by day and thus it is required that the testing should be made automated as and when and as much as possible. 

The traditional tools for test automation and management have very less capability for accommodating the required changes that are made to skills, processes, responsibility, and attitude and so on. 

Therefore, the whole software world is now shifting to the agile management practices. 

- Agile development goals at delivering the code at the end of the sprints which is ready for the production process. 

- There is no other go for the agile development projects except to undergo a rigorous testing routine in each and every sprint and to automate the testing. 

- If it is not done, the agile projects are sure to fall short of quality. 

- With every iteration a customer value is delivered by the agile project. 

- More testing is permitted in test automation process. 

- This also aids in cutting down the costs of the software since the time lag between the introduction and identification of the defect is slashed. 

- There is a need to regularly check about the changes which lead to development of frequent builds involving the test automation runs. 

- The earlier the test automation runs are run the sooner the defects are identified. 

- Another advantage of silk test is that it supports continuous test automation. 

- Test automation results are what is demanded by the agile teams and that too on a per build basis. 

- Silk test makes sure about this and delivers the UI automation at the fastest play back speed possible. 

- The play back speed offered by the silk test is the fastest that is available in the current market. 

- This in turn has another advantage which is that it reduces the duration of testing which helps in submitting timely test results as required by the agile teams. 

- The saved time thus can be utilized for further testing activities. 

- Agile teams exhibit a strong and flexible collaboration among the testers and developers and thus the test-ability of the applications can be further improved up on. 

- Here, we should not miss out mentioning that the tool which provides the strongest support for custom UI properties in the industry is none other than the silk test automation tool. 

- Stable and reliable identifiers are required for the UI controls and this is also catered by the silk test automation tool. 

- Silk test is quite different from the other tools in the sense that it does not rely on a small subset of properties for identifying the objects. 

- Silk test provides very detailed test results thus minimizing the efforts that you will have to spend on the analyzation of the test failures. 

- The test failures related to the issues of test script synchronization are minimized by the reliable test execution of the silk test.

Limitations of SilkTest

1. Recognition of some objects in some page is not possible due to some technical reasons.
2. Some window frames may not be recognized.
3. Frequent change in tag value is observed.
4. Difficulty in activating some window is experienced.
5. In some of the web applications and web pages the links are taken as simple text. 

Explain data parameterization in WinRunner?

Whenever you subject your software system or application to testing, it is obvious for you to think of checking how your software system or application performs with some other multiple sets of data. 

For this what do you do? 

You create some data driven tests with some loops that runs a certain number of times or we can say which runs for how many different sets of data you want the application to be tested with. Each time the iteration of loop takes place, it leads to the testing of the software system or application with a different set of data.

But the winrunner will not simply execute such loops! 

- To make the winrunner use that data for driving the tests it is necessary that you link the data with the particular test script which you want it to drive. 

- This process of linking the data with the test script that it’s going to drive is called parameterizing of the tests.

- The data sets are recorded in the form of a data table. 

- The process of parameterizing the tests can be either carried out manually or you can take the aid of the data driver wizard. 

- The data driver wizard will not only help you in parameterization of your tests but will also help you in storing the data in the data table.

- The conversion of a test in to a data driven test is composed of four major steps and out of which the first important step is the parameterization of the test itself. 

- The process involves the replacement of the fixed values in the following statements:

1. check point statements
2. in recorded statements with parameters

- In the next step in this process you have to deal with the setting up of a data table which is suppose to store the values that are to be fed as the arguments to the test. 

- This marks the completion of the parameterization process. 

- Later, the statements and functions are added to the test so that they can be read from the data table and can execute in a loop during each iteration of the loop. 

- Statements are added to that script which is responsible for the opening and closing of the data table. 

- This whole process becomes less head ache when carried out with the help of the data driver wizard. 

- With its aid you can either convert just a part of your script or whole of your script in to a data driven test. 

- In some cases, it happens that even though your test scripts consists of check points, recorded operations, statements etc there is no need to parameterize them, you just want to parameterize the rest of the part of the test script that will be run with multiple sets of data in a loop. 

- In data driver wizard the fixed values in recorded statements and selected check points are replaced by the function “ddt_val”. 

- This function also adds the columns containing variable values to be assigned as parameters. 

- A test script may consist of several statements containing the fixed values entered by the user. 

- There is a dialog box named as “parameterize data dialog box” that can be used for the effective and quick parameterization of the statements and replacement of the data with parameters. 

- For doing this, you need to select the particular instance which consists of the data that is to be parameterized. 

- Then, go for the parameterize data option in table menu and the box opens.

- Select the data table and enter the name for the table. 

- Then hit the “add the data to the table box” option. 

- Later, the data in this table can be modified. 

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.

How does agile teams work?

Agile teams work together as a team but include roles filled by specific individuals.
- First is the product owner, who is responsible for the product vision and for prioritizing features the team will work on.
- Next is the customer, who is the person paying for the project or purchasing the software once it is available.
- Users, developers, and managers are other roles on an agile project.

How does agile team work?

- Agile teams work in short, time-boxed iterations that deliver a working product by the end of each iteration.
- The features developed in these iterations are selected based on the priority to the business.
- This ensures that the most important features are developed first.
- User stories are a common way for agile teams to express user needs.
- Agile teams understand that a plan can rapidly become out of date. Because of this, they adapt their plans as appropriate.

What kind of planning are used for agile teams?

Agile teams use three levels of planning:
- Release planning : The release plan looks ahead for the duration of the release - typically, three to six months.
- Iteration planning : The iteration plan looks ahead only the duration of one iteration - typically, two to four weeks.
- Daily planning : A daily plan is the result of team member commitments made to each other in a daily stand-up meeting.

During release planning, the whole team identifies a way of meeting the conditions of satisfaction for the release, which includes scope, schedule, and resources. To achieve this, the product owner may need to relax one or more of her conditions of satisfaction.
A similar process occurs during iteration planning, when the conditions of satisfaction are the new features that will be implemented and the high level test cases that demonstrate the features were implemented correctly.

What is release planning and what is the need of release planning?

Release planning forms a very important part of the whole software development life cycle and from the term itself you can make out that it is related to the release of the software product.

What is a Release Plan?

- A release plan is drawn up during the release planning meeting. 

- The purpose of the release planning meeting is to lay out the overall project plan. 

- The release plan is further used to plan the iterations and schedules for the other processes. 

- For every individual iteration, a specific iteration plan is designed keeping in mind the specifications of the release plan. 

- It is important that a balance should be maintained between the technical aspect and the business aspect of a software project else the development conflicts will arise and the developers will never be able to finish the software project on time. 

- So, to get a better release plan it is important all the technical decisions must be handled by the technicians and all the business decisions are taken up by the business people. 

How to draw a proper release plan?

- To draw out a proper release plan, it is important that these classes of the stake holders co- ordinate properly. 

- In order to facilitate the co- ordination among these two, a set of rules has been defined for the release planning.

- With these rules it has been made possible that each and every individual involved with the project is able to state his/ her own decision.

- With such a way, it gets easy to plan a release schedule to which every one can commit to. 

- Otherwise, the developers will find it difficult to negotiate with the business persons. 

- The essence of the release planning meeting lies in the proper estimation of all the user stories in terms of the ideal programming weeks. 

What is an ideal programming week?

Now you must be wondering what an ideal programming week is. 

- The ideal programming week is defined as how long one can imagine regarding the implementation of a particular user story if there was nothing else to be done. 

- Here by nothing else we do not mean a total absence of the other activities! 

- It only means the absence of the dependencies and extra work but presence of tests.

Factors on which a release plan depends are:

- The importance level of a user story is decided by the customer itself.

- He/ she also decide how much priority is to be given to which user story regarding its completion. 

- There are two factors based up on which the release plan can be drawn:

1. Scope or
2. Time

Role of Project Velocity in Release Planning

- A measure called the “project velocity” helps with the release planning. 

- This measure proves to be a great aid in determining the number of the user stories that can be implemented before the last date of the completion of the software project.

- Or in the terms of the scope, the project velocity helps in determining the number of user stories that can be completed. 

- When the release plan is created according to the scope, the total weeks of the estimated user stories is divided by the project velocity to obtain the total number of the iterations that can be carried out till the due date of the project completion. 

Philosophy Underlining Release Planning

The philosophy that underlies the release planning is that the quantification of a software product can be done by the below mentioned 4 variables:

1. Scope: It defines how much work is to be done.
2. Resources: It states the number of the people available.
3. Time: It is the time of the release of the software product and
4. Quality: It defines how good the software is. 

What is meant by project velocity?

The project velocity is one of the terms that you come across while discussing about the iteration planning and release planning! The project velocity has a got a very important and  not to be ignored part to play in these two mentioned planning processes but still most of us are not aware of its importance. 

This article is centred on the project velocity and has been discussed in detail. Like the normal physics velocity, the project velocity gives the speed of the development of a software project. 

In other words, the project velocity gives the amount of work being and efforts being spent on the software project. 

About Project Velocity

- The project is simply the summation of all the estimates of the user stories that were involved in the iteration. 

- For the release planning, you add up the estimates of the user stories and for the iteration planning the estimates of the programming tasks are added up. 

- But anyway, both the factors can employed for determining the project velocity in the case of the iteration planning. 

- In the iteration planning meeting, the number of the user stories chosen by the customer is same as it was in the previous iteration. 

- There is a rule that the project velocity of the consecutive iterations must not exceed their preceding iterations. 

- These programming tasks are nothing but a broken down or divided version of the user stories. 

- The development team is supposed to take up or sign up for only the same number of tasks that were present in the previous iteration. 

- Such an arrangement proves to be a great help to the developers when they stuck in a sticky situation and need to recover and clean up from it and thus getting the average for the estimates. 

- The project velocity is suppose to rise when the developers are allowed to question the customers for other user stories when they have already finished their work and tasks like cleaning up are also accomplished.

Please do not think that you will get the project velocity consistent throughout the development cycle! It is expected to follow through some ups and downs. 

- But if a dramatic change is observed in the project velocity, then it is an issue of concern. 

- But there is no need to worry since all this can be kept in check by re- estimation and re- negotiation of the release plan. 

- It is not just in this case that the project velocity may change! 

- Even when the system is put under production for the maintenance tasks, again the project velocity is subjected to changes. 

- Division of the project velocity by the length of the iteration or the number of people involved. 

- Furthermore, the number of the people involved in the iteration is not an appropriate way for making comparisons between the productivity of two products. 

- This is so because each and every team has got its own different criteria for estimating the user stories and so we get some high estimation and some low estimation. 

- Important is to keep a track of the amount of work being done on the project so that a steady project velocity for the development can be maintained that can also be easily predicted.

The problem comes while making the first estimation! 

- At least for the following iterations you will have a clue that what project velocity is required. 

- If this measure is used properly you may be able to detect a major fault in your project much before the time at which you would have known with the help of the traditional development methods. 

Explain unstructured loops in detail?

Loops are one of the most important of the languages like C and C++. They have greatly reduced the drudgery of the programmers and developers which would otherwise have made the programming of a software system or application more hectic. The necessity of the loops cannot be ignored when it comes to the repetition of a particular executable statement or a block of statements in a program. 

In other words,

Say we have the below written statement in C++ programming language that we need to print only one time:

“hello! Welcome to C++ programming”

To print it one time we shall write the code like this:

Cout<<”hello! Welcome to C++ programming\n”;

Say now you need to print this statement a 100 times! What you are going to do- write the above C++ statement a 100 times? No! Certainly not! This is unfeasible and a complete waste of time! So what is the alternative that we have? Yes of course we have the “loops”. 

Using loop we will have to write only a small code instead of writing that C++ statement again and again for 100 times. Using loop we shall write like this:

For( int i = 1; i <=100; i++ )

{

Cout<<”hello! Welcome to C++ programming\n”;

}

The above loop is a for loop and it will the statement that we wish to be printed 100 times. See to how much extent our task has been reduced! This would not have been possible without loops. 

Loops generally are classified based on their types namely in to:

1. The while loop
2. The for loop
3. The do – while loop

But based up on their structure, they are classified in to two types:

1. Structured loops and
2. Unstructured loops

This article is all about the unstructured loops. We shall discuss them in detail. 

The Unstructured Loops

- The unstructured loops can be defined as the loops that are void of a single header or a node in the control flow graph that has all the nodes dominating the whole loop body. 

- The main problem that arises with these unstructured loops is of managing them.

- Managing them is such a hectic task.

- For analyzing the unstructured loops the programmers, developers and researchers have come up with so many ways but none of them seems to be so efficient.

- One of the ways is to use a control flow graph along with the scope graph corresponding to the function containing the unstructured loop to be analyzed. 

- This method involves attaching of each and every iteration counter with each of the loop header.

- Attaching the iteration counters in such a way can cause over estimation of the control flow. 

- So to overcome this problem, the iteration counters are attached to each basic block and this helps a great deal in achieving a lot of flow information. Even this way results in some disadvantage! 

- Therefore another method of managing the unstructured loops has been developed. 

- Another method has been developed for transforming the unstructured loops in structured ones. 

- If one looks at the unstructured loop with a view of the control flow graph they seem to have entry edges to one or more than one node all over the loop. 

- In another way we can say that an unstructured consists of parts of several different loops. 

- Several structured loops can also be merged in to an unstructured loop with the help of a code size optimizing compiler.

- A straight way has been developed for the elimination of the unstructured loops which is creating a scope with a single header for each entry of the loop. 

Explain concatenated loops in detail?

Loops as we all know are quite an essential programming constructs in the program that involve solving the complex problems with the repetition of the simple statements. With the loops it has been possible to reduce the drudgery of the programmers and developers of writing the same code again and again innumerable number of times. Everyone is familiar with the three types of loops namely:

   (i)  For loop

   (ii) While loop and lastly

   (iii) The do while loop

Based up on the structure of the loops, they have been categorized as mentioned below:

   (i)  Structured loops and

   (ii) The unstructured loops

There are various kinds of other loops like the nested loops and simple loops. Yet there is one more kind of loops that we are going to discuss in this article namely “the concatenated loops”. Before going to the discussion regarding the concatenated loops let us clear up with the meaning of the concatenation. 

What is meant by Concatenation and Concatenated Loops

- To concatenate means to join two things mostly statements or words or strings together end by end to make them in to one single statement, word or string respectively as the case may be. 

- Concatenated loops are the loops that occur in following to the preceding loop in the code of the program.

- The execution of the next loop begins only after the termination of the previous loop. 

- Concatenated loops are usually found to be the independent loops since the number of times they have to be iterated does not depends on the iterations of any other loop.

- They are treated normally as the other simple loops in the sequence.

Guidelines for testing concatenated loops

For testing these loops separate guidelines are followed rather than the simple loops.

- For the first and the last loop in the concatenated sequence, simple loop tests are conducted at the minimum possible values. 

- For the successive loops also the simple loop tests are carried out and keeping minimal values for the upper loops and typical values for the lower loops.

- Loop concatenation along with another looping technique called loop replication is used for increasing the network capacity. 

- The above mentioned approach is to be used only if the concatenated loops are found to be independent loops.

- If they are not found to be independent than the nested approach for testing is to be followed. 

- If there are two concatenated loops say loop 1 and loop 2 and if the loop counter of the loop1 is used as the initial value for the loop 2 or vice versa, then the loops are not said to be independent. 

More about Concatenated Loops

- The concatenated loops are quite easy to maintain as compared to the other types of loops except the simple loops.

- Concatenated loops form the basis of most of the program algorithms.

- The testing of these loops is carried out in accordance with the white box testing techniques. 

- The testing techniques are applied based up on the validity of the loop constructs.

- It depends up on the programmer whether the loops are tested independently or in groups. 

- The following tests can be applied to the concatenated loops:

1. Skipping of the entire loop
2. Giving one pass to the loop
3. Giving m passes to the loop where the m is less than n.
4. Giving, n, n + 1, n – 1 passes through the loop.

In the third test the n is the number of maximum passes allowed for the loop.

Explain Agile Model Driven Development (AMDD) lifecycle?

“AMDD” is the abbreviated form of the “agile model driven development” and nowadays is quite popular among the developers and programmers in the field of software engineering and technology.

AMDD took its birth from the “MDD” or the “model driven development” as its agile version that makes use of the agile models rather than using the extensive models in the pure model driven development. 

The agile model driven development was formulated out of model driven development since it was thought that the iterative development with the model driven development is possible. And since it constituted of the iterations, it was categorized under the category of agile software development methodologies. 

The agile models that drive the whole development procedure are good enough to take care of the development efforts. The agile model driven development is one of the most sought after beyond the small agile software scaling development methodologies.

Agile Model Driven Development Lifecycle

To understand this whole agile model driven development one needs to familiarize himself/ herself with the life cycle of this development model. This article is focused up on the life cycle of the agile model driven development only!

The life cycle of the agile model driven development is of quite a high level. So let us see what all are the various stages in the life cycle of the agile model driven development:

1. Envisioning: 

This stage of the life cycle is comprised of two more sub stages namely: the zeroth and the first iteration. These iterations usually come in to play during the first few weeks of the development process. This stage is actually included in to the life cycle with the purpose of the identification of the scope of the system and what kind of architecture will be suitable for developing the project. For this the following two sub stages come in to process:

(a)  Initial requirements envisioning or modeling: 

This stage may take up to several days for the identification of the high level requirements. Apart from just identifying the requirements the scope of the release product is also determined at this stage only. For carrying out with this stage the developer may require some type of usage model in order to see how the software project will be used by the customers or the users.

(b) Initial architecture modeling: 

This stage is all about setting up of a proper technical direction for the development of your software project.

      2. Iteration Modeling: 

     This stage involves planning for what is to be done with the current iteration. Often the modeling techniques are ignored by the developers while planning objectives for the iteration that is to be carried out next. The requirements in every agile model as we know are implemented in the order of their priority.

     

      3. Model Storming: 

      As mentioned in the agile manifesto the development team should consist of only a few members who are the ones who discuss the development issues by sketching it up on a white board or paper. The sessions which involve activities such as those are called the model storming sessions. These sessions are short enough to last for at most half an hour.

   

     4. Test driven development involving the executable specifications: this stage involves the coding phase using the re-factoring and test first design (TFD). The agile development helps you address cross entity issues whereas with the test driven development you can focus up on each and every single entity. Above all the technique of re-factoring the design, it is ensured that the high quality of the software project is not hampered at all.