Thoughts on Software Requirements specs

After slogging through the 80+ pages of the Volere template plus the "example" specs created with the template, I have to say that I certainly have a greater appreciation for just how much detail you can put in a software/project requirement spec (now, whether all of it is relevant...well I guess that depends on what you're designing). The Volere template certainly seems to include everything you'd ever consider putting in a project specification, but, based on some of the sections and the examples (e.g. a universal remote), the template is for more than just software projects. It can obviously also be adapted to other large-scale systems (like the library-management example). I'm pondering whether the generality of the project template can impose some limitations on what you can actually do with it. When I went through it, I pulled out a few things from the project requirements section, but a lot of the information they wanted was not relevant to my project. Obviously, this is to be expected from a general template, but it also means that you have to search through all 80+ pages to find and pull out the pieces you are looking for. As someone who does not have much experience writing formal software specifications, I found the template to be somewhat confusing, especially when I tried to determine what exactly I needed for my project. To me, I think it would have been easier to start from something designed specifically for software requirements, such as maybe a more detailed spec based on something similar to the example in the Wikipedia article on Software Requirements specs, and work that into my project. I'd imagine that once I become more proficient at writing software specifications, I'll be able to more easily sift through a more generalized requirements spec like Volere, but right now, it is quite a daunting task!

Agile Software Development method

The agile method is essentially a method of developing software that seems to be a response to a more structured, planned, and step-by-step approach that finishes one task and moves onto the next. Agile development follows an approach that allows the user to build up iterations of the software, slowly adding more features and building upon the previous iteration. This allows developers to learn from their past mistakes and also gives a working program to demo to the client at each iteration. Overall, the agile method is more people-oriented approach, whether the people in question are the developers, the clients, or the stakeholders in general. The agile method appears more adaptable than, say, a strict waterfall model, and allows developers to respond to change instead of "locking" them into a plan that restricts their ability to adapt. In particular, I like the pair programming aspect of agile development. I have done this one one or two other programming projects and I found it to be extremely helpful, particularly when it came to spotting bugs or errors in the code. It also allows two people to become "experts" in the code and thus one can take over if, say the other is out sick. Additionally, the agile method's emphasis on testing throughout an iteration is something else that I feel is important. Waiting until a feature is fully completed is not the time to start testing and realize that there is a major problem. Testing as development occurs prevents small errors from becoming huge bugs, thus saving time and money.

Agile development also places an emphasis on working code versus documentation, especially when it comes to presenting to the client. While working code is very important, and often has more of an impact than documentation with regards to a client demo, good documentation cannot be ignored. It is critical, in my opinion, to have good documentation (user manuals, test cases, detail code comments, etc.). I have seen too much code in my college career that lacks even basic comments, making it nearly impossible to decipher exactly what is occurring at complicated areas in the code. Therefore, I make it a point, as much as I hate it, to comment everything in my code that is ambiguous or confusing, ensuring that at least I, when I look at that code 6 months or a year from now, will know why I did what I did.

Another issue that I have with Agile is its adaptive approach to planning. It focuses on adapting to more immediate changes and, therefore, does not necessarily plan out future milestones and tasks to reach those milestones. While I feel that adaptation is very important, I also feel that having long-term goals and milestones is also important in order to get an idea of how long a feature might take or what the customer is going to expect in the next month or 6 months. Thus, in some areas I feel that Agile is too flexible and could benefit from some added structure. However, I really like its more iterative and incremental approach to programming and its emphasis on small teams, daily group meetings, and even pair programming. This, to me, makes my job as a programmer a little easier and more meaningful.

Project timeline

I ended up using OpenProj to create this (though ProjectLibre would have probably worked the same). Unfortunately, OpenProj (or ProjectLibre) does not give you the option of save the Gantt charge as a .png so I was relegated to using a .pdf, which is attached to this post. I also attached the Network diagram view of the timeline.

Use cases and user stories

I am most familiar with user stories and knew little about use cases so reading the Wikipedia article on Use Cases was quite informative. It seems that use cases are much more technical and detailed than user stories. User stories seem to describe the results of an interaction and are more about the benefit of a program's feature or function with respect to the user. For instance, "As a user of website X, I need to control who can see my blog posts for privacy reasons." However, a use case appears to be a more detailed description of how the system will respond when it has interactions with either users or other systems. It describes, step by step, the actions taken to perform a certain task. For instance, a use case for changing a blog's privacy settings would read more like (in a very basic form): "1) The system provides a Privacy Setting dialog window which allows the user to select whether their blog is public (readable by everyone), semi-private (readable by subscribers), or completely private (readable by themselves only). 2) The user selects the appropriate privacy level setting and either uses the “Save” button to save the changes or uses the “Cancel” button to cancel the changes.” This gives a more detailed description of how the dialog box would appear to the user and what functions it should perform. It therefore also gives the developer a better picture of what they need to do to code up this privacy settings dialog box.

It seems to me that both user stories and use cases can be helpful when developing software requirements. User stories are definitely more friendly to people who may not know the exact technical requirements of performing a specific action. I would imagine that user stories would be the results of meetings with the client and potential users of the program since they can be expressed in simple English and require little knowledge of the exact implementation of a feature. I would also then expect that use cases could be an outgrowth of a user story, where the developer “fleshes out” the details of implementing a feature described by the client or user. Personally, I find use cases more helpful as a developer, but I can certainly understand the importance of use stories when it comes to communicating with clients and/or users. I would also find use cases more helpful when creating the software requirements specification. However, having both user stories and corresponding use cases could be very helpful when trying to communicate with the client(s) and with other developers since we get both the top-level and detail views of the features from different perspectives.

Proposal Development: Concept Paragraph

There are many social media websites that help people find friends and make connections through common interests, but there are none that target college students at a university. Our team will create an easy-to-use website with a supporting database that will allow students to create groups and events based on mutual interests and also provide the option of arranging carpool or transportation services to these events or activities. College students, particularly those who are from out-of-state or another city, may not know many other students at their university and will benefit from having a website where they can participate in social activities that coincide with their interests. We will use Kickstarter to fund the initial start-up costs and then pitch the website to the university, where, as the website would be a service for students, it could be run and maintained through university funding.

Social media sites such as Facebook, Twitter, and MySpace are used to connect people online who know each other in real life and/or share common interests and backgrounds. However, these sites focus on connecting people from all over the world and it is normally a prerequisite that you at least know the name of the person you are trying to connect to. Often, students go to a college in a different city or out-of-state and, particularly in their freshman year, know very few people. Trying to find other students who share common interests can be difficult. Our website would give students the opportunity to connect with new people, discover new interests, and make new friends, all at their own university. In addition, trying to find transportation to events and activities is also difficult if you lack a vehicle or access to a reliable transportation system. Our website will allow students to organize carpooling and transportation to events and activities.

The website will be built using  HTML5 and Javascript or PHP. The database backing it will be built using PHP, MySQL, and possibly jQuery. It will be hosted on a free web-hosting platform to reduce the initial start-up costs.

Since the website can be created and hosted using free tools, the initial costs can be reduced. However, longer-term funding will be through Kickstarter and, once a working website is completed, the product can be shown to universities who can invest in the support and maintenance of the website.

Won’t you join us to create a website where students can connect with other students based similar interests and activities, helping them feel more at home at their university?

Reaction to Wikipedia Software Engineering article.

Reading the Wikipedia page on Software Engineering, I was interested to learn that there are certifications for software engineers in the U.S., even though there is still disagreement about whether such certification is necessary. Obviously, companies like Apple and Microsoft have their own set of certifications that they oversee. I have heard about certification programs for other engineering disciplines, such as mechanical engineering, but, like software engineering, it is not a pre-requisite to getting a job (though, obviously, it probably helps). However, the article did not really state exactly how many software engineers are currently certified (through one certification program or another) in the U.S. and it is interesting that there does not seem to be any real agreement on what constitutes "software engineering." I wonder if this is because, apart from testable technical skills, software engineers must also have the ability to effectively communicate and present their work and ideas and this is much harder to quantify in an educational program.

As I mentioned, the article seems to indicate that there is a conflict between these two disciplines (software engineering and computer science) when it comes to defining what "software engineer" means. For instance, in Canada, the Professional Engineers Ontario groups refuses to certify anyone with a computer science degree. This brings up an interesting problem, particularly in the U.S. where, if you do a search of schools that offer Software Engineering degrees versus those that offer Computer Science degrees, you will get about 20 or 30 schools for the first search and close to 80 or 90 schools for the second search. Chances are, more people are getting computer science degrees than software engineering degrees. Thus, I think it is important that computer science programs put students in situations where they have to use communication skills in a team setting (such as this class).

Obviously, as mentioned in class today and in the article, software engineers are expected to have more than just programming skills--they need (in the words of Office Space) "people skills." As a self-proclaimed nerd/geek, this can be hard when you are used to dealing with a computer more than people, especially in high-stakes situations where the tension and stress can make things even more difficult. From a personal standpoint, I feel that helping computer scientists learn communication skills--both oral and written--is extremely important and can help make them more than just "code monkeys." However, we must also be able to communicate technical information to people who may have very little technical expertise; this is, in my experience, one of the hardest things to do.

The Wikipedia article on software engineers also mentions that even the use of the term "software engineer" is still contested as some countries, such as Canada, where people believe that the field is too young and is changing too rapidly to be given a title that includes "engineer." Some people believe that there should be no software engineering certifications (because software engineers are not truly, in their eyes, "engineers"). I do not completely agree with this assessment because to be more than just a programmer, you need skills that I feel are inherent in any engineering discipline--the ability to communicate effectively, the ability to be a productive member of a team, the ability to be professional and follow specifications for appropriate software engineering practices, etc. I do feel that it is important, especially for people who work on software that is high-consequence (e.g. for hospital equipment or traffic systems), that they can be certified as someone who is capable of not only programming but also of following approved design, debug, and maintenance procedures during software development.

On the other hand, there is the Agile software development movement, which challenges the belief that software engineers should be subjected to restrictions, procedures, and certifications and instead emphasizes the coding ability of the programmer and their willingness to take responsibility for their creations. I find this to be an interesting compromise between the more traditional view of a "software engineer" and a "computer programmer." One the one hand, there are not as many rules, regulations, and procedures, which can bog down a process to the point that it becomes useless and meaningless. On the other hand, it introduces responsibility and flexibility, allowing the programmer to make decisions and answer for them, which I feel is very important in any field. Personally, I find the Agile philosophy to be appealing because of this approach. Too often, trying to quantify skills for certifications, especially when it comes to software (where even quantifying materials, man hours, and product results can be difficult), is something that nobody can agree on and just leads to regulations and restrictions that vary so widely that it is impossible to compare them.