T-76.4115 Software Process Framework - SoberIT

rangaleclickSoftware and s/w Development

Nov 4, 2013 (3 years and 7 months ago)

85 views

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