Enhancing Product Design: Collaboration Between Product Managers and Usability Experts

The collaboration between a product manager and a usability expert is one of the most important yet often understated aspects of successful software development. Each plays a distinct but interdependent role in shaping the final product, and when their efforts are aligned, the result is a well-designed, user-friendly product that addresses real-world needs.

The Role of a Product Manager in the Development Lifecycle

The product manager is the guiding force throughout the product development or project execution cycle. They are deeply involved at every step — from defining initial requirements to guiding development teams, validating workflows, and ensuring that customer expectations are met.

Some of the core responsibilities of a product manager include:

• Delivering detailed feature requirements to the engineering teams.

• Collaborating with developers during the design and implementation stages.

• Providing critical clarifications when edge cases or gaps appear in design documentation.

• Conducting testing — particularly of newly developed or modified features — to ensure the experience aligns with expectations.

• Participating in beta programs and collecting feedback from early users.

• Helping to prioritize defect fixes based on feedback severity and customer impact.

In essence, the product manager acts as the bridge between customer needs, business goals, and the engineering team’s execution.

The Strategic Role of Usability Experts

While usability experts may not be involved throughout the entire cycle like product managers, their role is essential — especially during the early design phases. Usability experts focus on how a product "feels" and functions from the user’s perspective, aiming to make interfaces intuitive, appealing, and efficient.

One particular cycle that stands out involved a comprehensive redesign of a mature software product. The product team had compiled multiple user complaints, feature requests, and visual feedback from previous versions. Alongside this, the interface was beginning to feel outdated.

To gain executive buy-in for the redesign, we had to articulate the vision clearly. Phrases like “modernizing the interface” or “improving the user journey” resonated surprisingly well — especially when backed by usability metrics and customer sentiment analysis.

When the Real Interaction Begins

In situations like a full UI overhaul, the interaction between the product manager and the usability expert can begin even before a development cycle formally ends. Planning, ideation, and initial wireframes often start in parallel with the finalization of the current release.

Several key sources guide their collaboration:

• Customer complaints and forum feedback: Recurring pain points or requests indicate problem areas.

• Expert analysis: Usability specialists often identify issues by examining screen flows, layout consistency, or call-to-action placements.

• Product manager insights: Based on product knowledge and user feedback, the PM often has a list of areas needing attention.

• Technical limitations or new opportunities: Sometimes UI changes are driven by backend modifications or updated component libraries that enable previously impossible workflows.

A Cyclical Design Process

Usability improvements aren’t achieved in a single pass. Typically, the usability expert begins by proposing a refreshed flow or layout for a screen. The product manager and other stakeholders review the changes, offering insights and critiques. Based on that feedback, the next iteration is refined and validated.

This process repeats across numerous screens and workflows. In large products, it’s rarely feasible to redesign all screens simultaneously. Instead, the usability expert works iteratively, and teams begin implementation as soon as screens are finalized.

Here, the product manager’s role becomes even more crucial. They can help drive the process forward by working alongside the usability expert to:

• Prioritize which screens or workflows should be tackled first.

• Ensure engineering teams receive enough detail to begin development.

• Translate early wireframes into preliminary requirements that can evolve as designs solidify.

Project Management and Scheduling

Managing a UI redesign project involving multiple stakeholders is no small task. It requires deft project management, clear communication, and tight scheduling. Project managers often rely heavily on product managers to coordinate with usability teams and ensure timely delivery.

The agile model can be particularly effective here. Breaking down the redesign into sprints, assigning specific screens or modules per sprint, and tracking feedback cycles keeps momentum going and avoids analysis paralysis.

Measuring the Impact of Product Manager and Usability Expert Collaboration

While the collaborative process may seem time-consuming, the benefits are immense:

• Better user experience (UX): Directly correlates with increased user satisfaction and engagement.

• Fewer design iterations post-launch: Reduces rework and development time.

• Clearer workflows and screens: Improve usability scores and reduce support tickets.

• Stronger stakeholder alignment: Ensures fewer surprises late in the development cycle.

Ultimately, products created through strong product manager–usability expert collaboration deliver more value and are more likely to succeed in competitive markets.

Final Thoughts

Whether it’s a small feature update or a complete redesign, the bond between the product manager and the usability expert is essential. By bringing together customer insight, technical knowledge, and design thinking, they create experiences that not only look good but work well — delivering tangible value to end users.

If your team is preparing for a UI refresh or tackling a complex workflow change, investing in this collaboration early can make the difference between mediocre and exceptional.

Suggested Amazon Books on Product and Usability Collaboration

• Don't Make Me Think by Steve Krug (Buy - Affiliate link)

• Inspired: How to Create Tech Products Customers Love by Marty Cagan (Buy - Affiliate link)

• The Design of Everyday Things by Don Norman (Buy - Affiliate link)

Helpful YouTube Videos on Product Management & Usability Design

UX Design: What Product Managers Need To Know

What is UX? User Experience Explained For Beginners

---

Emotional stability - Somebody's got to remain in control during a heated discussion

This was a painful episode when seen in highlight, and something that has stayed with me the rest of my career and even intruded into my personal life. I did not do something outrageous, but the concept of making your way down a path where there is no easy way back has remained with me ever since, and everytime I get into a situation where it could become problematic, I recall the incident to see that I am not boxing myself into a corner.
The exact incident could vary, but the scenario is the same. You are Project Manager / Program Manager of a team with colleagues who have different roles, and their emphasis at different parts of the schedule is different. At a particular point in the schedule, even though both Development, Usability and Testing are supposed to be on the same wavelength, their focus and push could be different, and that is very natural. In this particular case, the situation happened at the time of the schedule when we were supposed to stop all new feature work, from that point on, all the focus would be on resolving defects in the features already implemented.
This is a critical moment for the testing team, since they essentially consider this the time when the entire product comes together, with all features working to some degree or the other (one is really considering a development process that is not ideal scrum). The integration testing happens more critically from this point onwards, and it can take a lot of time from this point in the schedule to thrash through most of the defects and make the product stable (of course, you cannot find all the defects in the product). The testing team is expected to not welcome any addition of new features from this point onwards.
This was a critical time. Some of the members of the development team had come in mid-cycle, so there was already some instability in the team, and it did take them some time to understand the product code and understand the team dynamics and work together as a team. At this time, the Product Management came in with a critical new feature (that had been introduced by the competition) which was expected to take another 2 weeks to develop, with the remaining testing time being around 1.5 months. Now, this was not an easy situation. The testing team was well justified in terms of not agreeing to take this feature, since in the end, it was their responsibility to ensure that the product was stable and had the least number of defects possible. The product manager was quite serious in terms of the need for this feature, and was pushing for it. The development team was ready to implement it.
The first meeting to discuss this was a disaster, with these stated positions being discussed, and getting heated. For me, unfortunately, being the Program Manager, it was my responsibility to ensure that the discussion remained in reasonable limits of discussion, without getting heated, and nobody getting into an inflexible position. However, in this case, at some point, the discussion went into a thread of policy and schedules, and it turned out that I started taking a more inflexible position, whereby such a change would not be possible. The discussion terminated soon after, and it got escalated, and during the midst of a discussion with my manager, I realized my mistake (while I was being chewed out). In every discussion, typically the managers need to ensure that discussions need to remain on a civil level, discussions can get heated, but nobody should reach a point where they get into a position from there was no roll-back, and certainly not the Project Manager / Program Manager. 

Trying to get non-responsive members of the team be more schedule sensitive

We know this problem, it happens all the time. You have different members of the team, some more disciplined and some less disciplined. Actually discipline is the wrong word. When you have creative members of the team, or team members who are attached to multiple projects, then there can be problems with respect to scheduling of their deliverables. In the case of team members such as User Interface Designers or Visual Experts, or Visual Designers, they typically do not move to the same beat as that of the rest of the project teams, such as Engineers or Testing Engineers.
This can be problematic for the rest of the team, since schedules are interlinked to each other. For example, the User Interface Designer would prepare design specifications that are used by the team members to discuss and finalize the feature workflow and the technical architecture. These are then developed and passed onto the testing team which does the testing and then releases the feature. However, if the initial design does not come in time, then the rest of the schedule will get impacted.
One of the problems that I have experienced with User Designers or similar creative people is that they do not work in pieces; they would like to look at the overall workflow for the product and then release a completed design. But the team does not work like this, it would like workflow designs feature by feature, so that the work can be done feature by feature (and it makes logical sense).
Another option that could have been postulated is that the Workflow Designer could have a period of 2-3 months before the start of the cycle, so that the Designer gets enough time to make the design. This seems logical, but there are problems in this. The Workflow Designer does not work entirely on his / her own, but needs to work with the Product Manager and the team members (the team members  are involved so that the team could figure out the technical cost of doing the Workflow designs; some of these workflows may take more time and effort than other workflows and the contribution of the technical team in figuring out these is critical. This process can be iterative).
So how do you work out trying to get such more creative members as part of the process?
- First and foremost, it is necessary to ensure that you do not make the assumption that these resources understand the critical nature of meeting their schedule deliveries. It would be needed to spend much more time with these people and form a detailed plan for deliveries, doing this discussion multiple times till an understanding has been formed.
- In my experience, it was also necessary to have 2 dates in the schedule with a few dates gap between the 2 dates. It was necessary to push the delivery to happen for the first date, but there was also the understanding that the delivery happening on the 2nd date would also work fine without threatening the schedule.
- It was also realized that there was the need for a regular reminder along with checking about state of progress and updating the rest of the team on such progress. So, the Project Manager had setup a weekly meeting with the workflow designer to discuss the state of progress and the deliverable, and figure out alternatives if there was a delay.

How to cope with team members (or functional teams) who do not easily follow deadlines / schedules ?

Aah, this is one of the most difficult posts to write, since there is no magic bullet answer. Let me take a situation where you have some team members or functional folks who are not really up to working with schedules, or are disciplined about schedules as the development or testing members of the team. What happens typically ? You have a schedule that has been worked out pretty diligently, that takes into account the work of different team members and functional folks, and gets them all integrated with each other to have a schedule that promises, if you follow the schedule, that you will have your software application ready.
So if everything is going well, if the project management structure of the team is tracking the schedule and the entry and exit of each of the team members as per the schedule, then everything can work out. Further, a lot can be done to help in the process, by setting up systems that provide advance schedule information to the team members, before their tasks are due to start, as well as close to when their tasks are about to end. This can be followed by status meetings and other to ensure that team members have all the information that they need to get their tasks done, and any problems that they are having can be followed up.
However, if everything went so smooth, schedules would always work and there would never be any kind of problems regarding risks, and so on. One of the biggest elements of risks in the entire schedule, just from the scope of delivery from the different functional teams is regarding adherence to the schedule. When you consider the functional requirements of the schedule, you will have requirements and feature details from the product management, followed by elements of design (architectural, workflow and others) from the development and user interface designers, and then the actual development and testing. One of the biggest problems that I have seen is with regard to the more creative elements of this process, namely the user interface designer or the workflow designer. We had an interesting interface designer who would just tell us that to give him a final date by which the entire design would be needed, and not bother about interim dates since that was not the way that he worked. There is some justification, since the user interface designers tend to be creative folks who are not really as bound to a schedule as the rest of the development and testing teams. However, this can screw up the entire schedule, since the assumption is that there are dates by which the designer needs to submit a first draft and there are iterations through which this draft is discussed, and then finally agreement is reached on the final draft to be used for the product development.
So, what do you do ? Well, here are some techniques that we used:
- Ensure that there is ongoing communication with the designer. Typically, it was during a regular phone call that we would find out about some issue that the designer was running into, but which the designer had not told us about via email.
- Remind the designer on a regular basis when the schedule for either the start of the tasks or the end of the tasks was coming up to ensure that this was on the top of the mind
- Add some buffer to the schedule of the user interface designer, and start harassing from the first schedule so that you know that you can expect to get the work by the buffer date

What happens when you find a serious defect right before you release ??

The end game of a software development schedule can be very critical. It is the timeframe when you are hoping that there are no critical problems that pop up - given that the time involved in turning around for solving critical problems is less, and the amount of tension that such a problem causes to everyone in the team can be enough to give a coronary to everybody involved. Once we had a defect come up 2 days before we were supposed to release the product, and the complications were very bad (in terms of decision making - we had to decide whether the defect needed to be taken, we had to get somebody very safe to diagnose that defect, we had to evaluate the fix to see that there was nothing else that could get broken, we had to then roll out the fix into the product and test the hell out of the fix to ensure that there was nothing that was getting broken). All of this caused a huge amount of tension, and we had management on our heads, wanting to know the progress, and more worryingly, why this defect was not caught before, and whether we were confident that we had done enough testing to ensure that we had caught all other such defects such as this one.
Typically, when you reach a situation like this, you need to ensure that you are thinking through all the options. It is all right to brazen it out and hope that everything will go well and say that you are fine with releasing the product. But, without having done a proper analysis, that would not be the correct option. If you want to get the product released in this haste, then you might be reaching a situation where user find serious defects after the product has been released, and that is something that no one wants. Such a situation, if it happens more than once, can cause loss of user confidence in the product, and to some extent in the organization, and have a lot of serious consequences. However, in most cases, I know teams tend to brazen it out even if they see much more problems later.
But, on the other hand, you cannot suddenly decide that you are willing to take a delay on the product release date to get some extra confidence of the testing (which would have been shaken due to the recent serious defect found). This sounds good, but there are costs involved with such a decision. A product delay causes a loss in revenue, also can cause some customer confidence problems if the organization suddenly has to announce a delay in release, and cause a huge impact on the team morale as well because of management involvement. However, it may be less of an impact than if the product is released and the customers find many problems.
So how do you make such a decision ? Well, that is the million dollar question. And there are no easy answers. To a large extent, whatever decision is made has a number of risks, but it is important to get genuine feedback from the testing team about what they feel, especially from the test managers (and this needs to be done in environment where there are fewer recriminations). Finally, the team manager needs to own the decision and be able to justify this in front of management.

Synchronizing multiple activities together in a complex environment

Typically, during the software development cycle, most of the activities are straight-forward. For most features, the way that the cycle flows is that the feature request flows into the requirement phase where the requirements are defined (if you are doing Scrum, then there are User Stories defined for the feature that make up the feature request), these are then converted into design, and then into the coding phase followed by testing. The sequence of activities is typically linear, and not complicated, the only variables being the amount of resource effort needed for the work, and the schedule of the feature.
However, sometimes you come across a feature that is more complicated than the normal case. There can be complex features which have dependency on multiple other features, and it is takes effort on the part of the team, and of the project manager to work on these dependencies, figure out their schedules and ensures that everything in in place and at the same time, things are going on track.
For example, consider the case of a feature which depends on a change in the database structure (addition of one more table to the database structure as well as modification of an existing table) as well as hook-ups with other features (to send and take data from this new feature). In addition, since this is an existing product and a new version is being developed, users who more from the previous version of the product to this new version will need to ensure that their existing data is migrated from the previous database structure to the new structure. For this purpose, there will need to be data migration scripts that are ready, which will need to be run before testing of the new feature can happen.
Typically in most teams, this work is done by separate feature teams. All changes to the database structure (there may be changes requested to the database from multiple feature teams and it is more efficient to ensure that only one team is doing the required database changes), and similarly, other feature teams also need to make the changes on their end.
How do you ensure that all this is happening properly ? For the feature to work properly, it is necessary that all these changes from the different feature teams be synchronized to happen so that the feature is done. This requires intensive work from the project manager to work with the schedules of these different teams, shuffling them around until these different tasks all are planned to happen before the main feature. This can be captured in a tool, where the required tasks are all captured as dependencies of the main feature, thus ensuring that the team working on the main feature is not expected to start work before the dependencies are all done (or atleast, are done to the required degree as per the dependency logic). This also ensures that any modification to the schedule of these tasks are captured in the tool, and in turns affects the schedule of the main feature.

Sending a weekly list of tasks for the team at the beginning of the week

As a part of project management, it is very important to ensure that the team has adequate knowledge of the tasks that are coming up in the near future. If you maintain an updated task schedule, then the task schedule will have an updated list of the tasks for each team member, and this should be easily accessible to the team members. It is important that the team members be given access to the schedule and task tracking tool with the required level of access rights. Them not having access to the tool would put a lot of pressure on the project manager to control the tool, and also be accessible whenever a team member needs access to the tool, either for viewing a certain detail, or for modifying a certain detail.
However, it is also a reality that in many cases, especially when you have a team that is not so mature, there is a resistance to accessing the tool (and this may be justified to some degree; I have seen many tools that combine a high amount of functionality into the UI of the tool with the assumption that it will be primarily accessed by the project manager and can be fairly cumbersome for a developer or tester to update). As a result, you end up with a situation where the team members has not really accessed the details of the upcoming tasks and there are delays (and this can be almost comical if it was not serious to the schedule - once when I asked a couple of team members about why they did not check the details of the schedule in the tool to review their upcoming tasks; they put the blame on me about having a horrible tool and why I did not inform them about the tasks in their name).
Based on all this information and after discussion with the team managers, there was felt the need to actually send out a communication of the tasks that are doing to coming to team members in the upcoming week. So, we worked on setting up a report (or rather, 2 reports) which tried to provide the following details:
- A large list of the upcoming tasks for the week across all the team members. This would list the tasks per day as well as the team member and the estimated days. This list was also printed and up on a large board next to the team's physical location where they could see the list at all times. We also encouraged the team members to actually run a line through a task that was completed, which was a good way of letting the team see that there were tasks that were getting done.
- In addition to this, the other report went at individual level. This report listed out the ongoing tasks for the person, the upcoming tasks for the week and the tasks that were also expected to be completed in the upcoming week. This report was more detailed, and there were enabled links in the report that would take them the team members (via the login process) to the section of the tool where they could update their tasks. This particular report was however tweaked to ensure that team members could log into the report site and do customization - one team member had typically broken up his task into 2 day chunks and he had set the report to come to him once in 2 days, ensuring that the report was very useful for him.

Processes of the last few days and weeks of a product release schedule ..

As part of a normal product cycle, the last few days and weeks are the ending points of all the hard work, frustration and rewards of the schedule. It is a critical time period in the schedule with the following properties:
- The team is doing their final set of testing / verification. Towards this end, the entire set of test plans and cases would not be running since that may take up more time than is available. For shorter time periods and for quick verification that everything is running fine, a subset of the test cases would be made ready to execute. If automation is made available, then these should be running on a regular basis.
- Any changes to code or defects fixes are being monitored very closely and thoroughly to ensure that there is no risk from these changes to the code. In some cases, when time in the schedule is short, only defects that are deemed very high severity will be fixed and that too when the impact of the changes can be safely evaluated
- All the release documents including the Help file and release notes are all ready and reviewed
-  External testers / pre-release testers have been using the software for some time and all of them have verified that they have been using the product and a majority of them have also deemed the software product ready for release. This can be critical. When the software is near the release period, people not belonging to the team and who are an approximation of the customer base of the product should be comfortable with the quality level of the product and the set of features in the product.
- In many cases, during the testing process, features that require connection to an online server are typically connected to a test or staging server rather than the live server. During the last few days, these connections are changed to the live server and the product is testing with those rather than with the staging server. There is a possibility that this kind of change may bring about some instability in the system and hence the changes need to happen before the release date (atleast a few days before the release date).
- When the product also needs to be released on DVD and on the product web store, there is a need to do final verification on such systems to ensure that everything is working fine (which includes generating actual DVD's and installing from them to ensure that everything works as it should).
- Defect stats are monitored very finely to ensure that there are no surprises at that end.

Working with people who are not so responsive as developers or testers ..

It can really test the patience of a team when they work with people who do not seem to follow the same guidelines, processes and schedules as the rest of the team does. It seems a bit odd though. The schedule is the most important item of a software development project, with a lot of effort going towards determining whether the team is following the schedule or not, and if there are any slippages from the schedule, it can imperil the success of a project. If there are slippages of the schedule, then it would take a lot of effort from the project manager and other managers and senior members of the team to get the project back on track. In such a case, it seems strange that there can be members of the extended team who are not so committed to the schedule (actually, it is not right to say that they are not committed to the project, it is just that it can be a challenge to get them to follow the details of the schedule).
Who are these members of the extended team ? Well, let me lay out a few candidates (and this does not mean that every one of these roles will not follow the details of the schedule, but I do know many people who were in such roles with whom it was a challenge to get them to follow the schedule) - these are typically the more creative people of the team - in some cases, the Product Manager; in more cases, the UI Designer or the Experience Designer; and even in other cases, some of the more senior members of the development team.
Does this really happen ? Well, yes, it happens like this all the time. Let me layout some examples - during the course of a project schedule, there is an initial time period when the requirements need to be defined by the Product Manager (with a certain detail inherent in these requirements, a level of requirements that is enough for the workflow designer and the development team to do a certain level of estimation), and more often than not, unless I, as the Program Manager would do a lot of reminder to the Product Manager, there would always be some amount of delay, or the requirements that were available were not of enough detail. As a result, by a couple of cycles, we had actually started giving a buffer so that after all the urging, there would be time to do a couple of cycle of the requirements. Given that the Product Manager is also typically a senior person, we did not try any other method of ensuring that they finished their work by the scheduled time; instead we added a buffer of around a week in the overall schedule.
The bigger problem was when we were dealing with the experience designer / UI designer. The interaction with this person was on a regular basis, for more than 70% of features (given that most of the features needed some kind of UI work, or needing some kind of workflow optimization). Hence, it was not only the overall schedule, but also the schedule for each feature that needed dates and details for work supposed to be done by the UI designer. The work done by the designer followed in a logical order to the requirements and was needed for the development team to do their work, and hence any delays in this work would cause a ripple effect all down the schedule. However, in a clear case of Murphy's Law, the chances of there being a delay from the designer end was high (not always, but in most cases, there would be something pending).
How do you ensure that the work done by the designer was on time ? Well, there are no clear ways (atleast nothing that was 100% successful), but here are some steps:
- Layout a clear schedule for when the delivery from the designer is expected, including dates for interim deliveries, review times, and final deliveries.
- If the designer does not agree with the dates that you would have started out with, and considers them too aggressive, then you need to do a discussion. Don't try to force any dates on the designer from your end, make sure that dates are negotiated.
- Setup a weekly telecon with the designer, and make sure that you are reminding them of the dates that are due, and also find out from them whether they are on track or not. If wildly out of track, then you might need to modify your dates to some degree, and make sure that the team knows about.
- If there is a manager from the designer end who is looking at this, then make sure that they are also in the loop for the work done.
- Finally cross your fingers and hope that this is not the schedule where the designer is going to delay their deliveries.

Explain the Priority CPU scheduling algorithm

A number of scheduling algorithms are available today and all are appropriate for some different kinds of scheduling environments. In this article we give a brief explanation about the ‘priority CPU scheduling algorithm’. 

For those who are not familiar with this scheduling algorithm, a special case of the priority algorithm is the shortest job first scheduling algorithm (SJF). 

- This algorithm involves associating a priority with each and every thread or process. 

- Out of all the processes, the one with the highest priority is chosen and given to the processor for execution. 

- Thus, it is decided by the priority that which process has to be executed first. 

- There are cases when the two or more processes might have the same priority. 

- In such case FCFS (first come first served) scheduling algorithm is applied. 

- The process first in the queue is then executed first. 

- The SJF is essentially a modification of the priority algorithm. 

- Here, the priority of a process (indicated by p) is simply taken as the inverse of the following CPU burst as predicted. 

- This implies if a process is having a large CPU burst, then its priority will be low accordingly and similarly if the CPU burst is small, the priority will be high. 

- Numbers in some fixed range are used for indicating the priorities such as from 0 to 4095 or from 0 to 7 etc. 

- One thing to be noted is that there has been no general agreement up on whether the number 0 indicates lowest priority or highest priority.

- In some systems the lower priorities are indicated by the low numbers while in some systems low numbers mean higher priorities. 

- The latter case i.e., using low numbers for representing high priorities is more common.

For example, consider the 5 processes P1, P2, P3, P4 and P5 having CPU burst as 10, 1, 2, 1, 5 respectively and priority also respectively as 3, 1, 4, 5, 2. Using the priority scheduling algorithms, the processes will be executed in the following order:

P2, P5, P1, P3, P4

There are two ways of defining the priorities i.e., either externally or internally. This gives two types of priorities:

1. Internally defined priorities: These priorities make use of some quantities that can be measured for computing a process’s priority. These quantities include memory requirements, time limits, ration of the I/O burst and CPU burst, number of files and so on.
2. Externally defined priorities: These priorities are defined by some criteria that are external to the operating system. Such factors include political factors, department leading the work; importance of the process, amount of money paid and so on.

The priority scheduling can be itself divided in to two types namely non – preemptive or preemptive. The priority of the process waiting in the ready queue is compared with that of the executing process.

Ø  Preemptive priority scheduling: Here the CPU is preempted if the waiting process has a priority higher than that of the currently executing process.

Ø  Non – preemptive priority scheduling: Here the new process will be let waiting in the ready queue till the execution of the current process is complete.

Starvation or the indefinite blocking presents a major problem in priority scheduling. A process will be considered blocked if it is ready for execution but has to wait for CPU. It is very likely that the low priority processes will be left waiting indefinitely for CPU. In a system that is heavily loaded most of the time, if the number of high priority processes is large, the low priority processes will be prevented from getting processor. 

What is CPU Scheduling Criteria?

Scheduling is an essential concept that serves in the multitasking, multiprocessor and distributed systems. There are several schedulers available for this purpose. But these schedulers also require a criterion up on which they can decide how to schedule the processes. In this article we discuss about these scheduling criteria. Today a number of scheduling algorithms are available and all these have different properties. This is why these may work up on different scheduling criteria. Also the chosen algorithm may favor one class of processes more than the other.

What Criteria is used by algorithms for Scheduling?

Below mentioned are some of the criteria used by these algorithms for scheduling:
1. CPU utilization:
- It is a property of a good system to keep the CPU as busy as possible all the time.
- Thus, this utilization ranges from 0 percent to 100 percent.
- However, in the systems that are loaded lightly, the range is around 40 percent and for the systems heavily loaded it ranges around 90 percent.

2. Throughput:
- The work is said to be done if the CPU is busy with the execution of the processes.
- Throughput is one measure of CPU performance and can be defined as the number of processes being executed completely in a certain unit of time.
- For example, in short transactions throughput might range around like 10 processes per second.
- In longer transactions this may range around only one process being executed in one hour.

3. Turnaround time:
- This is an important criterion from the point of view of a process.
- This tells how much time the processor has taken for execution of  a processor.
- The turnaround time can be defined as the time duration elapsed from the submission of the process till its completion.

4. Waiting time:
- The amount of time taken for the process for its completion is not affected by the CPU scheduling algorithms.
- Rather, these algorithms only affects the time when the process is in waiting state.
- The time for which the process waits is called the waiting time.

5. Response time:
- The turnaround is not a good criterion in all the situations.
- The response time is favorable in the case of the interactive systems.
- It happens many a times that a process is able to produce the output in a fairly short time compared to the expected time.
- This process then can continue with the next instructions.
- The time taken for a process from its submission till production of the first response is calculated as the response time and is another criterion for the CPU scheduling algorithms.

All these are the primary performance criteria out of which one or more can be selected by a typical CPU scheduler. These criteria might be ranked by the scheduler depending up on their importance. One common problem in the selection of performance criteria is the possibility of conflict ion between them.
For example, increasing the number of active processes will increase the CPU utilization but at the same time will decrease the response time. This is often desirable to produce reduction in waiting time and turnaround time also. In a number of cases the average measure is optimized. But there are certain cases also where it is more beneficial to optimize the maximum or the minimum values.
It is not necessary that a scheduling algorithm that maximizes the throughput will decrease the turnaround time. Out of a mix of short and long jobs, if a scheduler runs only the short jobs, it will produce the best throughput. But at the same time the turnaround time for the long jobs will be so high which is not desirable.

What is Testing Anywhere software product? What are its uses?

Testing anywhere software product was developed by the Automation Anywhere Inc. based in San Jose. This is another software in the category of test automation tools. This software has proven to be a boon for the software testers and developers who have to test the web sites, applications, GUI front-ends, objects and controls. The product has got many uses from recording to the execution of the test cases. It is used for the following major purposes:

1. Recording of the tests
2. Debugging them
3. Scheduling their execution
4. Executing the tests

The above mentioned operations can be carried out for a number of application types such as:

1. Java
2. Silverlight
3. Mainframe
4. C++
5. .NET and so on.

Testing anywhere product provides option for automating the test case creation. Testing anywhere offers you 5 different methods for creating the test cases namely:

1. Web recording
2. Object recording
3. Image recognition
4. Smart recording and
5. Editor

- The test cases thus created using any of the above methods can be later recorded, edited, saved and can also be enhanced. 

- The editor is used for editing the test cases. 

- People who don’t have programming skills can use the wizard for creating and editing the test cases. 

- Testing anywhere software lets you create files with .exe extension i.e., the executable files which later can be deployed by the software testers on remote machines. 

- The creation of a high level IT and business processes is the responsibility of the workflow manager. 

- Further, workflow manager only takes care of the ability by virtue of which these processes are managed. 

- It supports a number of platforms:

1. Microsoft windows 7 (both 32 and 64 bit)
2. Microsoft windows vista (both 32 and 64 bit)
3. Microsoft windows XP (both 32 and 64 bit and along with service pack 2)
4. Microsoft windows server 2008 R2
5. Microsoft windows server 2003

- Testing anywhere supports the following kinds of testing:

1. Integration testing
2. Compatibility testing
3. Performance testing
4. GUI testing
5. System testing
6. Java application testing
7. Automated flex testing
8. Silverlight application testing
9. Mainframe application testing
10. WPF testing
11. Third party .NET supported testing
12. Automated software testing
13. Automated web testing
14. Regression testing
15. Distributed testing
16. Functional testing
17. Black box testing
18. Acceptance testing
19. Unit testing
20. Keyword driven testing
21. Data driven testing
22. Smoke testing

- The product has been named because of the facility that it provides for running the tests on any remote machine present in the network. 

- Further, it reduces the testing cost by a huge margin since it cut down the money being spend up on the software licenses, resources, and training and time of course.

- Testing anywhere provides you a SMART recorder for creating new tests.

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. 

Elaboration Phase - One of the phase of Rational Unified Process

The life cycle for a project under the context of the rational unified process is known to consist of the following four phases:

1. Inception phase

2. Elaboration phase

3. Construction phase

4. Transition phase

Here we shall discuss about the second phase of the unified process i.e., the elaboration phase. In Rational Unified Process, the four phases represent the process at a high level although the iterations that are carried out in every phase of development are the key to the process. 

Each phase here is provided with an objective and a milestone. It is necessary to have a milestone for each so that it could be decided that when and where a particular phase is ending and the next one is starting. All the above phases as well as the process disciplines are visualized in to what is called an “RUP hump chart”. 

About Elaboration Phase in Rational Unified Process

- The primary objective of the elaboration phase is defined as the mitigation of the key risk items whose identification is done by the analyzation of the whole phase from the beginning till the end. 

- It is here in the elaboration phase where the project starts taking the shape. - In elaboration the following 2 basic things take place:

1. The analyzation of the problem domain is done.

2. Basic form is given to architecture. 

- The following are the outcomes of the elaboration phase:

1. A use case is obtained in which both the actors and use cases have been identified. This use – model consists of most of the developed use – case descriptions. It is required that this use – case model should be at least 80 percent complete. 

2. A description concerning the architecture of the software system in a development process. 

3. An architecture that is executable and realizes the use cases which have an architectural significance. 

4. A revised risk list.

5. A revised business case.

6. A plan for the overall development of the project. 

7. Prototypes which give a demonstration on the mitigation of the identification of the technical risks. 

8. An optional preliminary user manual.

- There is a milestone criteria called the life cycle architecture milestone which involves answering the following questions:

1. Stability of the architecture?

2. Stability of the vision of the product?

3. Have the major risk elements been addressed and resolved and has been indicated by the executable demonstration?

4. Has the sufficient detailing has been done for the construction phase plan and is it accurate?

5. Have all the stakeholders agreed for achieving the current vision using the current plan under the current architectural context?

6. Is the expenditure of planned resource vs. actual resource acceptable?

- It is important that the project should pass this milestone and if it doesn’t there are 2 possibilities:

1. It can either be redesigned or

2. It can be cancelled.

- However, when the project leaves this phase, the project is transitioned in to an operation that involves high – risk i.e., to say here the changes are quite detrimental as well difficult to be made. 

- The system architecture serves as the key domain analysis for the elaboration phase. 

- The basic thing here is addressing of the major technical risks threatening the project. 

- Another thing is to have a bare system which provides answers to all of the major technical questions. 

- Once all the questions have been answered by the end, the development team will know whether a working system can be successfully built or not. 

Inception 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

This article is dedicated entirely to the first phase of the unified process i.e., the inception phase. The major development takes place in the iterations of development which are carried out within each phase. All of the above four phases have their unique key objective as well as milestones.

The accomplishment of the objective is denoted by the milestone. An RUP hump chart is used for the visualization of all the four phases of the rational unified disciplines and phases over the time. 

Objective of Inception Phase

- The primary objective of the inception phase provide adequate scope to the software system or application as a basis on which the validation of the budgets and initial costing could be done.

- The inception phase involves the establishment of a business case which is inclusive of the following:

1. Business context
2. Success factors such as the market recognition, expected revenue and so on.
3. Financial forecast

- In order to complement the business case, the following things are generated:

1. A basic use case model
2. Project plan
3. Initial risk assessment
4. Project description which in turn includes the following:

    a)   Key features

    b)   Constraints and

    c)   The core project requirements

- Once the generation of the above mentioned sources is complete, the verification of the project begins against the following criteria:

1. Stake holder concurrence on the following:

  a)   Cost estimates

  b)   Schedule estimates and

  c)   Scope definition

2. Understanding of the requirements as per the evidence obtained by the fidelity of the use cases.
3. Credibility of the following:

  a)   Cost and schedule estimates

  b)   Priorities

  c)   Development process and

  d)   Risks involved

4. The depth and breadth that was developed for any architectural prototype.
5. Establishment of a base line using which the planned expenditures and actual expenditures can be compared.

- If for one or the other reason the project is unable to pass the milestone (commonly termed as the life cycle objective mile stone) then there are only two possibilities after redesigning the program (for meeting the criteria in a better way) as mentioned below:

1. It can be cancelled or
2. It can be repeated

- This phase is involved with launching the project. 

- A proper business case can be developed for the project. 

- It is by the end of the inception that the development team comes to whether to carry on with the project or not. 

- In inception phase, one can see a core idea being developed in to a vision for a product. 

- In this phase may reviews, discussions, etc. are carried out regarding the business case involved in the project. 

- The scope of the project is delimited in the inception phase and also the product feasibility is established. 

- This is perhaps the smallest of all the phases of a project and also according to its ideal nature it should be short. 

- If the duration of the inception phase is too long it indicates that there has been an excessive up – front specification (even though this goes against the spirit of the rational unified process.).