T
-
76.4115/5115
Software Development Process
Framework
Jari Vanhanen
Contents
•
T
-
76.4115 Software process framework
•
Project management
•
Requirements engineering
•
Quality assurance
•
Design & implementation
•
Iterations
Course Arrangements
•
Tools
–
MSDN AA
•
accounts have been e
-
mailed to all students
–
Magic Draw UML Tool
•
instructions have been e
-
mailed to project managers
–
Aalto Student Wiki launched 1.9.2010
•
Mentors and peer groups will be assigned soon
–
see “Projects”
-
page
•
Group names and home pages
–
e
-
mail to teacher
9/14/2010
Jari Vanhanen
3
Course Arrangements
•
Contracts
–
all group members sign the same copy
–
choose correct IPR and NDA options
–
include project manager’s home address
–
DL 20.10. or
as soon as possible
•
e.g. companies may ask for NDAs
•
Jari Vanhanen, SoberIT, PL 19210, 00076 Aalto
Contents
•
T
-
76.4115 Software process framework
•
Project management
•
Requirements engineering
•
Quality assurance
•
Design & implementation
•
Iterations
Process Should Match the Context
•
Typical challenges in the T
-
76.4115 context
–
no existing, common development culture within the team
–
varying level of experience between developers
–
physical and temporal distribution
–
project is done for an external customer
–
software will be maintained by other people
•
Process is never ready
–
continuous improvement needed
Creating and improving the process (work practices, tools etc.) is
part of project
management/QA.
Have you already found
other challenges?
T
-
76.4115 Software Process Framework
•
Helps you plan how to do the work
•
Includes educational aspects
–
trying certain practices in a real context
•
Enforces certain crucial/good work practices
•
Allows lots of freedom (and responsibility) for
customization
•
Minimizing risks requires some “overhead”
T
-
76.4115 Software Process Framework
•
Guidelines and templates
•
Mandatory and recommended practices
–
mandatory ones written as “
group must do xxx
” and
summarized in Overview (Chapter 3)
http
://
www.soberit.hut.fi/T
-
76.4115/10
-
11/instructions/index_process.html
Check
more materials from
SoberIT’s
SE courses.
T
-
76.4115 Framework vs. Agile Methods
•
Agile sweet pots [Cockburn] match quite poorly the
course context
–
experienced developers
–
2
-
8 people in one room
–
on
-
site usage experts
–
one
-
month increments
–
fully automated regression tests
(unit and/or functional tests)
•
However, many agile practices are still useful
T
-
76.4115 Framework vs. Agile Methods
•
Many agile practices are included in or can be adapted
to the T
-
76.4115 framework
–
short iterations and sprints
–
iteration planning, iteration demos
–
project/iteration/ sprint backlogs
–
(daily)/weekly scrum
–
reflection workshops
–
all XP’s programming level practices may be adopted
•
TDD, pair programming, collective ownership, coding standards,
refactoring, continuous integration
–
etc…
9/14/2010
Jari Vanhanen
10
T
-
76.4115 Framework vs. Traditional
Methods
•
Some things borrowed from traditional methods
–
more rigorous planning of project’s work methods
–
risk management
–
trying use cases for documenting requirements
–
more rigorous QA
•
explicit quality goals
•
planning QA practices based on quality goals
•
trying a code review
9/14/2010
Jari Vanhanen
11
I
n real life there are also very large and/or quality
critical projects that need more rigorous work methods.
Iterative Development
•
Why iterations?
–
regular control points
–
force packaging the results
•
remember testing and delivery!
–
enable giving feedback
It is recommended to
split a course’s
iteration into two
sprints.
Software Process
–
Iterations
9/14/2010
13
Jari Vanhanen
Software Process
–
Iteration Planning
•
Group and
customer
plan each iteration’s
goals
and
deliverables
–
goals
are higher level ideas of what is expected from the iteration
–
deliverables
include software units and documents to be created/updated
•
Customer selects and prioritizes iteration’s content based on
–
business importance
–
group’s effort allocation for the iteration
–
group’s rough effort estimates for implementing sw units
–
group’s estimates about architectural impact
•
Group concretizes goals and deliverables into required tasks
–
re
-
planning, if task effort estimates and allocated resources differ largely
9/14/2010
Jari Vanhanen
14
Iteration
planning
meeting
Deadline for the PP Iteration plan
Mo 4.10
.
13:00 by
e
-
mail to customer, mentor and teacher
Software Process
–
Iteration Demo
•
Arranged in the end of each iteration
–
tell impossible dates/times (8:00
-
19) to the teacher immediately
–
at SoberIT (
Innopoli
2)
•
Participants
–
at least the critical members of the student group
–
customer, mentor, teacher, Accenture
•
Group presents
project status and iteration’s results including sw demo
–
45 minutes including questions
–
slide set = progress report
•
no need/time to present all content in detail
•
Customer evaluates the work performed
–
private discussion about the given points with the mentor after the demo
Tip
!
Combine
the
next
iteration
planning
meeting
to
the
iteration
demo.
9/14/2010
15
Jari Vanhanen
Contents
•
Software process framework
•
Project management
•
Requirement engineering
•
Quality assurance
•
Design & implementation
•
Iterations
Project Management
•
Planning
–
how are we going to do the work
•
Tracking
–
noticing any deviations to the explicit or implicit plans
•
Steering
–
reacting to the deviations
Content of T
-
76.4115 Project Plan
1. Introduction
2. Stakeholders and staffing
3. Goals
4. Resources
5. Work practices and tools
6. Phasing
7. Risk log
planning is more important than
documenting its results, but documenting
is also needed in this kind of a project
•
”contract” with the customer
•
basis for tracking and steering
Identify Stakeholders and Staffing
•
External
–
customer representatives, mentor, 3
rd
parties
•
Internal
–
project group and its roles
–
sub groups?
•
Show the relationships between the stakeholders
–
e.g. organizational chart
•
Contact information
–
emails, phones,
skype
, web pages etc.
You can rotate or change the assigned
roles within the group.
Project Goals
•
Defining goals
–
identify
•
consider all stakeholders
–
resolve conflicts
•
everyone’s commitment
•
manage expectations
–
define verification criteria
•
objective vs. subjective
–
prioritize
•
Goals and priorities change
–
keep them up
-
to
-
date and document changes (and reasons)
•
Project’s results will be evaluated against project’s goals
Define personal learning goals separately!
Resources and Budget
•
Personnel
–
27h/credit/person
-
~15h spent before the project
•
-
>
120
-
200h
for project work + educational aspects
–
effort allocation per iteration
•
how many hours per person
–
depends on roles, vacations etc.
•
planning
allocated
vs. required vs. max. available?
•
Materials
–
hardware and software resources
–
other materials (books etc.)
Work Practices and Tools
•
Plan which practices and tools you will use and how
–
analyze the major challenges in the context of
your
project
•
Document the practices shortly
–
all stakeholders need to know how work is done
•
Continuous process improvement
–
reflection workshop in the end of iterations
•
present action points in progress report
–
analyze practices in the final report
•
Make sure the practices are deployed
–
and the usage is
visible
to the mentor
Increasing visibility to mentor
using low
overhead
approaches:
•
build trust with the mentor
•
show
him work products,
e.g.
code review notes
•
invite him to work sessions
•
invite him
to
reflection
workshops
Phasing
•
Iteration dates fixed
•
Add important events to the general project schedule
–
internal milestones
•
Plan tentative goals and deliverables for all iterations
with the customer
•
Tentative plan is refined during iteration planning
–
make PP iteration plan immediately
Communication
•
Plan efficient communication channels between all stakeholders
•
Who needs what information and when?
–
provide enough information, but avoid information overflow
•
How to ensure that everyone has received important information?
•
For example
–
project Wiki/web pages
•
documents, online sw demos
–
regular meetings
–
Skype conference calls
–
e
-
mail lists
–
discussion forum
–
status reports/project metrics
Time Tracking
•
Purpose
–
managing resource usage (fixed
budget)
–
visibility for tracking project
progress
–
learning to estimate better
•
Plan how and when
–
time reporting tool
•
AgileFant
,
GoogleDocs
, …
–
personal reporting daily
•
reliability
–
weekly summaries on web
Report all project related hours
such as studying etc...
T
-
76.4115 Typical Effort Distribution
design; 8
documenting; 17
infrastructure; 4
meetings; 17
programming; 32
proj. management; 8
studying; 8
testing; 6
Documenting
•
Required documents
–
project plan
•
including QA plan and description
of work practices
–
requirements document
–
technical specification*
–
user’s manual*
–
progress reports (a slide set for the
iteration demos)
–
final report
•
Course provides some document
templates
–
their use is mandatory, but irrelevant
topics can be omitted
•
Documentation practices
–
use a change log
–
clear and compact form
–
once and only once
•
avoid duplication
•
use links/references
•
give IDs to items (
reqs
, tests, …)
–
use spelling checker
•
Document delivery
–
send URL to 1)customer, 2)mentor,
3)teacher
–
www
-
page must contain separate
documents and a zip
-
package
–
DL is 1
-
2 days before iteration demo
Risk Management
•
Risk identification
–
involve all stakeholders
–
use brainstorming and lists of typical risks
•
Risk analyzing
–
for the most important risks analyze
•
probability, severity
•
effects
•
controlling actions
–
document risks to the risk log
•
Risk controlling
–
implement controlling actions to avoid or reduce risks
•
Risk monitoring
–
check the risk situation and status of controlling actions
–
update the risk log in the end PP and I1 iterations
Project Management
-
Hints
•
Arrange a project kick
-
off
–
get to know each other
–
find out about each other’s
commitments and personal interests
–
discuss roles and responsibilities
–
good team spirit is crucial
•
Arrange a weekly, co
-
located work
session
–
at least for sub teams
•
Start work immediately in the beginning
of iterations
–
more calendar time to react to
unexpected situations
•
Test unfamiliar technologies and tools
early to minimize risks
•
Spy on others to get ideas
–
projects from previous years/this year
–
give a reference, if you copy some
materials
Software Process
–
Project Management
9/14/2010
30
Jari Vanhanen
Contents
•
Software process framework
•
Project management
•
Requirement engineering
•
Quality assurance
•
Design & implementation
•
Iterations
Requirements Engineering
Ensure that the project’s results solve the customer’s problem
Requirement types
functional requirement
a required function or service of the system from the users’ point of view
typically documented as use cases
non
-
functional requirement
a required
property
e.g
. usability, performance, reliability, security, safety
constraint
a limitation to the choices available to developers for implementing the
system
e.g. “
the system must run on Windows”
Elicitation
Find out using any
possible means
:
•
business
goals
•
main
domain concepts
•
user groups
•
requirements (on high level)
Analysis
Analyze
the gathered information.
List
identified requirements
shortly.
Estimate
roughly: customer value,
effort, architectural impact.
Analysis
Re
-
estimate the “most important”
requirements.
Iteration planning
Choose iteration’s
requirements.
Representation
Find out the details of iteration’s
requirements.
(Re
-
)Analysis
Re
-
estimate required effort
.
Ensure
realism of the plan.
Validation
Review iteration’s requirements
.
Get
customer’s approval.
Implementation, QA, Delivery
Collect feedback from the
customer.
I1&I2 Iterations
PP Iteration
Change management, status
tracking, tracing
In practice many activities
are parallel and iterative!
Requirements Engineering
Other RE Activities
•
Change management
–
requirements (refine, add, delete)
–
content of the iterations
•
Status tracking
–
requirements’ statuses communicate project progress to the
customer
•
Tracing
–
showing relationships between requirements and other artifacts
•
e.g. test cases are often derived from requirements
Software Process
–
Requirements
Engineering
9/14/2010
35
Jari Vanhanen
Contents
•
Software process framework
•
Project management
•
Requirement engineering
•
Quality assurance
•
Design & implementation
•
Iterations
Quality Assurance
•
QA means here all practices that are used to
–
achieve the required level of quality in the end product
–
evaluate the actual achieved level of quality
Planning QA
•
Identify the most important quality goals
–
among non
-
functional requirements, implicit customer expectations, project goals and risks
–
for which parts of the system are the goals relevant
•
Choose QA practices based on the quality goals
–
testing levels, test types, other QA practices
–
mandatory QA practices include
•
test case based functional testing (50%), unit testing, coding standard, a code review
•
Plan when the QA practices are performed
–
plan concrete QA tasks during iteration planning
•
Plan what QA materials are needed
–
test cases, test data, test logs, defects reports, tools, guidelines
•
Plan the utilization of QA information
–
for evaluation of quality status, for convincing the customer
Functional Testing
•
Test case based (TCB) testing
–
pre
-
designed test cases based on requirements
–
must be used for at least 50% of the functional requirements
•
Exploratory testing (ET)
–
not defined in advance
–
continually adjusted plans and re
-
focusing on the most promising risk
areas
–
minimizes the time spent on documenting
•
Managing ET
-
Session Based Test Management (SBTM)
–
45
-
120 minutes
–
test session charters
–
exploration log
Reporting QA
-
Quality Goals and
Practices
•
State of major quality goals
•
Contribution of each QA practice
Practice
Main quality goals
functionality
usability
maintain
-
ability
x
y
z
test case based
functional testing
***
**
unit testing with
JUNit
*
***
coding standard
***
code review
*
*
practice x
Quality
:
green = good
yellow = moderate
red = bad
white = don’t know
Effect
:
*** = large effect
** = moderate effect
* = small effect
<empty> = no effect
Reporting QA
–
Quality Status per
Subsystem
Subsystem
Quality
Confidence
Comments
File
conversions
2
1
Only few minor defects found, very efficient
implementation.
GUI editor
0
Not started
Encoder
0
2
Carefully tested, 2 critical bugs found during last test
round, lots of small problems.
Admin tools
1
2
Nothing serious yet
Quality
:
2 = good
1 = moderate
0 = bad
<empty> = don’t know
Confidence
:
2 = high
1= moderate
0 = low
Consider also other relevant
quality metrics such as defect
counts, code metrics...
Defect Tracking
•
Defect = bug, change request, idea, …
•
Ensure that found defects are handled
•
Defect tracking process
–
how any stakeholder can report defects
–
how to decide which reports will be implemented and when
–
who tests the implemented changes and when
–
possible links to requirements change management process
•
Defect status
–
evaluate found defects before the end of each iteration
–
list open defects in the end of the project
Peer Testing
•
Peer groups test each other’s systems in I2
–
any additional collaboration is highly recommended
•
At least 8 hours of testing effort
•
Exploratory testing
–
give at least two test session charters
•
Report findings
–
exploration log
–
defects, ideas, etc.
–
summary
•
Evaluate the value of the testing done by the peer group
Software Process
–
Quality Assurance
9/14/2010
44
Jari Vanhanen
Contents
•
Software process framework
•
Project management
•
Requirement engineering
•
Quality assurance
•
Design & implementation
•
Iterations
Design
•
Architecture design
–
identify architecturally significant requirements
–
create architecture description
•
based on the most significant requirements
•
at least functional and development views
–
validate architecture
•
does it address the significant requirements
•
Construction design
–
class diagrams
–
error handling
–
database schema definitions
–
…
•
Documenting design
–
negotiate with the customer
Software Process
–
Design and
Implementation
9/14/2010
47
Jari Vanhanen
Contents
•
Software process framework
•
Project management
•
Requirement engineering
•
Quality assurance
•
Design & implementation
•
Iterations
Iterations
-
Project Planning (PP)
•
Iteration planning
–
work plan for the next ~3 weeks
–
customer in a minor role compared to later
iterations
•
Project planning
–
goals, resources, work practices
•
Adoption of all relevant practices
–
communication
–
time tracking
–
requirements elicitation
–
…
•
Requirements engineering
–
business goals, main domain concepts, user
groups
–
list of requirements
•
name & short description
•
Initial drafts of the system architecture
–
select the implementation technologies
–
technology prototypes?
•
Iteration demo
–
project plan and main requirements
–
project status
Iterations
-
Implementation 1 (I1)
•
Iteration planning
–
architectural importance
–
business value
•
QA plan
•
RE, design, implement, QA, delivery
•
Decide about technical documentation
–
level of detail, format, …
Iterations
-
Implementation 2 (I2)
•
Iteration planning
•
RE, design, implement, QA
–
keep a demo to the customer also in the middle of the iteration
•
Create the User’s manual
•
Finalize technical documentation
•
Delivery to the peer testing
–
fix critical defects
•
Delivery to the customer
–
installation/training?
•
Evaluate your work and the course
Other Practices
•
In addition to the practices discussed in the process framework you
may use any other relevant practices
•
See for example the Recommended practices
-
document
–
Heuristic evaluation
–
Usability tests
–
Design patterns
–
Pair programming
–
Refactoring
–
Automated unit tests
–
Test
-
driven development
–
Test automation on system test level
–
…
http://
www.soberit.hut.fi/T
-
76.4115/10
-
11
/instructions/recommended_practices.html
Experience Exchange Sessions (EESs)
•
Dates in the course schedule
–
first ones on Thursday 7.10.
•
Send two proposals for discussion
by previous day
13:00
–
teacher prepares agenda for the session
•
Discussion language is Finnish
•
Two persons per group may participate
•
Innopoli
2, SoberIT seminar hall
Next Steps
•
Arrange the first meetings
–
with the whole group, customer,
mentor
•
Start project planning
–
roles and responsibilities
–
urgent work practices
•
communication
•
time tracking
–
iteration plan
•
DL Mo 4.10. 13:00
•
Start requirements elicitation
•
Sign the contract with Aalto
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Σχόλια 0
Συνδεθείτε για να κοινοποιήσετε σχόλιο