Tuesday, January 5, 2010

Reusability and Usability

Reusability is no longer an uncommon buzzword in Software Engineering.

Several months ago one of my team members had identified a reusable component from his code and wanted to release it to his colleagues. When he approached me with his idea, I asked him ’Have you used this component in different contexts and found it reusable?'. He responded with a firm 'Yes'. I ticked the first checklist item to qualify his component as 'reusable'. There started his uphill task of publishing it and getting acceptance from our local community of Software Engineers. He stretched himself to make it happen. That was indeed an uphill task!

Last week I was in a meeting with my engineers where all of us delved into a discussion on reusable components. Our conversation emerged with a flavor of belief that the reuse of concepts, designs and templates are easy to implement and it is very hard to develop and release reusable components that other developers can use to avoid reinventing the wheel. Our conversation openly claimed that developers do not like to use a component developed by others and would rather develop their own.

Eventually, after several minutes of debate we settled together with the fact that developers do utilize reusable components. Reusability does exist in many forms including component reuse. Typical examples of reusable components are Apache's FOP or Log4j in J2EE world – to name a few.

This makes it evident that if we want our components to be reused, we have to look into the usability aspects while designing, coding, testing, maintaining and releasing reusable components. Usability plays a critical role in creating usable systems. To create usable systems, we need to consider human abilities and limitations, learn about the needs of end users and involve them while designing such components.

How do we do this when we create reusable components? The answer, though not very simple, is two-fold. First the creator needs to understand the end-users, their needs and think like the end-users throughout the design process. Next, the creator needs to test the reusability of any component among peer groups or projects and enhance it so that it becomes reusable among a wide spectrum of users. For frequent reuse the creator may have to provide the following artifacts in addition to the source code.

1. Feature list
2. Tips/Instructions on usage
3. Sample code on how to plug-n-play
4. Contact info (Email/Phone) for help

Interestingly, usability evolves with the evolution of user experience on what is available and user expectation. The more our users understand and relate well to the systems they use, the better and faster they are in liking or disliking the systems we provide. Progressively, end users become more and more aware and demanding too. Unfortunately, the more and more we, the software professionals get detached from users and usability, we become responsible for designing and delivering systems that fail to meet usability expectations.

Clearly, it is not enough if we understand just the business requirements and technology to deliver software. The more we understand our users as well as the importance of usability, the greater our results will be in delivering usable systems. To conclude, if ‘Know Thyself’ is the mantra for happy living, ‘Know Your Users’ is the mantra for delivering successful systems.

Software Engineers do spot reusable components in the code they produce. Couple of days ago a young engineer in my team identified a reusable component from his code and wanted to release it to his colleagues. He approached me with his idea.

I asked ’Have you used this component in different contexts and found it reusable?'

He responded with a firm 'Yes' and agreed to take up the uphill task! He needs to make it usable. Am sure he will succeed.

Naturally, usable reusable components become reusable, live long and evolve!

Related Article: 

      Reusability, Usability and Flexibility


Monday, January 4, 2010

Requirements Engineering = Elicitation + Analysis and Negotiation + Specification or Documentation + Validation !

Yes! Requirements Engineering is composed of four key activities – Requirements Elicitation, Requirements Analysis and Negotiation, Requirements Specification or Documentation and Requirements Validation.

Requirement Elicitation is to discover system requirements through consultation with stakeholders. Some of the sources of this discovery could be system documents, domain knowledge and market studies. Requirement Analysis and Negotiation is to analyze requirements in details and negotiate them with stakeholders on which requirements are to be considered. Requirement Specification or Documentation is to document agreed requirements at a certain level of detail. Requirement Validation is to review or validate requirements for clarity, consistency and completeness.

This is an attempt to address a set of key areas where things can go wrong during Requirements Engineering.

Who Plays the Role? Sometimes, project teams go by the assumption that every skilled programmer is also proficient at interviewing customers and writing requirements specifications. This is a risky assumption. This may not yield good results in all cases.

Training alone would not suffice: Requirement Analysts are grown – not just trained! A good training in various areas related to requirement analysis is mandatory but not sufficient. This includes training sessions on business, software engineering as well as soft skills. A requirement analyst needs to be aware of the business domain, technology aspects as well as user expectation management. Soft skills such as effective listening, negotiating and facilitating, help analysts uncover users’ unspoken desires. Thus, training alone would not suffice. Adequate mentoring and coaching is required to groom Requirement Analysts. Requirement Analysts grow to higher levels based on their work experience in performing their role effectively – a good training is just a starting point.

Focus on Soft Skills: Most of the times, due to factors such as information over flow, analysts focus more on business requirements itself and lose focus on their soft skills. Soft skills such as listening, interviewing and questioning, analytical reasoning, facilitation, observation, writing, organizing, modeling, interpersonal intelligence, collaboration and creativity are to be consistently honed to conduct requirement analysis effectively.

Planning: Requirement Analysis needs thorough planning. Typical deliverables need to include traceable requirements, open issues, open queries - in addition to other artifacts. Formal reviews need to be planned to ensure quality before design. Often analysts rely on a series of meetings to perform Requirement Analysis. This is not sufficient. Various techniques such as user interviews, demonstrations, walk-through of live data and processes, etc., are to be considered while planning.

Inadequate Elicitation: Inadequate or elicitation will result in poor specification. Requirement elicitation consists of fact-finding, information gathering and integration. Identification of various sources of requirements (such as end users, interfacing systems), gathering requirements and integrating them is key to the success of Requirement Analysis. Inadequate Elicitation could be the result of factors such as ineffective meetings, not asking relevant or revealing questions, not scooping, not modeling, not prioritizing etc. Some of such key factors have been explained below.

Ineffective Meetings: Effective meetings ensure progress. Requirement Analyst needs to plan effective meetings with a manageable list in the agenda and ensure that all action items are followed-up and closed.

Not Asking! Many experts provide the tip – ‘Communicate, Communicate & Communicate’ to ensure project success. Requirement Analysis (as well as any other phase in a project) can go wrong when the team members (more specifically the Requirement Analyst) do not ask questions. Thus the tip for successful analysis is ‘Ask, Ask, Ask’ – specifically, ask revealing and relevant questions. Asking good questions to explore and understand detailed requirements provide the base for thorough testing. Both the type and timing of questions are very important. Questions related to requirement originating during Integration Testing are not uncommon in projects. It is good to identify, ask and resolve queries during early stages of the project. The book ‘Exploring Requirements: Quality Before Design’, Dorset House, 1989 by Donald Gause and Gerald Weinberg is worth reading to understand this aspect.

What, How and When? Sounds simple to follow – but this is forgotten at times. Analysts capture ‘What is required’ – but they forget ‘How’ and ‘When’! Here is an example. The business users want an email notification facility that sends an email notification whenever a user is registered into the system. The analyst captures the ‘What’ factor which goes in to the FS document ‘A email has to be sent whenever a user is registered into the system’. During acceptance testing, the user elaborates on the ‘How’ factor and says - ‘…the system should detect the delivery status of such emails and resend the mail until it is delivered successfully. The email message should contain few dynamic links as well as a logo. The users should have an option of not receiving such emails’ and stresses that he wanted the email functionality to work this way in the initial delivery itself. This is reported as a critical issue and the project team works late nights to provide this functionality. In this example, initially the analyst should have given adequate stress on the ‘How’ and ‘When’ factors that help him focus on elaborating the requirement. This happens when the analysts focus on ‘elicitation’.

Not Modeling! Modeling is done across industries and disciplines. Requirements need to be modeled using appropriate techniques and tools. A textual description may not be adequate in all instances. Use Modeling. Use examples, illustrations and substantiate them with good data.

What is the Scope? Things can definitely go wrong when the analyst gathers exhaustive requirements but fails to qualify if all of them fall under the scope of the project. This could lead to misunderstanding, overruns and poor quality. Requirement Management: Requirement Analysis as a project phase need to end with a set of baselined requirements. Still, Requirement Management activity progresses until acceptance of the end product. Loosing focus on Requirement Management may lead to conflicts and poor quality.

Communication Gap: Requirement Analyst acts as a bridge between the end-users and the project team. The objective is to transform user requirements in to system requirement specifications and ensure good quality of traceable requirements so that end-users get what they wanted. Any communication gap in this area could result in customer dissatisfaction.

Not Prioritizing! Not prioritizing requirements is a potential risk, as the project team has no means to handle design, implementation and testing issues. Prioritization cannot be overruled in any project.

Missing out Non-Functional Requirements: A project cannot succeed with high-quality functional requirements alone. Non-functional requirements play crucial role in planning design, coding and testing activities. Non-functional requirements fall in to categories such as Reliability, Scalability, Installability, Useability, Availability, Performance, etc.

Missing Assumptions, Dependencies and Constraints: Identification, elicitation and documentation of assumptions, dependencies and constraints is a vital part of Requirement Analysis. It is a good practice to understand the list of assumptions, dependencies and constraints specified in project proposal or statement of work & plan meetings to discuss all assumptions, dependencies and constraints pertaining to project requirements. Missing assumptions, dependencies and constraints would guarantee chaos and customer dissatisfaction.

Inadequate Validation or Reviews: Validation of requirements is the responsibility of the Requirement Analyst. The relatedness and conflicting nature of requirements are to be identified and resolved during initial stages. All artifacts of Requirement Analysis are to be reviewed to identify and resolve defects.

Not Measuring the Quality of Requirements: Quality of requirements affect the quality of subsequent phases. Quality of requirements can be measured using organizational metrication process in organizations that follow standards such as CMM.

Not documenting “What is not in scope”: It is a good practice to document the list of things that are out of scope. During meetings with the stakeholders or end users, a set of features may be qualified for subsequent phases of the project. If not documented, such features may creep in during the time of project execution or acceptance testing. It is good to document all such features and get a sign-off to mitigate requirements creep.

Not focusing on ‘Technical Requirements’: Technical requirements are vital for the acceptance of the system. Such requirements could be related to areas such as compatibility, coding standards, error handling and propagating errors with user-friendly messages, audit trial, data interfaces, design of multi-currency support, design of multi-lingual support and UI design. Requirements Engineering needs to consider technical requirements with respect to what the stakeholder want on technical perspective. Design Phase would address these requirements with respect to how they would be implemented. Thus, the identification and documentation of technical requirements should not be forgotten or pushed to Design Phase.

Needless to say, practitioners need to focus on these areas to mitigate risks related to Requirements Engineering. Any thoughts?

Other Posts on Requirements Engineering:

Friday, January 1, 2010

Customer Value Management and IT Outsourcing

Welcome 2010! This decade is going to see a great shift from value-neutral to value-based IT outsourcing trends…

The last two decades encompassed huge opportunities to software service providers. IT evolution and cost-effective onsite-offshore operations offered stability and growth in the areas of Software Maintenance and Support, and Sustenance Engineering. Service providers played in a value-neutral way looking at the opportunities alone to reap benefits. Over the years the competition has grown to a global level. Under these circumstances, Customer Satisfaction Surveys failed to assess the relative performance in a competitive world and hence to understand customer values. Customer Value Management (CVM) is an emerging art and science – it is a way of thinking coupled with a set of techniques and methods that anyone in business can use to decide where to expend time, energy and money to create value for customers. Mature disciplines such as consumer electronics, telecommunication and automobiles focus immensely on Customer Value Management to delight and retain customers.

Software Engineering is a maturing discipline. The focus on CVM in Software Engineering is too low compared to other mature disciplines. Offshore Software Service Providers realized the demerits of ‘one-size-fits-all’ approach during the post-Y2K era and took the first step by means of defined organizational structures or business units based on verticals and horizontals to provide focus on domain-specific as well as technology-specific customers. Strategic initiatives of Software Service Providers during the mid-90s focused on the adoption of process maturity models (such a, ISO and/or CMM) and enrichment of skills with professional certifications (such as PMP). These initiatives focused on standardizing organizational software processes and strengthening the delivery arms. However, for more than a decade, the contribution of such initiatives to Customer Satisfaction as well as the overall success of the Offshore Project Management could not provide consistent results across projects.

Software service providers go with their Unique Selling Points (USP) and Value Propositions to win new business relationships. Seldom do they focus on answering the following questions.

1) Do we choose the right set of values?
2) Do we manage our business processes to deliver the values we promised?
3) Do we communicate the values we offered to the customer and understand customer's perception?

Customer Value Management is all about this focus. Do software projects deliver software as well as customer values? The answer is not a definite 'Yes'. In many cases unfortunately, the answer is a definite 'No'. This is due to the mindset of businesses that deliver software - the mindset that treats software as a technical commodity executable on a piece of hardware to satisfy user requirements. As the competition gets truly 'Global' this mindset will transform towards value-orientation. Delivery Management community will work towards managing customer values effectively.

Obviously, cost effectiveness as a singular value proposition will lose gravity. Cost pressures will continue to exist. Increasing number of service providers will move their operations to cost effective geographies. Organizational focus on cost effectiveness and cost cutting measures will become ubiquitous. Worldwide blended rates will emerge.

Surveys show that when customers slip from ‘Highly Satisfied’ to ‘Satisfied’ (the ‘Slippery Slope’ syndrome) they do limit existing relationships to low-end services with the current vendor and seek new providers for value-added high-end services. For example, in banking industry customers who are just ‘Satisfied’ with the current bankers keep their relationship to maintain a savings bank account and open new accounts with other providers for high-end services. This is a classic scenario that could happen and restrict players from growing up in the value-chain in our industry. Unless the current service offerings are value-centric, existing customers will never ‘Pull’ a provider to offer high-end services or succumb to any ‘Push’ to buy additional services. In fact, service providers do go with ‘Value Propositions’ to customers and sell their services. This was the first step taken by service providers towards value-orientation during the current decade –‘Going with Value Propositions’. This partially answers the first question – ‘Do we choose the right set of values?’ In reality, the industry has a long way to go in choosing the right set of values, in managing business processes to deliver such values, and finally, in communicating the values delivered to understand customers’ perception. CVM is the way to go in order to evolve a value-based delivery model and hence to stay ahead of competition.

Incremental & Evolutionary Development Methodologies will become a dominant factor of delivery models. Software Application Development and Maintenance has undergone a major paradigm shift from traditional waterfall life cycle to iterative and incremental life cycle. Incremental and Evolutionary Development Methodologies (for example Agile Methodologies and Lean Development) have proved to be successful. The trend will continue and there will be many adopters of such methodologies to ensure early deliveries, high quality and effective risk management. The need of the hour in software development is to plan for early and continuous delivery of high-quality software along with the flexibility to respond to changes and provide better visibility and predictability to the customer. Time-to-market and budget constraints put tremendous pressure on Global Delivery Models in meeting this need.

Foundation of critical resource pools at customer-centric locations will become a necessity to attain competitive advantage. Customer-centric locations will provide competitive advantage to position critical resources to offer high-end service offerings such as Consulting Services and Package Implementation. Businesses will strive to hire resources in order to overcome cultural and linguistic barriers. There are two dimensions to this foundation – a) Establishing critical operations close to customers for value addition and b) Exploring worldwide locations for business operations, talented resources and operational efficiency. With cost effectiveness being the basic ingredient the ability to compete globally will make these two dimensions the key strategic options to establish effective delivery models. Service provides operating from a base country with sales forces across geographies will have to provide value-addition to its existing as well as potential customers by forming ‘expert teams’ consisting of domain as well as technical expertise to increase their ability to respond fast to market situations. This will become a necessity to be a true ‘Global’ player in the industry.

The significance of relationship will surpass the power of branding when it comes to business continuity with existing customers. This will limit the power of branding in business continuity and entrust enriched customer relationship as the strategy to retain and grow businesses. Branding will prove to be advantageous in entering new accounts and attracting new talents. When it comes to ‘Retention & Continuity’, ‘Relationship’ will play a key role in global competition. Customers will create and sustain business relationships purely based on value offerings. Branding and market dominance will never bias a relationship or business continuity in the competitive world. Rather value offerings and business relationships will add power to branding.

Services offerings will get wrapped around innovative value-based alternatives that provide for Flexibility, Risk Mitigation, Business Continuity, Partnership Opportunities, Technology Leadership and Relationship Commitment. The last decade was predominantly full of opportunity-based value-neutral selling. Delivery Models were SLA driven with contractual bindings. Though this trend will continue to exist, the next generation will see different kinds of value-based alternatives.

Focus on Employee Skill Building will mature further to ‘Value-Based Competency Building’ (VBCB). Global competition will transform businesses to strategize on Value-Based Competency Building. ‘Value-Based Competency Building’ will address contemporary challenges in building competencies specific to Verticals or Horizontals. This will enable businesses to establish the basic foundation for effective Customer Value Management. ‘Value-Based Competency Building’ will become a critical aspect of Human Resources Development and Planning. Global players will evolve VBCB to establish a strong foundation for their delivery models to improve quality of deliverables and to reduce project costs.

Partnered Delivery Model will emerge as a new trend. To build a successful Value-Based Delivery Model’ the new generation will see the trend of ‘Partnered Delivery Model’ where Service Providers will establish partnerships to enable value-addition to their system. Partnerships will emerge in the areas of Resourcing &Competency Building, Employee Care, V&V Services, Package Implementation and Technical Writing. Matured industries such as consumer electronics and airlines operate with partners who supply both products and services. In these cases the delivery system operates by consuming products and services from partners to optimize internal value creation and hence to exceed customer expectations.

Value-Based Software Engineering (VBSE) originated by Berry Boehm will become a catalyst in IT services industry and Value-Based Process Frameworks (VBPF) may evolve as well – both of these will become the building blocks delivery models. VBSE is currently maturing among the academia and research communities. It is going to reach practitioners in few years from now. It focuses on both monetary and non-monetary values and explores ways to infuse value orientation in each and every activity of Software Engineering starting from Requirement Analysis to Verification & Validation. The VBSE agenda includes Requirement Engineering, Architecting, Design and Development, Verification & Validation, Planning and Control, Risk Management, Quality Management, People Management, and Principles and Practices.

Adoption of Quality Processes will upgrade to Value-Based Process Optimization and Process Tailoring (VBPO &PT). Quality Processes and Process Model will upgrade to include value definition, measurement, corrective action and optimization. Process Areas will include key value elements to practitioners and Process Tailoring will help them the right set of key elements are add new ones to ensure successful deliveries. This is a potential area of research and practice in the industry.

An organizational level CVM initiative will be the first step to create awareness and develop CVM skills in the organizations. Implementation of CVM will require an experimental approach on a selected set of projects of business units and customers. A customer’s view on the market depends on various factors including the maturity of the market, value-offerings, and supply. This is true for a vast majority of the customers of any industry. Cost effectiveness alone cannot survive businesses that are stronger in value-neutral organizational or process maturity frameworks. Organizational Value Orientation and CVM in IT Services Industry are in their infancy. As of now, less than a handful of organizations have started moving in this direction. The next decade is going to see a great shift from value-neutral to value-based IT outsourcing trends.

  1. Bates Collin, Forget the value of the customer to you and think about your value to the customer, Customer Management, September/October 2003
  2. Boehm Berry, Value-Based Software Engineering: Overview and Agenda, University Of Southern California, Computer Science Department, February 2005
  3. Boehm Berry, Turner Richard, Observations on Balancing Discipline and Agility
  4. Favaro John, When the Pursuit of Quality Destroys Value, IEEE Software, May 1996
  5. Gale T. Bradley, Introduction to CVA – Trends in Customer Satisfaction, Loyalty and Value, Customer Value Inc.
  6. Highsmith Jim, Cockburn Alistair, Agile Software Development: The Business of Innovation, September 2001
  7. Minseong Kim, Sooyong Park, Value-Based Requirement Analysis of Product Families: A Goal and Scenario Oriented Approach, Department of Computer Science and Engineering, Sogang University
  8. Poppendieck Mary, Principles of Lean Thinking
  9. Shirhattikar Gautam, Future Winners and Losers in Global Outsourcing, CHAZEN Web Journal of International Business, Winter 2005
  10. Terdiman Rita, New Dynamics in the Application Outsourcing Marketplace, Gartner Inc Article Top View, 30 January 2003