Steve_Gubenia_SDP

2014
Stephen Gubenia
Developed for CMIS 330 Dr. Almarzooq
12/7/2014
Software Development Plan
(SDP) for John and Joan Bed &
Breakfast

i
Table of Contents
1. 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. Overview
The 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 Summary
1.1.1 Purpose, Scope, and Objectives
The 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
guarantees
2. 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 product by the agreed upon delivery date.
Product requirements are listed in the BBRMS Software Requirements Specification.

2
1.1.2 Assumptions and Constraints
For 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 Deliverables
The 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
guarantees
2. 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. References
The BBRMS project management plan references the following documents:
1. Software Development Plan (this document);
2. Software Requirements Specification
3. Software Design Document;
4. Software Test Specification.

3
3. Definitions
Term Definition
Agile A lean development strategy to manage requirements based on an iterative
method
Git 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 requirements
Verify Building the product to function correctly and efficiently.
Waterfall A linear method of project management and software development.
4. Project Organization
This 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 Interfaces
The 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
Customer
Project
Manager
Customer
Outreach
Liaison
Developers
User
Experience
Specialist
BBRMS Development Team
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.
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:

5
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.
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.

6
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 Plans
This 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 Name SDLC Task Category SDLC Sub-Task
Form Teams Analysis BusinessAnalysis
Initial CustomerEngagement Analysis BusinessAnalysis
IdentifyCustomerNeedsand High-Level Requirements Analysis Software Analysis
DevelopMilestones Analysis BusinessAnalysis
Define Budget Analysis BusinessAnalysis
DevelopRequirements Design Software Analysis
DeliverandDiscussSoftware Requirements
Specification Analysis BusinessAnalysis
Software DesignReview Design Software Design
Create Software DesignDocument Design Software Design
DeliverandDiscussSoftware DesignDocument Analysis Software Design
Create Software TestingSpecification Design TestDesign
DeliverandDiscussSoftware TestingSpecification Analysis BusinessAnalysis
BuildCalendarQuery Services Code Service Development
BuildCalendarQueryGUI Code Interface Development
BuildUserInformationServices Code Service Development
BuildUserInformation GUI Code Interface Development
Produce Initial UserDocumentation
Code
Documentation
Development
BuildandPackage Alpha(v0.1) Code Software Build
Release 0.1(Alpha) Code Software Build
Initial UserAcceptance Engagement Test User Testing
BuildRoomReservationDomainObject Code Data Development

7
BuildRoomReservationServices Code Service Development
BuildRoomReservation GUI Code Interface Development
BuildPaymentDomainObject Code Data Development
BuildPaymentServices Code Service Development
BuildPaymentGUI Code Interface Development
BuildGuestReservationDomainObject Code Data Development
BuildGuestReservationServices Code Service Development
BuildGuestReservation GUI Code Interface Development
Produce ExtendedFunctionalityUserDocumentation
Code
Documentation
Development
BuildandPackage Beta (v0.5) Code Software Build
Release 0.5(Beta) Code Software Build
Mid-PointCustomerEngagement Analysis BusinessAnalysis
Mid-PointUserAcceptance Engagement Test User Testing
BuildReservationScanningServices Code Service Development
BuildDatabase ConnectivityServices Code Service Development
Produce Final UserDocumentation
Code
Documentation
Development
BuildandPackage Final (v1.0) Code Software Build
Release 1.0(Final) Code Software Build
Final CustomerEngagement Analysis BusinessAnalysis
Final UserAcceptance Engagement Test User Testing
Deliveryof Product(BBRMSv1.0 and Documentation) Code Software Build
Figure 2. Master Work Schedule
5.2.2 Schedule Allocation
Figure 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 retesting will ensure that the final stages of
integration and user acceptance testing go smoothly.

8
Figure 3. Gantt chart for Project Schedule

9
5.2.3 Resource Allocation
Before 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 projecttime 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 weeks for development is

10
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 Plan
The 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 Model
The 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 Department of Defense (DoD) model for
government acquisition planning with lean development phases. This model helps to achieve

11
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 Acrobat
5. Testing – Jasmine
6. 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.

Steve_Gubenia_SDP

More Related Content

What's hot

Similar to Steve_Gubenia_SDP

Steve_Gubenia_SDP