Presentation is loading. Please wait.

Presentation is loading. Please wait.

(1) A “Software ICU” for assessing and maintaining software project health Philip Johnson Collaborative Software Development Laboratory Information and.

Similar presentations


Presentation on theme: "(1) A “Software ICU” for assessing and maintaining software project health Philip Johnson Collaborative Software Development Laboratory Information and."— Presentation transcript:

1 (1) A “Software ICU” for assessing and maintaining software project health Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii Honolulu HI 96822

2 (2) Medical ICUs & Vital Signs Intensive care units are designed to monitor patient health via “vital signs” Temperature Heart (pulse) rate Blood pressure Respiration (and others, depending on particular patient) Why are vital signs interesting? Vital signs in a “healthy” patient are “normal” or “improving” Change in one vital sign may or may not be significant. Change in multiple vital signs is almost certainly significant. In an ICU, vital signs monitored automatically and continuously.

3 (3) An ICU Room

4 (4) ICU Vital Signs Instrumentation Recent History and Trends Current Values

5 (5) Characteristics of a “healthy” development project High efficiency: Software development proceeds “as fast as possible, but no faster” - Don’t sacrifice quality for speed. High effectiveness Effort is focused on most important issues. Minimal re-work. High quality Software conforms to specifications. Software can be easily installed, adapted, maintained.

6 (6) Software Project “Vital Signs” ICS 413 “vital signs” for a “healthy” project include: Everyone works consistently; Everyone works equally; Code is committed consistently; Progress is regular; Quality remains high; No last minute “rush” to finish; Up to now, vital signs were assessed informally and manually: Blog entries about project Review of “Updates” and “Issues” pages in Google Project Hosting This will now change!

7 (7) A Software ICU for ICS 413 Approach: Attach Hackystat software “sensors” to your development tools: Eclipse Ant Hudson Automatically gather “vital signs” about the state of your software project. Display trends and current values of “vital signs” for all projects in ICS 413. Learn which projects are “healthy” and (hopefully) how to improve health of those that aren’t.

8 (8) Monitoring Project Vital Signs with Hackystat Portfolio Analysis We will build our “Software ICU” using Hackystat Portfolio Analysis

9 (9) Software ICU Concepts Display 10 software vital signs: Coverage, Complexity, Coupling, Churn, Code Issues, Builds, Commits, Unit Tests, Size, and Dev Time. Show both current value and historical trend. When possible for the vital sign: Color the current value Red/Yellow/Green Color the trend Red/Yellow/Green Projects that are mostly green are “healthy”. Projects that are mostly red are “sick”.

10 (10) Vital signs for project health Indicators whose relationship to “health” can be easily assessed: Coverage, Complexity, Code Issues, Coupling, Churn. The system automatically colors these red,yellow, or green. Indicators with more subtle relationship to health: Commit, Test, Build, Size, DevTime. These are always colored white.

11 (11) Vital Sign: Coverage Measures percentage of code executed by tests. A healthy project should have HIGH coverage. Healthy: Above 90%; trend: stable or rising. Unhealthy State: Below 40%; trend falling. Tool to collect coverage: Emma

12 (12) Vital Sign: Complexity Measures the density of branches and loops in your code (called the “cyclomatic” complexity). A healthy project should have LOW complexity. Healthy: Average CC below 10; trend stable or falling. Unhealthy: Average CC above 20; trend rising. Tool to collect complexity: JavaNCSS

13 (13) Vital Sign: Coupling Measures the number of dependencies between classes: How many classes are used by a class How many classes does a class use? A healthy project should have LOW coupling. Healthy: average < 10; trend stable or falling Unhealthy: average > 20; trend rising. Tool to collect coupling: DependencyFinder.

14 (14) Vital Sign: Churn Churn is a measure of the lines of code added, deleted, and modified in a commit. A healthy project should have LOW churn. Healthy: Churn < 400 LOC; trend stable or falling. Unhealthy: Churn > 900 LOC; trend rising. Tool to collect churn: SVN

15 (15) Vital Sign: Code Issues Code Issues is a measure of the number of warnings generated by QA tools like Checkstyle, FindBugs, PMD. A healthy project should have LOW Code Issues. Healthy: Code Issues < 10; trend stable or falling. Unhealthy: Code Issues > 30; trend rising. Tool to collect churn: Checkstyle, FindBugs, PMD In 413, your code issues should stay around ZERO.

16 (16) Vital Sign: Commits Measures the number of commits to the repository made by developers. Healthy projects should commit “early and often”. Not easy to colorize. Tool to collect commits: SVN

17 (17) Vital Sign: Builds Measures the number of builds of the system made by the developers and/or CI system. Healthy projects should be built regularly by all developers and CI system. Not easy to colorize. Tool to collect build info: Ant

18 (18) Vital Sign: UnitTests A measure of the number of unit tests invoked on the system. A healthy project should be tested regularly. Not easy to colorize. Tool to collect test information: JUnit

19 (19) Vital Sign: Size A measure of the amount of code in the system. There is no general relationship between size and health! Tool to collect size information: SCLC

20 (20) Vital Sign: DevTime A measure of the time spent by developers editing their source code. A healthy 413 project will have developers editing source code regularly and spending an approximately equal amount of time on it. Tool to collect DevTime: Eclipse, Ant.

21 (21) Things to note Color of current state and trend are generated independently: A single “red” indicator is weak evidence of project dis-health. But many red indicators provide strong evidence of problems:

22 (22) A running Software ICU What can you tell about these projects?

23 (23) Some points of interest

24 (24) Drilling down to get more details The portfolio analysis provides an overall view of project “health” and vital signs, but what do you do once you see something “interesting”? Two ways to get more information: Clicking on a histogram trend runs a “telemetry” analysis with more information about that trend. Running a “DailyProjectData” analysis provides more information on how the current value of a measure was computed.

25 (25) Drilling Down: Telemetry Click any trend histogram to display “telemetry” with more details. This one shows a break-down of DevTime by project member.

26 (26) Drilling Down: DPD DailyProjectData analysis can provide a breakdown of how the current value was computed. This shows there are 20 highly coupled classes in the hackystat-analysis-dailyproject data project.

27 (27) Drilling Down: DPD Clicking a link shows the files in the specified category of coupling.

28 (28) A Software ICU for ICS 413 Your remaining development will be supported by a Software ICU for all the projects in this class. To do this, you must: Read the Hackystat tutorials to learn more about the system. Download and install the Eclipse sensor. Download and install Ant sensors. - Update your *.build.xml files. Define a Hudson -dailybuild task to gather sensor data every day. Define a Hackystat project to represent your group’s development. Run Portfolio analyses to see how your project is doing.

29 (29) ICS 413 Software ICU goals Get a better sense for the “health” of your group’s development process. More easily see how your project health compares to other projects in the class. Be able to identify unhealthy trends easier and earlier. However, it’s still up to you to take action!

30 (30) ICS 413 Software ICU


Download ppt "(1) A “Software ICU” for assessing and maintaining software project health Philip Johnson Collaborative Software Development Laboratory Information and."

Similar presentations


Ads by Google