Software Engineering

Cloud Computing: Will Standards Ensure Compliance?

2012-02-06T07:53:00.000-08:00

In 1979, Relational Software, Inc. which became Oracle Corporation at a later stage introduced the first commercially available implementation of SQL. Also, several other vendors such as Ingres (based on Ingres project led by Michael Stonebraker and Eugene Wong at University of California Berkley during late 70s) and Sybase introduced database products with SQL. The American National Standards Institute (ANSI) announced SQL standard (also known as ANSI-SQL) in 1986. The International Standards Organization (ISO) announced another standard (known as ISO-SQL) in 1987.

However, database vendors could not follow any of these standards completely due to various reasons. A prominent reason was that the standards were seemingly ‘guidelines’ with lack of clarity and room for multiple interpretations. Consequently, the portability of applications or data migration from one database product to the other remained a challenge. After several years of product evolution, some of the database vendors announced compliance with SQL standards. However, the portability or migration challenges have not been addressed yet.

The problem with cloud-computing standardization as elaborated by Sixto Ortiz Jr. in his article published in IEEE Computer, July 2011 is significant. Obviously, the lack of standards means limited adoption. This is because of the limitations in comparing and evaluating offerings and hence there is a potential danger of vendor lock-in.

The good news is that last month(Jan 2012) the Open Group has published the first technical standard for the Cloud. This is called SOCCI (Service Oriented Cloud Computing Infrastructure framework) and it outlines the concepts and architectural building blocks necessary to support SOA and Cloud initiatives.

We are going to see new standards related to Cloud Computing over the next five years. Will standards ensure compliance? We need to wait and see!

Useful Links:

NIST (National Institute of Standards and Technology) Definition of Cloud Computing: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
NIST Cloud Home Page: http://www.nist.gov/itl/cloud/
Critique on NIST Definition: http://blogs.technet.com/b/yungchou/archive/2011/12/19/an-inconvenient-truth-of-the-nist-definition-of-cloud-computing-sp-800-145.aspx
The First Cloud Computing Technical Standard: http://blog.opengroup.org/2012/01/24/1st-technical-standard-for-cloud-computing-socci/
HP Blog on First Standard: http://h30499.www3.hp.com/t5/Grounded-in-the-Cloud/Cloud-Computing-gets-its-first-technical-standard-SOCCI-from-The/ba-p/5502543
SOCCI (Service Oriented Cloud Computing Infrastructure framework) Announcement:
http://www3.opengroup.org/news/press/open-group-publishes-new-standards-soa-and-cloud
Article on SOCCI: http://cloudcomputing-365.info/news_full.php?id=20929&title=The-Open-Group-publishes-new-standards-for-SOA-and-cloud
The Problem with Cloud-Computing Standardization by Sixto Ortiz Jr.: http://www.infoq.com/articles/problem-with-cloud-computing-standardization
The Problem with Cloud-Computing Standards, Paul Strassman’s Blog: http://pstrassmann.blogspot.in/2011/08/problem-with-cloud-computing-standards.html
Cloud-Computing’s Vendor Lock-In Problem: Why the Industry is Taking a Step Backward? http://www.forbes.com/sites/joemckendrick/2011/11/20/cloud-computings-vendor-lock-in-problem-why-the-industry-is-taking-a-step-backwards/
Perspectives on Cloud-Computing and Standards, Peter Mell, Tim Grance, NIST, Information Technology Laboratory: http://www.omg.org/news/meetings/tc/dc/special-events/Cloud_Computing/NIST.pdf

Agile Teams: Try Drumming for Team Building!

2012-01-27T07:11:00.000-08:00

My previous blog mentioned a little bit about the “5th Indira International Innovation Summit” presented by Indira College of Engineering and Management. One of the sessions in this event was “Building Teams One Beat at a Time” by Ms. Aliya Hasal, CEO, Drum Café International.

15 minutes before the start of this session, event volunteers swiftly distributed Djambe drums to almost all 400 attendees in the auditorium. When the anchor Dr. Raju Bhatia invited the presenters on stage, the audience started beating the Djambe drums whimsically. I could feel a sudden desire or change of mind among all to keep beating the drums until the presenters acknowledged the enthusiasm and calmed down everyone!

We were in complete silence. Dr. Vinod Hasal (Director, Drum Café, India) started leading the performance on stage and miraculously gave us very simple instruction to follow the beats! Within minutes, the entire auditorium was in rhythm. We could feel unity, team-building, relaxation, creativity, learning and fun! He was a great coach! & He engaged the team of 400 enthusiastic, novice drummers very well! The result was rhythmic drum beats! The patterns changed every three minutes and the audience followed without missing the beats! A vast majority of us had never touched a Djambe drum before! However, we could join the team on stage and follow their rhythm. As a result, this session rejuvenated us and made us believe in the power of co-creation.

I strongly believe that drumming sessions like this one can benefit organizations and communities. These sessions can help us build Agile teams. No doubt about it! My experience in this session reemphasized the fact that we must trust our team, give them the necessary infrastructure and tools, and provide them an open environment. This is because the quality of our workday counts! When we do this our teams become creative and innovative.

Above all, we must identify an agile coach. This is the foundation of agile teams. With a good coach, team members will align and start performing! When they perform together over multiple iterations there will be continuous improvement and high quality.

Have you been through a ‘drumming’ session for team building? What do you think?

Application of TRIZ in Software Engineering

2012-01-24T08:08:00.000-08:00

Last year at SPIN Chennai Annual Conference (SPICON 2011), I delivered a talk on “Inventive Problem Solving for Customer Value Creation”. My talk was based on a real life problem solving experience. When you go through the presentation you will get a broad understanding of this talk.

This year, I got an invitation to speak at “5th Indira International Innovation Summit” presented by Indira College of Engineering and Management . During this event, the event organizers honored me with “Excellence in Innovation Award”.

It was a house-full event with more than 400 participants. The planning and execution of this event was very impressive. The selection of topics and speakers on both days offered a good balance between serious discussions and fun-filled learning.

In Software Engineering and Software Services Industry there are numerous opportunities to innovate. What we have accomplished is just the beginning. We have a long way to go! Do you have an experience to share? Feel free to write to me.

Do You Follow Defect Prevention Techniques?

2012-01-18T20:08:00.000-08:00

The term 'Defect Prevention' (DP) relates to defect analysis and preventive action planning related to defects found in various streams of project activities. Typically defects can be review defects or testing defects (there are other types of defects as well - For example, configuration defects or other forms of defects that are not captured during reviews or testing).

What can be our approach to DP? It can be something that includes a systematic way of collecting and analyzing defects and preventive action planning. Also, this approach includes the frequency of performing DP and a clear definition of ownership so that DP happens as planned. The objective of DP is to make sure that a significant number of those defects do not occur in future.

Creating and executing test cases, test automation, and code quality checks are meant for ‘Defect Detection'. Not for ‘Defect Prevention’.

So, how do we do DP? Well, we can do DP by gathering data on all defects, categorizing them, analyzing them and deriving certain conclusions. Based on these conclusions we decide on preventive actions and implement them.

If we do not derive and implement preventive actions, all we accomplish is a pure 'Defect Analysis' (also known as Bug Analysis). DP requires you to travel an extra mile (in terms of identifying and implementing preventive action plan) after you complete Bug Analysis.

80/20 principle is adopted as one of the DP techniques. When you analyze test defects you perform ‘Pareto Analysis' to understand the distribution of defects. Based on your findings, you come up with action items that help you prevent 80% of defects. There are other techniques too.

Agile teams go through iteration-end retrospectives. How can DP techniques help them perform better? What has been your experience? Do you follow DP techniques? Let us discuss.

Clouded by Cloud Security Concerns?

2012-01-06T08:56:00.000-08:00

Cloud Computing is an emerging trend or seemingly an evolution in IT industry. When electricity, water, telephone, etc., are provided as utilities, why not the power of computing or data storage? Thoughts on similar lines triggered the concept ‘Utility Computing’ during early 60s. This concept has matured over years. With the power of internetworking it has reincarnated as ‘Cloud Computing’.

However, end users are clouded. They are unclear and concerned. The source of their concerns is ‘Cloud Security’. We park our expensive cars on streets. We are not concerned because of an appropriate car insurance plan. We do keep our hard earned money in banks. We use bank lockers to store important documents, jewelry, etc., We are used to these paradigms or provisions whether or not they offer adequate security.

Is there a cloud we can trust? This is what CIOs ask. As a matter of fact, product companies are working on clouds we can trust. Cloud platforms will have an increasing level of adoption when security concerns are addressed adequately. In addition to this, cloud providers will have to get into contractual terms and commit to legal obligations in serving end users or customers. Until now, not many providers address these areas. Therefore, customers think twice and decide to adopt private clouds.

We will go through this evolution. However, Cloud Computing has its promises. It is possible to optimize IT budgets by leveraging the benefits of cloud. The term ‘Clouptimization’ relates to this possibility.

Inspections and Reviews in Agile Projects

2011-12-20T06:28:00.000-08:00

In my previous blog "Can Inspections Make Defect Prevention Effective?" , I emphasized on spending one or two hours per iteration on reviews and inspection in Agile projects. Also, I wrote that Fagan inspection can be fine tuned to suit Agile projects so that team members can perform inspections or reviews in small groups of two to four team members, depending on the criticality of such inspections or reviews. In this blog, let us go through when and how this can be done in Agile projects.

1. Review of requirements. Group reviews makes sense in agile projects. In one of the distributed agile projects we had scheduled conference calls to walk-through requirements at the beginning of iteration. These conference calls were more beneficial than 1-1 interactions because, the entire team could understand and ask questions as group. As a group, we found gaps in requirements and related one user story to another and refined user stories. Don’t we call this backlog grooming?

2. Review of architecture and designs. This is not about ‘big-upfront’ architecture or design. I have come across situations in agile projects that required our team to do complex designs in order to move forward with reasonable modularity in code. These designs are either UI designs or UML notation etc. In this context, it is valuable to involve all team members and perform group review. This step helps us improve the quality of design.

3. Code Refactoring. Whether you do pair programming or not, it is a good practice to convene meetings at regular intervals (typically once in a month or on need basis) to discuss some of the key code refactoring instances. This can be a part of ‘retrospectives’ too. More than this, for critical chunks of source code, group review with two to four engineers is the way to go.

4. Test Case Reviews. At regular intervals, group review of test cases can help agile teams improve the quality of requirements as well as test cases.

5. Configuration Files, Build Files, etc. When two or more engineers come together and review configuration files they can streamline the placement of configuration parameters in the right files. Also, reviews of build files can minimize build failures due to scripting or configuration errors.

Typically these reviews in traditional projects used to take 10 to 15% of efforts. Should we invest in inspections and reviews to eliminate defects proactively? Why not? Ultimately, when we find ways to implement continuous improvement through this experience, we get to improve process as well as product quality.

One may think or argue that practices such as pair programming and ‘retrospectives’ enable agile teams practice continuous improvement and that is sufficient. 'Retrospectives’ are iteration specific. Do we get to apply 80/20 rule by gathering cumulative data of all past iterations in Agile projects? If no, don’t we have to?

Can Inspections Make Defect Prevention Effective?

2011-12-19T08:24:00.000-08:00

“Yes”, says Capers Jones. Formal inspection of requirements, architecture, designs, source code, configuration files, build scripts and test cases enable project teams in finding critical defects.
The cost of defects (related to requirements or designs) found during later stages of lifecycle is enormous. The best way to deal with this issue is to detect defects at early stages. Inspection is a way to accomplish this.

Not all Agile teams do pair programming. What about designs? Or configuration files? Do we inspect? When inspection or reviews are not done, the result can be accumulation of technical debt. Right?

When we find defects through inspections and reviews, we get an opportunity to classify defects and identify the root causes. Remember 80/20 rule? When we do this we can reduce the number of defects in subsequent iterations.

Fagan inspection can be fine tuned to suit Agile projects. Instead of performing inspection in large groups, Agile teams can perform inspections or reviews in small groups of two to four team members depending on the criticality of such inspections or reviews. One or two hours per iteration spent on reviews and inspection in Agile projects can yield immense benefits.

Have we forgotten the value of inspections and reviews? Caper Jones’s article ‘Do You Inspect?’ is an eye opener for everyone.

In the next blog "Inspections and Reviews in Agile Projects" I have shared 5 pointers and additional questions.

Agile Myths and Misunderstandings

2011-12-07T07:26:00.000-08:00

In our industry we do come across myths and misinterpretations related to Agile Software Development and Agile Testing. Here are some examples.

1. Take the waterfall model and add one arrow
2. Agile means 'start coding with no documentation'
3. Agile means 'ad hoc' or 'no processes’
4. Agile means 'no planning'
5. Agile team members must be super stars
6. Agile is for product engineering only
7. Changes can happen on a daily basis
8. Agile is for development projects only
9. Agile impacts work-life balance
10. Agile is just another fad
11. TDD is enough to ensure software testing
12. A chain of unit tests is a complete regression suite
13. Agile doesn’t allow for long-term planning
14. Agile testing is all about unit testing, TDD, and test automation
15. In Agile projects process compliance is a big issue

Details on each of these are available in this freely downloadable PDF. Happy Reading!

Requirement Engineering: Ten Principles

2011-12-02T21:22:00.000-08:00

1. Quality is the top priority and it is possible to deliver high-quality software. In order to make this happen, business analysts need to focus on delivering high-quality requirements. Obviously, both the form and the substance of specifications are equally important.

2. Understand the problem before specifying requirements. When business analysts understand the problem accurately, it is highly probable that they are going to create specifications that are very close to what the user wants.

3. Use appropriate tools, models and practices. It is necessary to understand the organizational culture of customers and be aware of what tools, models and practices have worked for them. Tools, models and practices that provided results in collocated teams may not work well in case of distributed teams.

4. Awareness, skills, techniques, and discipline are more important that tools. The outcome of any practice is not determined just by the tools that you use. For example, a plumber who is in-charge of your facility requires awareness of your facility. He needs to be skilled. He has to follow certain discipline and understand relevant techniques. Without these qualities, if he claims his strength because of a powerful tool set he has, he is a dangerous plumber. This applies to team members who participate in requirement engineering activities too.

5. Establish appropriate measurement criteria. How do you measure the progress of requirement engineering activities? It is necessary to have appropriate measurement criteria. Document exchange or data collection is not requirement engineering.

6. Establish an appropriate verification and validation criteria. How do you verify requirements? How do you validate them? It is essential to have appropriate criteria for V&V activities. Doing it right is more important that making it faster.

7. Good team and good management are vital to success. Technology comes next. Start-ups succeed when they have a good team that captures product requirements and a good management that fosters product development. Technology is essential. More than technology, a good team and good management are important.

8. Understanding of customer’s priorities is paramount. This is what helps the team understand priority requirements at early stages and find ways to deliver working software early. The more the customers see, the more they will need. Understanding customer’s priority is a way to deliver valuable features early. Delivering early is the way to understand what else the customer wants.

9. Use the most efficient communication tools. Information exchange over documents can lead to misinterpretation or inadequate grasp. White board sessions, walkthroughs, using face-to-face meetings or video conferencing sessions are the effective ways of information exchange.

10. Ask questions. While this is applicable for all areas of software engineering areas, it is very appropriate for requirement engineering. Questions based on various aspects such as business need, functionality, scalability, performance, usability, test data, data volume, geography of users, compliance, etc. help business analyst understand requirements in detail. Asking context-free questions are equally important to make a positive impact.

Fixed Price Distributed Agile Projects

2011-11-20T06:02:00.000-08:00

I will be delivering a session on 'Fixed Price Distributed Agile Projects' at Agile Tour 2011, Bangalore on 26th Nov 2011. This session will present the challenges and approaches related to executing Fixed Price projects in Distributed Agile model.

In reality, projects are sanctioned based on pre-approved budgets. Customers prefer to get projects done in fixed-cost. Can the scope remain fixed? Can the schedule also remain fixed? The challenges of fixed price projects emerge from changes in requirements. How do we stick to "Responding to change over following a plan" as mentioned in Agile Manifesto when we execute fixed price projects? How do we value "Customer Collaboration" over "Contract Negotiation"?

If you are in Bangalore next week, plan to attend Agile Tour 2011.

Requirement Engineering: Specifications in which form?

2011-11-18T07:42:00.000-08:00

The day before we started the new project, my team member got curious. He asked, “Are we going to receive requirement specifications from customer? How will the specifications look like? Let us make sure that there are no communication gaps.”

I responded, “In a document with text, and UML notations in our standard format. We will get wireframes too.”

We had a short pause. I continued, “We will have a look at existing data and reports. We will do our best to reduce communication gaps.” He nodded silently.

I could read his mind. We had serious gaps in understanding requirements in our recent project and the result was a huge schedule over run. We wanted to do it better this time.

Specifications come in what form? Obviously in documents with UML diagrams, wireframes, etc. When it comes to requirements, we cannot afford to say, “Let us not worry about form. Substance is critical.” Both form and substance are equally important.

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to go rectify later”, says Fredrick P. Brooks, Jr. in his book ‘The Mythical Man-Month (Addison-Wesley, 1995).’ He adds, “I would go a step further and assert that it is really impossible for clients, even those working with software engineers, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying.”

Can Rapid Prototyping help? Yes. It can help to a certain extent. In fact, Rapid Prototyping can be done at the time of Requirement Gathering and Elicitation. Products meant for this purpose are available in the market these days.

When we combine the power of such tools with the way we create software using methodologies based on iterative and incremental delivery, we get an opportunity to deliver working software early and frequently. Delivering working software early at regular intervals is a way to make your specifications powerful. This is when you reduce the gap between what is specified, what is delivered and what is needed.

When you have specifications in written text, UML notations or wireframes for more than a month or two, chances are that they become obsolete. You need to get them validated. When you do rapid prototyping (on a case-to-case basis) and focus on short-iterations to deliver working software you get an opportunity to demonstrate working software and get feedback. You get to improve what you did.

It is easier said than done. I agree with Brooks. He said it right. Right?

Code Quality Metrics: Identification, Collection and Consumption

2011-11-01T09:22:00.000-07:00

Unless we identify the code quality metrics we want to consider for a given project or product, before we start coding, it is highly probable that we will get confused with a huge collection of metrics presented by tools and textual content such as books, white papers, blogs, etc.

We do capture functional and non-functional requirements in software projects. Can we capture requirements that can help us set a common understanding on expected level of code quality?

When you use a static analysis tool, it is necessary to know acceptable range of values for each metric. Otherwise, how will you access code quality?

Code review tool does not serve the purpose until developers are cognizant of the semantics of code quality metrics and permissible range of values. I am sure we have heard, ‘A fool with a tool is still a fool.’ Don't you agree?

Every project or product team needs to have a code review checklist, coding standards and guidelines that can set a common understanding among developers on code review criteria. This will enable developers write good quality code to begin with.

Prevention is better than cure. Isn’t it?

Distributed Agile: Quality before Design

2011-10-18T06:21:00.000-07:00

Distributed Agile involves geographically dispersed teams and short iterations of 2 to 4 weeks. Stakeholders of distributed agile projects need to find ways to improve quality before design by means of providing the right work environment and tools to team members and ensuring that project requirements are of good quality. There are five steps that can help us improve quality before design.

Product Vision Document: When distributed agile teams execute iteration activities without knowing the product vision or release vision, they not only miss an opportunity to understand the big picture but also fail to interact with stakeholders by asking context-free questions. Context-free questions increase project awareness among team members and provide for a strong foundation.

Goal-Oriented Requirements: The next step is to ensure that user stories are not generic statements but relate to the goals of end users. When team members receive goal-oriented requirements or users stories, they relate them to the goals of end users and come up with innovative ways to find solutions.

Not Only Functional Requirements: The third step is to include non-functional requirements such as performance requirements or security requirements in user stories. When this is accomplished, distributed agile teams optimize the time spent in defining the acceptance criteria and ‘Definition of Done’ for user stories. Also, this improves the quality of test cases and test scripts in projects.

Prioritization: Product Owners and Scrum Masters of distributed Scrum projects need to have an objective and proactive prioritization approach in order to define priority categories unambiguously. When prioritization of user stories becomes a reactive approach, it can lead to changes during iterations and hence can put lot of strain on team members. Distributed agile teams need to be aware of the rationale behind the prioritization of user stories. Lack of awareness among team members can lead to perceived notions on lack of inclusiveness.

Tool Selection: Tool selection plays a vital role in distributed agile projects. Effective tools for managing user stories as well as related communication and coordination mechanisms contribute positively to distributed agile projects. Indecisive approaches to tool implementation or introduction of new tools during project execution will hamper effective management of user stories. It is strongly recommended that distributed agile teams consider a web based tool that supports specification of user stories as well as facilitates collaboration among team members.

Finally, quality before design is quintessential to improve project success. My article, ‘Distributed Agile: Steps to Improve Quality before Design’, published by Agile Record articulate these steps with additional details.

The 7 Habits of Highly Effective 21-st Century IT Professionals

2011-10-07T08:56:00.000-07:00

Gone are those days when monolithic IT systems were developed and maintained by exclusive communities of IT professionals confined to technology-savvy regions of the world. The challenges of software engineering during the 21st century are quite different and multifold because of factors such as globalization and technology evolution.

In order to face these challenges, 21st-century IT professionals will need to transform successful practices into habits so that these practices become second nature.

Cutter IT Journal published my article “Force of Habit: 7 Essentials for 21-st Century IT Professionals” in the September 2011 issue. In this article, I have discussed the seven habits that are essential for today’s IT professionals.

The seven habits discussed in this article empower IT professionals to prepare, act, collaborate, optimize, and influence effectively in their career.

~~Watch this space. I will publish a link to download the article soon~~. If you are a Cutter member, you can download it from Cutter.com. Or you can download a free copy of this article from http://www.cutter.com/offers/forceofhabit.html.

Can Unit Testing Improve Testability?

2011-09-29T18:10:00.000-07:00

While writing unit tests software engineers tend to relook at the source code and improve it so that it becomes testable. This is an internal experience. When you do this your code becomes maintainable as well. Have you gone through this experience?

You get this experience when you write unit tests for the complex pieces of your source code.

Two recent articles on topics related to this subject are ‘Breaking Away From The Unit Test Group Think’ by Cedric Beust and ‘Chasing Code-Coverage Baubles’ by Andrew Binstock. A good read for all software engineers.

These articles reveal several misconceptions related to Unit Testing and TDD and provide answers to the following questions.

Do you think 90% code coverage through unit testing is sufficient?
Do you think you need to do TDD always in your development cycle?
What is the optimal code coverage? How do you decide?
Has TDD become a common practice in the industry?

Governance of Distributed Agile Projects: Critical Success Factors

2011-09-22T08:45:00.000-07:00

On 15th October 2011, I am speaking at 'Agile Tour 2011, Pune'. India Scrum Enthusiasts Community is organizing this event. Agile Tour is a forum for Agile practitioners at all levels - from young engineers to professionals at very senior levels.

The title of my session is 'Governance of Distributed Agile Projects: Critical Success Factors'.

This session is based on an article published in the July 2011 issue of Agile Record.

Requirement Engineering: Asking Context-Free Questions

2011-09-18T06:25:00.000-07:00

‘Exploring Requirements: Quality Before Design’ by Donald C. Gause and Gerald M. Weinberg is a must read for students as well as professionals. In this book, the authors emphasize that project teams need to ask context-free questions in order to understand high level details that are necessary to create the right product in the right way. According to them there are two primary categories of context-free questions: a) context-free process questions and b) context-free product questions. Also, they discuss about the third broad category of questions called metaquestions or questions about questions. Context-free questions are applicable to any product design. They consume less effort but provide an opportunity to obtain valuable information.

Context-free questions can be used in Software Engineering irrespective of the lifecycle methodology used. Also, IT consulting teams can use context-free questions during portfolio analysis or assessment phase in order to better understand the customer requirements.

Context-free process questions relate to the process to be followed and the answers to context-free questions relate to the project or the lifecycle activities. Context-free product questions relate to the design of the product and the answers to context-free product questions provide details on attributes, considerations or trade-offs related to design of the product. Let me share few examples here. Most of these examples are based on my experience.

Examples of Context-Free Process Questions:

What are the success criteria for this project? Or how do we measure the success of this project?
What are the driving factors for executing this project with a collocated team (or distributed team) or a consulting partner?
How much time do we have for this project?
What is your trade-off between schedule and quality?
Where else can the solution to this design problem be obtained?
Can we reuse something that already exists? Can we use open source?
Who are the competitors for this product?

Examples of Context-Free Product Questions:

What problems does this product solve?
What problems could this product create?
What are the operational environments for this product?
What kind of precision is required or desired in the product?
What are the interfacing standards to be followed?

Examples of Metaquestions:

Am I asking you too many questions?
Do my questions seem relevant?
Who is the right person to answer these questions?
Do you think our team needs to contact multiple members in your organization to get answers to these questions?

Context-free questions help us identify hidden assumptions. They help us identify the right approach to design applications or products. Also they help us design the right applications or products.

Computer Programming: Art or Science?

2011-09-12T08:10:00.000-07:00

Donald E. Knuth, one of the world’s eminent computer scientists, published hundreds of papers and evangelized computer science through his writings and teachings. His three volumes of ‘The Art of Computer Programming’ are among the most popular books in computer science.

In an interview he said, “When you write a program, think of it primarily as a work of literature. You’re trying to write something that human beings are going to read. Don’t think of it primarily as something a computer is going to follow. The more effective you are at making your program readable, the more effective it’s going to be: You’ll understand it today, you’ll understand it next week, and your successors who are going to maintain and modify it will understand it.”

Programming is not a mechanical activity. Successful compilation of programs is not the end to programming. Putting your programs through a static analysis tool (for eg., JTest) is just the beginning. Programmers need to understand the errors reported by such tools and develop the ability to pick and choose the right set of fixes that can improve code quality. Also, programmers need to practice refactoring in order to improve code quality.

An interesting analogy is cookery. Those who carry the passion for cooking do not blindly follow a set of instructions or restrict themselves to using state-of-the-art tools. They think of it as a work of art.

By the way, the full version of Donald E.Knuth's interview is available at the website of Dr.Dobb's journal.

Data Mining for Environmental Protection

2011-09-06T06:49:00.000-07:00

Data Mining is an emerging field of computer science. It involves data processing, data analysis and derivation of useful information from large databases or data marts.

Life-Cycle Assessment (LCA) is a technique used to estimate the environmental footprints of hardware products by taking a comprehensive view of multiple environmental impacts such as greenhouse emissions of products. Interestingly Data Mining can be used to automate Life-Cycle Assessment (LCA). This is a wonderful application of Software Engineering for environmental protection.

A recent article titled 'Using Data Mining to Help Design Sustainable Products' published by IEEE is a very good read on this subject.

You may ask, ‘How Green is my iPad?’. The answer to this question was elaborated by Daniel Goleman and Gregory Norris in their article published by New York Times, 4th April 2010.

Another interesting article on this subject has been published by Brazilian Journal of Oceanography. The title of this article is 'Data mining for environmental analysis and diagnostic: A case study of upwelling ecosystem of Arraial do Cabo'.

Is there a way to monitor illegal dumping of garbage and toxic material? The answer is yes. Read ‘Monitoring of Illegal Dumping Using Spatial Data Mining and Remote Sensing’ for more information.

Here is an example on how governments are funding research in this area:
Environmental data mining: learning algorithms and statistical tools for monitoring and forecasting

Isn't it interesting?

Speaking at Java Conference 2011

2011-08-17T05:14:00.000-07:00

SiliconIndia's Java Conference 2011 is scheduled on August 20th 2011 in Bangalore. This conference is for Java professionals as well as IT experts who are into object-oriented languages, evolutionary methodologies (for example, Agile methodologies) and emerging trends such as Cloud Computing . This is a 1-day conference and it has 3 tracks:

1) Language, Tools & Techniques

2) Architecture and SOA

3) Agile and Cloud.

The conference fee is very nominal. If you are in Bangalore, don’t miss this opportunity. I am speaking on 'Agile for Legacy to SaaS Migration: Ten Key Considerations'.

Agile for Legacy to SaaS Migration

2011-08-13T08:23:00.000-07:00

During 2000, I was associated with an Independent Software Vendor (ISV) - a small startup firm with not more than fifty employees. The engineering team of this startup firm built a Human Resources Management (HRM) product on J2EE stack with JRun application server and My SQL database. During the first 3 years the sales team sold the product to less than 25 customers. These customers were small to medium size businesses with 100 to 1000 employees. Sales cycles were longer. Every new customer had to go through an installation ceremony followed by a series of customization routine to make the product functional. Even though product customization fetched some revenue through professional services, working with customers spread across geographies and providing them product support became very tedious. Over the next several years the customer base of this product increased by 300%.

Since the past two years the complexity of product management and customer management has increased multifold. Every customer installation has had some form of customization request queue with less than 50% of the requests implemented in production. Lately, scaling up in the current model has become an insurmountable challenge.

Interestingly, this HRM product is a good example of a legacy web product or application that needs to be re-architected or transformed to SaaS paradigm. Can we use Agile for SaaS migration? The answer is “Yes”. However it is essential to reflect on a set of key considerations in such projects. You will find more info on this subject in the free white paper “Agile for Legacy to SaaS Migration: Ten Key Considerations”.

What has been your experience in this area?

Can Refactoring Improve Design ?

2011-07-29T07:31:00.000-07:00

Yes, it can but not always!

When can refactoring improve design? Refactoring can improve design when team members who do refactoring are not only just programmers who know only language constructs but also are designers who know design principles. Team members who perform refactoring need to be experienced programmers. That is not enough. They need to know design principles in order to improve design. Else, they will not be able to figure out if the structure and association of entities or classes need to be changed in order to improve the design of software systems. They will focus only on a single program or subset of classes while refactoring.

Refactoring cannot improve design when we put programmers through a crash course on refactoring. It is essential to train them on object oriented analysis and design. They need to learn all design principles as well as programming principles. If we take this approach, yes, refactoring can improve design.

There can be extreme cases of dealing with complex or legacy code. Refactoring of legacy code is a costly affair. This requires experienced designers who have the ability to discover the hidden design.

In his article ‘Discovering Hidden Design’, Michael Feathers has articulated this very well with an example. It is a good read for all software professionals.

Challenges in Distributed Agile

2011-07-13T09:08:00.000-07:00

While executing multi-site projects, Agile practitioners do face several challenges due to factors such as distribution of teams that results in limitations in face-to-face communication, and cultural mix of teams that impedes team bonding. In some instances I have seen collocated Agile teams inducting distributed teams in order to implement distributed Agile. In other instances, several virtual teams come together to implement distributed Agile. In both cases, the short term results are not impressive because of the inherent challenges associated with distributed Agile. Also, several questions such as the following surface as challenges.

1) How do you ensure that everyone understands the project vision and builds adequate rapport to work as a team?
2) Are engineers making the right assumptions (and validating them) and understand their expectations?
3) Are team members aware of detrimental communication loops that can impact productivity?
4) How will team members involve in efficient query resolution and ensure that they preserve the tacit knowledge exchanges?
5) How do team members avoid the trap of 'Blame Game' that could arise from product demos at the master location?
6) How do team members own quality and improve both internal and external quality of the product?
7) How will senior leaders or program mangers react to unfinished user stories?
8) How accurate can be the status checks? How will Scrum Master(s) perform status checks?
9) When and Where will Root Cause Analysis happen? Who will participate?
10) How will senior leaders maintain team motivation across virtual teams?

There are ways to manage distributed Agile challenges and ensure early success in projects. Governance of distributed agile projects plays a crucial role in making this happen. What has been your experience? What are the critical success factors?

SQL - The Past, Present and Future

2011-07-06T21:19:00.000-07:00

In June 1970 Dr. E. F. Codd published the seminal paper, "A Relational Model of Data for Large Shared Data Banks", in the Association of Computer Machinery (ACM) journal, Communications of the ACM. This paper laid the foundation of relational databases and Codd's model got accepted as the definitive model for relational database management systems (RDBMS) across research institutes in all continents.

For the past three decades SQL has been accepted as the standard RDBMS language. There are three key reasons for the longevity of SQL. They are a) Simplicity, b) Strong Mathematical Foundation and c) Adoption (by several vendors). The power of SQL increased tremendously over the past three decades and SQL emerged as the de-facto standard for relational databases.

The NoSQL movement of 1998 supports database implementations that are non-relational data stores of several categories such as document stores, graph databases, key-value stores, multi-valued databases, etc. There are several flavors of NoSQL implementations such as Oracle Corporation’s BerkeleyDB, Google’s BigTable, Apache’s Cassandra, and Amazon’s SimpleDB.

It is very evident that SQL and NoSQL movement are complementary. RDBMS and SQL implementations will continue to thrive in ecosystems that require OLTP support on relational data stores. What Next?

Podcast on ’10 Best Influences on Software Product Engineering’

2011-06-28T08:55:00.000-07:00

Tom Cagley (http://tcagley.wordpress.com/) interviewed me on my article ’10 Best Influences on Software Engineering’ published at SD Times. This interview happened sometime during April or May 2011. During this interview Tom asked me very interesting questions and engaged me in a great conversation. This interview happened over phone across continents. He was in US (East Coast) and I was in India(Pune).

Tom has composed this interview and made it available at http://spamcast.libsyn.com/s-pa-mcast-140-raja-bavani-the-ten-best-influences-on-software-product-engineering.

Tom runs 'Software Process and Measurement' (SPAM) casts regularly. The Software Process and Measurement Cast provides a forum to explore the varied world of software process improvement and measurement. The SPaMCast covers topics that deal the challenges how work is done in information technology organizations as they grow and evolve. In a nutshell, the cast provides advice for and from practitioners, methodologists, pundits and consultants!

I encourage you to visit his sites and listen to as many casts as you can. You will find impressive interviews by several industry leaders in Software Engineering.

The Four Dimensions of Quality

2011-06-25T18:42:00.000-07:00

This is with reference to my blog of June 3rd 2011 on The Manifesto for Software Craftsmanship Manifesto. This manifesto says

As aspiring Software Craftsmen, we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work, we have come to value:

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left, we have found the items on the right to be indispensable.

When you observe the crux of this manifesto closely, it relates to four dimensions of quality, viz., Product Quality, Business Quality, Professional Quality and Engagement Quality. Right ?

Are Software Engineering Methodologies Converging?

2011-06-09T09:09:00.000-07:00

Are Software Engineering methodologies converging? Or are traditional methodologies becoming extinct because of the popularity of evolutionary methodologies? Isn’t it a reality that projects customize methodologies to suit project context? Does it mean that every project adheres to its own flavor of a methodology? Can we attempt to collect all engineering and project management best practices & pick and choose them to create a methodology for a given context? Will Agile methodologies dominate the industry during the next decade?

Or do we need more methodologies?

The Ideal and the Essential

2011-06-06T03:34:00.000-07:00

Distributed Agile projects are very challenging. Expecting the best results in your first Sprint is optimistic as well as ideal whereas the willingness to accept mixed outcomes and supporting your team in progressing over the first three or four iterations is essential.

Agile teams are as energetic as music bands that yearn for their first stage appearance. A debut of a music band comes with tremendous efforts and enthusiasm. The debut of successful musicians is not only well-rehearsed but also well-supported by the team as well as sponsors. The first Sprint of a team is as memorable as the first stage show of a budding music band.

More on this at “The First Sprint in Distributed Agile – What to Expect ?”

Manifesto for Software Craftsmanship

2011-06-03T06:46:00.000-07:00

Robert Martin, one of the 17 founders of Agile Manifesto is one among the leaders who initiated ‘Software Craftsmanship’ movement during 2009 in order to emphasize on the importance of product quality. According to him, Agile practitioners focus more on iteration management activities and less on engineering best practices. The motivation of Software Craftsmanship manifesto is to kindle the enthusiasm in software engineers to create high quality products. Widely known among industry leaders as ‘Uncle Martin’, Robert Martin has objectively crafted this manifesto with his colleagues so that it remains aligned with Agile Manifesto and propels Agile movement. He believes that Software Craftsmanship movement will help us reinstate engineering best practices such as Coding Standards, Refactoring, Test Driven Development, Automated Unit Tests, etc. Also, he claims that several Scrum projects focus heavily on management practices and on the other hand they do not provide equal focus on engineering practices. He recommends that there has to be a balance.

Undoubtedly, Software Craftsmanship manifesto is here to stay and propel Agile movement over the next several years to come.

Agile Software Development - What Next ?

2011-04-21T23:23:00.000-07:00

Agile Software Development - What Next ? This is a frequently asked question. Agile Manifesto was announced during Feb-2001. Agile became very popular in the next few years.

Looking back, Agile adoption has never been a cakewalk. Immense challenges and struggles in transitioning from 'waterfall' to 'Agile' mindset were not uncommon. Interestingly, something that happened along with Agile evolution was the growth of internet.

The growth of internet enabled computer users in collaborating on the net using collaboration tools as well as social and business networking forums. The exchange of opinions, ideas, and best practices became easier on the internet. Probably, I think, this is one of the key factors that propelled Agile. Eventually, Agile could spread faster than any other methodology.

On the 10th anniversary of Agile Manifesto, the founders had a gathering to discuss the past, present and the future of Agile Software Development.

Couple of weeks ago, I was interacting with Michael Hugos on my thoughts on his blog 'Ten Years of Agile - What the Agile Community Must Do Now'.

Our interactions were engaging. The end result of our interactions was another blog 'Reflections on Four Recommendations for Agile Developers' by Michael.

When you read all these one by one, you will understand the recent happenings in Agile Software Development. Also you will notice the power of collaboration over social and business networking forums.

Note: Every blog that I write carries a picture and this blog is not an exception. I took this picture while flying from Mumbai to Bangalore. It is the picture of an apple offered to me by the cabin crew.

Inventive Problem Solving for Customer Value Creation

2011-04-19T07:31:00.000-07:00

SPIN (Software and Systems Process Improvement Network) founded by the Software Engineering Institute (SEI) of Carnige Mellon University (CMU) has over 130 chapters worldwide. In India there are 13 chapters. SPIN Chennai's annual conference SPICON 2001 is happening on 29th and 30th of April 2011. The theme of the conference is "Innovation in IT Processes - The Engine for Growth".

I am speaking at SPICON 2011 on "Inventive Problem Solving for Customer Value Creation."

Indian IT industry has matured over the past few decades. The maturity of our industry has helped us encounter several challenges successfully. However, new challenges continue to challenge us. One such challenge is managing Service Level Agreements (SLAs) and retaining skilled engineers in projects when the work involved is technically complex but monotonous. This session is about a case study on how we solved this problem by applying 'Inventive Problem Solving' and created value to stakeholders.

I will keep posting some interesting facts and questions here and provide my writing or a presentation on this topic to readers.

Fixed Price Agile

2011-03-12T08:14:00.000-08:00

Agile Software Development is rooted in Agile Manifesto and Agile Principles. It is all about delivering working software at regular intervals in order to provide visibility and predictability. It is also about embaracing changes. Agile requires discipline, focus, team work, conviction and courage. I started a series of Distributed Agile Blogs couple of months ago. Going forward, I will be writing more on this.

Agile methodologies such as XP, Scrum etc. work well in Time and Material (T&M) model. It has been a big challange to harness such projects in Fixed Price model. How can stakeholder commit to Fixed Price and execute projects that involve agile principles? Agile and Fixed Price: Can they go together? These questions are just the beginning. If we dig deeper, we come across distributed teams that work across time zones and cultures. Executing agile projects with distributed teams has become a common theme across several companies. However, combining agile or distributed agile with fixed price has been a bigger challenge.

My recent paper on Fixed Price Distributed Agile shares a case study on this topic.

The 10 Best Influences on Software Product Engineering

2011-02-16T07:40:00.000-08:00

When we think through the past decade Software Product Engineering is one of the areas that witnessed several challenges as well as innovations. Here are the ten best influences on SPE that transformed the landscape of businesses as well as social life.

1) Growth of E-commerce and Online Applications
2) Service Orientation and New Business Models
3) Collaboration Tools
4) Agile Software Development
5) Modern Software Engineering (or Modern Software Development)
6) Test Automation
7) Business Intelligence
8) Global Software Development
9) Open Source Movement
10) Paradigm Shift in Delivery Platforms

More information on each of these influences is available in my article published at SD Times.

CONSEG 2011 - International Conference on Software Engineering

2011-02-06T03:55:00.000-08:00

CONSEG is a series of International Conferences on Software Engineering conceived and initiated by Computer Society of India in 1991. CONSEG-2011 is going to happen in Bangalore, India during Feb 2011. The theme of this conference is "Software Quality - The Road Ahead".

When financial markets and economies struggle to regain their strengths, the theme of this conference seems to be appropriate. With cost-cutting measures and challenges in governing projects across multiple sites, delivering high quality software is a tall order.

I attended CONSEG during 2009. In my opinion, CONSEG is one of the professionally managed conferences with less commercial and promotional intents. It offers a great value to every attendee and provides a overall perspective of the happenings in the industry, research instituties and academia.

More info on CONSEG-2011 at the conference website.

Is IT Inclusive?

2011-01-22T20:09:00.000-08:00

Information Technology (IT) and Software Engineering, the well known hi-tech areas once exclusive for scientists, engineers, academia and industry have transformed over years. IT has seeped through human lives in several ways.

As we enter 2011 with all the nightmares of global economic crisis, IT continues to penetrate several areas of our lives. Is IT exclusive? The answer is a definite 'No'. It is not exclusive for scientists and engineers. Meanwhile, let us ask ourselves 'Is IT inclusive?'

These days, IT has started becoming part of physical infrastructure such as roads, power grid, television, telephone networks, and water distribution. Sorel Reisman, IEEE Computer Society 2011 President, in his article "Planning for an Inevitable Future" published in IEEE Computer magazine (Jan 2011) has expressed his views on this transformation and has emphasized on the need for organizations like Computer Society to start considering inclusive approaches. He says "It is time to consider a new transformation - one that addresses societal changes" and adds "By the end of 2011, we’ll have launched pilot Special Technical Communities in social networking, cloud computing, gaming, education, software engineering, and green computing." In this context, during Dec-2010, he initiated a social networking forum at http://www.computer.org/portal/web/the-presidents-discussion-corner for both members and non-members to participate.

Let me return to our question 'Is IT Inclusive?'. The answers are 'Yes' and 'Not Yet'. 'Yes' applies to some of the developed countries and 'Not Yet' for the rest of the world.

I can see certain visible transformations in India. During mid 80s, when I was doing my post-graduation, we used to wait for our 1-hour timeslot (couple of times a week) to use a personal computer at the computer lab of our University. It used to haunt us when a desktop crashes or has a technical problem. We had to wait for couple of days to a week or sometimes even couple of weeks for the technical support engineers to fix the problem. These days, the trend has improved. Timesharing happens among family members in sharing one or two computers. Computers are used more for other purposes than for educational activities by students. Let me add more. Emails have become prevalent. Computers are used for paying utility bills by bill processing executives or end users or both. Online Education and Online Tests have become the trend setters. Several widely accepted IT applications such as Online Banking can be added to this list. This substantiates that we are into this transformation. But we have not made it inclusive yet.

Finally, making this transformation inclusive in our context is a big challenge. At any cost, we are part of the inevitable future! What about other countries?

Distributed Agile in Outsourced Product Development - 10 Critical Success Factors

2010-10-17T07:43:00.000-07:00

On 23rd October, I am speaking at 'agile tour 2010, Pune'. India Scrum Enthusiasts Community is organizing this event. This is a forum for software engineers at all levels - from programmers to professionals at very senior levels. My presentation is going to be on our experience related to implementing Distributed Agile practices in Outsourced Product Development at MindTree.

On 20th November, at Agile Tour 2010, Bangalore, I am going to speak on Distributed Agile and this session is based on my white paper published last year at International Conference on Software Engineering, CONSEG-09.

Outsourced Product Engineering: Tip of the Iceberg

2010-09-26T08:09:00.000-07:00

Outsourced Product Development (OPD) has become an integral part of Software Product Engineering for more than a decade. OPD business has high potential as well as challenges. The idiom ‘tip of the iceberg’ applies to OPD in two contexts – at a macro or industry level, in business context, and at the micro or product level, in engineering context.

At industry level we have seen little more than the tip of the iceberg and we do have a lot more to see.

Every engagement in OPD offers services for multiple products. At every product level we have seen just the tip of the iceberg. Understanding the rest of it is very mandatory!

More on this at: http://www.mindtree.com/blogs/category/software-product-engineering

SaaS - Disruptive but Positive !

2010-05-16T07:11:00.000-07:00

My interview on this topic appeared on CIOL last week. The full version is available at http://www.ciol.com/Enterprise/Enterprise/Interviews/SaaS-Disruptive-but-Positive/135989/0/

Disruptive means "Break through traditional teachings to truth and the word of life". Disrupt(verb) means 'to interrupt the normal course' or 'to through into disorder'. (courtesy: http://www.webster.com/ )

Service Oriented Architecture (SOA) and Software as a Service (SAAS) are disruptive. In general, end users use only 20% of the features of any software product 80% of the time. And in how many instances have we used 100% of the features? The answer is an obvious one. But the fact is that we pay for the entire product. Annual support and maintenance overheads prevail throughout the lifecycle! This trend required some disruption ! SOA and SaaS came in to disrupt.

SOA and SaaS have emerged strongly to promote 'Pay-Per-Use' model. Almost all product companies do have strong focus on releasing new versions of their products that support such paradigms. In order to leverage the benefits of these technologies the volume of hosted software licenses and related business models in the IT landscape will increase. This will benefit several small and medium business. They will be able to avail niche products by means of transaction based license fee or similar models. This is a disruptive but positive trend.

This trend in disruption extended to infrastructure provisioning as well. Now, businesses can purchase 'on-demand' infrastructure for a limited period of use and thus can save loads of costs involved in hardware and software procurement. 'On-demand provisioning' is an application of Cloud Computing. An anology for this is the hotel industry that provides for booking a desired room configuration for a limited period and attracts customers with several offerings with discounts. As one may think, 'Cloud' is not just a retirement home for 'end-of-life' 'non-ctirical' applications and data!

We could not have thought about SaaS two decades ago! It has emerged over the past 5 years or so. Is n't SaaS an impressive disruption?

Software Architects – An Evolving Breed of Software Professionals!

2010-05-15T09:24:00.000-07:00

Software Architecture is considered to be one of the overused terminologies in our industry. Typically, any contemporary software project team, depending on its size, consists of a team of one or more architects that is responsible for providing a sound architecture for the proposed software system. Contemporary projects that involve cross-functional solutions based on multiple technologies, platforms and user groups require a dedicated team of architects in addition to a typical design team as compared to traditional projects. The characteristics of software architects and their role have evolved over a period of time.

Traditional waterfall approach comprises of Requirement Analysis, Design, Construction (Coding, Unit Testing), Documentation, and System Testing and this provides for an intensive design activity during the design phase. The term ‘Software Architecture’, though originated long ago, is being focused upon in the industry during the last couple of decades and this coincides with the evolution of new technologies (such as Web Technologies) and evolutionary methodologies (such as Rational Unified Process and Agile Software Development) in IT industry.

Architecture is a software engineering activity in software projects and a civil engineering activity in civil engineering projects. The myth about the term ‘Architect’ in both Software Engineering and Civil Engineering is that an architect is an individual who brings just a good amount of technical experience in the respective engineering discipline. Though this is the fundamental requirement, an architect needs more than the technical skills specific to the project he has been hired for. The definition of ‘Software Architecture’ would help us identify the desired characteristics of ‘Software Architects’ – the not-so-new but evolving breed of software professionals.

Software Architecture has been defined by various organizations and professionals and a definition that consolidates many such definitions is

“Software Architecture is based on strong architectural principles and guidelines. It provides the blue print of the proposed software system and such a blue print consists of all necessary views of the software system, its components, their interaction and addresses the requirements (both functional and non-functional). Besides, it exploits the available technology with a clear strategy in order to reduce the impact on existing systems in an enterprise, stands cost-effective and delights the stake holders.”

Thus, it is not enough if software architecture addresses the functional and non-functional requirements. The architecture itself has to be based on strong principles, guidelines and it must address the long-term requirements related to the structure of the software itself. The long-term requirements related to the structure of the software are derivable from the best case requirements, long-term focus of the IT organization, reuse considerations, technology preference, proposed budget, wish-lists and other up-coming technologies that could benefit the organization.

This makes it clear that all user requirements mapped into an excellent set of use cases is just one of the inputs to the architect to produce a sound architecture. An architect need not wait until all detailed requirements are documented and use cases are identified. The architect can start his activity with initial requirements, high-level use cases, based on a set of organizational standard (or project specific) architecture goals, principles (typically a set of Dos and Don’ts) and guidelines, keeping in mind the clear picture of the customer’s IT infrastructure, mission and vision. Unless the architecture is aligned to customer’s IT infrastructure, mission and vision, it would prove itself to be fruitless and evolve as a major risk for the project as well as the IT organization as a whole.

A software project, depending on its size, may require a team of one or more architects to accomplish this vital task of identifying, consolidating, documenting, reviewing, finalizing and maintaining the architecture of the software system through out the project’s lifecycle. Such a requirement essentially focuses on a professional who is not only broadly technical but also very good at soft skills especially in the areas of business communication, conflict resolution, self-expression, emotional intelligence, and team skills. Often, a highly respected technical professional in an organization fails to be a good architect because of his lack of soft skills in getting things done on time with a team of professionals. When a team of technical architects meets the project team to propose an architecture there could be conflicting issues and interests among the architecture team as well as the project management team as a whole. It is the architect who needs to posses strong skills in putting his architecture across by means of presentations or discussions. He has to be open-minded to encourage, understand and appreciate the suggestions or conflicting opinions. Meanwhile, he must be time-bound and decisive to make his team as well as his stakeholders understand the rational behind the proposed or renewed architecture. And he must carry the right level of self-esteem and feel proud of the final decision and exhibit ownership throughout the product life cycle.

In summary, software architects need to be experienced in various areas including core technologies, peripheral technologies, application development & implementation and variety of soft skills. Software architects need to hone their skills and build knowledge to research and understand emerging technologies, technology trends, client’s IT infrastructure, mission and vision. Finally, they need to have necessary expertise in identifying and using necessary software processes, tools and techniques to architect the software system, document the architecture with required granularity (with APIs and code samples), communicate it to the project team and be a mentor for the team to implement the system. With these qualities, this new breed of software professionals can definitely be identified and admired as visionaries for the software project and team they are working with!

Bibliography:

A framework for information systems architecture – J.A.Zachman, IBM Systems Journal, Vol26, NO 3, 1987
Extending and formalizing the framework for information systems architecture – J.F.Sowa, J.A.Zachman
Architectural Blueprints – The “4+1” View Model of Software Architecture – Phillippe Kruchten, Rational Software Corp., 1995
The Role of the Architect – Dana Bredemeyer and Ruth Malan, Bredemeyer Consulting
Design Patterns – Elements of Reusable Object-Oriented Software – Eric Gamma, Richard Helm, Ralph Johnson, John Vlissides
Software Architecture: a Roadmap – David Garlan, School of Computer Science, Carnegie Mellon University
Functional Requirements and Use Cases – Ruth Malan and Dana Bredemeyer, Bredemeyer Consulting
How Do You Define Software Architecture? (http://www.sei.cmu.edu/architecture/definitions.html)

Attaining Code Quality Excellence !

2010-03-06T02:48:00.000-08:00

Software quality has two primary dimensions: Internal Quality and External Quality. External Quality is an attribute that relates the end-user experience. External Quality can be assessed and improved through defect prevention as well as black box testing.

Internal Quality is visible to various groups in the development team such as designers, developers, maintainers and technical reviewers. Internal Quality is invisible to the end-users. Internal Quality can be improved by means of defect prevention as well as defect detection followed by analysis and correction or defect fixing. Software inspection and reviews are the means to assess, control and assure Internal Quality. Although software inspection and reviews have operational differences, both are aligned towards the objective of examining work products to unearth defects.

Great focus on black box testing by means of well-documented test cases, multiple rounds of rigorous testing, defect fixing and defect verification is mandatory for successful deliveries. However, lack of focus on Internal Quality could pose serious consequences in the form of unexpected naive defects, technical issues and maintenance nightmares. Poor Internal Quality encompasses the root causes for issues related to External Quality. Thus, in order to improve Software Quality, Internal Quality must be improved.

I could identify seven critical milestones that are necessary to attain Code Quality Excellence through experiential learning and a list of five best practices that were useful in ensuring good coding practices and assurance of Internal Quality. My second paper on Code Quality ("Critical Milestones and Best Practices for Cod Quality Excellence") provides a comprehensive coverage of these milestones and best practices.

As I wrote in my previous blog, Code Quality continues to be an unfading focus area in Software Engineering! Any thoughts?

On Code Quality

2010-03-06T02:29:00.000-08:00

Code Quality has been an unfading focus area in Software Engineering. Software inspection and reviews have been in practice in the industry for over three decades. Reviews uncover errors while they are relatively inexpensive to find and correct.

In any project, code reviews need to provide a complete coverage of the entire code base for better results. Code reviews need to focus on adherence to various factors such as

a) Content Quality:   Adherence to requirements, architecture, design, coding standards, programming principles and coding style
b) Format Quality:   Readability in terms of adequate internal comments, indentation, structure
c) Business Quality:   Alignment with business goals in terms of extensibility, maintainability, and so on.

Implementing rigorous reviews has always been a challenge in the industry due to time-to-market and budget constraints.

Roger S Pressman uses the term ‘Formal Technical Reviews’ (FTR) to denote work product inspections, reviews and walk-throughs. The motivation of all kinds of FTRs are the same – ‘ To have a work product examined by an external group of professionals so that they can unearth as many defects as possible at early stages of software life cycle.’

One of the great breakthroughs in software engineering was Gerald Weinberg’s concept of egoless programming – the idea that no matter how smart a programmer is reviews will be beneficial. Reviews and Inspections are considered to be one of the 10 best influences on Software Engineering. Defect prevention at early stages is invaluable as it enhances software quality. Code review automation saves human intervention in detecting issues related to the static nature of the code. Defect prevention and code review automation make manual reviews more effective. Refactoring is a valuable practice to improve code quality to improve the design.

Systematic Focus on Code Quality(SFCQ) is a technique to improve Code Quality and Design. It is technology independent. Besides, it is suitable for projects that follow either waterfall or iterative life cycles.

It ensures

• Improvement in code quality & hence customer satisfaction
• Constructive feedbacks and improvements in software design
• Enhanced maintainability
• Professional development in design and coding skills
• Improvement in team morale & esteem

The guiding principles of this technique are
• Increasing developers’ accountability in producing good quality code
• Improving productivity by deploying tools for code reviews
• Leveraging expertise in manual reviews to improve code quality
• Refactoring instead of reworking to make the development process more challenging

I presented my first paper on this subject during 2004. (Raja Bavani, Systematic Focus on Code Quality: A Technique to improve Design and Implementation, 5th Annual International Software Testing Conference in India 2005). Several practitioners have tried this approach and found positive results. Just thought of sharing this on this blog!

Reusability and Usability

2010-01-05T22:21:00.001-08:00

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!

___________

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

2010-01-04T00:39:00.001-08:00

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?

Customer Value Management and IT Outsourcing

2010-01-01T03:45:00.000-08:00

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.

References

Bates Collin, Forget the value of the customer to you and think about your value to the customer, Customer Management, September/October 2003
Boehm Berry, Value-Based Software Engineering: Overview and Agenda, University Of Southern California, Computer Science Department, February 2005
Boehm Berry, Turner Richard, Observations on Balancing Discipline and Agility
Favaro John, When the Pursuit of Quality Destroys Value, IEEE Software, May 1996
Gale T. Bradley, Introduction to CVA – Trends in Customer Satisfaction, Loyalty and Value, Customer Value Inc.
Highsmith Jim, Cockburn Alistair, Agile Software Development: The Business of Innovation, September 2001
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
Poppendieck Mary, Principles of Lean Thinking
Shirhattikar Gautam, Future Winners and Losers in Global Outsourcing, CHAZEN Web Journal of International Business, Winter 2005
Terdiman Rita, New Dynamics in the Application Outsourcing Marketplace, Gartner Inc Article Top View, 30 January 2003

___________