SE News

Ohloh is a resource for open source intelligence on thousands of open source projects. Ohloh collects software metrics from a variety of sources including the project’s source code and the software development infrastructure used by the project’s development team.

http://www.ohloh.net

Open Source Software leek enkele jaren geleden op het punt van een doorbraak. Maar nog steeds is er veel koudwatervrees bij de toepassing van Open Source software.

Met een risico gedreven benadering helpt DNV-CIBIT u vast te stellen of Open Source voor uw organisatie een valide optie is.

http://www.cibit.nl/site.nsf/page/ict_nieuws_ict_de_essentie_van_open_source_software

Unit testing individual classes is almost always useless. You need to unit test contracts or well-defined APIs instead. Why? Because testing and simulating APIs enables you to refactor a whole component with very few changes to the test. You can even rewrite the entire component without the tests knowing, since the tests depend only on the APIs they use and the APIs they simulate. They don’t depend on any implementation classes.
This article introduces MockLib, a tool that simulates entire APIs (not just one single interface) using a mock library. It enables you to perform this more effective type of unit test.

Dean Hiller

http://www.devx.com/Java/Article/34990

The practices in this category promote strategies for running a project efficiently and effectively, so project teams and executives get the transparency and oversight required for lean governance, without unnecessary overhead. The specific practices associated with this category are:

• Iterative Development
• Risk-Based Milestones
• Adapt the Process
• Continuous Improvement
• Embedded Compliance

Scott W. Ambler and Per Kroll

http://www.ibm.com/developerworks/rational/library/jul07/kroll_ambler/index.html

Recently, my family and I moved into a new house. There is a certain excitement about moving into a brand new house: It’s fun to check out the new rooms, feel the new carpet between your toes, use new appliances for the very first time . . . ah, yes, the appliances. Unfortunately, our enthusiasm diminished slightly when we realized that the refrigerator didn’t cool.We got a new unit quickly, but its icemaker didn’t work. The icemaker was fixed, but then the ice door didn’t open. And then the water line froze. After several visits by the repair man, the refrigerator worked perfectly. But in the mean time, the stove and dishwasher — made by the same company — needed repairs also.

On its Web site, the company proudly proclaimed its commitment to quality. The company was particularly proud of its defect-free manufacturing processes. Since this was not my experience, I came to the conclusion that the company didn’t really believe in quality. It wasn’t as important as other things, such as short-term profit, perhaps.

What does this have to do with software? Quite a bit, actually. Like this large appliance company, we are in the business of providing a product to our customers. We may boldly state our commitment to quality and may even wave the banner of certification or process maturity. But the thing that really matters is how users experience our product. If they have to put up with frequent crashes, annoying bugs, or software that is difficult to use, our quality is merely a façade. Wrapping ourselves in the flags of ISO, CMM, or Six Sigma doesn’t make our users feel any better.

Neil Harrison

http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea

Architects must often make architectural design decisions but are typically unable to evaluate their economic impact. Management is often interested in product-level decisions (such as features and quality) but not in the technical details of how those decisions are achieved. These differing interests can lead to inconsistencies between how executives and managers define and foresee value, and how architects can enable or disable those value propositions through their design decisions. This lack of effective communication results in a weak partnership between architects and executives, resulting in missed opportunities to make informed and technically feasible valuedriven design decisions. This information exchange is particularly critical when an organization must plan for architecture evolution in the face of uncertain future business and mission goals. Since software engineering artifacts exist to serve the business goals of an enterprise, optimizing the value of software systems is a central concern of software engineering [Boehm 2000].

Equipping software architects with the ability to reason about value will provide them with the vocabulary and rationale needed to articulate the value-driven impact of architectural decisions to management.

Ipek Ozkaya, Rick Kazman and Mark Klein

http://www.sei.cmu.edu/publications/documents/07.reports/07tr003.html

All modern software development processes try to help project teams conduct their work. While there are some important differences between them, the commonalities are far greater - and understandably, since the end goal of them all is to produce working software quickly and effectively. Thus, it doesn’t matter which process you adopt as long as it is adaptable, extensible, and capable of absorbing good ideas, even if they arise from other processes.

To achieve this kind of flexibility things need to change. The focus needs to shift from the definition of complete processes to the capture of reusable practices. Teams should be able to mix-and-match practices and ideas from many different sources to create effective ways of working, ones that suit them and address their risks.

Ivar Jacobson, Pan Wei Ng and Ian Spence

http://www.jot.fm//issues/issue_2007_07/column5

“Open” seems to be the adjective of choice lately in software engineering circles. Open source, open interface, and open standard are all terms in popular use, but “open” doesn’t mean the same thing in every use. What they have in common is that the decision to make something open has strategic implications for the organization. It changes fundamental aspects about how products are produced.

John D. McGregor

http://www.jot.fm//issues/issue_2007_07/column1

When Java ME technology started in 2000 (back then it was called J2ME) there weren’t many choices available for developers for graphical API at that time. In fact, the only API that was available was the standard LCD user interface packages of javax.microediation.lcdui of the Mobile Information Device Profile (MIDP). At that time, MIDP was only at version 1.0, and there weren’t any tools available like the Sun Java Wireless Toolkit, Netbeans Mobility Pack, or Websphere Device Developer. Now, with so many graphical Java ME APIs available today, mobile developers have a different problem: API overload.

Bruce Hopkins

http://developers.sun.com/mobility/midp/articles/guiapis/

In my previous column, I provided a quick tour of the Business Process Execution Language (BPEL), using a complex sample business process. Now, let’s look under the covers of BPEL and get a sense of what it takes to wire an existing Web service into a BPEL process. Rather than focusing on the subtleties of the BPEL language itself, let’s concentrate on the key language concepts you need to build your first BPEL process. To do this, I start by using the Employee Web service I used a couple of columns ago to illustrate JAX-RPC programming, handlers, and management issues with Web services, in a simple BPEL process.

Mike Lehmann

http://www.oracle.com/technology/oramag/oracle/04-sep/o54web.html

Most software engineering books are written as textbooks. Geared at hapless students who typically don’t have a say in the course content, they often stray toward dry lists of term definitions and methodologies. Code Craft: The Practice of Writing Excellent Code claims to be “a survival guide for the software factory.” Indeed it is, but it’s also a brilliant software engineering book.

With language-agnostic advice that’s relevant to all developers, Code Craft covers code-writing concerns such as presentation style, variable naming, error handling, and security. And it tackles broader, real-world programming issues like effective teamwork, development processes, and documentation.

Pete Goodliffe

http://nostarch.com/frameset.php?startat=codecraft

Enterprise software is plainly problematic, no matter whose perspective you take - that of the vendor selling it, the buyer acquiring and operating it, or the people using it. It’s especially a nightmare to deploy and upgrade. Everybody suffers. Software as a service promises to address some of the ills afflicting product-based enterprise software. But a few flies might be lurking in the ointment.

Hakan Erdogmus

http://www.computer.org/portal/cms_docs_software/software/homepage/2007/S407/s4005.pdf

The Internet is quickly replacing the desktop as the medium of choice for modern application development. From its early days as a simple means for sharing information and communicating, the Internet has evolved into a modern day necessity. Consumers rely on the Internet for commerce, banking, email, instant messaging, and a variety of other daily tasks. This current evolution is often referred to as Web 2.0. This term has come to denote the personalization of the Web from streaming video (YouTube), social networking (MySpace), collaboration (blogs and wikis), and updated client technology (AJAX).These new technologies and trends have revitalized the Internet in terms of profitability and usability. With all of the new technology and innovation in Web 2.0, many consumers and professionals are wondering, what’s next? The answer just might be a dramatic move toward a service-oriented architecture (SOA).

Jared T. Howerton

http://www.computer.org/portal/cms_docs_itpro/itpro/homepage/2007/may_june/f3062.pdf

Chip manufacturers are currently talking about potentially doubling efficiency on a 2x core, quadrupling on a 4x core, and so forth. Some programs even run 18 times faster on a 32-core machine. In the past, it was typical to talk about improvements of 5 to 10 percent — rather than 400 to 1,800 percent — by parallelizing parts of an application. For a change, this is a change. Yet, multicore is useless without concurrent programming. A single-threaded application can exploit at most 1 percent of the potential throughput of a 100-core chip, so the reigning software development advice that “processors just keep getting faster, and we can get the benefit without doing anything” is over. Multicore chip manufacturers are calling for a new software revolution: the concurrency revolution. At first glance, this might seem surprising, for concurrency is almost as old as computing, and many concurrent programming models and languages have been invented over the years. In fact, this revolution is about more than concurrency alone, but rather concurrency for the masses.

Rachid Guerraoui

http://www.computer.org/portal/site/dsonline/menuitem.9ed3d9924aeb0dcd82ccc6716bbe36ec/index.jsp?&pName=dso_level1&path=dsonline/2007/08&file=w4tow.xml&xsl=article.xsl&

Microsoft Silverlight is a cross-browser, cross-platform plug-in for delivering the next generation of .NET based media experiences and rich interactive applications for the Web. Silverlight offers a flexible programming model that supports AJAX, VB, C#, Python, and Ruby, and integrates with existing Web applications. Silverlight supports fast, cost-effective delivery of high-quality video to all major browsers running on the Mac OS or Windows.

http://silverlight.net/