1. Collaborative Documentation for an Evolving Product Presented by Premila Louis & Arati Crasta

2. Agenda  What do we mean by ‘Collaborative Documentation for an Evolving Product’  Data Warehouse (DW) technology & Business Intelligence (BI) - concept and overview  Our Product - FLEXCUBE Information Center  Where We come in - SDLC and Documentation Development Life Cycle  Documentation for Traditional and Evolving Products - a comparison  Making ends meet - Deliverables

3. What do we mean by Collaborative Documentation for an Evolving Product...  According to the Merriam Webster’s dictionary, to ‘ collaborate,’ means ‘to work jointly with others or together especially in a intellectual endeavor’ and ‘ evolving ’ means ‘ a process of continuous change from a lower, simpler, or worse to a higher, more complex, or better state’.  In simple terms it means ‘working jointly with others (SME’s) to deliver documentation for a product undergoing continuous change’.  FLEXCUBE Information Center (FIC), the product that we at the Center for Business Intelligence (CBI) at i-flex have developed is based on the dynamic, emerging technology - Data Warehouse

4. Data Warehouse - an overview Evolution  DWH was introduced as a concept 25 years ago and emerged into technology only 5-6 years back.  Data stored in a consistent manner was mainly accessed for query and reporting.  From mere information management DWH evolved into Business Intelligence where information was used in a business understandable form for analytics and decision-making.  Business Intelligence has now given way to Knowledge Management.

5. Data Warehouse - an overview Definition  It is a collection of non-volatile, subject-oriented, time-variant, integrated data - stored and maintained for decision support within an organization. Features Centralized analytical database Data extraction from various sources Data integrated, transformed and cleansed Designed for informational breadth and query performance

6. What is Business Intelligence (BI)? Business Intelligence is the process of using data to discover knowledge that can be used in decision making and presenting this knowledge in a user comprehensible form. –Blends data into organizational knowledge –Facilitates seamless access to Information –Layered Business Analytical Solutions –Packaged with a proven methodology –A rule-based Intelligent framework –Portal based Knowledge delivery

7. FLEXCUBE Information Center (FIC)  A complete end-to-end Information Management Solution from Data Extraction through to Information Delivery.  Business Intelligence through Business Solution Packs.  Powerful Metadata Framework & Architecture  Portal based delivery  Intelligence Enabled through IntelliFramework

8. FIC - Iterative Methodology  Continuous Integration  Frequent executable releases  Incorporation of changes in future iterations without disrupting ongoing production  Results achieved in a short time span  Project’s support teams - testers, technical writers, QA etc., can plan work effectively

9. Where We come in - SDLC & DDLC Software Development Life Cycle (SDLC) The entire FIC product lifecycle is described in the illustration below.

10. Where We come in - SDLC & DDLC contd... Documentation Development Life Cycle (DDLC)  Requirements Study Phase –Understanding the Requirement Specifications –Review the RS –Prepare the skeletal structure TOC, Chapters, Appendices

11.  Design Study Phase –Review the Design Specifications –Design the prototype –Based on the evaluation of the prototype GUI is prepared –Design Review meetings –Decide Online Help/ User Manual precedence  Draft User Manual / Online Help –Documentation Team assigned task of drafting User Manuals for separate components –Begins at the end of the Construction phase –Spans the Component Assembly and Integration phase Where We come in - SDLC & DDLC contd...

12.  Self and Peer Reviews –Compliance with documentation standards –Review formatting, style and voice –Grammatical errors and spell check –No redundant information  Technical Reviews –During Component Integration phase –Members of the technical team review the draft User Manual –Logical sequence of information –Detect gaps in the information provided –Reviews are baselined Where We come in - SDLC & DDLC contd...

13.  Rework –Happens during the Component Integration phase round 2 –Review comments received are incorporated and sent for second review –Online Help is created or vice-versa  Reconciliation of the UM & OH –At this stage both the user manual and the online help is completed –The UM and OH are checked for discrepancies (if any) Where We come in - SDLC & DDLC contd...

14. Where We come in - SDLC & DDLC contd....  UM/OH Testing –With the completed UM –Manual vis-à-vis the software –SQA comments On content, logical sequence, documentation standards and quality  Final Rework and baseline –SQA comments are incorporated –SQA re-checks UM/OH and baselines it –Ready for shipping

15. Traditional ProductsEvolving Products  Requirements are frozen for entire release  Requirements happen on an on-going basis and are frozen for every iteration Requirement Phase Documentation for Traditional & Evolving Products - a comparison

16. Documentation for Traditional & Evolving Products - a comparison (contd.…)  Prototype designed on the basis of the RS  Documentation Team organizes the UM in terms of CHAPTERS, TOC etc. and prepare the draft based on the RS and DS  Design and Construction phase are combined  Documentation (Doc) team constantly reviews the DS  Only a skeletal structure of content of the draft UM is prepared for the current iteration Design Phase Traditional ProductsEvolving Products

17. Documentation for Traditional & Evolving Products - a comparison (contd.…)  Coding done as per the RS and DS  Doc team progresses with the draft of the UM  At this stage a considerable amount of the draft is completed, except for the screens, error messages etc.  Coding is part of the Design and Construction phase  Doc team in constant collaboration with the technical team prepares the draft of the UM  Changes in the Design occur in every iteration. Without collaboration it is difficult to keep track of the changes Coding Traditional ProductsEvolving Products

18. Documentation for Traditional & Evolving Products - a comparison (contd.…)  Every module is tested individually  Every module in the UM is reviewed by the technical team  Self and Peer review is completed for documentation standards, grammar and spellings etc  Components are equivalent to Modules  Many logical units constitute a component.  Logical units need to be assembled which is referred to as Component Assembly.  Doc team is part of the change control meetings and is constantly in sync with the technical team. Module Test Plan Traditional ProductsEvolving Products

19. Documentation for Traditional & Evolving Products - a comparison (contd.…)  The tested modules are integrated.  The doc team receives review comments from the technical team  Component Assembly and Component Integration are combined and work in an iterative mode  Doc team completes draft for each component and UM reviewed during Component Integration by the technical team  Doc team attends change control meetings. Changes in the components are incorporated in the draft. Integrated Test Plan Traditional ProductsEvolving Products

20. Documentation for Traditional & Evolving Products - a comparison (contd.…)  The documentation team incorporates the review comments in the UM  Focus is laid on the overall look and feel of the UM  Doc team incorporates review comments in the draft  Self and peer reviews are completed  Doc team concentrates on the overall presentation of the document  Relevant changes are incorporated in the Online Help in tandem with the UM.  Rework time frame also includes Online Help Rework Traditional ProductsEvolving Products

21. Documentation for Traditional & Evolving Products - a comparison (contd.…)  The UM is tested vis-à-vis the software  User Manual and Online Help are tested vis-à-vis the software  Many rounds of testing are done prior to system testing  Both UM and OH are completed prior to System testing  Software Quality Assurance (SQA) group reviews the document and help for consistency, accuracy, presentation before base-lining System Testing Traditional ProductsEvolving Products

22. Making ends meet - Deliverables  User Documentation (Installation, Implementation, User, Operations manual) / Online Manual  Online Help  Training Material  Computer Based Training

23. For further details… Visit our Website: www.iflexsolutions.com Mail us at premila.louis@iflexsolutions.com / arati.crasta@iflexsolutions.com Address: i-flex solutions limited i-flex Center #146, Infantry Road Bangalore - 560 001

24. THANK YOU!