University of Texas at Dallas

CS 6361 – Requirements Engineering, Section 001 Fall 2007

Meeting Scheduling System

CS 6361 – Requirements Engineering, Section 001

Fall 2007

Name Email Phone Student ID

Russell Smith rss061000@utdallas.edu 972-278-2580 11126187
Jose Perez jperez@utdallas.edu 972-423-3161 10271422
Joshua Wu nike284@gmail.com 469-449-4672 11174269
Eric Anderson ejona86@gmail.com 361-443-8677 10496083
Daniel Qi qi_dapeng@hotmail.com 469-360-4323 11155733
danielqi@utdallas.edu
Elodie Mambounou ecm071000@utdallas.edu 919-539-8348 11162346
Le Qiao (Joe) qiao127@missouristate.edu 417-429-6932 11170695
Arturo Saracho axs067000@utdallas.edu 972-839-9730 11120701
Liga (Li-Chia Kuo) Liga.ling@gmail.com 469-426-9146 11106264

http://www.utdallas.edu/~rss061000/
Project Development Plan 1.0 (Delivery 0)

-1-
 University of Texas at Dallas
CS 6361 – Requirements Engineering, Section 001 Fall 2007
Revision History
Version Date Comments Author
1.0 Aug 24, 2007 Initial Version. Includes team A. Saracho
members, deliverable milestones,
introduction, tools, project organization
summary, risk analysis, monitoring and
controlling mechanism. Details on
method, tools, techniques and software
documentation are also included.

-2-
 University of Texas at Dallas
CS 6361 – Requirements Engineering, Section 001 Fall 2007
Table of Contents

INTRODUCTION............................................................................................................................................6
1.1 PROJECT OVERVIEW.......................................................................................................................6
1.2 PROJECT DELIVERABLES................................................................................................................6
1.3 REFERENCES..................................................................................................................................6
1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS...........................................................................7
2 PROJECT ORGANIZATION.............................................................................................................8
2.1 PROCESS MODEL............................................................................................................................8
2.2 ORGANIZATIONAL STRUCTURE......................................................................................................8
3 MANAGERIAL PROCESS.................................................................................................................8
3.1 MANAGEMENT OBJECTIVES AND PRIORITIES................................................................................8
3.2 ASSUMPTIONS, DEPENDENCIES AND CONSTRAINTS......................................................................9
3.2.1 Feasibility.................................................................................................................................9
3.2.2 Acceptance Criteria.................................................................................................................9
3.3 RISK MANAGEMENT....................................................................................................................10
3.4 MONITORING AND CONTROLLING MECHANISM..........................................................................12
4 TECHNICAL PROCESS...................................................................................................................12
4.1 METHODS, TOOLS AND TECHNIQUES...........................................................................................12
4.1.1 Methods..................................................................................................................................12
4.1.2 Tools.......................................................................................................................................13
4.1.3 Techniques..............................................................................................................................13
4.2 SOFTWARE DOCUMENTATION.......................................................................................................13
5 WORK ELEMENTS, SCHEDULE AND EFFORT........................................................................13
5.1 WORK BREAKDOWN STRUCTURE................................................................................................13
5.2 CRITICAL PATH ANALYSIS...........................................................................................................14
5.3 Effort and Cost Analysis..............................................................................................................14

-3-
 University of Texas at Dallas
CS 6361 – Requirements Engineering, Section 001 Fall 2007
List of Tables

TABLE 1. RISK REGISTER................................................................................................................................10

TABLE 2. PROBABILITY MATRIX.....................................................................................................................11
TABLE 3. FUNCTION POINT ANALYSIS............................................................................................................15
Table 4. Function Point Conversion Factor....................................................................................................14

-4-
 University of Texas at Dallas
CS 6361 – Requirements Engineering, Section 001 Fall 2007
List of Figures

FIGURE 1. RISK FACTOR CHART.....................................................................................................................11

FIGURE 2. WORK BREAKDOWN STRUCTURE..................................................................................................14
Figure 3. Critical Path.....................................................................................................................................14

-5-
 University of Texas at Dallas
CS 6361 – Requirements Engineering, Section 001 Fall 2007
1 Introduction

1.1 Project Overview

This document details the software planning activities for meeting scheduling
system. The software will reside on a computer server and will execute the
functionality to satisfy the requirements of the system. The high level
functionality of the system is:
 <Add functionality overview using bullet points>

This project plan includes details as well about feasibility, critical path, risk
analysis, cost analysis, development environment, acceptance criteria and
budget.

1.2 Project Deliverables

Date Deliverable
August 30, 2007 Preliminary project plan
September 27, 2007 Interim project 1
October 11, 2007 Final project 1 submission
November 8, 2007 Interim project 2
November 21, 2007 Final project 2 submission

1.3 References

[1] Lawrence Chung, Requirements Engineering syllabus, CS 6361 section

001, Fall 2007. http://www.utdallas.edu/~chung/RE/syllabus.htm
[2] Bernd Bruegge, Allen H. Dutoit, Object-Oriented Software Engineering
using UML, second edition. Prentice Hall, 2003.
http://wwwbruegge.in.tum.de/OOSE/
[3] Kathy Schwalbe, Information Technology Project Management, Thomson
course technology, 2006.
[4] William Roetzheim, Estimating Software Costs.
[5] David Longstreet, Function Points Analysis Training Course,
SoftwareMetrics.com, October 2004.

-6-
 University of Texas at Dallas
CS 6361 – Requirements Engineering, Section 001 Fall 2007

1.4 Definitions, Acronyms and Abbreviations

Cf Consequence of Failure
EI External Inputs
EIF External Interface Files
EO External Outputs
EQ External Queries
EV Equivalence Value
IDE Integrated Development Environment
ILF Internal Logical Files
LPF Linear Productivity Factor
Pf Probability of Failure
PF Penalty Factor
GUI Graphical User Interface
SDP Software Development Plan
SLOC Source Line of Code
SOW Statement of Work
SRS Software Requirements Specification
SWA Software Architecture Document
SWT Software Test Document
WBS Work Breakdown Structure

-7-
 University of Texas at Dallas
CS 6361 – Requirements Engineering, Section 001 Fall 2007
2 Project Organization

2.1 Process Model

The process model to be used for this project is the Waterfall model with the
ability to accept change; i.e., we will be able to provide feedback to earlier
phases and change documentation based on new information acquired during
the present phase.

2.2 Organizational Structure

The team is formed of nine members:

Name Responsibilities
Russell Smith Final Project II - Lead
Jose Perez Final Project I - Lead
Joshua Wu Interim Project II - Lead
Eric Anderson Final Project I - Lead
Daniel Qi Interim Project I - Lead
Elodie Mambounou Interim Project II - Lead
Le Qiao (Joe) Interim Project I - Lead
Arturo Saracho Project Plan and Traceability - Lead
Liga (Li-Chia Kuo) Final Project II - Lead

3 Managerial Process

3.1 Management Objectives and Priorities

The project must be completed by the deadline of November 21 st, 2007; this
includes complete documentation (all supporting documents must be updated
with feedback from other phases already included), and code in the functional
state and fully tested. The completion of all deliverables is equally important for
the success of the project; at the end of the project, a functional system must be
delivered that will allow for the scheduling and control of meetings. The
individual phase leaders must make sure all team members follow the guidelines
for the corresponding phase and that they finish their work on time.
The general guidelines for the different deliverables are:

 The deliverable leader is responsible to gather all the work from everyone
else and put it together in a formal document.
 This document must be available for the group to review on the morning of
the day of the class that is one class before the due date. For example, if
we need to deliver on Wednesday, the document must be available on
Monday morning so that everyone has a chance to review before the class
on Monday and discuss any last changes after class.
 In the event of an emergency or something very important that will prevent
the lead from having this document on time, he/she must notify the group
a day before in the morning (in the case of the example, Sunday morning)

-8-
 University of Texas at Dallas
CS 6361 – Requirements Engineering, Section 001 Fall 2007
and I will create the document, unless someone else has a strong feeling
about doing it instead, then, he/she can do it.
 If any member cannot finish a part of his/her work on time, he/she must
notify the group as soon as possible so that someone else can take on
his/her part of the work; the lead must divide this member's work among
all other members.
 Everyone needs to comment (on Google document) on everyone else's
comments where there is a discussion on a topic where members have
different opinions; in the end, since this is a democracy; the majority that
agrees on a topic wins, and this shall be reflected in the formal document.
These comments must be available by 4:00 PM the day before the lead
must have the document ready. (In our example; Sunday at 4:00 PM).
This, so that there is enough time for the lead to put the document
together.
 Anyone who does not comment on any discussion by this time; forfeits
his/her right to do so.
 The lead will collect any final comments after class, after everyone has
reviewed the formal document and everyone agrees on all topics. He/she
will make any changes necessary and upload to the Google group site
before the due date so that it can be uploaded to the website on the due
date.
 The lead is also responsible to bring a printout of the deliverable on the
due date to class for submission.
 In the case that the lead will not be able to attend class on the due date,
he/she must notify the group and the overall manager will print out the
document and deliver, unless he/she cannot make it either, then, a
volunteer must be found to do this.

3.2 Assumptions, Dependencies and Constraints

3.2.1 Feasibility
The technologies being used to develop the project are well known by most of
the team members. Such technologies are divided into: the process to follow for
the development of the software project, the language to be used, which is
chosen to be <language>, and the compiler/IDE <IDE>. However, there are a
few members in the team that have little exposure to these technologies. We
have a high confidence that this will not be an issue since these members are
highly experience in other similar technologies.

3.2.2 Acceptance Criteria

The software release will be tested according to the test plan. The test plan will
contain a section with all the test cases that have to be executed on the code and
that have to be passed in order to determine that the software is ready to be
released for use by the customer. At the same time, test cases must be
developed that verify functionality, not just against requirements (which test what
should be the expected behavior) but also to make sure that unexpected

-9-
 University of Texas at Dallas
CS 6361 – Requirements Engineering, Section 001 Fall 2007
behavior will not happen. As well test cases that verify against non functional
requirements will be developed.

3.3 Risk Management

The following items have been identified as potential risks for the project:
1. Testing phase shows some of the test cases failed. This is an issue as
there will not be enough time to make corrections to the code.
2. Legal risks. If the system fails to provide the tools necessary for the
scheduling and control of a critical meeting.

The risk register is shown in the following table. This table shows the details
about each one of our risks.

Table 1. Risk Register

Potential Risk
No. Rank Risk Category Root Cause Triggers Probability Impact Status
Responses Owner
Increase the
development time Code
Make sure the development to
Not enough unit
design reflects the be started
Testing Technology testing.
Small development requirements and immediately after
R1 1 phase is risk, financial Code PM Medium High
time. these are clear. the design is
failed risk implementation is
Perform enough finished. Test
not completed.
unit testing as plan will also be
progress is made in started.
coding.
Ensure that
PM to monitor
Product is released validation properly
and control the
for production with covers the
The device communication
Market risk, inadequate customer's and
R2 1 Legal malfunctions in the PM Low High between
Financial risk validation or with internal
field technical staff
known working requirements and
needed to be
issues provide enough
involved
time for testing
Clairfy all
Software
Product fails requirements from
Product does not developers to
to provide Market risk, Requirements are customer. Make
R3 1 schedule meetings PM Low High maintain regular
desired Financial risk unclear sure they
as expected meetings with
functionality understand they
clients
needs

The probability matrix indicates that the highest impact risk are both the failing of
the testing phase, and the legal risk, however, the failing of the testing phase is
the overall highest risk since the probability of occurring is higher.

In order to provide a better argument, the probability of failure (Pf) and

consequence of failure (Cf) attributes are used to show the risk factor. The risk
factor is calculated using the following formula:

Risk _ Factor   Pf  Cf    Pf  Cf 

The Pf value for our project is: 0.7 [3] since we have never done this before, it is
somewhat complex and there is at least another program that has to be

- 10 -
 University of Texas at Dallas
CS 6361 – Requirements Engineering, Section 001 Fall 2007
interfaced (mapping). The Cf value is: 0.2, since there are a few know
alternatives in terms of development approaches, we are between 90% and
100% confident that the architecture chosen will met the initial operational
capabilities, we are confident it will reduce the life cycle cost, and we are highly
confident that it will reduce the downtime factor.

Table 2. Probability Matrix

Probability

High

Moderate R1

Low R2, R3

Low Moderate High

Impact

The risk factor gives us a value of 0.76, which falls just barely above the medium
risk category, and into the high risk category. The following table shows this risk
factor in a chart.

Figure 1. Risk Factor Chart

Having analyzed the risks for our project, we have determined that we can bring
the overall risk of the project down as we have contingency plans in place that
we are working on such as the early start of the code, early start of the test plan
and increased unit testing.
In order to meet the delivery date we have agreed that we will integrate all the
classes that are coded, which satisfy all design and requirements, but we will
make the necessary modifications to make all the modules work together, even
though these modifications will not be reflected in the documentation for this
initial prototype delivery. Proper changes to the documentation will be done for
the next delivery that will include changes needed per finding in the coding and
integration phases.
The lack of a software version control system makes it difficult for the integration
of the system, and especially in this project where there are nine different
developers. This could also affect the quality of the system in order to be on time
for the delivery.

3.4 Monitoring and Controlling Mechanism

Each delivery phase will be lead by the corresponding phase lead. This person
will initiate activities by:
 Providing details of each member's responsibilities for the phase, the due
dates for individual work, and meeting time and place for review of final
draft document.

- 11 -
 University of Texas at Dallas
CS 6361 – Requirements Engineering, Section 001 Fall 2007
 He/she will deliver an initial framework to be used as a base for other
members to complete their part of the work.
 Receive and compile the individual work of all team members, as well as
own, and send back for review.
 Receive review comments from team members, generate a final draft and
send to team members for discussion during team meetings. (Team
members must review this final draft before the meeting).
 An agenda is to be sent to the team and to the TA, indicating the time and
place for the meeting and the items for discussion.
 Meet with team to discuss the final draft. Record minutes during the
meeting and distribute to team and TA after meeting has been finalized.
 Generate final delivery phase document with inputs from meeting, upload
to website and print out a copy for delivery during class on due date.

4 Technical Process

4.1 Methods, Tools and Techniques

4.1.1 Methods
Traceability is required between phases and documentation. In order to achieve
this, explicit details of relationships between items in documents between phases
has to be documented. This will be done using the following strategy:
 Each requirement will be numbered inside a corresponding section in the
SRS.
 The analysis document and the SWA will specify the design and analysis
as well as the architecture details stating what requirement(s) is(are) being
satisfied by the specific solution(s).
 As well the code should contain comments that provide traceability back to
the requirements, analysis, and architecture documents.
 The test plan and test cases will also contain references to the previous
documents, as well as to the code.

4.1.2 Tools
The following tools are to be used for the development of documentation and
code:
 The code development languages: <language>.
 The IDE used is <IDE>.
 <Database> is used for Database implementation.
 Documentation is to be done using Microsoft Office tools.
 A website is to be available that serves as repository for the deliverables.
 A working group using Google groups is to be available for discussions
and communication between team members.
 Jude is used for the design of UML diagrams.

- 12 -
 University of Texas at Dallas
CS 6361 – Requirements Engineering, Section 001 Fall 2007
4.1.3 Techniques
The software development will be used following a naming convention and a
specific structure approach, and will be common between all members; this
naming convention will be the well known Hungarian notation.

4.2 Software Documentation

The following software documents will be developed:
 Software Development Plan (This document)
 Requirements Specification – Lists the requirements from the customer as
understood by the development team. (This document must be reviewed
with the customer and agreed upon).
 Analysis – Contains the high level analysis of the system.
 Architecture Specification – Explains the system’s architecture.
 Component Specification – Details the individual software components
and their interactions.
 Code – The software.
 Test Plan – Gives a detailed description on the approach to be used to test
the software.
 Test Cases – Individual and detailed instructions to verify functionality of
the software against the requirements.
 Test Report – Gives an overview of what tests were done and the outcome
of these.

5 Work Elements, Schedule and Effort

5.1 Work Breakdown Structure

The project is to be developed within two months. All team members will
participate in all the activities. The project lead for each delivery will distribute
the work among these members.
The WBS is developed following a sequential order of events with their details,
such as subtasks, and indicating how much time it is expected to be needed for
their execution.

Figure 2. Work Breakdown Structure

5.2 Critical Path Analysis

The following figure shows the critical path for the project. The total time needed
to complete the project is the sum of the days necessary to complete each task
that is in the critical path (showed by the bold lines).
By following the critical path we have a total development time of 40 working
days.

Figure 3. Critical Path

- 13 -
 University of Texas at Dallas
CS 6361 – Requirements Engineering, Section 001 Fall 2007
5.3 Effort and Cost Analysis
The following table shows the function point analysis for each of the modules in
the software, this is used to create the WBS and obtain the critical path(s) for the
project. The linear productivity factor for web software is 2.51 and the
exponential size penalty factor is 1.030. The SLOC per function point for
<language> is <value>. [4]

To start estimating function points we have to determine the number of external

inputs (EI), external outputs (EO), external queries (EQ), internal logical files
(ILF) and external interface files (EIF). We calculate the number of each one of
this metrics for each software module and multiply each value times its
conversion factor. The conversion factors are shown in the following table:

Table 3. Function Point Conversion Factor

Raw Type Conversion
Factor
EI 4
EO 5
EQ 4
ILF 10
EIF 7

The total function points are calculated adding the EI, EO, EQ, ILF and EIF
columns for each software module, then adding these totals to obtain the total for
the project. The Effort is calculated using the following formula:
PF
 EV  FunctionPo int s 
Effort  LPF   
 1000 

Where LPF is the linear productivity factor, the EV is the equivalence value and
PF is the exponential size penalty factor.

Table 4. Function Point Analysis

Function
SW Module EI EO EQ ILF EIF Effort Cost
Points

Total

- 14 -
 University of Texas at Dallas
CS 6361 – Requirements Engineering, Section 001 Fall 2007
The function-points analysis shows that we need <value> man months to finish
the code.

- 15 -