T76.41155115 Software Development Project III Software Development Process

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

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

2
Contents

• Software process framework
• Mandatory requirements
• Iterations

3
Software Process Challenges on T-76.4115

• Project is done for an external customer
• understanding the true (and changing) needs
• -gt requirements engineering during the whole
  project
• -gt managing customers expectations
• Physical distribution
• all stakeholders and group members are physically
  distributed
• not necessarily any common work place
• -gt special care for communication and increasing
  project visibility
• communication practices, reporting, iterative
  development, risk management
• Temporal distribution
• only one of several on-going projects for all
  participants
• long duration, but only 1-2 days a week
• -gt documentation overhead, you cant keep
  everything in your head
• No existing, common development culture within
  the team (process)
• people are not necessarily familiar with each
  other
• -gt process must be planned from scratch and
  communicated to everyone

4
T-76.4115 Software Process Framework

• A process framework is provided by the course
• establishes the ground rules for making software
• enforces certain good work practices and crucial
  documents
• allows lots of freedom (and responsibility) for
  customization
• Described in the following documents (and
  templates)
• Process framework overview
• Project planning (project plan)
• Requirements engineering (requirements document)
• Design
• Quality assurance (test report)
• See the Instructions web page

5
Software Process - Iterative and Incremental

• Implementation iteration is a miniature project
• specify, design, code, test, deliver
• varying emphasis
• Iteration produces an increment
• adds new functionality and refines previously
  implemented parts
• Increment generates feedback
• concrete results

• Increment reveals the project status
• must be tested and bugs resolved, i.e., the true
  quality must be known
• Use-case driven and architecture-centric process
• identify (key) use cases
• create baseline architecture based on most
  important use cases for
• architecture (technical risk)
• customer (business value)
• add use cases on top of the baseline

6
Software Process - Iterations
7
Software Process 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
• Effort fixed
• 150h/person (-25h if 5p, 20h if T-76.5633)
• Scope flexible
• adjusted depending on the groups skills and
  knowledge of the problem domain

8
Contents

• Software process framework
• Mandatory practices
• Iterations

9
Software Process Mandatory requirements

• Mandatory practices
• iterative development
• iteration planning
• documenting
• risk management
• time reporting
• software size reporting
• communication
• iteration demo
• version control
• coding convention
• defect tracking
• peer testing

• Other mandatory requirements
• project planning
• requirements engineering
• planning and performing QA
• Documented using bolded must sentences

10
Iteration Planning

• Plan the iterations goals and deliverables
  together with the customer
• goals are higher level ideas of what is expected
  from the iteration
• deliverables include software units and documents
  to be created/updated
• Have an iteration planning meeting with the
  customer
• group tells the allocated effort for the
  implementation work in the iteration
• customer selects and prioritizes what is
  implemented next based on
• business importance
• groups rough effort estimates for implementing
  sw units
• estimate the most probable sw units before the
  meeting
• groups technical briefing about the chosen
  implementation order
• Group concretizes goals and deliverables into
  required tasks
• re-planning, if task effort estimates and
  allocated resources differ largely
• Identify the most important dates during the
  iteration
• E-mail the iteration plan to all stakeholders

Not in PP iteration
11
Documentation

• Required project documents
• project plan
• including QA plan and description of work
  practices
• requirements document
• technical specification
• users manual
• test 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
• update documents in each iteration
• use a change log
• clear and compact form
• once and only once (avoid duplication, use
  links/references)
• number items (reqs, tests, )
• spelling checker
• printability
• Deliver documents (HTML/PDF/PPT) by iterations
  last Monday 1300

12
Risk Management

• Risk identification
• involve all stakeholders
• Risk analyzing
• for the most important risks analyze
• risk factors
• 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

13
Time reporting

• Crucial for
• following the resource usage in a fixed effort
  project
• for learning
• Adopt some reporting system
• some web tool, Excel, mails to project manager,
• typical attributes for a reporting entry
• task ID, day, effort done, work type, performer,
  explanation, estimated effort left, estimated
  finish date
• For learning purposes you can use work type
  classifications
• Maintain a weekly updated task list on a web page
  showing
• original effort estimate per task
• realized and remaining effort per task
• sum of realized effort per person per iteration

14
Software size reporting

• Lines of Code (LOC) is inaccurate, but easily
  collected metric characterizing system size
• requires interpretation
• e.g. after code refactoring decreasing size
  indicates progress
• LOC must be reported in the end of iterations
• Tip
• StatCVS generates a graph from a CVS repository

15
Communication

• In a distributed project some effort is needed
  for building effective and efficient
  communication channels
• For example
• regular meetings
• project web pages
• e-mail lists
• discussion forum
• status reports
• project metrics
• sharing documents, source code and executable
  program
• Tools
• phone, e-mail, Wiki, version control tool,

16
Iteration Demo

• Arranged in the end of each iteration
• 19.-20.10., 7.-8.12., 1.-2.3.
• exact times (We Th 800-1900) published in
  early October
• at SoberIT (Innopoli 2, 4th floor, Tekniikantie
  14)
• Participants
• all project stakeholders
• Group presents
• project status (10-15 min)
• iterations results including sw demo (20-25 min)
• see the template (progress report)
• Customer evaluates the work performed
• private discussion about the given points with
  the mentor after the review
• sends/tells the comments about the evaluation to
  the group

Tip! Arrange the iteration planning meeting right
after the iteration demo.
17
Other mandatory practices

• Version control
• use a version control tool
• define usage conventions (check-out/check-in
  frequency, change log, tagging)
• Coding convention
• use some defined standard, e.g., Sun Java Coding
  Conventions
• Defect tracking
• Track defects and define a change management
  policy
• Peer testing
• provide system to the peer group for testing and
  test the peer group's system

18
Other mandatory process requirements

• Project Planning
• see PP iteration
• Requirements engineering
• specify the requirements in co-operation with the
  customer
• prioritize all types of requirements with the
  customer
• trace functional and non-functional requirements
  to use cases and vice versa
• track the status of each requirement during the
  project
• manage changes to approved requirements
• Planning QA
• make the project level QA plan
• major quality goals
• means for achieving the quality goals
• testing levels, testing types (usability,
  reliability, ) and other QA activities
• refine the QA plan for each iteration
• what will be tested
• test environments, test data and test rounds
• resources, schedule

19
Other 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
• Process construction and tuning
• Meeting practices

20
Process visibility

• The plan should
• communicate how to follow the practices
• short, concrete descriptions, examples, training
  slides
• give an overview of the practices for the
  customer and mentor 
• allows commenting
• Make the mentor confident about your conformance
  to the process
• the plan does not show that the practices are
  really used
• Innovative, low overhead approaches are
  encouraged
• build trust between the group and the mentor
• show work products generated by the use of some
  practice
• e.g. code review notes
• invite the mentor to the groups reflection
  meeting where the group discusses and improves
  their work practices
• invite the mentor to watch you while you work
• e.g. participation to a requirements elicitation
  meeting with a customer

21
Contents

• Software process framework
• Mandatory practices
• Iterations

22
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
• see next lecture
• Requirements engineering
• project's business goals
• main domain concepts
• user groups
• functional and non-functional requirements
• use cases (name short description)

• Design
• initial drafts of the system architecture
• selecting the implementation technologies
• Iteration demo
• present the project plan and req. document

• Deliveries
• Project plan (except ch. 5.3 QA plan)
• Requirements document(ch. 1-5, ch. 6-9 at least
  most important requirements, ch. 11-12)
• Progress report

23
Iterations - Implementation Iterations (general)

• Iteration planning
• including QA planning
• Analyze-design-code-test
• analyze the selected use cases in detail
• write use case descriptions
• design the implementation of the use cases
• documenting before/after implementation?
• code
• test
• information for understanding the true status of
  the developed increment
• Delivery of documents and software
• Iteration demo

24
Iterations - Implementation 1 (I1)

• Plan the QA approach for the whole project and
  for this iteration
• Iteration planning
• architectural importance
• business value
• Analyze, design, implement, test
• Decide about technical documentation
• level of detail, format,
• Deliver the system to the customer

• Deliveries
• Project plan (especially ch. 5.3)
• Requirements document
• Technical specification(at least the general
  architecture)
• Test cases
• Test report and test log
• Progress report
• SEPA diaries (T-76.5633)

25
Iterations - Implementation 2 (I2)

• Plan the QA approach for the iteration
• including utilizing the peer testing
• Analyze, design, implement, test
• keep a demo to the customer in the middle of the
  iteration
• Create the Users manual
• 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)