ECM81IS Mobile Commerce

Executive Summary

DownTown Videos, wants to take advantage of the market by developing a state of the art system for renting movies and video games. In order to achieve this, the system to be developed must include all the objectives to satisfy its customers better. Using the internet and the World Wide Web it is determined to unite all its customers by providing excellent services to its customers.

Background of the Study

Automating processes in businesses has been a controversial issue that determines failure or success of a business. Most businesses nowadays have automated their process in order to gain an edge over other businesses. Besides the ongoing growth in business, the current manual system in place at the DownTown videos doesn’t not provide means in which it can give proper services to its customers such as the keeping of inventory, keeping track of useful information about movies such as the movie titles, genre, and customer related information and so on. This has led to the loss of important information that is stored in print form. As a result, the business has faced stiff competition from other movie and game rental businesses around.

Literature Review

In order to overcome this problem DownTown Videos is experiencing, it has been decided that an online rental system will solve their problem. The system will improve the services towards its customers by automating all the process to be undertaken while renting the movies and games thereby gaining a competitive edge over its competitors. The objectives of the system will include;

• Store information about movies (genre, rental type, rating, cost, and producer).
• Create a nice user interface to improve customer interaction.
• To ensure that the rental system performs the operations in real time and ensure optimum utilization of resources.
• Extending video marketing to other areas.
• To help the management in making a decision about the store.

Resources/Materials used for the system

To make the project a success, a number of software and hardware materials will be needed to complete the system and meet its objectives. These includes:

• High-speed laptops or desktops.
• MySQL server to store data.
• An Integrated Development Software such as NetBeans
• Programming language such as PHP, HTML, JavaScript

Potential Risks

Risks can be defined as the changes that happen in the project management process that may have an influence on its development (Barkley, 2004). There are many types of risks that may affect a system under development. In our scenario, we encountered some of the risks that could influence the development of the system. These could be:

1. Technical risks - One of the main reason behind the risk could be because of the requirements that could change as per the customer. Since the project team involved each and every stakeholder in the development of the system (i.e. customers and staff), it noted that requirements had to change as per customer. Another reason was that in the integration of different modules of the system we could have some problems. These risk would, therefore, make the system fail and hinder its functionality if not taken care of.
2. Management risks – these are the risks associated with environments that are not conducive enough, insufficient hardware reliability and low effectiveness of the programming. The solution to this problem is that, if the team leader is working with a team for the first time he/she should go through a testing period in order to familiarize with the team

• Operational risks – the team leader should be aware of such risks that could lead to loss owing to inappropriate process implementation(Karolak, 1995). These risks may happen as a result of inadequate resources, lack of resource planning, lack of team communication as well as failing to settle the responsibilities. (QArea, 2011).

1. External risks – these are factors that are not in control of the project team. These risks can be in form of war, crime, bankruptcy etc.  This poses a direct threat to the project since predicting, and controlling them tends to be difficult(Raftery, 2003).

Timeline/Work Breakdown

With the help of a Gantt chart, we can provide a way in which we can plan, coordinate and track tasks that are related to the development of a system in a graphical manner (Clark, W). The system to be developed will include the following steps that are going to be followed as shown in the Gantt chart below:

Week Activity	1	2	3	4	5	6	7	8	9
Feasibility study
Analysis
Design
Coding
System Testing
System Implementation
System Maintenance
Documentation

Methodology used

The agile methodology makes use of agile teams that work directly with customers in order to appreciate the objectives and give a result without much delay and in an incremental manner (Cockburn, 2002). The iterative methodology, on the other hand, uses a completely different path as compared to agile methodology. In this method, the software is developed through recurrent cycles and in lesser portions at a time (Basil et al. 1975).

One of the methodologies used in the agile category is the Scrum methodology. It is a framework that assists people can solve intricate problems while delivering products of high value creatively (Schwaber et al. 2002). On the other hand, extreme programming delivers short and frequent parts of the system under development in an iterative form. The customer is involved during unit testing and reviewing the code. (Beck, Gamma 2000).

Differences between the methodologies

There are some of the differences between scrum and extreme programming as explained below:

• To start with, the team undertaking the scrum method do not encourage any changes in their sprints. When the sprint gathering is over and a pledge is done to bring the set of product backlog items, these items are left unaffected till the conclusion of the sprint whereas extreme programming teams are prone to more changes in iterations.
• In the scrum, the time interval between sprints ranges from two weeks to a month-long whereas iterations in extreme programming are in between one to two weeks long.
• In the scrum, the owner of the product determines the workload by prioritizing the product backlog from the one with the highest priority descending to the one with least priority. In Extreme programming, however, everything is prioritized by the customer. It uses the first come first served notion.

DownTown video system would likely use Extreme Programming methodology. The project manager has realized that in order to retain and attract more customers, the system must give maximum satisfaction. This methodology then integrates both the customers and the project development team. This gives the customers knowledge of how the system is like and gets a chance to give their own ideas. This makes them feel that they are part and parcel of the system being developed.

Another issue that needs to be taken care of is the time that is needed to complete the system. The team must, therefore, be as efficient as possible while delivering the product. In order to achieve this, the project leader must stress teamwork. This methodology assumes that customers, managers, and the developers are equal partners as a collaborative team. The team them works around the problem in order to tackle it more efficiently.

The other issue is that the system must be as flexible as possible. This helps changes to be done more frequently in the rise of any requirements. Since we are living in a changing world, new things tend to emerge. The project team must always be in contact with their customers and be ready to welcome any changes that the customers feel that the system should do. The team should then take this into consideration and work on the requirements during the oncoming iteration. Working on new requirements for the system will also help in customer satisfaction.

Finally, for the DownTown Videos to reduce the costs involved in changing the requirements, it attempts to break the development cycle by having short developments instead. This helps the team to plan adequately and take into consideration all of the requirements and resources that are needed in the development of the system in small bits than when taking all of the systems into consideration (Bahli, 2005).

Gathering adequate requirements is a very important part of the development of DownTown Videos system. Requirements determine if the project will be delivered as a success or not (Hofmann, H.F, Lehner, F., 2001). There are many methods of collecting requirements some of them are; sampling, use of questionnaires, interviews, observation, brainstorming etc. In the case scenario above the system to be developed will have to use interviews, questionnaire/ surveys and the use of prototypes as a form of collecting the requirements.

DownTown requirement collection techniques

• Interviews

The project manager can conduct meetings with the stakeholders and get requirements from them directly. During a meeting session, the manager can draft a list of questions that are related to the project under consideration. The stakeholders are then entitled to answer them or even give additional information. Otherwise, he/she can conduct the interview through the use of emails or even via phone calls. The manager will then note down the feedback from the stakeholders and store it to be used during the development of the system.

• Use of questionnaires

This is a method that will be used to collect the requirements because the DownTown Videos has a large number of stakeholders. Since organizing meetings and interviews will consume more time to collect and finalize the requirements, use of questionnaires will be a better alternative. This method uses a series of questions in order to collect important information related to the project. Since it uses a YES/NO question format it gives the project manager a direct feedback hence simplifying the requirement collection process.

• Use of prototypes

A model called a prototype is first created cheaply and fast. It is a representation of the system to be developed though it is not complete (Young, 2002). The model is then given to the stakeholders to experiment with it. If there is a part or functionality that they may not like or which requires improvement, the feedback is then presented to the manager who makes necessary improvement or corrections

Functional and Non-functional requirements

Functional requirements are those things that the system is supposed to perform. These are the preferred outcomes that the stakeholders are expecting from the system (Thayer, 1995). Non-functional requirements are those requirements that state exactly what should be done by the system while Non-functional requirements dictate how the system should perform its functions (Rainardi, 2008).

 The functional requirements most likely to be evident in the DownTown Videos scenario are:

1. A search function should be in place to query the database and search all the available movies at the store.
2. A database module to keep all the movies details and customer records.

• A report generation module to help in the generation of reports.

1. Customer registration - Store names, location, legal information
2. Store movie information to the database – such information should be movie category(genres), rental type(new release, standard), movie rating
3. Manage inventory records(The cost for renting movies, time for movies to be returned, penalties associated if movies not returned in time)

• Have a module that keeps track of movies that are available at the store and also update itself if a movie has been taken.
• Perform restrictions to the movies and games that have been rented to the families.

The non-functional requirements likely to be evident in the DownTown Videos scenario are:

1. The system attractive and user-friendly.
2. It should use features such as buttons, context menus, and navigation buttons and so on.

• The system should be able to perform its operations in real time and have a performance.

1. The system should be easy to maintain and develop in case of any major improvements.

Use case Description

Name of  use case	Downtown Video Movie and Game Renting System
Brief Description	The system to be developed is going to allow customers to rent movies or game through this software instead of necessarily walking into the store in their respective locations.it will be an online system in which rent orders will be made via the internet. The system will collect information on which the customers need through the aid of an interactive user interface. This information will be stored in an electronic database managed by the rental stores after which the orders will be processed and the customers will rent the movies or games they want.
Author(s)	Name of author
Actor(s)	Customers(primary), Employees(secondary)
Location(s)	Muscat
Status	Medium Level of Details.
Priority	Must have
Precondition(s)	1. The customer must have a smartphone to access the DownTown website and log into their accounts. 1. The system must be working online. 1. There must be available stock in the stores. 1. The customer must have a registered account 1. The system should accommodate any updates made resulting from the return or borrowing of a movie or game.
Postconditions(s)	1. The customer has rented a movie or game. 1. The store has kept details of the movie or game that has been rented. 1. The system produces information on when to return the movie or game. 1. DownTown stores receive cash and produce a receipt to their customer.
Main flow	1. The customer logs into his/her account 2. The system displays the list of movies or games in the store in a categorized manner. 3. The customer orders a movie that he/she is interested in. 4. The system processes this request and approves it. 5. The system makes an update to the database that that particular game or movie is already taken or the number of movies in that category remains. 6. The system gives details as to when the rented game or movie should be returned back to the store. 7. The customer makes payments for the rented game or movies.
Alternate flows	· Invalid login credentials · no results found for the movie requested · invalid order · Order  not approved · You should make payments first

Proposed development methodology

In software development, a systematic methodology is an outline used to plan, arrange as well as control the process of developing a software. The DownTown Video system to be developed, a well laid out software development methodology must be taken into account. For this system, the most likely methodology to be used is the Waterfall methodology. It takes the software development lifecycle as a series of logical steps. It states that we proceed to the following phase only if the previous phase has been reviewed and verified (Balaji, 2012). We follow a series of six phases in this methodology for the system to be complete. These are:

1. Gathering requirements – In this phase, all the requirements visible in the system are collected through the various methods such as questionnaires, interviews and so on and are then documented in a requirements specification document.
2. Analysis – Here models and business logic to be used in the system are formulated as a result of analyzing the system.

• System design – In this phase, the requirements gathered in the specification document are then reviewed. In this phase also we are to draw diagrams such as the context diagrams, flowcharts, and the data flow diagrams which will aid in specifying the overall system architecture.

1. Implementation – This is the phase where unit testing comes into play. We first create small programs knows as units aided by the inputs obtained from the previous phase. These programs are then tested to check on their functionality.
2. Integration and testing – In this phase, we test for any available bugs that may be evident in the system after the coding process has been done. We also test whether the software behaves as expected as per the requirement specification document. We use software such as beta testers. If there are bugs in the application the testing software will notify the development team who takes the necessary action.
3. System deployment – the system will then be released to the market when the testing phase is through so that the customers can use and familiarize with the system itself.

• Maintenance – In this phase new versions of the products can be released. The team that maintains the system must be aware of any post-production issues in the system.

Modeling techniques

System modeling is a discipline in which models are constructed for the purpose of conceptualizing and constructing I.T systems (Kinny, 1996). The proposed software modeling technique to be used while developing the DownTown Videos system is the Unified Modelling Language (UML). UML helps to visualize, specify, and construct the design of the system in a standard way  (D'souza, 1998). This modeling language will aim at doing just the following in the development of the system:

1. It will find out the set of classes that work closely together in order to display some characteristics.
2. It will also find out the responsibilities for the classes mentioned.

• The set of classes mentioned will be monitored as a whole, if they contain too many responsibilities then they will be split into smaller abstractions.

1. The tiny classes that have the most important responsibilities will be collapsed to larger ones.
2. Relocate responsibilities so that the abstractions are independent.
3. Finally, make the classes collaborate with one another, the classes should also be redistributed so that no class are failing or over-performing.

Modeling and development tools

It has been found that the likely tools to be used in the development of the system is the Enterprise Architect. It is a tool that supports UML. It's goal bringing together all the elements involved in system development such as managing tests, analyzing business processes, building and designing behavioral models as well as creating the component and deployment models.

Conclusion

Finding the right methodology to use in developing the DownTown system will be an added advantage to the development team. Choosing a clear structure will help the software under development to be delivered in good time and within the budget. It is also important for communication to flow properly between the customers and the team developing the system. Waterfall methodology will do exactly that through user involvement. Another importance is that the system will be quite flexible when more requirements arise in the future. This will help the development team to cope up well with these requirements (Osorio, 2011).

Modeling is also another important aspect to be considered while developing the DownTown system. It will help the team and other members of the organization understand the system fast through visual analysis. Modeling will also help to reuse most parts of information and knowledge that exist in the system thereby saving on cost and time. Errors in the system will be discovered early thereby reducing the defects that may occur in the system. Lastly, modeling will detect any alternatives in the system lifecycle at an early stage (Pohl, 2005).

The DownTown Video System to be developed requires more improvement in order for it to work as per the owner and customer. Therefore the project team leader must gather more requirements from the customers themselves as well as the staff working with the system. This will only be possible if the project team integrate more with its customers. It is considered that user involvement is an important mechanism to bring in quality as well as making the system more implementable (Kaulio, 1998). More requirement techniques such as observation, brainstorming sessions should be also included so as to gather more requirements from them.

The traditional model is one of the models used in user involvement (Ives, 1984). It states that when users are more involved in the development of the system, it increases both customer usage and satisfaction. The users also understand the system more and it will also be developed as per the user's needs. As a result, the customers will be more motivated while using the system (Baroudi, 1986).

While developing the DownTown system, user involvement will have some benefits to the developers of the system. First, it will assist the developers to use the appropriate methodologies. Easy and fast system methodologies mean that data can be verified and assessed from the secondary sources in order find out user’s requirements. It can also point to having simple design methods and less complicated software functionality validation.

Secondly, involving users in system development will eliminate any clashes that might occur between the developers and users of the system.  This is true because developers will obtain firsthand information from users. They will negotiate between themselves in case of any differences between and come to an agreed conclusion.

Lastly, system involvement will help in creating a good and interactive user interface. Developers will understand exactly what the customer really wants and place dialog boxes, menus, and buttons in the right place to satisfy the customer interaction.

User interaction will generally help to collect vital information from users, which will be necessary objectives in designing an effective class diagram. One most vital importance of a class diagram is that it will describe the structure of the system and it will also dictate the notion of other diagrams depicted by UML (Chanda, 2009). In conclusion, for a successful completion of the system under development, user involvement is a vital factor in obtaining relevant and important requirements from customers.

References

Baroudi, J.J., Olson, M.H. and Ives, B., 1986. An empirical study of the impact of user involvement on system usage and information satisfaction. Communications of the ACM, 29(3), pp.232-238.

Chanda, J., Kanjilal, A., Sengupta, S. and Bhattacharya, S., 2009, December. Traceability of requirements and consistency verification of UML use case, activity and Class diagram: A Formal approach. In Methods and Models in Computer Science, 2009. ICM2CS 2009. Proceeding of International Conference on (pp. 1-4). IEEE.

Ives, B. and Olson, M.H., 1984. User involvement and MIS success: A review of research. Management Science, 30(5), pp.586-603.

Kaulio, M.A., 1998. Customer, consumer and user involvement in product development: A framework and a review of selected methods. Total Quality Management, 9(1), pp.141-149.

Clark, W., 1952. The Gantt Chart (Vol. 2). London.

Bahli, B. and Zeid, E.A., 2005, December. The role of knowledge creation in adopting extreme programming model: an empirical study. In Information and Communications Technology, 2005. Enabling Technologies for the New Knowledge Society: ITI 3rd International Conference on (pp. 75-87). IEEE.

Hofmann, H.F. and Lehner, F., 2001. Requirements engineering as a success factor in software projects. IEEE software, (4), pp.58-66.

Young, R.R., 2002. Recommended requirements gathering practices. CROSSTALK The Journal of Defense Software Engineering, 15(4), pp.9-12.

Thayer, R.H. and Dorfman, M., 1995. System and software requirements engineering. IEEE Computer Society Press

Rainardi, V., 2008. Functional and nonfunctional requirements. Building a Data Warehouse: With Examples in SQL Server, pp.61-70.

Balaji, S. and Murugaiyan, M.S., 2012. Waterfall vs. V-Model vs. Agile: A comparative study on SDLC. International Journal of Information Technology and Business Management, 2(1), pp.26-30.

Kinny, D., Georgeff, M. and Rao, A., 1996, January. A methodology and modelling technique for systems of BDI agents. In European Workshop on Modelling Autonomous Agents in a Multi-Agent World (pp. 56-71). Springer, Berlin, Heidelberg.

D'souza, D.F. and Wills, A.C., 1998. Objects, components, and frameworks with UML: the catalysis approach (Vol. 1). Reading: Addison-Wesley.

Osorio, J.A., Chaudron, M.R. and Heijstek, W., 2011, August. Moving from waterfall to iterative development: An empirical evaluation of advantages, disadvantages and risks of RUP. In Software Engineering and Advanced Applications (SEAA), 2011 37th EUROMICRO Conference on (pp. 453-460). IEEE.

Pohl, K., Böckle, G. and van Der Linden, F.J., 2005. Software product line engineering: foundations, principles and techniques. Springer Science & Business Media.

Bahli, B. and Zeid, E.A., 2005, December. The role of knowledge creation in adopting extreme programming model: an empirical study. In Information and Communications Technology, 2005. Enabling Technologies for the New Knowledge Society: ITI 3rd International Conference on (pp. 75-87). IEEE.

Basil, V.R. and Turner, A.J., 1975. Iterative enhancement: A practical technique for software development. IEEE Transactions on Software Engineering, (4), pp.390-396.

Beck, K. and Gamma, E., 2000. Extreme programming explained: embrace change. Addison-wesley professional.

Cockburn, A., 2002. Agile software development (Vol. 177). Boston: Addison-Wesley.

Schwaber, K. and Beedle, M., 2002. Agile software development with Scrum (Vol. 1). Upper Saddle River: Prentice Hall.

Barkley, B.T., 2004. Project Risk Management (Project Management) (Vol. 1). McGraw-Hill Professional.

Clark, W., 1952. The Gantt Chart (Vol. 2). London.

Karolak, D.W. and Karolak, N., 1995. Software engineering risk management: A just-in-time approach. IEEE Computer Society Press.

Raftery, J., 2003. Risk analysis in project management. Routledge

QArea, 2011. possible risks in software projects. [Online]
Available at: https://qarea.com/blog/possible-risks-in-software-projects
[Accessed 12/5/2011].