Requirements Management

Many studies out there confirm the fact that poor requirement management during software project lifetime contribute to the cancellation or failure of the project. Here are a few of them:

In “Major Causes of Software Project Failures”, one of the major failures identified is vague requirements: "You can't design a process that assumes [requirements] are stable". Also there are poorly established guidelines that determine how and when requirements can be added, removed, and implemented. "User wants and needs are two different things. What they put in a requirement document is what they want. What they want you to produce is what they need" (http://discuss.joelonsoftware.com/default.asp?joel.3.36443.16), Joel Spolsky mentioned in one of his blogs.

The well known "Chaos Report" released in 1994 by the Standish Group sites incomplete requirements and changing requirements and specifications as playing a major role in failed projects.

"Why software fails" is an IEEE article that was published in 2005 in the IEEE Spectrum Magazine, and which mentions that badly defined system requirements are one of the most common factors in software failures.

Many other studies exist, but all of them have one central message: poor requirements management leads to poor functionality of the end software, or even cancellation of the project. In order to alleviate this, we could and should manage requirements, and the best way is by using requirement management tools. INCOSE came out with a survey on such tools that can be read here. There are 38 tools surveyed; I recommend reading it if you need to make a decision on what requirement management tool to go with.

Can the current crisis help Motorola?

Is it a stretch to think that one has to undergo some kind of a crisis (spiritual, emotional, material, etc) to become the source of innovation and light? Ron Tolido's blog has some examples of just that. Motorola needs to turn around its mobile devices business (something that is clear to everybody) and this is the perfect moment to do just that.

If we think abut new phones that Motorola has come up with, one comes into mind, namely the ROKR E8. The phone uses the ModeShift technology that is proprietary to Motorola as far as I can tell. I tried finding more info about it, but with no great success, except an article on InformationWeek. You can switch between the camera, music player, or a basic phone just by pressing one button. One has only the controls they need when they need them. For example, in music player mode, you would only see controls such as play, pause, shuffle, fast forward/backward etc, all specific to what a music player should have. The phone has won CNET's Best of CES award in the cell phones and smartphones category and CNET People's Voice Award. It is clearly a big step forward that Motorola has made, and we should expect in the future to see more mobile phones from Motorola that will incorporate this technology.

One other effort has been made in the R&D category by trying to incorporate technologies and practices that would shrink the design cycle of a mobile phone from 24 months (as it was in 2003 when the project started) to 24 hours. Known under the name of "One Pass to Production", the research project is being carried out by students and researchers at Florida Atlantic University. I came on board in 2006 and was (and still am) very excited by the challenge that comes with this project. There are six critical areas that are investigated: product specification; verification; performance evaluation; software development acceleration techniques; digital six sigma; and software-hardware co-design techniques. Students are divided into groups focusing on different stages of product development in order to find ways to reduce the length of the production cycle. Currently, we believe that our current methodology, after 5 years of research, can lead to a one month design cycle. Motorola's internal evaluation puts it at 3 months. I do believe that the goal of 24 hours will be reached, and in the future, I will post more about this research project. More information about this can be found here.

I have no doubt that if continuing on this path, Motorola's Mobile Division will survive its own recession and come out stronger and more focused than before.

Google Competitions and Challenges

There are at least three challenges/competitions sponsored by Google at this moment that I'm aware of:

The Google Online Marketing Challenge involves around 21.000 students that have the chance to work with small local businesses (under 100 employees) and plan online marketing campaigns. Google offers student groups a $200 voucher to spend on Google AdWords. The competition lasts 3 weeks; students need to submit 2 reports: one before they begin the challenge, one one after the challenge is over. The winners will have a chance to visit Google Headquarters in Mountain View, California. What is positive about this is the fact that you actually gain practical experience in online marketing. The gains of the local businesses are obvious, namely more website traffic.

Doodle for Google is another competition directed towards K-12 students who have a chance to design Google's homepage logo around the theme "What if...?". Have a look at the sample doodles on the competition web page, all designed by Dennis Hwang (if I'm not mistaken), imagination is the limit. The number one national winner will win "$10,000 college scholarship to be used at the school of their choice, a trip to the Googleplex, a laptop computer, and a t-shirt printed with their doodle." The winner's school will also be awarded with $25,000 grant that will go towards improving or establishing a computer lab.

Last challenge that I am aware of is the Android Developer Challenge, where developers have a chance to design a mobile application on the Android platform, application that, if chosen, will be awarded $25,000 for further development. Those selected will then be eligible for $275,000/$100,000 awards. I will also participate in this competition, together with my wife-to-be. Details of what our application is about on how we did will be posted later on, after the challenge deadline on April 14, 2008 for the first part. I will probably have a different blog where I will talk in more details about Android, so I will not go over any details here. By the way, a new Android SDK has been released (version m5-rc14); what is on many developers mind is how this will affect their current application since during this pre-release period Google is not maintaining binary compatibility between versions.

Welcome to Google world!

Yahoo says no to Microsoft

In a news by ZDNet, Yahoo said no to the acquisition proposed by Microsoft, which offered 31$ per share, amounting to 44.6 billion dollars in stock and cash. The problem seems to be the amount of dollars per share offered by Microsoft, which in Yahoo's opinion underestimates the company in the sense that the merger might be rejected by the regulators. This is good news for Google who expressed its concerns in a blog at the beginning of February. I feel that the acquisition could have had a positive effect since the paid search revenues amount for 75% world wide, while Microsoft and Yahoo combined have 30% in the U.S., while outside the numbers are even lower, with Google having around 85% of the search market in Europe. A more tight competition could benefit everyone. Microsoft did respond with a news release by Microsoft's General Counsel Brad Smith.

The question that can be raised is could have these 'merger' benefited Yahoo?

Product Specification

In the research that my group is involved in, one part involves having structured information of different products that can be used to build a system. We were looking to see if there is a (XML-based) standard that is used by the industry to describe the products by means of capabilities, futures, interfaces etc. It was a surprise to find out that none of the companies that we looked at (Freescale, TI, SiRF, Crossbow, Marvell, AMD, Qualcomm, Atmel). Most of these companies offer data sheets in pdf format; but the properties of their components, if they are stored in a database, it would not be that hard to produce XML files containing out of them. Oracle is been doing this since 9i by means of the SQL/XML (SQLX) standard. If you want to exchange data it is more likely that you will pull out the data you have stored in your database and format it as XML. Of course one alternative is just placing the data into pdf files... I am sure that XML Component Specification will be structured in the future using the XML format. The Web Services world has its WSDL; sharing business information is done more and more using XML based standards, such as RosettaNet, XML/EDI, ebXML, eCl@ss, xCBL, OAGIS, and so many more. Unfortunately, these technologies cannot be used to describe (hardware) components because they lack in the details needed.

I mentioned using the data one has stored in databases and store it under XML format. One way to achieve this, beside using SQL/XML, is model your component using SysML, and then exporting the model into XMI or XML. The problem with this solution is that different modeling tools use different sets of tags to describe the model. Another problem is that within the tools, the format differs from one version to another.

Solving all this problems should be done by standardization. Until then, we get by with what we have.

Device Fragmentation

I was watching a video taken from the "Java Mobile & Embedded Developer Days" that was mainly concerned with device fragmentation related issues. Having to write tens, hundreds of separate builds for your application is taken a toll on the developing community and solutions need to be found in order to solve this problem. Some problems that directly affect fragmentation are multiple standards, ambiguity in the specifications, optional items that might or might not be supported/implemented on the handset.

Some (possible) solutions have been mentioned in the video. I believe the most important one is the fact that we as a community start to discuss this issue. Having talks such as the one in the video moves us forward to solving the fragmentation problem. So, what has been mentioned? Mobile Service Architecture, a new Java platform for mobile devices that comprise of different JSRs that have to be implemented/supported. Writing an application for this platform assures that you will have those functionality on other devices that support the MSA platform. This is definitely a step forward, but it only addresses the functionality available that will be constant.
Tighter specifications are also needed; ambiguity and optionality should be kept at a minimum (if not removed completely). The developer community should push harder and point out what needs to be changed in the specification to avoid future confusions/problems.
One other solution that seemed a bit to extreme at the beginning but made sense if you think about it, is have one single entity that makes the (final) decisions on the specifications. What I like about this is the notion of a more tight control that would be added. I do believe that more restrains are needed to make this work.
Technology Compatibility Kit was also mentioned as needing improvement in the sense that it needs to be dynamically and continuously enhanced with new tests. We should also force vendors to re-run test suites and make sure that the product still complies to the specification.

To sum this up, we should have all the mentioned (partial) solutions implemented and applied.
It will be a long process, but it will be one in the right direction.

What this blog is all about

Welcome to my blog!

I have been wanting to start writing thoughts on different technology information and news that I read during the week. I finally got around to creating this blog and I hope that at least once a week I will write something down.

I hope you will enjoy and maybe in time, find it useful.

Mihai