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

I have never written a bad line of code.

When I tell people that, they often scoff and offer replies like “so you’re not a programmer then?” and “let me guess, you’re a coding deity or something?” Well let me say, I am a programmer and I am not Codethulu, but in the same manner that Al Gore can fly around the world in a private jet without polluting, I have negated my bad code footprint through the purchase of Bad Code Offsets.

Alex Papadimoulis

http://thedailywtf.com/Articles/Introducing-Bad-Code-Offsets.aspx

This report provides guidance for those who want to make the business case for building software assurance into software products during each software development life-cycle activity. The business case defends the value of making additional efforts to ensure that software has minimal security risks when it is released and shows that those efforts are most cost-effective when they are made appropriately throughout the development life cycle. Although there is no single model that can be recommended for making the cost/benefit argument, there are promising models and methods that can be used individually and collectively for this purpose, as well as some convincing case study data that supports the value of building software assurance into newly developed software. These are described in this report.

Nancy R. Mead
Julia H. Allen
W. Arthur Conklin
Antonio Drommi
John Harrison
Jeff Ingalsbe
James Rainey
Dan Shoemaker

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

So you want to design, write and refactor code like a seasoned pro but are unsure of what direction to take and how to navigate around pitfalls and obstacles to get the best results? It would be great if there was a design compass that showed the way to a code shangrila where inversion of control, loose coupling, testability, reuse and more are bountiful.

A design compass does exist and this article will show you how to obtain and use the compass to achieve code that leaves you with time to do other things or just enjoy the tranquility and confidence that comes from having great code that does more. Seasoned professionals may also put the compass to use in finding hidden gems of functionality and dependencies that can be inverted or to help direct design or testing efforts towards a more fruitful result, but whatever your level, a compass can certainly come in handy in getting from place A to B.

James Ladd

http://jamesladdcode.com/?p=12

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

We’re charged with the task of writing software that is reliable, sturdy, and trustworthy. We could all write tests and extensive preconditions for our code, and choose languages which make errors less likely, but across the industry we don’t do any of these things uniformly. Michael Feathers looks at error-prevention in the short history of our discipline and considers our possible futures.

Michael Feathers
http://www.infoq.com/presentations/error-prevention-ethics

Experts from more than 30 US and international cyber security organizations jointly released the consensus list of the 25 most dangerous programming errors that lead to security bugs and that enable cyber espionage and cyber crime. Shockingly, most of these errors are not well understood by programmers; their avoidance is not widely taught by computer science programs; and their presence is frequently not tested by organizations developing software for sale.

The impact of these errors is far reaching. Just two of them led to more than 1.5 million web site security breaches during 2008 - and those breaches cascaded onto the computers of people who visited those web sites, turning their computers into zombies.

http://www.sans.org/top25errors