[RÜPING-2003], Chapter 1 [DUVALL-2007], Chapter 1-3

1. ************ [RÜPING-2003], Chapter 1 **************************************************************
Documents describe user requirements, software architectures, design decisions, source code and management issues.
Documentation can contribute to the success of a project by making necessary information available to the team
members. It can preserve knowledge within a team, and prevent the team from re-inventing things when team members
leave and new people join. It can capture expertise gained in one project and make it available to future projects. When
knowledge has been committed to paper, it cannot be lost.
“Documentation in moderation, aids communication, enhances knowledge transfer, preserves historical information,
and fulfils governmental and legal requirements.” –Highsmith
Light-but-sufficient approach is favorable because:
 Such approach prevents the project team form expending unnecessary large effort on documentation
 Light-but-sufficient documentation is more accessible, and therefore more useful, for a team than voluminous
documentation
“Quality is more important than quantity in project documentation.” / “Documentation is a means, not an end.”
A pattern in this sense is essentially a well-proven problem-solution pair, presented in a structured form. Users can look
up patterns for their particular problems, apply the solutions, and thereby draw on the general expertise available. A
good pattern describes the forces that are associated with a problem, those issues that influence or constrain possible
solutions. A pattern offers the rationale behind the solution.
Contrast of the Role of Documentation with Face-to-Face Communication

2. Roadmap diagram of Patterns: it sketches the patterns and relationships that hold between them.
Target Readers: To ensure that the documents that the project team produce will be appreciated, each document must
have a target leadership, and must address these readers in order to prove useful.
Focused Information: Documents can be prevented from meandering and getting nowhere by having a clear and
identifiable focus on a particular topic, making it concise and straightforward.
Individual Documentation Requirements: Unnecessary documentation requirements can be avoided by defining
documentation requirements individually.
Documentation Portfolio: Teams can reuse the knowledge about which documents might be required in their projects
by using a documentation portfolio that describes which documents might be necessary in software project, and their
scope. In an organization sets up such a portfolio, projects can choose those documents they need, checking the necessity
of each candidate document individually. [Management, Specification, Design, Migration, Test, Usage, Operations]
Focus on Long-Term Relevance: Projects can avoid producing documentation that expires too soon by making
documentation that focuses on issues with a long-term relevance, issues that will play a role in a later project phase or
in future projects.
Specification as a Joint Effort: Development projects can ensure that they head in the direction the customer wants by
doing specification based on the requirement analysis done jointly by the project team and the customer.
Design Rationale: Team can make sure that the foundations are laid for future design changes by making design
documents not restricted to describing the actual design, but also focus on the rationale behind the design and explain
why the particular design was chosen.

3. Big Picture: People can be introduces to a project without being confronted with a deluge of technical details by
describing the ‘Big Picture’ of the architecture that underlies the system under construction.
Separation of Description and Evaluation: Authors can prevent
loss of credibility by clearly separation description from valuation
in their documents.
Realistic Examples: Abstract material can be explained in a
comprehensible way if the project documents include realistic
examples from the project’s context.
************ [DUVALL-2007], Chapter 1-3*************************************************************
What is continuous integration? A software development practice where members of a team integrate their work
frequently, usually each person integrates at least daily- leading to multiple integrations per day. Each integration is
verified by an automated build to detect integration errors as quickly as possible. This approach leads to significantly
reduce integration problems and allows a team to develop a cohesive software more rapidly.
Rapid Feedback: Continuous integration increases opportunities for feedback. Through it, we learn the state of the
project several times a day. CI can be used to reduce the time between when a defect is introduces and when it is fixed,
thus improving overall software quality.
CI works well with practices like refactoring and test-driven development, because these practices are centered on the
notion making small changes.
What is a Build? It is a compile that may consist
of the compilation, testing, inspection, and
deployment. A build acts as the process for
putting source code together and verifying that
the software works as a cohesive unit.
‘Find problems earlier by building often.’
The purpose of Version Control Repository is to manage changes to source code and other software assets (such as
documentation) using a controlled access repository.
A CI server runs an integration build whenever a change is committed to the version control repository. The CI server will
retrieve the source files and run a build script or scripts.
The Build Script is a single report, or set of scripts, you use to compile, test, inspect, and deploy software. It can be used
without implementing a CI system.
One of the key purposes of CI is produce feedback on an integration build.
Integration build machine is a separate machine whose sole responsibility is to integrate software. It hosts the CI server,
and the CI server polls the version control repository.

4. Four features required for CI:
1. A connection to a version control repository
2. A build script
3. Some sort of feedback mechanism (such as e-mail)
4. A process for integrating the source code changes (manual or CI server)
Compilation involves creating executable code from your human-readable source.
By using CI system, the integration of the database can be ensured
through a version control repository.
The database source code—Data definition language scripts,
Data manipulation language scripts, stores procedure definitions,
partitioning, and so on—in the same manner as any other source
code in the system.
Different categories of tests run from a CI system to speed up the builds. These categories may include unit, component,
system, load/performance, security, and others.
Automated code inspections (static & dynamic analysis) can be used to enhance the quality of the software by enforcing
rules.
Continuous deployment enables delivering working, deployable software at any point in time. Meaning a key purpose of
a CI system is to generate the bundled software artifacts with the latest code changes and make it available to a testing
environment.
Concise code with well-chosen class, variable, and method names (for instance) is the best documentation. Ci system can
use tools to generate class diagrams and other information, all based on the committed source code in the version control
repository.