licensing versus certification

The following is a short, informal piece I wrote for a class last year while we were debating whether or not software engineers should be licensed. The debate continues in real life as the software industry as a whole is trying to find agreement on the issue of whether or not software engineers should be licensed.

In casual English, licensing and certification have similar meanings. However, in the context of the debate on whether software engineers should be licensed like traditional Professional Engineers (PEs), licensing and certification have very distinct meanings.

The following are definitions from Knight and Leveson (2001), ACM Task Force on Licensing of Software Engineers Working on Safety-Critical Software. The notion of licensing is to have some authority grant permission to an individual to engage in an activity that is otherwise unlawful.

Similarly, certification assures that an individual meets a minimum set of requirements.

Licensing and certification differ primarily in the permission to act. Licensing is mandatory and is a state or federal activity (usually state) while certification is voluntary.

The local governments in Texas and provinces in Canada are licensing software engineers today as PEs with legal rights. Meanwhile, other professional organizations in industry are in the business of certification. For example, the IEEE has the Certified Software Development Professional (CSDP) program, the Project Management Institute has the Project Management Professional (PMP) program, and of course many are familiar with the gamut of technical certification programs like the Microsoft Certifications.

My point is, if we software engineers are going to discuss/debate this topic and be understood, we should aim to be precise in our wording. It's the only way we can all understand what someone really is saying instead of making assumptions and implications. I know, this sounds like an advertisement for good requirements analysis and specification techniques.

Now for the alarming part. If one takes note of the Texas PE exam requirements one will find that their exam has little to do with software engineering as it is typically treated in academia and in industry. Searching around on their website, I found Texas Board of Professional Engineers meeting minutes (pdf) (2005) where they decided to use the IEEE CSDP certification exam for licensing software engineers as PEs in Texas until a better exam comes around. From the minutes, "IT WAS MOVED AND SECONDED (Frailey/Rodriguez) that the Board accept the CSDP examination as an interim substitute for a PE exam in software engineering, until such time as a national exam is provided by NCEES and reconsider the licensure of software engineers."

To me, this is not a real confidence builder in their system of licensure -- I just think Texas jumped the gun a little. Before we as a software community have understood what the implications of licensing are and before we decided on what the best means of licensing are, Texas already started issuing licenses to legally allow people to do things, while considering to use a minimum certification exam to allow them to do it. One would like to think that if licenses are being issued to people who are trusted to do something safety-critical like design software for an aircraft system or a medical device, they should know more than the minimum requirements. The Texas exam, and any exam really, determines a minimum level of knowledge, but it does not determine competence or mastery.


References
IEEE Certified Software Development Professional Program. Retrieved May 30, 2007, from http://www.computer.org/certification

Knight, J., Leveson, N. et al. (2001, August). ACM Task Force on Licensing of Software Engineers Working on Safety-Critical Software. Retrieved May 30, 2007, from http://www.acm.org/serving/se_policy/safety_critical.pdf

Microsoft. Microsoft Certifications Overview. Retrieved May 30, 2007, from http://www.microsoft.com/learning/mcp/default.mspx

Project Management Institute. Certification Project Management Professional Overview. Retrieved May 30, 2007, from http://www.pmi.org/info/PDC_PMP.asp

Texas Board of Professional Engineers. Examination Information. Retrieved May 30, 2007, from http://www.tbpe.state.tx.us/lic_exams.htm

Texas Board of Professional Engineers. (2005, August). Minutes, Industry Advisory Committee, August 16, 2005. Retrieved May 30, 2007, from http://www.tbpe.state.tx.us/minutes/ind_81605.pdf

minimizing losses on a late project

The following post is the text of a short paper I wrote for a course in Software Systems Development. The writing style is a little formal for a blog, but I wanted to share because I believe the advice is sound, not just in terms of the citations, but based on my real-world experiences as well. Sometimes it's hard for me to believe that I've been working in software for over a decade...

Although software engineering practice focuses on establishing good project plans from the onset, sometimes it becomes necessary to consider what happens when a project becomes late and over budget. In the case where a project is nearing completion (and one has come too far to cancel the project), there are some project management strategies, specifically relating to project monitoring and control, to minimize the lost revenue for the project.

Monitoring and controlling the staffing level in the project is essential for stabilizing the development cost. Personnel shortfalls are common in projects, so common that Boehm (1991) considers it one of the top 10 risks on any software project. However, according to Brooks (1974), one must resist the temptation to add staff to the project or risk it becoming later, and as a result, more expensive. Adding staff generally increases the communication overhead between project team members and it takes time for new staff to familiarize themselves with the project (Brooks, 1974). The only case where adding staff might help accelerate the project towards completion is where new team members are already familiar with the tasks to be performed, thus reducing the learning curve to understand how the project operates (Glass, 1998).

With a stable development staff working on the project, it is also important to monitor and control the project’s requirements. Wallace and Keil (2004) consider “scope and requirements” to be one of four major risk categories on a project. Scope and feature creep needs to be controlled through the customer and controlled within the development team as well. Using a Requirements Traceability Matrix, the project manager should monitor the development team’s effort to ensure everything being done in the design, implementation, and testing activities is traceable to a stated requirement. Tracing work being performed by the development team back to requirements helps to limit any extra work beyond the stated requirements being done (Wallace and Keil, 2004), which would further delay the project and increase the cost. Glass (1998) also suggests reducing the initial project scope if it is possible with the customer – deferring or eliminating some requirements or features to make the task more feasible.

Despite the pressures of a project being late and over budget, the project manager should continue to monitor and control the project processes, particularly quality control. Glass (1998) suggests that projects often fall behind schedule because there was not enough time originally allocated in the schedule and that 85 percent of project managers extend the schedule as a result. Although extending the schedule may result in revenue loss, conducting the remainder of the project according to the planned processes may minimize the revenue loss. Effective quality management reduces the risk of introducing defects, which would adversely affect cost and schedule in terms of effort required to manage and rework the defects.

In a project that is late and over budget, project managers should reexamine what is known through project monitoring and readjust through project control. The project manager must address the fundamental questions in a project: Who is working on the project? What are they working on? How are they working on it? Finding stable answers to these questions will result in the project being completed with a minimal loss in revenue.

References
Boehm, B. (1991). Software Risk Management: Principles and Practices. IEEE Software, 8(1), pp. 32-41.

Brooks, F. P. (1974). The Mythical Man-Month. Datamation, December, 1974. pp. 44-52.

Glass, R. L. (1998). Short-Term and Long-Term Remedies for Runaway Projects. Communications of the ACM, 41(7), pp. 13-15.

Wallace, L. & Keil, M. (2004). Software Project Risks and their Effect On Outcomes. Communications of the ACM, 47(4), pp. 68-73.