Software Project Management Plan (SPMP)
Software Project Management Plan (SPMP)
Project : Recruitment Solution Agency( RSA)
Supervisor: Shyresh Patel
Team: Shining stars
NAME
CONTACT NO
EMAIL
Uma Bharti Rana
0416987781
[email protected]
Poonam Sen
0430717000
[email protected]
Anmoldeep Singh Gill
0468315056
[email protected]
Amy Zheng
0424676155
[email protected]
Mohammed Nasser Alzuabi
0413242552
[email protected]
Bilawal Ansari
0416793134
[email protected]
Table of Contents
41) PURPOSE
41.1 Purpose of this SPMP
41.2 Project Aims
41.3 Client Information
52) INTRODUCTION
52.1 Project overview
52.1.1 Purpose, Scope and objectives:
52.1.2 Assumption and Constrains
62.2Project deliverable
62.2.3 Project Organization
72.3 Definitions
72.4 Acronyms
83) ROLES AND RESPONSIBILTIES
83.1 Roles
93.2 Responsibilities
154) MANAGERIAL PROCESS PLANS
154.1 Project Start –up Plan
154.1.1 Estimation plan
174.1.2 Resource Acquisition Plan
184.2 Control Plan
184.2.2.1 Procedure for internal reviews
194.2.2.2 Procedure For external review
194.2.2.3 Quick reference sheet:
194.2.3 Reporting plan
204.2.4 Meeting Procedure
214.3 Risk Management plan
225) TECHNICAL PROCESS
225.1 Development Methodology
225.1.1 Agile model
245.2 Configuration Management
255.3 Version Control
255.4 Programming Languages and Software Tools
265.5 Tools and Techniques
265.6 Design Tools
265.7 Testing
275.8 Test Procedures
285.9 Documentation standards
295.10 Software Test Plan
295.11 User Manual or Documentation
295.12 Project Acceptance Plan
305.13 Project Milestones
305.14 Approval Process
316) WORK PLAN:
316.1 Work Activities
336.2 Work Breakdown Structure
336.2.1 Initialization:
346.2.2 Planning
346.2.3 Design phase
356.2.4 Development phase
356.2.5 Implementation
356.2.6 Closing of the project
366.3 Gantt Charts:
387) References
1) PURPOSE
1.1 Purpose of this SPMP
The purpose of this Software Project Management Plan (SPMP) is
to detail the standards, practices, tools, and techniques the team
will use during the development life cycle of this software
product. The team is the intended audience for this document.
1.2 Project Aims
This project is aimed at creating a complete system for the RSA
which will include database, designing, documentation of the
website.
1.3 Client Information
The client names is Anna damos, CEO of the RSA (Recruitment
Solution Agency), it is located in far north of Melbourne, Vic, and
provides the staff to different sectors.
Contact info
2) INTRODUCTION
The Purpose of this document is about the project assign to
students group. The main objective of this project is to assess the
students’ different skills, which they have acquired through
learning of different subject during their relevant degree. This
project is about to designing a website for a recruitment agency,
which facilitate all the major stake holders such as the employees,
recruiters and staff. The client has specifically asked for few
demands which will be met during the project and there will be
continuous client feedback on the progress and needs of this
project.
2.1 Project overview
Project overview will include its objectives, scope and
constrains.
2.1.1 Purpose, Scope and objectives:
Purpose: The purpose of the project is to develop a website
which should be fully functional, apart from that it also needs
documentation, database to handle with proper skills.
Scope: The scope of the project covers the core requirements
details in SRS. And it will help the client to achieve all the
desired features and function as requested.
Objective: The main requirement of the Client is that the
product be time-effective, in that
the Client wishes to have minimal interactions with the
interface in order to produce desired results.
2.1.2 Assumption and Constrains
· There will be multiple users of the system being developed and
that will be used on different pc and laptops or mobile
devices.
· The client has stipulated that security is not a major issue
of concern however simple login functionality is required.
· There is a time constraint on the project in that it must be
completed by the June 2013.
· The project development is constrained to the resources
available at the ATMC Melbourne, as well as those owned by team
members.
Assumptions
-
-
-
-
-
-
-
Constraints
-
-
-
-
-
-
2.2 Project deliverable:
The deliverables of the project are as follows:
· Software Project Management Plan. (SPMP): It will include the
outlines of the project and people involved and details process and
guidelines to be followed right through the project.
· Software Requirements Specifications. (SRS): It will include
details about the functional and non function requirements given by
the client.
· Software Architecture Design Document. (SADD): It will include
the architecture design of the entire system.
· Software Design Document. (SDD): Contains an in-depth design
of the software, including use-case, collaboration, sequence and
class diagrams.
· Test Plan. (TP): Details the types of tests to be carried out
on the system to ensure the system meets requirements and maintains
integrity.
· Source and Object Code: The main deliverable of the project
which allows the client to run the required system.
· User Manual: Details how the system runs and instructs the
user in how to install and use the product.
2.2.3 Project Organization
2.3 Definitions
Copied – I told you many times that plagiarism will not be
tolerated. Most of you are masters students and we do not expect
this.
· Core requirements - Requirements which are necessary for the
system to meet Client's requirements.
· Optional requirements - Extra functionality which will be
implemented if possible
· Task Sheet - One A4 sheet (created from the _le tasksheet.txt)
in which a team member writes the week's tasks and fills in time
taken during the week.
· Touts - A project management tool used mainly for task
allocation and tracking.
2.4 Acronyms
· PC - Personal Computer
· SPMP - Software Project Management Plan
· SRS - Software Requirements Specification
· SADD - Software Architecture Design Document
· SDD - Software Design Document
· ROLES AND RESPONSIBILITIES 6
· GUI - Graphical User Interface
· UML - Unified Modeling Language
· CVS - Concurrent Version System
· TP - Test Plan
· SQAP - Software Quality Assurance Plan
· UD - User Documentation
· PM - Project Manager
· CLO - Client Liaison officer
3) ROLES AND RESPONSIBILTIES3.1 Roles
Roles
Team Member
Project Manager
Uma Rana
Client Liaison officer
Uma Rana
Risk Manager
Anmoldeep Gill
Design Architect / Designer
Uma Rana, Bilawal, Amy
Quality Assurance Manager
Amy , Nasser
Backup Manager
Poonam Sen, Anmoldeep Gill
Programmer / Database Manager
Poonam Sen, Anmoldeep Gill
Testing & Tester
Bilawal, Nasser
Documentation
Uma Rana, Amy
Researcher
Bilawal, Nasser
Mail Manager
Uma Rana , Poonam Sen
3.2 Responsibilities
There are many errors in this section. Write your own
responsibilities. Simply put down what will you be doing in the
project. For example, you DO NOT have to research on what are the
duties of PM. Just write down what will you be doing as A PM for
this project.
Role: Project Manager
Team member: Uma Rana
· The Project Manager is the person responsible for
managing and ensuring that the Project team completes the
project.
· He is able to identify and reduce risks involved, gather the
initial requirements and prototyping organize communication with
the client as needed and with the team members effectively, towards
the development of the project. (Babou, 2008)
· The Project Manager develops the Project Plan With the team
and manages the team’s performance of project tasks. It is also the
responsibility of the Project Manager to secure acceptance and
approval of deliverables from the Project Sponsor and stakeholders.
To be available for team members to see when there is a problem
within the group.
· The Project Manager is responsible for communication,
including status reporting, risk management, escalation of issues
that cannot be resolved in the team, and, in general, making sure
the project is delivered in budget, on schedule, and within
scope.
· The Project Manager is the person responsible for
accomplishing the project objectives within the constraints of the
project. He is responsible for the Outcome (success or failure) of
the project.
· The Project Manager is involved with the planning, controlling
and monitoring, and also managing and directing the assigned
project resources to best meet project objectives. Time, scope,
cost and quality managements are some of the major task that is to
be performed by the Project Manager.
· Conducting meetings with the team members of the project
timely and clearly deciding the project to be implemented out of
the given choices, gathering information regarding the initial
requirements, motivate the team to enhance productivity, assign the
individual task to the team members, conducting general
administrative duties and monitor the work done and goals to be
accomplished.
Team Role: Client Liaison Officer
Team member: Uma Rana
· To arrange meetings with the client.
· To regularly update the client on the progress of the
project.
· Either via email or during a client meeting.
· A liaison officer is responsible for ensuring communication
and cooperation between two or more entities by serving as an
official go-between between top-ranking officials of each
organization.
· To notify the team members of the client's needs.
· Communicate their name and contact telephone number to all
client departments affected by the contract.
Team Role: Risk Manager
Team member: Anmoldeep Singh Gill
Responsibilities
· Organizations, especially larger entities, have recognized the
need to better understand their exposures and means of covering
their exposures.
· A risk manager will determine all of a company's exposures,
determine if insurance or Self-insurance is appropriate and
coordinate loss control.
· The person in the project with the overall responsibility,
accountability and Authority for ensuring that the risk management
process is applied effectively.
· To suggest possible solutions for problems arising within the
team.
· Excellent communications and presentation skills, to be able
to inform and persuade both orally and in writing. This means
excellent written and spoken English.
Team Role: Requirements Engineer
Team member: Nasser, Amy
Requirements Engineer is a term which is often used
interchangeably with the IT Business Analyst though many people see
this role as being limited to requirements gathering and
documentation. The reality is that there are no industry standards
for the scope of the requirements engineer. The requirements
engineer is charged with working with the project stakeholders and
end users to elicit, understand, analyse, and document the
requirements for a system in order to solve a given business
problem.
Responsibilities
· To ensure that the specifications are well documented.
· Requirement engineer is presented as the first phase of the
development process.
Team Role: Quality Assurance Manager
Team member: Poonam Sen, Amy
A quality assurance system is said to increase customer
confidence and a company's credibility, to improve work processes
and efficiency, and to enable a company to better compete with
others. Quality assurance was initially introduced in World War II
when munitions were inspected and tested for defects after they
were made. Today's quality assurance systems emphasize catching
defects before they get into the final product
Responsibilities
· QAS should be punctual in meetings and conferences.
· QAS should listen to team members and make them feel that
he/she is also in the team.
· QAS should keep good documentation of what each of your team
doing and remind them their responsibilities and
deadlines.
· Get to know the system so QAS can talk in and out when needed
in meetings, both with superiors and also with sub-ordinates.
· Research, study, evaluate and implement quality assurance
practices in compliance to company's best practices.
Team Role: Design Architect / Designer
Team member: Uma Rana, Amy, Bilawal
· Developing website architecture and content development is
also a big responsibility in web designing because content is the
soul of a web page or website.
· Web designing and development involve lot of programming work
similar to software development. Preparing flowcharts, diagrams,
tabulation of the client's requirements and documentation are the
major duties and responsibilities in web designing.
· Good communication skills are also required for web
designing.
· To ensure the design is thorough and easily implemented by the
Programming team.
· Visual communication is a reality as soon as a word is typed,
a colour chosen, or a text displayed on the screen, and any visual
expression, whether it is intentional or not, communicates
something to the visitor of the site. The Web designer can never
bypass the effects of graphic design elements.
Team Role: Backup Manager
Team member: Poonam Sen, Anmoldeep Gill
· He/she should able to backup whole system and create recovery
records.
· Backup Manager should be able to recover system in critical
stages or whenever required.
· He should kept record of all documents and files developed by
project team.
Team Role: Programmer / Database Manger
Team member: Poonam Sen, Anmoldeep Gill
· Supply design and development projects on time and within
budget.
· Help in preparation and documentation of program requirements
and specifications.
· Analyse and resolve software errors accurately on time and
provide required status reports.
· To perform code inspections on regular basis.
· Develop programming procedures and documentation and Assist in
development and maintenance of user manuals and guidelines.
· Design, develop, test, document and debug logical and
mathematical software through data processing equipment.
· Review program performance and data input and output and
remedy discrepancies appropriately.
· Programmer / software engineer should be able to implements
and code according to design provided and do testing along the way
to ensure that the implementation meets the design.
Team Role: Testing & Tester
Team member: Bilawal, Nasser
· Software testing is any activity aimed at evaluating an
attribute or capability of a program or system and determining that
it meets its required results.
· Software testing is a methodology to find bugs in the
software.
· Software testing is the most important phase in any software
development project, so that we can know whether our project or
product is going to be successful or it will fail before it goes
live.
Broadly software-testing levels are categorized into three
levels.
· Unit Testing: Unit testing in this phase of testing, separate
units of software system are tested. This is also known as
component testing in which each module is tested alone to find any
error in its source code. Programmer performs this testing as part
of the development life cycle. The prerequisite for this phase is
unit test plan, which should be written from low-level design
document.
· Integration Testing: Integration testing this testing is done
to test the communication between different components of the
software; all the modules that a program comprises are being bring
together to test whether they are functioning in correct order with
their counterpart. Modules are typically integrated in a top-down,
incremental fashion.
· System Testing: System testing this level of testing is done
to test the functionality of software as a complete system. System
testing is entirely different then integration testing. In
integration testing interaction of component are tested while in
system testing interaction of complete software with the system is
tested. Besides system functionality and behaviour, system testing
may include testing configuration, throughput, security, resource
utilization, and performance.
Team Role: Documentation
Team member: Bilawal, Amy, Uma Rana, Nasser
· Documenter should have knowledge of all formal documents.
· Should choose the right way to produce the user manual.
· The Communication Strategy should articulate the extent and
nature of communications involved in the project.
· Documentation should be kept to make some changes in the
project.
Team Role: Mail Manager
Team member: Uma Rana
· To ensure email is utilised efficiently by team members for
communication purposes.
· To ensure all team members utilise email tags correctly.
· To contact a team member if an email requiring a reply is not
replied to within 24 hours.
Team Role: Web Page Maintainer
Team member: Anmoldeep Gill
· Upload web page when some changes are made to project Web
Site.
· Able to write current news and affairs on website.
· To ensure web page is up to date.
· Able to modify file on web repository or server.
4) MANAGERIAL PROCESS PLANS
4.1 Project Start –up Plan
4.1.1 Estimation plan
4.1.1.1 Schedule: The schedule is entirely based on the due
dates given to us by the university or the client. The dates will
be adjusted according to the deadlines of the client or university.
The team will finish all documents at least 7 days before the due
date given by the university or client. The schedule also includes
the items which are not supposed to be delivered but are necessary
for the entire project. The schedule is subjected to change due to
change in the client requirements or earlier delivery requests.
4.1.1.2 Resources Requirements: Resources will be selected on
the basis of the skills, knowledge and previous experience of the
entire teams as well as the on the requirements of the client.
Management and technical practices are the other factors which
effect the selection of the resources.
4.1.1.2.1 Technical Resources
· Touts
It is the software which will be widely used by the PM (Project
Manager), to allocate different tasks. Group members will be able
to indicate that how much they will need to accomplish a specific
task. And it would be easy to divided work equally rather then
putting burden on one.
· Development methodologies
Other thing which will be considered will be which methodology
will be use in the development of the project.
· Programming language
In order to deliver a successful online browser based system, it
is required a considerable amount of programming to be completed.
The language which we will be using will be Html, PHP, JavaScript
and CSS.
· CVS
CVS is a software which will be used to keep records of changes
to both documents and codes. It is known as version control
software.
· Procmail
This is used as a filter to mails so that they should not be
mixed up. Procmail is a mail delivery agent (MDA) capable of
sorting incoming mail into various directories and filtering out
spam messages. Procmail is widely used on Unix-based systems and
stable, but no longer maintained users who wish to use a maintained
program are advised to use an alternative MDA, such as mail
drop.
· Hypermail
Hypermail will be used to create different html links to emails.
Hypermail is a free (GPL) program to convert email from Unix mbox
format to html.
· Home page
It will contain all the mails and links to all the documents
related to project.
· Development programs
Smart draw, Microsoft frontpage, HTML, MYSQL, Php, Mysql
database server.
4.1.1.2.2 Written resources
· Textbook
· IEEE Standards
· Online website: w3 school
4.1.2 Resource Acquisition Plan
4.1.2.1 Technical Resources: It will include all the softwares,
methodologies, programming languages which we are going to use in
development of the project.
4.1.2.2 Written resources: For written resources we will go
through some different books as there are unlimited numbers of
books available in the library or online journals. By going through
different books best one will picked according to needs and options
will be changing as requirement will change.
4.1.2.3 Staff training plan
Team members will be provided with some time to learn about the
resources, software, and hardware to make them more efficient and
multi skilled. So that we always have a backup for any sickness or
illness.
4.2 Control Plan
Control plan explain the steps or control procedure that will be
used by the team members to measure, report, and control the
product requirement, schedule, budget and resources of the
project.
4.2.1 Requirement and Schedule Control Plan
This includes all the requirements given by the client, and they
will be further divided by core or noncore requirement. On the
basis of that a schedule will be designed to accomplish all these
core and noncore requirements with specific time frame.
4.2.2 Quality Control Plan
Quality Assurance manager will be responsible for quality
control.
4.2.2.1 Procedure for internal reviews
Steps
Person involved
Request of an internal review
Team, document manger, PM
Conduct team review
Team member
Review the documents in a specific time frame
Team members, PM, Reviewer
Hard copy of documents reviewed
Reviewer
Hard copy submitted to document manger
Document manager
Amendment of the soft copy
Document manager
Disagree (conduct meeting with team)
Document manager
Agree( Hard copy kelp safe )
Document manager
4.2.2.2 Procedure For external review:
· Copy of documents will be send to the client
· Each part will clear and explained
· If approves, then start working forward
· In case of unapproved desired changes can be made and again
reviewed by team and client.
4.2.2.3 Quick reference sheet:
Quick reference sheet will be a guide for all the team members.
It will contain all the contact details of the team members, file
permission protocols and email tags. It will allow all the team
members to follow the processes without continual check of SPMP. A
soft copy can be quick reference sheet can be achieved from PM /
general folder in case any team member lost his own.
4.2.3 Reporting plan:
It involves management of documentation and maintains
communication. It tells the team what to while a problem occur and
how to tell others and overcome that specific issue.
4.2.3.1 Email
Email will be the preferred way to contact each other for any
reason. Each team member will be supposed to check their official
(University student emails) emails two to three times a day. The
emails tagged as urgent or important will need to be sorted as soon
as possible or within 24 hours. Response to each email will be
necessary and mandatory.
4.2.3.2 Procmail and Hypermail
· The mail manager will save all the filtered with Procmail in a
spate mailbox with appropriate tag. Email tags are to be used at
the beginning of the subject field of the email. Tags can be as:
SADD, SRS, Code, SPMP, SDD, Design, Risk, Meeting, Client,
Process.
· Once a week , the mail manager will use the Hypermail to
create html versions of the mails and place them in
· The Manager will ensure that the links to the mail on the team
web page are up to date.
4.2.3.3 Task sheet
· Task sheet will be used to distribute task in the project
meeting. Each team member will have their own task sheet given to
them PM.
· Each member will be responsible for their each and individual
task to be written on the task sheet.
· Copy of each task sheet with estimated time of completion by
each team members will be given to supervisor and PM.
4.2.4 Meeting Procedure
4.2.4.1 Team Meetings
· Team meeting will be held every Monday at 4 pm with supervisor
in ATMC Melbourne campus in room 2.4. The place is subjected to
change according to the needs.
· Each and every team member must attend this meeting without
any excuse.
· Team meeting within the group members will be held between 5-6
pm every Monday in ATMC Melbourne. Presences of each member will be
compulsory
· In case of more work the no of group meetings will be more
than once a week.
· Meetings with the client will be held once every two weeks and
it can be changed as per needs. Only client liaison and minute
taker will attend this meeting.
4.2.4.2 Agenda
Agenda for the group will be decided by the team members in the
previous meeting or it can be send by PM through email to all team
members two days before the meeting.
4.2.4.3 Meeting minutes:
Minute taker will take minutes of each and every meeting. It
will be taken by hand first and then later transcript into
computer.
It will include the following things:
· Open
· Attendance
· Agenda
· Items discussed
· Schedule check
· Close of meeting
4.3 Risk Management plan
This part will have all the methods and procedures that the team
has to follow in case of any risks. It will involve the
following:
· Unrealistic schedule or Budget
· Real time shortfalls
· Capability Shortfalls.
· Wrong Functionality
· Wrong Functionality
· Personal Shortfalls.
5) TECHNICAL PROCESS
This section specifies the technical methods, tools, and
techniques and methodologies to be used to develop the required
project. It also includes identification of the work products
and reviews to be held and the plans for the support group
activities in user documentation, training, software quality
assurance, and configuration management. Technical Process Plan of
a project is refers to what project activity we will do before we
start it. Planning mechanisms have served project managers well in
planning for their projects. However, a complete, realistic,
accurate and up to date plan before major work on a project is
initiated is often missing (Carnegie Mellon University, 2012).
5.1 Development Methodology
After researching the positive and negative attributes, and the
overall concept of each of the software development methodologies,
it came up to agile methodology which may be a preferable method
for this small project and where time is determining constant.
5.1.1 Agile model
Agile software development is a group of software development
methods based on iterative and incremental development, where
requirements and solutions evolve through collaboration between
self-organizing, cross-functional teams. It promotes adaptive
planning, evolutionary development and delivery, a time-boxed
iterative approach, and encourages rapid and flexible response to
change. Software is developed in small batches, changes can easily
be introduced into the software product.
Agile approach tries to define an overall system plan quickly,
develop and release software quickly, and then continuously revise
the software to add additional features. In our project we will
examine how the values, principles and practices of agile
modelling, including extreme programming (XP), shape the
development of our system. The most important of the principles is
customer satisfaction by giving rapid and continuous delivery of
small and useful software. The delivery of the software happens at
regular intervals may be on weekly basis. In our project, the aim
is to test from the perspective of the customer as early as
possible in the development process.
Agile development Process
Agile modelling seizes on the opportunity to create models which
can be logical models such as drawings of systems or mock-ups such
as the prototypes described by the client’s needs.
Agile project life cycle
Iterations
As according to given diagram, customer reviews the completed
phase and gets immediate feedback. Agile software development
processes are built on the foundation of iterative development.
Since the software is developed in small batches, changes can
easily be introduced into the software product. Agile processes use
feedback, rather than planning and these feedbacks are driven by
regular tests and releases of the evolving software.
The development team gets more details about the requirements to
be developed from the customer. They develop and test that piece of
software, then deliver it to the customer, and iteration completes
here. At the beginning of next iteration the customer gives the
feedback and prioritizes the remaining requirements and the same
cycle is repeated again. This loop goes on until the customer is
satisfied with the software they have and there are no more
requirements from the customer. All these factors become software
qualitative and efficient (Agile Methodology Essay 2, 2012).
XP teams create and monitor their own iteration plans in
collaboration with the customers. The customer creates stories and
prioritizes them based on their business value. Extreme Programming
improves this software project in five essential ways;
communication, simplicity, feedback, respect, and courage. Extreme
Programmers communicate with their customers and fellow programmers
and get their feedback. They implement suggested changes and
deliver the system to the customers as early as possible. The
developers divide up the tasks themselves as they work and measures
progress for each iteration (Ambler, 2002).
5.2 Configuration Management
Our team for Configuration management (CM) establish and
maintain the consistency of software's performance, functional and
physical attributes with its requirements, design and operational
information throughout its development life. It also called change
management whose purpose is systematically controlling changes to
the configuration and maintaining its integrity and traceability
throughout its development life cycle.
Configuration Manager makes sure that the version management of
code and documents can be done with ease and in a correct manner.
Configuration Management also saves time and money by giving
management precise visibility and therefore improved control over
an evolving complex system. It also improves the traceability of
changes in the team’s work. Team is used Version control system for
configuration management (Configuration Management, 2013).
5.3 Version Control
Version control, also known as Revision control is used for
changes to documents, computer programs, large web sites,
and other collections of information. In our project the
version control will do the following functions:
· Developers can create projects for collaborative development
using the version control.
· Recreating the older versions of web pages when needed.
· Identifying which version a file is.
5.4 Programming Languages and Software Tools
Programming Languages
The basic thing to achieve a successful website is programming.
The most commonly used language for the coding of a web site is
HTML. So in the project the languages can used for coding are HTML,
PHP, CSS, JavaScript programming.
· HTML stands for Hyper Text Mark-up Language is the main
mark-up language for creating web pages and other information that
can be displayed in web browser. It can embed scripts written in
languages such as JavaScript which affect the behaviour of HTML web
pages.
· PHP is a server-side scripting language, especially suited for
the creation of dynamic web pages. This programming language offers
our web developers a large selection of instruments. PHP allows
easy insertion in HTML code and connection to MySQL Databases.
· CSS stands for Cascading Style Sheets. It defines how to
display HTML elements. External Style Sheets can save a lot of
work. External Style Sheets are stored in CSS files. It is used to
separate the layout from the content.
· JavaScript (JS) is an interpreted computer programming
language. It was originally implemented as part of web browsers so
that client-side scripts could interact with the user, control the
browser and alter the document content that was displayed.
5.5 Tools and Techniques
The following tools and technologies can be used for the
project, however it can be changed depending on which can be best
for this project.
Different software tools
· Adobe Dreamweaver: This editor will be used for coding.
· Microsoft Windows 7 /XP/Vista: These platforms can be used
during the development phase.
· Concurrent Version System or Subversion: It will be used to
maintain version control.
· Entity Relationship Model: It will be used for the database
design.
· MySQL Database Server or Wamp server: It will be used for
running and storing database in sql.
· MS Project: it will be used to make Gantt Chart.
5.6 Design Tools
· Enterprise architecture: ER design tool can be used for
drawing the diagrams. It is easy to use and all the team members
are familiar with it. It can be used to draw any use case diagrams,
sequence diagrams, Collaboration diagrams, Entity relationship
diagrams and UML diagrams.
5.7 Testing
Testing is an important phase in every software development
process. It involves the testing of the system against the
requirement specification and successful running of the developed
system. According to our accepted methodology for software
development, testing should be done after completion of every
phase. Testing is done by our testers in point of view of user
perceptions and changes are made according to the needs. The
testing phase involves testing of developed system using various
kinds of data. While testing, errors are noted and corrections are
made. The correction is noted for future use.
5.8 Test Procedures
All coding produced will be tested systematically in various
ways to ensure the integrity of the system. All test cases that are
generated must be stored in the Testing folder, with clear
documentation of the scope, date and the results of the test. In
development procedure testing will be done by following phases:
5.8.1 Unit Testing
Unit tests are one of the corner stones of Extreme Programming
(XP). But unit tests XP style is a little different. We will create
our tests first, before the code. Unit testing will occur when
a module is completed to ensure its functionality. A summary of the
modules test result (PASS/FAIL) along with a description of any
errors, will be kept in the Testing folder (Unit Testing,
1999).
5.8.2 Integration Testing
Integration testing is a logical extension of unit testing. In
its simplest form, two units that have already been tested are
combined into a component and the interface between them is tested.
Integration testing identifies problems that occur when units are
combined. By using a test plan that requires you to test each unit
and ensure the viability and compatibility of each before combining
units (Integration Testing, 2003).
5.8.3 Acceptance Testing
This testing requires to verify that it complies with the
client's requirements. Acceptance tests are created from user
stories. The user stories selected during the iteration planning
meeting will be translated into acceptance tests. The customer
specifies scenarios to test when a user story has been correctly
implemented (Acceptance Tests, 1997).
5.8.4 Verification and Validation testing
Verification testing involves reviews and meeting to evaluate
documents, plan, code, requirements and specifications. This can be
done with check lists, issue lists, walk through, inspection
meetings and reviews.
Validation testing involved actual testing. This can be done
after the verification is completed. Validation succeeds when the
software functions in a manner can be reasonably expected.
5.8.5 Security testing
Security testing is required to protect data and maintains
functionality as intended. It will be covered confidentiality,
integrity, authentication, availability, authorization and
non-repudiation.
5.9 Documentation standards
For documentation plan, team will follow The Institute of
Electrical and Electronics Engineers (IEEE) standards for all
documentation purposes. All the documents would be discussed and
reviewed with supervisor before their baseline versions are issued
and distributed to the members of RSA project. All the team members
will follow the standards of throughout the project development.
The necessary documentation for the website will be the development
plans, code scripts making the website pages and applications,
legal compliance and corporate registration certificates,
procedural and organization documentation for the website (IEEE,
1998).
Software Documentation
Documentation is an important part for this project and the
types of peer reviews to be held for these projects. Documents must
be good quality and reviewed by project manager to get them
approved. In this documentation plan provides a summary of project
schedule, methodology and resource requirements.
There are a number of documents that will be produced during the
lifetime of the project. All documents are responsibility of the
project team members.
To ensure that the implementation of the software satisfies the
requirements, the following documentation is required as a
minimum:
Software Requirements Specification (SRS)
It is the first document after SPMP, which specifies all client
requirements of proposed project. It is a complete description of
the behaviour of a system to be developed. In addition it also
contains non-functional requirements. To derive the requirements we
need to have clear and thorough understanding of the products to be
developed. This will prepared after detailed communications with
the project team and RSA organisation (Software Requirements
Specification, 2006).
Software Architecture Design Description (SADD)
An SADD is a document used to specify system architecture and
application design in software development process. The SADD is
created by the System Architect or designer and is the major
deliverable from the detailed design process. The SADD describes
the major components of the software design including databases and
internal interfaces. The architecture design will decompose the
system to three levels.
5.10 Software Test Plan
The Software Test Plan will be a document specifying a
systematic approach to testing the RSA system software at all
levels of development. The test plan also describes the test
procedures, test cases, and test results that are created during
testing activities. This document will be used to verify and ensure
that a product or system meets its design specifications and other
requirements. A test plan is usually prepared by or with
significant input by our tester team.
5.11 User Manual or Documentation
User manual or User Document will be a technical communication
document intended to give assistance to our user for using and
handling of our proposed system. It will describe and instructs the
user how the system runs and use the product which may include some
screenshots.
5.12 Project Acceptance Plan
Every milestone of the project will be accepted by the clients
by signing appropriate acceptance documentation. At the end of
every phase the client will install the product and perform an
acceptance test. It may result in additional requests for change
and improvements.
5.13 Project Milestones
A milestone is the beginning of a new phase or the completion of
an important deliverable. After completion of software development,
it is tested and the software is to be delivered to the client by
the 1st week of June 2013.
Milestones
Due Date
Planning
Tues, April 2nd, 2013 - 17:00
(Week 3)
Designing
Fri, April 19th, 2013 - 17:00
(Week 5)
Coding
Sun, May 10th, 2013 - 17:00
(Week 8)
Testing
Fri, May 24th, 2013 - 17:00
(Week 10)
Test report
Fri, May 31st, 2013 - 17:00
(Week 11)
5.14 Approval Process
This form is required for submission of projects for approval to
the ATMC and RSA group. This process will involve a review of
software by all the team members and the team supervisor. After
successfully completion of acceptance test by our client it will be
approved for delivery. This process will check the following
factors:
· All core functional and non-functional requirements are
implemented.
· Product is Complete on time.
· It successfully completion all acceptance tests by clients by
real data.
6) WORK PLAN: 6.1 Work Activities
· Software Project Management Plan (SPMP). The SPMP will specify
the technical and managerial processes necessary for the project.
During this step, a detailed timeline and schedule will be
prepared. The timeline will contain dates of commencement and
completion of each phase of the development. In order to be
successful the team must deliver a software product that will
satisfy the needs of the client, and during the project the goals
of the team are considered and achieved whenever possible. For
example, deliver a product that is stable and relatively
defect-free, deliver a system that addresses the client’s needs,
meet client and team deadlines etc. If changes need to be made
during the process of the project, the SPMP need to be altered and
copies will be distributed to all team members, client and
Supervisor.
· Software Requirements Specification (SRS). Following the
approval of the SPMP, the SRS will be developed to meet the
requirements for all three levels of our client. Technical
requirements for the system will also be determined. These
requirements will be published on the SRS. The document must be
completed and agreed upon by all parties by the end of April 2013
(Project team and client) before moving onto the design phase. Once
signed by the client the SRS will under go no alterations.
· High level architecture. Towards the end of the SRS
development, the High level architecture design will begin. The
interface will be designed using the Programming Language PHP. Once
the interface is designed, the data will be stored in Tables and
Schemas which the team will create using MySQL. Major functions
that will be provided by the system include: logging into the
system, storing registrant information. The developers of the SRS
will inform the architectural designers of any late major changes
in the SRS that could affect the design.
· Low level architecture. When the High level architecture is
near completion and SRS finalised, the low level architecture
design can begin. For the design of the website, it needs to meet
all requirements of the client, such as the colour, the font and
the structure. During this step, no coding may occur until the
document is completed but the document may be changed during the
coding and testing phase of the project.
· Software Architecture Design Document (SADD). Once both the
high level and low level architecture design is completed, it will
be compiled into the SADD. A design of the system will be produced
based on the requirements agreed upon in the SRS. The detailed
design will be published in the SADD. The final version of the SADD
must be agreed upon by all team members and our client before the
design can be implemented.
· Test Plan. The Test Plan formation will begin just after the
start of the SADD. During this phase, the Test Plan will be
developed. The Test Plan contains detailed plans and descriptions
for various test cases. The tests will be performed as specified in
the Test Plan. Test case results will be published and documented
in the Software Test Report. These documents will need to be
reviewed and approved by the client. Once completed it will
continue to be altered throughout the remaining lifetime of the
project development.
· Coding of core functionality. Coding of the core functionality
can begin once the SADD is completed and agreed upon. Coding will
follow the plans set out in the SADD.
· Testing of core functionality. Testing of the core
functionality will be done continually throughout the coding
period. All tests will be contained within the guidelines set out
by the Test Plan.
· Coding of extra functionality. Once the code functionality is
completely coded and tested, the team will discuss which extra
functionality time allows to be coded and thoroughly tested. Only
these extra sections will be attempted.
· Testing of extra functionality. The testing of extra
functionality will be done as outlined in the Test Plan. A function
will not be included in the final package if testing is not
completed.
· Compilation of project for final submission. A period of time
will be allocated towards the end of the projects development to
compile all documents and code together into the deliverable
package.
6.2 Work Breakdown Structure
S .No
Name of Task
Duration
Date of Initiation
Date of Completion
1
Initialization
7 day
19/03/2013
25/03/2013
2
Planning
14 days
26/03/2013
09/4/2013
3
Design Phase
13days
09/04/2013
22/04/2013
4
Development Phase
35days
22/04/2013
27/05/2013
5
Implementation
7 days
27/05/2013
03/06/2013
6
Closing the Project
1 day
03/06/2013
03/06/2013
6.2.1 Initialization:
S. No
Initialization
No of days
dd-mm-yy
dd-mm-yy
1
Choosing the Role of Project Manager
1
19/03/2013
19/03/2013
2
Building up the Project Team
2
20/03/2013
21/03/2013
3
Charter of Project (RSA)
76
19/03/2013
03/06/2013
4
Requirements of client
4
19/03/2013
25/03/2013
6.2.2 Planning:
S. No
Planning
X days
dd-mm-yy
dd-mm-yy
1
Collection of client requirements for the project
2
26/3/2013
28/03/2013
2
Creation of standard documentations required for the
project(SPMP)
12
28/03/2013
09/04/2013
3
Identification of critical areas and risks involved in the
project
12
28/03/2013
09/04/2013
4
Providing reasonable solutions to mitigate risks and critical
areas identified earlier
12
28/03/2013
09/04/2013
6.2.3 Design phase
S. No
Design
X days
dd-mm-yy
dd-mm-yy
1
Designing templates to meet the requirements of the client
7
09/04/2013
15/04/2013
2
Collecting client feedbacks and suggestions on draft designs
2
15/04/2013
16/04/2013
3
Designing the final login and logout template for the RSA.
7
16/04/2013
22/04/2013
6.2.4 Development phase
S. No
Development
X days
dd-mm-yy
dd-mm-yy
1
Defining deliverables of project management
7
22/04/2013
29/04/2013
2
Developing Prototype
28
29/04/2013
27/05/2013
3
Developing code
28
29/04/2013
27/05/2013
4
Statement of Scope
28
29/04/2013
27/05/2013
5
Structuring work breakdown
28
29/04/2013
27/05/2013
6.2.5 Implementation
S. No
Implementation
X days
dd-mm-yy
dd-mm-yy
1
Implementation of Algorithm
7
27/05/2013
03/06/2013
2
Documentation of Deliverables
7
27/05/2013
03/06/2013
3
Testing of code to highlight any errors
7
27/05/2013
03/06/2013
4
Getting Scope Statement
7
27/05/2013
03/06/2013
6.2.6 Closing of the project
S. No
Close Out
X days
dd-mm-yy
dd-mm-yy
1
Assimilating all project related documents
1
03/06/2013
03/06/2013
2
Preparation of the Final Project
1
03/06/2013
03/06/2013
6.3 Gantt Charts:
Gantt charts showing our work breakdown structure.
a) Schedule and Initialization
b) Planning and Design Phase
c) Development, Implement and Closing phase
7) References:
Agile Methodology Essay 2, (2012). Retrieved 2012, from
http://www.oppapers.com/essays/Agile-Methodology-Essay-2/545183
Ambler, S. (2002) Agile Modeling: Effective Practices for
Extreme Programming and the Unified Process. New York: Robert
Ipsen.
Unit Testing. (1999). Retrieved from
http://www.extremeprogramming.org/rules/unittests.html
IEEE. (1998). Standard for Software Project Management Plans.
California: IEEE Computer Society Press.
Software Requirements Specification (SRS). (2006). Retrieved
2006, from
http://searchsoftwarequality.techtarget.com/definition/software-requirements-specification
Acceptance Tests. (1997). Retrieved from
http://www.extremeprogramming.org/rules/functionaltests.html
Integration Testing. (2003). Visual Studio .NET. Retrieved 2003,
from
http://msdn.microsoft.com/en-us/library/aa292128(v=vs.71).aspx
Configuration Management. (2013). Retrieved from
http://www.chambers.com.au/glossary/configuration_management.php
Terasoft, Inc., (2004). Software Project Management Plan (SPMP)
for Nirvana National Bank ATM Software Project. UAE: Nirvana
National Bank.
Risk Manager. (2012). Retrieved Aug, 2012, from
http://www.prospects.ac.uk/risk_manager_job_description.htm
Project manager. (2011). Retrieved Oct, 2011, from
www.epa.gov/fedfac/pdf/rpm_roles_responsibilities.pdf
Project Manager Roles and Responsibilities. (n.d.). Retrieved
from
www.finance.alberta.ca/business/alternative-capital-financing/Appendix-C7-Project-Manager-Roles-and-Resp.pdf
Software testing. (1999). Retrieved from
http://www.ece.cmu.edu/~koopman/des_s99/sw_testing/
Requirements Engineering. (2004). Retrieved from
www.cs.toronto.edu/~sme/papers/2004/FoRE-chapter01-v7.pdf
Project Manager
Uma Rana
Quality Assurance Manager
Amy
Amy
Uma Rana
Client Liaison Officer
Uma Rana
DBA
Anmoldeep
Researcher Nasar
ProgrammerPoonam, Anmoldeep
Designer
Uma, Amy
Risk Manager
Anmoledeep
Uma Rana
DocumentaterUma, Amy, Bilawal
Uma Rana
Tester
Bilawal
Assistance Documentater
Nassar
Uma Rana
Planning
Reg. Breakdown Automation
Iteration Schedule
Testing
Automation
Functional
Manual
Implementation
Design/Coding
Pair programming
Feedback
Demonstration
Retrospect
Development
Cycle
Page | 26
7602 Project – SPMP, Team - Shining Stars
