Relevant bibliographies by topics / Agile documentation

Contents

  1. Journal articles
  2. Dissertations / Theses
  3. Books
  4. Book chapters
  5. Conference papers
  6. Reports

Academic literature on the topic 'Agile documentation'

Author: Grafiati
Published: 4 June 2021
Last updated: 3 February 2022

Create a spot-on reference in APA, MLA, Chicago, Harvard, and other styles

Select a source type:

Consult the lists of relevant articles, books, theses, conference reports, and other scholarly sources on the topic 'Agile documentation.'

Next to every source in the list of references, there is an 'Add to bibliography' button. Press on it, and we will generate automatically the bibliographic reference to the chosen work in the citation style you need: APA, MLA, Harvard, Chicago, Vancouver, etc.

You can also download the full text of the academic publication as pdf and read online its abstract whenever available in the metadata.

Journal articles on the topic "Agile documentation"

1

Selic, Bran. "Agile Documentation, Anyone?" IEEE Software 26, no. 6 (November 2009): 11–12. http://dx.doi.org/10.1109/ms.2009.167.

Full text
APA, Harvard, Vancouver, ISO, and other styles
2

Clear, Tony. "Documentation and agile methods." ACM SIGCSE Bulletin 35, no. 2 (June 2003): 12–13. http://dx.doi.org/10.1145/782941.782949.

Full text
APA, Harvard, Vancouver, ISO, and other styles
3

Hoda, Rashina, James Noble, and Stuart Marshall. "Documentation strategies on agile software development projects." International Journal of Agile and Extreme Software Development 1, no. 1 (2012): 23. http://dx.doi.org/10.1504/ijaesd.2012.048308.

Full text
APA, Harvard, Vancouver, ISO, and other styles
4

Rubin, Eran, and Hillel Rubin. "Supporting agile software development through active documentation." Requirements Engineering 16, no. 2 (October 13, 2010): 117–32. http://dx.doi.org/10.1007/s00766-010-0113-9.

Full text
APA, Harvard, Vancouver, ISO, and other styles
5

Møller, Margrethe H., Pernille Bagger Nielsen, and Stanislav Kalianov. "INTERVIEW: Quick, Social and Collaborative - wiki-based user documentation at APC by Schneider Electric." Communication & Language at Work 2, no. 2 (January 26, 2013): 60. http://dx.doi.org/10.7146/claw.v1i2.7898.

Full text
Abstract:
In the software documentation department at APC by Schneider Electric in Kolding, Denmark, Technical Writer Pernille Bagger Nielsen writes user documentation for the software developed by the company. In cooperation with Localization Manager Stanislav Kalianov she reorganised the user documentation for publication as wiki-based documentation on the internet. The new platform supports their strategy of using agile and iterative, topic-based, collaborative writing when developing user documentation. Their experience will interest readers who consider introducing a similar new strategy.
APA, Harvard, Vancouver, ISO, and other styles
6

Hobbs, Brian, and Yvan Petit. "Agile Methods on Large Projects in Large Organizations." Project Management Journal 48, no. 3 (June 2017): 3–19. http://dx.doi.org/10.1177/875697281704800301.

Full text
Abstract:
Agile methods have taken software development by storm but have been primarily applied to projects in what is referred to as the “agile sweet spot,” which consists of small collocated teams working on small, non-critical, green field, in-house software projects with stable architectures and simple governance rules. These methods are being used more and more on large projects, but little documentation is available in the academic literature. This article investigates the adoption and adaptation of agile methods for use on large projects in large organizations. The empirical study is based first on case studies, followed by a survey to validate and enrich the case study results. The results are somewhat paradoxical in that some features are common to almost all observations, whereas others show extreme variability. The common features include use of Scrum methodology and agile coaches, as well as the non-respect of the agile principle of emergent architecture.
APA, Harvard, Vancouver, ISO, and other styles
7

MATALONGA, SANTIAGO, MARTÍN SOLARI, and GERARDO MATTURRO. "FACTORS AFFECTING DISTRIBUTED AGILE PROJECTS: A SYSTEMATIC REVIEW." International Journal of Software Engineering and Knowledge Engineering 23, no. 09 (November 2013): 1289–301. http://dx.doi.org/10.1142/s021819401350040x.

Full text
Abstract:
In the last decade we have witnessed a growth in outsourcing and outshoring development. Following the promise of reducing costs and round-the-clock development, software organizations have grown from local to global enterprises. In the same decade, agile software development methodologies have emerged as a viable alternative to produce software. There is a myriad of agile processes and methodologies now available for any software development organization to choose from. These agile processes follow the values signed in the Agile Manifesto that preaches the exaltation of the individual programmer, high feedback, customer interaction and just enough planning and documentation. But how does global distribution affect these values? Can agile software development be implemented under the global software development context? This paper presents a systematic literature review aimed at identifying factors that affect the adoption of agile factors in global distributed teams. Our findings show that the literature is still in its initial case study publication stage. But most notably, we have found that only a few of the factors found are related to the agile values. Even though more research is clearly needed, this can be a signal that the factors affecting team distribution has more impact on software development than the values and practices preached by the agile processes.
APA, Harvard, Vancouver, ISO, and other styles
8

Marques, Johnny, and Adilson Marques da Cunha. "ARES: An Agile Requirements Specification Process for Regulated Environments." International Journal of Software Engineering and Knowledge Engineering 29, no. 10 (October 2019): 1403–38. http://dx.doi.org/10.1142/s021819401950044x.

Full text
Abstract:
Agile methods have provided significant contributions to Software Engineering. This work presents a new process for Software Requirements Specification, integrating Agile Properties and regulated environments, such as aviation, medical, nuclear and automotive, among others. The Software in Regulated Environments (SRE) involves plan-driven methods with needed documentation to ensure safety, reliability, security, and discipline. This paper proposes a balance between agile and plan-driven methods. We define a new process, which explores and investigates the usage of agile methods in SRE. The scope of this paper is Requirements Engineering, which is considered as a set of activities involved in the management, elicitation, documentation, and maintenance of requirements. The Adile Requirements Specification (ARES) process contains four methods, 13 activities, and some required artifacts to ensure compliance with the following six relevant Software Standards for regulated environments: RTCA DO-178C, IEC 62304:2015, ECSS-E-ST-40C, IEC 61508-3, ISO/IEC/IEEE 12207, and IAEA SSG-39. The process evaluation was performed using two experiments: a Cockpit Display System (CDS) and a Healthcare Information System (HIS). These experiments were measured with appropriate metrics to ensure improvements in Software Requirements Specification and traceability among artifacts. The experimental results revealed that the ARES process works better than the original Scrum for Software in Regulated Environments. The ARES process can also be integrated with traditional software life cycles (Waterfall, V, and Incremental and Iterative), when applied in the Requirements Engineering phase.
APA, Harvard, Vancouver, ISO, and other styles
9

Tsai, Wen-Lung, Chung-Yang Chen, and Chun-Shuo Chen. "Snowman: Agile development method with institutionalized communication and documentation for capstone projects." Asia Pacific Management Review 23, no. 1 (March 2018): 12–19. http://dx.doi.org/10.1016/j.apmrv.2017.01.002.

Full text
APA, Harvard, Vancouver, ISO, and other styles
10

Gkadolou, Eleni, Poulicos Prastacos, and Thanos Loupas. "Documentation of cultural heritage monuments with CityGML: an application for ancient theatres." AGILE: GIScience Series 1 (July 15, 2020): 1–16. http://dx.doi.org/10.5194/agile-giss-1-4-2020.

Full text
Abstract:
Abstract. The scope of this research is to identify the concepts that describe cultural heritage monuments and model them with CityGML. CityGML is the most popular data model for storing and sharing semantic 3D geographic data and there is an increasing interest in its use in the Cultural Heritage field. An Application Domain Extension that covers the most important concepts for describing monuments with special focus on the ancient theatres is developed. The INSPIRE data model is reviewed and its integration with CityGML is discussed. Following the proposed extension, a CityGML model is constructed for the ancient theatre of Hersonissos in Crete. To visualize the model, it is transformed using the Generics approach.
APA, Harvard, Vancouver, ISO, and other styles
More sources

Dissertations / Theses on the topic "Agile documentation"

1

Tabrez, Shams, and Islam Jan. "Documentation and Agile Methodology." Thesis, Uppsala universitet, Institutionen för informatik och media, 2013. http://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva-212653.

Full text
Abstract:
Computer science in general and software engineering in specific is changing very fast. Software engineers are constantly using more innovative and more efficient ways to develop new software than in the past. This continuous evolution of software development methodologies has a great impact on both the software developed and the environment that the developers work-in. Agile software development methodologies are used to overcome many issues in the software development processes. One of the issues which still exists and needs to be addressed is the preparation of proper documentation along with the software. The work presented in this dissertation focuses on software documentation. The work starts by a thorough literature review which focuses on different aspects of software documentation and different agile methodologies. The thesis focuses on finding out the challenges that the developers faces during their development process. Two major questions addressed in the thesis. First one is to find the motivation to document in agile envirionment, whih is based on the hypothesis that there do exist a motivation. The second question is that how should documentation be produced such that we could avoid maximum possible potential problems. These questions are addressed with the help of different perspectives of the stockholders (i.e. developers and users) and the existing methods for documentation. A questionnaire was developed based on the nine categories of documentation, like user documents and system documents etc.. It included different questions related to the types of documents created in software development processes, the software development stage at which the documents are created and the importance of the documents. Questions from this questionnaire are then posted on agile specific discussion forums. Where many experienced and fresh practitioners participated in the discussion. We had a detailed discussion on every component of documentation and problems were identified by the practitioners. The questionnaire was also sent to different companies practicing agile methodology. we received about 14 responses as it was detailed questionnaire with about 34 questions. The responses of the discussion forum and survey are then analyzed and conclusions were drawn. The conclusions include that all the participants consider software documentation very important to the success of a software development project. the question of motivation is answered from the literature and opinions we received from experienced practitioners. While seven factor are identified that affect your documentation, to help solve the question of how should documentation be done.
APA, Harvard, Vancouver, ISO, and other styles
2

Kiss, Fabian. "Documenting for Program Comprehension in Agile Software Development." Thesis, Högskolan i Borås, Institutionen Handels- och IT-högskolan, 2011. http://urn.kb.se/resolve?urn=urn:nbn:se:hb:diva-20393.

Full text
Abstract:
Program comprehension, i.e. to understand from its source code what a computer programdoes, is crucial for change and maintenance in software development. In this thesis, it is lookedfor innovative documentation techniques and tools that support program comprehension, butthat are also conform to agile values and principles – commonly, documentation is consideredcritical due to the agile value “working software over comprehensive documentation.”1 First,a research framework is developed that embodies detailed requisites for such techniques andtools. Apart from its internal use for examining techniques and tools subsequently obtainedfrom a literature search, this framework is intended to be likewise employed by software practitioners.Eventually, the findings of a series of survey studies conducted in an industrial softwareorganization for the primary purpose of evaluating the obtained techniques and tools are analyzed.Three innovative techniques that meet all requisites are revealed. These are regarded bypractitioners independently from the support of program comprehension as helpful for a changeimpact analysis conducted by non-developers. Therefore, a requisite deduced from the highestpriority in agile software development – customer satisfaction – is met. It says that a techniqueor tool has to directly induce a benefit for non-developer stakeholders besides the benefits forthem which are indirectly induced by the support of program comprehension, e.g. a potentiallyimproved source code quality. Further, the technique most beneficial for developers as well asfor non-developers among the three techniques is identified, which bases on design rationales– textual information related to the source code that states the reasons why a part of the programhas been implemented in a certain way. Secondarily, the studies revealed that the researchframework is difficult to understand for practitioners due to its unstructured form.
Program: Magisterutbildning i informatik
APA, Harvard, Vancouver, ISO, and other styles
3

Lake, Brandon. "An empirical evaluation of an agile modular software development approach : A case study with Ericsson." Thesis, KTH, Skolan för informations- och kommunikationsteknik (ICT), 2012. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-102397.

Full text
Abstract:
Software development is a growing part of many businesses today. The software development approach that is used to develop new software may have a positive or negative impact on the efficiency and quality of the final software product. The objective of this thesis was to propose a refined software development approach and to test it empirically. The software development approach is comprised of three main subcomponents: development style, development architecture, and technical documentation. The software development approach was applied in a case study in cooperation with Ericsson. At the completion of the case study, questionnaires were administered to Ericsson employees to evaluate the success of the software development approach. The results showed that the quality of the software product was high and Ericsson was pleased with the result. The results indicated that the development approach helped the case study be successful in some of the researched areas. The end results suggest that the proposed software process has the potential to be successful in other projects of a similar type and structure.
APA, Harvard, Vancouver, ISO, and other styles
4

Gislén, Mikael. "Achieving Agile Quality : An Action Research Study." Thesis, Blekinge Tekniska Högskola, Institutionen för kreativa teknologier, 2016. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-13732.

Full text
APA, Harvard, Vancouver, ISO, and other styles
5

Abu, Baker Mohamed. "Agile Prototyping : A combination of different approaches into one main process." Thesis, Linköping University, PELAB - Programming Environment Laboratory, 2009. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-56463.

Full text
Abstract:

Software prototyping is considered to be one of the most important tools that are used by software engineersnowadays to be able to understand the customer’s requirements, and develop software products that are efficient,reliable, and acceptable economically. Software engineers can choose any of the available prototyping approaches tobe used, based on the software that they intend to develop and how fast they would like to go during the softwaredevelopment. But generally speaking all prototyping approaches are aimed to help the engineers to understand thecustomer’s true needs, examine different software solutions and quality aspect, verification activities…etc, that mightaffect the quality of the software underdevelopment, as well as avoiding any potential development risks.A combination of several prototyping approaches, and brainstorming techniques which have fulfilled the aim of theknowledge extraction approach, have resulted in developing a prototyping approach that the engineers will use todevelop one and only one throwaway prototype to extract more knowledge than expected, in order to improve thequality of the software underdevelopment by spending more time studying it from different points of view.The knowledge extraction approach, then, was applied to the developed prototyping approach in which thedeveloped model was treated as software prototype, in order to gain more knowledge out of it. This activity hasresulted in several points of view, and improvements that were implemented to the developed model and as a resultAgile Prototyping AP, was developed. AP integrated more development approaches to the first developedprototyping model, such as: agile, documentation, software configuration management, and fractional factorialdesign, in which the main aim of developing one, and only one prototype, to help the engineers gaining moreknowledge, and reducing effort, time, and cost of development was accomplished but still developing softwareproducts with satisfying quality is done by developing an evolutionary prototyping and building throwawayprototypes on top of it.

APA, Harvard, Vancouver, ISO, and other styles
6

Lundgren, Sara, and Tove Lundkvist. "Mystiken kring överlämningen i den agila projektmodellen : Svenska bankers upplevelse av överlämningen av en produkt och dess konsekvenser." Thesis, Linköpings universitet, Företagsekonomi, 2019. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-158455.

Full text
Abstract:
Bakgrund: Den agila projektmodellen har under de senaste två decennierna vuxit fram som en utmanare till den traditionella vattenfallsmodellen. En av de stora skillnaderna mellan projektmodellerna är att i det agila arbetssättet involveras kunden kontinuerligt. Frågan är vad som då händer med överlämningen av den sista versionen av produkten, när utvecklingen är färdig? Samtidigt har bankbranschen på senare år utmanats av nya aktörer vilka profilerar sig som just digitala och IT-inriktade, och både dessa moderna banker såväl som de traditionella storbankerna har anammat det agila arbetssättet för att kunna konkurrera om kundernas uppmärksamhet. Dessa banker arbetar inte agilt till lika hög grad, och frågan är om överlämningen påverkas av det? Syfte: Syftet med studien är att öka förståelsen för hur överlämningen av det slutliga projektresultatet i agila projekt ser ut på svenska banker. Vidare ska studien undersöka om den skiljer sig mellan banker med olika agil mognad samt vilka konsekvenser som kan uppkomma i samband med överlämningen. Genomförande: Studien är genomförd som en flerfallstudie där två fall - storbanker och nischbanker, undersöks. Vidare har en fenomenologisk ansats och ett kvalitativt angreppssätt använts. Empirin har samlats in genom ett målstyrt urval varpå semistrukturerade intervjuer har genomförts med tio projektledare. Slutsats: Studien resulterar i slutsatsen att en överlämning av en slutlig produkt i agila projekt inte genomförs på ett formellt sätt, till skillnad från vad teorin tidigare har antytt. I synnerhet lämnar aldrig ansvaret för produkten någonsin det team som har utvecklat den. Vidare visar studien att storbanker arbetar med en lägre grad av agil mognad än vad nischbanker gör, men att detta inte påverkar hur överlämningen ser ut. Slutligen bidrar studien till insikter om konsekvenser kring att överlämningen inte existerar på ett formellt sätt. Detta leder till en reflektion kring att organisationer behöver anpassa sin agila projektmetodik till sin egen kontext. Projektledare generellt bör dessutom fundera över hur organisationens arbetssätt påverkar organisationen i stort samt vara medveten om de konsekvenser som dyker upp vid förändringar i arbetssättet.
Background: During the last two decades, the agile project methodology has grown as a competitor to the more traditional waterfall methodology. One of the biggest differences is, with an agile methodology the customer is involved throughout the project. But what happens in the final handover, when the development is finished? At the same time, the Swedish banking industry has been challenged by new actors whom profile themselves as digital focused and IT centred. Both types of banks have developed an agile way of working to be able to compete about the customers. However, the two types of banks does not work agile with the same maturity, and we wonder if the handover is affected by that? Purpose: The purpose of the study is to increase the understanding of what the handover of the final product in agile projects at Swedish banks looks like. Further, the study will examine if the handover differ between banks with different agile maturity, and which consequences that may arise in connection to the handover. Completion: The study was conducted as a multiple-case study in which two cases - traditional banks and specialised banks were examined. Further, a phenomenological and a qualitative approach has been used. The empirical data has been conducted through a targeted selection, where semi-structured interviews have been held with ten project leaders. Conclusion: The study concludes that the handover of the final product in agile projects does not exist in the formal way previous research has suggested. Specifically, the responsibility of the product does never leave the team developing it. Further, the study show traditional banks work with a lower degree of agile maturity in comparison to specialised banks. However, this does not affect the characteristics of the handover. Finally, the study contributes to insights about the consequences of the handover not being as formal. This contributes to a discussion about the need for organisations to be able to adapt their agile methodology to their own context. In general, project leaders also should reflect upon how their way of working affect the organisation as a whole, as well as being aware of the consequences that appears when changing the organisation’s way of working.
APA, Harvard, Vancouver, ISO, and other styles
7

Andrén, Samuel. "Categorizing and managing difficulties in interorganizational requirements engineering." Thesis, KTH, Industriell ekonomi och organisation (Inst.), 2020. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-273975.

Full text
Abstract:
As globalisation is now a reality for most large organizations, and the competition for most businesses moving faster and becoming tougher, there is a need for engineering projects to deliver results faster in a more complex environment than ever, but also for companies to collaborate to utilize a wider array of competencies and to reach new markets with their products. This case study analyses which difficulties arise in interorganizational requirements engineering, and what organizations can do to alleviate the effects of those difficulties, as well as suggest which actions are most effective to focus on. The conclusion of this study is that the difficulties can be divided into three categories, namely interpersonal, structural and processual. Each category concerns a different set of people and require different actions for increased effectiveness. For the interpersonal category, prioritized efforts should be to establish a shared vocabulary and use techniques to build shared contextual understanding. For structural difficulties, evaluating management and control structures and the implementation of the project’s strategy should be prioritized. In the processual category, codifying existing processes to enable improvements, defining information artefacts and aligning information flows should be of high priority
Globaliseringens effekter är idag en verklighet för de flesta stora organisationer, och konkurrensen för företag blir hårdare och förändrar sig allt snabbare. Därför blir det allt viktigare för utvecklingsprojekt att anpassa sig till en allt mer komplex miljö och leverera resultat snabbare än tidigare, men också att samarbeta mer med andra företag för att såväl utnyttja bredare kompetens som att nå nya marknader. Den här studien undersöker utmaningarna i interorganisatoriskt kravställningsarbete, vad företag kan göra för att möta de utmaningarna, såväl som att föreslå vilka handlingar som ger mest effekt för ett bättre kravställningsarbete. Slutsatsen av studien är att utmaningarna kan delas in i tre kategorier, nämligen personorienterade, strukturella och processorienterade. Varje kategori rör en viss mängd deltagare i projektet och kräver olika handlingar för ökad effektivitet. För att minska utmaningar i den personorienterade kategorin bör ett projekt prioritera att använda tekniker för att skapa ett gemensamt språkbruk och att använda tekniker för att bygga upp gemensam kontextuell förståelse. För strukturella utmaningar bör det prioriteras att utvärdera styrnings- och kontrollstrukturer, samt hur projektets strategi har implementerats och förankrats bland deltagarna. I den processorienterade kategorin bör det prioriteras att kodifiera existerande processer för att möjliggöra förbättringsarbete, definiera informationsartefakter och att försäkra sig om att informationsflöden är i linje med varandra mellan företagen, så att rätt information möts vid rätt tillfällen.
APA, Harvard, Vancouver, ISO, and other styles
8

Ferreira, Diogo Filipe Dos Santos. "Weaki Desktop App: a tool for agile software documentation." Dissertação, 2017. https://repositorio-aberto.up.pt/handle/10216/110193.

Full text
Abstract:
Uma aplicação multi-plataforma para documentação de software em ambiente agile desenvolvida em Node, Electron e React. Weaki foca-se em maximizar a reutilização ao, por exemplo, oferecer um sistema de páginas tipificadas reduzindo assim o esforço necessário aquando se pretende produzir diversas páginas semelhantes. Para além deste aspecto a aplicação também facilita o seu uso ao ter uma interface muito semelhante a outras aplicações usadas pelos developers tais como o editor de texto Atom e ao integrar com ferramentas como o Git.
Software documentation is an important aspect of software development but unfortunately nottreated as such most of the time. There are many known ways to document software and theseshould be adopted by the developers taking their work environment into account. The target audi-ence is the most important factor since it dictates the contents and structure of the documentationand assumes the pre-acquired knowledge of the reader. Documentation for the product's end-usershould be completely different to the one viewed by the development team for example.Agile development describes a mindset which focuses on doing only what is required when itis required. This can also be applied to documentation and there is a set of guidelines to followamong which reusability and simplicity stand out. These two guidelines can be interpreted as themost basic requirements for agile software documentation tools.Weaki is a cross-platform desktop application, based on the Electron framework, for agilesoftware documentation meant to extend its web version based on DokuWiki. Its principles arebased on weakly-typed wikis which means that the pages are structured but it is not enforced onthe user who has the freedom to gradually adopt stricter rules but with benefits. Running nativelyon the desktop brings many benefits such as direct access to the file system, integration with Gitand the ability to customize the application to the user.The application is developed with the use of agile methods in which at the end of each iteration,one week-long, there's palpable progress and reports on the situation. Starting by implementingthe core features of the web version of Weaki, at the end of 3 months it is expected to start workingfor the next month on refinements and extra-features such as integrating with Slack, GitHub andGoogle Drive. The results are then compared to the initial goals and the conclusions are taken.
APA, Harvard, Vancouver, ISO, and other styles
9

Ferreira, Diogo Filipe Dos Santos. "Weaki Desktop App: a tool for agile software documentation." Master's thesis, 2017. https://repositorio-aberto.up.pt/handle/10216/110193.

Full text
Abstract:
Uma aplicação multi-plataforma para documentação de software em ambiente agile desenvolvida em Node, Electron e React. Weaki foca-se em maximizar a reutilização ao, por exemplo, oferecer um sistema de páginas tipificadas reduzindo assim o esforço necessário aquando se pretende produzir diversas páginas semelhantes. Para além deste aspecto a aplicação também facilita o seu uso ao ter uma interface muito semelhante a outras aplicações usadas pelos developers tais como o editor de texto Atom e ao integrar com ferramentas como o Git.
Software documentation is an important aspect of software development but unfortunately nottreated as such most of the time. There are many known ways to document software and theseshould be adopted by the developers taking their work environment into account. The target audi-ence is the most important factor since it dictates the contents and structure of the documentationand assumes the pre-acquired knowledge of the reader. Documentation for the product's end-usershould be completely different to the one viewed by the development team for example.Agile development describes a mindset which focuses on doing only what is required when itis required. This can also be applied to documentation and there is a set of guidelines to followamong which reusability and simplicity stand out. These two guidelines can be interpreted as themost basic requirements for agile software documentation tools.Weaki is a cross-platform desktop application, based on the Electron framework, for agilesoftware documentation meant to extend its web version based on DokuWiki. Its principles arebased on weakly-typed wikis which means that the pages are structured but it is not enforced onthe user who has the freedom to gradually adopt stricter rules but with benefits. Running nativelyon the desktop brings many benefits such as direct access to the file system, integration with Gitand the ability to customize the application to the user.The application is developed with the use of agile methods in which at the end of each iteration,one week-long, there's palpable progress and reports on the situation. Starting by implementingthe core features of the web version of Weaki, at the end of 3 months it is expected to start workingfor the next month on refinements and extra-features such as integrating with Slack, GitHub andGoogle Drive. The results are then compared to the initial goals and the conclusions are taken.
APA, Harvard, Vancouver, ISO, and other styles
10

Gonçalves, Beatriz Nunes. "A quality management system for safety critical platforms." Master's thesis, 2018. http://hdl.handle.net/10316/83565.

Full text
Abstract:
Dissertação de Mestrado em Engenharia Informática apresentada à Faculdade de Ciências e Tecnologia
Num projeto de software é essencial ter qualidade, tanto nos produtos como nos processos. Para além de diminuir a probabilidade de falhas, a qualidade garante a satisfação dos clientes e faz com que estejam mais abertos a voltar a contratar os serviços da empresa no futuro.¬¬¬ Atingir esse nível de qualidade implica por em prática os mecanismos que asseguram que os processos são efetivos e eficientes e que os produtos têm todas as funcionalidades implementadas. Para além disso, os produtos têm de ter bom desempenho, sejam quais forem as circunstâncias.Isto tona-se ainda mais crucial quando há vidas que dependem do bom funcionamento do sistema, como é o caso dos sistemas críticos de segurança. A plataforma que vai ser objeto de estudo neste relatório, Mobitrust, vai ser usada em situações de emergência, em que há vidas em risco. Por isso, qualquer falha do sistema pode ter consequências desastrosas.Assim sendo, o objetivo deste estágio será assegurar a qualidade da plataforma em estudo, Mobitrust, através da implementação de metodologias que aumentam a qualidade de processos e de produtos. Para isso, para além da produção de documentos relacionados com o projeto, que garantem a qualidade da plataforma, o trabalho inclui especificar e implementar a metodologia de qualidade considerada mais adequada para melhorar a qualidade dos processos relacionados com o projeto. A segunda parte, melhorar a qualidade dos processos relacionados com o projeto, significa descrever os passos necessários para assegurar conformidade com os padrões de qualidade da metodologia escolhida.A metodologia proposta neste relatório combina a escrita da documentação do projeto (especificação de requisitos, análise de riscos, arquitetura e design e plano de testes) com os padrões ISO 9000 (focando-se no ISO 9001) para assegurar que o Mobitrust tem a qualidade requerida em sistemas críticos de segurança que serão usados em situações de emergência pelas entidades competentes.
Quality is essential both for the products and the processes. In addition to lowering the probability of failure, quality guarantees the satisfaction of customers and their willingness to use the company’s services again or recommend them to friends.To achieve that level of quality, it is necessary to have the mechanisms in place to assure that the processes are effective and efficient and that the product has all the necessary features and performs well under every circumstance.This becomes even more imperative in safety critical systems, that have lives depending on it. The platform which is the object of study in this dissertation, Mobitrust, will be used in emergency situations where environment, lives and property are at stake. Therefore, any failure can have disastrous consequences. With that in mind, the goal of this internship is to make sure that the platform, Mobitrust, has good quality, by implementing quality of product and quality of processes. To do so, in addition to producing the documentation related to the project, to assure the quality of the platform, the work includes the specifying and implementing a quality methodology considered to be the most adequate in order to improve the quality of processes related to the Mobitrust platform. This last part, improving the quality of processes, means establishing the necessary steps to assure compliance with quality standards of the methodology chosen.The methodology proposed in this thesis combines the drawing up the project documentation (requirements specification, risk analysis, architecture and design and test plan) with ISO 9000 standards (focussing on ISO 9001) to assure that Mobitrust meets the quality requirements for Public Protection and Disaster Relief (PPDR) markets.
APA, Harvard, Vancouver, ISO, and other styles

Books on the topic "Agile documentation"

1

Agile documentation: A pattern guide to producing lightweight documents for software projects. Chichester, West Sussex, England: J. Wiley, 2003.

Find full text
APA, Harvard, Vancouver, ISO, and other styles
2

1938-, Sayani Hasan H., and Sone Saya 1963-, eds. The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Pub., 2009.

Find full text
APA, Harvard, Vancouver, ISO, and other styles
3

Rico, David F. The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Pub., 2009.

Find full text
APA, Harvard, Vancouver, ISO, and other styles
4

Agile Documentation. New York: John Wiley & Sons, Ltd., 2005.

Find full text
APA, Harvard, Vancouver, ISO, and other styles
5

Rueping, Andreas. Agile Documentation: A Pattern Guide to Producing Lightweight Documents for Software Projects (Wiley Software Patterns Series). Wiley, 2003.

Find full text
APA, Harvard, Vancouver, ISO, and other styles

Book chapters on the topic "Agile documentation"

1

Cimolini, Patrick, and Karen Cannell. "Documentation." In Agile Oracle Application Express, 143–62. Berkeley, CA: Apress, 2012. http://dx.doi.org/10.1007/978-1-4302-3760-0_8.

Full text
APA, Harvard, Vancouver, ISO, and other styles
2

Baumgartner, Manfred, Martin Klonk, Christian Mastnak, Helmut Pichler, Richard Seidl, and Siegfried Tanczos. "Agile Testing Documentation." In Agile Testing, 143–56. Cham: Springer International Publishing, 2021. http://dx.doi.org/10.1007/978-3-030-73209-7_6.

Full text
APA, Harvard, Vancouver, ISO, and other styles
3

Kohl, Jonathan, and Brian Marick. "Agile Tests as Documentation." In Lecture Notes in Computer Science, 198–99. Berlin, Heidelberg: Springer Berlin Heidelberg, 2004. http://dx.doi.org/10.1007/978-3-540-27777-4_27.

Full text
APA, Harvard, Vancouver, ISO, and other styles
4

Voigt, Stefan, Detlef Hüttemann, Andreas Gohr, and Michael Große. "Agile Documentation Tool Concept." In Developments and Advances in Intelligent Systems and Applications, 67–79. Cham: Springer International Publishing, 2017. http://dx.doi.org/10.1007/978-3-319-58965-7_5.

Full text
APA, Harvard, Vancouver, ISO, and other styles
5

Hanssen, Geir Kjetil, Tor Stålhane, and Thor Myklebust. "Documentation and Proof-of-Compliance." In SafeScrum® – Agile Development of Safety-Critical Software, 135–44. Cham: Springer International Publishing, 2018. http://dx.doi.org/10.1007/978-3-319-99334-8_9.

Full text
APA, Harvard, Vancouver, ISO, and other styles
6

Brolund, Daniel, and Joakim Ohlrogge. "Streamlining the Agile Documentation Process Test-Case Driven Documentation Demonstration for the XP2006 Conference." In Extreme Programming and Agile Processes in Software Engineering, 215–16. Berlin, Heidelberg: Springer Berlin Heidelberg, 2006. http://dx.doi.org/10.1007/11774129_31.

Full text
APA, Harvard, Vancouver, ISO, and other styles
7

Poniszewska-Marańda, Aneta, Arkadiusz Zieliski, and Witold Marańda. "Towards Project Documentation in Agile Software Development Methods." In Data-Centric Business and Applications, 1–18. Cham: Springer International Publishing, 2019. http://dx.doi.org/10.1007/978-3-030-19069-9_1.

Full text
APA, Harvard, Vancouver, ISO, and other styles
8

Mazni, Omar, Syed-Abdullah Sharifah-Lailee, and Yasin Azman. "Agile Documents: Toward Successful Creation of Effective Documentation." In Lecture Notes in Business Information Processing, 196–201. Berlin, Heidelberg: Springer Berlin Heidelberg, 2010. http://dx.doi.org/10.1007/978-3-642-13054-0_18.

Full text
APA, Harvard, Vancouver, ISO, and other styles
9

Dooms, Ko, and Roope Kylmäkoski. "Comprehensive Documentation Made Agile – Experiments with RaPiD7 in Philips." In Product Focused Software Process Improvement, 224–33. Berlin, Heidelberg: Springer Berlin Heidelberg, 2005. http://dx.doi.org/10.1007/11497455_19.

Full text
APA, Harvard, Vancouver, ISO, and other styles
10

Heeager, Lise Tordrup. "How Can Agile and Documentation-Driven Methods be Meshed in Practice?" In Lecture Notes in Business Information Processing, 62–77. Cham: Springer International Publishing, 2014. http://dx.doi.org/10.1007/978-3-319-06862-6_5.

Full text
APA, Harvard, Vancouver, ISO, and other styles

Conference papers on the topic "Agile documentation"

1

Stettina, Christoph Johann, Werner Heijstek, and Tor Erlend Faegri. "Documentation Work in Agile Teams: The Role of Documentation Formalism in Achieving a Sustainable Practice." In 2012 Agile Conference. IEEE, 2012. http://dx.doi.org/10.1109/agile.2012.7.

Full text
APA, Harvard, Vancouver, ISO, and other styles
2

Baptista, Joaquim. "Agile documentation with uScrum." In the 26th annual ACM international conference. New York, New York, USA: ACM Press, 2008. http://dx.doi.org/10.1145/1456536.1456596.

Full text
APA, Harvard, Vancouver, ISO, and other styles
3

Aguiar, Ademar. "Tutorial on agile documentation with Wikis." In the 5th International Symposium. New York, New York, USA: ACM Press, 2009. http://dx.doi.org/10.1145/1641309.1641365.

Full text
APA, Harvard, Vancouver, ISO, and other styles
4

Voigt, Stefan, Detlef Huttemann, and Andreas Gohr. "sprintDoc: Concept for an agile documentation tool." In 2016 11th Iberian Conference on Information Systems and Technologies (CISTI). IEEE, 2016. http://dx.doi.org/10.1109/cisti.2016.7521550.

Full text
APA, Harvard, Vancouver, ISO, and other styles
5

Shafiq, Muneeb, and U. sman Waheed. "Documentation in Agile Development A Comparative Analysis." In 2018 IEEE 21st International Multi-Topic Conference (INMIC). IEEE, 2018. http://dx.doi.org/10.1109/inmic.2018.8595625.

Full text
APA, Harvard, Vancouver, ISO, and other styles
6

Hadar, Irit, Sofia Sherman, Ethan Hadar, and John J. Harrison. "Less is more: Architecture documentation for agile development." In 2013 6th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE). IEEE, 2013. http://dx.doi.org/10.1109/chase.2013.6614746.

Full text
APA, Harvard, Vancouver, ISO, and other styles
7

Prause, Christian R., and Zoya Durdik. "Architectural design and documentation: Waste in agile development?" In 2012 International Conference on Software and System Process (ICSSP). IEEE, 2012. http://dx.doi.org/10.1109/icssp.2012.6225956.

Full text
APA, Harvard, Vancouver, ISO, and other styles
8

Voigt, Stefan, Jörg von Garrel, Julia Müller, and Dominic Wirth. "A Study of Documentation in Agile Software Projects." In ESEM '16: ACM/IEEE 9th International Symposium on Empirical Software Engineering and Measurement. New York, NY, USA: ACM, 2016. http://dx.doi.org/10.1145/2961111.2962616.

Full text
APA, Harvard, Vancouver, ISO, and other styles
9

Behutiye, Woubshet, Pertti Seppänen, Pilar Rodríguez, and Markku Oivo. "Documentation of Quality Requirements in Agile Software Development." In EASE '20: Evaluation and Assessment in Software Engineering. New York, NY, USA: ACM, 2020. http://dx.doi.org/10.1145/3383219.3383245.

Full text
APA, Harvard, Vancouver, ISO, and other styles
10

Hess, Anne, Philipp Diebold, and Norbert Seyff. "Towards Requirements Communication and Documentation Guidelines for Agile Teams." In 2017 IEEE 25th International Requirements Engineering Conference Workshops (REW). IEEE, 2017. http://dx.doi.org/10.1109/rew.2017.64.

Full text
APA, Harvard, Vancouver, ISO, and other styles

Reports on the topic "Agile documentation"

1

Wright, T. J. The Need for Agile Program Documentation. Fort Belvoir, VA: Defense Technical Information Center, June 2013. http://dx.doi.org/10.21236/ada608825.

Full text
APA, Harvard, Vancouver, ISO, and other styles
You might also be interested in the extended bibliographies on the topic 'Agile documentation' for particular source types:
Journal articles
We offer discounts on all premium plans for authors whose works are included in thematic literature selections. Contact us to get a unique promo code!

To the bibliography