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

Mentors assigned on Thursday TikiWiki and Bugzilla accounts will be created today A218 Windows accounts will be created on Friday Contracts

small modifications are coming soon English versions

Deadline for the Iteration plan 2.10. 11:00 by e-mail to customer & mentor

Contents

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

T-76.4115 Software Process Framework

Establishes the ground rules for making software

Enforces certain good work practices and crucial documents allows lots of freedom (and responsibility) for customization

Improving productivity

Minimizing risks requires some overhead higher productivity in the long run

Process documentation http://www.soberit.hut.fi/T-76.4115/06-07/instructions/process.html

Process Should Match the Context

Challenges in the typical T-76.4115 context no existing, common development culture within the team 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 the process (work practices, tools etc.) is part of project planning.

Have you already found other challenges?

Project Control Variables

Quality ”fixed” high quality recommended some alleviations to carefully selected quality aspects are allowed if that is

beneficial for the customer

Calendar time fixed project schedule defined by the course major control points such as iteration demos fixed

Effort fixed 150h/person (+2*20h if taking T-76.5158)

Scope flexible adjusted depending on the groups’ skills and knowledge of the problem domain

Effort Distribution in old T-76.4115 Projects

0,00 %

5,00 %

10,00 %

15,00 %

20,00 %

25,00 %

30,00 %

35,00 %

Iterative Development

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

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 deliverables based on customer value group’s effort allocation for the iteration group’s rough effort estimates for implementing sw units group’s briefing about architectural impact

Group concretizes goals and deliverables into tasks re-planning, if task effort estimates and allocated resources differ largely

Iteration Demo

Arranged in the end of each iteration for all project stakeholders

Agenda project status (10-15 min) iteration’s results including sw demo (20-25 min) discussion

Tip! Arrange the next iteration planning meeting right after the iteration demo.

Schedule

Remember the DEADLINES!

Contents

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

Project Management

Planning project planning, iteration planning

Tracking noticing any deviations to the plans

Steering reacting to the deviations

Project Planning

Planning is more important than documenting its results

but documenting is needed in this kind of a project

Project plan ”contract” with the customer basis for tracking and steering

keep up-to-date

Content of the project plan1. Introduction2. Stakeholders and staffing3. Goals4. Resources and budget5. Work practices and tools6. Phasing7. Risk log

Identify Stakeholders and Staffing External

customer, tech. advisor, 3rd parties, mentor, …

Internal project group and its roles sub groups?

Show the relationships between the stakeholders

Contact information emails, phones, web pages, wiki etc.

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 will be evaluated against these goals

Define personal learning goals separately!

Resources and Budget

Personnel 150 or 190 hours/person effort distribution 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

Analyze the major challenges in the project context

Plan which practices and tools you will use and how

Document the practices shortly all stakeholders need to know what to do

Make sure the practices are deployed and the usage is visible to the mentor

Continuous process improvement reflection workshop in the end of iterations analyze practices in the final report

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

Iterations fixed

Add important events to the general project schedule internal milestones

Plan tentative goals and deliverables for each iterations with the customer

Tentative plans are refined during iteration planning make PP iteration plan immediately

Project Tracking

Communication Time tracking Documenting Risk management Process improvement Iteration demo

Communication

Plan efficient communication channels between all stakeholders physical distribution

Who needs what information and when? provide enough information, but avoid information overflow

For example regular meetings e-mail lists discussion forum status reports project metrics project web pages

documents, source code and executable program

TikiWiki accounts will be created tomorrow.

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, Excel, … personal reporting daily

reliability weekly summaries

on project’s web page

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 to the course by iteration’s last Monday 11:00 am

Risk Management

Risk identification involve all stakeholders

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 kick-off

good team spirit is crucial get to know each other discuss roles and responsibilities find out about each other’s

commitments and personal interests

Test unfamiliar technologies and tools early to minimize risks

Start work immediately in the beginning of iterations

more calendar time to react to unexpected situations

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

Software Process – Requirements Engineering

Making sure that the project’s results solve the customer’s problem

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 “content” of the requirements 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 – Project Level What are the most important quality goals?

e.g. among explicitly stated non-functional requirements, implicit customer expectations, project goals and project risks

for which parts of the system are the goals relevant

What practices are performed in order to achieve the quality goals? testing levels, test types, other QA practices a quality palette (see QA report)

How, when and by whom are the QA practices performed?

What kind of QA materials are produced test cases and their documentation test data, test logs, defects reports, utilities such as scripts etc.

How the QA information is utilized? for evaluation of quality status, for providing feedback to steering the project etc.

What metrics are used to evaluate the quality status in the end of each iteration

Planning QA – Iteration Level

For what functionality, when and by whom are the QA practices performed?

How many times and when certain tests are executed (test rounds)? some tests may be executed continuously (smoke tests) some tests may be executed earlier in the iteration if major bugs are found and fixed, how the system is regression tested?

What hardware, software, test environments and test data are needed?

Performing QA – Functional Testing

Test case based (TCB) testing pre-designed test cases based on requirements must be used for at least 50% of the requirements

Exploratory testing continually adjusted plans re-focusing on the most promising risk areas, following hunches minimize the time spent on documentation session based test management (SBTM)

test session charters may be used instead of TCB for <50% of the requirements

can always complement TCB

Reporting QA

Communicating the project's quality status status of project's quality goals quality status of the different parts of the system characterizing what the status evaluation is based on

QA report used QA practices (quality palette) quality status

quality goals, metrics, quality dashboard

Quality Palette

Which QA practices were used and how much? plan and realization

What was the contribution of each QA practice?

Quality Dashboard

Quick overview of the quality status

Defect Tracking

Ensure that found defects are handled defect = bug, change request, idea, …

Defect tracking process how to report defects how to decide which reports will be implemented and when who tests the implemented changes and when how to provide access to the reports for all project stakeholders.

Defect status evaluate found defects before the end of each iteration resolve at least all major defects list open defects in the end of the project

Peer Testing

Peer groups test each other’s systems in I2 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

Peer groups will be announced soon!

Quality Assurance – Mandatory Practices

Contents

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

Design

Implementation

Identify architecturally significant requirements Create architecture description

iteratively first based on the most important requirements different views

Validate architecture does it address the significant requirements

New guidelines coming soon!

Implementation - Mandatory Practices

Contents

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

Iterations - Project Planning (PP) Iteration planning

customer is only in a minor role work plan for the next ~3 weeks how are you going to do project

planning and requirements elicitation plan tasks, resources, schedule

Project planning

Requirements engineering business goals, main domain concepts,

user groups list of requirements

name & short description

Deliveries Project plan (except ch. 5.2 QA plan) Requirements document

(except details in ch 6-8) Progress report

Design initial drafts of the system architecture selecting the implementation

technologies

Iteration demo present the project plan and req.

document

Iterations - Implementation 1 (I1) QA plan for the whole project and for

the I1 iteration

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 SEPA diaries (T-76.5158)

Iterations - Implementation 2 (I2) QA plan for the I2 iteration

including utilizing the peer testing

RE, design, implement, QA keep a demo to the customer in the

middle of the iteration (1.2.2006)

Create the User’s manual

Finalize technical documentation

Deliver to the peer testing fix critical defects

Deliver to the customer installation/training?

Evaluate your work and the course

Deliveries Implemented software

Project plan Requirements document Technical specification Test cases Test report and test log

User's manual Final report SEPA diaries (T-76.5633)

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 Session for Project Managers

Tu 3.10. 16:15 - ~18:00 @ T1 e-mail your questions and proposals for discussion topics by Mo 2.10.

14:00 Teachers will prepare agenda for the session Prepare to present your questions and tell your own experiences and

solutions language Finnish