Encouraging a creative team member to assist in the UI designer duties

There are a certain number of resources that any particular software team can have assigned to them. Based on the amount of work that is under consideration of the team, the needs of the team are estimated in terms of the developers and testers vs. the amount of work done. If there is a lot of work and there are not enough developers or testers needed for this quantity of work, then the team has only 3 choices:
- Ask for and get more testers and/or developers, and take on this quantity of work
- Ask for and not get more testers and/or developers, and decline work beyond the amount that can be done with the team that you have
- The third one is the most problematic. The team does not get additional testers or developers, but there is a lot of pressure built to take on the additional work. One would not like to think of such a scenario, but it does happen, and eventually the team either gives up the additional work or takes on a lot of stress, and maybe even has a reduced quality in terms of their deliverable.
However, twice in the past 4 years, we have come across a situation which is not easily solvable, and for which we did not get any additional support. What was this case ? This was the case where the release we were doing had a number of features that required the support of a workflow designer / UI designer. In a typical release, we have a certain number of such resources assigned to the team, based on an expectation that the amount of workflow and UI required will be of a certain % (let us assume that 60% of the work being done by the team needs the support of the workflow / UI team - the reason for it being 60% is that the remaining 40% is where the team does some kind of tweaking / modification which does not require any workflow changes or UI changes).
However, this gets badly affected when there was a release where the estimation of the amount of work where the workflow / UI designer is needed was around 80%, and it was pretty clear that the team that was doing the workflow / UI design was not staffed for this extra work, and even if we had got allocation of budget for the extra work (which was not 100% certain by itself), it takes months to hire somebody with this skill set. Hence, there was no getting around the fact that we had a puzzle on our hands - we had estimated work for which we had enough developers and testers, we did not have enough designers. What to do ?
When we were discussing with the senior members of the team, we came across an interesting suggestion. Over the past, the team had noted that there were some members of the team who were more easily able to comprehend the designs put out by the designer team and understood the way that they were doing their reasoning. Given that we really did not have a choice, we went ahead with the open offer to team members who wanted to give open flow to their creative juices, and prepare the design, with rounds of review by the designer team (we found that this amount of effort could be accommodated), and then present to this team. One of the main persons we expected did not volunteer, but another person who was also seen a prospect volunteered, and we pulled her off her current responsibilities and got her temporarily assigned to the designer team. Over the next few weeks, we did a close watch on this arrangement, and while it was not as good as the design done by the designer team, our Product Manager was satisfied with this, and so was the design team, and we went with the design that she produced and the team accepted. Now, this was not a long term arrangement, but in the scenario described above, it seemed to work. 

What is meant by Business Process Reengineering?

Business process reengineering or BPR is a very important concept when it comes to achieving the business goals centred on the development of a software product. This article is all about the same concept. Let us define the business process re-engineering process formally.

"The process that involves analyzing and designing of the processes and workflows within the organization which is developing a particular software product is called business process re-engineering". 

Business process re- engineering has got many other names like:

1. Business process redesigning
2. Business transformation
3. Business process change management

What is a business process?

- A business process can be thought of as an aggregation of tasks that are logically related to each other and are meant to achieve a pre-defined business outcome. 

- Re-engineering eventually led to many changes in the management processes for the good. - The best example that can be given is of the cross functional team! 

- The concept of cross functionality came in to existences because of the need for re- engineering of the functional tasks which are separately developed in to the processes that are completely cross functional. 

- The concept of business process re engineering is gaining popularity worldwide since there are so many management information systems developments which aim at achieving a wide integration of a large number of business functions.

- Few of those management information systems are:

1. Supply chain management
2. Enterprise resource planning
3. Knowledge management systems
4. Human resource management systems
5. Groupware systems
6. Collaborative systems
7. Customer relationship management and so on.

- This technique emerged in the private sector to help the organizations fundamentally, so that they can improve up on their customer service to a large extent. 

- This technique also helped in reducing the development cost and gain the world class competitive edge.

Key Aspects of Re-engineering Process

The following are the two very important key aspects of the re- engineering process:

1. Deployment of the sophisticated information systems and
2. Continual development.

Details about Business Process Re-engineering

- The leading organizations of the world which are known to support the innovative business processes are used to deploy this technique instead of refining the current methodologies of doing work. 

- Business process re-engineering involves rethinking and then radically redesigning the already existing processes and resources of the organization.

- The business process re- engineering cannot be called as a mere business improvisation technique rather it is a technique using which the whole way in which the work is done can be redesigned for the better. 

- A high level assessment of the mission of the organization, its customer needs and strategic goals marks the beginning of the business process re-engineering. 

- The business process redesigning invokes the question, “does the (aspect) needs to be redefined?” 

- During the implementation of the business process re- engineering technique, an organization may feel that till now it has been working up on the assumptions that are questionable. 

- On implementing this technique, they are forced to think what exactly they should be doing. - The primary focus of the business process re- engineering is on the business processes of the organizations that govern the usage of the resources to develop software products and services to cater the needs of the customers. 

- Business process re- engineering works on the philosophy that “a business process can be broken down in to several short and simple processes which then can be individually measured, modeled, and improved up on”.   

- Apart from this, all the processes can also redesigned altogether.

- With business process re- engineering, the whole business process is optimized in such a way that the organization and the customers reap only benefits. 

WebApp Interface Design - Interface Control Mechanisms and Interface Design Workflow

INTERFACE CONTROL MECHANISM
The objectives of Web application interface are:
- establishing a consistent window into content and functionality provided by interface.
- guiding the users through interactions with web application.
- organizing the content and navigation options.

A metaphor is drawn that guides the user interaction and enables the user to gain understanding of the interface. Some interaction mechanisms available to web application designers are
- navigation menus that list key content and or functionality.
- graphic icons that enable user to select some property or specify a design.
- graphic images that implements a link to content object or the functionality of web application.

INTERFACE DESIGN WORKFLOW
It includes the following tasks:
- The information contained in analysis model is reviewed and refined.
- A rough sketch of web application interface layout is developed.
- The user objectives are mapped to specific interface actions.
- Set of user tasks associated with each action are defined.
- For each interface action, storyboard screen images are developed.
- Input from aesthetic design can be used to refine interface layout.
- User interface objects required to implement interface are identified.
- A procedural representation of user's interaction is developed.
- A behavioral representation is developed.
- Interface layout is described.
- Interface design model is refined and reviewed.

The Team Software Process Team working Process

One should make ensure that the team members of team software process team follow the TSP plan.It includes:
- Leading the Team
- Process Discipline
- Issue Tracking
The team leader is responsible for leading and guiding the team which includes the day-to-day direction of the work, protecting team resources, resolving team issues, conducting team meetings, and reporting on the work.
During process discipline, the team leader ensures that the engineers do the job the way they had planned to do it. In monitoring process discipline, the team leader should check that every team member records his or her process data, reports on weekly status, and produces quality products.
Another responsibility is issue tracking which ensures that all of the issues that the team.

- Communication
- Management Reporting
Communication is a key part of maintaining the team’s energy and drive and facilitating communication is a key part of the team leader’s responsibilities. The team leader is responsible for maintaining open and effective team communication.
Management should be informed about team status and performance on a regular basis.

- Maintaining the Plan
- Estimating Project Completion
Maintaining the plan is very important once the teams have completed the project launch and started on the job, the plan guides the work. It also provides a benchmark for measuring progress as well as means to identify problems that might threaten the project schedule.
TSP teams track progress against the plan every week using a method called earned value. With earned value, each task is assigned a value based on the percentage of
the total project estimate that is required for that task.

- Re-balancing Team Workload
- Relaunching the Project
Unbalanced workload can cause a team to be inefficient. Causes include normal fluctuation in engineering performance. Also, the most experienced engineers are generally involved in much more of the work than the team members with less experience.
Whenever teams find that the plan no longer helps them to do their jobs, they should relaunch their projects. Teams should also be relaunched when there are major changes in the work to be done or in team membership.

- TSP Quality Management
TSP shows how to manage quality, teams must establish quality measures, set quality goals, establish plans to meet these goals, measure progress against the plans, and take remedial action when the goals are not met.

What are some of the formal approaches used for exploratory testing?

Some of the formal approaches used for exploratory testing are:

- Identify the domain
The exploratory testing can be performed by identifying the application domain. If the tester has good knowledge of domain, the it would be easier to test the system without having any test cases. If the tester were well aware of the domain, it would help analyzing the system faster and better. His knowledge would help in identifying the various workflows that usually exist in the domain. He would also be able to decide what are the different scenarios and which are most critical for that system. Hence, he can focus his testing depending on the scenarios required. If a QA lead is trying to assign the tester to a task, it is advisable that the tester identifies the person who has the domain knowledge of that testing for exploratory testing.

- Identify the purpose
Another approach to exploratory testing is by identifying the purpose of the system i.e. What is that system used for. Thus, by identifying the primary and secondary functions for the system, testing can be done where more focus and effort can be given to primary functions as as compared to secondary functions.

- Identify the workflows
Identifying the workflows for testing any system without any scripted test cases can be considered as one of the best approaches used. The workflows are nothing but a visual representation of the scenarios as the system would behave for any given input. The workflows can be simple flow charts or data flow diagrams or something like state diagrams, use cases, models etc. The workflows will also help to identify the scope for that scenario. The workflows would help the tester to keep track of the scenarios for testing. It is suggested that the tester navigates through the application before he starts exploring. It helps the tester in identifying the various possible workflows and issues any found which he is comfortable can be discussed with the concerned team.

DFD: data flow diagram

Not everybody who has worked in the software development cycle has heard of what a Data Flow Diagram is, or what it does. So, for example, somebody who makes applications such as Windows or Office or PhotoShop may not need to know what a DFD is. However, for a team that is designing an application for a bank or for a shopping application that involves a lot of data, it is essential to map the data flow. Hence, a Data Flow Diagram (DFD) is an essential component for the design of a large number of software applications, and if you don't do the DFD well, then the system may not end up having been designed well, and may end up being less efficient than it was supposed to be.
So, what is a DFD ? A brief definition and description:
DFDs were first used in the software engineering field as a notation for studying systems design issues. A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. DFDs show the flow of data from external entities into the system, showed how the data moved from one process to another, as well as its logical storage. A data-flow diagram can also be used for the visualization of data processing (structured design).
Data flow diagrams can be used to provide a clear representation of any business function. The technique starts with an overall picture of the business and continues by analyzing each of the functional areas of interest. This analysis can be carried out to precisely the level of detail required, leading to a data flow diagram that is strong in illustrating the relationship of processes, data stores and external entities in business information system.
Complicated information systems have lots of data flows which can be presented in a form of a data flow diagram. Without such data flow diagram you just can't visualize all data flows and won't be able to analyze and improve the whole system. Data flow diagrams represent data flows in a clear visual way as arrows between blocks which represent parts and processes of the system. Identifying the existing business processes, using a technique like data flow diagrams, is an essential precursor to business process re-engineering, migration to new technology, or refinement of an existing business process.
Sounds complicated, so the next few posts will detail the steps to making a data flow diagram, what are the benefits for this diagram, and some tools that will help in generating a data flow diagram.