Download to read offline
Uploaded byCEE-SEC(R)
Who Needs Documentation Anyway?
This document discusses documentation in software development. It explains that documentation is needed to support communication, enable informed decision making, minimize risks from staff rotation, and allow for traceability. The amount of documentation depends on factors like the project size and risks. Both traditional and agile methodologies require some documentation, though agile calls for less upfront documentation. Quality assurance and audits often require documentation to evaluate areas like requirements, testing, and configuration management. The document provides examples of documentation from frameworks like RUP, OpenUP, ISO standards, and CMMI. It advocates establishing clear documentation policies and practices tailored to each organization's needs.
More Related Content
Similar to Who Needs Documentation Anyway?
Who Needs Documentation Anyway?
- 1.
- 2. Agenda Why, whoand how much documentation? Documentation in different SDLCs Documentation from the QA perspective IT Audits, security audit ISO, CMMI appraisals Documentation best practices ground rule policy documentation throughout the project/product lifecycle
- 3. Why we needdocumentation? to support communication make informed decisions to minimize risk of staff rotation enable traceability
- 4. Who needs documentation? to support communication Team (internal, partners, subcontractors) Management (team lead, project manager) Client (technical team, users) make informed decisions PM, IT director, CEO client's management (project level & company level) to minimize risk of staff rotation development team enable traceability QA team, internal auditors, external auditors
- 5. How much documentation? depends on many factors domain, project (size, type, risks, no. of participants), SDLC, regulatory requirements, organization, etc. start with more and trim down if not useful understand the purpose of every document or information container understand the risks of not having documentation don't produce documents to justify spending documentation might be time dependent
- 6. SDLC & documentation good process will define project artifacts provide guidelines on how to tailor (mandatory vs. optional) different templates for more formal and lean projects required by the SDLC, but not used not defined in SDLC, but would be useful documentation can be in different form is burn down chart documentation? information in Jira, Confluence, Trello, etc.
- 7. Examples – IBMRUP 9 domains 76 work products
- 8. Examples - OpenUP 7 disciplines 29 (only) work products
- 9. Examples - SCRUM Source:Essential SCRUM: A Practical Guide to Most Popular Agile Process
- 10. Traditional vs. Agile Source:http://www.agilemodeling.com/essays/agileDocumentationBestPractices.htm
- 11. Documentation & QA Can we do quality assurance without documentation? How can we do IT audit without documentation? example: outsourced government project that went bad Can we replace team member or vendor without documentation?
- 12. Example: IT audit Typical documentation (depends on audit goals) software requirements specification high level architecture description of the SDLC quality plan, test plan, test data, test reports change management & configuration management If efficiency and costs are also evaluated project plan project data – plan vs. actual
- 13. 1205 Evidence Source: ISACA,ITAF 2nd edition
- 14. Example: security audit Typical documentation (depends on the goals) penetration testing no documentation required security audit user manual software requirements specification risk evaluation technical documentation (key security concepts – encryption, implementation of Access Control List, access controls, etc.) network schema SDLC
- 15.
- 16.
- 17. CMMI & documentation Model does not specify documents, it defines goals and practices (specific and generic) specific goal (SG 2) Develop a project plan A project plan is established and maintained as the basis for managing the project. Fulfilling goals without any documentation might be difficult. In some cases CMMI is more specific about the expectations SP 1.1-1 Estimate the scope of the project Establish a top-level work breakdown structure (WBS) to estimate the scope of the project.
- 18. Documentation best practices Documentation is necessary! How much and when, depends on many factors. Every company/group should tailor the documentation. Have a clear policy what can be changed and how.
- 19.
Editor's Notes
- #8 Domains: Analysis and Design Business Modeling Configuration & Change Management Deployment Environment Implementation Project Management Requirements Test
- #9 Disciplines Architecture Deployment Development Environment Project Management Requirements Test
- #10 This year I was working with two teams, one using OpenUP and one using SCRUM, the OpanUP team had very smooth start, since they new exactly what to do, the SCRUM team was struggling a lot since they did not know exactly what to do and how – at the operational level.
- #11 Here emphasize on the last part – documentation in the late stage.