Interviews -
After review of the methodologies I am using and consideration of the scenario I think that informal interviews will be more appropriate than a set formal questions. I conveyed my thoughts to my project lecturer and my arguments were convincing.
The system composes of 3 parts (front end MIS, middleware and a web site) and each will have to be developed in a separate stage (since I am only one developer). I know for a fact as a amateur and very junior developer attempting to code 3 different systems at the same time is too much for me. Each part of the system will be based on the business processes and business logic of the school's departments who actually use these processes. Even though there will be one analysis I believe that I will have to revisit the people from the original interviews for additional information and confirmation of some of the details involved in the logic of the software. It would serve the project and the employees (SBCS staff) to have a more casual interaction with short conversations instead of structured interviews and questions.
The system composes of 3 parts (front end MIS, middleware and a web site) and each will have to be developed in a separate stage (since I am only one developer). I know for a fact as a amateur and very junior developer attempting to code 3 different systems at the same time is too much for me. Each part of the system will be based on the business processes and business logic of the school's departments who actually use these processes. Even though there will be one analysis I believe that I will have to revisit the people from the original interviews for additional information and confirmation of some of the details involved in the logic of the software. It would serve the project and the employees (SBCS staff) to have a more casual interaction with short conversations instead of structured interviews and questions.
- This way the staff members do not have to structure strict meeting times that would interrupt their schedules.
- I could contact the interviewees via emails or visits to the office (on the days i have class) and I would take care to solicit their time in the most unobtrusive way possible.
- The information from a casual conversation would more honestly describe the users experience with the system and how they feel about certain processes and how they may be reworked for efficiency.
- This way users get to see parts of the system progressivly and their input can be filtered-in incrementally into the design process. (This is a project with a deadline and as a new developer i know i will miss some ingredients in the initial phases - by including the users and constantly having their feedback in small amouts; I hope to catch at least any key points initially left out.)
I hope to publish the general findings from the interviews here. Time permitting i would like to submitt for the report the findings of the interviews as a diagram or picture. I hope that turns out well - because the interviews will be short my notes will be consice and mostly scribblings; that wount be acceptable as a document.
I hope to draft the similarities and differencs as either a rich pic or a flow diagram and this should link nicely into the requirements for the the first part of the code - The MIS.
Also I intend to turn the conversations into User Stories. I have a whole lot of documents on user stories and I in the next post i will publish some of what i hope to use and the links referencing the documents. After the interviews i will publish my approach to the stories and the requirements. These techniques are in line with the Agile Development path. They include methods like user involvement and having cases and scenarios documented that bring the developer closer to the users understanding of the functionality expected. This hopefully will result in less rework as a result of mis communication.

No comments:
Post a Comment