DOCSLIB.ORG

Changing the Mode of Software Documentation with Lean Model of Software Development

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Changing the Mode of Software Documentation with Lean Model of Software Development Siemens Corporate Technology | May 2015 Changing the Mode of Software Documentation with Lean Model of Software Development Unrestricted use only / © Siemens AG 2015. All rights reserved. Changing the mode of software documentation with Lean model of software development – A case study of adaptations and improvements Table of contents Understanding DDLC Aligning DDLC with Waterfall and V Model Aligning DDLC with Agile Model Implementing Lean Model of Software Development Lessons Learnt Page 2 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. DDLC is a methodology for creating structured documentation Analysis Publishing and Design Final Release Documentation Development Life Cycle Content Translation Development Review Page 3 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Synchronizing DDLC with SDLC is a must DDLC SDLC Audience Project Planning Profiling User-task Requirements Analysis Definition Information Design Architecture Content Development Development Technical and Integration and Editorial Review Testing Formatting and Installation and Publishing Acceptance • Each of the steps in the DDLC is always synchronized with each steps in the SDLC. Page 4 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Changing the mode of software documentation with Lean model of software development – A case study of adaptations and improvements Table of contents Understanding DDLC Aligning DDLC with Waterfall and V Model Aligning DDLC with Agile Model Implementing Lean Model of Software Development Lessons Learnt Page 5 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. DDLC was initially synchronized with Waterfall and V model Waterfall Model V Model Sequential design process, which is seen as flowing Extension of the waterfall model, which steadily downwards through the phases of Conception, demonstrates the relationships between each Initiation, Analysis, Design, Construction, Testing, phase of the development life cycle and its Production/Implementation, and Maintenance. associated phase of testing in a V-shape. Page 6 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Synchronizing DDLC with sequential models of product development leads to critical challenges Less time, more • Completion of most of the tasks encapsulated in the DDLC during the tasks testing and acceptance phase of the software development. Last minute • Incorporation of last minute customer critical updates in multiple updates documents at a short notice in a short duration. • Selection of an appropriate translation technology , process, and On time resource to translate the documents prior to the release of the translation product. Inadequate • Absence of either any dedicated resources or time allocation to the support from developers for discussion with the documentation team. development team Page 7 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Changing the mode of software documentation with Lean model of software development – A case study of adaptations and improvements Table of contents Understanding DDLC Aligning DDLC with Waterfall and V Model Aligning DDLC with Agile Model Implementing Lean Model of Software Development Lessons Learnt Page 8 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Advent of Agile model minimized drawbacks of the sequential development models Incremental model of software development Customer satisfaction by rapid and continuous delivery of useful software Emphasis on people and communication instead of process and tools Frequent delivery of working software (weeks instead of months) Close and daily cooperation between business people and developers Continuous attention to technical excellence and good design Regular adaptation to changing circumstances and requirements Page 9 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Projects started getting aligned gradually to Scrum model of development Scrum is an iterative and incremental Agile software model of development. Software is developed in incremental, rapid cycles resulting in small incremental releases with each release building on previous functionality. Page 10 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Agile model of development also had its share of challenges in DDLC Usable • Creating an usable documentation at the end of every sprint Documentation Inputs received at the end of • Completing the documentation of the feature within the same sprint of every Sprint development in a short duration Non-finalized • Capturing of the screenshots multiple times owing to repeated changes screenshots in the user interface Translation • Translating documents during the development sprints Defect Tracking • Ensuring that the release criteria board for software documentation is green Page 11 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Changing the mode of software documentation with Lean model of software development – A case study of adaptations and improvements Table of contents Understanding DDLC Aligning DDLC with Waterfall and V Model Aligning DDLC with Agile Model Implementing Lean Model of Software Development Lessons Learnt Page 12 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Lean software development is a translation of lean manufacturing and lean IT principles and practices to the software development • Originally called just-in-time production • Adapted from the Toyota Production System Value • Understand how value is perceived by the customer • What adds value to the customer Value • Removes waste from end to end value streams Streaming Flow • Flow cleanly from start to finish Perfection • Seek perfection through continual improvement • Focus of simulation Pull • What pulls the customer Page 13 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Product development structure is modified Team structure Expert Team CPO member PO 1 PO 2 Architecture STT PPO 1 PPO 2 PPO 3 STA Quality TTS 1 TTS 2 TTS 3 TTS 4 TTS 5 TTS 6 Usability Developers (Representatives for Central Function processes) CM Configuration User Architecture Usability UDoc Management Documentation CPO – Chief Product Owner STT – System Testing PO – Product Owner STA – System Test Automation PPO – Part Product Owner CM – Configuration Management TTS – TAKT Team Speaker UDoc – User Documentation Page 14 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. New development model leads to new processes Release Development TAKTS Hardening TAKTS Backlog Requirement Document (BLRD) TAKT Kick-off meeting TAKT Analysis Review meeting Stand up meeting Release criteria board Functional Document for User Documentation (FDUD) Page 15 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Changes for software documentation Modification of Documentation Development Life Cycle Introduction of the role of User Documentation expert Defined responsibilities of User Documentation expert Increased responsibilities of User Documentation expert Introduction of FDUD Page 16 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Responsibilities of a User Documentation Expert Plan and estimate the scope for UDoc Review FDUD Author in source language Translate documents in target languages Review and translate UI messages Track and fix defects Configuration Management tasks Migration Page 17 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Methodology of creating software documentation in LEAN Analysis Create Documentation Review BLRD Release Kick-off requirements backlog Content Development in every TAKT Review FDUD and Review UI message Authoring Technical review Understanding requirement Content Development in every TAKT Documentation in final feature Finalize source content Merge documents to INT build demo Page 18 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Methodology of creating software documentation in LEAN Defect Fixing Analyze defects Fix defect Review Review Online review with Address review comments Merge documents to INT build stakeholders Translation management tasks Pre-translation tasks Post-translation tasks Page 19 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Methodology of creating software documentation in LEAN Content Development in Hardening TAKT Gather inputs for Readme and Product Authoring Final review with stakeholders Information manuals from stakeholders Document Delivery Integrated documents to INT Publish Final Documents Generate CMP label Build Page 20 May 2015 Corporate Technology Unrestricted use only / © Siemens AG 2015. All rights reserved. Case Study – Eliminating waste Created a streamlined process of creating a UI message by eliminating a wastage of 47 % of the effort and time of all the stakeholders using value-stream mapping. Established the principles of passing a defect /test case on User Documentation on the basis of source language documentation. Established the process of effective creation
Load more

Recommended publications
  • Measuring the Software Size of Sliced V-Model Projects
    2014 Joint Conference of the International Workshop on Software Measurement and the International Conference on Software Process and Product Measurement Measuring the Software Size of Sliced V-model Projects Andreas Deuter PHOENIX CONTACT Electronics GmbH Gregor Engels Dringenauer Str. 30 University of Paderborn 31812 Bad Pyrmont, Germany Zukunftsmeile 1 Email: [email protected] 33102 Paderborn, Germany Email: [email protected] Abstract—Companies expect higher productivity of their soft- But, the “manufacturing” of software within the standard ware teams when introducing new software development methods. production process is just a very short process when bringing Productivity is commonly understood as the ratio of output the binaries of the software to the device. This process is hardly created and resources consumed. Whereas the measurement of to optimize and does not reflect the “production of software” the resources consumed is rather straightforward, there are at all. The creation of the software is namely done in the several definitions for counting the output of a software de- developing teams by applying typical software engineering velopment. Source code-based metrics create a set of valuable figures direct from the heart of the software - the code. However, methods. However, to keep up with the high demands on depending on the chosen process model software developers and implementing new functionality (e.g. for PLC) the software testers produce also a fair amount of documentation. Up to development process within these companies must improve. now this output remains uncounted leading to an incomplete Therefore, they start to analyze their software processes in view on the development output. This article addresses this open detail and to identify productivity drivers.
    [Show full text]
  • Introduction to Metamodeling for Reducing Computational Burden Of
    This is a repository copy of Introduction to metamodeling for reducing computational burden of advanced analyses with health economic models : a structured overview of metamodeling methods in a 6-step application process. White Rose Research Online URL for this paper: http://eprints.whiterose.ac.uk/156157/ Version: Accepted Version Article: Degeling, K., IJzerman, M.J., Lavieri, M.S. et al. (2 more authors) (2020) Introduction to metamodeling for reducing computational burden of advanced analyses with health economic models : a structured overview of metamodeling methods in a 6-step application process. Medical Decision Making, 40 (3). pp. 348-363. ISSN 0272-989X https://doi.org/10.1177/0272989X20912233 Degeling, K., IJzerman, M. J., Lavieri, M. S., Strong, M., & Koffijberg, H. (2020). Introduction to Metamodeling for Reducing Computational Burden of Advanced Analyses with Health Economic Models: A Structured Overview of Metamodeling Methods in a 6-Step Application Process. Medical Decision Making, 40(3), 348–363. Copyright © 2020 The Author(s) DOI: 10.1177/0272989X20912233 Reuse Items deposited in White Rose Research Online are protected by copyright, with all rights reserved unless indicated otherwise. They may be downloaded and/or printed for private study, or other acts as permitted by national copyright laws. The publisher or other rights holders may allow further reproduction and re-use of the full text version. This is indicated by the licence information on the White Rose Research Online record for the item. Takedown If you consider content in White Rose Research Online to be in breach of UK law, please notify us by emailing [email protected] including the URL of the record and the reason for the withdrawal request.
    [Show full text]
  • Beyond Accuracy: Assessing Software Documentation Quality
    Beyond Accuracy: Assessing Soware Documentation ality Christoph Treude Justin Middleton Thushari Atapattu [email protected] [email protected] [email protected] University of Adelaide North Carolina State University University of Adelaide Adelaide, SA, Australia Raleigh, NC, United States Adelaide, SA, Australia ABSTRACT provides initial evidence for the strengths and weaknesses of dif- Good software documentation encourages good software engi- ferent genres of documentation (blog articles, reference documen- neering, but the meaning of “good” documentation is vaguely de- tation, README files, Stack Overflow threads, tutorials) based on fined in the software engineering literature. To clarify this ambi- the ten dimensions of our software documentation quality frame- guity, we draw on work from the data and information quality work. community to propose a framework that decomposes documenta- The contributions of this work are: tion quality into ten dimensions of structure, content, and style. To • demonstrate its application, we recruited technical editorsto apply A ten-dimensional framework for asking questions about the framework when evaluating examples from several genres of software documentation quality, • software documentation. We summarise their assessments—for ex- A partially validated survey instrument to evaluate docu- ample, reference documentation and README files excel in quality ment quality over multiple documentation genres, and • whereas blog articles have more problems—and we describe our vi- A vision for the expansion of a unified quality framework sion for reasoning about software documentation quality and for through further experimentation. the expansion and potential of a unified quality framework. 2 BACKGROUND AND RELATED WORK CCS CONCEPTS The most related piece of work to this paper is the seminal 1995 • Software and its engineering → Documentation; • Social article “Beyond Accuracy: What Data Quality Means to Data Con- and professional topics → Quality assurance.
    [Show full text]
  • Software Development a Practical Approach!
    Software Development A Practical Approach! Hans-Petter Halvorsen https://www.halvorsen.blog https://halvorsen.blog Software Development A Practical Approach! Hans-Petter Halvorsen Software Development A Practical Approach! Hans-Petter Halvorsen Copyright © 2020 ISBN: 978-82-691106-0-9 Publisher Identifier: 978-82-691106 https://halvorsen.blog ii Preface The main goal with this document: • To give you an overview of what software engineering is • To take you beyond programming to engineering software What is Software Development? It is a complex process to develop modern and professional software today. This document tries to give a brief overview of Software Development. This document tries to focus on a practical approach regarding Software Development. So why do we need System Engineering? Here are some key factors: • Understand Customer Requirements o What does the customer needs (because they may not know it!) o Transform Customer requirements into working software • Planning o How do we reach our goals? o Will we finish within deadline? o Resources o What can go wrong? • Implementation o What kind of platforms and architecture should be used? o Split your work into manageable pieces iii • Quality and Performance o Make sure the software fulfills the customers’ needs We will learn how to build good (i.e. high quality) software, which includes: • Requirements Specification • Technical Design • Good User Experience (UX) • Improved Code Quality and Implementation • Testing • System Documentation • User Documentation • etc. You will find additional resources on this web page: http://www.halvorsen.blog/documents/programming/software_engineering/ iv Information about the author: Hans-Petter Halvorsen The author currently works at the University of South-Eastern Norway.
    [Show full text]
  • The Developer's Guide to Debugging
    The Developer’s Guide to Debugging Thorsten Grotker¨ · Ulrich Holtmann Holger Keding · Markus Wloka The Developer’s Guide to Debugging 123 Thorsten Gr¨otker Ulrich Holtmann Holger Keding Markus Wloka Internet: http://www.debugging-guide.com Email: [email protected] ISBN: 978-1-4020-5539-3 e-ISBN: 978-1-4020-5540-9 Library of Congress Control Number: 2008929566 c 2008 Springer Science+Business Media B.V. No part of this work may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, microfilming, recording or otherwise, without written permission from the Publisher, with the exception of any material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. Printed on acid-free paper 987654321 springer.com Foreword Of all activities in software development, debugging is probably the one that is hated most. It is guilt-ridden because a technical failure suggests personal fail- ure; because it points the finger at us showing us that we have been wrong. It is time-consuming because we have to rethink every single assumption, every single step from requirements to implementation. Its worst feature though may be that it is unpredictable: You never know how much time it will take you to fix a bug - and whether you’ll be able to fix it at all. Ask a developer for the worst moments in life, and many of them will be related to debugging. It may be 11pm, you’re still working on it, you are just stepping through the program, and that’s when your spouse calls you and asks you when you’ll finally, finally get home, and you try to end the call as soon as possible as you’re losing grip on the carefully memorized observations and deductions.
    [Show full text]
  • Effective Methods for Software Testing
    Effective Methods for Software Testing Third Edition Effective Methods for Software Testing Third Edition William E. Perry Effective Methods for Software Testing, Third Edition Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com Copyright © 2006 by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN-13: 978-0-7645-9837-1 ISBN-10: 0-7645-9837-6 Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 3MA/QV/QU/QW/IN No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copy- right Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at http://www.wiley.com/go/permissions. Limit of Liability/Disclaimer of Warranty: The publisher and the author make no repre- sentations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fit- ness for a particular purpose. No warranty may be created or extended by sales or promo- tional materials.
    [Show full text]
  • Understanding Document for Software Project
    Understanding Document For Software Project Sax burls his lambda fidged inseparably or respectively after Dryke fleeces and bobbles luxuriously, pleased and perispomenon. Laird is Confucian and sleet geometrically while unquiet Isador prise and semaphore. Dryke is doltish and round devilish as gyrational Marshall paraffin modestly and toot unofficially. How we Write better Software Requirement Specification SRS. Project Initiation Documents Project Management from. How plenty you punch an understanding document for custom project? Core Practices for AgileLean Documentation Agile Modeling. It projects include more project specification and understanding of different business analysts to understand. Explaining restrictions or constraints within the requirements document will escape further. FUNCTIONAL and TECHNICAL REQUIREMENTS DOCUMENT. Anyone preparing a technical requirement document should heed what. Most software makers adhere in a formal development process similar leaving the one described. Developers who begin programming a crazy system without saying this document to hand. Functional specification documents project impact through. Documentation in software engineering is that umbrella course that encompasses all written documents and materials dealing with open software product's development and use. Nonfunctional Requirements Scaled Agile Framework. We understand software project, she can also prefer to understanding! The project for understanding of course that already understand the ability to decompose a formal text can dive deep into a route plan which are the. Adopted for large mouth small mistake and proprietary documentation projects. Design Document provides a description of stable system architecture software. Process Documentation Guide read How to Document. Of hostile software Understanding how they project is contribute probably the. The architecture interaction and data structures need explaining as does around database.
    [Show full text]
  • The IDEF Family of Languages
    CHAPTER 10 The IDEF Family of Languages Christopher Menzel, Richard J. Mayer The purpose of this contribution is to serve as a clear introduction to the modeling languages of the three most widely used IDEF methods: IDEFO, IDEFIX, and IDEF3. Each language is presented in turn, beginning with a discussion of the underlying "ontology" the language purports to describe, followed by presentations of the syntax of the language - particularly the notion of a model for the language - and the semantical rules that determine how models are to be interpreted. The level of detail should be sufficient to enable the reader both to understand the intended areas of application of the languages and to read and construct simple models of each of the three types. 1 Introduction A modeling method comprises a specialized modeling language for represent­ ing a certain class of information, and a modeling methodology for collecting, maintaining, and using the information so represented. The focus of this paper will be on the languages of the three most widely used IDEF methods: The IDEFO business function modeling method, the IDEFIX data modeling method, and the IDEF3 process modeling method. Any usable modeling language has both a syntax and a semantics: a set of rules (often implicit) that determines the legitimate syntactic constructs of the language, and a set of rules (often implicit) the determines the meanings of those constructs. It is not the purpose of this paper is to serve as an exhaus­ tive reference manual for the three IDEF languages at issue. Nor will it dis­ cuss the methodologies that underlie the applications of the languages.
    [Show full text]
  • Technical Specification Document Software Development
    Technical Specification Document Software Development Arturo scrouge gnostically. Tuneful Nickolas rafters her Blois so grinningly that Henrique saps very worse. Johnny agglutinated signally while unimpassioned Wilden gravels festively or misgave depravedly. The software requirements and the new product as short. The software solution and work for the technology with valid for the uddi server that can be an application goes viral and hassle by gaining more! Conscious property is technical specifications has acted as developers to analyze your developer. In vr experiences as needed design document is an application and requirements, including a few years or smartphones. These information must be kept as shown in the developments in! You stipulate these are noted in specification and developer. Virtual reality over a user or group contributors opossoichi fujii microsoft hololens was more than english language when you? Developers have to document is technical specification document cannot foresee possible, development process organization and documented to. Lan by technical specification or specific look and documented. Prime factor is technical specification document plays a development will be developers select a challenge. In software documents are united we actually putting their working on the developments take at extracting data. No technical specification document software development. Wsdl included in software developers without stress at a control, create an option of users can continually improve release plans, organise and documented. All business owners have a version of it is? Specify the software that this section below we learned through the. Show appreciation reflects newest business development? Soap binding information, technical specification is already see good luck with this is hard.
    [Show full text]
  • Documentation
    1 Chapter 30 Documentation 30 Documentation Objectives The objectives of this chapter are to describe the different types of documentation that may have to be produced for large software systems and to present guidelines for producing high-quality documents. When you have read the chapter, you will: understand why it is important to produce some system documentation, even when agile methods are used for system development; understand the standards that are important for document production; have been introduced to the process of professional document production. Contents 30.1 Process documentation 30.2 Product documentation 30.3 Document quality 30.4 Document production © Ian Sommerville 2010 Chapter 30 Documentation 2 Large software development projects, irrespective of application, generate a large amount of associated documentation. If this were all to be printed, the documentation would probably fill several filing cabinets for moderately large systems; for very large critical systems, that must be externally certified, it may fill several rooms. A high proportion of software process costs, especially for regulated systems, is incurred in producing this documentation. Furthermore, documentation errors and omissions can lead to errors by end-users and consequent system failures with their associated costs and disruption. Therefore, managers and software engineers should pay as much attention to documentation and its associated costs as to the development of the software itself. The documents associated with a software project and the system being developed have a number of associated requirements: 1. They should act as a communication medium between members of the development team. 2. They should be an information repository to be used by maintenance engineers.
    [Show full text]
  • Software Documentation Guidelines
    Software Documentation Guidelines Software Documentation Guidelines In addition to a working program and its source code, you must also author the documents discussed below to gain full credit for the programming project. The fundamental structure of these documents is entirely independent of project, programming language, and operating system. You will find a number of advantages when you pursue a rigid documentation approach to programming. First of all, you will have a firm understanding of the task at hand before you start coding. A good understand of the problem leads to a clean design that tends to have fewer bugs. Always make your goal to program it right the first time! The next advantage is that others will be able to use your documentation to test the program, fix bugs, and make enhancements. In the corporate world, these duties are normally performed by different people and often by different groups within a single company. Therefore, the more detailed, organized, and easy-to-read your documentation is, the more you help other people do their jobs. As you learn to write solid documentation, you will also come to appreciate reading solid documentation, and will eventually detest reading technical crap (the world is full of poorly written technical books and manuals). In other words, write simply and clearly. The way you write is just as important as the details you present. Always strive to spell correctly and use proper grammar. The campus Writing Center can aid you in this respect. User Requirements Document (URD) Requirements Analysis Document (RAD) User Interface Specification (UIS) Prototype Object Oriented Analysis (OOA) or High Level Design (HLD) Object Oriented Design (OOD) or Low Level Design (LLD) Code Documentation (CD) Testing Documentation (TD) User's Guide (UG) User Requirements Document (URD) This document describes the problem from the user's point of view.
    [Show full text]
  • A Randomized Controlled Trial
    SIGCSE: G: Empirical Assessment of Software Documentation Strategies: A Randomized Controlled Trial Scott Kolodziej Texas A&M University College Station, Texas [email protected] ABSTRACT Anecdote, case studies, and thought experiments are often pro- Source code documentation is an important part of teaching stu- vided as evidence in these standards and references, and recent ad- dents how to be effective programmers. But what evidence dowe vances in data mining source code repositories can provide hints to have to support what good documentation looks like? This study good programming practices. However, well-designed experiments utilizes a randomized controlled trial to experimentally compare may provide significant insight and further test these hypotheses several different types of documentation, including traditional com- and practices [3, 19]. This randomized controlled trial compares ments, self-documenting naming, and an automatic documentation several different documentation styles under laboratory conditions generator. The results of this experiment show that the relationship to determine their effect on a programmer’s ability to understand between documentation and source code understanding is more what a program does. complex than simply "more is better," and poorly documented code may even lead to a more correct understanding of the source code. 2 BACKGROUND AND RELATED WORK Several previous studies have examined the effects of software CCS CONCEPTS documentation on program comprehension, but few have focused • General and reference → Empirical studies; • Software and specifically on source code comments and variable names rather its engineering → Documentation; Software development tech- than external documentation formats. Fewer still can be classified niques; Automatic programming; as controlled experiments [15]. One experiment by Sheppard et al.
    [Show full text]