Friday, June 21, 2013

My CSDA (Certified Software Development Associate) Experience

Software engineering has been a passion of mine since before I knew there were words for it.  Last year I learned that the prestigious IEEE offers certifications in this field, and my ears perked up.

Planning My Attack

I investigated the two different offerings:  CSDA (Certified Software Development Associate) for entry-level developers, and CSDP (Certified Software Development Professional) for experienced ones.  My first impulse was to shoot straight for CSDP.  After all, I have several years of software development experience and recently completed a Masters degree in software engineering in which I was less than one tenth of a grade point away from graduating with distinction.  By IEEE's recommendations, I should be a candidate for CSDP.

However, I decided to go for CSDA first, even though my experience and education should drastically over-qualify me.  My reasons:

  • I teach an undergraduate software engineering course.  If there is any hope of preparing my students for certification, it would be at the CSDA level.  I would need to assess the content firsthand in order to accurately convey the experience and expectations to them.
  • I really want to go for CSDP, and CSDA might offer a somewhat gentler preview of what the exam might be like.
  • Unlike CSDP, the CSDA doesn't expire, so I won't be trying to maintain two similar certifications after I get my CSDP in the future.
  • I have lofty aspirations of someday becoming a presenter for the IEEE Computer Society.  I want both certifications so I'll know how they differ and can accurately answer questions about them.
  • The professional development budget that my employer provides will cover the costs of both certifications, so why not?

My Preparation Process

I started by attending the IEEE Metro Area Workshop session on Software Engineering Essentials.  Then I purchased six months of access to the relevant courses in the IEEE e-learning library.  Immediately I discovered that I was right to go for CSDA first.  Some of the review questions were extremely difficult, even with my education and experience.  Tiny nuances that seem trivial in practice can have the  power to completely shift the focus in a theoretical/hypothetical context.  This was perhaps the greatest lesson I learned through this process.

At the end of my six-month subscription, I scheduled the exam for the first available time slot that fit into my busy schedule.  It was over a month away from that point, so I had some time to keep studying.  I carried my favorite software engineering book (Software Engineering: A Practitioner's Approach by Dr. Roger S. Pressman) with me everywhere I went so I could browse through it every chance I got.  I read the entire SWEBOK guide online, and even read the new drafts as they became available.  I also skimmed relevant message boards to see if anyone was talking about these exams, but very few people were.

Exam Day Arrives!

Finally the scheduled exam day arrived.  I surveyed the battlefield the day before by driving by the testing center to make sure I knew exactly where it was.  That night, I armed for battle by reviewing all of the SWEBOK knowledge areas as well as the engineering, math, and computing foundations.  Then I tried unsuccessfully to get a restful sleep so my mind would be sharp the next day.

Two things I love: Java and Mountain Dew
That morning (actually this morning), I awoke long before my alarm sounded.  I put on my Java polo shirt as a motivational reminder of the last certification I conquered.  After a delicious, energizing breakfast of peanut butter and grape jam, I popped some vitamins, downed a Dew, and headed to the testing center.

The check-in procedure was quick and simple.  I just had to sign a few things and empty my pockets into a secure storage locker.  You are not allowed to carry anything into the testing room that could be used to record or copy the questions, or to cheat by looking things up.  I carried only my driver's license and the key to the storage locker.  I was allowed to borrow a marker and a wet-erase sheet which I only ended up using on one question -- to diagram a cyclomatic complexity problem.

Most of the questions were surprisingly straightforward.  I was very glad that I had taken the prep course because some of them involved those tiny details that seem insignificant unless you really understand the intentions of software engineering processes, methods, and techniques.  There were a few on which I had to venture an educated guess based on various assumptions.  But there were two that really got under my skin.

Two Irritating Questions

I had to agree with an NDA that prevents me from repeating the questions here, so I'll summarize in a nondescript way the two questions that angered me.  One question showed a class diagram depicting an inheritance hierarchy using a mix of concrete and abstract classes, then asked which of four statements was true for the diagram.  However, all four options were technically false.  I was able to make a reasonable assumption by granting some semantic leniency, but doing so led to two valid answers based on that rationale.

The other objectionable question was even worse than that.  It was a Boolean logic notation question that gave a compound statement, assigned letters A, B, and C to its three elements, and then asked which expression was equivalent to the original statement.  The question was very simple and I could have answered it easily were it not multiple choice.  The problem is that answer A was identical to answer B and it was wrong.  Answer C was identical to answer D, and again, wrong.  So there were no right answers, and the answer choices were all duplicates of each other.

Victory!

The score report printed at the front reception desk.  Aside from my name, address, and other identifying information, it simply said this:
We are pleased to inform you that you have achieved a scaled score of 170 or higher and have thus passed the CSDA examination.
It would have been nice to know how I performed in the various knowledge areas, particularly on those with faulty questions, but overall I'm just relieved to have this challenge behind me.

On to the next!

Sunday, May 5, 2013

Non-Teaching Session 2013 Wrap-Up


It's over already? Really? Yep, my non-teaching session has come to and end and classes resume tomorrow.

So how did I do on the objectives I set for myself in the beginning? Let's break it down.
ObjectiveStatus
Guide a student group on a Java-based client project, participate in some outreach events, and attend the Faculty Symposium.Success. I did all of these things.
Finish my CSDA certification and port functionality from MHF2 to MHF3.Failed to complete my CSDA. I have about three more weeks to my exam. I did succeed in porting a lot of functionality to the new engine though.
Get a test level set up for [SECRET PROJECT] and learn Illustrator well enough to create a vector version of the new MHFramework logo.Failed. Ran into dev environment issues on the project, and still don't have a vector version of the MHF logo, though I do have a few bitmaps.
Work on words and vocabulary every day with Avery.Worked on it daily, but he still doesn't talk.
Get my stuff organized and help Michelle with housework while she's taking a difficult grad school class.Success, but I think perfection in this endeavor may not be feasible.
Play a game every day.Success...pretty much.
Miscellaneous things, like organizing my desk and library, moving things to storage, mounting stereo speakers in my office/man cave, and plenty more.Success. I did almost everything I'd planned. in this area.

Tuesday, March 5, 2013

Non-Teaching Session 2013 Objectives

Well, here it is -- my annual non-teaching session.  Each year, DeVry University requires each full-time faculty member to take one session where he/she does not carry a teaching load.  Mine started yesterday.

Here are the objectives I set forth for the various roles I play:

Professor:Guide a student group on a Java-based client project, participate in some outreach events, and attend the Faculty Symposium.
Software Engineer:Finish my CSDA certification and port functionality from MHF2 to MHF3.
Game Developer:Get a test level set up for [SECRET PROJECT] and learn Illustrator well enough to create a vector version of the new MHFramework logo.
Father:Work on words and vocabulary every day with Avery.
Husband:Get my stuff organized and help Michelle with housework while she's taking a difficult grad school class.
Gamer:Play a game every day.
Human:Miscellaneous things, like organizing my desk and library, moving things to storage, mounting stereo speakers in my office/man cave, and plenty more.

I'll post an occasional update on my effectiveness (or lack thereof) on these goals.

Thursday, January 3, 2013

Class Structure of the Platform Layer (Corrected)

In my previous post, I forgot to include the event handling mechanism, so here's an updated class diagram that accurately shows the static structure of the platform layer.  If you compare it to the architecture diagram I posted awhile back, you'll see that all four elements of the platform layer are now represented.


Wednesday, January 2, 2013

Class Structure of the Platform Layer

The platform independence layer seems to be working beautifully so far.  Here's how it stands right now.




This is only the abstracted view of the system.  All of the abstract classes and interfaces shown here have been implemented in both PC and Android versions in their own respective packages.

Sunday, December 16, 2012

A Little Success With Graphics

After a couple days of work, there's been some success along with a frustrating and perplexing mystery.

The Good News
The PC platform in windowed mode works, rendering scenes using nothing but calls to overridden abstract methods.



The Bad News
The display mode selector is completely, inexplicably broken, so full-screen mode doesn't work.  Neither does windowed mode unless I bypass the selector entirely when retrieving the platform graphics context.

So, it's a start, but there's still some distance to travel before I'll call it "ready".


Thursday, December 13, 2012

A First Look at a Possible High-Level Architecture

Here's a very high-level look at one possible architecture for the new engine.  Essentially, it just takes the features of the current MHFramework, adds a few requirements of the new engine, and organizes them based on dependency and abstraction.

It's rough, but it's a much better start than MHFramework 1 and 2 had.