Saturday, February 21, 2009

Business Analysis, Software Engineering, and Our Profession

At the insistence of my employer I completed a Business Analysis course in gathering and documenting user requirements. I expected from the title and description it was about gathering business requirements, which in my mind are high level requirements expressed in business terms about how a solution (which may or may not include a software system) to a business problem should fit with the business goals, address business needs, and bring value to the organization. As there was no hint of software engineering in the course description, I was thinking this course could not be about software (or systems) requirements engineering I first learned in school and practiced for years.

I was wrong.

A rough guess: 90% of the material was straight from classical software engineering requirements elicitation and documentation courses taken in university. I was thinking while sitting through this course: Is most of this stuff not simply a part of software engineering? Why the silly name Business Analysis, like it is a distinct profession outside the domain of software engineering? And, how can a class full of software developers not know this stuff already? What kind of education do they have? Where did they do their training to become software developers and not learn this stuff? Disturbingly, many in this course have been building software for years and are calling themselves software developers.

I suspect many "software developers" lack other software engineering fundamentals as well. Consider the core courses for a certificate in Business Analysis: How to Gather and Document User Requirements, Testing for Business Analysts, Object Orientation for Business Analysts, and Object Oriented Modeling. These are topics all software developers should be intimately familiar with. Obviously, some of us are not. But why not?

I believe the answer lies in the lack of a professional organization that certifies (and licenses?) software engineers. Such an organization would ensure quality engineers by mandating appropriate education, training, and experience, and establishing codes of ethics and professionalism. Even though a lot of software is built to run critical systems (think about software in the medical, engineering, banking, and insurance fields, to name a few), we do not have any regulations on who is qualified as a software engineer to build such systems; i.e. there is no regulatory body to ensure those who practice our profession are qualified to do so. In the words of Bjarne Stroustrup: "I find it appalling that you can become a programmer [software engineer] with less training than it takes to become a plumber" [1].

The lack of required and approved software engineering training has resulted in many developers having little or no requirements elicitation and documentation knowledge (not to mention other software engineering fundamentals). This is a fundamental part of the software engineering process, and many in our profession are not prepared to do it. What has resulted is a need in the business world to fill a void created by inadequate and under qualified software developers. Hence, Business Analysts, out of necessity, have expanded their role to do what good Software Engineers should be doing.

My understanding from this course is that Business Analysts are gaining evermore respect in our field and are leading the way to certification on their own. Good for them. If we as a group of software development professionals (software engineers, computer scientists, programmers, and the like) can't organize ourselves and bring some professionalism to our discipline, more and more of our field will be shifted to other professionals who can. I can see this already happening. The Business Analyst is now somehow seen as much more than the Software Engineer, fulfilling major roles in the software engineering process (I'm not saying BAs don't have a role to play, just not as software engineers). That leaves us as "just coders", unprofessional worker bees, with no control over our own profession. Shame on us.

Every true profession eventually forms an organization to ensure integrity and quality of the professional, and to protect the public, the business world, and the practitioners. Such organizations also ensure the discipline remains in practitioner's hands and those practicing it are properly qualified (education, certification, licenses). Consider teachers, lawyers, doctors, pharmacists, electricians, and, my God, in my neck of the woods even mortgage brokers. They have all professionalized. Its time we grow up and do the same.

References

[1] James Maguire, Bjarne Stroustrup on Educating Software Developers, Datamation, http://itmanagement.earthweb.com, 2008

Wednesday, February 18, 2009

Including Images in LaTeX Documents

Following are a few notes on including graphics (images) into Latex documents.

I recommend using the graphicx package. There is another one called graphcis that has the same functionality, but uses a different syntax. In my opinion, graphicx has the better syntax.
  \usepackage[options]{graphicx}
Common options are:
  • Driver name, such as dvips, dvipdf, and pdftex.
  • draft: draw an empty box in place of the image.
Examples:
  \usepackage{graphicx}
  \usepackage[dvips]{graphicx}
When compiling with latex or texify to create a DVI file (and then to PS or PDF using dvips, dvipdfm, or ps2pdf if needed) you can include EPS files using the command
  \includegraphics[key=value, ...]{fileName}
Common key/values are
  • scale= number
  • width= length
  • height= length
  • totalheight= length : height plus depth; generally used when rotating the graphic
  • keepaspectratio= boolean : true or false
  • angle= number : the angle to rotate the image counterclockwise, in degrees
  • origin= location : the anchor point for rotation; legal values include c (center), t (top), r (right), bl (bottom-left), B (baseline), and certain combinations, such as tr
  • draft= boolean : true or false; draw an empty box in place of the image.
  • bb= llx lly urx ury : creates a new bounding box using the specified coordinates; default unit is bp (points)
  • clip= boolean : true or false; don't draw parts of the graphic outside the bounding box
  • viewport= llx lly urx ury : creates a bounding box relative to origin (generally ll) of the existing one
  • trim= left bottom right top : creates a new bounding box by adding or removing the given lengths to each side of the existing bounding box
Examples:
  \includegraphics{MyFile.eps}
  \includegraphics[height=3cm,angle=45]{MyFile.eps}
  \includegraphics[scale=0.55]{MyFile.eps}
  \includegraphics[height=3cm,width=5cm,keepaspectratio=true]{MyFile.eps}
You can convert images to EPS files using the convert command in the ImageMagick tool suite. Other tools such as matlab, and PaintShop Pro (maybe Gimp?) also let you save images as EPS files.

When using pdflatex to create PDF files you can use the same commands above, but instead of including EPS files, you can include PNGs, BMPs, and GIFs directly (no need to convert to EPS files first):
  \includegraphics{MyFile.jpg}
  \includegraphics[height=3cm,width=5cm]{MyFile.png}
References
  1. CTAN, CTAN graphicx package information, 2009
  2. D.P. Carlisle, Packages in the graphics bundle, (graphics guide for Latex3, PDF), 2005
  3. Including graphics in a LaTeX document, amath.colorado.edu, 2008

Wednesday, February 11, 2009

Compiling Vim (on Windows) To Use Different Python Versions

I recently wanted to use Python Omni Complete for Vim, but whenever I executed the complete command <c-x><c-o> it failed with the error:
Error: Required vim compiled with +python
E117: Unknown function: pythoncomplete#Complete
This is incorrect. After doing a :version command, Vim showed it was compiled for Python support (the +python/dyn option was present). The real problem was Vim could not find the correct version of Python it was expecting: I had 2.6 installed, Vim wanted 2.4 (DYNAMIC_PYTHON_DLL="python24.dll").

Following is one way to compile Vim to use a different version of Python than that shipped with Vim. I targeted 2.6, but the steps can be tweaked to work for any version of Python. It is assumed Vim and Python are already installed.
  1. Obtain a C++ compiler. I considered two, GCC from Cygwin and GCC from MinGW. I went with the latter simply because it was easy to install only the C/C++ development tools (e.g. GCC, make) that I needed. The Cygwin installer had far too many packages to chose from. I didn't want to waste my time determining what was necessary to install from packages I had no interest in.
  2. Obtain Vim source code and unzip somewhere, say C:\.
  3. Edit the MinGW make file. For me that is C:\vim\vim72\src\Make_ming.mak. Find the variable PYTHON_VER and set the version number to whatever version of Python you have installed. Also, find the variable PYTHON and set to the root of the Python installation directory. In my case,
    PYTHON=c:/Programs/Python26
    PYTHON_VER=26
    
  4. MinGW did not add the location of the GNU make tool to my PATH, so I had to manually do that next. Since I had no intentions of using this tool after I was done compiling Vim, I updated my path temporarily. To do that, I opened a command prompt in the directory of the make file (C:\vim\vim72\src) and executed
    set PATH=%PATH%;C:\Programs\MinGW\bin
    
    where C:\Programs\MinGW is the location where I installed MinGW.
  5. Compile GVim. Using the same command prompt window in which PATH was changed, execute
    mingw32-make -f Make_ming.mak gvim.exe
    
    Normally you would execute make -f Make_ming.mak gvim.exe, but make.exe seems to have been renamed to mingw32-make.exe in the MinGW installation.
  6. Install gvim.exe. After compiling is done, locate gvim.exe in the same directory as the make file (C:\vim\vim72\src) and copy to Vim's runtime directory. For my, C:\Program Files\Vim\vim72. There should already be a gvim.exe there.
  7. Make sure the Python 2.6 installation is on your path, namely the directory where Python26.dll is located.

Google Earth 5 (beta)

Some pretty cool stuff: Historical imagery, oceans, Mars and more.

Tuesday, February 3, 2009

FoxPro Java ODBC Query Bug

The result set for a query to a FoxPro database may have incorrect data in the row's fields if the ORDER BY clause is not used. This occurred using ODBC from Java and Groovy code. I'm thinking this might have been caused by the old database driver I was using. I can't remember the publication date, but it was sometime in the late 90's, I'm thinking 98 or 99.