SE News

Object-oriented analysis and design have been more concerned with system functionality, neglecting non functional aspects; the result is code entanglement, difficult to maintain, contradicting main principles of object orientation. Aspect Oriented Software Development (AOSD) proposes the early specification of non functional requirements. However, a standard and homogenous vision of the AOSD terminology is still missing. The goal of this work is to integrate AOSD concepts, classic requirements engineering notions, and the new standard ISO/IEC 25030 on software quality requirements.

Isi Castillo,
Francisca Losavio,
Alfredo Matteo,
Jørgen Bøegh

http://www.jot.fm/contents/issue_2010_07/article4.html

In the Internet era, information is accessible to and published by everyone in a free and uncontrolled way. New technologies such as mashups and service-oriented computing let users search, query, and employ such data to provide new services. New data types, such as geographical and multimedia video, are becoming common in the day-to-day user experience. This incredible amount of available data introduces new challenging data quality problems, such as accessibility and usability. Low information quality is common in governmental, commercial, and industrial Web applications (including Web 2.0 tools). Consequently, information quality on the Web is one of the most crucial requirements for an effective use of Web data and the pervasive deployment of Web-based applications.

Elisa Bertino
Andrea Maurino
Monica Scannapieco

http://www.computer.org/portal/web/csdl/abs/html/mags/ic/2010/04/mic2010040011.htm

Given the critical importance of architecture to software project success, it follows that the architecture cannot be effective unless it is effectively captured in documentation that allows the architecture’s stakeholders to understand and use the architecture in the way it was intended. That is, the documentation of the architecture inherits the criticality of the architecture itself. An architecture that cannot be understood (or, worse, is misunderstood) because of deficient documentation will fail to meet its goals as surely as a poorly chosen architecture.

Put succinctly, if your architecture is not well described, it doesn’t matter if it’s well designed.

Robert Nord,
Paul C. Clements.
David Emery,
Rich Hilliard.

http://www.sei.cmu.edu/library/abstracts/reports/09tn030.cfm

As programmers, our first priority is creating code that works. Unfortunately, code that just “works” just isn’t good enough. To provide real, lasting value, code has to be clean. In “Clean Code: A Handbook of Agile Software Craftsmanship”, Robert C. Martin makes use of extensive examples and case studies to hone our ability to identifying code that has room for improvement, and provides a multitude of techniques to clean up code, just a little, every time we touch it.

This book belongs on the bookshelf of every developer who cares passionately about quality and craftsmanship. Less experienced developers will find it more valuable, and more of a slow read – this book is packed with good advice, without much “filler”. Martin uses plenty of examples, and uses clear, concise language, so although inexperienced developers will find it slow going, they are unlikely to feel lost.

Experienced developers would do well to give it a read as well. It will reinforce those things that you already know you should be doing (but which you don’t always do), remind you of a few things you’ve forgotten, and teach you a few new things as well. Most of all, it will give you a fresh perspective on all those seemingly mundane decisions you make hundreds of times a day.

Ryan Cooper

http://www.infoq.com/articles/clean-code-book-review

The Army Strategic Software Improvement Program (ASSIP) is a multiyear effort targeted at improving the way in which the Army acquires software-intensive systems. The ASSIP has funded a number of programs, in conjunction with the Carnegie Mellon Software Engineering Institute (SEI), to conduct software architecture evaluations using the Architecture Tradeoff Analysis Method (ATAM). Additionally, in cases when a system’s architecture did not exist or was not ready to evaluate, the ASSIP sponsored Quality Attribute Workshops (QAWs). During the period of this effort, several other programs funded their own ATAM evaluations and QAWs. The goal of this study was to determine the benefits associated with using the ATAM and QAW.

This special report describes the results of a study of the impact that the ATAM evaluations and QAWs had on Army programs. All 12 programs that used the ATAM and/or QAW responded to a questionnaire whose objective was to determine the impact of the experience in terms of the quality of the system, the practices of the involved program office, stakeholders, and suppliers, and the overall value of the engagement.

The data gathered confirms that the use of ATAM-based architecture evaluations and QAWs are generally beneficial to system acquisitions and suggests that maximal benefit is achievable only if architecture-centric practices are built into the acquisition process.

Robert L. Nord, John Bergey, Stephen Blanchette, Jr., and Mark Klein

http://www.sei.cmu.edu/publications/documents/09.reports/09sr007.html

Most programmers agree that another pair of eyes on your code will uncover bugs and disseminate knowledge across development teams. But many also recognize that peer review can waste a lot of time.

So how do you get started in such a way that you 1) don’t waste time, 2) match the process to your team and your goals, and 3) have a clear way to evaluate results? So many code review techniques exist, and each with pros and cons, so which are right for your team? Even if you’re unwilling to spend the time to review all your code, perhaps spending a little time reviewing a specific subset would be worthwhile.

The only way to know is to try it for yourself. Use these tips to simplify, expedite, and measure the process.

Jason Cohen
http://www.ddj.com/architect/215800147

Verification is an important part of any product development effort. Determining that the product satisfies its requirements is important in any market but in life-critical systems it is a legal requirement. Software product line organizations often have a goal of higher quality whether their products are safety-critical or not. In my opinion, the single most strategic mistake that organizations make in the early stages of software product line adoption is to limit verification activities to only software modules.

What I do propose to do is consider how the verification process might be expanded to accommodate the range of variation required for the scope of products in the product line and the range of assets constructed by the product line organization.

John D. McGregor
http://www.jot.fm/issues/issue_2009_03/column1/index.html

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

http://manifesto.softwarecraftsmanship.org/

Professionalität = Bewusstheit + Prinzipien

Softwareentwicklung braucht Profis. Was aber sind Profis? Menschen die mit der Softwareentwicklung Geld verdienen? Nein, das CcdTeam meint, es gehört mehr und anderes dazu.

Professionalität in der Softwareentwicklung hat nichts mit Geld zu tun. Sie hat auch nur bedingt mit einem bestimmten Ausbildungsweg zu tun. Wir kennen professionelle Softwareentwickler, die wenig oder gar kein Geld mit ihrer Software verdienen; und wir kennen professionelle Softwareentwickler, die weder Diplom noch Doktortitel haben.

[…] Wir glauben, die Branche sollte nach Anerkenntnis des Problems einfach mal nur einen kleinen Schritt machen. Weder müssen die Curricula von Masters-Studiengängen neu definiert werden noch ist die Gründung eines Verbandes zwingend.

Viel einfacher glauben wir, dass “es” schon besser würde, wenn wir alle auch nur ein Buch gemeinsam gelesen hätten. Schon die vereinte Zustimmung zu den Aussagen in nur einem Buch würde einen Konsens herstellen, der viel bewirken könnte.

Wir meinen, mit Clean Code von Robert C. Martin solch ein Buch gefunden zu haben, das der gemeinsamen Lektüre würdig ist.

Es ist kein perfektes Buch und auch wir stimmen nicht allem darin vorbehaltlos zu - aber es ist ein Buch “im rechten Geist”: es ist ein Ausdruck profunder Reflektion und hat den Mut, ein fundamentales Wertesystem zu formulieren.

[…] Letztlich ist aber auch das nicht in Stein gemeißelt. Morgen erscheint vielleicht ein noch besseres Buch. Gut so! Aber an dem, was wir meinen, dass Professionalität ausmacht, ändert das nichts. Deshalb fangen wir einfach mal an. “Nicht lang schnacken, Kopf in Nacken” - so sagen die Hamburger, wenn sie einen Korn (norddeutscher Schnaps) in der Hand haben. Und so wollen wir es auch halten: Ganz im Sinne der Agilitätsbewegung nicht planen bis zur Bewusstlosigkeit, sondern etwas tun. Einen kleinen Schritt machen in Richtung mehr Professionalität.

Wer hat Lust mitzumachen?

Wer will CleanCodeDeveloper werden? Es ist ganz einfach!

http://www.clean-code-developer.de/

As enterprises demand more accountability for IT costs and contributions, application quality metrics will become required inputs for managing, developing, and evolving applications. Although software metrics have existed for at least three decades, the use of metrics other than size (lines of code, function points, etc.) has been infrequent. The demand for better measurement is being driven by the growing impact of application software quality on the business.

Bill Curtis

http://www.ibm.com/developerworks/rational/library/edge/08/jul08/curtis/index.html

U.S. Department of Defense (DoD) program managers care about how well the software-intensive system they are developing will perform for the warfighter. They are not particularly interested in software architecture, at least not as architecture.

But through efforts made by the SEI, they are gaining an understanding that the architecture of the software-intensive systems they are developing significantly determines whether those systems will be reliable, secure, and safe - characteristics known as nonfunctional or quality attributes.

John Morley

http://www.sei.cmu.edu/news-at-sei/features/2008/07/01-feature-2008-07.html

I’ve seen various taxonomies of requirements. Like all taxonomies, any set of requirement types exists to classify or partition requirements into coherent groups for further analysis. Most break down the list of requirements into things reminiscent of “who or where the requirement comes from.”

For example, one taxonomy I’ve seen recently described:

Business Requirements - high level business goals
User Requirements - the user experience needs
Functional Requirements - business process or functionality needs
Non Functional Requirements - all other requirements (like quality attributes)

Another taxonomy may be:

Information requirements - needs for information storage
Functional Requirements - needs for functionality
Non-functional requirements - all other requirements

I’ve seen others as well. Most will have a category that contains “non-functional” requirements. And there’s where my heartburn lay.

Nick Malik

http://blogs.msdn.com/nickmalik/archive/2008/10/13/non-functional-requirements-the-all-other-classification.aspx

Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.

Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it.

What kind of work will you be doing? You’ll be reading code—lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft.

Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code—of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.

http://www.pearsonhighered.com/educator/academic/product/0,3110,0132350882,00.html

Every enterprise now lives and dies by the data stored on its computers and networks, and none can long survive if that data isn’t accurate and reliable. In addition to the damage that can come from the actual alteration of data, the impact on a company’s reputation can be substantial if customers are faced with unreliable, poor-quality products. Quality assurance (QA) and information assurance (IA) programs play crucial roles in protecting assets and developing trustworthy products and services.

Jeffrey Voas,
Linda Wilbanks

http://csdl2.computer.org/comp/mags/it/2008/03/mit2008030010.pdf

Vindt u kwaliteit vanzelfsprekend “Must Have”, of moet hieraan speciale aandacht worden besteed “Nice to Have”? Is te veel of te weinig aandacht voor kwaliteit een risico voor uw Business of voor uzelf? Zijn we verwend met kwaliteit en weten we niet meer hoe het zonder kwaliteit was en kunnen we ook niet met ietsjes minder of zijn we dan gelijk ontevreden? En, wat hebben we tot nu geleerd van mislukkingen en successen in tal van ICT projecten?

Over dit soort van kwesties willen wij op deze woensdagmiddag met u van gedachten wisselen. We gaan daarbij in op hetgeen we hebben geleerd van Q (de “best practices”), hoe het staat met de menselijke maat van Q (de ‘human factor”) en hoe de toekomst van Q eruit ziet (de Future of Quality).

http://www.st-spider.nl/QProfs/Voorjaar2008.php