Stephen Gubenia

Developed for CMIS 330 Dr.

Almarzooq

12/7/2014

2014

for John and Joan Bed & Breakfast

i

Table of Contents1. Overview................................................................................................................ 1

1.1 Project Summary...............................................................................................1

1.1.1 Purpose, Scope, and Objectives..................................................................1

1.1.2 Assumptions and Constraints......................................................................2

1.1.3 Project Deliverables....................................................................................2

2. References.............................................................................................................2

3. Definitions..............................................................................................................3

4. Project Organization...............................................................................................3

4.1 External Interfaces............................................................................................3

4.2 Internal Structure..............................................................................................3

4.3 Roles and Responsibilities.................................................................................5

5. Managerial Process Plans.......................................................................................6

5.2 Work Plan..........................................................................................................6

5.2.1 Work Activities............................................................................................6

5.2.2 Schedule Allocation.....................................................................................7

5.2.3 Resource Allocation.....................................................................................9

5.4 Risk Management Plan....................................................................................10

6. Technical Process Plans........................................................................................10

6.1 Process Model.................................................................................................10

6.2 Methods, Tools, and Techniques.....................................................................11

1

1. OverviewThe software development plan (SDP) is a comprehensive, composite document that contains all information required to manage the development and delivery the Bed and Breakfast Reservation Management System (BBRMS). This document will detail all standards, methods, tools, actions, reuse strategies, and responsibilities associated with the development and qualification of all requirements, including safety and security. It should be used by the project manager and development team to meet milestones, product deliverables, and maintain project flow according to the predetermined schedule.

1.1 Project Summary1.1.1 Purpose, Scope, and ObjectivesThe BBRMS will be used by the management and staff of small bed & breakfast (B&B) establishment to process guest reservations, store guest information, and assist in the financial management of the business. The software is designed to automate many of the business processes thus increasing efficiency and driving revenue.

The scope of the software is limited to the needs of the customer, who are the management and staff of a small, single B&B establishment. The software should be designed as a standalone system with only the functional elements required by the customer as outlined in the system requirements specification (SRS). By limiting the functionality to the needs of the customer, the software will be simple and reliable thus ensuring a high level of usability by the customer.

The objectives of the BBRMS are to simplify the reservation process, and financial transactions, thus enhancing efficiency. The software will automate some manual processes to assist the user of the BBRMS servicing customers over the phone or in-person.

The product delivered should include:

1. Software package containing:a. Calendar management;b. Reservation queries;c. Guest information GUI form;d. Reservation information GUI form;e. Financial transaction GUI form;f. Background polling of reservations to delete reservations with expired

guarantees2. User guide and product manual;3. Quick reference guide.

Delivery of the complete product depends on successful user acceptance testing, automated testing, integration testing, and guided walkthroughs of the user guide and quick reference guide. Successful delivery of the final product will be defined as meeting all project milestones and providing the customer with a completed

2

product by the agreed upon delivery date. Product requirements are listed in the BBRMS Software Requirements Specification.

1.1.2 Assumptions and ConstraintsFor the development of the BBRMS, it is assumed that a sufficient platform is in place to deploy the software. This platform is not part of the BBRMS, and is out-of-scope of the requirements.

The BBRMS is designed to be portable. To ensure portability, the software will be developed with a portable language (Java) and will minimize user interface requirements.

The BBRMS has minimal assumptions because of the lean design. The development teams should make use of open-source software (OSS), when appropriate, and current libraries for general functions, to expedite development. The database within the environment is dependent on the infrastructure in use by the customer. As a result, testing for several versions of relational database management systems (RDBMS) will be required to assure compatibility with these technologies, and must referenced within the user guide.

Interfaces with other software are not applicable for the BBRMS.

1.1.3 Project DeliverablesThe focus for project deliverables of the BBRMS is concentrated on the following:

1. Software package containing:a. Calendar management;b. Reservation queries;c. Guest information GUI form;d. Reservation information GUI form;e. Financial transaction GUI form;f. Background polling of reservations to delete reservations with expired

guarantees2. User guide and product manual;3. Quick reference guide.

The software delivery of the BBRMS will consist of a Java application with executable shell scripts for Microsoft Windows and an example configuration file for database connectivity. The example file will show configuration options for MySQL, Oracle, and Microsoft Access. The software will be made available for digital download and will also be provided on CD-ROM.

The user guide and quick reference guide will be delivered as a hard copy, as a CD-ROM and available for digital download as well, in PDF format.

2. ReferencesThe BBRMS project management plan references the following documents:

1. Software Development Plan (this document);

3

2. Software Requirements Specification 3. Software Design Document;4. Software Test Specification.

3. Definitions

Term DefinitionAgile A lean development strategy to manage requirements based on an

iterative methodGit A distributed revision control system with an emphasis on speed, data

integrity, and support for distributed, non-linear workflows. It is the most widely adopted version control system for software development and is a full-fledged repository with complete history and full version-tracking capabilities, independent of network access or a central server.

Outreach The methodologies used by a project lead or specialist working with the customer to perform business analysis, requirements specification, and determine opinions on implementation to ensure delivery of a product that meets the customer’s needs and expectations.

Validate Building the right product to meet customer’s requirementsVerify Building the product to function correctly and efficiently.Waterfall A linear method of project management and software development.

4. Project OrganizationThis section designates how the project team will be organized for BBRMS. The project team is designed to be small due to the lean nature of the BBRMS. The small size will enhance efficiency in communication both internally within the team, and externally with customer during outreach phases.

4.1 External InterfacesThe lean design and functionality of the BBRMS and the small size of the development team limit external interfaces directly to the customer.

4.2 Internal Structure The BBRMS development team will consist of five (5) members. The breakdown of the team consists of two (2) Java developers, a user experience (UX) specialist, program manager, and customer outreach liaison. This composition allows direct interaction with the customer, via the customer outreach liaison and project manager, during development of the software requirements, as well as during the design and modification of the user interface elements, via the UX specialist, ensuring efficient requirements and process management and transparency of the project between the customer and development team. This transparency will serve to maintain a high level of customer trust and satisfaction.

4

Figure 1. BBRMS Development Team Structure and Information Flow

The structure of the BBRMS development team is designed to encapsulate and isolate some processes specific to team members, while also allowing for maximum flow of information and enhanced communication. In Figure 1 the developers and UX specialist are highlighted in light blue. This signifies that these members perform internal functions which vital to the software and interface development. Therefore some level of shielding and isolation from customer interaction is necessary to allow for maximum efficiency. The project manager and customer outreach liaison communicate and negotiate directly with the customer to ensure that customer needs are feasible and can be met. They determine the agreed upon requirements and minimize the amount of changes that can occur to the requirements during development to maximize efficiency and keep the project on schedule to ensure timely delivery. This structure ensures that communication between each portion of the team exists for optimum results.

Some level of isolation is necessary to the efficiency of developers and designers. If each developer and designer had interaction with the customer it is possible for a single developer to make changes based on customer feedback without the knowledge of other members of the team. This can lead to compatibility errors and faults within the software causing the project to fall behind schedule. While isolation of these team members is necessary, it is critical to ensure constant feedback flows between the developers and customer through the project manager and customer outreach liaison to ensure validation of the product. This structure will ensure that both customer requirement questions and issues from the development team are handled directly and frequently, without slowing or halting work by the developers.

5

Software version control for all software within the BBRMS development cycle will be implemented using Git. Developers will manage quality assurance throughout the development cycle by ensuring the following requirements for change management and version control are met:

1. Commit source code to the Git repositories every 24 hours at minimum, and more frequently as able.

2. Commits to the source code repository will occur only after completion of sufficient testing to verify that the changes work, and do not break builds.

3. Test infrastructure will use Puppet Enterprise, an automated configuration management and orchestration tool. This will facilitate repeatable results for the creation of a virtual environment to deploy builds and minimize requirements for system administrators.

4. Commit all source code changes and infrastructure change management scripts to Git when stable.

To provide a high-level of quality assurance during testing, developers are to provide complete unit and integration test suites for automated testing. These tests are to be built in Jasmine to match the Java class design and details defined in the SDD, and accurately match functionality of methods during development. The commit process to Git should have a post-commit hook to run automated tests. This will ensure a 100% pass rate of code moving into the source code repository.

Integration tests should be created to test the functionality where external interactions, such as database configurations, occur. Each configuration for supported databases should have an appropriate integration test that both passes and directly corresponds to a requirement and statement of configuration within the user’s guide.

All automated test suites for unit and integration testing should correspond with a requirement within the Software Test Specification (STS), and be version controlled and committed within the source code repository.

4.3 Roles and Responsibilities The BBRMS development team is assigned the following work roles and responsibilities:

Two (2) Java developers – Perform software development tasks using the third generation language (3GL) Java. Must be fluent in the Java language, and corresponding application programming interfaces (APIs) used to implement software in a cross-platform environment. Additionally, the understanding and configuration of data sources and connectivity for data persistence in the BBRMS will be required to validate and test requirements associated with data stores.

One (1) user experience (UX) specialist – Outlines and designs interfaces focusing on design efficiency and internal/external requirements related to the human-computer interaction (HCI) of the BBRMS. This person shall provide prototypes, based on user engagement and customer interaction, to the development team for the user interface.

6

One (1) program manager – Oversees all aspects of the project including, requirements management, and milestone deadlines for the team. Delivers integrated master schedules (IMS) for the project and conducts schedule conflict resolution to mitigate any risks associated with the waterfall development methodology. The manager is also responsible for receiving and managing feedback from the customer, and providing on-time deliverables for milestones within the project lifecycle.

One (1) customer outreach liaison – Interacts with the customer frequently for consistent and constant feedback through the project lifecycle. Also serves as the interface between the BBRMS development team and the customer to provide feedback from the team to the customer when required. This position is the key to ensuring successful delivery all deliverables created during development stages and milestones, as well as the complete software package. The liaison will also allow the maintenance of a high level of customer trust and satisfaction during the development cycle.

5. Managerial Process PlansThis section of the SDP outlines the work schedule and task structure required to meet the customer needs and requirements on an agreed upon timeline.

5.2 Work Plan The following section contains a detailed definition of the breakdown tasks in the project schedule for the BBRMS development team.

5.2.1 Work Activities The following table (Figure 2) contains the full breakdown of tasks included in the master work schedule of the BBRMS software development life cycle (SDLC).

Task NameSDLC Task Category

SDLC Sub-Task

Form Teams Analysis Business AnalysisInitial Customer Engagement Analysis Business AnalysisIdentify Customer Needs and High-Level Requirements Analysis Software AnalysisDevelop Milestones Analysis Business AnalysisDefine Budget Analysis Business AnalysisDevelop Requirements Design Software AnalysisDeliver and Discuss Software Requirements Specification Analysis Business AnalysisSoftware Design Review Design Software DesignCreate Software Design Document Design Software DesignDeliver and Discuss Software Design Document Analysis Software DesignCreate Software Testing Specification Design Test DesignDeliver and Discuss Software Testing Specification Analysis Business AnalysisBuild Calendar Query Services Code Service DevelopmentBuild Calendar Query GUI Code Interface Development

7

Build User Information Services Code Service DevelopmentBuild User Information GUI Code Interface Development

Produce Initial User DocumentationCode

Documentation Development

Build and Package Alpha (v0.1) Code Software BuildRelease 0.1 (Alpha) Code Software BuildInitial User Acceptance Engagement Test User TestingBuild Room Reservation Domain Object Code Data DevelopmentBuild Room Reservation Services Code Service DevelopmentBuild Room Reservation GUI Code Interface DevelopmentBuild Payment Domain Object Code Data DevelopmentBuild Payment Services Code Service DevelopmentBuild Payment GUI Code Interface DevelopmentBuild Guest Reservation Domain Object Code Data DevelopmentBuild Guest Reservation Services Code Service DevelopmentBuild Guest Reservation GUI Code Interface Development

Produce Extended Functionality User DocumentationCode

Documentation Development

Build and Package Beta (v0.5) Code Software BuildRelease 0.5 (Beta) Code Software BuildMid-Point Customer Engagement Analysis Business AnalysisMid-Point User Acceptance Engagement Test User TestingBuild Reservation Scanning Services Code Service DevelopmentBuild Database Connectivity Services Code Service Development

Produce Final User DocumentationCode

Documentation Development

Build and Package Final (v1.0) Code Software BuildRelease 1.0 (Final) Code Software BuildFinal Customer Engagement Analysis Business AnalysisFinal User Acceptance Engagement Test User TestingDelivery of Product (BBRMS v1.0 and Documentation) Code Software Build

Figure 2. Master Work Schedule

5.2.2 Schedule AllocationFigure 3 below contains the entire project schedule in a Gantt chart view. This view shows the dependency between tasks, tasks that are performed concurrently, and isolates important milestones reflected as diamonds on the chart. The schedule shows project-related, development-related tasks and deliverables throughout the project duration, which is approximately 12 weeks. The nature of the waterfall methodology used (see section 6.1) means that changes in schedule due to external factors, changes in requirements, or technical delays during the development cycle can shift the project timeline to the right, past it’s agreed upon and intended delivery date of May. The project uses a test driven development (TDD) strategy, thus the testing specifications will be developed in the early stages of the project prior to coding. The regular cycle of coding, testing, recoding, and

8

retesting will ensure that the final stages of integration and user acceptance testing go smoothly.

8Figure 3. Gantt chart for Project Schedule

9

5.2.3 Resource AllocationBefore beginning resource allocation for the BBRMS project, an initial understanding of the complexity of the overall design needs to be addressed. The Constructive Cost Model (COCOMO) method will be used for project analysis and subsequent assigning of staff to the project.

The BBRMS consists of software components designed for a mixture of payroll and inventory systems, therefore the COCOMO method can be used for the following project analysis model:

COCOMO Mode

Project Type Team Size Development Environment

Constraints and

Deadlines

Organic Payroll, Inventory

Small Stable (in-house)

Loose

The model determines that the ‘Organic’ COCOMO mode can be used for further analysis. This method provides an equation for project effort in the form of:

Effort = a * (size) ^ b

Under the ‘Organic’ COCOMO mode, a = 2.4 and b = 1.05. The preliminary estimation of the source lines of code (SLOC) in thousands of units (KLOC) is determined to be 5.5, or ~5500 lines of code. Using the above equation we yield the following calculation for an estimation of human effort:

Effort = 2.4 * (5.5) ^ 1.05 = 14.37

With the calculation of human effort, we can now estimate project time in staff months. The COCOMO method provides the following equation:

TDEV = 2.5 * (Effort) ^ 0.38

Entering the calculated estimate of human effort, the equation becomes:

TDEV = 2.5 * (14.37) ^ 0.38 = 6.88 months

The following equation calculates the average staff size based on the ratio of estimated human effort versus estimated project staff time:

Average Staff Size = Effort / TDEV

This equation yields the final calculation:

Average Staff Size = 14.37/ 6.88 = 2.08, or two full time developers

The calculation of two full time developers, plus staff to provide customer liaison and project oversight functions, and user interface design, matches the mechanics required to fulfill implementation of the BBRMS software. The approximation of 12

10

weeks for development is roughly equivalent to the dependency tree of tasks observed in the project schedule in Figure 3, and the association of tasks in the master work schedule in Figure 2.

5.4 Risk Management PlanThe focus of risk management for the BBRMS is both the proper software configuration of databases, and the developers’ ability to prioritize features based on the customer’s requirements. The most critical development risk identified is the possibility of the BBRMS software not being compatible with the RDMBS at the customer site. Figure 4 prioritizes the development risks.

Risk Priority

Description Impact Probability

Weighted Impact

1 Customer wants connection to unsupported database software.

$1000.00 0.5 $500

2 Customer wants feature not provided in requirements set

$500 0.8 $400

3 Customer is unable to load software

$3500 0.1 $350

Figure 4. Prioritized Risk Management Matrix

The development team must provide the following in order to mitigate the risk of database configuration and implementation mismatch (Risk Priority 1, Figure 4):

1. Documentation defining what database software is supported by the BBRMS.2. Generation and application of specific tests for supported RDMBS.3. Configuration examples for the supported RDBMS.4. Customer support, for RDBMS software that is out-of-scope for integration.5. Documented scenarios that explain ‘like’ configurations of databases. An

example of this would be the use of MariaDB, which is similar to MySQL.

Most risks can be mitigated by enforcing a rigid set of tests against supported RDBMS software, communicating with the customer to ensure specific requirements are met during development, and providing helpful support when issues arise.

6. Technical Process Plans This section addresses the processes and methods that the development team will use to plan, analyze, construct, and test the source code based on customer requirements.

6.1 Process ModelThe waterfall method for development and project management will be used by the development team. The development team may organize and develop deliverables in a pseudo-agile fashion, building epics, stories and tasks in conjunction with the overall planning strategy for the team. This model is heavily influenced by the

11

Department of Defense (DoD) model for government acquisition planning with lean development phases. This model helps to achieve large scale planning for acquisition and management while providing more flexibility to the development teams tasked with implementation.

This process allows for starting activities based on project assessment and business analysis with or without the customer present. This provides for the development of both sub-processes and requirements used to generate milestones through the course of the project, and to assign responsibility tasks within the team. The conclusion of the project, which is the final milestone, is defined as the delivery of the final product after multiple cycles of customer engagement and user acceptance testing.

6.2 Methods, Tools, and Techniques The BBRMS development team will also require a standard process to perform development, testing, integration and documentation. The following standards are to be implemented and adhered to throughout the SDLC:

1. Language – Java and associated APIs;2. Database Implementations – MySQL, Oracle, and MS Access;3. Source Code Repository – Git;4. Documentation – Microsoft Word 2010 and Adobe Acrobat5. Testing – Jasmine6. Build and Deploy – Gradle

All source code will be written using spaces versus tabs, and committed only after successful completion of relevant unit and integration tests. Any builds not conforming to this standard must be rolled back to the prior Git commit hash, fixed, verified with automated testing, and pushed forward to the repository. This commit will also include information specifying why the error was made, what was done to correct the action, and actions to be taken in the future to prevent it from occurring again.

Each build associated with a milestone in the project schedule will be built using automated build processes in Gradle, and supplied to the customer outreach liaison for discussion, demonstration and user acceptance testing. Failure to provide a timely build for the customer liaison will result in an internal review to address any concerns associated with the issue.