What Is Net60?

• What exactly is the .NET platform?
• How does the .NET architecture measure up against J2EE?

And, if you think more long-term, you might have a third question rattling around your head:

• What can we learn from the .NET architecture about pushing the envelope of enterprise software development?

The .NET framework is at a very early stage in its lifecycle, and deep details are still being eked out by the Microsoft .NET team. But we can, nevertheless, get fairly decent answers to these questions from the information that’s already out there.

What is it?

Current ruminations about .NET in various forums are reminiscent of the fable of the three blind men attempting to identify an elephant: It’s perceived as very different things, depending on your perspective. Some see .NET as Microsoft’s next-generation Visual Studio development environment. Some see it as yet another new programming language (C#). Some see it as a new data-exchange and messaging framework, based on XML and SOAP. In reality, .NET wants to be all of these things, and a bit more.First, let’s get some concrete details. Here’s one cut at an itemized list of the technical components making up the .NET platform:

• C#, a “new” language for writing classes and components, that integrates elements of C, C++, and Java, and adds additional features, like metadata tags, related to component development.
• A “common language runtime“, which runs bytecodes in an Internal Language (IL) format. Code and objects written in one language can, ostensibly, be compiled into the IL runtime, once an IL compiler is developed for the language.
• A set of base components, accessible from the common language runtime, that provide various functions (networking, containers, etc.).
• ASP+, a new version of ASP that supports compilation of ASPs into the common language runtime (and therefore writing ASP scripts using any language with an IL binding).
• Win Forms and Web Forms, new UI component frameworks accessible from Visual Studio.
• ADO+, a new generation of ADO data access components that use XML and SOAP for data interchange.

How do .NET and J2EE compare?

As you can see, the .NET platform has an array of technologies under its umbrella. Microsoft is ostensibly presenting these as alternatives to other existing platforms, like J2EE and CORBA, in order to attract developers to the Windows platform. But how do the comparisons play out item-by-item? One way to lay out the alternatives between .NET and J2EE is shown in the following table:

The comparisons in this table only scratch the surface. Here’s an executive summary of .NET vs. J2EE:

Features: .NET and J2EE offer pretty much the same laundry of list of features, albeit in different ways.

Portability: The .NET core works on Windows only but theoretically supports development in many languages (once sub-/supersets of these languages have been defined and IL compilers have been created for them). Also, Net’s SOAP capabilities will allow components on other platforms to exchange data messages with .NET components. While a few of the elements in .NET, such as SOAP and its discovery and lookup protocols, are provided as public specifications, the core components of the framework (IL runtime environment, ASP+ internals, Win Forms and Web Forms component “contracts”, etc.) are kept by Microsoft, and Microsoft will be the only provider of complete .NET development and runtime environments. There has already been some pressure by the development community for Microsoft to open up these specifications, but this would be counter to Microsoft’s standard practices.

Read more on the .NET platform in this in-depth interview by O’Reilly Windows editor John Osborn: Deep Inside C#: An Interview with Microsoft chief architect Anders Hejlsberg–John gets to the bottom of not only Microsoft’s detailed plans for the C# programming language but also the .Net framework.

The Bigger Picture

These last points highlight some of the key differentiators between .NET and J2EE, and point towards Microsoft’s real play here. Microsoft is doing two very notable things with .NET: It is opening up a channel to developers in other programming languages, and it is opening up a channel to non-.NET components by integrating XML and SOAP into their messaging scheme.By allowing cross-language component interactions, .NET is enfranchising Perl, Eiffel, Cobol, and other programmers by allowing them to play in the Microsoft sandbox. Devotees of these languages are particularly amenable to gestures like this, since for the most part they have felt somewhat disenfranchised and marginalized in the Microsoft/Sun/Open Source wars. And by using XML and SOAP in their component messaging layer, Microsoft is bolstering their diplomatic face and adding an element of openness to their platform, providing ammunition against claims of proprietary behavior.

What’s the correct response?

For Microsoft developers:.NET is a good thing for those of you committed to Microsoft architectures. ASP+ is better than ASP, ADO+ is better, but different, than ADO and DCOM, C# is better than C and C++. The initial version of .NET won’t be real until sometime in 2001, so you have some time to prepare, but this will undoubtedly become the default development environment for Microsoft platforms. And if you’re developing within the Microsoft development framework now, you will undoubtedly benefit from adopting elements of the .NET framework into your architectures.

However, several of the goals of the .NET platform are fairly lofty and not at all guaranteed to fly, at least not in the short term. The IL common language runtime, for example, has some fairly significant hurdles to overcome before it has any real payoff for developers. Each language that wants to integrate with the component runtime has to define a subset/superset of the language that maps cleanly into and out of the IL runtime, and has to define constructs that provide the component metadata that IL requires. Then compilers (x-to-IL and IL-to-x) will have to be developed to both compile language structures (objects, components, etc.) into IL component bytecodes, and also generate language-specific interfaces to existing IL components.

There is some historical precedence here. Numerous bridges from non-Java languages to the Java VM have been developed, such as JPython, PERCobol, the Tcl/Java project, and interestingly enough, Bertrand Meyer and some other Eiffel folks put together an Eiffel-to-JavaVM system a few years back. With the possible exception of JPython, these tools have not been widely adopted, even within their respective language communities, even though they seem to offer a way to write code for the Java environment (albeit not the entire J2EE framework) using your favorite language. Why this lack of enthusiasm? I believe it’s because people are hesitant to take on the headaches of adding yet another translation step from their development language to the target framework. If the Java environment is the goal, people will generally choose to learn Java. I predict that the same will be true of .NET: People will generally choose to learn C# and write .NET components in that language.

Another caution: Beware of performance issues with .NET’s SOAP-based distributed communications. SOAP essentially means XML over HTTP. HTTP is not a high-performance data protocol, and XML implies an XML parsing layer, which implies more compute overhead. The combination of both could significantly reduce transaction rates relative to alternative messaging/communications channels. XML is a very rich, robust metalanguage for messaging, and HTTP is very portable and avoids many firewall issues. But if transaction rates are a priority for you, keep your options open.

For the Java and Open Source communities:

It would be easy to dismiss .NET as more Microsoft marketing-ware and continue on your merry way. But don’t. .NET is a sign of a subtle but significant shift in Microsoft’s strategy to evangelize their platforms. They have been fighting alternative frameworks and platforms at the management level pretty well, touting the usual questionable “statistics” about cost of ownership and seamless integration. Now they are fighting Java and open source initiatives on their own terms, putting their own spin on “open” and attempting to directly address the needs of developers, two things that they have been faulted for not doing very well in the past. If you consider yourself an evangelist for Java or open source platforms, then the nature of the war is changing. Be prepared.

Also, Microsoft’s IL runtime has at least one notable, if improbable, goal: eliminate the programming language as a barrier to entry to the framework. Java eliminates the platform barrier (within limits, of course: You can’t make up for missing hardware resources with software, for example), but in order to work in J2EE, you have to work in Java. .NET wants to let you use the language of your choice to build .NET applications. This is admirable, though there are big questions as to whether and when the IL approach in .NET will actually become broadly useful (see above). Regardless, this points to a weakness in the single-language J2EE approach. The importance of this weakness is questionable, but it exists nonetheless, and deserves some consideration by the Java community. If this is really desired by developers, then maybe the efforts in Java bytecode generators for non- Java languages should be organized and consolidated.

Focusing on J2EE, there are a few issues that should be addressed immediately in order to bolster the advantages of that platform compared to what .NET is shooting for. First, XML support needs to be integrated seamlessly into the framework. I’m not talking about bolting an XML SAX/DOM parser to the set of standard services, or extending the use of XML in configuration files. XML messaging and manipulation need to be there, ready to use. Admittedly, you can use XML payloads on top of JMS messaging, but the platform doesn’t facilitate this at all. The XML space is a cluttered mess of standards, de facto standards, APIs and DTDs, which is to be expected when you’re dealing with a meta-language.

But Microsoft has put a stake in the ground with SOAP, and they’re pushing hard to put something understandable and useful in the hands of developers. J2EE proponents need to do the same with their platform. One possibility that comes to mind is to add an XML messaging “provider” layer on top of JMS, along the lines of the pattern followed by Java Naming and Directory Interface, or JNDI, with LDAP, NIS, COS Naming, etc. This in combination with a standard SOAP/BizTalk provider, an ebXML provider, etc. would be an impressive statement.

Clarifications and Corrections

Since the publication of this article in August 2000, 40 readers have responded with their own thoughts about .Net vs. J2EE. Jim Farley, the author of this article, has sifted through those comments, as well as email he’s received, and added the following clarifications and corrections.

Clarifications

The description of C#’s compilation features vs. those of Java seems to have confused some readers. To put it another way: C# code always runs natively. Java code typically runs as interpreted bytecodes, and can run natively. C# is either compiled entirely to native code, or it is compiled into the common language runtime bytecodes and then just-in-time compiled to native code during execution. Java code, on the other hand, typically runs as runtime-interpreted bytecodes (from which its cross-platform abilities spring), and can also run in a just-in-time compiled context. Some Java native-code compilers also exist (Jove, BulletTrain, JET, etc.).As a side note, Microsoft claims that the default interpretive mode of Java is a liability, in that bytecodes designed for a virtual machine do not lend themselves as well to native optimization. I haven’t seen any hard data to prove or disprove that claim, either generally (bytecodes vs. native-compiled languages) or specifically (Java vs. C#).

Several readers, in response to the call to include XML support in J2EE, mentioned the fact that J2EE 1.3 (currently in public draft) requires that any J2EE-compliant product must include Java XML SAX and DOM parsers. But this is just “bolting an XML SAX/DOM parser” to J2EE, as I mentioned. I was calling for it to be taken a step farther, to incorporate XML support directly in the J2EE support APIs. Ideally, J2EE-based components and services would have XML support (for messaging, interface description exports, etc.) automatically built-in, to some extent.

Corrections

I state in the article that C# “borrows some of the component concepts from JavaBeans.” This statement can’t be proven, and, as several readers pointed out, it’s more likely that Microsoft based the component functionality of C# more on their own COM and VB models, with influences from other pre-existing component models. Jim Farley is a technology architect, strategist and IT manager.

<source: http://www.oreillynet.com/pub/a/oreilly/java/news/farley_0800.html>

But Claudia Radasanu, senior vice president of development services, says the Toronto-based financial institution must now investigate the rival .Net environment that Microsoft Corp. launched in February – even though her firm made a huge investment in IBM’s Java-centric WebSphere application server and has no immediate plans to make costly changes.

“What if the total cost of ownership is lower on .Net? You always have to ask the ‘what if,’ ” Radasanu says.

Corporations will find it tough to settle on a single development architecture such as .Net or Java 2 Enterprise Edition (J2EE), “unless they are the size of a dentist’s office,” says Yefim Natis, an analyst at Gartner Inc. in Stamford, Conn.

Mixed environments of mainframes, Unix, Windows and proprietary systems will drive most enterprises to use both J2EE and .Net, particularly if they’ve been involved in mergers and acquisitions, some analysts say.

“The question is not whether J2EE or .Net is the better architecture,” Natis says. “The question is, How to integrate them, how to make them work together, what are their strengths and weaknesses?”

Some IT shops may use .Net for some types of new projects and Java for others. Others may explore using .Net for the presentation layer, to take advantage of Microsoft’s client-building tools, or to connect to Java-based business logic via XML-based Web services or a Java/Microsoft bridge.

Whatever the choice, Randy Heffner, an analyst at Giga Information Group Inc. in Cambridge, Mass., recommends that corporate users decide on a primary platform and use “a containment strategy” for the other platform. He says that will allow an IT department to get greater synergy of development, operations and application management skills.

The following are some points that IT managers should consider when weighing the choice of .Net vs. Java:

1. Weigh the importance of application portability to your company. Java may not have entirely lived up to its “write once, run anywhere” promise. But Heffner says J2EE portability tends to be good for core components such as business rules, Java Server Pages and Enterprise JavaBeans.That, in turn, gives corporate users the negotiating leverage to present “a credible threat” that they’ll move an application to another vendor’s platform, something they can’t do with Microsoft, because the .Net framework runs only on Windows, he says.

   Microsoft submitted a portion of its .Net framework to a standards body, but Heffner estimates it amounts to only 10%, or “just enough for an application on some other platform to connect to a Microsoft server environment.” Although there are open-source efforts to get .Net to run on other platforms, none are credible yet, he adds.

   Portability has never been a concern for Microsoft, which advocates writing applications optimized to run on Windows for higher performance. Claiming that interoperability is more important than portability, Microsoft now tells users that .Net-based applications can share information with applications running on other platforms through Web services, in which XML-based messages are sent via the Simple Object Access Protocol.

   Bob Dutile, a senior vice president of enterprise architecture at Cleveland-based KeyCorp, says he’s interested in Microsoft’s approach, but he wants the option of selecting a best-of-breed server. “One of the reasons we are a Java shop is because Microsoft was too proprietary,” he says. “We like to have the opportunity not to be locked into one vendor all the time.”

2. Take stock of your existing developer skills and infrastructure.Training developers and ripping out existing infrastructure can be costly, so an IT shop may favor sticking with the development environment that best fits its current situation.Pacific Life Insurance Co., for instance, didn’t hesitate to adopt .Net technology. Brad Sewell, an assistant vice president in IT at Newport Beach, Calif.-based Pacific Life, says his life insurance division didn’t consider Java because the division is “pretty heavily invested in Microsoft infrastructure.”

   The Home Depot Inc. in Atlanta, in contrast, is primarily a Unix shop and made a significant commitment to Java early on. But the decision wasn’t based solely on its Unix focus. “Java ran equally well on all of our hardware,” says senior IT manager Curtis Chambers, noting that his company also uses Windows, MVS and z/OS. “The end goal was a common development platform for all of our developers.”

   Because of .Net’s Windows-only limitation, Thomas Murphy, an analyst at Stamford, Conn.-based Meta Group Inc., says that for Unix shops, “the decision’s made for you.”

   “If you’re a mixed shop, you have to look at how you are mixed,” he adds.

   Murphy says IT managers should ask questions such as: Is Unix just the database platform, or does it have a role beyond that? How are you going to attach to legacy resources? Or are you going to try to develop new business logic on the legacy platform?

   Microsoft’s .Net environment allows developers to program in more than 20 languages, including Cobol, which could appeal to programmers who have worked in legacy environments. But since their .Net applications would need to run on Microsoft’s Common Language Runtime, they must weigh the infrastructure consequences.

   Developers skilled in using Microsoft’s Visual Basic tools for building less complex applications will find a similar learning curve whether they shift to Visual Studio .Net or J2EE, if they’re taking on full distributed computing and object-oriented programming, warns Frank Gillett, an analyst at Forrester Research Inc. in Cambridge, Mass.

   Whatever switch is made, it costs money. Gartner analyst Joseph Feiman says a Cobol-to-Java move, for instance, can cost an average of $57,000 per developer, once training costs, time, initial lost productivity and risk are factored into the equation. But he notes the costs can vary significantly, depending on programmers’ skills and the type of change they’re making.

3. Assess the complexity of the applications you will be building.Microsoft tools have an edge over Java for building applications that require rich graphical user interfaces and that deliver content to Web browsers, analysts say. Although Java tools are improving, Microsoft’s tools are generally considered easier to use.Heffner says there are “more knobs to turn” in a J2EE environment. But for complex, high-volume applications with lots of business rules, “that’s just the sort of knob-turning you need available,” he says. Those types of applications need to be more highly architected, and J2EE has more features to offer for session management, fail-over and load balancing than the Microsoft architecture does, Heffner says.

   For now, analysts say, J2EE may continue to be the preferred choice for highly scalable, mission-critical applications, and .Net may make more sense for applications that need a low-cost, quick turnaround. Natis says Gartner is advising clients to wait for .Net’s next release before they consider using it to build an application that will go beyond 1,000 concurrent users.

4. Investigate outside vendor support. Murphy says that users who buy major packaged applications will probably be driven to gain some Java skills, since enterprise software vendors such as SAP AG and Oracle Corp. lean toward Java.Another consideration may be the tendencies of the independent software vendors that develop applications for a particular vertical industry. Heffner says one insurance company chose J2EE because five of its six peers did.

   Analysts also note that tools and components may be more readily available for Java now, since .Net is so new. However, Microsoft, has already put out a thick binder entitled “.Net in the Real World,” featuring early adopters.

5. Compute costs with care. On a straight cost basis, Microsoft presents an appealing option. Its Windows server operating system ships with a built-in application server, while pricing for the most popular Java-based application servers starts at $8,000 to $10,000 per CPU.There are other options. Hewlett-Packard Co., for instance, ships a free application server with its operating system, and JBoss is an open-source alternative, analysts say. But the top two choices, by far, have been San Jose-based BEA Systems Inc.’s WebLogic or IBM’s WebSphere.

   Rather than simply looking at the costs of application servers, Heffner advises clients to use a total economic impact model that takes into account costs, benefits and flexibility for future options. “In this case, you’re making a strategic platform decision that will affect not only this one application; it will affect the stream of application delivery that you’re going to pursue as a company over the coming years,” he says.

<source: http://www.computerworld.com/developmenttopics/development/story/0,10801,71221,00.html>

Java and Microsoft .NET offer more than just object-oriented programming languages. They provide a framework and platform for building enterprise-level software, complex applications whose architecture may be separated among multiple tiers and be comprised of many distributed components. Java and .NET, as it turns out, are very similar in many respects, in terms of their runtime architecture, toolsets, and even language syntax. I would like to state, before going any further, that I think both .NET and Java have proven themselves worthy candidates for delivering enterprise software solutions. That does not mean that one does not fit better in some instances than others. Look at some areas that I think should be considered when making an informed decision between the two of them.

Existing Infrastructure

Are you a Windows-only shop? Or, are you running Windows right alongside Linux and even some Unix systems? If the former is the case, .NET becomes a very appealing option, of course. You’ve already standardized on Microsoft technology and .NET is the future of development for Microsoft-centric applications. For heterogeneous environments, or if you are writing commercial software and looking for the widest possible customer base, a strong case can be made for Java. Java’s promise of write-once-run-anywhere holds true, for the most part, and can be an important factor in your decision. Of course, when building Java applications, it is important to be mindful of any vendor-specific enhancements you utilize as they will most certainly not be portable.

Existing Relationships

What current vendor relationships do you have? As mentioned previously, if you have a close relationship with Microsoft and that relationship has worked out well for you, it might make sense to stick with what has worked in the past and proceed with .NET as your development platform. This would also apply to vendors such as IBM and Oracle, who promote Java technology through their tools and application server offerings. With .NET, you will inherently tie yourself closely to a single vendor. That is, Microsoft. With Java, there are numerous vendors to choose from, each offering their own tools and server software.

Cost and Flexibility

Cost is always a factor. Having said this, there are many ways to evaluate cost and it is not just the initial price tag for an application server or a per-seat license for an IDE (Integrated Development Environment). A large choice in vendors can provide greater flexibility and the ability to lower costs. In recent years, open-source software has gained significant traction within organizations. For example, there are many good open-source Java application servers out there. There are also many Java applications servers with a price tag that far exceeds the Windows alternative. It’s not to say that these commercial application servers are not worth the money and that they may not provide real value over their open-source competitors. When adopting technology, one also must consider support. Going with .NET or a vendor of commercial Java products will include support. Open-source offerings often will provide some kind of support package, but this will cost money. If open-source is appealing to you, you will find that Java is the clear leader in this area. However, there should be some structured approach to what and how open-source products are utilized in your organization.

Ease of Development and Maintenance

Now, look at .NET and Java from a software developer’s perspective, the individual who will create and maintain that software for years to come. It has often been suggested that developing with .NET is easier than Java. In truth, I think there is at least some merit to this argument. One obvious reason for this is that you are dealing with one vendor and that vendor’s set of tools. In the world of Java, it is, quite simply, easier to become overwhelmed by the different offerings, from IDEs such as Eclipse and NetBeans, to web application frameworks such as Struts and JSF (JavaServer Faces), and to the numerous application servers available. It is true that Sun Microsystems, the owner of Java, helps to drive standards through specifications. The JSF framework, for example, is based upon a standard specification to which all vendors offering JSF tools and components must conform. However, numerous popular open-source frameworks are decidedly non-standard, even if they are popular in the development community. It’s a big job to digest everything that’s out there and available in the world of Java, and it can be time-consuming.

Development shops that choose Java are well served to implement some kind of in-house standardization. I am not talking about coding standards, though that is a good idea too, but standards in terms of which frameworks, toolsets, and servers are permissible in your organization. These restrictions will eat at those Java developers who crave the freedom of choice above all else, but it will help to minimize training costs, reduce maintenance headaches, and help to focus you on what is truly important: building software that delivers business value.

A New Reality

Finally, it should be noted that with the emergence of SOA (Service-Oriented Architecture) through the use of web services and more, some of the worry over making the wrong technology choice should be eliminated. Standards such as SOAP allow Java and .NET applications to interact quite nicely, whether they be two systems across the globe, or in another department on the same floor where you work. With this in mind, any application providing important business functions should consider what services they can make available to others, regardless of the technology they are based upon.

Conclusion

Deciding between .NET and Java is not always an easy decision and requires careful consideration. The upside to this is that you have two powerful and proven technology foundations to choose from for creating world-class software.

About the Author

Michael Klaene is a Principal Consultant with Sogeti USA. He has over 10 years of experience in IT, and specializes in J2EE, .NET, and Oracle design and development.

<source: http://www.developer.com/java/ent/article.php/3766471>

Nokia is rather proud of their efforts with Web Run-Time, a system for developing applications for S60 using web technologies. Ewan takes a look at why they are so proud, and what it means for the developer experience on S60.

Last week’s S60 Summit from Nokia provided, as always, an interesting look into what the S60 team think are the important medium and long terms issues for the S60 platform. It’s not the short term “we’ve got a new phone” sort of conference, although Samsung did take the opportunity to announce the rather spiffy L870, but rather a chance to explore topics around the current and future development of S60 as a software platform.

It’s clear that expanding the opportunities for developers and communicating their availability is a key area. This ongoing effort goes much further than nurturing the existing developers, it aims to enable new technologies and developer environments on the platform (Web Run-Time, Flash Lite, Open C++, Python) to make it easier to get applications onto the S60 platform.

Notable mentions at the S60 summit included the expansion of Open C with ‘Open C++’, further building on the cross platform standard (Linux alike) C/C++ APIs. There was a seminar on Adobe’s Open Screen Project, which outlined the strategy of a cross platform software development environment built on Adobe’s Flash and Air technology. In the expo hall, Flash Lite started to show signs of real maturity with several companies showcasing applications and service solutions. Python, which has gained a strong following in academic institutions, was also mentioned as popular option for rapidly prototyping applications. However what S60 were pushing hardest, and for which they have the highest hopes for the future, is Web Run-Time (WRT). This is a browser-based run-time environment that allows developers to use key web technologies (HTML, Javascript and CSS) to create applications (also known as widgets) for the S60 platform.

There’s every chance that all these names and soups of initials will mean little to the average user – and to be honest that’s exactly as it should be. Developer environments and runtimes are really only of interest to developers – what matters to the consumer is the experience. The last thing S60 needs is end-users having to add in environmental variables, packages and extensions. That’s the advantage of building these technologies into a platform-aware way. It means the right elements can either be packaged in the installation files, e.g. the Python run-time, or present in the phone’s firmware, as is the case with WRT. With all the run-time environments on S60, the intention is that, to the end-user, they should look the same – they all have application icons and behave in the same way.

As we mentioned, WRT is powered by a number of web technologies; in essence, as with all web-based applications, HTML and CSS provide the application UI and styling while Javascript provides the application engine. In the case of WRT there are a few extra components to tie into into the S60 platform. Firstly, there are a number of custom Javascript API calls which allow access to phone services and functionality, secondly there’s a ‘plist’ file and icon which describe the application and govern the way (name and icon) it appears in the S60 application launcher.

The first iteration of WRT, announced last year, had relatively few Javascript API calls – access to keypad tones, vibra functions, network status and battery status – and consequently the resultant widgets are little more than a web page accessed via an S60 application icon. There are some good uses cases for this type of widget, particularly as a simple access client for web services (e.g. returning stock quotes or train times), but there are some fundamental limitations. The key advantage provided by this first version of WRT was to enable developers to put an icon into the S60 application launcher rather than existing purely as a bookmark in the browser.

The second iteration of WRT, announced at Web 2.0 this year, was a key focus at this year’s S60 Summit. It greatly expands the number of Javascript API calls available. WRT will be able to access numerous phone services, such as the camera, GPS (for location), and the calendar and contact stores. This means that it will be possible to create widgets that are much more tightly integrated into the phone to the extent that they start to become much more like applications than individual web pages.

Nokia was keen to stress two key areas that the new version of WRT would enable. The first is context awareness – this is the idea that phone can make available additional information (context) to web services. The most obvious example of this is location information (e.g. location-aware cinema search), but also extends to presence (calendar information) and contact information (who do you know). Combining these together, you could create a widget that looked up film times at your nearest cinema, checked you were available at the appropriate times, offered to book the tickets and then alerted friends to join you. Secondly,  the new version enables the creation of mashups between the phone and web services (as distinct from mashups between web services), or put another way, web services that can interact with, and insert information into, the phone. Building on the example above, a widget could insert the film times into your calendar and the contact number into your address book.

A key point in favour of WRT is that it changes the economics of development. At the S60 Summit, several demo stations had widgets on display and there was a clear consensus from the developers that WRT enabled faster development. In the case of Muzeeker, a prototype was up and running in a few hours with a more polished version taking just days. This compared to the Java version that had taken several weeks to put together. Also of note was the fact that WRT will not require certification through Symbian Signed. Instead a similar model to Java ME will be adopted - user prompts will be displayed before accessing phone services or private information. This can potentially run in several modes (controlled by a security policy file): ask once, ask once each session or ask every time. The exact policy implementation will be dictated by each manufacturer on a device by device basis.

WRT will likely continue to develop indirectly too. Since it’s browser-based, some of the plug-in browser teachnology will be available to WRT. This is already the case for Flash Lite and future possibilities include future Adobe run-time developments (Air) and, when it arrives on S60 later this year, Microsoft’s Silverlight.

WRT is not without its problems – possibly the most important is that of fragmentation. Mobile widgets are a young technology and consequently there are no standards. Both OMTP and W3C are working in this area, but there are already a number of mobile widget platforms out there: Opera Widgets, Widsets, Plusmo, Yahoo Go Widgets, and so on. Although these are all based on the same web technologies, they often take different approaches. This means the web as a platform on mobile faces fragmentation issues. The use of Javascript API calls, which are currently specific to S60 within WRT, only adds to the problems in this area. Arguably S60 makes up a big enough chunk of the market on its own for WRT development to be viable, but it does feel like a missed opportunity. It is worth bearing in mind that there’s not really anything that S60 or the WRT development team can do about this – reality dictates a ‘build first, standardise later’ approach.

But in the end what it comes down to is that WRT may be the right technology and released at the right time.

In principal there’s nothing fundamentally different to building a WRT widget than there is in coding a web site. Put another way, if you can put it on a web page, there’s no reason why you can’t make it an S60 application. How many S60 Symbian OS developers are there, and compared to how many Web Developers? The answer now is that the numbers are the same! – They just don’t know it yet. There is a strong argument to be made that it is tapping into this resource that will significantly help drive a mobilisation of Web 2.0 content and services.

The architecture of Web 2.0 (open APIs) makes it easy for third parties to access and utilise content and services. For example, why open the web browser, go to your bookmarks, log in to Twitter, type in your latest message and hit send, when you could create a Twitter post widget? This is a rather simple example, but that’s the power of the web-based widget, and that flexibility, scale, and ease of development is what Nokia are targetting.

Existing developers should not feel threatened by all these new tools. There is of course ongoing support for the ‘low level’ languages of Open C and Symbian C++. It will remain the development environment of choice when looking for maximum performance or lower level integration and API calls. It is no different between the relationship Symbian C++ and Java ME have had over the years. In contrast to the early days of Symbian, Java ME has greatly matured and, thanks to JSRs, now has much richer functionality. The situation between the two languages is always something of a moving target – if you want to use cutting edge technology then C++ is the only choice, but what is considered ‘cutting edge’ changes. Today’s cutting edge C++ is tomorrows JSR. That said, it’s also possible to see a progression of technology throughout an application’s life-cycle. Google Maps is a good example; it started as web service, was made available as a Java application and later made the move to Symbian C++.

Ultimately, each language or run-time environment is suited to certain tasks. WRT is just one more post in a continuum of developer options. You will not see WRT used to create full blown word processors or complicated 3D graphical games. However, with the web as an application platform becoming ever more prevalent, having a quick and easy way to bring them to the mobile world has great potential benefits. At the S60 Summit, Lee Williams underlined this when he talked about how the Internet is driving innovation in technology and creating compelling user experiences and how this matched up with the challenges ahead for S60 (enabling innovation and creating compelling user experiences). It is this convergence between Web 2.0 and Mobile that has provided much of the impetus for WRT and explains why Nokia is heavily promoting it.

For all this enthusiasm for web technologies, it is still early days for WRT. There are currently only fourteen devices which are WRT-enabled (and some of these need firmware upgrades), so it’s not yet the global option for developers in the same way that Symbian C++ or Java ME are. However, this will change quickly. WRT is a standard part of S60 3rd Edition Feature Pack 2, albeit in its first iteration. Given its capabilities, I suspect, the second iteration of WRT will be what really drives uptake. It will be a standard part of the next version of S60 and seems like an ideal candidate for a back port to FP2 phones.

Developers should therefore watch this technology carefully; this is a hot area which is rapidly evolving, but it is also important to keep expectations realistic. Of course, for the end user, the reasons for Web Run-Time are much simpler – better experiences and more applications. For manufacturers, it’s another potential differentiator and platform advantage provided by S60. It seems to be a win-win situation all round.

<source: http://www.allaboutsymbian.com/features/item/The_Wonderful_Widgetised_World_of_Web_Runtime.php>

INTRODUCTION
Traditional methods were suitable for software development in the past when software systems were small

and uncomplicated. Nowadays, software systems are more and more complicated so traditional methods have several limitations. These limitations reduce the success of software projects. Unsurprisingly, the statistics of software projects shows that the success percentage is very low with less than 20% chances. Most traditional methods consider the software development process as fixed process and it is predictive [5]. At the beginning of a project, project managers laid out the whole development lifecycle from the unchangeable requirements and try to make a schedule to follow. In this process, the software is done through five phases: analysis of requirements, design, implementation, testing, and deployment. During the process, the customer can not change their requirements. Another limitation of traditional methods is a long development process which leads to more risks. Agile methods to software development were introduced in the 90s. These methods brought out some principles to solve above limitations of the raditional methods. They were considered as “lightweight” methods while traditional methods were considered as “heavyweight” methods. The main nature of agile methods is to develop rapidly software systems and to satisfy changing requirements. A new version can be released within less than two months. In the case of agile methods, customers are required to work alongside with other team members. They can make any changes in requirements during the development process. Agile methods are appropriate for projects with small teams which include senior developers with face to face communication so a few documents are released. When customers make any change, a simple design plan document is made and senior developers implement the program in short time. Testers test results from developers immediately and directly give feedback. With such process, software is developed very fast. In agile methods, software is developed in an incremental process with a lot of iterations. Each iteration includes necessary phases to make a complete product. It means that software is done through following phases: Analysis of requirements, Design, Implementation, and Testing. These iterations are very short, only from two weeks to two months [1]. The development process stops when customers do not make additional requirements.
There are several software development processes in agile methods such as Extreme Programming, Scrum, Crystal family of methodologies, Feature Driven Development, The Rational Unified Process, Dynamic Systems Development Method, Adaptive Software Development, and Open Source Software Development. They are different in their practices but have common characteristics. We will provide an analysis on agile methods which are based on the principles of the Agile Manifesto (http://agilemanifesto.org), our experience about Extreme Programming, Scrum and other methods in the family of agile methods, and some other relevant papers. Our survey uses a theoretical approach. After analyzing them in the software engineering point of view, we will further discuss the advantages and disadvantages of these methods, and
how to extend them. The structure of the paper includes four sections. In the following section, we will describe twelve principles in Agile Manifesto introduced by Agile Alliance on which we base our analysis. The third one is the main part in which we will analyze on the advantages and disadvantages of these methods, and propose some ideas to extend them. The last section is our conclusions.

THE PRINCIPLES OF AGILE METHODS
In the early stage of the development, there were confusions about what was considered as one of the agile

methods. Therefore, in February, 2001, seventeen people met to find out the common principles of agile methods. The result from the meeting is the establishment of the Agile Alliance (see http://agilemanifesto.org/history.html). All members agreed on principles described in the manifesto of  agile software development. These principles cover the main characteristics of agile methods. They are
listed and briefly explained below:

1. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. The most important purpose of agile methods is to satisfy the requirements of the customer at highest level. A software product is developed rapidly in short iterations. In each iteration, it is adjusted and developed to meet new requirements from the customer.
2. “Welcome changing requirements, even late in development. Agile processes harness change for the
customer’s competitive advantage”. The customer is encouraged to work along side software developers and make any change in requirement specifications.
3. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”. A new version is released in a very short time. One of the most important characteristics of agile methods is to develop software products as fast as possible.
4. “Business people and developers must work together daily throughout the project”. In order to make software products agile, requirements from the customer are changed to developers as soon as possible. Hence, customers, stakeholders are required to work along side developers during the development process.
5. “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”. In the case of agile methods, people are considered as the most important factor of success. Developers have all possible supports to concentrate on programming software products.
6. “The most efficient and effective method of conveying information to and within a development team is face-toface conversation”. Face-to-face communication is one of the most important factors to ensure the rapid development of software products. Developers, stakeholders, and customers are working together in small teams, for example, from 10 to 30 people in a team, so people talk each other, no need to create documents.

7. “Working software is the primary measure of progress”. When estimating the progress of a project, they does not estimate the amount of source codes they have created or the volume of documentation they have written, they estimate the amount of software that is working.

8. “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”. Developers are required to have a stable working process from the beginning to the end of a project. In any phase, they must ensure the high concentration on their tasks. They should not work hard in some phases but they are tired in later phases.
9. “Continuous attention to technical excellence and good design enhances agility”. The high quality of tasks which were done leads to high speed. If the quality of source codes is high, developers do not waste time to redo their tasks.
10. “Simplicity–the art of maximizing the amount of work not done–is essential”. A software product is done through several iterations so developers do not care about the whole architecture in each iteration. They only care how to finish new functionalities for the product in this iteration.
11. “The best architectures, requirements, and designs emerge from self-organizing teams”. In agile  methods, developers are assigned into small self-organizing teams. Responsibilities are shared between
members. No single member is responsible for architectures, requirements or designs. Each member has
responsible for all aspects of a project.
12. “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly”. Requirements, architectures, tasks are changed very often so members must change to adjust to the continuously changing environments.

ADVANTAGES OF AGILE METHODS
Five advantages are discussed as follows. We analyze them from the software industry point of view and highlight these advantages by comparing with traditional methods.

Rapid software development
Software systems are developed in an incremental process with several iterations. Each iteration includes necessary phases to make a complete product such as: analysis of requirements, design, coding and testing. It means that a new version is released after each iteration. The third principle of the Agile Manifesto said that the duration of each iteration is only from two weeks to two months. In the case of the XP method, a new version is released in no more than two months and with Scrum method, the duration

of each iteration is from one week to one month [1]. It is shorter than these of spiral or incremental processes in traditional methods. The very short release is the main characteristic to distinguish a software process in agile methods with an incremental process in traditional methods. We can make short releases with agile methods because of the following reasons. Firstly, the customer is required to work alongside members of team. Therefore, developers have information about changes in requirements in a short
time and throughout face to face communication. Secondly, the tenth principle emphasizes “simplicity”. It means that the design plan is simple. Hence, programmers can implement it rapidly. It is not necessary to make a complex design plan because the product will be done through other iterations later. Thirdly, all members are in small environments with face-to-face communication so tasks are rapidly moved to next phase. For example, testers test what programmers have done after a few minutes and give feedbacks. Last but not least, team includes senior members with much experience on the area of project so they can
finish tasks in a short time. The fast development of software is very important in software industry nowadays. It saves a lot of money, minimizes risks, and so on. The long development process can not bring the benefit for products as other ones are developing with a rapid speed. Software technologies are improved extremely fast. For this reason of long development process, when the product is finished, it is
already obsolete and can not compete with other products.

High customers’ satisfactory level

Agile methods encourage changing requirements from customers, even in the end of development process. It is an important criteria. Consequently, it is introduced in the first and the second principles of the Agile Manifesto. The development process in agile methods supports this requirement changes. Customers work daily with other members in the team. They can make any changes in requirements during the software process. The purpose of creating a new iteration is adding new functionalities for software which satisfy new requirements. They themselves write functional tests at the end of each iteration. Because of this, the latest version meets what customers need at the highest level. In the development process, they still continue think about new changes. The development process only stops when customers do not require any
change in requirements. It means that the final product has all functionalities which the customer wants. In the case of XP method, the customers write what they want to be included in their product in story cards. Each story card describes a feature of program. Customers decide stories to be done in each iteration. In Scrum method, a product backlog list includes all requirements from the customer. They create, change, update or do whatever they want in this list. After a short time, a new iteration is created to implement product with updated changes in requirements. This advantage plays an important role in the improvement

of software quality. We can only benefit from a product if customers satisfy with it and then pay for it. As we knew, most of software developed by traditional methods does not fully meet he customer’s requirements. In the case of these methods, software is developed through five phases. In the first phase, customers provide information about the product what they want. Analysts and designers analyze these requirements and design the product. The process is fixed and the customer can not change their requirements.
Risk minimization
The development process in agile methods is an incremental process with a lot of short iterations. Hence,
software is developed more and more complicated after each iteration. In addition, it is done throughout all
necessary phases in each iteration. For this reason, risks are reduced a lot. The characteristics of agile methods are developing software in small teams with face to face conversation. In such small environment, the conveyance of information is quick. When risks are identified, they are quickly given to members who have responsibilities to fix them. In XP method, pair programming is used in release phase. Two programmers work together so they can support each other. Risks are easier to identified and eliminated. Furthermore, feedbacks are given in a short time so programmers get solutions from risk managers soon [1]. In the case of traditional methods, there are some limitations in solving risks. Most of projects have problems with risks. Some risks are significant so they must decide to cancel the project. The limitations are from the long and fixed development process with poor communication. Developers detect risks but they often do not know how to change your reports. Sometimes, we must change something in the development process to fix those risks but this is unable in traditional methods. In contrast, this can be
done easily in agile methods. For example, in the term of Scrum method, the development phase is treated as “black box” [1]. They include a lot of environment and technical variables which are changeable.

Improvement in the effectiveness of development process

The effectiveness of development process affects the software quality very much. By using agile methods, the effectiveness of the process is higher. Face to face communication reduces waiting times. Designers get new changes in requirements from the customer in short time. Programmers also get feedback from testers quickly. The customer can see product at the time when it releases. In this case, if a member does not understand about what other members are doing, he can ask immediately. This thing can not be reach if in the projects which use documents instead of face-to-face communication. The development process is very simple but sufficient. It includes all necessary phases to make a complete product such as: Analysis of requirements, design, coding, testing and releasing. The design in each of iteration is simple and straightforward so programmers are easy to implement it.

Cost and time reduction

The time to develop software in agile methods is shorter than in traditional methods. Consequently, the cost for development process also reduces. With agile methods, we only need from 20 to 40 people in a
team. Therefore, the salary which is paid for all of them deceases. The cost in this case reduces a lot comparing with traditional methods with hundreds of members in a project. All member works together with face-to-face communication so we do not lost money for communication fees as if members stay in different locations or renting offices.

DISADVANTAGES OF AGILE METHODS
Agile methods are suitable for developing software nowadays because of its fore mentioned advantages.
However, any method can have both the strength and the weakness. We cannot find a single method which is appropriate for all software projects. Therefore, agile methods can have some disadvantages as we will discuss below.
Insufficient necessary documentation
The emphasis on face to face communication and rapid development do not support documentation. It lacks an overall requirements specification document. Customers do not make their requirements at the beginning of the process. They do this thing during the process. Therefore, requirements are not systematic. At the end of project, we cannot have a virtual requirement document. We also do not have a design plan with agile methods. Software is developed in iterations. After each of the iterations, the design plan document is replaced with new one which is different from the previous one. Hence, we can not have an overall design plan document at the end of the development process.

Insufficient support for big teams
Face to face communication is not suitable for large teams. It will hard to communicate directly between teams member due to a large number of members. In this case, other communication approaches are used in large environments such as meetings, conferences. In fact, a few documents make members in large teams can not understand the whole project. Therefore, in these large teams, programmers cannot get feedback in a short time.
Insufficient support for teams with junior developers

Senior developers play an important role in agile methods. There are considerable gap between senior developers and junior developers. Experience is the most important thing in developing software. Senior developers often have much more experience and they can start their tasks immediately while junior developers need more time to study about what the tasks are and how to do them. Agile methods require
programmers implement tasks rapidly which is impossible for junior programmers. The delay occurs and affects all phases in the whole project.
Insufficient support for distributed development environments
Agile methods require all members work together in a co-location with face to face communication. Therefore, these methods can not be used in multinational companies which have a spread out development environment. In these companies, a project is developed by members in different locations and face-to-face communication is impossible. Customers cannot work together with other members. Video conferences, along with other real time communication technologies are expensive and we can not use all the time [10]. Members stay in different time zones so they can not work together in the same time. Agile methods do not support documentation. A few documents are released in the development process. This thing is very  difficult in distributed development environments. With a few documents, members cannot understand what other ones have done and where the development process is at that time. Rapid changes in design plan documents and the development process are also hard for team members to catch up.

Insufficient support for large software systems
While developing large software systems, we should have an overall architecture constructed at the  beginning of the project and update it during the development process. These software systems are normally complicated. We cannot do them without a designed plan. Agile methods do not support the overall architecture. A designed plan is done after there are any changes in requirements from the
customer so it is not systematic. Maintenance is required in large software systems. Lack of necessary documents such as requirement specifications, designed plan, implementation plan, and so on make the
maintenance process is unable.

SOME EXTENSIONS OF AGILE METHODS
In this section, we will propose some ideas to extend agile methods which we have identified after analyzing the disadvantages of agile methods.
Overall architecture
An overall architecture should be created after analyzing the first set of requirements from customers at the
beginning of the development process. It must reflect the structure of a product which customers want. Software developers should make it flexible in order to update frequently it. In each of iteration, we should have a design plan document. It describes the architecture of the product in this iteration. Overall architecture is updated from this document after each iteration.

Agile documentation
We know that documentation reduces the main characteristic of agile methods which is to develop software
rapidly. Therefore, we propose a suitable solution, making agile documentation. It means that only necessary documents should be created during the development process. Documentation is very important for maintenance activities. We can not maintain a software system with poor documentation. Therefore, necessary documents should be made during the development process such as: requirements specification, design plan. With requirements specification document, we can know the functions of the software
system. With design plan document, we can know about its architecture. Documentation is also very important with large or distributed software systems. Software developers can not understand about the system without documentation.

Roles of small group leaders

Splitting a team into small groups and set up leaders for each of these groups is one way to solve the limitation of face-to-face communication in large or distributed development environments. These groups should include from three to five members. Leaders not only communicate with each other to keep good communication in a team but also manage the development process in their groups. The communication role of leaders is as bridges between groups. The conveyance of information in a team is via leaders. When a member wants to get information, he requests his leader and then his leader requests other leaders
to have necessary information. Leaders often participate in team meetings to report the working status of his group. Leaders have role as project managers. They make plans, assign tasks to other members in the group and must be responsible to development process. This thing ensures doing tasks in a plan so it is easier to manage. The fifth principle of Agile Manifesto emphasizes motivated individuals. It means that software developers can do whatever they think that they should do. In the case of this idea, software will be developed rapidly but tasks are difficult to manage and the project occur more risks.

CONCLUSIONS

Software companies can take advantages of agile methods when they meet the requirements of making software systems in business environment today. Using agile methods ensures the high success level of software projects when they minimizes risks, develop software in very short time, satisfy the requirements of the customers at highest level, improve the effectiveness of development process, reduce cost and time and so on. Agile methods are effective to several software projects but not all of them. Large projects or projects in distributed development environments can not take advantages from agile methods. In the case of these projects, traditional methods such as spiral method or incremental method are more useful. Agile methods can not ensure the success in projects which are developed in big teams including more than 50 people or are developed by junior developers. Some ideas are provided to improve agile methods. Overall
architecture, documentation are very important things in developing software. However, we suggest that software developers think carefully about extension ideas to decide whether they are necessary to use. If their projects are small and have not complicated architecture, they do not need to think about these extension ideas. These ideas are useful when they develop big projects. In these projects, the architecture is not simple so it is necessary to have overall architecture and documents which are also helpful  for maintaining later. We hope that there will be more articles about how to improve agile methods in the near future. When agile methods are becoming popular, there will be much more problems about these methods when we use them in practice. Future works concentrate on how to change some of these principles to make agile methods have an optimal effect.

REFERENCES
1. Abrahamsson P., Warsta J., Salo O. and
Ronkainen J. Agile software developement
methods: Review and Analysis. VTT Publication
478, 2002.
2. Abrahamsson P., Warsta J., Siponen M.T. and
Ronkainen J. New Directions on Agile methods: A
competitive analysis. IEEE, 2003.
3. Aydin M.N., Harmsen F., Slooten K.V., Stegwee
R.A. An agile information systems development
method in use. 2004.
4. Favaro J. Value – Based Management and Agile
Methods. 4th International Conference on XP and
Agile methods, May 2003.
5. Hayes S., Andrews M.: An introduction to Agile
Methods.
6. Kalermo J., Rissanen J. Agile software
development in theory and practice. 2002.
7. Keefer R. Agile software development. Strategic
data systems, 2004.
8. Lindvall M., Basili V., Boehm B., Costa P.,
Dangle K., Shull F., Tesoriero R., Williams L., and
Zelkoowits M. Empirical Findings in Agile
Methods, XP/Agile Universe. 2002, pp.197-207.
9. McMahon P.E. Extending agile methods: A
distributed project and organizational
improvement perspective. System and Software
Technology conference, 4.2005.

10. Turk D., France R., Rumpe B. Limitations of
Agile Software Processes.
11. Szalvay V. An introduction to agile software
development. 2004.
12. Williams L. A survey of agile development
methodologies. 2004.

Introduction

This report analyzes two case studies on SPLE practices of two companies: Philips Medical Systems (PMS) and HP. Each case study is a success story of a software product line. The reported experiences are summarized, compared and mapped to product line principles. We focus on analyzing experiences about cooperative development, common platform, evolution development approach, process management, motivation of software product line and variability management.

Overview of software product line principles

Two basic principles of SPL are: mass customization and common platform.

“Mass customization is the large-scale production of goods tailored to individual customers’ needs.” [1] It means that different types of products are available, each produced in a large number. The customers can have a choice and they can find the best option for them. The consequence of mass customization is the necessity of managing variability of a product line.

“A platform is any base of technologies on which other technologies or processes are built.” [1] Therefore, it is a set of common elements used in different products. The platform approach helps the manufacturer to offer a wider variety of products and to decrease costs at the same time. In software development the use of platforms implies elaborating a reference architecture, which captures the high-level design of applications in the product line.

Software product line engineering is combining mass customization and common platform. It allows reusing a common base of technology and, at the same time, to bring out products in close accordance with customers’ wishes [1].

Two case studies

Phillips Medical Systems

Phillips Medical Systems (PMS) provides medical diagnosis equipments based on medical images for hospitals. It also provides solutions for storage and diagnosis support. For example, some products of PMS are computed tomography products, X-ray systems for radiography and fluoroscopy, nuclear medicine product portfolio, radio therapy planning systems, and so on [4].

PMS created not only a product line, but also multiple product lines based on a medical middleware platform [2]. This platform is the core architecture for developing and generating all products for PMS. One special thing is that it is also a product line in itself. By configuring and using different variants in this platform, engineers from PMS create different product lines. A product group typically includes several product lines, but they share a lot of common software. For example, all products support receiving, storing and retrieving images. In the report, the author describes four main experiences in building and developing multiple software product lines in PMS: Creating architect’s network and software community, using evolutionary approach for development process, making the reference architecture and keeping the stability of management and staff.

Architect’s network and software community: Unlike other organizations [5,6], which often create software product line from making plans for reusing first and then develop a common platform which is used for deriving different products, PMS decided to develop software product lines based on existing software [2]. It means that PMS developed a middleware platform which includes the common features of all existing software. Because of that, PMS arranged shared architecture meetings first, where architects from different development groups met to discuss and find the common architecture. At that time, a plan for reusing had been finished. It mentioned how to use the platform in developing new products in the future. A product manager also had been appointed to manage the development process of the platform. An architect’s network is used to connect all architects for the purpose of migrating features of all existing software to the common platform. There is a software community, where all members from different development groups discuss, having the roles of engineers, testers, and users. This ensures that the common platform is developed and tested by all members.

Evolution development: PMS decided to choose evolutionary approach in developing the common platform [2]. Evolutionary approach is a model for software development process which divides the development process into small iterations, called evolutionary cycle [10], which contain all necessary tasks to finish a software product such as requirement analysis, design, implementation, testing and delivery. The duration of each evolutionary cycle is short, so the customer can get the usable software as soon as possible and then provide feedbacks for improving the quality and functionality of the product. This approach aims: Getting usable software to the user as soon as possible, Early and regular software product feedbacks from the customer, continuous improvement of software process, delivering the the parts most important to the customer first, and capability to handle changes in requirements [10]. The platform is developed from the basis to be extended in an evolutionary way. Components are added to the platform based on existing software. It is a direct and one-to-one transformation. When new components are added, a new working version of the platform is released for development groups to use and test it immediately. The plan of platform’s development also is updated regularly during the development process.

Reference architecture: The reference architecture includes three main concepts: Components, Connectors and Sementics [2] and has four main layers: System (the lowest layer), Medical middleware (the second layer), Medical application (the third layer) and Workspots( the top layer) [8]. Components are elements of the system, which can be developed independently and can also be reused. For example, components in the system are operating systems, technologies, etc such as Windows, Unix, COM, Java, etc. Components in the medical middleware are image processing, image printing, image storing, etc. Components in the medical application layer are viewing, emaging, administration, etc. Component based architecture is the most efficient approach in design and development of a software product line, because the structure of the system will be flexible with this approach. Connectors are interfaces. Each component provides its functionalities through one or more interfaces and based on interfaces, components are developed. The user accesses the components through the interfaces. The distinct thing in architecture of PMS is the use of sementics in order to improve the stability. Sementics are information models used to interchange data among interfaces. Data access is abstracted, so the pass of data among interfaces is independent of where the data is stored: networks, database, files, etc. The information models form a stable factor. The communication among components only takes place after these components obtained agreement upon information models. Hence, components can ignore fields which are not understood by the information models. This ensures forwards and backwards compatibility over the different versions of the system.

Management and staff: The stability of management and staff contributed to the success of software product line development of PMS [2]. PMS considered that in multi business line environment, organizational aspects are much more complex than technological aspects [9]. When there were few changes during the process members were always familiar with it, so there were no major risks affecting the process. No new members were added, which lead to no training and no interruption. In order to reach this, PMS had following experiences:

• Team members must understand clearly and explicitly the platform concept and its consequences. Their understanding is not only the “what” of the platform concept, but also the “how” of implementation [7].
• Complete plans and models for handling organizational and process aspects must be created either for the initial development of the platform or the using of the platform [7].
• Decision model that defines how various interests will be judged and how final decisions will be reached on aspects of specification, design, implementation, etc should be created [9].
• The roles and responsibilities of team members should be distinguished clearly [7].

In addition, PMS operated other strategies in managing organization and process:

• The development of the platform’s architecture should not be organized as a one-shot project, but as continuous activities that release many versions of the platform during its lifecycle [7].
• The solution for moving application knowledge into the platform is moving a number of senior software developers from application teams into the platform team.

HP (Hewlett-Packard)

HP is one of the world’s leading manufacturers of printers. Each of their products is full of complex firmware for controlling all aspects of the printer’s operation. HP created an environment for extensive sharing of its firmware components across printer product lines and between geographically-dispersed development teams.

They took a new approach in the development of its Owen firmware, used in a wide range of printer variants. The idea was to organize a “firmware cooperative” including the firmware teams from several products, following the principles of cooperative organizations. It was an alternative to creating a specific reuse team.

Projects can freely choose which of the common firmware assets of the cooperative they want to use. They can add new components and modify existing ones, and they should do it in a way that allows reuse. However, no team in the co-operative is required to use changes developed by another team.

HP identified three key success factors that have helped make the firmware cooperative model a success [3]:

Firmware Architecture: Component-based architecture that exhibits the desired architectural properties of high component coherence, and low component coupling. It is captured in a graphical form which allows each product team to assess the current set of components against the needs of their product. The graphical overview is complemented by component documentation in a standard form. The team can decide which components to use as-is, which need to be changed, and which they need to build from scratch. The clean architecture generally accommodates component extension and addition without difficulty.

Development Approach: A project can choose with almost complete freedom which changes it wants to use, and which not. This is because Owen uses a software configuration approach based on “change-sets”. When a project team changes or adds to the set of components – for example, to add a new feature – each individual change is captured as a change set. The key property of change sets is that they can be applied mostly independently.
This allows loose coupling between projects, so they can focus on the requirements of each product. There is no risk that a change made in one project will have a negative side effect on another project. However, it is easy to include desired changes from other projects.

Sustaining the Cooperative: A number of key roles were established for the architects of the Owen cooperative:

· The Steward, responsible for the smooth running of the cooperative by communicating with the project teams, embodying the operating principles, convening get-togethers, and so on.

· The Firmware Architect, responsible for the definition and evolution of the overall firmware component architecture.

· The Asset Lead, responsible for the firmware code-base itself – with the realization that this is a valuable economic asset.

The Owen firmware cooperative has been a great success. There was a 70% increase in the amount of code shared across participating printer product lines. When compared with developing firmware independently for each printer variant, the team reported:

• a 3x improvement in time to market,
• a 4x reduction in overall team size and
• a 25x reduction in typical defect densities.

An analysis of reported experiences of above case studies

In this section, we compare experiences reported in the case studies of PMS and HP and then map them to the principles of software product line engineering.

Cooperative development: Both two case studies considered cooperative development as an efficient approach to obtain mass customization. The platform of PMS and HP were both contributed and developed by architects, developers and other stakeholders from various development groups, and by transforming components from existing software into the common platform, so they included features of all products. In particular, there was an architect’s network and software community in PMS. Architect’s network is where architects from various development groups communicate to find out a common platform which includes common features of all existing products. Software community is where developers, testers and other stakeholders from different development groups can discuss anything about the platform. Because of that, the platform was developed, used and tested by members, so the platform meets the requirements of all products of PMS. Similar to PMS, HP held a firmware cooperative which was a collection of firmware teams from several products in order to meet their needs.

Common platform: The architecture of the platform of PMS and HP were component based architectures, an efficient approach for building software product lines while other products can get only some components of the common platform. PMS focused on the stability of the structure of the platform while HP focused on the stability of the management of the platform. The platform of PMS includes Connectors which are interfaces to access into components, and Sementics which are information models for interchanging data between interfaces. The user can not access directly into components, they must access through connectors. Data, which is passed between interfaces, is abstracted into standard. The tight structure of units makes the stability of the platform architecture. The architecture of the platform of HP includes only components but it is managed efficiently through documentation management with graphical form. Graphical form makes the users easy to understand the whole structure of the platform and do not need much time to find out suitable components for developing their products.

Development approach: Because of using component based architecture, the structure of the common platform is independent components. Hence, the evolutionary development is the most efficient approach for building software product lines while different products only use some of components from the platform. Both PMS and HP used this approach. PMS created their common platform from the basis and extended it by transforming components from existing software. After adding new components into the platform, they release a new version of platform, so development groups can use the platform immediately. This reduces time to market when development groups can use necessary components of the platform soon and do not need to wait until the platform is completed. HP used a configuration approach based on “change-sets” during the evolutionary process of development. When a new component is added into the platform, it is captured. The efficient management of components available in the platform makes HP reduce time to choose components for new products.

Management and staff: Both PMS and HP agreed that management and staff is one of the most important factors to ensure the success of building software product lines. The management is more complex in software product line projects because these projects often include several stakeholders from different teams with different roles and knowledge. PMS reports that the stability of management and staff contributed the success of its software product line while during the development process, there were a few changes. This ensures there had been no interruption in the process because of training for new members or changing of structure of the project. Members were always familiar with the process, goals and their tasks. HP had another solution to ensure the stability of cooperative development in the long time. They set up a close structure of management with different roles such as Steward, who is responsible for connecting all activities in the project, Firmware architect, who is responsible for design all components in the architecture, Asset lead, who is responsible for coding.

Result: Both PMS and HP mentioned the benefits of developing software product linein their reports. Motivations of software product line are reduction of development costs and reduction of time to market [1]. The reduction of development costs comes from increasing similarity between products. When develop a new product, we do not need to develop all components for it, large numbers of components are got from the common platform and we only develop the rest of components. Because of this, we can reduce time to market. In the report, PMS reported that platform components are constructed with about 1.6 times as many people as when they are constructed by development groups themselves. If another development group uses these platform components, this approach is efficient because it saves 0.4 times as many people as when two development groups develop separately. However, in PMS, several development groups use these platform components, so they save development costs a lot. HP also reported that the benefits they received from their product line are a 3X improvement in time to market and a 4X reduction in overall team size.

Variability management: The efficient management of variants plays an important role in building and developing software project lines. However, in their report, PMS and HP mentioned a little about this. PMS developed software product line from existing software. They migrated and transformed components from existing software into their common platform. They also write that at the beginning stage of development process, they created a reuse plan of platform but did not explain anything about it. HP reported nothing about their variability management.

Conclusion

In the two analyzed cases introducing software product lines was a success and brought major benefits to the companies, reducing costs and time needed for development of software products. The main success factor was adopting effective approaches to product line principles: cooperative development as a way to achieve mass customization, and evolutionary approach in platform creation. Efficient organization and management with the diversification of roles in development teams also proved to be vital, which illustrates the fact that a mature development process is a prerequisite for introducing a software product line in an organization.

References

1. K.Pohl, et al, Software product line engineering: Foundations, Principles, and Techniques, Springer, 2005.
2. F. Linden, Multiple product lines for Phillips Medical Systems, Phillips Medical Systems, December 2004, http://www.softwareproductlines.com/successes/philips_med.html.
3. P. Toft, The HP Owen Firmware Cooperative: A software product line success story, March 2004, http://www.softwareproductlines.com/successes/hp.html.
4. Phillips Medical systems website, http://www.medical.philips.com/us/products/imaging/, 2008.
5. S. Cohen, Case study: Building and communicating a business case for a DoD product line, Technical note, CMU/SEI, April 2001.
6. P. Clements, S. Cohen, P. Donohoe, L. Northrop, Control channel toolkit: A product line case study, Technical report, CMU/SEI, September 2001.
7. H. Postema, J. H. Obbink, Platfrom based product development.
8. F. Linden, J. G. Wijnstra, Platform Engineering for the Medical Domain, Proceedings PFE4, Bilbao, October 2001, pp. 224-237.
9. B. J. Pronk, Product line introduction in multi-business line context, an experience report.
10. M. Chiwenda, D. V. Delano, F. Jonson, Evolutionary development – An introduction and analysis.

<author: myself, doantung83@yahoo.com>

Introduction

Software projects are now developed more in distributed environments because of two following main reasons. The first one is that software organizations want to outsource to developing countries where the cost of software engineers is cheaper than those in developed countries [6]. Because of the difference of living standards, the salary of a software engineer in a developing country probably is one tenth of the salary of a software engineer in a developed country, while the knowledge and skill of them are probably the same. For example, an IT graduate student in Vietnam is paid 150$ per month while an IT graduate student in Finland is paid 1500$ per month. Hence, outsourcing is the efficient solution for software companies to reduce the budget for software projects and then to heighten the competition which helps them to exist in software industry in which there are a lot of new software companies each day. The second one is that software organizations want to enlarge their markets. Applying information technology into the daily life in developed countries is quite popular. However, in developing countries, there is now a big market while their governments are planning to improve the applying of software in every daily life. Another reason, they want to find new markets where there are several customers but a few of suppliers. For example, there are many international software companies in Finland. The reason is that there are a lot of software projects for mobile devices from Nokia, a huge corporation in Finland, which Nokia can not perform itself, so it rents other software companies to do those projects.

Developing software projects in distributed environments makes companies reduce the cost of investigation for projects but there are several problems which decline the quality of software. The most serious problem comes from the communication. When working in distributed environments, the communication among members is hard to reach when there is no face-to-face communication. Members only use other ways such as emails, phone, web – based shared working environments. With these ways, it takes long time for information to pass. Communication plays a very important role in developing software because sharing information or knowledge occurs regularly. Sharing knowledge about development phase such as requirement specification, design, implementation and so on is the only way to help developers to know about what they are doing and how to do next. Sharing individual knowledge helps junior developers can perform their tasks with the guidelines, instructions, or experience from senior developers. Sharing culture helps members to understand about others and then can work together efficiently. In distributed environments, it is difficult to manage risks in the project. It is really a problem while risk management is very important. Risks always occur in every software project and if we can not track them correctly, the project will be failed. It is also difficult to manage the skills of members when they come from other locations with different education background and experience. Skill management also is important because if we manage efficiently the skills of members, we can assign right tasks for right members, so these tasks will be done with less time and better quality.

One of solutions for the above problem is applying knowledge management in software projects which are developed in distributed environments. In fact, there were several companies which have created knowledge management systems [3]. In the following sections, we first introduce basic concepts such as knowledge, knowledge management and then mention the role of knowledge management in software engineering. Next, we propose some main problems of developing software in distributed environment. In the last section, we suggest some solutions for creating a useful knowledge management system and we summary main points in conclusion section.

Overview of knowledge management

We first mention about the levels and characteristics of knowledge and then provide the definition of knowledge management.

Knowledge comes from information and information comes from data. It means that there are three levels of refinement to knowledge items [1]. Data, which is the first level of refinement, is raw material. It only consists of facts about events. It does not contain any information which helps the user can understand more about these events or their relations, dependences. Information, which is the second level of refinement, is created from data. It is an amount of data which creates a meaning, description, or definition. Knowledge is higher level of information. It requires understanding of information items, their relationships. In summary, data is only raw material. Information probably is description, definition. Knowledge refers to strategy, method or approach.

There are two contrary types of knowledge: explicit knowledge and tacit knowledge. Explicit knowledge is knowledge that is easy to capture and share. Tacit knowledge is hidden knowledge that is personal experience, so it is hard to capture and share. Knowledge management deals with both explicit knowledge and tacit knowledge.

Knowledge management is a process of creating, classifying, storing and using knowledge. Knowledge management is probably applied in an organization or even in a lifecycle of a project.

Creation: First of all, knowledge items are created based on particular goals of an organization. Creating knowledge items are tasks of all members in an organization although some members are responsible to manage them. It should be created not only in the first stage but also during the process.

Classification: Knowledge items in an organization are often large so they should be classified in order to access, find and use easily. Knowledge management systems often create categories and then divide knowledge items into particular categories.

Storing: Knowledge is used in a long time so it should be stored for the purpose of reuse. Each knowledge management system often has a repository. It is also useful if an organization has a lot of units in distributed environments.

Using: When a member in an organization perform tasks which need to refer knowledge from other members or knowledge which is available in the organization, he or she accesses the repository of knowledge management system and gets necessary knowledge items.

Knowledge management is applied in an organization in order to leverage the use and sharing of knowledge. Nowadays, knowledge is considered as one of the most valued resources of any organization. Hence, a lot of organizations pay attention to research and develop knowledge management systems.

The role of knowledge management in software development

Software is developed through several phases with a lot of different tasks done by many people. Hence, software development is human and knowledge-intensive process [1]. Knowledge management addresses the performance of people in software projects which can be called peopleware [1]. Therefore, knowledge management has an important role in developing software. It is one of the most efficient approaches using to improve the quality of software development.

Software development is a complex process hence knowledge management is useful for organizing teams, tracking processes by documentation, templates, and so on. For example, using knowledge management to identify and profile all stakeholders who are relevant to the project. It is very important because software development requires many people who possess different skills. Some people are required to have skills in gathering requirements, some people are required to have skills in design software products, some people are required to have technical skills in implementing source codes and so on. Managing skills of stakeholders helps all members can know who know what. Another example, developing software requires several documents such as requirement specification documents, design documents, testing plan documents, implementation plan documents, user interface specification documents, maintenance documents and so on. Documentation is necessary because it helps stakeholders to understand about the software product and software development process.

Software development includes a large amount of technical knowledge. Knowledge management helps developers to study and understand new techniques which are necessary to perform their tasks, to share individual experience, to discuss problems and find out solutions together based on tacit knowledge of all members.

Knowledge is shared during the software development process though formal training and learning by doing [1]. Formal training is an efficient way for developers to study and understand knowledge about new technologies, domain which are using in projects. However, it is time-consuming and expensive, so it is not easy to apply, especially in distributed development environments. Hence, only important formal trainings should be held instead of all trainings. Learning by doing is another way to share knowledge among developers. Developers studies by doing. They access knowledge management system of their companies and query knowledge which they need to perform their tasks. This way is efficient but contains a lot of risks. Developers probably continue to perform their tasks with wrong results until they actually recognize their failure. However, learning by doing is using more widely than formal training. Knowledge management systems are using to store knowledge which supports developers to perform their tasks.

Problems of developing software projects in distributed environments

The most important and biggest problem of developing software projects in distributed environments is communication. Most problems we mention below come from the problem.

Sharing knowledge about the development process

Software development process is a complex process with several phases which are relevant to each other. For example, there are often four phases in developing software: requirement analysis, design, implementation and testing. Designers create the architecture of application based on the requirements from the requirement analysis. Software developers implement components, subsystem based on the architecture of application which was made in the design phase. A software project requires members with different skills to work in phases. The sharing knowledge among these people is occurring very often. When a member performs a task, he or she must know all knowledge about stuffs which are relevant to his or her task. In order to do like that, he or she must communicate with other members who are working in other phases. In distributed environment, face-to-face communication is not used. We only can use other technologies such as emails, phones, and webpage-based forum. With these technologies, sharing knowledge is not efficient because it probably takes a lot of time or it requires much money and resources.

A software application is often a large system with a lot of subsystems, components and modules. Hence, a member can not know about the whole system. He or she is responsible for a small part of the system. Members must communicate with other members to know about other parts of the system in order to perform their tasks. Sharing knowledge about parts of the system is occurred very often. When developing software in distributed environment, this sharing is not efficient, so it is a problem.

During the development process, members in a software project often share knowledge about domain, technologies and tools. Knowledge about domain is very important for members to understand widely and systematically about the software, where the software belongs. Technologies in the field of information technology occur rapidly. Developing software often uses several technologies. Tools are used frequently to support developers to implement fast and usefully.

Sharing individual knowledge

In software development, the experience of software developers has a very important role. Because of this, software companies always pay attention to the sharing individual knowledge of senior developers with junior developers. This improves the quality of software and reduces risks, time and cost. Developers can not obtain necessary skills of developing software through studying at university or participating in software project in short time. Software development requires more practices and needs senior developers.

When working in distributed environment, junior developers do not work together with senior developers in the same place. Hence, the sharing of individual knowledge is difficult to occur. For example, if they work in the same place, when junior developers meet a problem, they can ask senior developers who are sitting next to them. The problem can be easy to solve when senior developers has face-to-face communication with junior developers or they can come to the place of junior developers to solve problem on the computers of junior developers. When working in distributed environment, the sharing of experience is happened through emails, discussion in forums or phone calls. It is hard to express the problem which developers meet by writing or using phone. Hence, the sharing experience in distributed environment is not efficient.

Culture

Nowadays, many software organizations pay attention to problems of having various cultures existing in their organization. They have realized the significant impact of this problem on developing software. When developing software in distributed environments, organizations always face with the problems of various cultures. Software developers come from various cultures, so they have various behaviors, backgrounds and thoughts. It is hard to expect that they have a same working style, problem solving. For example, teams from different cultures often tend to propose different solutions for designing the architecture of software [4]. Another example, a software company, which I have been worked, has offices in various countries in Asia and Europe. Software developers at offices in Asia countries tend to finish tasks with sufficient requirements, they do not want to spend more time just improve the quality of source code. In contrary, software developers at offices in Europe tend to finish tasks with the highest quality. If they finish tasks soon, they still want to think about them, try to find better solutions. Moreover, these developers work systematically. It means that they create source codes which are easy for other developers can understand. Source codes are written in clear structure with a lot of comments. Another difference is that developers in Asia offices are willing to work over time when there are a lot of tasks in the project or project needs to be finish as soon as possible but developers in Europe offices often do not want to work over time.

Sharing knowledge about local policies

In distributed environment, each office often sets up its own policies which are suitable with the environment, culture of the place where it is located. Hence, it is not easy for some members working in an office, to move to other offices. They will face with the different policies in the new office. First of all, they must find out what the policies of their offices are. Policies are set up and updated through the long time of working together in the same place. Hence, it is difficult for the new members to catch new policies in a short time. However, in fact, members working in distributed environment often move to work in new offices only in a short time and then they must return to their previous office or move to other new offices. Secondly, when they know about policies in their new office, it also is not easy for them to familiar with these policies because they must change their habit, behavior, or even thoughts.

Risk management

Risk management has important impact on the quality of software products. Risks occur in every software project and they probably reduce the quality of end product and even cause the failure of software projects. There are two approaches in risk management: preactive approach and reactive one. Preactive approach means that software engineers try to identify and then track risks before they occur. However, this approach is hard to apply. Reactive approach means that software engineers only pay attention to risks when they occur. However, some risks are very serious and when they occur, software engineers can not track them. This makes software unsuccessful. Two approaches above have limitations. In conclusion, risk management is a difficult task.

When developing in distributed environments, risks are more difficult to manage because of two following reasons. Firstly, risks are often detected by software developers though daily working. When discovering risks, they often discuss with their colleagues in office to know surely about those risks and then try to find solutions to eliminate or avoid risks. However, this can not be done in distributed environments. Secondly, risks also are detected from review meetings or by discussing in groups. However, in distributed environments, review meetings can not be held.

Skill management

A software project often includes a lot of members with different skills because a software product is developed through several phases. In each phase, it requires people with different skills. For example, a software development process often includes four phases: Analysis, design, implementation, testing. Members working in the analysis phase must have skills in communication, problem solving, decision making, documentation, etc. Members working in the design phase should have skills about software architectures, technologies, etc. Members working in the implementation phase have to possess skills and knowledge in coding, techniques, tools and so on. Based on this, a member can work very well in a phase but he or she can not perform tasks with excellent results in other phases. Hence skill management plays an important role in software projects. Good skill management will assign members into suitable places, so the quality of end product will be improved.

It is difficult for project managers to manage the skills of members when they are working in a distributed environment because project managers can not have face-to-face communication with members. Based on this, first of all, project managers do not work with members in a same place, so they can not remember exactly the skills or applied experience of members. Secondly, project managers can not observe the activities of members in working days, so they can not test the skills of members. They only can trust in what members say about their skills. This probably brings problems. For example, when a member say that he has enough skill and experience to do a task and project manager assign this task for him but actually, when doing it, he realizes that he can not do it. The problem is that the project manager believes that this member can do it. In addition, a project manager and a member in this case probably do not have same level of assessment. A member thinks that he has enough skills in his evaluation and a project manager thinks that this member can do the task in his evaluation. Hence, it is necessary to have a standard in evaluating skills of members. Lastly, project managers can not arrange trainings for all members.

When working in a distributed environment, members come from different locations. They possess different education, background and experience. For example, a university in a location is good in teaching a field of software technology, software engineering but another university focuses on teaching another field of software technology. Hence, students in two universities will have different skills and knowledge in a field of software technology. In addition, companies in a location focus on developing software in an area such as mobile devices using Symbian platform but companies in another location focus on developing software in another area using Microsoft platform. Based on this, software engineers in two locations probably have different skills and knowledge about software technologies, tools and techniques. Moreover, the level of development in software technologies of each location is not the same. Hence, it is hard for project managers to manage skills of members who come from different locations.

Applying knowledge management in order to solve the above problems

Knowledge management system should be an integrated system which includes many subsystems running synchronously. It means that all subsystems retrieve data from a repository. When there is a change, all stuffs which are relevant to this change will also be updated. In the following part, we describe generally some subsystems of knowledge management system.

Process management

This subsystem manages all tasks during the development process. It displays knowledge about all steps in the process from the beginning to the end of the project. The most important knowledge in this subsystem is knowledge about tasks which are created by project managers and assigned to suitable team members. Knowledge about tasks should be clear and complete. For example, they should be description of the task, the person creating the task, who must perform the task, deadline, etc. This subsystem will solve the first problem which we mentioned above: sharing knowledge about development process.

Organization management

Organization management includes knowledge about the structure of the organization, the role and responsibility of members, policies and culture. Knowledge helps members to make a common environment where they can understand each other and are comfortable to share. This subsystem will solve the third and fourth problems which we mentioned above: The problem of conflicting culture and sharing local policies.

Document management

Document management subsystem should works as a sharing workplace. All members have different rights to access into the system. Rights of each member are assigned depending on his/her role in the project. Members can create, view or modify documents in the system.

Document management subsystem stores important documents such as: requirement specification, design, user interface specification, testing plan, maintenance, and so on. These documents include information which is necessary for developers can have general view about the whole development process and find any information which is relevant to their tasks at any time. It is really important because developers can not perform their tasks without these documents. This subsystem is very useful to store and track knowledge about the process development. Hence, it is good solution for the first problem which we mentioned above.

Competence management

Competence management subsystem is a useful tool to manage human resources in an organization. It includes a database which stores personal information, skills, experience, etc of every member and a user interface which helps the user to access to database, browser information from the database and edit them. Information about each member should be complete. They are not only basis information as above but only other types of information. For example, information about working history helps managers to move a member to another office which is most suitable with him or her when the managers know that he or she worked at that office in the past. This subsystem will solve the sixth problem which we mentioned above: Skill management.

Information management

Information management subsystem works as a forum, blog, wiki where every member can discuss stuffs which are relevant to their tasks, projects, or the organization. It is the good place to share information. For example, when a developer meets a problem which he can not solve, he posts a topic on the forum and other developers can give his solutions. This subsystem will solve the problems of sharing individual experience (the second problem which we mentioned above) and managing risks (the fifth problem).

Conclusion

In this paper, we propose a solution for the problems of developing software in the distributed environment. When there are more and more software companies choosing outsource as the best solution to reduce the development cost and enlarge the market, applying knowledge management helps us very much in reducing the problems of this solution and improving the quality of the end product.

We tried to provide the main problems of developing software in the distributed environment based on our experience and references. At the end of this paper, we suggest some ideas to construct an efficient knowledge management system. In the scope of an article, we can not describe more detail about the system, or make a complete requirement specification and design document.

References

1. Rus, I., Lindvall, M., Knowledge management in software engineering, IEEE Software, May-June 2002.
2. Natali, A.C.A., Falbo, R.d.A., Knowledge management in software engineering environments,The 16th Brazilian Symposium on Software Engineering – SBES, 2002.
3. Dingsøyr, T, Conradi, R., A survey of case studies of the use of knowledge management in software engineering, International Journal of Software Engineering and Knowledge Engineering, July 2002.
4. Dingsøyr, T., Rolland, K.H., Jaccheri, M.L., The benefits and limitations of knowledge management in global software development, Third International Workshop on Global Software Development, May 24 2004.
5. Santos, G., Villela, K., Montoni, M., Rocha, A.R., Travassos, G.H., Figueiredo, S., Mafra, S., Albuquerque, A., Paret, B.D., Amaral, M., Knowledge management in a software development environment to support software processes deployment, p111-120, Professional Knowledge Management book, 2005.
6. Luczak, H., Hauser, A., Knowledge management in virtual organizations, Services Systems and Services Management, 2005. Proceedings of ICSSSM apos05, 2005 International Conference on Volume 2, Issue , 13-15 June 2005 Page(s): 898 – 902 Vol. 2.
7. Bjornson, F.O., Knowledge management in software process improvement, doctoral thesis, Norwegian University of Science and Technology, Faculty of Information Technology, Mathematics and Electrical Engineering, Department of Computer and Information Science, 2007.