Kudler Fine Foods Frequent Shopper Program Team D: Jose Frias, Delone Martin, Laurah Calligan, Ronald Tidwell BSA375 May 25, 2015 Todd Feuerherm Kudler Fine Foods

Analysis Key Stake Holders Interview/Meetings High Level Overview After identifying the key stake holders it will be important to have meeting and interviews to gather important information about the system requirements for the now system for loyal shoppers. The application Go Meeting will allow for us to automate all the necessary meetings to complete the analysis phase. After gathering all the information that we deem important we will present the organization stakeholders and upper management with a high level overview of the new information system that will store and track the rewards for the loyal customers.

Design Focus here is how will the new system function? Type of DB (database), Server (physical or virtual) Interface that the customer requested as structure, standard or prototype? Kudler Fine Foods Design what was determined by the Committee team – Stakeholders, Core team, and extended members. Review application architecture and process design to be implemented.

Design Process When a user clicks the checkout button on the website, the site will ask them if they have a current account or allow them to check out as a guest. Only users with accounts will be tracked for the loyalty program. If the user does not have an account, they will be given a chance to create one as part of the ordering process. Users must enter the following information to create an account: Name, a billing address, an email address, and they must have at least one item in their shopping cart. The site will not save payment information but payment information will be required to complete the order. Once they have created an account, they can log into their account on the website to view their loyalty point balance and redeem points. The system will track each order individually and award points based on the value of the order before taxes and shipping. The total from each order will be added to the users redeemable account balance.

Implement Preliminary design illustrating overall logical information architecture On commencing procedure, will determine if buyer is part of the frequent shopper program Existing logical information of current transactions. -- Will have existing and then new flow chart

Cost vs Schedule vs Performance Design Trade-Offs Cost vs Schedule vs Performance Cohn (n.d.), “There is a tradeoff to be made between schedule and cost. Most of the time, schedule wins. Companies always want things at the lowest cost they can—but not at the expense of schedule” (). Usually an organization has to balance cost, schedule, and performance to get a desired outcome. They want the product produced as cost effectively as possible, on time, and they want the product to perform as expected. Of the three considerations for most organizations; cost, schedule, or performance; performance is the one item that is almost never compromised due to cost or schedule. Companies and organizations want everything as cheaply as possible but they also want whatever they by to perform as expected. Cost can include the salaries of the individuals involved in the project, the cost of any software purchased for the project, as well as the time it takes to correct errors when they happen. Time is money. Companies and organizations also usually want everything right now. Meaning they want everything as soon as possible. In the case of software programing, sooner is usually not better. Producing software as fast as possible usually means there are a lot of errors and bugs in the code. A good example of this would be the ET game produced by Atari. This game was produced in about 5 weeks. Performance seems to be the common factor in cost vs schedule. You can pay a lot for something to be delivered on time without sacrificing performance by adding more people to the team. Or you can lengthen the schedule to allow a limited number of people more time to get you the performance you want. Or you can lower your expectations on what you expect from the new system. You usually cannot do all three. One of them has to be compromised for the sake of the others. Most of the time, a company will choose to compromise cost over schedule or performance. They are willing to throw a little more money into a project to have it done on time and work as expected.   Reference Cohn, M. (n.d.). Schedule vs. Cost: The Tradeoff in Agile. Retrieved from http://www.mountaingoatsoftware.com/blog/schedule-vs.-cost-the-tradeoff-in-agile

Questions We would like to thank everyone for attending on the behalf of the team. Our team is looking forward to implementing the recommended changes. Does anyone have any questions?

References Graphics. (n.d.) Retrieved from http://www.google.com