Large Scale Software Development

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

  1. Resources are classified based on resource types.
  2. Resource information needs to be stored which includes name, resource type and any comments on the resource, if required.
  3. 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.
  4. Customer requests for resources are made by scheduling a resource for a particular day for particular time based on resource type.
  5. If resources are available, the user can allocate and confirm the resources for that particular client.
  6. Schedules for resources are prepared based on resource types as well as resources.
  7. 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:

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:

  1. A square represents an external entity that is either a source or a destination of data, for example, customers and resources in this case.
  2. A rounded rectangle represents a process that takes data as input, processes it and provides an output, for example, request resources, make reservations, etc.
  3. Arrows represent the flow of data between the other notations.
  4. 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:

  1. 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.
  2. Table Resources – This table contains all the details regarding the resource including experience and contact details. This is also a master table.
  3. Table Resource Types – This table contains all the possible resource types.
  4. Table Skills – This table contains all the possible skills applicable (e.g. programming skills such as C#, ASP.NET, MS SQL, etc.).
  5. Table Resource Skills – This table connects a resource with all of the skills s/he knows.
  6. Table Schedule – This table contains the schedule date for a particular resource.
  7. 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:

  1. Thorough testing for coding bugs and logical errors
  2. High quality: well-executed software, easy to use interface, reasonable performance
  3. 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:

  1. 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
  2. Help components

    1. Help Files
    2. Tutorials
  3. Server Installation

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

  1. Unit Testing: A white box testing will be conducted using Basis Path testing methods.
  2. Integration Testing: An integration testing will be carried out on completion of the coding using black box testing.
  3. 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.
  4. 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:

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). ““. Web.

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

"Looking for a Similar Assignment? Order now and Get a Discount!

Place New Order
It's Free, Fast & Safe

"Looking for a Similar Assignment? Order now and Get a Discount!