T-76.4115/5115 Software Development Project I/II Software Development Process Framework

1. T-76.4115/5115Software Development Project I/IISoftware Development Process Framework Jari Vanhanen Ohjelmistoliiketoiminnan ja –tuotannon laboratorio Software Business and Engineering Institute (SoberIT)

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

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

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

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

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

7. Effort Distribution in old T-76.4115 Projects

8. Iterative Development • Why iterations? • regular control points • force packaging the results • enable giving feedback

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

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

11. Schedule • Remember the DEADLINES!

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

13. Project Management • Planning • project planning, iteration planning • Tracking • noticing any deviations to the plans • Steering • reacting to the deviations

14. 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 plan 1. Introduction 2. Stakeholders and staffing 3. Goals 4. Resources and budget 5. Work practices and tools 6. Phasing 7. Risk log Project Planning

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

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

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

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

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

20. Project Tracking • Communication • Time tracking • Documenting • Risk management • Process improvement • Iteration demo

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

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

23. 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 Documenting

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

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

26. Project Management – Mandatory Practices

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

28. Software Process – Requirements Engineering • Making sure that the project’s results solve the customer’s problem

29. Requirements Engineering PP Iteration I1&I2 Iterations Elicitation Find out using any possible means: • business goals • main domain concepts • user groups • requirements Analysis Re-estimate the “most important” requirements Iteration planning Choose iteration’s requirements Analysis Analyze the gathered information. List identified requirements shortly. Estimate roughly: customer value, effort, architectural impact. Representation Find out the details of iteration’s requirements Change management, status tracking, tracing Validation Review iteration’s requirements. Get customer’s approval. (Re-)Analysis Re-estimate required effort. Ensure realism of the plan. In practice many activities are parallel and iterative! Implementation, QA, Delivery Collect feedback from the customer

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

31. Requirements Engineering - Mandatory Practices

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

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

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

35. 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?

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

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

38. Quality Palette • Which QA practices were used and how much? • plan and realization • What was the contribution of each QA practice?

39. Quality Dashboard • Quick overview of the quality status

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

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

42. Quality Assurance – Mandatory Practices

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

44. Design • 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

45. Implementation - Mandatory Practices

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

47. 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 Iterations - Project Planning (PP) • Design • initial drafts of the system architecture • selecting the implementation technologies • Iteration demo • present the project plan and req. document

48. 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 1 (I1)

49. 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) Iterations - Implementation 2 (I2)

50. 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 • …