1. 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)

2. Course Arrangements  Mentors and peer groups have been assigned  Contracts  sign one copy and send it to the teacher  Jari Vanhanen, SoberIT, PL 9210, 02015 TKK  include YOUR address  A218 accounts created  MagicDraw available  Wiki, Bugzilla, and Delivery system accounts created soon  Deadline for the Iteration plan Fr 5.10. 11:00  by e-mail to customer & mentor  Iteration demo schedule preferences  23.-24.10. 8:00-18:00

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 typical 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 the process (work practices, tools etc.) is part of project planning. Have you already found other challenges?

5. T-76.4115 Software Process Framework  Helps the groups define how they are going to do the work  Enforces certain good work practices and crucial documents  allows lots of freedom (and responsibility) for customization  Minimizing risks requires some “overhead” Process documentation http://www.soberit.hut.fi/T-76.4115/07-08/instructions/process.htmlhttp://www.soberit.hut.fi/T-76.4115/07-08/instructions/process.html

6. T-76.4115 Software Process Framework  Instructions and templates  Mandatory practices  written as “group must do xxx”  summarized in Process overview Chapter 3

7. 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 (+40h if taking T-76.5158)  Scope flexible  adjusted depending on the groups’ skills and knowledge of the problem domain

8. T-76.4115 Typical Effort Distribution

9. 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.

10. Iterations

11. 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

12. 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.

13. Contents  Software process framework  Project management  Requirement engineering  Quality assurance  Design & implementation  Iterations

14. Project Management  Planning  planning is more important than documenting its results  but documenting is needed in this kind of a project  Tracking  noticing any deviations to the plans  Steering  reacting to the deviations

15. 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 ”contract” with the customer basis for tracking and steering

16. Identify Stakeholders and Staffing  External  customer, tech. advisor, 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, web pages etc. You are allowed to rotate or change the assigned roles within the group.

17. 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!

18. Resources and Budget  Personnel  150h or something else per person  effort allocation between iterations  how many hours per person in PP  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”

19. 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  Make sure the practices are deployed  and the usage is visible to the mentor  Continuous process improvement  reflection workshop in the end of iterations  present action points in progress report  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

20. Phasing  Iterations 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

21. Project Tracking  Communication  Time tracking  Documenting  Risk management  Process improvement  Iteration demo

22. 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  regular meetings  Skype conference calls  e-mail lists  discussion forum  status reports  project metrics  project web pages/Wiki  documents, source code and executable program

23. 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 a web page

24. 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

25. 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

26. 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

27. Project Management – Mandatory Practices

28. Contents  Software process framework  Project management  Requirement engineering  Quality assurance  Design & implementation  Iterations

29. 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”

30. Elicitation Find out using any possible means: business goals main domain concepts user groups requirements 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 IterationsPP Iteration Change management, status tracking, tracing In practice many activities are parallel and iterative! Requirements Engineering

31. 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

32. Requirements Engineering - Mandatory Practices

33. Contents  Software process framework  Project management  Requirement engineering  Quality assurance  Design & implementation  Iterations

34. 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

35. Planning QA  Identify the most important quality goals  e.g. among non-functional requirements, implicit customer expectations, project goals and project 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)  a quality palette (see QA report)  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

36. 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 - Ssssion Based Test Management (SBTM)  45-120 minutes  test session charters  exploration log  ET may be used instead of TCB for <50% of the functional requirements  can always complement TCB

37. Reporting QA - Quality Palette  Which QA practices were used?  What was the contribution of each QA practice?

38. 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

39. 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

40. 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

41. Quality Assurance – Mandatory Practices

42. Contents  Software process framework  Project management  Requirement engineering  Quality assurance  Design & implementation  Iterations

43. Design  Architecture design  Identify architecturally significant requirements  Create architecture description  based on the most important requirements  functional and development views  Validate architecture  does it address the significant requirements  Construction design  class diagrams  error handlng  database schema definitions  …  Documenting design  negotiate with the customer

44. Software Process – Design and Implementation

45. Contents  Software process framework  Project management  Requirement engineering  Quality assurance  Design & implementation  Iterations

46. Iterations - Project Planning (PP)  Iteration planning  customer is only in a minor role  work plan for the next ~3 weeks  plan for project planning and requirements elicitation  tasks, resources, schedule  Project planning  goals, resources, work practices  Adoption of all relevant practices  communication  time tracking  documenting  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

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

48. Iterations - Implementation 2 (I2)  Iteration planning  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  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  Test report and test log  User's manual  Final report  SEPA diaries (T-76.5158)

49. 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  …

50. Experience Exchange Sessions  SoberIT, Innopoli2, seminar hall 16:15 - 18:00  Tu 9.10. Project managers  Tu 16.10. QA managers (focus on RE)  Tu 30.10. QA managers (focus on QA)  Tu 6.11. Project managers  Tu 13.11. Architects  Two persons per group may participate  e-mail your proposals for discussion by previous day 16:00  Teachers will prepare agenda for the session  Discussion language Finnish