Software Project Management
Fundermental of Software
Project Managerment
Team Assignment 1
Team 2
Team member
Name
Student ID
Tạ Quang Hiệp( Leader)
Trần Dũng Đạt
Trần Thị Ngọc Trâm
Đặng Nguyên Toàn
Lê Trung Hậu
T090363
T095716
T094907
T095984
T093886
1. Write a short article (10 pages) summarizing your view on “Software development
process” and answer the following questions:
 What is a Software Development Process?
 What are Software development activities?
 What is software development model?
2. Describe the software development model assigned to your team as following:
TSP (Team Software Process)
Team 2 – K15T2 - VanLangUni
Software Project Management
I.
Software development process
1.
Definition

The software development process is the set of coordinated activities performed by
engineers, managers and technical writers resulting in the creation of a software
product. Various named software development processes are in use today, including
AUP, RUP, XP, Scrum, Waterfall …

There are four operation are the foundation of most software process is:




Software specification: The software’s functions and conditionss to operating
must be defined.
The software development: Software specification must be achieved with this
development process.
Evaluation software: Software must be evaluated to make sure it does what the
customer want.
The evolution of software: Software must be evolve to meet customer’s
requirement changing.
2. The basic activities or phases to be performed for developing a software
system are:
1. Requirement




Indentify the system development
Establish project scope
Develop project plan
Identify requirements for new systems and requirements analysis activities
include:Clarify requirements, review requirements, documentation requirements.
 Consider the problem to solve and clarify the requirements: communication with
customers and users to define their requirements
2. Architect
 Develop technical design architecture works
 Identify the system output, input and user interface.
 Select the system components (hardware, software, databases,
telecommunications,and procedures)
 Determine how to integrate the components
3. Implement
 Translating the design into code
 Find and check the identification code to prevent syntax errors
Team 2 – K15T2 - VanLangUni
Software Project Management
4. Test
 Check your code to see if it meets the expected results.
 Check the performance of the system in hardware.
 Testing the system in the business environment.
5. Maintain
 Continued monitoring and support systems to ensure it meets business objectives
 Provide support (debugging, repair, improve)
3. Software development model
Software development models describe phases of the software cycle and the order in which
those phases are executed. There are many of models, and many companies adopt their
own. The general, basic model is shown below:
1. The Waterfall Model
 The waterfall life cycle is a sequential development model in which development is seen
as flowing downwards (like a waterfall) through the phases of requirements, design, code,
test, integrate and maintenance.
 In the waterfall model, proceed from one phase to the next in a sequential manner. Thus,
only move to the next phase when the preceding phase is completed.
 The waterfall model is easy to understand and useful when you have well-defined and
stable requirements for a large software system with large distributed teams. But in
practice, it is unrealistic because requirements often change, making it difficult to fully
complete one phase before moving to the next.
2. The Spiral Model
 The development life cycle that combines elements of both design and prototyping concepts.
This model combines the features of the prototyping model and the waterfall model.
 Estimates (i.e. budget, schedule, etc.) get more realistic as work progresses in each iteration
because important issues are discovered earlier.
 It is better able to cope with the (nearly inevitable) changes that software generally faces.
 Software engineers can get their hands in and start working on a project earlier.
Team 2 – K15T2 - VanLangUni
Software Project Management
3. AUP (Agile Unified Process)
AUP is a simplified version of the Rational Unified Process (RUP). It describes a
simple, easy to understand approach to developing business application software using agile
techniques and concepts yet still remaining true to the RUP.
AUP approach applies agile techniques include test driven development (TDD) , Agile
Model Driven Development (AMDD) , agile change management , and database refactoring to
improve your productivity.
AUP model, a simple model for medium and small projects, requiring fast development.
4. Scrum
- SCRUM is a process that has defined the AGILE methodology for monitoring and controlling
the activities of software development. It include establish , monitoring, and managing the job
is not done, the current work, the risks, problems and changes.
- SCRUM particularly suitable for the requested project or quickly change.
Team 2 – K15T2 - VanLangUni
Software Project Management
i. A Scrum software project is managed by maintains a Product backlog (Requirements list) and
risks. Risks are things identify in product backlog that the team must mitigate.
ii. Scrum allows project team to determine when the system is “good enough” to be released to
customer. With Scrum, every project progresses through a series of iterations, usually four
weeks in length, called “Sprints” (Short duration).
1. At the start of each Sprint, a Sprint Planning Meeting is held during which the Product
Owner prioritizes the Backlog and the team selects the tasks they can complete within that
Sprint. These tasks are then moved from the Product Backlog to the Sprint Backlog.
2. Each day a daily meeting called the Daily Scrum is held, to identify which activity has been
completed and which is not and must be implemented on that day. This kind of meeting
creates a visibility of each person’s work to facilitate knowledge sharing, reduce
overlapping tasks, and ensure that their work is fully integrated.
3. At the end of each Sprint, the team demonstrates the completed functionality at a Sprint
Review Meeting
5. Extreme Programming
Extreme Programming (XP) is one method of developing software in a flexible way. XP
uses a combination of teamwork, including programmers customers and managers to develop
high quality software in quick time. A program run as the first measure of progress under XP.
XP can grow and survive is due to an improved understanding on the issues are resolved and
also because the tools available to allow us to change the price of change (cost-of-change)
(being a previous exponential form). XP keeps the cost low so this will promote software
production environment.
The life cycle of XP process
Planning  Analysis Design  Programming Test Deploy.
XP is operating iteration model. Products are divided into small part, each of which is
developed within one or a few weeks and called an iteration. With each part, the project team
performs all activities: planning, analysis, design, programming, test and deploy The
advantage of this model is that the project team to quickly get feedback from customers. The
Team 2 – K15T2 - VanLangUni
Software Project Management
necessary changes will be applied immediately in the next iteration.
II.
Team Software Process (TSP)
1. What is TSP?
Team Software Process (TSP) TSP is a process that is specifically designed for
software teams. It guides engineering teams that are developing software-intensive products.
Using TSP helps organizations establish a mature and disciplined engineering practice that
produces secure, reliable software in less time and at lower costs. TSP’s purpose is to build
high-performance teams and help them:
 Plan their work
 Negotiate their commitments with management
 Manage and track projects to a successful conclusion
 Produce quality products in less time
 Achieve their best performance without the “death march” ending
TSP has been applied in small and large organizations in a variety of domains with similar
results on first use, including
 Productivity improvements of 25% or more
 Reductions in cost and schedule variance to less than +/- 10%
 Testing costs and schedule reductions of up to 80%
2. TSP Implementation Strategy
The TSP has three general parts. The first part is team formation, during which you
recruit potential team members and provide them and their mangers with any needed training
or orientation. Second comes the team launch, in which management tells the team what
they want done and the team builts its plan to do the necessary work. The third part is
ongoing team operation, where the team follows its plan to do the job.
2.1.
Personal Software Process (PSP)
Team 2 – K15T2 - VanLangUni
Software Project Management
The first step in a TSP initiative is to train all team members who can write programs in
PSP. The PSP is more than just training; it is a boot camp consisting of about 40 hours of
classroom instruction, 10 programming assignments, and three data-analysis exercises,
requiring a total of about 150 hours for the average programmer to complete.
The result of the PSP boot camp is that the programmers do not just learn about good
processes, they actually improve their own processes, measure the effects of those process
changes, quantify the benefits they have experienced, and set goals for further improvements.
The PSP achieves these results by leading students through three steps.
1. In PSP0, they lay a simple foundation for the learning to come:
 Following simple process scripts.
 Collecting three basic measures of their work (time spent, size of products produced, and
defects corrected).
 Performing a simple post-project analysis.
2. In PSP1, they begin to build the capability to plan and manage their own work:
 Following a defined project planning process.
 Using their own prior data to make increasingly more accurate estimates for each
programming assignment.
 Planning their work at a level of detail that allows them to track and manage their progress.
3. In PSP2, they focus on achieving significant quality improvements:
 Using their prior data to plan for incremental improvements in the quality of their programs.
 Removing defects early using personal review techniques guided by their own prior defect
performance.
Team 2 – K15T2 - VanLangUni
Software Project Management
 Identifying and capitalizing on defect prevention opportunities in their program design and
implementation methods.
Those who complete the PSP boot camp emerge with the knowledge and skills to make
accurate plans, work to those plans, and produce superior quality products.
2.2. The TSP Launch Process
TSP uses team based planning sessions called “launches” to put the detailed project
plans in place. Team based planning has advantages as several members working together
will create a more accurate plan than one project manager working alone. Team based
activities will also identify more detailed tasks with more dependencies than a single person
working in isolation, and the overall tasks will have less errors because errors from multiple
uncorrelated activities tend to cancel each others out.
Meeting 1 - Understand the Project Objectives
The team meets with management to understand the project objectives.



Management describes the business goals and objectives, e.g. business need,
resources, schedule, success criteria.
Marketing or the customer describes the product goals and objectives, e.g. market,
customer needs, features, success criteria.
The team asks questions.
Team 2 – K15T2 - VanLangUni
Software Project Management
Meeting 2 - Assign Roles and Define Team Goals
The team develops a business needs statement to guide the project.


Why does management want this project?
What will the project contribute to the business?
Measurable goals are established for each project stakeholder.





Customer
User
Management
Team
Team member roles
Meeting 3 - Define the Work and the Approach
The team accomplishes three important prerequisites to building the team plan.



Identifies all of the work the team needs to do
Identifies the build strategy the team will use to develop the software
Identifies or defines the processes the team will follow to do the work
Meeting 4 - Build the Overall Plan





The team creates the overall plan by establishing
The estimated size of each work product (how big is the job)
The tasks needed to complete the work (with effort estimates)
 Next-phase tasks, detailed to the work-step level
 Later phases at a high level
The estimated team hours available each week for the work
An initial schedule for the project
Meeting 5 - Build the Quality Plan
The team builds a quality plan that estimates the




Number of defects that will be injected in each phase
Number of defects that will be removed in each phase
Quality (defect density) of the final product
Quality (process quality index) of the development process
The team ensures that the plan meets the quality goals.
Meeting 6 - Build Individual Work Plans
Team 2 – K15T2 - VanLangUni
Software Project Management
Each team member builds a plan to which he or she can commit.
In building their plans, the team members






Allocate tasks to individuals
Refine size and effort estimates using their own data and processes
Break tasks to the granularity of around 10 hours or less per task
Estimate their own available task hours for each week
Create an earned-value plan
Balance workloads across all team members.
Meeting 7 - Risk Management
The team develops a risk management plan.
In building the risk management plan the team members



Identify project risks
Evaluate each risk for high, medium, or low impact and likelihood
Assign each high or medium risk to a team member and define an action date and
mitigation strategy
Meetings 8 and 9


Prepare Management Briefing and Launch Report
Hold Management Review
Meeting 9 - Making a Commitment



The team leader briefed management on the plan.
Under strong management pressure, the team
 Explained their approach.
 Justified the effort required.
Management reluctantly accepted the plan and the team began development.
3. TSP and CMMI
CMMI and TSP form a powerful set of technologies that businesses can use to
improve performance and meet their business goals, sometimes even quicker than using one
by itself.
The TSP has the same roots as the CMMI, being based on the Software Engineering
Institute’s (SEISM) early research that produced the CMM for Software (SW-CMM). As such,
it aligns well with the CMMI and partly or fully satisfies the CMMI’s goals.
Team 2 – K15T2 - VanLangUni
Software Project Management
So, adding the TSP to a CMMI initiative does not mean adding more work to an
already overworked group. Rather, it can be an effective way to accelerate that initiative by
laying a solid foundation of process discipline, engaging the engineers from the very
beginning, and providing processes that already address a significant number of CMMI
practices. The costs of incorporating the TSP into your CMMI initiative should be more than
returned as you achieve your CMMI goals more quickly and with less organizational pain.
4. Who is using TSP?
A growing number of industry organizations are using TSP, including Microsoft, Oracle,
Intuit, Adobe, EDS, FujiFilm, Toshiba, HitachiSoft, Softtek, and IBM. Government software
organizations using TSP include NAVAIR, NAVOCEANO, Hill AFB, and JSOC.
Team 2 – K15T2 - VanLangUni