Chocoholics Anonymous

While assessing the needs of the Chocoholics Anonymous organization our team agreed unanimously that we wanted to gain the most value out of this project. We first sat down and decided our approach for how to handle this project in the most professional and business simulating way possible. During this sit down we agreed to treat this project like a real business venture. For that we would use a hybrid approach that consisted of some project management techniques as well as agile software engineering techniques. For this project we would need a finished result that can be used by developers to accomplish the tasks with very little questions. To accomplish the project in the manner we set forward we needed to achieve a fine-grained set of requirements and specifications during multiple sessions of business and software analysis. This means we need to have all the items needed for development figured out and all assumptions handled ahead of development as a result of these sessions.

We managed to set up mock actual sessions of requirements gathering like that of a actual business analysts. During these sessions we would go back and forth with problems from the project and come up with viable solutions and answers to these problems, documenting them as we proceeded. Then came the user interface, for this we put together ideas about what we would like to see in the user interface and how customers would interact with it. Next we considered the development process and how the structure and layout of classes and other items should and could look. For this we created diagrams to assist development efforts such as the collaboration diagrams and class diagrams. We decided on collaboration diagrams versus sequence diagrams in the interest of time because we could just modify our class diagrams and add the functional workflow of the application to them.

Finally, since we would not be doing the actual development, short of some UI mock-ups, so we decided to put on our testing hats. For this we devised scenarios to test the application and help flesh out missing requirements and specs that needed further defining. Through these team exercises we aimed to control the scope of this project and achieve the finished product of requirements and supporting documentation that could lead to an expedited development and delivery for overall success. To better understand the length of our efforts lets go more in depth with what was actually accomplished. Business Analysis

For this analysis we acted out the roles of stakeholders and business analysts. We went back and forth with what we knew and what we needed to know about the project. This long and grueling process resulted in a set of items that could be later fine tuned and refined into great requirements. Through this exercise we gained insight as to how frustrating it can be to gather requirements even when everything is seemingly defined for you. Fine-tuning the items created in the exercises would prove to be a little easier than the actual defining itself. Through this effort of fine-tuning we managed to extrapolate the actual assumptions for each item of the future application and come up with true requirements that can be used by a developer for creation and coding of the application.

As shown in the use cases (Appendix A) you can see the result of some of the time and effort of requirements gathering. These use cases are pretty thoroughly defined processes that represent the interactions with and within the application. They can be defined in a number of ways. Scott Sehlhorst mentions a few tips in his blog entry about writing good use cases. “Clearly indicate the user goal represented by the use case, Avoid specifying the design of the system, Make people want to read the use case not dread reading them, Allow for evolution of use cases across releases, Define the scope of the project, Write consistently (Sehlhorst, 2007).” We tried to follow these tips and the instruction provided throughout the class to create the best and most applicable use cases possible. These use cases would drive the goals of the project and our general though and planning process to the user interface. User Experience

We found that as we defined the use cases we began immediately thinking about how the use cases would look as a user interface and user experience. The user experience is an important piece to the overall puzzle of creating software. According to blog writer Dmitry Fadeyev “a good user interface needs to be clear, concise, familiar, responsive, consistent, attractive, efficient, and forgiving (Fadeyev, 2009).” When we set out to come up with a mocked user interface we talked about what items would make these graphics easy to understand. As well what would make them pop on the page or whatever would display them. For this we came up with a decent mocked set of graphics in html to emulate what the user would see in the interface for the application. This set of mocked up graphics would prove to be attractive, consistent, and even familiar. The other items on the list such as responsiveness, efficiency, and forgiveness would have to be realized after the actual development itself was accomplished.

The screen shots in Appendix E clearly show the basic principals we attempted to mock/create. We knew that a basic drop down menu system in a header would provide the navigation. This navigation would go to all the different items needed to express functionality of the application. The hardest part of creating this was keeping them all together in the way they were designed. By this I mean the color and design flow. We wanted all the items to look like they belonged together and function together. This would provide an unrivaled experience given the proper back end programming. We exploited the strength of our team and used HTML5 and CSS3 for the mock up. This mock up showed the basic flow that a use would see when navigating and traversing through the application. This interface came together in a very professional fashion and very quickly. The looming question with the user interface though was the implementation behind the graphics. Development Design

When thinking about implementations for the backend we tried to think functionally what would need to be created from package structure to classes themselves. When beginning to create the appropriate documents to support this project regarding development we decided that a quick review of our textbook would provide the needed guidance. We referenced “Section 13.1 Workflow Analysis” on pages 405-406 in favor of using the methods we have learned for creating the proper class diagrams. This would offer us the advantage of offering entities and their interaction in the application to the developers. This would provide the clearest understanding of the application to be developed.

We managed to come up with a basic class structure that we, not all developers, would understand and be able to logically use to create and develop the needed items of this project. We managed to create the class diagrams to support our thought process for the creation of the functionality. Utilizing “draw.io” we were able to utilize visio quality flow chart creation tools to map our diagrams and detail them as we proceeded. We later expanded these to contain the sequences needed for flow of the application as well as you will see in Appendix B class/collaboration diagrams. This basic flow of operations and functionality would guide us further down the path to create this projects supporting documentation as we all agreed that the set of what we had created could be used to make the development run much smoother than it would without our documentation. Application Testing

Once we had a good amount of supporting documentation on the structure of the classes and packages as well as the basic flow of operations through the collaboration diagrams we know it was time to think testing. This is the most important and most exposing part of the requirements gathering and document creation. This is where we think about the application and its integration with all the moving parts. We wanted to consider every permutation when we first started but decided to control our thoughts and focus on the major items at hand. This was in part to trying to control the scope and our time management for the project and took a bit of maturity on our part as a team. While we could have spent the whole time coming up with every option we could think of we settled on coming up with pertinent scenarios that would reflect proper operation of the application instead.

As you see in Appendix D we have explained the basic functionality through testing and functional scenarios. As mentioned before we tried to stay focused on covering the bulk of primary functionality rather than getting lost in edge cases as we know the time and scope limitations of this project were at stake. This focus and determination allowed us to come up with very intuitive and exploratory test scenarios that aimed to expose minor errors or bugs in the project as the application was to be developed. BY this I mean that these scenarios would provide the development a way to guide testing practices as they created the functional pieces. This testing would be at an integration and end-to-end level rather than unit testing. Unit testing would be handled on a component level and integration being the moving parts working collaboratively across the application. Scope and Functionality

The core of the functionality for this application rests with the use of members and providers of services. The equipment that is supplemental to the software is paramount as the gateway to the application and collection of data needed for the users of the application. The tangible items such as embossed cards and card readers provide the avenue of access into the data collection for the providers and system admins about the members and the service providers so they may send the time needed to actually provide the services to the members. These services are from an array of offerings such as medicine to exercise organizations. The goal of the application is to keep all of this in order as the members pay their monthly fee and utilize the services provided. The amount of work that will be reduced by putting this software together versus whatever old-fashioned paper and pen method should be monumental. This software solution should also be able to help maintain more accurate records and keep better order during the business life cycle.

Conclusion
While trying to achieve success on such a short timetable our team managed to gain a lot of useful insight and knowledge from this project. We managed to operate as a well functioning team while under demand for quality work while developing the needed requirements and documentation needed to develop this application. Successful communication was key while simulating the key business roles such as: business analyst, pre-development software architect, software validation tester, and user interface developer. Through these roles we managed to create the needed documentation to support our finished product of requirements and specifications. Given the opportunity these items will offer the right group of developers an easy and well-guided way to create a software solution to meet and maybe even exceed the needs of the Chocoholics Anonymous organization. Appendix A

References
Flow Chart Maker / Visio Online. (n.d.). Retrieved December 7, 2014, from https://www.draw.io/#LUntitled Diagram
Fadeyev, D. (2009, April 15). 8 Characteristics Of Successful User Interfaces. Retrieved December 5, 2014, from http://usabilitypost.com/2009/04/15/8-characteristics-of-successful-user-interfaces/ Schach, S. (2011). Object-oriented and classical software engineering(8th ed.)). New York: McGraw-Hill

Sehlhorst, S. (2007). How to Write Good Use Case Names – 7 Tips. Retrieved December 6, 2014, from http://tynerblain.com/blog/2007/01/22/how-to-write-good-use-case-names/