Large Scale Software Development

Topic: Software Words: 4129 Pages: 15

Introduction

This report provides information regarding the Resource Scheduling project. The Resource Scheduling project is useful for a consultant company that provides resources of different types to various companies for a particular duration. An example of a company that would require this kind of software is an IT consultant company. Such a company has developers, testers, project managers, technical architects, business analysts, etc. with different levels of experience and different expertise. Another example is a company providing technicians to get work done (servicing, repairing, etc.) on an hourly basis.

The company requires keeping a tab on the available resources. The resources also need to be classified into resource types so that they can be easily identified when a client requests for resources of a particular type. The company also needs to keep records of client details as well as resource requests they have made. A resource request typically consists of resource type and the duration when they would be required to work for that client. A client request may be confirmed or not an also there is a possibility of unavailability of the particular resource type. Both these possibilities need to be incorporated in the project. Finally, the reports in the form of schedules for each of the resource as well as based on the resource type need to be made available in order to check who has to work where and when.

The structure of the document is based on the activities required to be completed. The report starts with the user requirements that are provided in detail along with formal specification of part of the system so as to get familiar with the project. A data flow diagram along with database design provides further insight into the project from a technical perspective. A prototype design, test specification and quality plan including quality assurance processes are also outlined. A project plan and schedule setting out milestones, resource usage and estimated costs in Singapore Dollars are also provided to complete the report. The report ends with a conclusion that summarizes the report.

User requirements

Resources are classified based on resource types.
Resource information needs to be stored which includes name, resource type and any comments on the resource, if required.
Customer information needs to be stored which includes the company address and contact details as well as the contact details of the point of contact in that company.
Customer requests for resources are made by scheduling a resource for a particular day for particular time based on resource type.
If resources are available, the user can allocate and confirm the resources for that particular client.
Schedules for resources are prepared based on resource types as well as resources.
If resources are not available, alternate suggestions regarding schedule is provided based on the schedule of the resources obtained.

Architecture

The architecture used for the project is client-server architecture. This architecture applies irrespective of the language chosen for executing the server-side processes. In this case, a web browser acts as the client and a specific server machine is assigned where the program resides. A user, for example, seeks to view the resource schedule for the coming week. This sends a request from the browser to the server (step 1 in figure).

The server then checks the headers and uses this information obtained to locate the necessary program (step 2 in figure). The data from the headers (in this case, it is the period during which the resource schedule is to be provided) is passed to the program (step 3 in figure). The program then processes this data and the resulting schedule is returned to the server (step 4 in figure). The server then sends the resulting schedule formatted in HTML to the browser which displays the HTML page (Step 5 in figure). Thus, a dynamic HTML page is generated using this client-server architecture. (www.webdevelopersnotes.com, 2000)

Partial formal specification

The formal specification is provided using Unified Modeling Language (UML). “A Class diagram gives an overview of a system by showing its classes and the relationships among them. Class diagrams are static — they display what interacts but not what happens when they do interact” (Miller, n.d.).

The notation used in a class diagram is shown below:

*Figure 2: Notation used in class diagram.*

The relationship between classes is shown with the help of lines and one of the notations below to depict the relationship.

A class diagram is used to represent the project as seen in the figure below.

There are three main classes – Customers, Resources, and Schedule.

A customer can request for many resource types and each resource type can be requested multiple times. Also, a resource can be scheduled for a customer multiple times. Thus, a customer and resource have a many-to-many relationship. This many-to-many relationship is depicted using another class Schedule that connect the two classes with a one-to-many relationship.

A customer may have not requested for a resource yet and also a resource may have not been scheduled yet. However, a resource schedule is associated with one and only one resource and one and only one customer. Thus, a Customer class has a zero-to-many relationship with Schedule class and a Schedule class has a one to one relationship with Customer class. Similarly, a Resource class has a zero-to-many relationship with Schedule class and a Schedule class has a one to one relationship with Resource class.

Data flow design

The notations used to create data-flow diagrams (DFDs) are known as Gane and Sarson notations (Ambler, c. 2003).

The four notations used are explained in brief below:

A square represents an external entity that is either a source or a destination of data, for example, customers and resources in this case.
A rounded rectangle represents a process that takes data as input, processes it and provides an output, for example, request resources, make reservations, etc.
Arrows represent the flow of data between the other notations.
An open-ended rectangle represents a data store such as the database in this case.

The data flow diagram for the project is shown in the figure below.

A customer requests for particular resource types. If resources are available during the period required, reservations are made and the schedule details are stored in the database. Once the resources are scheduled, customer is given a confirmation and a resource schedule is appropriately provided to the resources.

Database design / Data dictionary

The database consists of seven tables. The description of each table is provided below:

Table Customers – This table contains the details of the customer including the company details, address, contact person and his contact details. This is a master table.
Table Resources – This table contains all the details regarding the resource including experience and contact details. This is also a master table.
Table Resource Types – This table contains all the possible resource types.
Table Skills – This table contains all the possible skills applicable (e.g. programming skills such as C#, ASP.NET, MS SQL, etc.).
Table Resource Skills – This table connects a resource with all of the skills s/he knows.
Table Schedule – This table contains the schedule date for a particular resource.
Table Schedule Details – If the resources are scheduled based on hourly slots, then this table helps note down the start time and date and also whether the reservation is confirmed or not.

The ERD diagram of the database is as shown below:

The data dictionary of the project is provided in detail below for each of the seven tables in the project.

Table 1: Data Dictionary.

Table	Field Name	Data Type	Field Size	Others
Customer	CustomerID	AutoNumber	Long Integer	No Duplicates
Customer	FirstName	Text	30
Customer	LastName	Text	50	Indexed
Customer	Company	Text	50
Customer	BillingAddress	Text	255
Customer	City	Text	50
Customer	State	Text	20
Customer	PostalCode	Text	20	Indexed
Customer	Country	Text	50
Customer	Title	Text	50
Customer	Phone	Text	30
Customer	Ext	Text	30
Customer	Fax	Text	30
Customer	Email	Text	50
Resources	ResID	AutoNumber	Long Integer	No Duplicates
Resources	Name	Text	50
Resources	ResTypeID	Number	Long Integer	Indexed
Resources	Experience	Number	Byte
Resources	Address	Text	255
Resources	City	Text	50
Resources	State	Text	20
Resources	PostalCode	Text	20
Resources	Country	Text	50
Resources	Phone	Text	30
Resources	Email	Text	50
Resources	Comments	Memo
Resource Types	ResTypeID	AutoNumber	Long Integer	No Duplicates
Resource Types	ResType	Text	50
Skills	SkillID	AutoNumber	Long Integer	No Duplicates
Skills	Skill	Text	50
Resource Skills	SkillID	Number	Long Integer
Resource Skills	ResID	Number	Long Integer
Schedule	ScheduleID	AutoNumber	Long Integer	No Duplicates
Schedule	ResID	Number	Long Integer
Schedule	ScheduleDate	Date/Time	Short Date
Schedule Details	ScheduleDetailsID	AutoNumber	Long Integer	No Duplicates
Schedule Details	ScheduleID	Number	Long Integer
Schedule Details	CustomerID	Number	Long Integer
Schedule Details	ScheduleStartTime	Date/Time	Short Date
Schedule Details	ScheduleEndTime	Date/Time	Short Date
Schedule Details	Confirmed	Yes/No

Prototype design

The prototype design of three forms is shown below. The forms are simple data entry forms consisting of text boxes and drop down menus for entering data.

Customer Data Entry Form

First Name
Last Name
Billing Address
City
State/Province
Postal Code
Country
Title
Company
Phone
Extension
Fax
Email

Figure 8: Customer Data Entry Form.

Resources Data Entry Form

Resource Name
Resource Type
Experience
Address
City
State
Postal Code
Phone
Email
Comments

Figure 9: Resources Data Entry Form.

Resource Type Data Entry Form

Resource Type

Figure 10: Resource Type Data Entry Form.

Test specification

The testing process for Resource Scheduling will be based on the following goals:

Thorough testing for coding bugs and logical errors
High quality: well-executed software, easy to use interface, reasonable performance
Errors are handled appropriately ensuring that the program does not end abruptly.

The system will be tested on machines with the following configuration:

Windows XP and Windows Vista
1.7+ GHz
512 MB RAM
Browsers
- Internet Explorer 6.0 and 7.0
- Firefox 2.0

Components to be tested:

Interfaces
1. Resources Data Entry Form
2. Resource Types Master Form
3. Skills Master Form
4. Customers Data Entry Form
5. Reservations Data Entry Form
6. Resource Schedule Report
7. Resources By Type Report
Help components
1. Help Files
2. Tutorials
Server Installation

The types of testing that will be conducted on the project are:

Unit Testing: A white box testing will be conducted using Basis Path testing methods.
Integration Testing: An integration testing will be carried out on completion of the coding using black box testing.
Validation Testing: All input controls such as textboxes, drop down menus, etc. will be validated as per the constraints (type, size, etc.) levied on it based on data dictionary.
User Acceptance Testing: Users will formally test the software based on the processes they follow when scheduling resources manually and report any issues.

No special resource will be used for testing. Except for user acceptance testing which will be carried out by the users, the remaining tests will be conducted by the development team headed by the project manager.

A bug log and a test log will be maintained in Microsoft Excel.

Project plan

The project schedule was prepared using Microsoft Project. A WBS was created up to three levels. Each entry in WBS has been assigned a number depending upon the level it is for ease in identification. Expert judgment was used in order to arrive at durations for each task. The dependencies of each task were noted down. Once the starting date of the project was provided, Microsoft Project automatically provided the start and finish dates of all the tasks based on the duration and predecessors provided.

Table 2: Project Schedule.

ID	Tasks	Duration	Start	Finish	Predecessors
1	Resource Scheduling Project	101 days	9/21/2009	2/8/2010
2	1.0 Project Initiation	12 days	9/21/2009	10/6/2009
3	1.1 Team Organization	3 days	9/21/2009	9/23/2009
4	1.1.1 Select Project Manager	1 day	9/21/2009	9/21/2009
5	1.1.2 Form Project Team	1 day	9/22/2009	9/22/2009	4
6	1.1.3 Briefing	1 day	9/23/2009	9/23/2009	5
7	1.2 Stakeholder Management	4 days	9/22/2009	9/25/2009
8	1.2.1 Identify Key Stakeholders	1 day	9/22/2009	9/22/2009	4
9	1.2.3 Stakeholder Meeting	2 days	9/24/2009	9/25/2009	3, 8
10	1.3 Project Charter	4 days	9/28/2009	10/1/2009	7
11	1.3.1 Develop Charter	2 days	9/28/2009	9/29/2009
12	1.3.2 Revise	1 day	9/30/2009	9/30/2009	11
13	1.3.3 Approval	1 day	10/1/2009	10/1/2009	12
14	1.3.4 Project Charter Finalized and Approved	0 days	10/1/2009	10/1/2009	13
15	1.4 Preliminary Scope Statement	3 days	10/2/2009	10/6/2009	10
16	2.0 Project Planning	16 days	10/7/2009	10/28/2009	2
17	2.1 Project Kickoff Meeting	1 day	10/7/2009	10/7/2009
18	2.3 Develop Project Plan	11 days	10/8/2009	10/22/2009	17
19	2.3.1 Create Scope Statement	7 days	10/8/2009	10/16/2009
20	2.3.2 Create WBS	4 days	10/19/2009	10/22/2009	19
21	2.4 Prepare Cost Baseline and Schedule	4 days	10/23/2009	10/28/2009	20
22	2.4.1 Estminate Task Resources	2.5 days	10/23/2009	10/27/2009
23	2.4.2 Estimate Task Duration	2.5 days	10/23/2009	10/27/2009
24	2.4.3 Develop Budget	1 day	10/23/2009	10/23/2009
25	2.4.4 Create Gantt Chart	0.5 days	10/28/2009	10/28/2009	22 FS + 1 day
26	2.4.5 Create Network Diagram	0.5 days	10/28/2009	10/28/2009	22 FS + 1 day
27	2.5 Project Plan Approved	0 days	10/28/2009	10/28/2009	21
28	3.0 Project Design	10 days	10/29/2009	11/11/2009	16
29	3.1 Analyze Current System	5 days	10/29/2009	11/4/2009
30	3.1.1 Define User Requirements	3 days	10/29/2009	11/2/2009
31	3.1.2 Define System Requirements	2 days	11/3/2009	11/4/2009	30
32	3.2 Design	5 days	11/5/2009	11/11/2009	29
33	3.2.1 Define System Standards	2 days	11/5/2009	11/6/2009
34	3.2.2 User interface	2 days	11/9/2009	11/10/2009	33
35	3.2.3 Configuration	1 day	11/11/2009	11/11/2009	34
36	3.3 Review and Approval	0 days	11/11/2009	11/11/2009	29, 32
37	4.0 Project Implementation	41 days	11/12/2009	1/7/2010
38	4.1 Develop Software	37 days	11/12/2009	1/1/2010
39	4.1.1 Software Requirement Specifications	5 days	11/12/2009	11/18/2009	32
40	4.1.2 Develop Prototype	4 days	11/19/2009	11/24/2009	39
41	4.1.3 Review and Approval	2 days	11/25/2009	11/26/2009	40
42	4.1.4 Software Coding	21 days	11/27/2009	12/25/2009	41
43	4.1.5 Debugging	5 days	12/28/2009	1/1/2010	42
44	4.2 User Manuals	2 days	11/12/2009	11/13/2009	32
45	4.3 Installation	2 days	1/4/2010	1/5/2010	38
46	4.4 Training	2 days	1/6/2010	1/7/2010	45
47	4.5 Coding completed	0 days	1/7/2010	1/7/2010	45, 46
48	5.0 Project Testing	15 days	1/8/2010	1/28/2010	37
49	5.1 Develop Test Cases	10 days	1/8/2010	1/21/2010
50	5.2 Execute Test Cases	5 days	1/22/2010	1/28/2010	49
51	5.3 Testing completed	0 days	1/28/2010	1/28/2010	50
52	6.0 Project Closing	7 days	1/29/2010	2/8/2010	48
53	6.1 Verify Deliverables Met	2 days	1/29/2010	2/1/2010
54	6.2 Gain User Acceptance	3 days	2/2/2010	2/4/2010	53
55	6.3 Project Closure	2 days	2/5/2010	2/8/2010	54
56	7.0 Project completed	0 days	2/8/2010	2/8/2010	52

The Gantt chart of the project is as shown below:

Gantt chart - Part 1. — *Figure 11: Gantt chart – Part 1.*

Gantt chart - Part 2. — *Figure 12: Gantt chart – Part 2.*

In order to calculate the cost of the project, each task was assigned a resource. The resource units were allocated instead of any particular resource. Also, an average cost of 30 SGD per hour was assumed for each resource. Once the resources were allocated, Microsoft Project again provided the costs based on the resource units required and the cost per hour of the resource.

Table 3: Cost per task and overall cost.

ID	Tasks	Cost	Resources
1	Resource Scheduling Project	107,520.00 SGD
2	1.0 Project Initiation	7,440.00 SGD
3	1.1 Team Organization	1,920.00 SGD
4	1.1.1 Select Project Manager	240.00 SGD	Resource
5	1.1.2 Form Project Team	240.00 SGD	Resource
6	1.1.3 Briefing	1,440.00 SGD	Resource [600%]
7	1.2 Stakeholder Management	720.00 SGD
8	1.2.1 Identify Key Stakeholders	240.00 SGD	Resource
9	1.2.3 Stakeholder Meeting	480.00 SGD	Resource
10	1.3 Project Charter	1,920.00 SGD
11	1.3.1 Develop Charter	1,440.00 SGD	Resource [300%]
12	1.3.2 Revise	240.00 SGD	Resource
13	1.3.3 Approval	240.00 SGD	Resource
14	1.3.4 Project Charter Finalized and Approved	0.00 SGD
15	1.4 Preliminary Scope Statement	2,880.00 SGD	Resource [400%]
16	2.0 Project Planning	16,800.00 SGD
17	2.1 Project Kickoff Meeting	1,440.00 SGD	Resource [600%]
18	2.3 Develop Project Plan	10,560.00 SGD
19	2.3.1 Create Scope Statement	6,720.00 SGD	Resource [400%]
20	2.3.2 Create WBS	3,840.00 SGD	Resource [400%]
21	2.4 Prepare Cost Baseline and Schedule	4,800.00 SGD
22	2.4.1 Estminate Task Resources	1,800.00 SGD	Resource [300%]
23	2.4.2 Estimate Task Duration	1,800.00 SGD	Resource [300%]
24	2.4.3 Develop Budget	720.00 SGD	Resource [300%]
25	2.4.4 Create Gantt Chart	240.00 SGD	Resource [200%]
26	2.4.5 Create Network Diagram	240.00 SGD	Resource [200%]
27	2.5 Project Plan Approved	0.00 SGD
28	3.0 Project Design	16,320.00 SGD
29	3.1 Analyze Current System	8,400.00 SGD
30	3.1.1 Define User Requirements	5,040.00 SGD	Resource [700%]
31	3.1.2 Define System Requirements	3,360.00 SGD	Resource [700%]
32	3.2 Design	7,920.00 SGD
33	3.2.1 Define System Standards	2,880.00 SGD	Resource [600%]
34	3.2.2 User interface	3,840.00 SGD	Resource [800%]
35	3.2.3 Configuration	1,200.00 SGD	Resource [500%]
36	3.3 Review and Approval	0.00 SGD
37	4.0 Project Implementation	46,080.00 SGD
38	4.1 Develop Software	42,240.00 SGD
39	4.1.1 Software Requirement Specifications	6,000.00 SGD	Resource [500%]
40	4.1.2 Develop Prototype	0.00 SGD
41	4.1.3 Review and Approval	0.00 SGD
42	4.1.4 Software Coding	30,240.00 SGD	Resource [600%]
43	4.1.5 Debugging	6,000.00 SGD	Resource [500%]
44	4.2 User Manuals	960.00 SGD	Resource [200%]
45	4.3 Installation	1,440.00 SGD	Resource [300%]
46	4.4 Training	1,440.00 SGD	Resource [300%]
47	4.5 Coding completed	0.00 SGD
48	5.0 Project Testing	13,200.00 SGD
49	5.1 Develop Test Cases	9,600.00 SGD	Resource [400%]
50	5.2 Execute Test Cases	3,600.00 SGD	Resource [300%]
51	5.3 Testing completed	0.00 SGD
52	6.0 Project Closing	7,680.00 SGD
53	6.1 Verify Deliverables Met	1,920.00 SGD	Resource [400%]
54	6.2 Gain User Acceptance	2,880.00 SGD	Resource [400%]
55	6.3 Project Closure	2,880.00 SGD	Resource [600%]
56	7.0 Project completed	0.00 SGD

The total cost based on this comes to 107, 520.00 SGD.

The milestones of the project are:

ID	Tasks	Start	Finish	Predecessors
14	1.3.4 Project Charter Finalized and Approved	10/1/2009	10/1/2009	13
27	2.5 Project Plan Approved	10/28/2009	10/28/2009	21
36	3.3 Review and Approval	11/11/2009	11/11/2009	29, 32
47	4.5 Coding completed	1/7/2010	1/7/2010	45, 46
51	5.3 Testing completed	1/28/2010	1/28/2010	50
56	7.0 Project completed	2/8/2010	2/8/2010	52

Quality plan

Quality assurance process consists of several umbrella activities that assist in continuous improvement of processes in an organization (Dinsmore et al, 2006). Quality assurance activities can help ensure that quality is built into the project, instead of being tested or checked at the end of the project. Continuous improvement in processes help eliminate activities that provide no value addition to the process and also helps introduce new activities that add value to the processes or modify existing activities so that it can provide better value, thereby allowing operating the organization processes at very high levels of efficiency (Dinsmore et al, 2006). Quality assurance endeavors to ensure that the scope, cost and time goals of a project are met satisfactorily (Kerzner, 2003).

The most commonly used technique for quality assurance is a quality audit. Harold Kerner (2003) defines quality audit as “an independent evaluation performed by qualified personnel that ensures that the project is conforming to the project’s quality requirements and is following the established quality procedures and policies”. It is important to note here that project team members should not be used for audits as Kenneth Rose (2005) warns that “project team members may be just too close to things to get an accurate picture”.

With the help of a quality audit, an organization can ensure that there is compliance with the policies, processes and procedures as defined in the project plan for the project and any deviations from them are noted down. The result of a quality audit comes in the form of corrective and preventive actions, defects, and change requests. Also, a quality audit is used to confirm whether these change requests, corrective and preventive actions and defect repairs that were identified in earlier audits or using other methods have been corrected or correctly implemented.

A quality audit usually requires a root cause analysis to be conducted post the audit. This involves examining the problem(s) found, especially ones that have been a repeat problem or has a high impact and discovering and tackling the underlying issues to avoid reappearance of the problem.

This project demands high quality and in order to achieve that frequent quality audits will be conducted. The frequency of quality audits would ideally take place every month; however, if many non-compliances are found in any audit, then the management can take a call to have a quality audit every two weeks instead of a month. The report of the quality audit should be a formal report and needs to be submitted to the management. All corrective and preventive actions will be noted along with action items and start date. Defect repairs will be added to common project bug log. Any process improvement suggested and implemented will be thoroughly documented and their effectiveness will be measured.

Reviews, walkthroughs and inspections will also be conducted in order to evaluate the system.

Peer review and expert review are the two main types of reviews that will be conducted in this project. Expert review, as the name suggests, is conducted by an expert in that field while peer review is conducted by fellow colleagues. When the accuracy of the content is important and needs to be checked and corrected as required, an expert review is used. On the other hand, a peer review is used when it is required to check the structure rather than the content although content could also be checked. All deliverables will be first peer reviewed to ensure that the structure is appropriate and the applicable standards are followed for the same. An expert review will then be conducted to ensure that the content is correct.

A walkthrough is time-consuming and requires “walking through” the code and checking for content and structure. The walkthrough will be conducted twice during the implementation by the project manager. The final check will be a formal inspection of all documentation prepared for the project and would ideally be done by an external project reviewer or auditor.

Conclusion

The Resource Scheduling project is designed for a consultant company that provides different types of resources to companies on a need basis. The resources can be provided on an hourly basis. The user requirements for the project are provided in detail. The basic user flow is that a customer requests for particular resource types. If the resources under that resource type are available, then they are scheduled and upon confirmation, a periodic schedule is provided to the resource.

An outline architectural design, a class diagram, a data flow diagram, entity relationship diagram (ERD), database design, and a data dictionary are provided in order to understand the needs of the project and to discover any errors in the understanding.

A prototype design consisting of 3 screenshots of the forms used in the project are also provided to give an idea of how the project would work. A project plan outlining the schedule, milestones, resource usage, estimated costs in Singapore Dollars are also provided along with a Gantt chart. A test specification is outlined that provides the testing to be carried out, the test environment, the scope of the testing, etc. Finally, a quality plan provides information on the quality assurance procedures and also how the system will be evaluated. The project has been set up with all technical and project management activities taken care of as appropriate in order to ensure the success of the project.

Bibliography/Reference List

Ambler, S. W. (c. 2003) Data Flow Diagrams (DFDs). Web.

Dinsmore, P. C. & Cabanis-Brewin, J. (2006). “Chapter 11 – Project Quality Management in Practice”. The AMA Handbook of Project Management, Second Edition. AMACOM.

Kerzner, H. (2003). “Chapter 20 – Quality Management”. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, Eighth Edition. John Wiley & Sons.

Miller, R. (n.d.). “Practical UML™: A Hands-On Introduction for Developers”. Web.

Prasad, N. & Lord G. (2006). “Protein Express Project Quality Management Plan”. Web.

Rose, K. H. (2005). “Chapter 4 – Project Quality Planning”. Project Quality Management: Why, What and How. J. Ross Publishing.

Rose, K. H. (2005). “Chapter 5 – Project Quality Assurance”. Project Quality Management: Why, What and How. J. Ross Publishing.

Rose, K. H. (2005). “Chapter 6 – Project Quality Control and Quality Improvement”. Project Quality Management: Why, What and How. J. Ross Publishing.

Turbit, N. (2005). “Project Quality Planning“. Web.

webdevelopersnotes. (2000) “The Client Server Architecture”. Web.