product documentation process infosys technologies ltd. bangalore
TRANSCRIPT
Product Documentation ProcessProduct Documentation Process
Infosys Technologies Ltd.
Bangalore
Agenda
Product documentation processes
Synergizing documentation process with product development cycle
Product development processes
Static v/s dynamic product documentation
Results
Life cycle
Two sides of the ladder
Product Development Cycle Documentation Cycle
Client meeting
Software requirements
High level design stage
Low level design stage
Coding
Testing
Testing fixes
Product release
Product closure activities
No direct involvement
Offline review
Participating review
Participating review
Analysis and draft stage
Reviews/rework
Reconciliation in manuals
Documentation release
Project closure activities
Client Meeting No direct involvement
Product Schedule Doc Schedule
Software Requirements
Offline review
Understand product functionality
High Level Design (HLD)
Is a macro-level blue print of the project
Developers are more open to suggestions
Active participation
Doc team is aware of the functionality of the product
Inputs to create user friendly interface
Product Schedule Doc Schedule
Low Level Design (LLD)
Micro-level design specs for coding
Start analysis
Knowledge gaining cycle is complete
Develop analysis document
Analysis - crucially important
Involves understanding the functionality and its translation into user manual/s
Writing the analysis document
Exact content of user manuals
User interface screens
Descriptions of screens/fields in a screen, their significance and usage
Conceptual explanation
Analysis - Plus Points
Reduces cycle time and effort redundancy for authors
Helps maintain consistency across manuals
Reduces review time of each manual/s for engineering group
A tech review of the analysis doc traps mistakes in understanding / communication of functionality early in the life cycle
Coding Draft Analysis document is the base
Prepare skeletal structure
Prepare draft of manual
Product Schedule Doc Schedule
Testing Review and Rework
Ideally:
2 tech reviews - Engg. Team / User Education Team
1 Self Review, 1 Intra-group Review
Rework by author
Accuracy of technical functionality
Gaps in information
Clarity of writing
Logical sequence of information
Compliance with doc standards
Accuracy of screens and field descriptions
Formatting, style of writing
Grammatical errors
Missing / repetition of information
Tech Review Checks Intra Group Review Checks
Self Review Checks
Testing fixes Reconciliation in manuals
Doc testing may be taken up by Product Testing Team Defects / bugs trapped before the client receives the product Discrepancies between software and documentation spotted Authors rework the documentation
Documentation in required media productionized
Product Schedule Doc Schedule
Product Release Documentation Release
Software released to the customer
One product version One documentation
version
Product Schedule Doc Schedule
Static Product
Dynamic Product
Product Version Maintenance releases
Major product release
Documentation Version Release notes only
Updated documentation release (with previous release notes reconciled)
Qualitative & Quantitative Results
The process results in
Knowledge sharing
Domain enriched writers
Increased accountability for the end product
Concise, comprehensive, user-friendly documentation
User-oriented testing
Fewer customer help desk calls
To Summarize
Process - Product v/s documentation
Analysis
Draft preparation
Reviews
Rework
Version control management
Signoff with acceptable results
User acceptance