bookmark_borderEclipse IDE for C++

I’ve been working with Eclipse for at least 2 years. When I just learned of Eclipse I was mostly programming C / C++ using Visual Studio 6, which I bought zillion years ago.

Eclipse was a whole new world to me, offering all the convenient tools (like finding references, go to class, etc) a Java programmer could need. 

All my hobby projects are mostly written in C / C++ using the old Visual Studio version. It worked well, but after getting used to Eclipse, going back to Visual Studio 6 was like going back to the stone age. Of course, at this time Visual Studi0 7 is already out-dated; If I’m not mistaken, version 9 or 10 is around the corner.

Good news though, there is an Eclipse version where you can develop in C / C++ using the Eclipse IDE. It is available here. You have to use it in combination with a compiler. To get started, I have used MinGW which is easy to set up. Grab that from here

The good thing is, once MinGW was set up correctly, Eclipse automatigically found it (I bet it used the PATH variable) and you could try to compile your first “Hello world” program. 

My first impressions are good, the C++ IDE is actually like the Java variant with all the handy tools.  The performance is good, it works good, It has Doxygen built in for you. All in all I am quite satisfied. Also, I am quite happy that it exists, since Dev-Cpp and Code::Blocks is not being updated. I thought Dev-Cpp had a lot of potential, especially with the built-in packages.

If you ever consider to use an IDE (you don’t need it!) for writing C / C++ programs, you should definately give the Eclipse IDE for C++ a try.

bookmark_borderRequirements, requirements, requirements…

Recently I am studying an important topic regarding system development, called requirement engineering. A great book covering this topic is from Sommerville, Software Engineering (version 8). 

What I find fascinating is that, from a developer perspective, it is hard to tell if what you’re creating is actually that what the customer wants. Although I am used to using Functional Design’s, which cover the requirements, there are always multiple filters applied to those requirements (and their documents). And, even when finally a developer is building the software, the developer has its own filter applied as well.

The so called ‘gap’ that exists can be minimized by making the language, used for writing requirements, more abstract. Even so, there is simply not enough time to formally write requirements, like how it is done with formal specifications. Unless you’re writing requirements and the needed systems for critical systems (like a nuclear powerplant, aircraft, etc), there will always be gaps.

Something I’ve noticed is that it is also hard to verify if the end-result is actually what the customer defined in their requirements. Or, sometimes it could be that 2 or more requirements simply conflict with eachother. It should not be a problem, when these requirements are discovered early in the process. The real fun begins when these conflicting requirements are discovered later.

The good thing is there are always solutions around the corner, a little agile software development can do miracles and speed up the discovery of ‘gaps’. Using short(er) iterations to confirm your design has proven quite effective. Even when creating ‘just’ requirement specifications. 

I’ve had the pleasure of following a process of discovering requirements and I’ve learned a lot from it. Although I am not an Information Analist, nor a requirement elicitator expert, I did find something interesting about the whole requirement specification process. In one word i could define it as scope.

Somehow determining the scope of the requested functionality versus the requirements it has effect on is easily widened. This is not nescesarily a bad thing, because it is good to know what requirements are effected by a new requirement, or a change in requirement(s).

The problem lies within the complexity which is introduced by cristalizing all the details for all requirements that are ever hit. In my opinion there is a role for the company that actually creates the requirements documents, and the stakeholder(s) who continiously have new, or changed, requirements for their system. 

The role of the company, responsible for creating the system and the requirement documents, should make clear to the stakeholders what effects their requirements have on other requirements on a high-level. Even though there will be effects on the lower level(s), it should be possible to ask for faith, and trust, in your work. It should be possible to ask for an approval on high level requirements, in order to ‘drill down’  to the details. Whenever every detailed question needs to be answered in order to have the high-level requirements being accepted, it will cause multiple (unwanted) effects:

– the requirements remain unclear, and can still change. The context is not defined.
– because no decisions are being made, discussing details could be a waste of time.
– when taking all details into account, the complexity increases significantly. Making it even harder to decide what effect is acceptable for a needed change.

Again, I am no expert. But this is the vision I have built up the past few weeks. I am wondering what others think. If you have any comments then I’d like to hear them.