SPM Project Report
SPM Project Report
SPM Project Report
Introduction ..3 Project Overview 3 Background .4 Objectives of Project 5 Constraints 5 Methods/Technologies used 6 Project Deliverables 6 Product breakdown diagram10 Activities 11 Activity Flow Diagram (PERT) 12 1
1.
INTRODUCTION
In recent years the use of the Internet has changed the way our world functions. From social interaction to a new focus and availability of wider education, it has created a new way of life. But one of the greatest effects of the World Wide Web has been the integration of business, as with the many companies that now provide their products for purchase online. The process is called ecommerce, and it has been proven that the development of an ecommerce web site is the perfect way to increase retail sales. This is especially beneficial for those who commonly find themselves with a product overstock, or a need to quickly move unsold merchandise and close-out products, which would otherwise result in a profit loss. The next major benefit of developing an ecommerce web site is increasing the sales to supplement those that are already generated by the business. This Document gives details about a software project development plan to develop an e-commerce website for a brick and mortar retail stores. The Retail store chain is a medium sized retail chain company ABC retails Ltd. currently involved in Brick and Mortar retails operations. However, increasing the reach through internet and other issues such as inventory turnover made them to implement an e-commerce website which would assist its current business model both in terms of sales and managing inventory. The retail chain is based in Ahmedabad and has its 5 stores in Ahmadabad Region.
1.2 Background
Client: ABC Retails Ltd. Current business: Five retail stores in Ahmedabad. The retail stores are supermarkets which includes all the grocery items, collection of various apparels, footwear etc. Currently there is no online presence of the store and all the operations are carried out through physical stores. The company wants to enter into the online ecommerce business where users would shop online, make the payment online and their goods would be delivered to their homes. Home delivery is also available currently but this is done only when customers come to the stores, pay and ask it to be delivered to their homes in case the shopping cart size is large and they are unable to carry it to their homes. The company does not charge anything for home delivery currently. Current status of Online presence: Nil. Functionalities required: 1) Website with information of all the available products. 2) User Login and storing of users information by maintaining a DB. 3) Shopping cart. 4) Payment system. 5) Shipment and delivery details. 6) Connecting and coordinating website operations with current operations. Existing Software: Inventory management and billing system. The Company already processes the backhouse operations (Supply chain management) with their inventory management systems which take care of the purchase and inventory. The Billing system is specifically used for billing purposes at the Retail stores. The inventory management system is a centrally located server which is connected to terminals present at various retail chains. Also the individual billing data is updated on the real time basis to the central server located at the Head office IT.
Stakeholders in the project include all the upper management of the Retail chain stores, steering committee which is responsible for the project, all the other employees as the accuracy of the transactions will depend on the success of the project, shareholders who have stake in the retail chain, and the employees and customers of the stores who will using this site for their purchase activities.
1.4
Constraints
The project undertaken would have following constraints: 1. Website created would be available on World Wide Web but operations would be restricted (for operation) only to the users in Ahmedabad as Retail chain does not have presence outside Ahmedabad. 2. As this is a low scale project hence there are resource constraints both in terms of money and people. 3. There are external timelines demanded which are imposed by the ABC ltd. as they would want to go Live according to their business strategy. Thus once the website is on Live and that company has already advertised for its promotions and 5
declared the date. Not availability of the site on the expected date would certainly affect the reputation. Hence the project has an externally imposed timescales.
Service Level Agreement: A service level agreement ( SLA) is a part of a service contract where the level of service is formally defined. IT is a negotiated agreement between the IT provider and ABC Ltd. The SLA would record a common understanding about services, priorities, responsibilities, guarantees and warranties. Each area of service scope will have the 'level of service' defined. The SLA would specify the levels of availability, serviceability, performance, operation, or other attributes of the service. The Warranty time for code development, after sales services, Website downtime, delivery time etc. would be covered under this document. Violation of this document can lead to legal complications. Requirement Specification Document: This is very important phase at the start of the project. The business analyst and the technical analysts would have interactions with the client (ABC ltd.) to understand its basic requirements of the website. The business analysts would then analyze the functional requirements and then pass it on to the technical analysts for technological requirements. Once the analysis is completed they would prepare a requirement specification document which would include all the functionalities that the website should provide, GUI interface or front end interface, order journeys, content displayed and other facilities provided. It will also contain all the technical requirements that are needed to carry out this project in terms of hardware, technological requirements. This document is then approved by the client and once approved is then given to system designers to work on the design part. In case of waterfall model and depending on the SLAs mentioned, any changes to be done in the later stages of this document after the client signoff is received would involve complications in terms of budget and time as mentioned in SLAs. High Level and Low level Design Document: Once the requirements are finalized, the next product is the design document. It will involve design of various modules involved and the interconnections between them. There will be two types of design procedures carried out, high level design and detailed or low level design. High level design will outline various functionalities that will go into the package on a broader view. Since the software will be using a J2EE Weblogic platform, it will
outline the object classes required for the major functionalities. The functionalities would include: 1.Creation of Users Registration and login 2.Creation of the order journeys through jsps. 3.Creation of the products database and its display on the front end. 4.Connection of these jsps through content management tool. 5. Linking payment system by using the functionality of PayPal system. It will also mention the database connection and various database drivers to be used for connecting database with the application. Currently, a central server is been used for storing all the products in the inventory at various stores. Hence the application will be connected to this server. Detailed level design will explain all the functions in great detail. It will explain the actual flow of different java classes and its connection with the database and the front end (which will be done using jsp). It will mention all the calls and how will they be called. In case of jsp, it will explain which structure these jsps are using. It will also explain how the connection will be established with the database and how the calls will be made. Thus a complete technical design document would be created for carrying out the coding processes. Code: Once the Design documents are ready the next phase is the coding. The coding in this project would essentially be done on UNIX operating systems and would be in java (J2EE version). The various five modules described above would be developed by different set of developers. The output would be a code done in java languages in the form of Jsps which would adhere to the design documents prepared. Test cases: Once the code is developed it requires testing. Thus specifying the test cases is very important. These would include White box and Black box test cases. Black box test cases are generally for the end user or acceptance test cases which are generally done at the end of every module or completion of the website by users to
check the business functionalities being met. These would include test cases for ordering journeys for purchasing and payment. Black box test cases would include scenarios where the code is checked technically from inside. These cases are comprehensive and should check solidarity of the coding being done. These documents are fairly important in order to check the performance and limitations of the code as to how much load it can sustain and extreme cases. IT is important from both the developers (IT providers) and users aspects. Application builds: This is the combined package of the coded jsps, its interlinked connection tools which is to be deployed on application servers. This build package also includes the xml files to be deployed on the webservers. The Jsps would go to app. Servers and xml to webservers. This would also contain the content needed to be uploaded as a part of feed to the website. This content is a collection of product related jpgs, flash files, and other promotional related content files which are dynamic on the website.
User Manuals: This document would cover in detail about the various functionalities of the website (as per the requirements). This would contain exhaustive description step by step about the different functions and its working and uses that are incorporated in the website. By using this manual the users can easily come to know about the working of website through a users point of view. Module description Documents: These would contain the technical details of the different modules that are built for making the website. Since it would contain the internal working of these modules these would be confidential documents. This would also contain the working of webserver and its connection to the app servers and content servers and app server connection to database. A complete flow of the internal working would be covered in this document. Progress Report/Dashboard. This document would essentially help the management and the project steering committee to continuously monitor and view the progress of the project. It would indicate deviations if any and hence would help the project committee to take necessary actions if required.
Project Products
System Products
Module Products
Management Products
Design for Registr ation and Login Design docume Design nt for docume Order Design Design nt for Journey docume docume Products nt for nt and DBfor Content Payment Display mgmt. system
Code for Reg. & login Code for Order jrny. Jsp Code Code for for Payme Product Content nt s Mgmt. system
Test cases for reg. & Test plan and test Test cases plan Test Test Order and plan plan test and and cases test test for cases cases
10
1.7 Activities:
The following are the activities that are identified and would be carried out accordingly for this project.
Activity A B C Overall specification Technical Design & Architecture Low level Design for Registration & login module Low level Design for Order jrny. module Low level Design for Product DB & display module
Estimate d Days 20 17 5 I J K
Activity Coding/testing Order jrny. Module Coding/testing Product DB & display module Coding/testing content mgmt. module Coding/testing Payment system module System Integration
Estimate d Days 12 12 12
D E
5 5
L M
12 5
11
F G H
Low level Design for content mgmt. module Low level Design for Payment system module Coding/testing Registration & login module
5 5 12
N O P
Overall system testing Build and Deployment on LIVE servers Creating User manual
4 2 14
Below is the Activity network diagram shown for the project. The required days for activities are estimated keeping the contingency factor for each activity.
C 37 37 5
5
Design for Registratio n & login module
H 42 42 42 42 12
12
Code/test Registratio n & login
54 54
D 37 37 5
Design for order journey module
5 42 42 0 42 42
12
Code/test order journey
54 54 0
12
A 0 0 20
Overall
20 20 20 0
B 20 20 17
Technical Design & Architectu re
17 37 37 0
E 37 37 5
Design for Products DB & display
5 42 42 0 42 42
12
Code/test Products DB & display
Specificati on
54 54 0
12
F 37 37 5
Design for content mgmt. module
5 42 42 0
k 42 42 12
12
Code/test Content Manageme nt
54 54 0
12
G 37 37 5
Design for Payment system module
5 42 42 0
L 42 42 12
12
Code/test Payment system
54 54 0
M 54 54 5
5
System Integration
N 59 59 0 59 59 4
Overall system testing
4 63 63 0
O 63 63 2
2
Build & deploymen t on Live Servers
65 65 0
P 37 49 26
Creating User manual
14 51 63 12 Activity Label
Earlie st start Lates t start Activity span
duration
Earlie st finish Latest finish
Activity Description
float
13
It is apparent form the Activity diagram that the complete project is bound to finish in 65 days which is well within the given deadline of three months (considering working of total 14 weeks and 5 days per week) Here the System analyst/Architect would design the system specification and high level design for system, while the developers would carry out the Design and coding part of each module which would run in parallel. Testers would test the code initially during the development of the modules The system integration would then take place which would include integration of all the modules, connection of jsp code with database and current inventory system through appropriate calls, drivers and queues. The overall system would again be tested in terms of end to end working. Then the final build and deployment would be done on Live servers along with the domain name registration and activation which would make the website go live.
1.8 Resources
Resources are one of the key components of any software project. The project is a fixed time/money project involving three months of time in which the IT Company has to develop and deliver complete website up and running in three months from the date of start. There would be a fixed amount of Rs. 10,00,00 would be paid by ABC ltd to the IT company. Also the cost of licensing of the softwares and hardwares would be borne by ABC ltd. Resources for this project can be classified into the following categories:
Labour: There needs to be a proper hierarchical structure in place for efficient managing.
There will be a project steering committee controlling the flow of project. A project manager who will be responsible for the entire project. Each module will employ 1 developer who will be responsible for developing each module. The developers will be responsible for testing and
14
integrating their respective modules. There will be 5 testers for testing the integrated codes base. The team will also consist of a system analyst who will analyze the client system and will accordingly prepare the technical specifications. The system analyst would also do the technical architecture design of the complete project. It will also consist of a quality assurance team, which will be responsible for ensuring quality. Along with that a build, deployment and an integration personnel looking after the integration of builds onto the development, test and production servers. A content manager would work with the client for management and uploading of content on the website.
Hardware/Software/Network It will include workstations and other computing and office
equipments. It will include the hardware requirements for the projects like servers, network cables, internet ports, printers, scanners, photo copiers, etc. Software like OS, antivirus and other various important software need to be updated on all the workstations. For this project Sun Solaris servers are being used with UNIX OS and licenses for other softwares such as Oracle DB, Weblogic, Teamsite, Loadrunner, Toad, Etc would be required.
Other Requirements: The management will require proper space for housing the resources. It
will include cabin for the manager and cubicles for other employees. It will also include desks, chairs, proper lightings and other such stuff for the staff.
Time: The time required for the completion of project has been estimated to 3 months in
which the Website needs to be On Live fully functional. Further distribution of timelines in terms of activities has been discussed in detail in Activity section.
Cost: The costs would in general is categorized into two sections: 1. Staff Costs: Staff costs for the project are shown below :
Member Module code developers (5) Module code testers (5) System Analyst/ Technical Architect (1) Project Manager (1)
Integration manager (1) Content Manager (1) Quality/security assurance manager (1)
2. Overheads: Overheads for this project are estimated as Rs. 10,000 per week.
Hence for three months (approximately 15 weeks) the Overhead + staff costs add up to Rs. 4,83,000 The resource allocation needs to be done on the basis of skill set and the management needs to be in constant touch with the HR department in order to get the right people. They have to manage the resource attrition and have to find suitable replacement. Also, if some critical activity is taking more than estimated time, management needs to employ extra resources there from some other module or activity. The management, also, need to keep the resources motivated in order to get the maximum out of them, so that there will be no issues in completing the project on time.
activities 2 Requirement phase 3 Design and specification takes 6 longer than expected 4 Major sickness of employees 8 involved in non critical path activities 5 Coding of individual modules 5 takes longer time 6 Design flaws during module 4 testing 7 Architecture & design flaw 3 10 30 8 32 4 20 4 32 7 42 specification 7 9 63
The required score in the risk exposure column gives the priorities for the risks which need to be either reduced or prevented first. For example the personnel shortfall could be reduced by staffing with top talent, training and development and early scheduling of key personnel. Technical faults in coding could be avoided by improved software evaluation and formal specification methods. Quality of the design and code could be improved through quality assurance procedures and certification. The major risk exposure is certainly on changes in requirement specifications during coding and testing phase. Since it involves changes in design and lots of rework, its impact is also high both in terms of time and money. Hence Stringent control procedures high change threshold and incremental code development could be done to reduce this risk.
18