Project plan
Javier Baro
Israr Ahmed
Student of MSc. in Software Engineering
Blekinge Tekniska Hogskola
SE-37225, Ronneby, Sweden
Student of MSc. in Software Engineering
Blekinge Tekniska Hogskola
SE-37225, Ronneby, Sweden
jaba07@student.bth.se
issh07@student.bth.se
Nattakarn Phaphoom
Josef Hardi
Student of MSc. in Software Engineering
Blekinge Tekniska Hogskola
SE-37225, Ronneby, Sweden
naph07@student.bth.se
ABSTRACT
In this paper, we present our own perspective about the definition
of a plan for a particular software development project. This
perspective is based on several main characteristics like: formal,
agile, process based and dual complementary perspective. It is the
beliefs of this development team that formality it is not a synonym
of bureaucracy. For the achievement of the final goal in any kind
of software development project: delivery of the final product in
time, under budget with the adequate resources and with the
quality levels required by our customers, some kind of formality
is required. But, formality applied in an agile way. By agile, this
development team wants to express the idea of selecting and/or
defining, customizing and applying the right processes to fit the
management and development requirements of the project in a
dual a complementary perspective. By dual and complementary
perspective this team wants also to express their view that
separating the management and development processes in a
complementary way, we can expect the achievement of one of our
main concerns that is to maintain the project under control. So we
will be able to know in any time the real state of the works
undertaken to the final achievement of the goal.
Categories and Subject Descriptors
K.6.3 [Software Management]: Software development
General Terms
Software development, software process.
Keywords
Software project plan, software project management method,
software project development method, software processes, PMP,
PMI, Unified Process, Agile Unified Process.
1. INTRODUCTION
In this paper we describe the personal decisions undertaken by the
software engineering team in the context of academic
environment in order to produce a software project plan for a
practical example. Section 1 is the introduction to the context of
our project. Section two is the assumptions introduced to the
premises of the practical example. In Section three, the dual
perspective of management and development is introduced. In
Section 4, the details of the project management methods are
Student of MSc. in Software Engineering
Blekinge Tekniska Hogskola
SE-37225, Ronneby, Sweden
johw07@student.bth.se
explained. In Section 5, the selection of the software development
method is provided and finally in Section 6, the main conclusions
achieved by the team were elaborated.
2. ASSUMPTIONS
The following assumptions have been considered for this project
in particular:
The overall budget for the project is 60.000 €
The salary for each one of the roles involved in the project is:
Project manager: 600 € / day
Analyst: 350 € / day
Developer: 250 € / day
The software required for the management, development and
execution of the project belongs to the infrastructure of the
company and we do not have to care about this.
3. DUAL PERSPECTIVE PROCESS
For our team, the overall development of the product was split
into two different but related models- project management method
and software development method. The reason for this division
was to separate the management concerns, more related with
scope, time, cost and resources management, from the pure
development concerns which are more focused on the
functionality, the creation of artifacts, and the implementation of
the software. Both models should not be seen as independent
models. They both interact each other so that the pure
development activities, tasks and the artifacts, produced as a result
of the execution, are managed both by the development processes
themselves, and also, by the management processes in all the
aspects related with scope, time, cost, resources, etc. As we
mention in the abstract of this paper, the main objective of this
dual perspective is the control of the project for the deliverance of
the right product, in time, under budget and with the quality
required by our customer.
4. PROJECT MANAGEMENT METHOD
In this project, two different approaches for project management
process, traditional and agile process, are considered as
alternatives. The first one characterized in the form of the Project
Management Process (PMP) method from the PMI [1] and the
second one characterized in the form of the Scrum method. The
following advantages and disadvantages have been identified.
Table 1 PMP
Advantages



Disadvantages


Advantages
Disadvantages

PMP is the only formal model that the
team members having experiences. It is a
risk to learn a new model in limited time.
It is a well-known model, proposed by
people from industries with standard
practices and implemented worldwide.
It provides a good control about the
impact of changes along the life cycle.
The formality has been proposed could
also be seen as a disadvantage, because
the project has to elaborate and produce a
number of deliverables within time
constrain.
Since it is a process oriented method, the
project are going to expend time selecting,
defining, etc. not only implementing the
software.
Table 2 Scrum
The simplicity of the process, the way it
provides value to all stakeholders and the
scalability it offer makes it very attractive
methodology to choose[2]
It provides control mechanism for project
release as it is designed for iterative
development.
The team members do not have
experience and/or knowledge and training
is required.
According to the advantages and disadvantages, the following
decision has been taken. The agility approach is promising, but its
less formality is concerned. So although we were conscious about
the great effort required, we proposed to choose the PMP as the
project management method to use. The project minimized the
impact of the process formality by limiting the number of
processes to the minimum required for an adequate plan,
execution, control and closing of the project.
4.1 Project management processes
The followings are the selected processes: team motivation and
communication, scope, scheduling, quality and risk. To all these
PMP processes we added another one more process called change
control. It is added as a new independent process to remark the
importance given to the overall change control of the project.
4.1.1 Team motivation & Communication
In any kind of a software project, the persons are the most
important resources over processes and tools. How persons
interact each other and the level of commitment with the project
are two of the key factors for project success. That is the reason
why we decided to include this process in the project.
4.1.1.1 Team motivation
The team members came from different backgrounds and culture.
According to Expectancy theory, it can be said that our members
have different needs and goals. In order to understand each other
needs and goals we decided to develop several formal meeting
groups for team cohesion. In those meetings the team members
were also agreed according to Goal-setting theory that each one
was going to have the responsibility over some different aspects
of the project. We split mainly in three: meeting goals and
responsibilities, management goals and responsibilities and
development goals and responsibilities. Each member of the team
has to assume a different role at each time of the project. The
different roles are: for meetings: leader, facilitator, chronometer
and quality. For management: scope and scheduling, quality, risk
and change control and finally for development: requirements,
design, deployment and the team are going to assume the role of
developers. These roles are not permanently assigned so each one
of the members has the freedom to satisfy their own needs and
expectancies at every time of the project.
4.1.1.2 Communication
For communication purposes, the team was agreed that the
meeting is the fundamental tool for group communication. The
main objective with these meetings is that each one of the team
members has the opportunity to participate in the decisions and
also receive feedback from the other team members. One
important aspect when dealing with communication is how to
solve the conflict situations that will arise. Because in an
academic perspective we do not have the possibility to establish a
hierarchical structure, all the conflicts should be resolved in a
completely cooperative way. Based also in the concept of role, the
techniques chose for conflict resolution was altering the team
structure. By this way we can limit the influence of some
members on situations of conflict in decisions taking.
4.1.2 Scope
Following activities were undertaken for the project plan.
4.1.2.1 Scope statement
The project scope was established as: “Develop a software mobile
phone application for uploading and downloading images to and
from Internet”.
Inside the scope of the project, sub-activities are: image format, an
installable application, interface with the mobile phone virtual
machine, interface with the server side, browse between the
images stored in the server file system.
Outside the scope of the project are: deal with how the image
comes to the mobile phone, how the user download our
application, how or when the VM is installed, how to deal with
the mobile phone Operating System, manage the file system in the
server, develop web browser functionality, develop
communication protocols (HTTP, HTTPS, FTP).
In order to deal with scope, we used a technique called WBS
(Work Breakdown Structure). The reason for using this technique
in particular is because WBS allows a better overview of the
overall scope of the project. Applying this technique through a
process of decomposition provides better definition of the project
scope.
4.1.2.2 Scope control
The team agreed in the definition of a formal process of change
control to the project’s scope. As a result of this agreement, for
scope control we decided to define a Change Control Board
(CCB). The main responsibility of the CCB is to control the
changes to the scope baseline. Only trough formal petitions to this
board, one of the team members is allowed or not to do a change
to any one of the documents or artifacts under “base line”. More
information about the CCB and the change control process is
elaborated in the change control management process.
4.1.3 Scheduling
One of the most important activities in the project planning phase
is scheduling. By scheduling we can understand the definition of
the activities and tasks of the project, their sequence and the
estimation of their duration. The first step in project scheduling is
the identification of all the activities and tasks inside the scope of
the project, usually through the application of the WBS technique
introduced in the scope statement. For us the application of this
technique is considered as a very important step, only by the
rigorous decomposition of our project into smaller tasks, we will
reach the objective of obtaining a better management and control
of the project. The WBS we have done in this project in particular
has been represented in a hierarchical tree and transferred to a
Gantt chart and developed enough detail in order to transit
smoothly to the following phase that is product identification.
In product identification, the objective is to compile a list of the
products or deliverables that are going to be produced as a result
of, at least, the main activities. With this list we were able to
produce the PBS (Product Breakdown Structure). In this case our
objective was the compilation of all the important products for our
project. Once the PBS was developed, we were able to further
identify from the whole list of documents the ones that are going
to constitute the milestones of our project. This list is also very
important for us because only through the control of the
intermediate products or deliverables, we will be able to guarantee
the quality levels required by our customers.
In parallel, once the main activities were identified, we were also
able to begin a series of other activities like: identification of the
resources required by our project. These resources were compiled
in a RBS (Resources Breakdown Structure)and establishment of
the sequence of the activities and works. The tool chosen for this
network establishment has been network diagrams, in concrete,
the precedence diagramming method (PDM), technique that
uses rectangles connected by arrows to show the dependency of
activities within the project. The main reason for adopting this
technique is because we used Microsoft Project and is the only
technique supported specifically in this tool for network
diagramming. From the four possible tasks dependencies available
in this technique, we chose the finish-to-start dependency type,
because it is the most recommended technique when the project is
oriented to ongoing development like our project is.
Once the definition and sequencing of the activities were
established or, at least, well known, we began to assign resources
to those activities. In order to do so, we needed to do some
estimation about the size of the activities in order to assign the
correct number of resources for their fulfillment. The estimations
were done in first step in size applying the technique of Function
Points and then translated to lines of code (SLOC) in order to do
the cost estimation by applying the technique of COCOMO II.
We chose both techniques because both are well known and
proved techniques in the software community and also because
there are some public available estimation databases that we can
use for our own estimation purposes.
Once the effort required was known, we finally were able to
assign resources to each one of the different tasks. As a result of
this cross between tasks and resources, the responsibility diagram
matrix was done in order to have a visual representation in tabular
form of the different tasks to execute and the person responsible
for its execution.
Finally, all these data about time, resources and cost were also
transferred to the Gantt chart in Microsoft Project. With this last
document we close the responsibility circle: Process-ActivitiesWorks-Products-Effort-Resources-Cost.
4.1.3.1 Scheduling analysis
One important decision when dealing with scheduling is the
decision about when the techniques can be performed once the
resources has been assigned. The technique we chose for this
important aspect was critical path method (CPM). This technique
helped us to identify the project’s critical path by determining the
longest path through all the works in a project that can be done in
the shorter time.
4.1.3.2 Scheduling control
The project team decided to have closely control over project
schedule because limited project execution phase is considered as
primary concern. Schedule control allows us to see variance
between current situation and the project plan. Therefore proper
corrective actions (e.g. scope refinement, activity reassignment)
can be taken in time.
The scheduling control technique chosen was: Progressing
Report. This technique presents the progress of activities
identified in project WBS. Our project used percentage of
completed work product as a measurement of project progress. In
order to present project progress we used Gantt chart as the base
template for inserting percentage of work done. The reason of
using Gantt chart, instead of WBS, is that Gantt chart presents not
only project activities in hierarchy, but also includes starting date,
duration, and planned finish date. It reminds the responsible
person both the remaining work and remaining duration, so (s)he
can effectively plan to get everything complete in time.
There are two worthy reasons to generate progressing report
weekly. First of all, it helps us identify risky activitiesthat have
tendency to miss dateline, and second it represents performance of
team members..
4.1.3.3 Cost control
The cost control technique chosen was: Earned Value technique
(EVT). This technique was applied to control cost of the project.
EVT presents planed curve, actual curve, and earned value curve
in the same diagram.
There are several reasons of using EVT. First of all, it not only
allows us to see the cost variance between planned and actual
cost, but also predicts the overall cost when project completes.
Secondly, it connected cost control process to risk management.
This diagram provides earlier sight of problems. The analysis
result will be an input for risk identification process that we
adopted to the project as well.
Even there are other cost control techniques available, we selected
EVT because it is a standard technique that most of team
members have experiences and do not require more reading.
4.1.4 Project Quality Management
The objective of explicitly defining quality management process
in the project is to ensure quality of the work products that will be
delivered to customers and be internally used. It also ensures that
agreed procedures are well understood and followed by all team
members.
The feedback from work product inspections
represents the common mistakes and leads to process
improvements and staff development.
Quality management plays a crucial role in maintaining
completeness and correctness of deliverables, even though the
size of team is small and the project scope is very limited. This is
because it reminds the project team that the standard level of work
products need to be reached before delivered to the stakeholders.
Our project adopted 2 processes for quality management that is
quality assurance and quality control. We used work product
inspection for quality assurance and Pareto diagram for quality
control.
4.1.4.1 Quality assurance
Work product inspection is the method to review the documents
before submitted to the baseline or delivered to other stakeholders.
There are 3 levels of inspection that is self review, supervisor
review, and team review. The crucial documents need to be
inspected and given feedback by project manager, and
communicated to the whole team.
There are three reasons for adopting the inspection process. First
of all, we do not know background of team members. Some Agile
methods believe in competency of team member and the work
product is reviewed by its generators. This technique results in
fast and flexible development, but it can be risky in case that the
background of team member is unknown. Second, the inspection
ensures that the contents of document are validated and verified
by appropriated person. Therefore other member can refer to or
reuse the documents with confidence. Third, result of the
inspection shows the common mistakes and misunderstood issues.
These can be used as a guideline for improving processes and
staff training as well.
The only concern of inspection process is that it requires lots of
time to review all work products at team level. To avoid time
consuming, we decided to have 3 levels of inspection. The team
review is performed only for crucial work products (e.g. scope
statement, project management plan, project schedule).
Documents that are mainly use in one phase such as test plan can
be inspected by peer review. And other documents like a minute
of meeting can be inspected by self review.
The result of inspection is record in a defect form. It identifies
severity level, defect type, and injected phase. For further detail,
Table 3 shows the defect table.
Table 3: Defect Table
4.1.4.2 Quality control
By quality control our objective is to have a visual representation
of some of the results of the project. These results are compared
with the quality standards defined. As a result of this comparison,
we will be able to identify causes of our main problems. This
identification is considered also very important in our project
because it will serve as an input for other process, like risk
management process to identify the main risks we are facing in
our project at each time.
Refer to PMBoK, there are variety basic tools of quality (e.g.
Fishbone diagram, Control chart, Flowcharting). The technique
we chose for quality control was Pareto diagram. A Pareto
diagram represents the distribution of variables related specific
events. The height of column shows the frequency of the variables
and the curve, the accumulative sum of the frequency of all the
variables. Our project selected Pareto diagram to represent the
causes of common problems found in work product inspection
and causes of identified risk.
We considered Pareto chart the most appropriated tool for our
project for 4 reasons. First of all, Pareto diagram combines
characteristics of Fishbone chart, Histogram chart, and defect
review. All problem causes are presented and we can easily point
out the cause that created the greatest number of defects and fix it
first. Secondly, Pareto diagram is easy to be created and
understood comparing to other tools like Control chart. Thirdly, it
does not require a special tool to generate the diagram. Lastly,
team members are all experience in this technique. In order to
generate Pareto diagram, the input is defect list of work product
inspection process (showed in Table 3). Defect type, injected
phase and defect cause can also be used to present problem
characteristic in different perspective. We decided to create the
Pareto diagram once a week in project execution phase, in order to
implement proper corrective action (e.g. template adjustment,
process improvement).
4.1.5 Risk Management
The objective of the risk management is to make a plan for risk
management; which affect the cost, schedule and deliverables of
the project. In our project we had a number of risks, such as time
management, lack of knowledge, project complexity , error in
document generation and resource availability. All these risks
affect our goals and objectives. The scope statements and WBS
structure help to identify some of the risks.
Our project have taken constrains (e.g. time, members’
background) as pre existing risks. During project life cycle, new
risks might be discovered as a result from quality and control
processes. . Therefore, risk management processes are needed to
deal with them.
4.1.5.1 Risk Management Plan
The purpose of making a risk management plan is not only to
identify the risk but also to manage them in a proper way, so they
have a very little impact on project’s schedule and cost. In our
project we mainly focus on risk based on project scope statement
and work breakdown structure, but we will also have to identified
during execution or other activities.
In quality management, the work product inspection led the
discovery of risks; which will later be managed through project
management plan. Based on the information provided in the
project scope statement and WBS; the project manager called for
a meeting to manage the risk management plan for the project.
The attendees in the meeting are the development team. Plans for
risk management activities, risk responsibilities are defined. The
goal of making the risk management plan is to manage project
risks and to adopt a suitable technique. The activities to perform
during risk management process, technique, roles and
responsibilities regarding risk management, budget, time, risk
breakdown structure and other definition and recommendation to
rate when a risk occur all defined in the risk management plan.
4.1.5.2 Risk Identification
The identified risks were documented along with their
characteristics e.g. source of risk, risk impact, and description etc.
The participants in this activity include the project manager and
team member. The risk related to the project includes time
constraints, team member’s availability, lack of knowledge and
participation, resources, complexity of project, experience and
skills of team members.
The technique used for risk identification is Checklist. For our
project in particular, checklist was developed from the checklist
taxonomy proposed by the SEI. This checklist was applied to our
project based on the information and knowledge compiled from
the scope and the WBS mainly. Other techniques related to risk
identification are brainstorming, information gathering technique,
diagramming technique that focus on group meeting and building
diagrams respectively will consume time in handing risk
identification and may affect other project activities. The output of
the checklist is a risk register that are used for further activities of
this plan. The main advantages of using check list that it is
repeatable, comparable and cost efficient.
4.1.5.3 Risk Analysis
Qualitative risk analysis was performed to access and prioritize
the identified risks. The participants in the qualitative risk analysis
are the project manager, team member and the assigned risk
member. The risk register was reviewed and updated by the
project manager. The risk probability and impact assessment
technique used for the qualitative risk analysis. This technique
used group meeting. The main agenda of this meeting was to find
the level of probability for every risk; its impact and source were
evaluated. The level of probability and the impact were rated
based on the definition described in the risk management plan.
The reason for adopting this technique was the limitations and
lack of knowledge.
Decision tree analysis technique was performed in qualitative risk
analysis. The risk that was prioritizing earlier during qualitative
risk analysis was structured using decision tree analysis. The
purpose of this approach is to identify available choices and
scenarios. This technique will help to estimate cost at each choice
and the scenarios. This helped the development team to estimate
the right decision along with the cost.
4.1.5.4 Risk response Planning
To minimize risk threat and take necessary actions to resolve risk,
risk planning was adopted. The “strategy for both threats and
opportunities” technique was used to eliminate the risk from the
project. The rest of techniques for risk response either deal with
risk with potential positive impact or risk with negative impact.
The active acceptance strategy was adopted to establish
contingency reserve to handle risks and opportunities.
4.1.6 Change control management
The goal of change control management is to provide methods or
procedures for handling project changes in order to minimize
impact of the risks and consequently to help maintain the quality
and operations in the project.
4.1.6.1 Change Control Process
In our project, we will try to practice the change control
management for case that major changes is happened in the
project. In the process, the change control board or change
committee is the most important role in the system. The
committee responds for making decision whether or not to accept
change requests that are inevitable as project proceeds. For doing
the role, we agreed that the project manager is the chair of the
change committee. The team members brainstorm necessary
adjustment in scope statement, project plan (e.g. schedule,
resources) if changes are approved.
There are three reasons that our projects appointed a formal
change committee to justify change requests before implementing.
First of all, we want to prevent unnecessary and costly changes for
derailing project schedule. Second, we want to ensure that the
most appropriate solution is taken. And lastly, the impact of
changes that might affect personal schedule is acceptable by all
parties.
4.1.6.2 Configuration Management
The configuration management (CM) serves as the subset of the
change control management, which its purpose is to maintain the
evolving project products under control. Our primary concern in
this area is to provide the tool and the storage for every entity
produced during the software development project.
4.1.6.3 CM Tool
Two parts of CM is the software configuration management
(SCM) and the operational configuration management (OCM).
While SCM focuses on managing source code during
development, OCM focuses on managing the configuration items
(such as documentation and service definitions) within a project
management. In this project, we agreed to practice these two parts
of CM as integrated portion by using single management tool. For
that purpose, we selected Subversion as the configuration tool.
Regarding with the other CM tools option, we put notice on
Concurrent Versions System (CVS) and Subversion only. The
reason is because we want to exercise for tools that have been
widely used and known by the software development
communities. Furthermore, the comparison between these two
tools shows that Subversion has many useful advantages rather
than CVS. For example, the Subversion's atomic commits will
assure the data consistency in the system so the repository will
always stable. In this manner, persons who update their working
copy will never miss any changes left from the others' commits.
Another useful feature is that Subversion can also manage
changes of the binary files. This feature is very helpful because in
the project not only source code text will be maintained in the
system but also the documentations in binary format (i.e.
Microsoft Word document or Portable Document File), thus, the
project team will still be able to trace changes or find differences
between various revisions. For further details, Table 4 shows the
features summary for both CVS and Subversion.
Table 4: CVS and Subversion Features Comparison
CVS doesn't provide atomic
commits.
Subversion provides atomic
commits which mean a
collection of modifications
either goes into the repository
completely, or not at all.
CVS only tracks the history of
individual files.
Subversion
implements
a
``virtual'' versioned file system
so files and directories are also
versioned.
CVS doesn't support copy and
rename operations.
Subversion
supports
add,
delete, copy, and rename for
both files and directories.
CVS only supports text
(human-readable) files when
Subversion
differences
expresses
file
using a binary
sensing changes or tracing
differences.
CVS only uses its proprietary
protocol for the networking.
differencing algorithm, which
makes Subversion supports on
both text (human-readable) and
binary (human-unreadable) files
when sensing changes.
Subversion can also use another
network
protocol
as
an
extension (i.e. HTTP or
HTTPS).
There are also three another reasons Subversion became the
preference. First, Subversion is free open software. So, it is
obvious that the team does not need to spend hundreds or
thousands US dollar to purchase proprietary license. This gives
significant saving money for the overall project cost. Second,
Subversion has enough features to perform several important
revision control needs for the project. Third, some members in the
team are quite familiar with using Subversion and the remaining
has heard the usage of the tool. This initial knowledge helps to
speed-up the exercise using Subversion.
effective communication and understanding among the team
rather than creating tedious specification documents.
Regarding with the other software development models (SDMs),
we selected only the SDM that has a clear definition about project
management inside it. For several SDMs we have surveyed, the
project management process was not very clear and even
incomplete or ambiguous. For example, the extreme programming
does not define risk management process [3]. Another concern is
about the time constraint and the part-time dedication of the team
members to the project. For example, the waterfall model and the
spiral model is too tedious for the team to define everything in
advance and do prototyping. Table 5 shows the comparison
between the other software development models.
Table 5: Software Development Model Comparison
SDM
AUP
4.1.6.4 Repository Location
SVN repository is the product of implementing the Subversion
service. The repository can be accessed online through the
Internet and only the members of the team have the fully readand-write operation. Public members can get access but with
limited permission. The repository can be located using URL
address: http://photohand.googlecode.com/svn. All
incremental codes and documentations will be stored in this
repository.
5. SOFTWARE DEVELOPMENT MODEL
In the project, we used the Agile Unified Process (AUP). AUP is a
simplified version of the Rational Unified Process (RUP). AUP
describes a simple and understandable approach using agile
techniques and concepts yet still remaining true to the RUP
practices.
The reason AUP became the choice is because AUP provides a
clear structure for project management process and its
development process. AUP defines four phases and seven
disciplines to be followed by the team. And in Section 4 we have
covered the management process activities. For example, in the
Inception phase of AUP, the team covered almost all the project
planning processes, such as scope planning, time estimation,
budget allocation, human resource assignment, risk identification
and so on. Later in the Construction phase, the team will execute
the project based on the plan.
AUP works as an incremental and iterative approach that suitable
in our assignment's case. The benefit of this approach is it helped
the team to break down the tasks and grouped them into a single
iteration work. Later, multiple iterations recur to create a fully
integrated product.
AUP also proposes a small amount of deliverable artifacts. This
value of AUP fits with the time constraint that the team faced.
Thus, the team could have enough time on focusing to the
working code rather than on composing the documents. For
example, AUP can use other agile practices in order to have
XP
Advantages
Similar
to
RUP
characteristics,
AUP
has a clear define
phases and activities
AUP uses iterative and
incremental approach,
risk-driven model.
It is an agile approach
that oriented to change
management.
Spiral
Spiral defines several
project
management
activities
Waterfall
It is a simple process,
unidirectional
and
sequential flow.
Disadvantages
Hard to maintain the
agile
practices
in
control.
The successful of XP’s
project
depends
on
people’s
competency
and experiences. This
become problem in our
team that we have
various
different
backgrounds.
A lot of overhead, like
creating prototype, is
produced before start
implementing.
It is difficult to gather all
the requirements in
advance at the early
stages of the project.
It is difficult to manage
changes
and
when
possible implies big
cost.
6. CONCLUSIONS
Is the believe of this software development team that the set of
decision adopted along the plan, in both, the project management
area as well as the software development area are going to drive
our project to our final goal. A goal based on the delivery of our
final product under cost, in time and with the quality level
required by our customer. This assumption is based on two main
decisions, the customization of the PMP for the project
management area and the adoption of an agile perspective of the
unified software development process.
During the elaboration of the present project plan the main
difficulties we have found were: the transition from a group of
people to a team. The adoption of a common understanding about
the activities and tasks required for a software development
project. The distinction between project management activities
and software development activities, as well as the relation
between them, have been a difficult area of agreement.
7. REFERENCES
[1] PMI Project management body of knowledge 3rd Ed. PMI
Inc. Four Campus Boulevard, Newton Square, Pennsylvania,
USA. 2004.
[2] Rising, L. and Janoff, N. S. The scrum software development
process for small teams IEEE Software. July/August 2000
[3] Nyfjord, J. and Kajko-Mattsson, M. Commonalities in risk
management and agile process model. In International
Conference on Software Engineering Advances, pages 18–
18. ICSEA, August 2007.