Requirement & Use Cases.
The Requirements for the Mock MIS is easily derived.
They came directly from the user stories.
Even thought the MIS will only provide a subset of the functionality of an actual system it was important to derive functions and object common to the different departments.
Three object that apply to all the academic departments were chosen;
Academic Body - Universities and Boards
Programme - A Degree / Diploma
Course - Subjects within a programme
ID Requirement Description – Mock MIS
01 Add Academic Body
02 Add Programme
03 Add Course
04 Edit Academic Body
05 Edit Programme
06 Edit Course
07 Remove Academic Body
08 Remove Programme
09 Remove Course
10 Notify Middleware
11 Send Update
ID Requirement Description - Middleware
12 Receive Notification
13 Process Notification
14 Request Update
15 Receive & Publish Update
Use Cases will be used to detail each requirement.
Tuesday, February 24, 2009
Week 31
The following is a diagram depicting the current system as I understand it.
The analysis will include ... a justification of why we are using middleware as the connecting technology. This software could have easily been constructed where the website is in MIS and published from the same server. The MIS could directly interact with the website to publish updates and the system would be significantly simpler in design.
There are several disadvantages to the latter method - commonly refered to as integration.
Disadvantages:
Advantages:
The feasibility analysis compared the following;
The user stories should come after and hopefully be a proper lead into the design that follows.
The analysis will include ... a justification of why we are using middleware as the connecting technology. This software could have easily been constructed where the website is in MIS and published from the same server. The MIS could directly interact with the website to publish updates and the system would be significantly simpler in design.
There are several disadvantages to the latter method - commonly refered to as integration.
Disadvantages:
- Highly coupled design
- Difficult to expand
- Limited load capacity / or capacity relative to hardware
Advantages:
- Simple design
- Simple configurations
- Likely a more cost effective solution
The feasibility analysis compared the following;
1. Technical
2. Operational
3. Economical
4. Schedule
The user stories should come after and hopefully be a proper lead into the design that follows.
Tuesday, February 10, 2009
Week 30
Analysis
User Stories -
The user stories will be initially drafted by me and then sent to the departments for approval. This way the users dont need to spend too much time bogged down with the details of what the project entails and how i need to go about achieving it. When I meet with the department representatives for the second time to show them the user stores that I created, I will give a brief of what type of the system the stories represent.
The user stories will be tied to testing. No its not that strange. For each User story there will be on the same document a corresponding test case. The user stories will be used as a starting place for the user stories that will lead directly into the design but they will not be able to give an appropriation of design time. The user stories will only cover the basics of the Mock MIS operation and therefore cannot be an estimation of the entire development process.
http://www.extremeplanner.com/blog/2006/01/writing-good-user-stories.html
Mountain Goat Software outlines the advantages of user stories. It also individualizes user stories from use cases and requirement definitions.
There is a very good metaphor identifying user stories with goals instead of requirements. This really brought home to me the meaning of what the user story should tell and maybe how to tell it. They described requirements and made mention of the IEEE style for writing them. They contrasted on how formal requirements can be unclear when trying to outline the general or rather actual wants of the user in contrast to a goal. And how a user story is not a goal but rather a description of a goal in the form of a story.
The following resources were also used in forming the methods used for collecting and writing the user stories.
http://www.agile-software-development.com/2008/01/example-of-user-story.html
http://dannorth.net/whats-in-a-story
http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/
http://www.agilemodeling.com/artifacts/userStory.htm
Work Flow Diagram -
User Stories -
The users will have direct input into the user stories that will foundation the Use Cases for this analysis. According to research user stories should be ideally written by the users themselves. In this case the MIS being constructed is for the purpose of demonstrating the functionality of the middleware and not its (The MIS) functionality. As a result the detail that the users may want to include in user stories would exceed the needs of this system. The user stories should cover enough functionality to modle some of the interactions the user would engage in daily processes. The MIS will not however model these processes in detail. If the users were left to propagate the stories on their own they would most likely exceed the detail necessary and loose sight of the focus of the *Mock MIS*.
The user stories will be initially drafted by me and then sent to the departments for approval. This way the users dont need to spend too much time bogged down with the details of what the project entails and how i need to go about achieving it. When I meet with the department representatives for the second time to show them the user stores that I created, I will give a brief of what type of the system the stories represent.
The user stories will be tied to testing. No its not that strange. For each User story there will be on the same document a corresponding test case. The user stories will be used as a starting place for the user stories that will lead directly into the design but they will not be able to give an appropriation of design time. The user stories will only cover the basics of the Mock MIS operation and therefore cannot be an estimation of the entire development process.
The four simple rules outlined by David Churchville on the Agile Project Planning blog is a clear guide for writing user stories and I employed these guidelines as thoroughly as possible.
http://www.extremeplanner.com/blog/2006/01/writing-good-user-stories.html
Mountain Goat Software outlines the advantages of user stories. It also individualizes user stories from use cases and requirement definitions.
There is a very good metaphor identifying user stories with goals instead of requirements. This really brought home to me the meaning of what the user story should tell and maybe how to tell it. They described requirements and made mention of the IEEE style for writing them. They contrasted on how formal requirements can be unclear when trying to outline the general or rather actual wants of the user in contrast to a goal. And how a user story is not a goal but rather a description of a goal in the form of a story.
The following resources were also used in forming the methods used for collecting and writing the user stories.
http://www.agile-software-development.com/2008/01/example-of-user-story.html
http://dannorth.net/whats-in-a-story
http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/
http://www.agilemodeling.com/artifacts/userStory.htm
.
Work Flow Diagram -
Week 29
Analysis
Interviews -
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.
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.
Friday, February 6, 2009
Week 28 - The Framework
Two Things -
The Framework under primary consideration is Struts2 using an integration framework called Appfuse . Struts2 falls under the J2EE environment (that's Java) and is a framework for web centric development. Its is very important to note the purpose of Appfuse. It fuses Struts with a set of other (popular) frameworks to provide a nice MVC platform for software development. It can use a combination of Spring, Hibernate, IBATIS, JPA, Tapestry (and some others) and it builds with Ant or Maven.
All this means is that, Appfuse puts frameworks gered to different implementation solutions (front end, back end, persistence, security ect.) into a bundle and helps with the configurations that were previously very cumbersome. (It is so helpful - that if i were asked to develop using the frameworks without appfuse as an amateur programmer I would never attempt to configure all these on my own - it would certainly be a formidable task).
Part 2 -
This project is composed of 3 parts and their inter-workings; together they are a challenge for a single designer. The coagulation of frameworks serves as a great foundation for a project of this scope. It comes with some built in functionality that will greatly ease the programming burden from tasks that are required for the system to run but are not necessary to demonstrate the core functionality of the middleware. Learning the functionalities of the facilitating technologies and how to use their APIs is a project in itself.
I started learning the framework in late July 2008. It took me a month just to get the framework to Build Successfully. At the time when the framework was up and running, I was proud and happy. Now it seems sometimes like a false celebration. Every day this code throws something new at me. The next series of entries I hope to out line some of the difficulties I encounter.
I am thankful though. The little knowledge I have of computers has served me well. One of the first issues when trying to build my first project was actually exposed later on on the official website as a common occurrence. At the time of course I found little or no support online for the tomcat server that would download nicely but not execute. That was so frustrating. I followed the exception (stated the distribution was corrupted ) to the Locals \ Temp folder where Tomcat was being downloaded to and examined the .zip package. The file did not seem corrupted and the exe ran fine. However in the folder was also the unzipped package which the framework was using to execute. I looked at the innards but most ignored it b/c, it was the same as the zip file just unzipped.
Now after trying for a few nights to pull the tomcat from alternate sources by editing the xml configurations in appfuse and redirecting where it downlowaded that dependancy and had the same probelm over and over, I went back to the tem folder. When I looked at the folder structure of the Unzipped files i noticed something; the Root folder was Tomcat X (the version) and in it contained another folder Tomcat X (version). I thought what if the program was looking in the root for the the exe and the dependant files. It would obviously fail b/c they were not there, they were in a sub folder. Look at that - The stupid local zip program was confusing the poor framwork, not to mention driving me insane for a few nights with little sleep. (And shcool was out - what would happen to me when i had classes and a job and had to do this at night - would I survive - that is still left to be seen...). I restructured the folders to what i thought the framework was expecting and I ran the installation offline. Appfuse allows you to download everything into a repository so your system can build and run offline. Now the idea worked, just not the first time. It took some working into but eventually it ran and I was happy I could finally start learning to use the thing.
The online tutorials are sufficient. After starting to follow them school, course work for another course (DIS) and all the research for this project and deliverables and the deadlines that came along with all these things took precidence and when I finally got back to the framework tutorials in late October (yes months passed) I felt a little lost and resorted to starting over.
Over the Christmas holidays I got throught the most of it, however another deliverable in January did not help my timeline where I planned to have started the actual project application or at least a mock of it.
So here's to the following weeks and the hope that I can apply all that I have learned to the app I have envisioned for the Final Project (and somewhere in between execute and document my analysis and the rest of the writeup).
http://appfuse.org/
http://struts.apache.org/2.x/
- The Framework Justification
- My History with the Framework
The Framework under primary consideration is Struts2 using an integration framework called Appfuse . Struts2 falls under the J2EE environment (that's Java) and is a framework for web centric development. Its is very important to note the purpose of Appfuse. It fuses Struts with a set of other (popular) frameworks to provide a nice MVC platform for software development. It can use a combination of Spring, Hibernate, IBATIS, JPA, Tapestry (and some others) and it builds with Ant or Maven.
All this means is that, Appfuse puts frameworks gered to different implementation solutions (front end, back end, persistence, security ect.) into a bundle and helps with the configurations that were previously very cumbersome. (It is so helpful - that if i were asked to develop using the frameworks without appfuse as an amateur programmer I would never attempt to configure all these on my own - it would certainly be a formidable task).
Part 2 -
This project is composed of 3 parts and their inter-workings; together they are a challenge for a single designer. The coagulation of frameworks serves as a great foundation for a project of this scope. It comes with some built in functionality that will greatly ease the programming burden from tasks that are required for the system to run but are not necessary to demonstrate the core functionality of the middleware. Learning the functionalities of the facilitating technologies and how to use their APIs is a project in itself.
I started learning the framework in late July 2008. It took me a month just to get the framework to Build Successfully. At the time when the framework was up and running, I was proud and happy. Now it seems sometimes like a false celebration. Every day this code throws something new at me. The next series of entries I hope to out line some of the difficulties I encounter.
I am thankful though. The little knowledge I have of computers has served me well. One of the first issues when trying to build my first project was actually exposed later on on the official website as a common occurrence. At the time of course I found little or no support online for the tomcat server that would download nicely but not execute. That was so frustrating. I followed the exception (stated the distribution was corrupted ) to the Locals \ Temp folder where Tomcat was being downloaded to and examined the .zip package. The file did not seem corrupted and the exe ran fine. However in the folder was also the unzipped package which the framework was using to execute. I looked at the innards but most ignored it b/c, it was the same as the zip file just unzipped.
Now after trying for a few nights to pull the tomcat from alternate sources by editing the xml configurations in appfuse and redirecting where it downlowaded that dependancy and had the same probelm over and over, I went back to the tem folder. When I looked at the folder structure of the Unzipped files i noticed something; the Root folder was Tomcat X (the version) and in it contained another folder Tomcat X (version). I thought what if the program was looking in the root for the the exe and the dependant files. It would obviously fail b/c they were not there, they were in a sub folder. Look at that - The stupid local zip program was confusing the poor framwork, not to mention driving me insane for a few nights with little sleep. (And shcool was out - what would happen to me when i had classes and a job and had to do this at night - would I survive - that is still left to be seen...). I restructured the folders to what i thought the framework was expecting and I ran the installation offline. Appfuse allows you to download everything into a repository so your system can build and run offline. Now the idea worked, just not the first time. It took some working into but eventually it ran and I was happy I could finally start learning to use the thing.
The online tutorials are sufficient. After starting to follow them school, course work for another course (DIS) and all the research for this project and deliverables and the deadlines that came along with all these things took precidence and when I finally got back to the framework tutorials in late October (yes months passed) I felt a little lost and resorted to starting over.
Over the Christmas holidays I got throught the most of it, however another deliverable in January did not help my timeline where I planned to have started the actual project application or at least a mock of it.
So here's to the following weeks and the hope that I can apply all that I have learned to the app I have envisioned for the Final Project (and somewhere in between execute and document my analysis and the rest of the writeup).
http://appfuse.org/
http://struts.apache.org/2.x/
Subscribe to:
Posts (Atom)
