SE News

WHICH WAY SHOULD WE GO? Christopher Columbus had a clear answer to that question when his project team set sail from Spain in 1492. His intention was clear: sail to the West to find an easier way to get to the East. Along the way, however, he ran into some unexpected land masses that weren’t on his map. His intentions may have been clear-cut, but his expectations were slightly skewed from reality.

And so it also goes for some of us who intend to launch a test automation process.

Test automation can be an effective route to success for some, but others never seem to reach their intended destination. Like Columbus, their expectations can be quite different from the experiences they encounter on their journey, and teams can become stalled. Those who have been around the test automation block a few times will tell you that’s not unusual; many of them would say they’ve had to modify their original perspective as they’ve learned their craft.

Kerry Zallar

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

Many people incorrectly judge Java/J2EE-based systems on problems associated with maintaining the codebase, the number of bugs or inconsistencies in functionality, or poor performance. Fortunately, these problems have less to do with the Java/J2EE technology itself and more to do with the lack of a process focused on the quality of the system. To ensure success of large-scale Java/J2EE projects developed by a sizeable team, or across multiple teams, a team lead must: - Use tools that can measure quality - Define a set of gates and artifacts derived from the tools - Stress accountability to deliver, monitor, and enforce the results

This article explains how incorporating these three tactics into your development strategy can ensure that your team consistently produces quality projects.

Jimmy Jarrett

http://www.javaworld.com/javaworld/jw-01-2005/jw-0110-quality.html

Good requirements have several useful properties, such as being consistent, necessary, and unambiguous. Another essential characteristic that is almost always listed is that ‘requirements should be complete.’ But just what does completeness mean, and how should you ensure that your requirements are complete?

In this column, we will begin to address these two questions by looking at (1) the importance of requirements completeness, (2) the completeness of requirements models, (3) the completeness of various types of individual requirements, and (4) the completeness of requirements metadata. In next issue’s column, we will continue by addressing (5) the completeness of requirements repositories, (6) the completeness of requirements documents derived from such repositories of requirements, (7) the completeness of sets of requirements documents, (8) the completeness of requirements baselines, and finally (9) determining how complete is complete enough when using an incremental and iterative development cycle.

Donald Firesmith

http://www.jot.fm/issues/issue_2005_01/column3

This technical note fits the architecture-centric methods of the Carnegie Mellon Software Engineering Institute (SEI) into the framework of Extreme Programming (XP). These methods include the Architecture Tradeoff Analysis Method, the SEI Quality Attribute Workshop, the SEI Attribute-Driven Design method, the SEI Cost Benefit Analysis Method, and SEI Active Reviews for Intermediate Design. This report presents a summary of XP and examines the potential uses of the SEI’s architecture-centric methods.

Robert L. Nord James E. Tomayko Rob Wojcik

http://www.sei.cmu.edu/pub/documents/04.reports/pdf/04tn036.pdf

The success of a message-oriented system, regardless of the technology used to implement it, depends upon the consistent and reliable delivery of messages between processes. In this installment of Quality busters, Michael Russell identifies some of the places or failure points along the path between processes where a message can be lost or rejected. If you don’t properly address these failure points, the results might include data corruption, out-of-sync conditions, timeouts, and perceived unreliability.

Michael Russell

http://www-106.ibm.com/developerworks/web/library/wa-qualbust11/

Set application performance goals through a life-cycle commitment in which attention to response time and scalability result in better business value.

It can be hard to believe that in an era of three gigahertz servers with four gigabytes of memory, hard disks with ten millisecond access times, and gigabit Ethernet and fiber optic networks that business applications still face significant performance and scalability limitations. However, a combination of more complex and demanding applications, additional users, an increasingly complex infrastructure, and a greater need for real-time information means that faster hardware may never be the answer to maintaining satisfactory application performance.

Getting control of application performance requires that user response and scalability be on the minds of everyone involved in the application life cycle: architects, designers, developers, testers, and system managers. Perhaps the most important participants are the application users themselves, who need to define performance as a critical application characteristic.

Peter Varhol

http://www.fawcette.com/javapro/2004_11/magazine/features/pvarhol/

As software systems became more plastic, new, more complex technologies came to dominate. Today we have objects. Programmers are instructed to think of the elements of their domain and their implementation as “things” with “state” and “behavior”, and to code that state and behavior. Linearity and planarity have decreased. Inheritance allows statements asserted in distant ancestors to intrude in program execution; dynamic object binding draws bridges over the program surface.

In all domains, old ideas give way or evolve to new ones. What is the postmodern programming equivalent? That is, what comes after object-orientation?

Robert E. Filman

http://dsonline.computer.org/portal/site/dsonline/menuitem.6dd2a408dbe4a94be487e0606bcd45f3/index.jsp?&pName=dso_level1_article&TheCat=1001&path=dsonline/0501&file=w1eic.xml&

This repository is designed for managing assets packaged according to the Object Management Group’s (OMGTM) Reusable Asset Specification (RAS) and for facilitating sharing among small teams or workgroups. This specification was recently adopted by the OMG.

http://www.alphaworks.ibm.com/tech/rasr4w?Open&ca=daw-hp-pr

The JUnit framework is the current one-stop solution for Java language unit tests. This framework deserves praise for introducing the idea of test-driven development to Java developers and teaching them how to effectively write unit tests. However, JUnit has only marginally evolved during the last few years; thus, writing tests for today’s complex environment has become an increasingly difficult task, in which JUnit must be integrated with several other complementary test frameworks. In this article, Filippo Diotalevi introduces TestNG, a new framework for testing Java applications. TestNG isn’t just really powerful, innovative, extensible, and flexible; it also illustrates an interesting application of Java Annotations, a great new feature in JDK 5.0.

Filippo Diotalevi

http://www-106.ibm.com/developerworks/java/library/j-testng/

As some of you might know, Stefan Roock and myself are working on a book about large and complex refactorings. The central chapters deal about large refactorings, API refactorings and database-related refactorings. We have finished the first version of the completely translated manuscript these days. Maybe some of you are interested in taking a look at it? Any feedback is appreciated!

This manuscript is a translated version from the german version, so please be patient regarding misused or wrongly translated words.

Thank you all in advance for the feedback.

Martin Lippert

http://www.stefanroock.de/downloads/LargeRefactoringsReviewVersion.pdf http://www.martinlippert.org/publications/review/LargeRefactoringsReviewVersion.pdf

Hierbij wil ik u uitnodigen voor de bijeenkomst van het
Platform voor Productsoftware op woensdag 23 februari. De
bijeenkomst wordt dit keer gehost door Exact Software te
Delft en het thema van deze bijeenkomst is:

Uitlevering van software via Internet.

Voor leveranciers van software producten wordt het steeds
moeilijker om software configuraties bij hun klanten te
beheren en controleren. De software draait op uiteenlopende
hardware en software platforms en is vaak voor een specifieke
klantinstallatie geparametriseerd of geoptimaliseerd. Op dit
moment worden bij veel bedrijven deze configuraties als
gedetailleerde lijsten van software semi automatisch
bijgehouden. Maar wat zijn de ontwikkelingen op het gebied
van delivery van product software? Welke technologieën zijn
beschikbaar off-the-shelf? Bij de volgende bijeenkomst van het
Platform voor Productsoftware wordt ingegaan op de strategieën
van andere bedrijven en de mogelijke oplossingen uit de
industrie voor de correcte uitlevering van software configuraties.
Het doel van de bijeenkomst is het oprichten van een groep
geïnteresseerden op het gebied van software delivery.

Er zijn geen kosten aan deelname verbonden. Graag aanmelden voor
deze bijeenkomst via een reply mail aan s.brinkkemper@cs.uu.nl.

Sjaak Brinkkemper - Voorzitter Platform Productsoftware

http://www.productsoftware.nl/

De inhoud van januari 2005 van het maandblad Informatie was tijdens het opstellen van deze editie van SE-Nieuws nog niet bekend bij de SE-Nieuws redactie.

De redactie verwacht dat de inhoud van het januari-nummer spoedig op de website van Informatie, http://www.informatie.nl, geplaatst wordt.

http://www.informatie.nl/