Journyx Project Management Blog

A large body of literature has appeared over the past three or four decades on how developers can measure various aspects of software development and use, from the productivity of the programmers coding it to the satisfaction of the ultimate end users applying it to their business problems. Some metrics are broader than others. In any scientific measurement effort, you must balance the sensitivity and the selectivity of the measures employed. Here we are primarily concerned with the quality of the software end product as seen from the end user’s point of view. Although much of the software metrics technology used in the past was applied downstream, the overall trend in the field is to push measurement methods and models back upstream to the design phase and even to measurement of the architecture itself. The issue in measuring software performance and quality is clearly its complexity as compared even to the computer hardware on which it runs. Managing complexity and finding significant surrogate indicators of program complexity must go beyond merely estimating the number of lines of code the program is expected to require.

Read more at: Developer.com

Mock objects are useful when performing unit testing and can provide a best solution in terms of testability. I will present the new NMock 2.0 (Release Candidate 1) library and show how you can use it to implement mock objects.

Mock objects are used as abstractions for dependencies of a class under test and are used to effectively isolate the class under test to ensure proper test verification. For example, if Class A uses a class that is an abstraction for a network service, I don’t want to have to go through the effort of setting up a connection and verifying connectivity just to be able to test. Therefore, I create a mock for the other class, and define how it should behave. I then write my tests for Class A based on the expected behavior of the dependency. This effectively decouples a class from its dependencies and makes the entire development and testing process much more smooth.

A mock object is a testing pattern that is used to test interfaces rather than specific implementations of classes. This is done by defining the expectations of the methods of those classes, and then verifying that your expectations were met after calling the methods. This can be useful for classes that are not yet developed, difficult to setup for testing, or dependent on an external resource such as a database or web service, or for classes that perform prohibitively slowly, such that the execution time for the unit tests using the actual implementation would be too great.

Read more at: Developer.com

Shaygan Kheradpir, CIO at Verizon Communications Inc., gets several mostly cordial instant messages each day from line-of-business workers — like customer service representatives — asking for help with their IT systems.

Kheradpir, whose IM address is available to all of the company’s 250,000 employees, largely credits the company’s four-year-old service-oriented architecture (SOA) for a comfortable relationship between Verizon’s IT and business groups. He said the SOA has eased low-level technical work, giving IT developers more time to work with end users when building applications.

Verizon’s CIO spoke at the BEAWorld 2006 conference, held here last week, where he and other users said they are expanding their focus on SOA and eyeing an emerging set of tools that promises to better nurture the relationship between business and IT, which has often been thorny.

At the conference, San Jose-based BEA brought out a new middleware offering, SOA 360, that includes components aimed at improving companywide collaboration on development projects.

Read more at: Computerworld

Some shops develop mobile applications the way a Boy Scout rolls his sleeping bag: fold, press air out, roll, press and repeat until you can stuff it in the nylon sack and tie the pull-string tight. Companies likewise take a desktop app, remove all the white space in forms, rearrange fields to fit tiny screens, shrink the database and jam the package into a mobile device. In this case, though, it’s not a pull-string but a noose they’re pulling tight, damning the application project to a slow, painful death at the hands of its own inflexibility and dearth of usability.

Repeat after us: Mobile applications are not the same as desktop applications. Mobile application deployment cannot be compared with rolling out the latest version of Microsoft Office to PCs on the corporate network. Mobile applications feel different, the hardware is smaller, and connectivity is limited and sporadic. Unfortunately, as we discuss in “Mobile Version of the Valdez”, the mobile-application ecosystem has been thoroughly polluted by the consumer-focused character of wireless carriers. It isn’t easy for an enterprise to completely meet its needs without assembling the parts itself. Never fear: Here’s a 10-step road map to ensure a successful rollout.

Read more at: Dr. Dobb’s Portal

It’s pretty rare for a software development project to go perfectly. In fact, although developers tend to have eternal faith that the next project will succeed completely according to plan, I can’t think of a single project that I’ve been involved with over the past 25 years that went off without a hitch. Dealing with bugs, sudden requirements changes, hardware and software that break down mid-project, unexpected personnel turnover, baffling interactions between components, malevolent servers, and incompetent subcontractors seem to be the order of the day. The question is not so much whether you’ll get hit with something unexpected, as how you’ll deal with it - and what you can learn from it for the next project.

The difference between average programmers and excellent developers is not a matter of knowing the latest language or buzzword-laden technique. Rather, it can boil down to something as simple as not making the same mistakes over and over again. Fortunately, there’s a powerful tool that any developer can use to help learn from the past: the project postmortem.

Star in your very own CSI at: http://journyx.com/rss/redir/developer-postmortem.html

Does your company struggle to brainstorm new products and services? Virtualization tools such as road-mapping software and patent-citation systems offer insight into the pipeline of promising ideas. Here’s how to pick technologies that fit your innovation approach.

Situational awareness is “the perception of elements in the environment … the comprehension of their meaning and the projection of their status in the near future,” according to Dr. Mica Endsley, an expert on systems supporting human decision making.

One business equivalent of situational awareness is “innovation insight,” an emerging area that is helping leading companies stay ahead of ever-faster demand cycles. Innovation insight is about analyzing and understanding your efforts to innovate, including the people involved, the processes used and the outcomes achieved. To gain insight into projects, market positioning and corporate performance, you can view Gantt charts, two-by-two matrices and balanced scorecards, respectively. Like these other forms of business insight, innovation insight depends on visualization to make it easy for managers to see the state of your initiatives and to tweak and tune those efforts.

Innovation is big business. According to a 2005 survey by Booz Allen Hamilton, the world’s top 20 innovators alone invested more than $110 billion on research and development. In this, the first article in a series on innovation, we’ll explore some of the software applications you can use to gain insight into innovation efforts and manage them more effectively. Next month we’ll examine the three approaches to innovation and how they can be turned into predictable business processes.

Read more at: Dr. Dobb’s Portal

People new to the idea of agile software development think that you can only be agile with small, co-located teams where you have no political constraints. Yes, that’s ideal, but most teams aren’t lucky enough to be in that situation. Does that mean they should give up on agile techniques? No! It means that they need to be smart about how they apply agile concepts and be as agile as possible given their current situation. This month, I explore strategies that people have used when they found themselves in not-so-ideal situations.

Dispersed Agile Development

In June I participated in the Perspectives on Systems Informatics at Akademgorodok, Siberia where I ran a tutorial on agile software development. After the tutorial, a couple of people came up to me and said this agile stuff was great in theory, but that it wouldn’t work for them. One person worked in an outsourcing company where their clients were in Europe, and another worked for a company where the development team was split between Copenhagen and Moscow. Both were convinced that because their team wasn’t co-located that they couldn’t be agile. Nothing could be further from the truth.

Ideally, you want to co-locate your developers and stakeholders to improve their ability to collaborate and communicate, thereby reducing cost (they don’t need to document as much) and risk (you increase the chance that they understand each other) on your project. In practice, many teams find themselves in a dispersed, multilocation environment and must find ways to overcome the inherent communication barriers. In “Bridging the Distance” (www.ddj.com/dept/architect/184414899), I describe strategies for doing exactly that. Dispersed agile teams will begin a project together so as to build a common vision, will get together occasionally to fortify that vision, and will have people traveling back and forth between locations as needed. They’ll also adopt collaborative tools such as chat software, desktop sharing software, and Wikis. They’ll communicate with each other via e-mail, telephone/video conferencing, and (egads!) even some written documentation.

Read more at: Dr. Dobb’s Portal

Managing a large group of scientists, jokes Milton Smith, can be like “corralling cats.” That’s particularly so if the scientists whose work you’re overseeing are based in medical schools and private- and public-sector labs scattered throughout the U.S. and Canada. The organizations Smith is working with make up the Advanced Medical Countermeasures Consortium, a group developing a drug-delivery therapy to serve as a first-response stabilizer for people exposed to avian flu H5N1, anthrax or mustard gas. To organize and delegate the research that’s being conducted, Smith and his partners use Mindjet’s MindManager.

While research on the therapy has received some federal funding, thus far the consortium has gotten no backing from private drug companies. “By using universities, we had a low-cost method of doing research and development, but we had to manage a complex task involving many components,” says Smith. Smith is a physician and president of Paw Paw, Mich.-based Amaox Ltd., a biotech company established in 1992 to study the therapeutic benefits of liposomes and that now acts as a bridge between government agencies and universities for the consortium effort. “The only way I could manage all these collaborators and the components they were working on was to use mind mapping,” he says.

Read more at: Computerworld

Want to complete a project successfully?

Then you’d better have success at the start. That means getting requirements right, and there are as many ways to do that as there are business analysts charged with getting it done.

But impatience, miscommunication, misunderstandings and overlooked users can produce requirements that aren’t clear or complete. ‘You want to have as little ambiguity as possible, because ambiguity creates defects,’ says Andrew Ari Clibanoff, a senior business analyst at GSI Commerce Inc., a King of Prussia, Pa.-based provider of e-commerce services.

Those defects can be costly. Ellen Gottesdiener, principal consultant at EBG Consulting in Carmel, Ind., and author of ‘The Software Requirements Memory Jogger’ (Goal QPC Inc., 2005), says that roughly one-third of the budget for a typical project goes to fixing defects that originated in faulty requirements.

The following tips will help you avoid becoming part of that depressing statistic…

Start understanding your users at: http://www.journyx.com/rss/redir/cworld-userswant.html

Software Developers are a tough audience. Why, I’d be willing to bet that even the likes of Jerry Seinfeld would tuck tail and take off from a roomful of programmers.

Take Java, for example. For years, Sun has been kicked around for not open sourcing Java (see www.catb.org/~esr/writings/let-java-go.html). So when Sun’s Rich Green made a public commitment to open source Java, you’d think the griping would pause for a second or two. And it did—for a second or two. At issue was that Green didn’t hand over the Java source code Johnny-on-the-spot, instead promising to do so in the future. “It is not a question of ‘whether,’” he said, “but it is a question of ‘how.’” So the announcement was really an announcement of an upcoming announcement.

I can live with that, but I’m more patient than, say, Richard Stallman, who saw Sun’s contribution to the free software/open-source community as “absolutely nothing” (www.newsforge.com/article.pl?sid=06/05/24/1154233). Well, Sun has open sourced Solaris, its Java Studio Creator and NetBeans Enterprise Pack tools, Java System Portal Server, BPEL Engine (from Java CAPS), a JMS-based message queue, and its Web Services Interoperability Technology (WSIT). Open Source Java will come, and Green and CEO Jonathan Schwartz will figure out how to make that happen.

Read more at: http://www.ddj.com/dept/architect/189401981