Myth 1 – Usability is expensive

Among the most common myths is that usability engineering (UE) is expensive, as many big software firms invest millions in setting up UE labs and they pay usability professionals highly. But what project managers and stakeholders fail to realize is that not every firm needs to invest so much. Usability methods are flexible and can be scaled up or down according to the situation. User tests can even be run in a spare conference room and existing staff can be taught how to conduct tests. Food for thought – on an average, best practices call for spending 10% of a design budget on usability.

Myth 2 – No scientific base for testing

This myth is based on the fact that only few users are utilized in a usability test. It’s assumed that based on few people’s observation, potential problems with the product can’t be uncovered. But a number of studies have shown that just 6 to 8 users typically uncover 80% of the problems with a given interface.

Myth 3 – Usability engineering delays the launch date

This is again a very common myth that surrounds usability. Usability need not be on a grand scale starting from entire user-centered design process followed to the letter and field studies. It can be as simple as paper prototyping and can allow you to go through several different design iterations in a few hours. One of the main benefits of letting user research drive design is that testers don’t have to spend time on features that users don’t need and can focus on resources to ship the product on time.

Myth 4 – No problems=No usability engineering

Though it may look as if there are no significant user-interaction problems reported for a product, it really may not be so. In many instances, users simply don’t report problems or at times problems are misinterpreted. Whatever the reason, unless the software firm does scientific research to gather user interaction data it’s not possible to know what the real problems are or if there are problems.

Myth 5 – We have already adopted usability engineering

There are many software firms who assume that verification tests, market trials, and a feedback form when a product releases are a part of usability testing. Just by interacting with a group of potential users and gathering user data doesn’t result in real user interaction testing. You need to get users early into the picture and ask them to use the software to complete certain tasks, without being told how to. The product is then rated based on how successful users are in completing those tasks. Issues are identified during these sessions and the product is improved based on the further recommendations.

The value of usability engineering and the role of the usability engineer are still not very well understood but it’s important to know that usability is an integral part of software quality and the correct usability methods are cheap, easy to implement, and won’t delay your project.

Read the entire digest contents

A framework can be regarded as a set of classes that embodies an abstract design for solutions to a family of related problems. It can also be thought of as a design and implementation for an application in a given domain. A good framework for software development may include programming languages, standardized libraries, and tools that form the part of any development process.

Managing code complexity and promoting code reuse are some of the main goals of a framework, besides reducing development time by making the code easy to create, maintainable and extensible by different teams. Application frameworks are available for a variety of technologies and environments and each software development framework has its own value.

What is important is how easily they allow software development and how long it takes developers new to the project to get up to speed with using the framework. Hence, generally speaking, frameworks that use industry standard patterns and underlying system framework code are safer bets. Some questions to ask when choosing a framework:

• Does the framework handle most things that are common to applications of the kind you wish to develop?
• Does the framework have a strong user community to back it?
• How much does the framework cost?
• How steep is the learning curve for the framework?

Often the underlying system frameworks are very similar-as most applications require a similar set of core functionality (e.g. validation, security/authorization/authentication, string manipulation, logging, etc). Since frameworks provide a lot of this out the box, they give developers a head start and prevent re-inventing the wheel.

Typically, frameworks provide more value for projects of a larger size. As a project gets bigger, the functionality of the software also increases, which in turn adds on to the complexity of the project. This can be managed and decreased by a software development framework.

While there is no dispute that frameworks have their advantages, there are some downsides to them as well. A single framework may not always suffice to the satisfaction of the development team. For example, they may find that they need three different frameworks – one for the UI, one for persistence (datastores) and one for data encryption. Each of these frameworks may have their own dependencies and to enable all the three of them to work together would require extra coding effort.

Hence, choosing a framework that integrates well with other development frameworks or better still, opting for some of the latest frameworks that are designed for components and services of any type to work together (and in which you can configure different application frameworks and access them in your development environment) may be the way to get the most out of a development framework.

Read the entire digest contents

For a software product to be usable, one needs to think about how and why people use a product. Understanding the user’s goals in the context of their environment and letting that determine the design is the first step to creating a usable product.

Usability engineering is an approach that puts the user, rather than the system, at the center of the process. Understanding the needs of users early is important to maintain the consistency of internal design of the software. Getting feedback through end-users’ interaction with the software at every stage and iterating based on observing users use the system is key to developing highly usable products, rather than relying on just designers’ experience.

Adoption of usability engineering throughout the development process gives users a chance to deliver feedback on the design before the product is released. Which means that even minor issues are rectified before it’s too late.

Experts believe that developers and designers should include certain essential usability characteristics for developing successful software. Interfaces are typically evaluated against a combination of these characteristics to determine how successful and satisfactory they are:

• Effectiveness – completeness and accuracy with which users achieve specified goals.
• Efficiency – speed (or accuracy) in which users can complete the task for which they use the product.
• Low Error Rate – ensures that users make fewer and easily rectifiable errors while using the system, and no catastrophic errors occur.
• Learnability – allows users to swiftly begin working with the system
  Satisfaction – makes the system a pleasure to use.
• Memorability – permits user to return to the system after a period of non-use without having to relearn everything.

Why should a development team adopt usability engineering?

• Increases productivity – allows users to focus on the tasks they want to complete with fewer distractions.
• Decreases training costs – usable systems require less training. In addition, usability testing can also identify the areas you need to focus on during training.
• Reduces development time and costs – missed requirements, workflow and design issues are identified earlier in the design meaning less cost to implement.
• Boosts sales and revenues – usability can help differentiate your software from those of your competitors. If two products are considerably equal in utility, the product with more usability will be regarded as superior.

Usability and user-centered design are iterative and typically proceeds in a cycle of hypothesis and evaluation. When followed correctly, design solutions build in richness and completeness and can provide a great user experience.

Read the entire digest contents

Hence having a product roadmap even when following an Agile approach is a must. A
product roadmap is a planned approach that helps with strategic project planning and communication of that plan with respect to product releases, functionality listing etc. But it should be formulated by first understanding the target users, the market, and the underlying technologies. Product roadmap forms an integral part of any product strategy and provide the framework for plan changes and the impact they would have on the product. It’s not just about the specific features or functionality of the product, but the long term product vision/goal of how far one would go with it.

The general perception today is that in Agile, unlike the waterfall model, it is difficult to chart out and manage an effective long –term product roadmap. However, Agile reflects the reality better because the planning is done only for the current items and the immediate iterations that may follow. And this necessarily avoids one from making a long-term product goal (say 6-10 months ahead), which may fail because priorities/requirements of the products often change. Moreover, making a long range roadmap has always been a real challenge in general.

In Agile, the roadmap and approximate dates are calculated based on the product backlog and the knowledge of the team velocity. Many a time over-commitment to the customers has been a major issue here. But product managers can certainly employ a centralized system that would ascertain development team velocity, all previously committed requests, and based on that, calculates the next available commit date for a task of importance. This always keeps one in check. A good agile product roadmap should invariably help one deliver the right products with the right features at the right time to the right customers.

Read the entire digest contents

As Agile teams manage their work differently, they typically need a different set of tools to support their agile approaches. Simple and adhoc tools like index cards and spreadsheets for requirements management and prioritization, wikis for collaborative documentation, commercial or opensource project management and bug tracking tools are usually sufficient for small, co-located teams. However, when teams and projects get larger and Agile methods need to be scaled up, integrated tools become useful.

New agile project and product management tools enable better coordination and collaboration between the various teams involved in the agile process (development, customer support, marketing, management, customers, etc) and also provide better reporting capabilities. Some of these tools even include requirements management, test and defect management and integration with development, test and build environments. They can bring about further improvement and acceleration of existing agile processes.

X-planner, RallyDev, VersionOne, TargetProcess, Yoxel and Mingle are some available Agile project management tools. .NET shops can also consider using MS team SCRUM plug-in for its agile project management functionalities. Some of these tools require you to spend time learning to use it initially while others allow easy integration with existing tools. Finding and using the tools that are well-integrated, facilitate meaningful interaction between your different teams and give more visibility can ultimately help you produce better software faster.

Read the entire digest contents

There are dozens of Agile methods, a detailed list of which can be found at Wikipedia and the Agile alliance. Interestingly, even these two lists are not identical and there is on-going debate on which processes can be considered agile, and almost everyone adapts and implements the same agile processes differently. After all, you cannot use the same agile approach with a team of six and a team of six hundred. The difference between building a data warehouse and an online ordering system on the other hand may be more subtle and harder for stakeholders to understand that it potentially requires different agile approaches.

So choosing the right agile method depends on the type and size of your product/ project, the criticality of the project, the location of the team members, and even the technology that is being used.

To get started with Agile, teams should equip themselves with knowledge about the different agile methodologies and the practices that form a part of these methodologies. Attending conferences and workshops where practical examples and best practices are shared is also encouraged.

What’s important next is to figure out which practices to adopt based on how it would address your requirement and what is the business value that can be derived from it. For example, if your goal is to reduce time-to-market, you can consider the agile practices of iterations, iteration backlogs and stand-up meetings. If increasing quality is the primary goal, automated developer tests, pair programming, user stories and continuous integration can work well for you.

There can be a lot of overlap between the various Agile processes and many successful practitioners adapt and adopt practices on an individual basis. Trying a pilot project can give teams a chance to understand and adapt to agile practices, make mistakes and learn from them. Also, instead of a big-bang approach to agile, a gradual transition (say from 9 to 6 to a 3 month release cycle) can cause less confusion and allow the teams involved to better adapt to agile.

Read the entire digest contents

A great analogy to this would be the biological evolution, where it begins with experimentation (mutation and recombination), exploration (survival of the fittest) and refinement (producing more of the survivors). Increasingly, product development follows this analogy, where it has switched from a process based on anticipation (define, design and build) to one based on adaptation (envision, explore and adapt).

In today’s digest, we will take this opportunity to recount one of the success stories where Aspire adopted iterative development. This was a music vending product that we developed for one of our customers and the salient features of the process followed were:

• Beyond the next iteration, the team didn’t know the features that would be included in the next development iterations
• The team had a clear product vision and a general idea about the features needed in the product
• There was active involvement from our customer’s product marketing organization
• There was an absolute time deadline and resource constraints, which the team was very aware of
• The team had a overall product platform architecture
• Within the above, team delivered tested features every two weeks and then adapted their plans to the reality of actual product testing

The team’s process was one of evolution and adaptation, not planning and optimization. In the end, product was delivered on time, met high quality standards, and has been a success in the marketplace. The team didn’t start with anticipated architectures and plans but with a vision followed shortly by the first iteration of the product. The rest evolved as the team adapted to the reality of the market and the technology.

Read the entire digest contents

However, many software organizations consider automation as a vital step in establishing a mature QA program and it certainly has a lot of value if it can be effectively leveraged. If you are seriously looking at automation though, there are few things that you should start with. One of the most important things is to understand the initial costs involved in test automation.

Automated testing involves higher upfront costs and should be looked at as a long-term investment where the pay-offs come anywhere between 2-4 years down the road. One has to also keep in mind that there are various intangible benefits associated with automation. Performing a return on investment (ROI) for your planned automation can however help you understand right at the beginning the autual returns that you will get from your investments and you can weigh those against the benefits you will gain from automation.

An ROI analysis will not only help you determine the various elements associated in calculating the ROI and the approximate cost and benefit involved but it can also help you decide on the types of automation you want, the areas that you can potentially automate, the tools and the skill-levels of the testing resources that will be required.

Therefore, determining the ROI for your test automation should be a necessary part of your planning process. It will give you better clarity and direction on how you proceed with your actual automation efforts and prepare you upfront on the costs and true benefits involved.

Read the entire digest contents

While SaaS companies that use open source technologies, or a combination of proprietary and open source software, are quite common, there are very few SaaS companies who adopt an Open source business model.

Open source communities typically form around projects where there is a development problem/opportunity, so unless it’s something (the area of work of the SaaS provider) more than just a mundane business problem, SaaS providers may have a hard time gaining a volume to form a community of interested developers/users. It is also expensive for SaaS providers to adopt a pure open-source model, like say Wikipedia, as the costs of hosting the software on a continuous basis are not negligible.

A hybrid model with open source and commercial versions, which SugarCRM has adopted, makes better business sense as the commercial editions of the product allow revenue inflow to the company and in turn supports the open source user community. Contributions from the community, in turn, enhances the value of the software.

However, Sugar’s model also cannot really be called Open source SaaS, as only the commercial editions (developed by Sugar’s engineers) are offered as a hosted or on-premise solution and the open source edition (including extensions developed by the community) is available on Sourceforge.org or SugarExchange.com (the add-on marketplace where extensions are sold).

Other areas that need to be thought about and addressed from the provider’s end, when offering an open source SaaS, are the support, service delivery and management aspects of the software. But with SaaS gaining ever-increasing popularity, and being driven by user adoption, there’s a high possibility that there will be more companies who find Open source SaaS a new profitable business model.

Read the entire digest contents

It’s certainly interesting how they feed off each other’s strengths and also create weaknesses in each other. Many SaaS providers, for example, use open source software (OSS) for its lower costs thereby driving open source growth. Open source vendors, on the other hand benefit from cloud computing and using web infrastructure services on a pay-per-use basis.

Open source licensing can create issues for SaaS vendors if it is not fully understood or complied with. A number of SaaS vendors may be incorporating open source code into traditionally licensed models unknowingly and without being aware of the violation until challenged. There is also repeated criticism regarding the security of open source software, which SaaS vendors need to take into account.

From the cloud computing end, although it is improving by leaps and bounds, reliability is something which SaaS providers and open source vendors have to worry about. Amazon’s S3 online storage services suffered two notable outages this year, which disrupted websites using the infrastructure service.

Those who believe open source or SaaS will win out over the other – due to the community contributions and support for open source software, or because open source software licenses will become irrelevant in the networked world – are wrong, because both of them can and will co-exist. What’s going to become more successful in the future is a SaaS revenue generating product that uses open source and is able to build a community as loyal as OSS communities which act as its sales force and becomes part of the development and PR team as well.

Read the entire digest contents