My Software Engineering Principles class has so far been rather like a seminar. There are only five students, and typically we just meet, and everyone should have read up on the topic we're going to discuss, and then we discuss the topic and what we've read. Sometimes we have to write a little reflection or some "nuggets" (pithy statements on a topic), but pretty much it's just been reading & talking. I like it!
But, since the follow-up class to this (Software Engineering Practices, my "senior experience" course) is all about working on a big software project, we're going to have a miniature software project for this class, and we started on that Tuesday.
Dr. Paul's idea, which nobody vetoed, is that we should write a requirements management tool. (Requirements are very precise statements about what a piece of software is meant to do and not do. They essentially form the contract between developers and customers/clients. Requirement engineering is what you do before you start working on design or actual coding, in theory.) The most commonly used requirements management tool is probably, alas, Microsoft Word.
I am not one of those anti-MS people, but the problem with keeping requirements in Word (or any word processing software) is that it limits them to being a flat document. What you really want is for requirements to be "live", to facilitate tracking changes over time, to allow for dependency relationships between different requirement statements, and to be able to link requirements to specific parts of the design and the actual code. And of course you also want to be able to produce them as a document.
What Dr. Paul would like is for our application to be open source, web-based, and backed by a database, and for it to support the Volere shell and template. (Volere is basically a style of requirements - sort like how APA or MLA are styles for writing papers.) He suggested (though this is up to us, ultimately) that we could use CSS (cascading style sheets, into which you feed HTML files that it then formats in a consistent way, so that you can take the same HTML pages and show them different ways), PHP (a scripting language that generates HTML pages), and mySQL (an open source database) to solve our technology needs.
Of course, in our first meeting on this (the day he told us about it), we all started jumping in talking about coding the thing, and he sort of interrupted us to say, essentially, "Uh, how about using proper software engineering practices since that's what this class is about, dummies." So we discussed our software lifecycle model (settling on a risk-based iterative model, for now), and started working on requirements. (Too bad we don't have a web-based, open source requirements management tool! Oh yeah.)
So as of this moment we have a pretty good list of proto-requirements. Near the end of class last night we discussed deliverables for Tuesday, so that everyone would have something to work on. Warren is going to get our proto-requirements partly into the Volere template (which has the dual purpose of making our requirements nicer while increasing familiarity with the Volere template) and think about a database schema. Nobody else volunteered for a specific responsibility (despite the suggestion from Dr. Paul that we do so) besides me.
My job is to download PHP, mySQL, set up an Apache server on my own machine, and figure out how basically to make the round trip from a web page where you enter something, to a database, and back out to a display page. I should have this done by Tuesday and be ready to show the class the code and process for how this is done.
(What I mean by "make the round trip" is to code up a page that has blanks where you type stuff in, and then it takes the typed in stuff and stores it in the database, and then you can go to another page to see what is in the database.)
I've never worked with PHP or mySQL before, or really done any web-based stuff at all, so this should be a fun challenge to put together by Tuesday.