Tag: programming

Frequently Forgotten Fundamental Facts about Software Engineering

Here are some jewels about Software Engineering that are worth reviewing. I recommend the rest of the article. It’s an oldie but goody!

Recently I have been doing a lot of work deciphering “other people’s code”. I would say the largest part of the work has been in error detection and removal. Even a seemingly comprehensive test plan does not make me terribly confident. I have been humbled by logic problems and faulty design requirements too many times.

Reliability

RE1. Error detection and removal accounts for roughly 40 percent of development costs. Thus it is the most important phase of the development life cycle.

RE2. There are certain kinds of software errors that most programmers make frequently. These include off-by-one indexing, definition or reference inconsistency, and omitting deep design details. That is why, for example, N-version programming, which attempts to create multiple diverse solutions through multiple programmers, can never completely achieve its promise.

RE3. Software that a typical programmer believes to be thoroughly tested has often had only about 55 to 60 percent of its logic paths executed. Automated support, such as coverage analyzers, can raise that to roughly 85 to 90 percent. Testing at the 100-percent level is nearly impossible.

RE4. Even if 100-percent test coverage (see RE3) were possible, that criteria would be insufficient for testing. Roughly 35 percent of software defects emerge from missing logic paths, and another 40 percent are from the execution of a unique combination of logic paths. They will not be caught by 100-percent coverage (100-percent coverage can, therefore, potentially detect only about 25 percent of the errors!).

RE5. There is no single best approach to software error removal. A combination of several approaches, such as inspections and several kinds of testing and fault tolerance, is necessary.

RE6. (corollary to RE5) Software will always contain residual defects, after even the most rigorous error removal. The goal is to minimize the number and especially the severity of those defects.

Frequently Forgotten Fundamental Facts about Software Engineering

Notes on Setting up the Eclipse C++ IDE on Linux

Since I had recently setup my laptop with C++ version of Visual Studio 8 Express, I was curious about setting up a similar IDE environment on Linux. I initially tried to set up Anjuta DevStudio and I failed miserably. I am running CentOS 5.1. There does not appear to be a recent RPM of Anjuta. I stumbled badly when I tried to manually install the dependencies and quickly became inspired to look for an IDE solution that would set up as easily and quickly as Visual Studio Express. Eclipse was the obvious answer.

So I went to the Eclipse site and downloaded the Linux version of the Eclipse IDE for C/C++ Developers. After I had uncompressed the file I tried running Eclipse and it did not work. It was complaining that my version of Java needed to be at least 1.5. Although I had installed a newer version of Java JRE, Eclipse was finding the 1.4 version. To get Eclipse to work I had to modify the PATH statement so that it would find the verion in “/usr/java/jdk1.6.0_03/bin” first. The best way I found to fix this problem was by modifying the .bash_profile file and adding the following statement:

export JAVA_HOME=jdk1.6.0_03

and modifying the path statement to read:

PATH=/usr/local/java/$JAVA_HOME/bin:$PATH:$HOME/bin

After I logged out and logged back in, I could start Eclipse. To test my Eclipse setup I decided to use the Hello World program for CPPUnit. This is the traditional Hello World program with a little extra, a C++ unit testing framework. The steps I performed to build this program are:

  1. Created a new C++ Project. In my case I called it HelloWorldCPPUnit.
  2. Next I created a “Source Folder” that I called “src” and a “Source File” in that directory that I called “HelloWorldCPPUnit.cpp”. I copied all of the source code from http://pantras.free.fr/articles/helloworld.html into the file and saved it.
  3. Before you compile this program you need to download and install cppunit. The instructions for installing it are straightforward but you will need to do a few more things to get it to work with Eclipse.
    1. You will need to modify the project settings for the GCC C++ Compiler-Directories in Eclipse to add the path to the include files, “/usr/local/include/cppunit”. This adds a “-I” parameter for the compile.
    2. You should run the command, “./cppunit-config –libs” to see the library linking information. In my case it showed “-L/usr/local/lib -lcppunit -ldl”. I modified the project settings for the GCC C++ Linker-Libraries in Eclipse to add these libraries, ccpunit and dl, and the library search path, “/usr/local/lib”.
  4. The final setup step was to tell CentOS where to find ccpunit shared library. At this point the program will build but will not run because CentOS cannot find the run-time library for cppunit. The cppunit installation creates a shared library and puts it in the “/usr/local/lib” directory. To tell CentOS where to find it I had to do the following steps.
    1. As the user, Root, I created a file that I called “local.conf” with one statement in it, /usr/local/lib, in it. I saved this file in the “/etc/ld.so.conf.d” directory.
    2. Then I ran the command, “/sbin/ldconfig”. This tells CentOS to update the links to the shared libraries.
  5. If everything is set up properly the program will build and run the simple unit test.

Overall Eclipse with CDT is slightly more difficult to set up then Visual Studio Express. Most of my difficulties occurred when I tried to go a little beyond the default configuration. Recently I tried to go slightly beyond the default configuration for Visual Studio Express. Since I had minor difficulties setting up both packages my gut feeling is that it was slightly easier to find answers to set up problems from the Internet for Visual Studio problems because there is a larger developer community specializing in Visual Studio. Of course, your mileage will vary! 😉

Garry’s Bit Patterns: TortoiseSVN and Visual Studio Integration – Visual Studio 2008

Finally, I am getting around to an update to the TortoiseSVN Visual Studio Integration. The catalyst for this is the release of Visual Studio 2008 (formally codename Orcas) Beta 2, and making sure I can still play with Subversion through the IDE.

Garry’s Bit Patterns: TortoiseSVN and Visual Studio Integration – Visual Studio 2008

Adding some TortoiseSVN integration is pretty simple using Garry’s settings file. I used the SubversionMenuToolbarContextsVS2008.vssettings file.

Building the LAME MP3 Encoder using Visual Studio 8 Express

Recently I had been playing around with the Visual Basic version of Visual Studio Express and somehow mucked it up real good. It told me it could not create the Visual Basic compiler and I should re-install. I re-installed and it was still mucked up so I completely removed Visual Basic and SQL Server pending an epiphany of sorts.

A couple of days ago I decided to rip a copy of the songs on a CD I got for Christmas for my portable player. I used Windows Media 11 to rip the copy but then I remembered that I preferred using Exact Audio Copy for ripping CDs. EAC makes a persuasive argument that they make a better copy. Since I had re-built my desktop since the last time I ran EAC, I had to re-install EAC. As part of the installation I had to install the LAME MP3 Encoder, too. Although I had a binary version of LAME available I decided this might this might be a good time to work through my Visual Studio Express problems. I would be working with C++ rather than Visual Basic environment but I expected that what I learned from the Visual Studio Express framework under C++ would also apply to Visual Basic environment. I expect that Visual Studio reuses most of the IDE environment. Since I had already downloaded the DVD with all of the Visual Studio 2008 Express packages on it the installation should be relatively painless. So I installed the C++ package.

The big challenge would be to fix the errors and warnings from using the 2008 compiler version. The only error I had to fix was the errors resulting from a missing msacmdrv.h. Since I did not have access to the Window DDK, I decided to use the version included in the ACM\ddk directory. I copied it into the ACM directory.

It took a little research to get rid of the warnings. Someone advised that I compile LAME from the command prompt using the included Makefile for the Microsoft compiler.

To build LAME from the included Makefile I had to:

  1. Download a copy of NASM. Extract nasm.exe from the file, rename it to nasmw.exe, and copy into the lame-3.97 directory. The makefile we are going to use requires nasmw.exe.
  2. Open a command prompt from Visual Studio using the “Tools-Visual Studio 2008 Command Prompt” menu item. This opens a command prompt with the environment path variables set properly to use the command line versions of the C++ compiler and linker.
  3. Change the directory to the project directory, lame-3.97.
  4. Type “nmake -f Makefile.MSVC COMP=MS” and press Enter.
  5. A LAME executable was created and the only messages I got were warning messages about invalid /QIof and /QIfdiv compiler parameters.

Okay, that wasn’t too bad! Since I had not been humbled by a compiler in the last thirty seconds I decided to see if I could do the whole process inside Visual Studio.

To build LAME from inside the Visual Studio environment I had to:

  1. I saw that there was a sln file(probably a VC7 workspace) available so I decided to let Studio try and convert the workspace. I was a little leery since I tried converting a Visual Basic workspace recently and I really made a mess of it. In this case the conversion appeared to create a working environment.
  2. The first time I built the solution using the converted workspace, I generated a lot of warning messages and the executable seemed large. So I set out to “fix” the problems. Some of the warnings were related to deprecated I/O functions that may be unsafe. In this environment I deemed them safe so I “fixed” the problem by including a compiler parameter, /D “_CRT_SECURE_NO_WARNINGS”, on the command line page for the lame project. I deleted references to /QIof and /QIfdiv on the command line page since these are not valid compiler parameters. I added the compiler parameters, /O2, /Ob2, /Zp8, /GL, and /Zi, to the optimization page since the Makefile used these parameters. I changed these parameters on libmp3lame, mpglib, and lamemp3encdll.
  3. To build the solutions, you select a Solution Configuration and press F7. There are twelve different configurations but I was interested in the configuration to build the DLL, “dll release”, and the one to build the lame.exe, “LAME release”.  When I built these solutions I was only getting 24 warning messages. Almost all of the messages were related to type conversion(e.g. float to double). It would be nice if there were no warning messages but these message looks to be harmless. I am unwilling to mess with other people’s code unless it does not work. If everything compiles without errors(warnings are okay 😉 ), lame.exe and lame_enc.dll should be in the output folder.

I tested LAME by running LAME with the input file, testcase.wav, and comparing its size to the testcase.mp3 file included in the distribution. I got the same size files so it must be working. 😉