T-76.4115/5115%20Software%20Development%20Project%20I/II%20Software%20Development%20Process%20Framework

1
T-76.4115/5115Software Development Project
I/IISoftware Development Process Framework

• Jari Vanhanen
• Ohjelmistoliiketoiminnan ja tuotannon
  laboratorio
• Software Business and Engineering Institute
• (SoberIT)

2
Course Arrangements

• Contracts
• all groups members sign together one copy and
  send it to the teacher
• Jari Vanhanen, SoberIT, PL 9210, 02015 TKK
• include YOUR return address
• DL as soon as possible, e.g. NDAs are not valid
  before this
• Mentors and peer groups will be assigned soon

3
Contents

• T-76.4115 Software process framework
• Project management
• Requirements engineering
• Quality assurance
• Design implementation
• Iterations

4
Process Should Match the Context

• 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

Have you already found other challenges?
Creating and improving the process (work
practices, tools etc.) is part of project
management.
5
T-76.4115 Software Process Framework

• Helps the groups define how they are going to do
  the work
• Includes educational aspects
• trying certain practices in a real context
• Enforces certain good work practices
• allows lots of freedom (and responsibility) for
  customization
• Minimizing risks requires some overhead

6
T-76.4115 Software Process Framework

• Instructions and templates
• Mandatory and recommended practices
• mandatory written as group must do xxx
• summarized in Overview Ch. 3

Process documentation http//www.soberit.hut.fi/T-
76.4115/08-09/instructions/index_process.html
7
Iterative Development

• Why iterations?
• regular control points
• force packaging the results
• enable giving feedback

If you want very short iterations, you can split
a courses iteration into two iterations.
8
Iterations
9
Iteration Planning

• Group and customer plan each iterations 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
• Iteration planning meeting
• customer selects and prioritizes what is
  implemented based on
• business importance
• groups rough effort estimates for implementing
  sw units
• groups effort allocation for the iteration
• groups estimates about architectural impact
• Group concretizes goals and deliverables into
  required tasks
• re-planning, if task effort estimates and
  allocated resources differ largely

• Deadline for the PP Iteration plan Fr 3.10. 1100
• by e-mail to customer mentor

10
Iteration Demo

• Arranged in the end of each iteration for all
  project stakeholders
• Agenda progress report slideshow
• project status (10-15 min)
• iteration goals
• project metrics
• iterations results including a sw demo (20-25
  min)
• experiences of used work practices (3 min)
• discussion

Iteration demo schedule preferences21.-22.10.
800-1800customer mentor group members
Tip! Arrange the next iteration planning meeting
right after the iteration demo.
11
Contents

• Software process framework
• Project management
• Requirement engineering
• Quality assurance
• Design implementation
• Iterations

12
Project Management

• Planning
• how are we going to do the work
• Tracking
• noticing any deviations to the plans
• Steering
• reacting to the deviations

13
Identify Stakeholders and Staffing

• External
• customer, tech. advisor, mentor, 3rd parties
• Internal
• project group and its roles
• sub groups?
• Show the relationships between the stakeholders
• e.g. organizational chart
• Contact information
• emails, phones, web pages etc.

You are allowed to rotate or change the assigned
roles within the group.
14
Project Goals

• Defining goals
• identify
• consider all stakeholders
• resolve conflicts
• everyones commitment
• manage expectations
• define verification criteria
• objective vs. subjective
• prioritize
• Goals and priorities change
• keep them up-to-date and document changes (and
  reasons)
• Projects results will be evaluated against these
  goals

Define personal learning goals separately!
15
Resources and Budget

• Personnel
• 27h/credit/person - 15h spent before the project
• -gt 120-200h for project work educational
  aspects
• effort allocation between iterations
• how many hours per person
• depends on roles, vacations etc.
• planning allocated vs. max. available vs.
  required?
• Materials
• hardware and software resources
• other materials (books etc.)
• Budget
• theoretical costs for the project, if done in the
  real world

16
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
• Use low overhead approaches!
• build trust with the mentor
• show work products generated by the use of
  practices, e.g. code review notes
• invite the mentor to the groups reflection
  workshops
• invite the mentor to work sessions

17
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 plans are refined during iteration
  planning
• make PP iteration plan immediately

18
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 people have received important
  information?
• For example
• project web pages/Wiki
• documents, source code and executable program
• regular meetings
• Skype conference calls
• e-mail lists
• discussion forum
• status reports/project metrics

19
Time Tracking

• Purpose
• visibility for tracking project progress
• managing resource usage (fixed budget)
• learning to estimate better

• Plan how and when
• some time reporting tool, GoogleDocs,
• personal reporting daily
• reliability
• Weekly summaries on a web page

20
T-76.4115 Typical Effort Distribution
21
Documenting

• Required project documents
• project plan
• including QA plan and description of work
  practices
• requirements document
• technical specification
• users manual
• QA reports
• 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, )
• spelling checker
• printability
• Deliver documents (URL) to the course by
  iterations last Monday 1100 am

22
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

23
Content of T-76.4115 Project Plan

• 1. Introduction
• 2. Stakeholders and staffing
• 3. Goals
• 4. Resources and budget
• 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

24
Project Management - Hints

• Arrange a kick-off
• good team spirit is crucial
• find out about each others commitments and
  personal interests
• discuss roles and responsibilities
• 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
• Try one-day group sessions
• problems can be addressed immediately
• prepare well (e.g. hwsw)
• Spy on others to get ideas
• Projects from previous years/this year
• give a reference, if you copy some
  ideas/materials

25
Project Management Mandatory Practices
26
Contents

• Software process framework
• Project management
• Requirement engineering
• Quality assurance
• Design implementation
• Iterations

27
Requirements Engineering

• Ensure that the projects results solve the
  customers 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

28
Requirements Engineering
I1I2 Iterations
PP Iteration

• Elicitation
• Find out using any possible means
• business goals
• main domain concepts
• user groups
• requirements

Analysis Re-estimate the most important
requirements
Iteration planning Choose iterations requirements
Analysis Analyze the gathered information. List
identified requirements shortly. Estimate
roughly customer value, effort, architectural
impact.
Representation Find out the details of
iterations requirements
Change management, status tracking, tracing
Validation Review iterations requirements. Get
customers approval.
(Re-)Analysis Re-estimate required effort. Ensure
realism of the plan.
In practice many activities are parallel and
iterative!
Implementation, QA, Delivery Collect feedback
from the customer
29
Other Requirements Engineering 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

30
Requirements Engineering - Mandatory Practices
31
Contents

• Software process framework
• Project management
• Requirement engineering
• Quality assurance
• Design implementation
• Iterations

32
Quality Assurance

• QA means all practices that are used to
• achieve the required level of quality in the end
  product
• evaluate the actual achieved level of quality

33
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 achieving the
  quality goals
• testing levels, test types, other QA practices
• mandatory QA practices
• test case based testing, unit testing, coding
  standard, code review
• Plan when the QA practices performed
• 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
• Plan concrete QA tasks during iteration planning

34
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
• minimize the time spent on documenting
• Managing ET - Session Based Test Management
  (SBTM)
• 45-120 minutes
• test session charters
• exploration log

35
Reporting QA - Quality Palette

• Which QA practices were planned and/or used?
• What was the contribution of each QA practice?

36
Reporting QA - Quality Status

• Quality dashboard - quick overview of the quality
  status of the system

• Relevant quality metrics
• e.g. defect counts, code metrics
• Status of quality goals

37
Defect Tracking

• Defect bug, change request, idea,
• Ensure that found defects are handled
• Defect tracking process
• how to report defects
• including all stakeholders
• 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

38
Peer Testing

• Peer groups test each others 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

39
Quality Assurance Mandatory Practices
40
Contents

• Software process framework
• Project management
• Requirement engineering
• Quality assurance
• Design implementation
• Iterations

41
Design

• Architecture design
• identify architecturally significant requirements
• create architecture description
• based on the most important 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

42
Software Process Design and Implementation
43
Contents

• Software process framework
• Project management
• Requirement engineering
• Quality assurance
• Design implementation
• Iterations

44
Iterations - Project Planning (PP)

• Iteration planning
• work plan for the next 3 weeks
• plan for project planning and requirements
  elicitation
• tasks, resources, schedule
• customer in a minor role compared to later
  iterations
• Project planning
• goals, resources, work practices
• Adoption of all relevant practices
• communication
• time tracking
• requirements engineering

• Requirements engineering
• business goals, main domain concepts, user groups
• list of requirements
• name short description
• Design
• initial drafts of the system architecture
• select the implementation technologies
• technology prototypes?
• Iteration demo
• content of the project plan and requirements
  document
• project status

• Deliveries
• Project plan (except ch. 5.2 QA plan)
• Requirements document(except details in ch. 6-8)
• Progress report

45
Iterations - Implementation 1 (I1)

• QA plan
• Iteration planning
• architectural importance
• business value
• Decide about technical documentation
• level of detail, format,
• RE, design, implement, QA, delivery

• Deliveries
• Implemented software
• Project plan (especially ch. 5.2 QA plan 6.3
  I1)
• Requirements document
• Technical specification(at least the general
  architecture)
• Test cases
• QA report and test log
• Progress report

46
Iterations - Implementation 2 (I2)

• Iteration planning
• RE, design, implement, QA
• keep a demo to the customer in the middle of the
  iteration
• Create the Users manual
• Finalize technical documentation
• Delivery to the peer testing
• fix critical defects
• Delivery to the customer
• installation/training?
• Evaluate your work and the course

• Deliveries
• Implemented software
• Project plan
• Requirements document
• Technical specification
• Test cases
• QA report and test log
• User's manual
• Final report

47
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 for the
  SEPA topics
• Heuristic evaluation
• Usability tests
• Design patterns
• Pair programming
• Refactoring
• Automated unit tests
• Test-driven development
• Test automation on system test level
• Static methods
• Meeting practices

48
Experience Exchange Sessions

• Innopoli2, SoberIT seminar hall, 1700 - 1845
• Tu 7.10. Project managers
• Tu 14.10. QA managers (focus on RE)
• Tu 28.10. QA managers (focus on QA)
• Tu 4.11. Architects
• Tu 11.11. Project managers
• e-mail your proposals for discussion by previous
  day 1700
• Teachers will prepare agenda for the session
• Discussion language Finnish
• Two persons per group may participate

49
Next Steps

• Arrange the first meetings
• with the whole group
• with the customer
• Sign the contract with TKK
• Start project planning
• roles and responsibilities
• plan urgent work practices immediately
• communication and material sharing
• time tracking
• iteration plan DL Fr 3.10.
• Start requirements elicitation