Transition Phase - One of the phase of Rational Unified Process

There are 4 phases which together constitute the rational unified process namely:

1. Inception phase
2. Elaboration phase
3. Construction phase
4. Transition phase

The above mentioned phases are responsible for the representation of the rational unified process at the highest level in the way which is similar to waterfall model representation but the difference is that the key for the rational unified process lies in the development iterations which form an integral part of all the phases of the rational unified process. 

Also, each of the four phases of the rational unified process are characterized by two things namely the objective and the milestone. The objective drives the whole phase from the beginning to the end and the milestone concludes the end of it. 

The phase is said to be complete with successful result if and only if it passes the milestone since this only marks the conclusion of the phase. All of the phases of the rational unified process are visualized in the form of a chart called the RUP hump chart which is drawn over the course of the whole process. 

In this article we shall discuss exclusively about the fourth phase of the rational unified process i.e., the transition phase. 

Objective of Transition Phase

- The primary objective with which the transition phase is driven is “to transit the software system or application” from the phase of development in to the actual phase of production. 

- This also extends the availability of the software system or application to the end user in such a form that it is understandable by the end user. 

- This phase involves the below mentioned activities:

1. Training the end users
2. Training the maintainers as well.
3. Carrying out beta testing on the software system or application for validating it against the expectations of the end users.
4. Checking the software product against the quality level that was set in the inception phase.

- When all the objectives are said to be accomplished, the software system or application is said to reach the ‘product release milestone’ and the development cycle is said to be concluded.

- This fourth phase of the rational unified process does the fine tuning of the software product.

- It is based on the feedback from the user and the software product is made ready for the release. 

- The transition phase is basically focused on the availability of the software system or application to the end users.

- The transition phase often involves the spanning of the several iterations. 

- The software product is tested in order to prepare it for the release and also minor adjustments are made as per the feedback provided by the end users. 

- When this point in the software development life cycle is reached, it is required that the feedback from the end user should be majorly focused up on the following issues:

1. Fine tuning of the software system or the application.
2. Configuration of the product
3. Installation issues
4. Usability issues

- By this time, almost all the major issues of the product structure should have been worked out in the earlier phases of the software development life cycle. 

- The product release milestone can be defined as a point where it is decided that all the objectives of the project have been met and whether or not another development cycle is required. 

- The basic and majority of the evaluation as well as the refinement of the software system or application is done based up on the feedback from the user.

- This can be considered to be a kind of fine tuning exercise for the software system since the system has already met the requirements of the users as it is driven by the use cases. 

- At the end, a final evaluation is done and accordingly the project is released to the public or is considered for another development cycle. 

Construction Phase - One of the phase of Rational Unified Process

There are 4 phases which together constitute the rational unified process namely:

1. Inception phase
2. Elaboration phase
3. Construction phase
4. Transition phase

For representing the process at a high level, it is necessary that all of the above mentioned four phases should work together just as it is done for the water fall styled model. But here the key difference is that the primary key to the process is nothing but the development iterations that are involved in each of the development phase. Each of the above mentioned phases is driven by the objective and ended by milestone. The RUP hump chart gives the visualization for all the above 4 phases. 

Here we shall talk about the third phase i.e., the construction phase. 

About Construction Phase of Rational Unified Process

- The construction phase is driven by the primary objective for building the software system or application. 

- The primary focus of the construction phase is taken up by the components development as well as the development of the other features of the software system or application. 

- A bulk of coding is carried out in this phase only. 

- For developing a large project, it is required that several construction iterations are carried out in order to make an effort for dividing the use cases in to the segments that are manageable and that can be used in the production of the demonstrable prototypes. 

- The software version that is released in this phase is its first external release.

- The elaboration phase is concluded with the initial operational capability milestone. 

- The major thing with which the construction phase is concerned is moving the executable architecture that was created in the elaboration phase to the operational system. 

- Therefore, a beta version of the software system or application is ready to be evaluated by the project team. 

- In the elaboration phase the software product resides on the architectural baseline.

- Here, it is moved to a system that is so complete enough that it can make transition to the end users’ community. 

- The architectural baseline is grown enough to become the completed operational system via the refining of the designing in to the code. 

- This phase acquires the largest part of the whole rational unified process. 

- The remaining part of the software system or application is built on the foundation that was laid earlier in the elaboration phase. 

- Short and time boxed iterations help towards the implementation of the features of the system where an executable release of the system or application is released at the end of each iteration. 

- In this phase, writing the full test use cases becomes customary where each one marks the beginning of a new iteration. 

- The elaboration phase makes use of certain UML (unified modelling language) diagrams which are mentioned below:

1. Activity
2. Sequence
3. Collaboration
4. State i.e., transition and
5.  Interaction overview diagrams

- The purpose of the rational unified process is to provide the industry tested practices for the development, implementation and delivery of the software system or application. 

- It also provides a comprehensive frame work for the effective project management. 

- This process is actually one of the many other processes which are contained within the rational process library of the IBM RMC (rational method composer). - This makes it easy to make selection and deploy the only components that you need for your process. 

- The rational unified process is adopted for 1000s of the projects nowadays worldwide. 

- It lessens the burden of inventing a new thing again and again rather it focuses on re-usability. 

Explain Rational Unified Process (RUP)?

Rational Unified Process development framework was developed by a division of IBM known as the rational software corporation. Rational Software Corporation has been a part of IBM since the year of 2003. 

About Rational Unified Process

- Rational unified process is a single process that has a concrete prescription.

- It is a process frame work which is adaptable to a large extent and can be tailored by the organizations and development corporations as per their needs. - They can select the elements of the process that they want to be present in their development approach. 

- The rational unified process or RUP is a product that is used to process other products. 

- This product is built on a hyper linked base of knowledge consisting of detailed description about a lot of activities along with some sample artifacts.  - Rational unified process constitutes a part of the IBM’s RMC product or rational method composer.

- It is used for customizing the rational unified process. 

- All the companies combined their experiences and declared 6 best practices that are known to drive the rational unified process. 

- Those 6 best practices are:

1. Iterative development where the risk is taken as the primary iteration driver.
2. Management of the requirements.
3. Employment of an architecture based up on component.
4. Visual modelling of the software system or application.
5. Continuous verification of the quality.
6. Controlling of the changes.

- The above mentioned 6 best practices are followed by the rational’s field teams in order to assist the customers in improving the predictability as well as quality of the efforts that they put for the development of the software.

- The resulting rational unified frame work had the following three main strategic characteristics:

1. This process is tailor-able for the effective guidance of the development process.
2. Consists of tools that are used for the automation of the process.
3. Involves services that accelerate and make the adoption of both the tools and processes easy.

- Rational unified process came into existence on the acquiring of the objector y process in the year of 1996 that was written by Ivar Jacobson. 

- This original process consisted of the content from the following three things:

1. Object modelling technology or OMT from Jim Rumbaugh,
2. Booch approach by Grady Booch and
3. UML 1.0

- Later the year of 1997 saw the addition of the test discipline and requirements to the approach. 

- Below mentioned are the additions to the approach that were made subsequently after the year of 1997:

1. Year 1998 saw the addition of two new disciplines namely configuration and change management discipline and business modelling. Other things that were added included the following techniques:

a)   Performance testing

b)   UI design

c)   Data engineering

Further the rational unified process was updated to 1.1 version of the UML.

2. Year of 1999 saw the addition of the project management discipline and techniques that supported the real time development of the software. Also the rational unified was again updated to UML 1.3.
3. From year 2000 onwards most of modifications were centered around the adding tool mentors, adding techniques along with a basic guide containing step by step instructions up on how the rational tools are to be used and how the customization of the rational unified process can be automated using which customers could customize their own process and at the same time incorporating improvements in the following releases. 

What are data driven tests and how they are created in WinRunner?

When you go for testing of your software system or application, it serves good if you check the performance of your software system or application with multiple sets of different data for some set of same operations. 

For doing so you can go for creating a data driven test! Let us see in detail what actually the data driven tests are and how you can create one in the winrunner. 

What are Data Driven Tests?

- Data driven tests cuts down on the difficulty of manually executing the same test over and over again. 

- The data driven test is created with a loop that iterates exactly the same number of times as there are sets of data to be implemented. 

- Say the loop executes 20 times, so in all these 20 iterations the loop executes with a different set of data and drives the test with it. 

- Since every time the test is driven by a different set of data, the test has been termed as the data driven test. 

- However, in order to make the winrunner run a data driven wizard, use parametrization which involves the linking of the data to the test script which it is to drive. 

- After parameterization, the data is stored in a table called data table. 

- It is up to you that whether you carry out this whole process on your own manually or you take the assistance of the data driver wizard. 

- Usually a non driven test consists of the following three steps:

1. Creation of a test
2. Execution of the test
3. Analyzation of the test results.

- In data driven testing there are two additional steps are there in addition to the above mentioned 3 steps. 

- These two extra steps lie between the creation of the tests and execution of the tests. 

- These two extra steps are as mentioned below:

1. Conversion of the test in to a data driven test and
2. Creation of a corresponding data table.

Stages involved in creation of data driven test

The below stated are all the stages that are involved in the process of data driven test creation:

1. Creation of a test
2. Conversion of a data driven test
3. Preparation of data table
4. Running the test
5. Analyzation of the test results.

- You cannot directly convert a test in to a data driven test. 

- For doing so, first it is required that you should create a basic test and then convert it in to a data driven test. 

- This basic test can be created by recording a test with only a single set of data. 

- Now this test is recorded by going to the insert menu, then selecting GUI check point, then “for single property” command.

- This is to ensure that the correct order is open. 

- This order can be later modified and updated. 

- There is an alternative to this, which is that you can create bitmap check points, bitmap synchronization points and data driven GUI check points. 

- Firstly, the values contained in the check point statements and recorded statements with parameters are replaced and a data table is created which stores the values that are to be assigned to the parameters. 

- This is the parameterization process. 

- The functions and statements are added to the test scripts so that they can be read from the data table. 

Can you test database using WinRunner? What are all the different DB that WinRunner can support?

- The testing of the databases has been made possible using the winrunner with the help of the data base record check points. 

- These runtime data base record check points can be added to the test scripts and data being processed in to information in the application software during the execution of the test can be compared with the corresponding record present in the data base that you want to test. 

- With the help of these check points, it is possible to compare the contents of the data bases of the different versions of the application software.

- Whenever a data base check point is created, a query is defined in the data base of the application and the values contained in the result set are tested by the data base check point. 

- The query can be defined in any one of the following ways:

1. By using Microsoft query (it can installed from Microsoft office’s custom installation).
2. Manually by defining an ODBC query i.e., by creating an equivalent SQL statement.
3. By using data junction for creating a conversion file.

- The data base check point is said to fail when no match is found between the comparison and success criteria that has been specified for that particular check point. 

- A successful run-time data base record check point can be defined as the one where one or more than one matches were found. 

- One major characteristic of these check points is that they can be used in loop as well. 

- Results for all the iterations of the loop are recorded as separate entities. 

- The run time data base record checkpoints can be added to the test in order to make comparisons between the current values in the data base and the information that is being displayed in the application software while a test is in the process of execution.

- The run time record checkpoint wizard can be used for the following purposes:

1. Defining the query.
2. Identification of the application controls containing relevant information.
3. Defining the success criteria of the individual check points.

- While testing your data base you may land in some situations where you may require comparing the data files of different formats. 

- Following the below stated steps for creating a run time data base record check point manually:

1. Record the application up till where you want the data to be verified on the screen.
2. Calculate the expected values of the corresponding records in the data base.
3. Add the expected values to an edit field.
4. Using GUI map editor teach the winrunner about the controls of the application and the edit fields of the calculated values.
5. Add TSL statements to the test script in order to calculate the expected data base values extract the values and write the extracted values to the corresponding edit fields.

- Before you run your tests do make sure that all the applications with the edit fields containing the calculated values are open. 

- Earlier we mentioned the term “ODBC” in the article, it is actually a technology which enables the computer to connect to a data base so that the information can be retrieved by the winrunner easily. 

- Those who developed winrunner did not knew what kind of data base the AUT uses so it becomes impossible for the winrunner to know the way to connect to the data base of your application. 

- To overcome this problem, the ODBC was developed which can be taught how to connect to the data base. 

- Thus, it is because of ODBC that almost all the data bases are supportable by the winrunner.

What are the values involved with scrum?

Since the invention of the scrum software development process, it gradually became popular among the programmers and developers because of its values. 

In this article we are going to discuss about the values that made the scrum development process quite popular in the field of the software engineering. 

Values associated with Scrum Methodology

The scrum is known to support the values of:

  i) Commitment

 ii) Focus

iii) Respect

iv) Openness and

 v) Courage

The scrum is said to be powered by the above mentioned values. It may seem like following so many of the values might be so difficult! But to be honest there is nothing like that in scrum and this is what makes the scrum as one of the best agile software development methodology. You just have to follow these values to the maximum extent you can and later on it is taken care of by the development process itself.

1. Commitment

- Commitment as we know is an art in itself i.e., it is the art of binding oneself with the task at hand. 

- According to the philosophy behind the scrum software development process,  a person can only act if he/ she can commit himself/ herself to the task or work whatever the case may be. 

- Normally, it happens that we work in a state of inaction, which means we work quite unwillingly. 

- Scrum helps you to commit to the tasks. 

- For a genuine scrum process usually high levels of commitment have been observed. 

- The authenticity of a scrum process is maintained by the level of commitment of the members of the development team towards the whole development process.

2. Respect

- Respect is a value that is considered to inculcate a feeling of self esteem in a person for others as well as for oneself and also towards the work that is being done.

- There is no doubt regarding whether the scrum supports this value or not! Of course it does. 

- According to the philosophy of the scrum, no positive communication can be developed without a feeling of respect towards one’s and towards all.

- Due to a lack of respect there are possibilities of misunderstandings developing among the team members which in turn may hurt the sentiments of the people. 

- This is another value that plays an important role in maintaining the authenticity of the scrum process. 

- Respectful iterations are needed.

3. Focus

- By focusing on a particular task you concentrate all your attention on a task. 

- This value is encouraged by the scrum since according to its philosophy without focus, you cannot pay attention to any task in any meaningful way. 

- Without focusing, learning cannot be done in a meaningful way either.

- For a scrum process to be quite genuine and authentic, high levels of effective focus are required.

4. Openness

- Openness is a value of the character or behaviour of an individual defining one’s attitude of ready accessibility.

- It means one’s actions do not speck of secrecy and concealment. 

- Scrum has a habit of dealing only with openness. 

- Scrum involves extensive sharing of information among the team members. 

- This value increases the transparency of the whole development process. 

- In a genuine and authentic manner, everyone knows everything about the process and the project.

5. Courage

- Courage is strongly supported by the scrum because the truth about the reality becomes obscured when nobody speaks out regarding it. 

- Often it happens that many of the team members feel very insecure while describing the reality, they fear they might get fired. 

When should scrum be used and when should it be avoided?

There are conditions and situations encountered while the development of a software system is in process in which only one specific development methodology can be implemented! 

It does not mean that any software development methodology can be implemented any time and any where! This holds true for all the software development methodologies and so for scrum too! 

In the recent years of the use of the scrum development method, it has been observed that many developers and programmers have faced problems while implementing the scrum in the development process of their software product, project or application etc. The nature of the scrum development methodology should always be kept in mind while implementing it. 

What is Scrum Methodology?

- Scrum represents a light weight agile process frame work that primarily finds it use in the management of the software development process. 

- The scrum has been recognized under the category of light weight agile process frame works since it involves the use of very few elements, 3 core roles (namely the scrum master, development team, product owner) and three main artifacts (namely sprint backlog, product backlog and burn down chart). 

- With scrum, the rate of response to the ever changing needs of the customers is improved. 

- Scrum cannot be called as a mere process but a frame work since it is composed of several concepts and practices that together can be used to build several combinations of processes.  

- The iterations in a scrum process are cyclic in nature i.e. the iterations are repeated in every few weeks. 

- The requirements are supplied by the product owner as the user stories. 

When should scrum be avoided?

There are cases in which the scrum should be avoided! They have been mentioned below:

Case I: 

Implementing scrum in a problem for whose domain it is not compatible and

Case II: 

Implementing scrum in a development processes whose processes are against that of the scrum principles.

Case III: 

When the development processes of an organization works actively or passively against the principles of the scrum, then the scrum cannot be fully used here. 

Case IV: 

The scrum spirit is also threatened whenever a faux scrum is implemented by the company.

Case V:

Scrum can go wrong when the company involves too many people in the development process of so many projects! This phenomenon is called matrixing.

Case VI:

When the teams cannot commit to a fixed scope of work during a week, the scrum can not be implemented for that project since the scrum processes demand commitment. 

When should scrum be used?

There are cases in which scrum is used. 

Case I:

Scrum can be used well till the company is not bothered about the process that is being used at the team level and is not against the scrum values. 

Case II:

Also implementing scrum in a holistic way is itself an art and requires faith in scrum development process. 

Matrixing at the level of the scrum master is somewhat ok but may pose as a hindrance in the way of scrum. Matrixing is ok as far as the people involved in it have high knowledge and IQ levels. 

Usually teams like production support, network support and so on encounter this kind of problem with scrum. You should be careful while fixing the scope since if it’s too much for the team than your team can experience some serious dysfunction. In some cases if you are advocating for scrum, it may prove to be a disaster for you lest you know how to embrace it! 

List out the differences between extreme programming and scrum?

The scrum development and extreme programming as we all know are two very great and popular agile software development processes. 

The common thing between the two is that both of these are agile processes, but on the other side there are a lot of differences too! 

In this article we are going to discuss the same i.e., what are the differences between extreme programming and scrum? There is no doubt in the fact that the two processes are very well aligned with each other! 

It often happens while following one of these processes that if you been following extreme programming you will feel as if you had been following scrum throughout the development process and vice versa.

Differences between Scrum & Extreme Programming

The differences between the extreme programming and scrum are quite subtle but they are important things which distinguish between the two processes from each other. Below mentioned are some of the differences between the scrum and the extreme programming:

Difference #1:

- The first subtle difference between the two is the duration of the iterations.

- In extreme programming the iterations are usually short i.e., one or two weeks long. 

- On the other hand the scrum iterations are quite long and may range from several weeks to months. The sprint is the name given for the iterations carried out in the scrum methodology.

Difference #2:

- In scrum, any changes during the development process are not supported by the scrum and neither do any changes are allowed in the iterations or sprints. 

- Once the sprint planning meeting is completed and it is decided to deliver a set of product back log items, the plan is not altered till the very end of the sprint. 

- In contrast to scrum, extreme programming iterations are known to be quite flexible since they allow changes to be incorporated in to its iterations. 

- But the changes can be made only if the team has not started working on a particular feature. And also the feature to be changed must be of the equivalent size of the feature that is to be replaced and has not been built up.

Difference #3:

- Extreme programming, has been known to work strictly in the order of the priority assigned to the various features and aspects. 

- These features and functionality had already been prioritized by the customers. 

- The customer is not considered to be the whole owner of the extreme programming product, whereas in the scrum it is do considered. 

- In the scrum development, the features are not prioritized by the customer instead the customers prioritize the product’s back log items.

- It is then the responsibility of the development team to determine the sequence for the development of the back log items. 

- In the extreme programming, the development always starts from the highly prioritized features and functionality.

- In scrum, the developers think that starting from a highly prioritized feature is not always a good option. They think that working up on low priority items makes more sense.

Difference #4:

- Under the concept of the scrum development process, no particular engineering practices have been stated. 

- But the extreme programming does prescribes some engineering practices like the TDD or test driven development, automated testing, simple designing, programming in pairs, refactoring and so on. 

But following the same practices is not always desirable! It is needed that the teams should incorporate their own values.

The above mentioned differences are quite small but they do make considerable set of difference and can have a profound impact on the development team. 

The extreme programming works well when it is not mandated and the teams are left to discover their own practices. Scrum methodology when worked out with time boxed iterations and additional focus can work wonders. 

What is meant by iteration planning?

Iteration like the release planning holds the same level of importance in the software development life cycle of a software product especially when the agile software development processes are being used to develop it. In this article we are going to discuss about the iteration planning in detail. 

Fundamentals of Iteration Planning

- It is important that the do's and don’ts of an iteration are planned at the very beginning of the iteration so that later no hindrances fall in the path of development. 

- So for this purpose, a meeting is called up which is commonly known as the iteration planning meeting. 

- This meeting is called up at the beginning of the iteration and is called for every iteration. 

- The purpose of this iteration meeting is to plan for the programming tasks that are meant to be completed in that iteration. 

- Iteration is not a small activity; rather it takes around 1-3 weeks for its completion. 

- The whole set of such activities is called an iteration plan. 

- Actually the duration of an iteration depends on the size and complexity of the software project.

- For each iteration, a user story is chosen for each of the iterations which appear in the release plan by the customer or the client on the basis of its importance to him/ her. 

- Apart from the user stories the acceptance tests that previously were not passed by the program are also taken in to consideration during the iterations so that they can also be fixed up. 

- The user stories that have estimates equivalent of the project velocity from the last iteration are also considered in to iteration planning of the succeeding iteration.

- These acceptance tests and user stories are divided in to programming tasks that are quite supportive for them. 

- These tasks are written down on the index cards similar to that of the user stories. 

- User stories and the tasks are developed in different languages i.e., the user stories are developed in the language of the user whereas the tasks are developed in the language of the developers.

- The tasks having duplicates can be removed. 

- The tasks are written on the cards along with the plan for implementing them. 

- Several developers sign up to accomplish these tasks and draw up the schedule for completing them so that the time taken for their completion can be estimated properly.

- There is one very important thing to be noted here is that the person who takes up the responsibility for completing task should be the one to estimate its time budget and nobody else should do it.

- This is so important because the estimation is largely dependent up on the abilities of the individuals i.e., some might be able to complete it in a few days while others may take a little longer since the people are not interchangeable and hence one who is doing the task must only figure out the estimate. 

- After the estimation of the tasks again the project velocity comes in to the play in the determination of the status of the iteration i.e., to check whether it is over or not. 

- The total time estimate in the ideal programming days similar as that in the case of the release planning must not exceed the project velocity of the preceding iteration. 

- If it exceeds then the customer is suppose to put off some of the user stories for the later iterations i.e., snow ploughing. 

- In another case, if it is less then the previous iteration then some more user stories can be helped too! 

- The velocity of the iteration planning is known for overriding the velocity in the release planning since it is more accurate. 

- Some people may not approve of the snow ploughing but it can be curbed by the techniques like unit testing and re-factoring. 

- You should always avoid adding a feature or functionality before it is really needed.