************ [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

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.

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.

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.