Back To Work!

This past week we had spring break and not much happened, except for everyone here getting sick... I was able to do some good reading in a book about hacking web applications. It is a pretty long and intense book, but so far it is a pretty interesting read, it is well written (didn't put me to sleep), and I have learned a lot so far! I also did some learning of the python programming languages and how to create classes as well as using Tkinter.

One of the things that is pretty annoying is that Tkinter doesn't have, in Java terms, a combobox built in. I had to download Pmw or try to write one from scratch. I guess I took all of the work that developers have created and added to the Java API for granted. Tkinter looks pretty rough around the edges but it is always good to have the experience of learning a new language and having new concepts under one's belt.

Today In class prof Kniss went through a few of the team's wikis/websites and basically had a lot of things to tell us about how we needed to be better. One of the things that I asked him was about how requirements are handled in the Scrum method. In a lot of the documents that I read about Scrum it seemed that requirements are looked at very differently in comparison to other software development processes. Instead of starting the project with a detailed analysis of the desired functionality and creating requirements from that, the Scrum method starts a sprint by talking with the Product Owner/ client and derives a product backlog from what is said. A sprint backlog is then created and work is done to try and accomplish the different tasks.

After a lot of searching online for getting requirements that would fit with what CS 460 asks of us I finally found a good website. The main points that I got from this website as well as some of the things that we discussed in class are the following:

• User stories are to be written out describing what we want the product to do. An example of one kind of format for user stories from the website: "As a I want to so that I can ."
• The user stories are then parsed to figure out what tasks need to be completed to achieve these higher level requirements, these then create the product backlog
• The user stories need to have a section describing on how these are validated, through tests and what not.

Scrum is interesting in that in each sprint there may be many tasks that aren't accomplished and that may not end up in the next sprint or in the final product. This was difficult for me at the start thinking the following:

"How can I give all the sprint tasks a unique identifier and create a requirement from them if I am not sure it's going to actually make it in? Are we just going to have a whole bunch of requirements that weren't completed? That doesn't look to nice on our record!"

My conclusion is as follows, as we create the backlog and add to it, each of the items will have a column showing the necessity of the item. Namely we will have a decent idea of requirements that we must be accomplished as well as requirements that have a necessity of "if we have time it would be nice" or just labeled as "features". That way by the end of the project yes we will have requirements that aren't met, but that will be ok because we didn't intend on implementing that feature, it was intended as an extra.

Something else that I want to do is make sure that everything is tied together:

• Each User story has a list of the requirements that were derived from it
• Each Requirement has a test tied to validate it
• Each section of code which is implementing a requirement and each test which is testing a requirement contains the unique identifier in a comment either at the top of the file or in a comment right above it. This way we can create a script that will go through all our code and output which requirements are accomplished and which ones are not.

It's a lot of stuff to think about! The development process is something that is pretty tricky when you actually sit down and think about it. The problem that I think we are running into is that we are all trying to figure out how to make the program function and there is a lot of overhead in dealing with requirement creation, setting up meetings, doing documentation, and ensuring that validation of our requirements are being carried out. It seems like we will need one person who is in charge of all the overhead stuff and not so much involved in the coding. We shall see if that happens or not. It seems like I am the one that came to this conclusion, I should probably be the one to carry it out... We shall see...