Inventory Systems Using Relational Database Systems

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.


This project aims to build an inventory system using ASP. Net. The purpose here is to build a system which can be accessed from any platform and information can be retrieved and updated in an easy and user friendly manner without any hitches. Obviously, the best example of a platform independent medium is the web. Hence, the inventory system is web based and allows the end user to update it or retrieve the necessary information from the database. Such a system is essential in the current environment. Users no longer want to work just from an office cubicle. They want to work on the move and this means mobile computing. Mobile computing brings with it a whole new set of problems which the current architecture of most organisations find hard to address due to the way their systems are configured.

Obviously, a change is required and it needs to happen at the very core of the organisation. While the front-end should be intuitive and provide ease of use, the back end is equally important in such a scenario. This is precisely why we have chosen to use a relational database management system for our project. Such a system provides you with the flexibility and the functionality needed to support the powerful interface of asp. Moreover, this type of system ensures that the platform doesn't play as big a role as before in determining the speed at which the transactions are processed by the database.

Coming back to the user interface, the project attempts to provide a GUI that is simplistic without compromising on the amount of data that is needed by the user. We ultimately aim to fine tune in such a manner that any user can make use of the interface without the need for a user manual. At the same time, the web site doesn't compromise on the security aspect as all the data that are sent and received to and from the user are suitably encrypted/decrypted and stored/retrieved from the database on an as-is basis.

Ultimately, this project aims to bridge the gap that currently exists between Windows and other operating systems with regard to inventory systems. One of its main objectives is to provide support to all mediums and gadgets by using the web as a common platform. It tries to really provide business on the move by extending the definition of e-business from just a web based transaction to a platform-free transaction. We hope to kick start a trend to provide business facilities to just about anyone with a gadget and an internet connection.

Chapter 1: Introduction

1.1 Overview

The issue that arises for the organisation in question is its reliance on a Windows centric platform that makes communication between other platforms impossible or at best difficult. In this day and age of advanced, wireless telecommunication systems, multi-functional, dimensional cross platform systems are required as a part of the organisational infrastructure especially with regard to information management. With respect to data management and inventory, this becomes all the more important as the organisations moves from using one platform to many. An organisation with an active supply chain will need interactive and flexible data systems in place in order to pursue business relationships out in the field. Cross platforms move away from the Windows worlds into advanced cellular networks and handheld gadgets. All of these seek a system that can allow for seamless use by employees on any team within the supply chain. Not only does access to such tools make for a leaner, more productive chain, it also leads to building a learning environment where the exchange of information or data flourishes. This in a sense leads also to innovative design of information architectures and the creative flow continues impacting multiple areas of function. It allows an organisation to reach a new level of functionality not only on one level of processes but also on many. In a sense, this type of paradigm works well for an organisation with multiple locations and offices because depending upon how tasks are categorised. Should each team maintain a specific process within the chain, and then all these processes can maintain high levels of productivity independently of each other and as a whole. This is the science behind supply chain mechanics; however, it does take utilisation of e-tools to make such levels work. This vision is not without drawbacks or challenges for designers. As data moves from one location to the next, there is the issue of security and privacy with regard to the information being shared. It is important for organisations of such size and activity to consider the amount of risk involved with such information flow. While technology is there to make the processes run at the speed of light, one must consider what happens when the system is targeted or when it falls victim to outsiders. This naturally means the organisation prospers in its field of specialisation and helps it to maximise its client base since the platform is more user friendly than before and can accommodate more views in an easier and concise manner.

Moreover, cross platform systems help in bringing down the costs over the long run. Additionally, the overall output of the organisation increases by a significant margin within just a few months of change in most cases. A system that is transparent and provides clarity will no doubt be acknowledged by all the players within and outside the organisation, including its clients, partners, suppliers and the employees themselves. This augurs well for the future of any organisation since it is in tune with the demands and the changing constraints put forth by the industry. Such a change provides a good platform for the organisation to set path breaking trends and also achieve its short term as well as long term goals with relative ease.

1.2 Aim

The aim of our project is to build a system that can update the inventory records in the database and retrieve data from it as well. To achieve this we need to keep up to data with the latest standards in technology and adapt our system accordingly. Technology has evolved and so has the way inventory systems are nowadays built and updated. It is no longer limited a particular platform or even a particular type of system for that matter. This is the age of mobiles and the existing architecture no doubt needs to be changed to accommodate that aspect. In the case of an inventory or database management system, this becomes all the more important since important transactions are nowadays even held from your hand held devices such as a Blackberry or an Iphone. GPRS, and off late the 3G and 4G evolving technologies have enabled us to access the web from the mobile, and has made business transactions to adopt this new medium. Moreover, the speed of using mobile technologies is also advantageous and works in its favour. In any case, most database and other business transactions do not require more than an average internet connection with optimum bandwidth. Hence it is not just new platforms that we are looking into but newer technologies and systems as well. Our overall environment needs to be one that can take into consideration all of these above mentioned factors and provide the support necessary to conduct database transactions from such new platforms and devices as well as keep in mind the future and leave space to accommodate any newer technologies that we are no doubt going to see in the forthcoming decade.

1.3 Objectives

The primary objective of the system at hand is pretty obvious. We need to build a system that facilitates easy updation and retrieval of data from the relational database at hand. To be specific we will be updating an inventory system. At this point, the question that begs asking is about the importance of an inventory system and the role it plays in an organisation. An inventory system plays an integral role in any organisation and what is important to note here is the fact that there is a need to keep track of objects and materials at each and every level in the organisation and hence there are bound to be differences in platforms and type of systems that are used to update the inventory.

There are several other secondary objectives at hand as well. Among these is the need to provide an interface which facilitates the client for easy updation of the values into the database. The interface must be simple and user friendly. It should not compromise at the same time on its security aspect. It should be secure and not vulnerable to attacks of any sort. This is an important secondary objective and goes a long way in ensuring the success of our project.



The need for such multi-platform systems remains inherent with organisational needs.  Eng (2004, p. 99) writes, "These capabilities seem to change traditional supply chain management processes by lowering costs and increasing speed to respond to supply and demand needs."  What does this mean for inventory and database management? There may be links in the chain that do not use Windows and this suggests an issue for supply harmony.  Many experts contend a common medium or multi-platform is needed as so much commerce is tied to telecommunications and global presence.  Many organisations turn to the Web as a means of channelling processes between departments and suppliers.  This still remains a weakness as the SCN remains captured in EDI.  Many believe that by creating an open network leans towards risky behaviour but also suggests a common thread for electronic infrastructure design. Moreover an open network leads to clarity and transparency in the system and leaves little scope for misunderstandings of any sort, which is a good thing. Moreover such a network can help in knowledge sharing to a very great extent and promote the growth of the organisation when looked at with a long term view. This doesn't mean that the risk factor should be ignored. Safety is always an issue and should take top priority in any organisation that wants to retain its existing clients and garner new ones. Safety is the first thing that a potential client will look at, so this should not be compromised at any stage. But at the same time, we should not attach over importance to safety and end up compromising on the user interface. This is to be noted and taken care of because of the fact that many of the existing systems end up sprucing up the security aspect of the project and have a very dull and monotonous frontend that requires lot of time and patience to understand and operate by the client. So this must be taken care of.

Most systems are based upon enterprise resources planning or ERP within the platform, in this case Windows.  What happens when other platforms do not mesh with the existing one?  In this day of Blackberry and other hand held devices, it seems multi-platform systems are needed for productivity and seamless communication. Moreover, making such of such a platform makes sure that all the players are accommodated by the system without any hassles that a windows centric platform may lead to. Yen et al. (2002, p. 339) surmises of older architecture as "Implemented via a core database of the system. The database interacts with all the applications in the system" creating a sense of data efficiency.  There are many points of view on how to design such a database for inventory and SCM tracking.  One approach is that each area remains independent still linked as a means of managing information but this encourages an organisation to hide details from each other.  This does not emulate knowledge sharing system.   This takes a task or product oriented view and this may explain why previous systems remain strong on one platform. This takes a task or product oriented view and this may explain why previous systems remain strong on one platform. Moreover, by making it remain on one platform, they actually end up minimizing the no. of risks that are possible in such a scenario. Obviously, following such a methodology is not advisable in this scenario. Hence it is all the more essential that we switch to a multi platform basis as soon as possible.

ERP systems also have obstacles. Yen et al. (2002, p. 341) present the contrasting view, "ERP has the following disadvantages: its high cost prevents small businesses from setting up an ERP system, the privacy concern within an ERP system and lack of trained people may affect ERP's efficiency, implementation of an ERP project is painful, and customization is costly and time-consuming." The thought here is that the information remains organisational property by making impossible to share along outside links of the chain.  Halman et al. (2003, p. 150) write, "Platform thinking, the process of identifying and exploiting commonalities among a firm's offerings, target markets, and the processes for creating and delivering offerings, appears to be a successful strategy."  To further this view, however, it has been addressed that platform technology should be developed embracing change which would also mean adopting policies toward more than one platform interacting to create a multi-platform architecture.  The idea here is "An entirely new platform emerges only when its basic architecture changes and aims at value cost leadership and new market application" (Halman et al., 2003, p. 152). The organisation needs to keep this in mind and make bold changes to the entire structure with an eye on the future. What may seem perfect and working now may become redundant tomorrow. Hence policies should be adopted that support a multi platform view and the system should be modified accordingly to suit the needs.

There is the device view of system architecture that puts the tool central at creating the management chain of multiple layers of activities.  This has been implemented as user needs change and more organisations find business in other regions. Specific to the issue of risk and security, the problem with multi-platforms does not necessarily have anything to do with outside invaders but inside behaviours but also increasingly different types of data movement. White (2004, p. 2) surmises, "This appears to be due to a few reasons, the increase in mobile computing, the use of social engineering techniques to spread, and an increasing number of high-level protocols. The first reason is due to a firewall's inability to block non-network traffic and effectively allows for internal devices such as laptops or removable media to travel outside the firewall, become infected and allow those infected files to piggy back their way through the firewall." This is obviously undesirable and can prove to be a disaster if not rectified immediately. Steps must be taken to ensure that the security of the system as a whole is not compromised at any point in time. To do this, the best way is to be preventive in approach. I.e it is better to make sure that the virus never enters the system rather than allowing it to prosper and then detect and kill it. There is no telling how much of sensitive information can be stolen in the precious time taken by the security radars to detect the virus or malware and kill it.

2.2 Web and business - The current trend

The Web provides customers and businesses with ubiquitous interactive access to text, sound, image, and video data. Millions of Internet users are potential consumers of online products and services. Moreover, most of them are already familiar with this medium of communication and interaction since nowadays the web has become a part and parcel of our daily life. Hence, most of the players involved will be quite receptive to the idea of web based business or e-business as it is called. The web provides a great means to interact with potential clients, partners and suppliers and dealers and the best part of it is that it is along the same medium. Obviously in such a scenario the platform doesn't play as major a role as before. Additionally, the advantages here are aplenty as the web offers a medium that can truly be called as platform independent. Connectivity to the web is something that is inherent in any platform, be it windows or Linux or any other platform. As summed by Medjahed et al. (2003, pp 59) "Numerous organizations started using the Web as a means to automate relationships with their business partners. This has elicited the formation of alliances in which businesses joined their applications, databases, and systems to share costs, skills and resources in offering value-added services". There are great incentives for companies of all sizes, ranging from multi-national corporations to small mom-and-pop operations, to automate interactions with their business partners, including suppliers and manufacturers[business-to-business (B2B) e-commerce] as well as their customers [business-to-customer (B2C) e-commerce] (Su et al., 2001, p. 72). The internet is a great medium to globalize a company and make it an important player in the global market. However the main concern with having e-commerce is the security aspect. As we explained earlier, the chances of a virus attack are quite large and since it is a large network the chances of it spreading through the network is also possible. The situation can get worse if it is a Trojan attack that attempts to steal sensitive information from the nodes in the network. Such a scenario can spell doom for any organization if sensitive information about the organization can be obtained by their rivals easily. Security concerns need to take top priority here to make sure that the integrity of the organization as well as the clients linked to it are protected from hackers.

Another drawback of using the internet as a business medium is that not only will you have to spend a lot on adding top notch security to your network but you will also have to convince the other nodes along the network that it is safe to use. These nodes include your partners, clients and suppliers. Obviously, to conduct business smoothly on the web, you will need the cooperation of all those concerned and there is also the issue of not everyone being web savvy enough to conduct business. A survey has shown that over 70% of clients are wary of their credit cards and other such private information being misused on the internet (Udo, 2001). You obviously need to convince everyone along the supply and demand chain that the medium is safe to use. This is easier said than done and the only way to ensure that the clients are satisfied is to spend what is needed on improving the security and infrastructure of the system to really make it world class. Unfortunately though, there is no foolproof security system that can be installed. The security concerns are changing by the day and the organization will have to ensure that it keeps itself updated and informed about the various security concerns that keep coming up and take whatever measures are needed to neutralize them.

Other than the internet, another trend that is fast catching on is that of going mobile. "The evolution of mobile technology has significant benefit toe-business applications in providing extended competitive advantage" (Atkins et al., 2006, pp.2). Mobile e-commerce is a trend that has a very futuristic outlook to it. However the issues that plague e-commerce on the web are applicable here too. Security is quite vulnerable when it comes to going mobile and once again the fears of the clients and the partners need to be alleviated. The major problem is that the security needs to be enhanced from the side of the handset too. The problems of such devices are aptly summed up by Ghosh et al (2001,pp 53) as "Without physical perimeter security provided by buildings, locks and guards, mobile computing devices are at increased risk of theft and loss, particularly given their small size. While the data stored on a misplaced device might be irreplaceable or proprietary, other risks of lost Internet-enabled devices include the ability for finders of lost devices to access proprietary corporate systems, including email servers and file systems." Such devices are more prone to get stolen as they are handheld and carried everywhere by their owners. The chances of it getting lost or even worse stolen are quite high and once such devices are compromised getting the data stored in it and the data to which it has access is not a tough task at all for professionals. This though is a problem that one will have to contend with. It is a price to pay for the other advantages that Mobile Computing offers to the client

In the forthcoming chapters, we will see how the issues addressed in the overview and their corresponding solutions can be well represented by using PHP as the frontend and a Mysql database as the backend for our project. Most of the issues raised here are quite easily solved by using a relational database such as Mysql for the project. We will now see how.

2.3 Advantages of OOP in PHP & MYSQL

Object oriented programming plays a major role in most languages and PHP / Mysql are no exception to this fact. PHP is fast becoming the language of choice when it comes to the internet world along with ASP. PHP provides us with many reasons to choose it to be the frontend of our project, some of them are very compelling indeed. PHP gives us a great deal of flexibility and power to develop our application. At the same time, a properly configured PHP page will withstand most hacking attacks on it. Hence it is very safe and secure as well. This combination of safety and comfort level offered by PHP make it a good choice for our project.

So far, we have seen an overview of PHP and the reasons why it is perfect to be used as the frontend interface for our project. Let us now see why complementing it with a Mysql backend is the perfect way to make this project a success. "PHP is only interesting when it runs on a computer configured as a web server. One way or another, you need access to a computer with at least three components on it: The PHP interpreter, a web server (such as Apache or Microsoft IIS), and some sort of database management system (usually MySQL)." (Harris, 2009) Like PHP, Mysql too has been around for some time.  It was developed initially by Sun Microsystems and later on by the Oracle Corporation (which took over Sun Microsystems) and the initial release was done on May 23rd 1995, more or less around the same time that the world came to know of the existence of PHP. Very soon after its initial release Mysql has gained a steady following in most organizations. It is widely regarded as one among the best database engines in the business mainly because of the raw power it provides which can be suitably harnessed by any decent frontend. LAMP (Linux, Apache, Mysql, PHP) deployment has created a buzz in the industry mainly because of the way in which the intuitiveness and flexibility with which PHP merges and harnesses the power offered by a Mysql database.

2.4 Growing popularity of Mysql

Mysql has always received a good welcome with developers and organizations alike. "For a long time Mysql was a polarizing piece of software in the applications development community. It had (and still has) aspects that many developers loved: It's free (at least, when used in applications that conform to the GNU Public License), it doesn't take up a whole lot of resources, it's very quick, and it's easy to learn compared to packages like Oracle and Sybase." (Bulger et al, 2004)

Mysql also has the capability to withstand load and handle simultaneous transactions. This is succinctly put by Bulger et al (2004) as "It's also important to remember that MySQL and other relational databases are multi-threaded, which means that they can process directives from multiple clients simultaneously." This is what is required in today's world of the internet where we could have n- number of tie-ins at the same time to the database. The database has to respond to all of them without losing any time or causing any inconvenience to any of the users. This naturally means that we need a database that can handle the heavy load that comes along with the internet. This is especially true in situations that cause an outbreak of complaints on the system in hand which would require a database that can perform out of the box and respond to all the queries without slowing down. Mysql satisfies all of these requirements perfectly and will no doubt perform just as well in our system even under peak load as long as it is configured properly. To take off some of the strain from the database, we will be making some optimization from the frontend side of things as well so as to ensure that the database isn't unduly peppered with queries from the system.

2.5 PHP & Mysql - A popular combo

"PHP and MySQL have been developed with each other in mind, so they are easy to use together. The programming interfaces between them are logically paired up. Working together wasn't an afterthought when the developers created the PHP and MySQL interfaces" (Davis and Phillips, 2006). The combo of PHP and mysql has been tried and tested already by many organizations world over and has been deemed to be a success. It is hence no surprise that we have chosen this combo to make our project a successful one.  Other than this, both are open source. Hence the code is visible to the developer and he can modify the language in the way he wants. Hence the power totally rests with the developer and he/she will not be restricted by the constraints in place by the languages. Moreover both of them have active communities on the web and hence support is easy to obtain on either of these languages. Their simple and efficient design makes them very quick to use and the developer also needn't be bothered by too many complex levels of code when using either of these languages.

The fact that they are open source plays a major role in selecting them. "Both PHP and MySQL are open source projects, so you don't need to worry about buying user licenses for every computer in your office or home. When using open source projects and technologies, programmers have access to the source code. This enables individual or group analysis to identify potentially problematic code, test, debug, and offer changes as well as additions to that code" (Davis and Phillips, 2006). Open source has dramatically changed the way the world looks at things. The source code is open for development and yet at the same time programming languages such as PHP make sure that the end user does not exploit the very nature of open source and turn it into vulnerability. Such a killer combination makes open-source very potent and it is no surprise that more than 80% of organization world over have their servers running on open source technologies. As mentioned earlier Mysql and PHP too come under these categories and hence they too can be easily developed since the code is open for developers to check and modify as per their wishes and the needs of the system in hand.

Mysql is a relational database system. This too works in its favor. This is because, a relational database has the power and the facility to populate the database by taking the various attributes from different platforms if needed and combining them (Yoder et al, p 17). A relational database works based on the common relations between two tables. These relations are also stored in the form of tables. Moreover a relational database is well equipped to handle most sort of queries on the database and facilitate the transfer and update of information in an easy to use and safe manner without compromising on speed. Hence it is a very good option to make use of such a database for your inventory system especially in an environment where the inventory might need updating or retrieval from just about any possible platform. In such a scenario, a relational database is best equipped to handle it smoothly. Also, relational databases have a lot to offer in terms of safety and current vulnerabilities are few and far between and can be patched easily. Hence it offers a lot in terms of user-friendliness and safety while at the same time not eating up on the system resources as some types of databases tend to do.

2.6 How does PHP fit into Object Oriented Paradigm

Object oriented programming forms the base of many programming languages. PHP is no exception to this fact. Manipulation of objects and other elements adds a whole new level of flexibility to programming. PHP can thus be said to fit well into an object oriented nature of programming.

The syntax of PHP is quite similar to C and Perl. Hence it is quite simple to use and understand. An oft used phrase when talking of PHP is that its beauty lies in its simplicity. Anyone can learn and understand PHP with just a basic knowledge of C/Perl/Java. Hence it is quite easy to code and obviously even easier to debug if the need arises. The fact that it is open-source and free to use just adds to the ever growing list of advantages offered by this programming language.

Safety isn't the only thing that PHP has going for it, PHP is an object oriented language with as much powerfulness and flexibility as any other.  Originally created by Rasmus Lerdorf in 1995 it has been in development ever since. Being widely influenced by C, C++, and Java among many others, PHP has incorporated the best from all of these languages. As Wright (2004) shrewdly observes "There are many reasons to use PHP. One reason is that it is a server-side scripting language and therefore the clients do not need to install any plug-ins or reconfigure their web browsers. This also allows for security of PHP code. The client/server relationship is maintained and the client only sees what the server chooses to allow the client to see."

2.7 Basic PHP Constructs for OOP

Making sure that your basic constructs for PHP are in order is very important. On many occasions, it is quite possible that the bug in the code is present right here. Most of us will overlook this part and instead look elsewhere for the error. Hence, making sure during the design stage that the basic PHP constructs for Object Oriented Programming are properly defined is very important.

PHP provides us with the security that such a web based system would require to protect it from hackers and other harmful elements that are the scourge of the internet. Hackers have been a part and parcel of the internet ever since it was invented. Specific to the issue of risk and security, the problem with the internet does not necessarily have anything to do with outside invaders but inside behaviours and also increasingly different types of data movement. White (2004, p. 2) surmises, "This appears to be due to a few reasons, the increase in mobile computing, the use of social engineering techniques to spread, and an increasing number of high-level protocols. The first reason is due to a firewall's inability to block non-network traffic and effectively allows for internal devices such as laptops or removable media to travel outside the firewall, become infected and allow those infected files to piggy back their way through the firewall." It is precisely for such reasons that we have chosen PHP to code the frontend of our system.  PHP, as mentioned earlier does not show the input code to the end-user. Instead html code is usually generated on the fly and only this is visible to the user and not the internal workings of the system as is the case with other basic native languages of the web. This works in favour of PHP as it has several other advantages which we will be elucidating upon in the coming chapters.

Chapter 3:Analysis

The project makes use of a relational database system as its backend. As discussed in the literature review, the backend is one that suits the latest trend of a cross platform genre that is nowadays being increasingly adopted by an ever changing world that is still highly receptive to change. The backend, even in its raw state ensures that the frontend of the project is well supplemented by a backend that, if used properly can be harnessed effectively. It is also pertinent to note that the backend is one that has been used successively before in many other projects of the same nature as well. Configuring it properly has proven to be the key to succeeding with such a database. For the purposes of configuration we have taken into account the type of frontend we are having, namely the web based frontend scenario and have accordingly done the changes to the backend. Mostly the changes include modifications that make the server able to withstand the pressure that such a database might experience during peak load hours. Naturally, this is very important since we do not want the database to crash under any circumstances.

To complement the backend, we have a powerful web interface as the frontend. For this purpose, we have made use of PHP as the programming language. The reasons for this have already been explained quite extensively in the literature review given above. In keeping with the latest world standards, such a frontend is no doubt going to prove to be an asset in determining how well the overall project will perform on a large scale basis. The platform of the web is no doubt the way to go in the current mobile world where on the move handheld devices are sweeping everyone off their feet with the latest 3G and 4G technologies. Such a platform is no doubt welcome as a frontend interface. Also, keeping in line with the trend followed by the other world leaders in this aspect, the frontend must be lightweight and support all types of internet connections. Ultimately, it should even be able to perform the basic operations and objectives that are intended with even a dial up connection if needed. This will ensure that it can then perform very well with a high speed internet connection for which it is primarily designed. Also, when viewed using a handheld device, a low bandwidth version of the frontend must be supplied to the device so as to ensure that the page load time is not significantly affected by this. This is what is needed to complement the backend and what we aim to provide to make this project a resounding success.

As regards to the facilities used for this project, there isn't much to state on this aspect. All that is needed is a computer terminal with the required authentication to connect to the server and it is good to go. This is a feature that is unique to our project in the fact that it makes use of very less extra facilities and hence not that much dependant on external factors as many other projects are likely to be. This is the strength of this project. Due to this factor, the no. of risks with respect to the facility are comparatively less when compared to others. Hence we can focus more on the interface itself and what needs to be improved there in order to neutralize the setbacks offered.

Nevertheless, the facilities offered must provide a standard terminal that has internet access with a basic web browser and standard system requirements. No additional tools or software's are needed to run this project. This is an advantage that is faced when the entire frontend is web based, as is the case here.

Hence, to sum it up our project makes use of very few resources including a relational database backend, a web based frontend and some standard computing facilities to connect to the frontend. Additionally, an interface to act as a medium between the frontend and the backend may also be used for facilitating any value add-ons that may be offered by the project frontend in later stages once the primary objectives are satisfied and approved of by the project supervisor.

3.1 Risks involved

In total this project had 12 risks from the beginning and no new risks have emerged hence added so far. A summary of these risks and their current status is as follows:

Risk No                                                                           Current Status                 Last reviewed

                                                                              Probability      Impact 

1   I Lose  client commitment/support to the project                              low          high              22-Oct-2009

2   The client business closes during the course of the project undertaking       low          high              22-Oct-2009

3   I am not able to find enough material directly linked to intended research    low          low               22-Oct-2009    

4   I cannot get enough resources to support the project i.e. finance             low          medium            22-Oct-2009 

5   I am not able to find enough people to help distribute questionnaires         low          low               09-Oct-2009 

6   The questionnaires do not reach respondents in time                           high         high              22-Oct-2009 

7   Respondents do not respond in time planned delaying the project               high         high              22-Oct-2009 

8   Respondents do not get motivated to complete questionnaire                    high         high              22-Oct-2009 

9   Questionnaires do not reach respondents at all                                low          low               22-Oct-2009 

10  My dental appointments affect project progress                                low          medium            22-Oct-2009 

11  I am unable to complete project in time due to poor time management           low          high              22-Oct-2009 

12  I am unable to complete project in time due to uncontrollable circumstances   low          high              22-Oct-2009 

13  Getting response/feedback later than expected from client                     low          medium            22-Oct-2009


This section will discuss only flagged or highly probable risks as of current date. A full specification of each risk is attached as part of the review submission. Due to the delays on questionnaire turnaround time, the risks currently on the outlook are the flagged ones 6, 7 and 8.

Risk 6 has also been affected because it appears that certain participants that should receive the questionnaire have not been reached. As part of mitigating the risk, I have been calling each distributer which is how I got the feedback. However, as the risk was about to happen, I took the stated contingency measure and increased the duration of the return date to 02-October 2009. However, this contingency decision had an effect on some project elements as discussed in the progress section. I still have an option of engaging extra distributers if the need arises as part of contingency planning. However this decision may be effected in week beginning 26 October after making other follow up calls.

Also because of this decision, Risk 7 also came into effect. As part of risk 7 mitigation, I have been calling each distributer to follow up progress and advice on the best means to distribute the questionnaire to avoid biased data collection for the project.  

Because of the responses lower than the expected target in some areas, risk 8 was promoted and flagged. Getting the appropriate response to such questionnaires from the clients is quite essential and to this regard, care has been taken to ensure that the questionnaire is not boring to the end user who in this case is the client. As part of this risk mitigation I ensured that I read books on questionnaire construction and contacted the supervisor for general guidelines. Furthermore pilot runs were made to simulate the turnaround process. All these mitigations were successful based on feedback from pilot participants who were my flat mates and friends (8 people).

It is usually tedious to think about updating the Gantt chart and schedules every day but it makes things easier to manage and keep track of.  Having a copy which can be updated by hand on the wall has proved useful over time. The reality of project tasks comes to play as the project is running. Hence it is helpful to have a copy of a Gantt chart that can be updated by hand in an easy manner.

The project sponsor has been helpful in plotting the course of this project and determining the direction in which it should be headed. The suggestions given by the sponsor were well received and generally implemented wherever possible. Additionally, some ideas too came out from these suggestions and those too were considered for further implementation in the project. Most of those ideas are quite useful as value additions to the frontend we have used. A comprehensive list of the suggestions made and the consequent corrections in the project design are mentioned in the following paragraphs.

It was noted that the reference to the supervisor section was missing and had to be filled in. This was duly corrected in the subsequent submissions. It was suggested that it would be ideal to increase the number of planned hours from 560 to 600 plus or minus 5%. The rational for this suggestion was based on the belief that judging from the explanation of the project scale, it would be ideal to cater for other unforeseen circumstances. In any case, any project which has some hours left over for emergencies is always good as it shows that the project has been planned out methodically for any such circumstances and can handle the situation accordingly. This will naturally enhance the reputation of the project.

Risk number three (3): 'I am not able to find enough material directly linked to intended research' was identified as less of a risk because the library had means to acquire any form of material I wanted. It was suggested that I either demote the risk to the lowest impact and probability or consider removing it.

Objective:  6 (Produce a complete project dissertation) had to be refined further to indicate the details of a complete dissertation so it can be measurable.

3.2 Changes made based upon the risks

I have changed the writing of first part of dissertation task from 18 to 40 hours adding an extra 22 hours to the plan. I have also added another 26 hours the writing the second part of the dissertation task, from 14 to 40.  The updates raise the number of planned hours to 623.

I realized that to this point on 19 October 2009, I have already spent 43 hours on the first part of dissertation task which was over by 25 hours. The same applied to the second part of the dissertation task which was at 36 hours and over by 22 hours. I decided to do work on the second part of writing because the questionnaire turnaround time was getting longer than expected. Hence as part of risk assessment as shown in Risk (7 'Respondents do not respond in time planned delaying the project) I had to take necessary contingencies. Although it was an expectation that some task would end up not going as planned despite my intentions to keep good project management practices, these task signalled a need to re-look at.

I had an option to break the 40 hours allocated into each chapter writing tasks i.e. 15 for introduction, 20 for literature review and so on. However I felt that it would make a long number of tasks resulting in a very long plan and schedule template since I would have to do the same for the second writing tasks as well. Hence, in order to keep the templates comprehensive and less cumbersome I made used an estimated total of 40 hours for each task.

I decided to re-assess the risk 3 and demote it instead. Enough material is available in the library. Additionally, the internet provides us with a means to search for answers to almost any question or further queries in this regard. Hence the risk is quite low and deserves to get demoted down the list. This has so far proven to be a correct move since I have not faced any problems with regard to this particular risk in my project.

The material I have seems adequate, however if feedback from draft discussions or second review indicates that more references are required then I would have to search for more material. If there are any that require contacting the staff library, then I will have to take the recommended approach. Otherwise if all reference material is regarded as adequate or suitable, then I will have to remove the risk completely. Once again, that too would not be such a bad option since this risk, as I have talked about already is appearing more and more like a low priority one in the face of all the information that I have access to.

The suggested explanation has been included to extend the current section of quantitative measurement for the objective. The reason was to ensure that the objective is measurable at the end of the project.

Adding the omitted communication section has made no major impact to the project. However, as part of project management it has proved to be useful because my record of communication with supervisor now has a link to the TOR. This sets a reminder to alternatives that are available to contact the supervisor depending on the situation. For instance, I know based on the TOR that the only appropriate way to get in touch of the supervisor for urgent matters is through telephone. As indicated in the schedules deliverable, this makes a complete TOR that was supposed to be delivered.

Changing the plan has made my plan much realistic than before. Changing the hours also has eased the pressure of trying to complete tasks within a short time unnecessarily which could affect the quality of my deliverables. It was a good lesson for proper planning judging by the way my actual plan hours were going over the planned which would have otherwise implied bad project management practices. However, the idea of breaking the 40 hours tasks would mean major rework on both the project plan and the schedules compared to how I currently did it, which I would still be prepared to do if the supervisor insists. This however is a small price to pay for such a scenario especially when we consider the gains that such a rework will give me.

Demoting the risk has not made any effect so far because I have not had a situation where I needed a particular journal that was not made available through current sources nor do I expect such a scenario to persist anytime in the near future. Hence demoting the risk was the correct thing to do in hindsight as well.

Changing the objective has proved useful in that as it has made the objective easier for me to judge for completeness. This will help me cross check this objective against each thesis section for validation until the end of the project when successful achievement can be fully measured.

Chapter 4: Design

The project deliverables include the desired frontend for the product. The frontend is used to communicate with the client and get the required information from him/her. Obviously, the interface needs to be one that is user friendly and provides the client with the options needed for the application to function smoothly. At the same time, the interface should not be cluttered with too many options that can confuse the client.

Another point to remember in this context is that the primary objectives of the project are satisfied by the frontend when the design is being made. Only after the objectives are satisfied should any importance be given to the value add-ons in the project. Also, care must be taken while adding such value additions to the project deliverables so as to ensure that they do not cause any harmful side effects to the project which could potentially act as a barrier in not fulfilling the key objectives of the project.

4.1 Impact of identified risks on design

Most of the risks/ setbacks have already been discussed extensively in the earlier sections, so we will not be commenting much about them here. It is pertinent to note though that the deliverables should be designed in such a way that risks other than the usual ones are also taken care of if and when they arise. For this to happen, the deliverables should be built accordingly. This is even more important in the project environment where the external environment of the client can also play a role in determining the shape of the project and its possible side effects. Hence those risks too have to be taken into account when designing both the frontend and the backend for the project in question. This can be done by keeping some space for such external risks and handling them as and when they arise. The external risks too have been noted down already and backup plans for those too have been sorted out and are in place for if and when such a situation occurs.

4.2 Configuring the backend

What we have talked about so far deals only with one part of the deliverables for the project. Obviously what we are talking about here is the frontend. We are yet to delve into the backend of the project and the complexities that are in place here. The backend will play a major role as all the good work that is done by the frontend can be erased if the backend is unable to support / supplement it properly. Hence we need to design it properly instead of just having it in place without any modifications. What we need to remember here is that most such databases that we have in place don't do much by themselves. We need to modify them accordingly.

The backend, which is our relational database, should be designed to handle the intricacies of the frontend that we have here on offer. The queries sent forth by the frontend need to be handled in the best possible manner by the backend with minimal amount of fuss.  This is important especially in our current project scenario where the relational database backend plays a major role as a key objective in our project. The project is more or less built upon the strength of the backend. Hence the deliverables include properly configuring the backend to suit our needs.

By configuration, we mean to say making it less server intensive and making it perform with the same amount of precision and speed even under heavy server load. This obviously means that the project deliverable with regard to the backend has to be heavily modified or rather optimised in order to meet the requirements here. This will go a long way in ensuring that the relational database backend stays up even during peak hours and doesn't fail perform. Performance of the backend is a key objective for this project and this aspect needs to be met by the deliverables. In this regard, we have optimised the backend to a great extent to make sure that we have indeed made a masterstroke by making use of a relational database system as our backend.

Coming back to the frontend, the objectives to be met here are pretty simple. The client should be able to operate the system with the minimal amount of fuss or help from the documentation. In other words, the interface should explain itself without the need for any documentation. This means that the interface should be intuitive with each and every control properly labelled and designed in such a way that the user doesn't have to do much.

Also, the information from the server should be displayed in a comprehensive manner from the user. This obviously means that our deliverable has to process the raw data obtained from the server and display it in such a manner that the user finds it very easy to understand the data that is obtained from the server and is able to update it in such a manner.

Another important objective that one needs to take note of here is that the frontend interface should be one that can be used from any platform. Hence it should be mobile friendly as well. The interface should be able to recognize the type of platform from which it is being accessed and make sure that the page is displayed properly to the user regardless of the platform he is using. This obviously means for both retrieving as well as updating information to and from the server which in this case is the relational database backend.

The frontend interface should also support the key areas that are looked upon by the client when he uses it. Obviously, for any client the important need is to determine how well the interface behaves when transactions are performed on a large scale basis from all around the world and how well they are all synchronised with each other to prevent a deadlock type of situation. Obviously, in such a huge system the chances of a deadlock occurring are very much a real possibility. Hence the frontend deliverables should be able to handle the data flow in an organised manner and not fail under such a circumstance by conceding the data control to one client and letting go of the other. Both the clients need to be appraised of the situation in such a scenario. The deliverables are built / designed in such a manner so as to satisfy the key objective of any client.

Chapter 5: Evaluation and Testing

Proper evaluation of any work that has been done is very important. A fair evaluation of the project is needed to iron out any design errors or small mistakes that might be present in the project. These will obviously need to be fixed. Evaluation helps us to identify the strong points of the project and also helps us to assess the weaker areas that we need to concentrate upon. This is needed to ensure that when we do submit a final project review we will have all the details regarding what makes the project special and what are those unique value add-ons that really add to the specialty of the project.

In our case, we have properly evaluated the frontend and ironed out some bugs that might possibly occur later on when it is used on a large scale basis. Such bugs in the coding were detected at the evaluation phase and this no doubt bodes well for the project since the final phase of the project, i.e. the testing that needs to be performed on each and every module in it is yet to be done.

The next thing we need to move on to with respect to this project is the testing phase. The testing stage is very important in the lifecycle of just about any project. This involves looking at the project from the eyes of the end user and doing a critical analysis of what the needs of the user exactly are and how these needs can be satisfied. This means that we might need to add some new features or fine-tune the existing ones to make sure that they work perfectly when testing is performed on them.

Coming to the testing that was performed with respect to our project, we have done a comprehensive testing of all the modules contained in our frontend both individually and as a whole. We have followed most of the prescribed testing methodologies for such a project and done a top-down testing of all the modules. This has indeed helped us to modify some of the existing features so that it appears more user-friendly than before. This naturally means that the final project application will look more appealing when it is used by the client. Also, due testing has also been performed to detect the load that can be handled by the backend in the case of situations where the frontend might be bombarded with simultaneous users at the same time on a large scale.

Chapter6: Conclusion

Inventory systems are the backbone of any organization. However, the days have changed from the times when communication between the different branches of an organization was done by word of mouth. In this internet era, inventory systems are passed along the supply chain to all the players' world over. Naturally in such cases, complications are bound to arise. Newer platforms have emerged and people prefer using those for conducting businesses. Customer satisfaction is always essential to any organization. Hence it should be flexible in its thinking and also in its implementation. The needs of all the clients should be fulfilled while at the same time the overall security of the network within the organization should not be compromised.  To do all this, an overhaul of the organization's structure is highly essential to stray away from the monopoly created by Windows. More and more users are moving on from the windows centric environment in both their homes and offices. The latest trend has been to do business on the move with blackberry and other similar handheld devices.

Relational databases are the way to go in achieving such a change. Not only are they safe to use, but they also provide the flexibility needed to support a multi platform environment. Also a frontend that understands how the backend is configured and harnesses the information from the backend accordingly will also go a long way in this regard. Also the interface will provide support to all types of users on all platforms. This in itself is a revolution, especially so because of the fact that a mobile interface that can handle transactions are very rare and needs a lot of coding to make it perfect.

Naturally, any organization that has the flexibility to do business on most of the desired platforms can be said to be on the right track with an eye on the future. The growth of such an organization is no doubt secure even 10yrs down the lane with such an outlook


Eng, TY. (2004). 'The role of e-marketplaces in supply chain management', Industry Marketing Management, vol. 33, pp. 97-105.

Halman, JIM et al. (2003). 'Platform-Driven Development of Product Families: Linking Theory With Practice', Product Innovation Management, vol. 20, pp. 149-162.

B Wright, 'PHP: Hypertext Preprocessor', 2004

Harris, 'PHP 6 Mysql programming for the absolute beginner', 2009, pp. 4

Bulger et al, 'MySQL® / PHP Database Applications', Second Edition, 2004, pp. 19

M Gardner, S Pinfield, 'Database-backed library web sites: a case study of the use of PHP and MySQL', 2004, University of Nottingham

Li, Y et al. (2008). 'Multi-model driven collaborative development platform for service-oriented e-business systems', International Journal of Advanced Engineering Informatics, vol. 22, no. 3, pp. 328-339.

White, D. (2004). 'A Unified Architecture For Automatic Updates', Rhodes University, Grahamstown.

Yen, et al. (2002). 'A synergic analysis for web-based enterprise resources planning systems', Computer Standards and Interface, vol. 24, pp. 337-346.

Medjahed et al. (2003) 'Business-to-business interactions: issues and enabling technologies', vol.12, pp. 59-63

Su, et al. (2001) 'An Internet-based negotiation server for e-commerce', 2001, pp. 72-75

E. Davis, A.Phillips 'Learning PHP and Mysql', 2006, 2nd edition, O'Reilly publishers, pp.3

Udo, GJ (2001). 'Privacy and security concerns as major barriers for e-commerce: a survey study', 2001, pp 165-169

Atkins, et al. (2006) 'Extending E-Business Applications Using Mobile Technology', 2006, pp 2-4

Ghosh et al (2001) 'Software security and privacy risks in mobile e-commerce', 2001, pp. 51-56

Yoder et al 'Connecting Business Objects to Relational Databases ', pp 17-20