T-76.4115/5115 Software Development Project I/II Software Development Process Framework Jari Vanhanen Ohjelmistoliiketoiminnan ja –tuotannon laboratorio Software Business and Engineering Institute (SoberIT)
Jan 04, 2016
T-76.4115/5115Software Development Project I/II
Software Development Process Framework
Jari VanhanenOhjelmistoliiketoiminnan ja –tuotannon laboratorio
Software Business and Engineering Institute (SoberIT)
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
Contents
T-76.4115 Software process framework Project management Requirements engineering Quality assurance Design & implementation Iterations
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
Creating and improving the process (work practices, tools etc.) is part of project management.
Have you already found other challenges?
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”
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
Iterative Development
Why iterations? regular control points force packaging the results enable giving feedback
If you want very short iterations, you can split a course’s iteration
into two iterations.
Iterations
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
Iteration planning meeting customer selects and prioritizes what is implemented based on
business importance group’s rough effort estimates for implementing sw units group’s effort allocation for the iteration 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
Deadline for the PP Iteration plan Fr 3.10. 11:00
•by e-mail to customer & mentor
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
iteration’s results including a sw demo (20-25 min) experiences of used work practices (3 min) discussion
Tip! Arrange the next iteration planning meeting right after the iteration demo.
Iteration demo schedule preferences21.-22.10. 8:00-18:00
customer + mentor + group members
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 plans
Steering reacting to the deviations
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.
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 these 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 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”
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 group’s reflection workshops
•invite the mentor to work sessions
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
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
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
T-76.4115 Typical Effort Distribution
design; 8
documenting; 17
infrastructure; 4
meetings; 17programming; 32
proj. management; 8
studying; 8
testing; 6
Documenting Required project documents
project plan including QA plan and description
of work practices requirements document technical specification* user’s 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 iteration’s last Monday 11:00 am
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
Content of T-76.4115 Project Plan
1. Introduction2. Stakeholders and staffing3. Goals4. Resources and budget5. Work practices and tools6. Phasing7. 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
Project Management - Hints Arrange a kick-off
good team spirit is crucial find out about each other’s
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. hw+sw)
Spy on others to get ideas Projects from previous years/this year give a reference, if you copy some
ideas/materials
Project Management – Mandatory Practices
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”
ElicitationFind out using any possible means:
•business goals•main domain concepts
•user groups•requirements
AnalysisAnalyze the gathered information.
List identified requirements shortly.
Estimate roughly: customer value, effort, architectural impact.
AnalysisRe-estimate the “most important” requirements
Iteration planningChoose iteration’s requirements
RepresentationFind out the details of iteration’s requirements
(Re-)AnalysisRe-estimate required effort. Ensure realism of the plan.
ValidationReview iteration’s requirements. Get customer’s approval.
Implementation, QA, DeliveryCollect feedback from the customer
I1&I2 Iterations PP Iteration
Change m
anagement, status tracking, tracing
In practice many activities are parallel
and iterative!
Requirements Engineering
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
Requirements Engineering - Mandatory Practices
Contents
Software process framework Project management Requirement engineering Quality assurance Design & implementation Iterations
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
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
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
Reporting QA - Quality Palette
Which QA practices were planned and/or used? What was the contribution of each QA practice?
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
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
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
Quality Assurance – Mandatory Practices
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 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
Software Process – Design and Implementation
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 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 …
Deliveries Project plan (except ch. 5.2 QA plan) Requirements document
(except details in ch. 6-8) Progress report
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
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
Iterations - Implementation 2 (I2) Iteration planning
RE, design, implement, QA keep a demo to the customer 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
Deliveries Implemented software
Project plan Requirements document Technical specification Test cases QA report and test log
User's manual Final report
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 …
Experience Exchange Sessions
Innopoli2, SoberIT seminar hall, 17:00 - 18:45
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 17:00 Teachers will prepare agenda for the session
Discussion language Finnish
Two persons per group may participate
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