Hello, World! You’re reading the first issue of The Software Practitioner’s Digest, covering resources published during October 2011.
Computer
The October issue of Computer features articles on Software Engineering and how it meets other fields.
Can Practitioners Neglect Theory and Theoreticians Neglect Practice?
Manfred Broy explains the importance of theory in software development and why it is often not applied in practice.
Software Engineering – Missing in Action: A Personal Perspective
In this thought-provoking and controversial article, David Parnas explains why software development should — but hasn’t yet — become an engineering discipline and mentions key impediments that need to be overcome for this to happen.
Open Source Software: Lessons from and for Software Engineering
Brian Fitzgerald discusses the best practices commonly leveraged by FLOSS projects and highlights ideas which could be borrowed by the broader software development community, while also considering inherent limitations and common shortcomings in this environment like the lack of feedback on design issues.
The author starts by claiming that FLOSS advocates consider this model a “silver bullet”, but provides no references to support such claims, and that made me read the rest of the article with caution. This was unfortunate as the rest of the article was fairly objective and based on sound research.
Software Engineering Meets Services and Cloud Computing
This is a very good overview of Service-Oriented Software Engineering and Cloud Computing. The authors, Stephen Yau and Ho An, also identify seven challenges in these paradigms and discuss approaches to deal with them.
I was confused by the term “Service-Oriented Software Engineering” as it sounded like what I knew as “Component-Base Software Engineering”. A paper from EUROMICRO 2007 was the only document I could find that explains the difference: Put simply (and inaccurately), both are paradigms for building software that consume services provided by independent and external applications, but in SOSE your software determines which external applications to use at runtime (among the ones proving the services it needs), while in CBSE the services to be used are bound during construction. The two paradigms can be combined as they’re not mutually exclusive.
SESO and CBSE are indeed not that different and much of this Computer magazine article also applies to CBSE.
Related reading:
- Software Engineering by Ian Sommerville has a chapter dedicated to CBSE. I think this is a very good introduction to the subject.
- Developing Cloud Business Models: A Case Study on Cloud Gaming by Arto Ojala and Pasi Tyrväinen. This article, published in the July issue of IEEE Software, explores Cloud Computing from a business perspective.
Software Engineering Meets Evolutionary Computation
In this article, Mark Harman talks about successful applications of Evolutionary Computation and Search-based Software Engineering in general. I think the introduction to the subject isn’t very good and it’s fair to say that the author assumed prior knowledge.
Related reading:
- Search Based Software Engineering: Introduction to the Special Issue of the IEEE Transactions on Software Engineering. This is a better introduction to the subject, for those who are not familiar with it. It was co-authored by the same person who wrote this article in Computer.
IEEE Software
The theme of the September/October issue of IEEE Software was games development, which means that a group of articles were related to this.
Gardening Your Architecture, Part 2: Reengineering and Rewriting
This is the last of the two-part series by Frank Buschmann, covering three key techniques to improving an existing system’s architecture: Refactoring, Reengineering and Rewriting. This definitely is a must-read for software developers.
Related reading:
Strategies Facilitating Software Product Transfers
Darja Smite and Claes Wohlin present their findings in the process of transferring the development of a software product from one team to another, from their studies on offshore transfers at Ericsson, including the circumstances in which transfers should ideally be made.
It’s a wrap!
After going through the time-consuming and exhausting process of moving home a few weeks ago, I wasn’t intending on starting this digest in November given that I couldn’t read a third of the sources I follow in the past month. But then I felt motivated by the articles published in Computer, which address the very reason why I am doing this. I just couldn’t let them slip by.
Future issues of The Software Practitioner’s Digest will not be limited to articles from IEEE-CS magazines and will cover different aspects of software development in addition to construction-related ones, like HCI and business considerations.
I guess RERO advocates would be proud of me — Don’t let them down and tell me what you liked and disliked about this digest and why!
Your SOSE vs CBSE differentiation is only describing late vs early binding. Component based systems often use late-binding (ex. plug-ins). So either there is something else important about SOSE or folks are just recycling the same old ideas to write new papers.
@davidk, you’re correct in that the differentiation I offered is is limited, hence I started by saying that my explanation was inaccurate. I was afraid to diverge too much by offering a more accurate explanation and I thought that binding time was the most significant difference.
In the EUROMICRO paper I mentioned above, the authors point out that late binding is also possible in CBSE and cite COM as an example. They cover other differences which, in my opinion, are not as significant as binding time.
Looked from another perspective, services in SOSE are black boxes for their clients, while CBSE allows components to be used as white, gray or black boxes. I’d imagine this distinction can be useful in areas like critical systems development, where redundancy and diversity strategies like NVP are used and SOSE could potentially be deemed the only acceptable paradigm.
@Gustavo Thanks to the reference to the EUROMICRO paper. Although I only skimmed the paper it seems to me looser-coupling is the main difference. I take away that SOSE is a subset of CBSE with some design flexibility removed by sticking to the same choice for certain thing (like location independence). If SOSE is a ‘good’ paradigm then the removed flexibility was in areas where people frequently made poor choices or always he same choice. Hopefully we’ve learned something from CBSE and taken the best parts/practices forwards to make SOSE. [Although personally I think it’s just a new name for making the obviously correct choices when building software.]