ref sw & testbed mini workshop june 2000 software process & environment in atlas back-end...

June 2000 Ref SW & Testbed Mini Workshop

Software Software Process & Process &

Environment Environment in Atlas in Atlas

Back-end Back-end Doris Burckhart

CERN ATLAS DAQ/EF-1

Back-end software

June 2000 Software Process and Engeneering Environment in Atlas Back-End - Doris Burckhart

2

ContentContent

Introduction Why a software process The Back-end DAQ Software

The Back-End SW Development Process Organisation Phases and Deliverables Software Management Review and Inspection

Summary Lessons learnt Summary


3

Why a Software ProcessWhy a Software Process

Define the obvious, plus ... define and meet user requirements define structured but flexible work-plan defining responsibilities define interfaces between components define interfaces to external systems

Closely follow-up on progress avoids unrealistic goals tracks problems early improves communication provides basis for iterative development

Some initial pointsSome initial points


4

Software Development Software Development

Version Control

SoftwareRelease

ToolSoftware

Development

Process

Common WorkingCulture

StandardsAgreements

Rules

BasicFramework

SoftwareDevelopment

Environmentchecklists

Documentation

ConfigurationManagement

TestingTools

Development

Tools


5

Back-End Integration Back-End Integration in Atlas onlinein Atlas online


6

Back-end ComponentsBack-end Components

Run Control Controls configuration and data taking operations

Configuration Databases Defines all aspects of the configuration

Message Reporting System Report/capture of error/information messages

Information Service General purpose information exchange

Process Manager Distributed job control of programs

Resource Manager Allows concurrent data taking activity

Integrated User Interface Gives current status and control to the shift operator

Online Bookkeeper Electronic tape log book

Test Manager Bank of functionality tests for hardware and software

Diagnostics Uses tests in the Test Manager to diagnose problems

Event Dump Event monitoring program with GUI


7

Back-End Software ProcessBack-End Software Process

‘Light’ Software Process We are not Gurus, just concerned developers based on ‘best effort’ approach - not perfect not formally described in a document

but it is on the Web ! -> easy to be updated and to work with Structured Organization - Helpful Framework

Process relies on division into component and on a development structured into phases

Define and agree on common goals -> community feels responsible for the results -> increased communication

Collaborate with Atlas offline where possible coding rules


8

SW Development ProcessSW Development Process

identify needs & common issues, define priorities and work-plan, define components

perform pre-design investigations -> identify candidate technologies/techniques

develop high-level design

refine design, implement code 180,000 lines of C++ 40 % generated

unit test componentsintegrate with other subsystems

Total 800 000 linesincl. external sw

Collect Requirements

Pre-design Investigations

High-level Design

Testing &Integration

Detailed DesignImplementation

Training, Programming and Testing Tools, FrameMaker, html, SRT Configuration Management, StP/OMT CASE TOOLS

Software Development Environment


9

Organization /1Organization /1

Work is organized around components small groups dedicated to each component

(up to 4 developers) one coordinator for each component prefer one institute per component

-> clear boundaries of responsibilities most developers follow a component all the way

through its lifecycle look for commonalties between components

- don’t duplicate functionality take / reuse as much as possible from colleagues:

code, ideas, documentation, templates, examples


10

Organization /2Organization /2

Components developed according to an agreed priority started with core components (run control, config. Databases,...) Then working on additional components (I.e. Online Book-

keeper)

Component independent parts Software Management (I.e. SRT, CVS) Use of external software (Corba/ILU, Rogue Wave Tool.h++,

CmdLine, CHSM) - one developer responsible for each package

Supported platforms: those agreed on in the Atlas DAQ community constraint: minimize number of platforms because each platform

represents a lot of work for the build and releases of the SW


11

Templates and Guidelines Templates and Guidelines

Doc. Templates developed within the project generic technical note (FrameMaker) test plan - test report

Doc. Templates taken from IP/IPT group user requirements users guide

Check-lists and guidelines brief requirements, design and general doc.check-lists C++ coding standards pointers to short easy-to-read ideas about design and testing

by Gurus on the Web Simple “how-to’ instructions for most commonly used tools

(e.g.SRT)


12

Software ManagementSoftware Management

Back-end software grouped into components

components map on to SRT packages

all packages together form a software repository

Test + Build Environment Tools + Release Tools ->

Release nightly or official


13

Tools: CVS & SRTTools: CVS & SRT

CVS : Concurrent Version System Used as Code Management System Includes Version Control and Management Keeps track of iterations

Control and track changes in our development environment

while we are working

SRT: Software Release Tools Organizes the development effort at the level of the software as a

whole

Builds and releases products such as libraries and executables

Groups our software as a collection of specific versions of package files - for day to day work and for official release


14

Nightly buildsNightly builds

Automatic, regular - early problem finding developers commit modified sw to cvs every night new version of the sw in the repository is build on

each platform. runs from a batch job each working day during night the latest version of each package is checked out and

compiled and linked on each platform. check target is executed. authors of a package will receive an email automatically if the

build process failed for their package - to be corrected a.s.a.p. The results of the build process are held in temporary log files

visible through the web page all binaries, objects and libraries produced by the nightly build

will be removed before the next nightly build.


15

Official ReleasesOfficial Releases

Release every 2 months - time-consuming package developer: steps as for nightly, plus

identification (tag) release notes

thorough integration testing (2- 3 weeks) represents lots of work for the software librarian each release is given a unique identifier distributed on CD-ROM


16

Iterative Development CycleIterative Development Cycle

Document Inspection

Document Inspection

Document Inspection Code Inspection

Document Inspection

Applying Testing Tools

Code Inspection

Requirements

Design

Test Implementation Documentation

Test Plan

Implementation

Unit Test

Use, Maintenance

of a Component

Integration Test

Feedback

other components


17

Review - InspectionReview - Inspection

Review: Presentation of each SW Component to the Group

in each Development Phase Discussion and Coordination with other components

Goal: Goal: Clarification and Accept/Reject DecisionClarification and Accept/Reject Decision

Inspection: Quality Improvement Process to the software project

Goal:Goal:Defect Detection & Defect PreventionDefect Detection & Defect Prevention


18

Informal ReviewInformal Review

From the start of the project document preparation and monthly open meetings

present status, results, proposals inform colleagues - receive feedback suggestions -> enhancements -> acceptance

Results: Coherent set of end-product components Increased communication

Drawback: Lack of time of reviewers No code review


19

Inspection - ObjectivesInspection - Objectives

Defect Detection documents are checked for

cleanness and consistency against rules

Defect Prevention learning from defects found suggesting improvements

On the Job Training education in standards and rules apply creativity


20

Sources

Inspection Process MapInspection Process Map

Inspection Team: Inspection Leader Authors Inspectors

Planning & Entry

Kick-off Meeting

Checking

Logging Meeting

Brainstorming

Edit

Exit

Follow-up

Inspection Plan

Issue logtables

Action Lists

Exit Product

Data Summary

Change Requests

Product

Rules

Checklists

Based on Tom Gilb’s Inspection method


21

ResultsResults

3 Requirement Inspections 2 Design Inspections 5 Code Inspections Total : ~ 200 pages of documents, 10000 lines of code Each issue is logged, discussed, checked Emphasis on non-trivial issues Per Inspection : 10 to 200 issues found

Number of recorded issue logs depends on : Type of Inspection, Phase of Project, Entry conditions,

Experience of Inspectors, Counting system

-> Improved Code -> Improved Documentation


22

Inspection Process ResultsInspection Process Results

Change Requests To Rules for Requirements, Design or Coding To the Inspection Procedure

Action Lists Actions to be performed outside the Inspection Process Questions to be clarified, i.e. beyond the scope of Inspection

Observations: Requirements: most important, the first in the chain: a bug

may propagate to the end -> unwanted results even with perfect code Design: the hardest to inspect, difficult to provide a good set of

guidelines Code: most time consuming: Code & Documentation,

mother documents & reference documents, Need good set of rules, Use of automatic checking tools


23

Adaptation to EnvironmentAdaptation to Environment

Everything is allowed which helps improving

process product communication cooperation, education integration, coherence

while keeping Consistency and

improving Efficiency

HEP:geographically distributedno specialized expertiselittle formal traininglittle hierarchical powerparticipation by conviction


24

Efficiency - FlexibilityEfficiency - Flexibility

Efficiency Inspection is time consuming - don’t waste time and effort of inspectors Careful planning and Clear Instructions Solid Process Framework Inspect Samples, ‘light’ Inspections Motivation of peers

Flexibility Build in change Management Well defined procedure - but each inspection to be handled individually


25

ExperienceExperience

Inspection is

Take fears seriously Explain aims Respect privacy Demonstrate helpfulness

ParticipationTrust amongst colleagues Constructive criticismIntegrationCommon working culture

Fear to be criticized and judged


26

Lessons Learnt: OrganizationLessons Learnt: Organization

Component model is effective Clear interfaces allows parallel development by multiple groups Small group dedicated to each component (max. 4 developers) One coordinator for each component One institute per component works best Component development based on agreed priority (core

components first) Look for commonality between components - avoid duplication

Centralised integration is best Need people and tests dedicated to this task

Must have good collaborative tools Code repository, release management, web site, mailing lists etc.

External software (Corba/ILU, Tools.h++, CmdLine, CHSM etc.) One developer responsible for each external package


27

Lessons Learnt: Lessons Learnt: Software ProcessSoftware Process

Software process is importantdo start gently (can’t go from chaos to Nirvana in one step)

do tune your software process according to your project

do keep it simple and stick with it (don’t abandon ½ way through)

do review/inspect every deliverable (requirements, design, code etc.)

do provide templates, checklists and examples for all deliverables

do get a non-author to perform component testing

do encourage developers to share their work and ideas

Things to avoiddon’t ask developers for a deliverable unless it will be used

don’t underestimate time & effort for SW mgmt, integration & test.


28

Lessons Learnt: Lessons Learnt: Software ReleasesSoftware Releases

Each one must be better than the last Iterative development model reduces errors and risks Use feedback to drive/focus work Nightly on all supported platforms - build & test Official - coincide with Back-end meetings: discuss status of

last release and contents of the next More platforms == more work

Implies every developer has access to every platform Try to keep the list short - agree within experiment

Software librarian != developer Librarian is not there to fix faults in the software Web page gives access to build log for each component

A release is an important milestone and a lot of work for everybody


29

Summary Summary

We need this working SDP & SDE as a helpful framework and to assure quality to hold software efforts from Institutes together, collect fractions

of manpower to keep development of components in line to keep track of modification and versions to always know where we are, keep documents

Reviews prepare the ground and stabilize SDP Adaptation of the Inspection method to the Environment is

necessary Use Review and Inspection through entire SW life cycle Gain in quality and experience, appreciated by authors and peers Help for team building in a distributed environment


30

References References

Atlas DAQ technical noteshttp://atddoc.cern.ch/Atlas/Notes

Software Development Environment http://atddoc.cern.ch/Atlas/DaqSoft/sde/Welcome.html

-> pointers to all relevant topics mentioned in this presentations, like

Component Development Procedure how to use SRT introduction to CVS and more ...

ref sw & testbed mini workshop june 2000 software process & environment in atlas back-end...

Documents

end componentssoftware

engeneering environment

end integration

atlas onlinesoftware

end daq software

atlas offline

software processthe

flexible workplandefining