Final PresentationCS673 Software Engineering

Dan SpuchesGrace Hopkins

Craig Cato

Topics

Software Engineering Phases• Planning • Requirements

Design• Implementation/Demo• Testing

End-of-Project Analysis

SE Phase 1 - PlanningChoosing the Project

Choosing the Project:

• Several ideaso Curling scheduling systemo Recipe collectiono Travel and weather tracking systemo Weight tracking

• Selected YAWPo Yet Another Weight-Tracking Programo According to www.dictionary.com:

yawp (verb) - to utter a loud harsh cry; to yelp, squawk, or bawl

SE Phase 1 - PlanningMotivation

SE Phase 1 - PlanningRelated Work

• Google Code

• SourceForge

BMI Calc

iDiet

SE Phase 1 - PlanningRelated Work

• Others All Online

WeightCharts

WeightWatchers

SE Phase 1 - PlanningRelated Work

• A Close Product

Weight Tracker

but it only runs on

windows...

We can be multiplatform

with Java

SE Phase 1 - PlanningDevelopment Model

Choosing a Development Model:

• First selection: Waterfall

• Second selection: Modified Unified Process

Image source: http://upload.wikimedia.org/wikipedia/commons/0/05/Development-iterative.gif

SE Phase 1 - PlanningProject Management - Risk Analysis

• Lack of experience with toolso Likelihood - 10; Impact - 7; Retirement cost - 3o Priority - 12o Retirement plan - Learn toolso Status - Resolved 3/20

• Work limiting team member availabilityo Likelihood - 4; Impact - 10; Retirement cost - 10o Priority - 70o Retirement plan - Close team communicationo Status - Active risk for entire project

SE Phase 1 - PlanningProject Management - Risk Analysis

• Deficient Java skillso Likelihood - 5; Impact - 8; Retirement cost - 7o Priority - 126o Retirement plan - Review prior to coding phaseo Status - Resolved 3/20

• Overly ambitious scopeo Likelihood - 5; Impact - 9; Retirement cost - 1o Priority - 12o Retirement plan - Prioritize requirementso Status - Resolved 3/21 with effective prioritization

SE Phase 1 - PlanningProject Management - Risk Analysis

• Small teamo Likelihood - 10; Impact - 5; Retirement cost - 7o Priority - 42o Retirement plan - Work together efficientlyo Status - Active risk for entire project

SE Phase 1 - Quality Assurance

• Quality metricso Defects per thousand lines of code (KLOC)

Goal - No more than 3 per KLOC• Overly ambitious, but no previous data to base goal on

o Time spent per task Track time on all work effort in minutes

o Self assessment on project deliverables Scale of 1 (poor) to 10 (exceptional)

o Defects per document Goal - No more than 15 defects filed per

document

SE Phase 2 - RequirementsThe Napkin Drawing

Getting Started...

What we realized:

• We have some screens/states.

• The lines look like events

SE Phase 2 - RequirementsState Transition Diagram

SE Phase 2 - RequirementsUse Cases

2.2.5 Set Preferences

Actor: User of YAWPUse case description:

1. User selects the Set Preferences option.2. System presents the Preferences window

with fields for entering data.3. User enters data in the fields.4. User selects Save Data.5. System Saves Data.6. Settings take effect immediately.

2.2.1 "User Identification" use case

Actor: User of YAWPUse case description:

1. User enters name to the system.2. System determines if user has previously

used the system and that their profile exists.

3. If profile can not be found System gets needed profile information from the User and creates a new profile.

SE Phase 2 - RequirementsFunctional Requirements

Functional•Create User•Enter Weights•Show Chart(s)•Enter Journal•Set Preferences•Export Data•Change User•Set Data Entry View

SE Phase 2 - RequirementsNonfunctional Requirements

• Reliabilityo YAWP will not fail more than once in 1000 weight

entries

• Portability & Availabilityo Run on any PC running Java 1.6o Windows, Mac, Linux

• Usabilityo Preferences

Any data defined at user creation can be modified at the preferences screen

SE Phase 2 - RequirementsOrganizing Requirements

Each requirement is assigned an identifier

3.2.XX.#

XX - GUI component

MW - Main Window

PW - Preference Window

JW - Journal Window

CW - Chart Window

EW - Enter Weights Window

...

# - Requirement number

SE Phase 2 - RequirementsPrioritizing Requirements

From text page 338: 100 * [T - |T/3 – essential| - |T/3 – desirable| - |T/3 – optional|] / TE=Essential, D=Desirable, O=Optional, T=TotalInitial E = 38 D = 8 O = 1 T = 47100 * [47 - |16 – 38| - | 16 – 8| - |16 – 1| ] / 47100 * [47 – 22 – 8 – 15] / 47100 * [2] / 47 = 4.25 % 0 is the worst; 100 is the best.

Initial - RevisitedE= 29 D = 8 O = 10 T=47

100 * [47 - [|16 - 29| - |16 - 8| - |16 - 10|] / 47100 * [47 - 13 - 8 - 6] / 47 = 42.56%

FinalE=33 D=8 O=10 T=51100 * [51 -[|17 - 33| - |17 - 8| - |17 - 10|] / 51100 * [51 - 16 - 9 - 7]/51 = 37.25%

Ended Fairly Balanced, Still a bit heavy focused on Essentials...

SE Phase 2 - RequirementsRequirements Status

• Why the change in number of requirements?o Consolidated requirements

Combined change user & new user

Raw data area in weight entry window was integrated into adding weights

o Some were no longer needed due to design decisions Decided to save data when entered instead of on demand

Charts selector window - behavior was integrated into chart window, no need for separate window

No clear button in weight entry window, delete satisfied the behavior

SE Phase 3 - DesignArchitecture - MVC

Model-View-Controller

Figure 3-1. “A Common MVC Implementation” from http://www.oracle.com/technetwork/articles/javase/index-142890.html

SE Phase 3 - DesignDetailed Design - Design Patterns

• Singletono Database creation

• Observero Messaging/updates between model/view/controllero View observes Modelo Controller observes View

• Templateo Abstraction in Model

WeightEntry & DataEntry Model & DatabaseModel

• Facadeo Single interface for View

View manages interactions to individual windows

SE Phase 3 - DesignArchitecture - Database

Third party database interface - SQLite

• No installation

• No dedicated database server

• Integrates with Java

• Works on target platforms

• Database files are compatible cross-platform

• Existed for a while (since 2000)

• Large amount of information available on the Internet

SE Phase 3 - DesignArchitecture - Charts

Third party chart interface: JFreeChart

• Craig saw it used on another project at work

• GNU Lesser General Public Licence (LGPL)

• "JFreeChart is a free 100% Java chart library that makes it easy for developers to display professional quality charts in their applications."

• Fairly easy to use - way over powered for our use in YAWP

Detailed Design: View + Model Description

• Prototype to evaluate JFreeChart and event processing

• Observer design pattern to update from the modelo When user changes all views updateo Leveraging major benefit of the design pattern

• View uses Swing ActionListener (an Observer pattern) to manage button presses and similar actions

• No Controller registration needed (view only window)

Detailed Design: View + Model Diagram

Detailed Design: View + Controller

• Controllero Needed due to data changingo Does not directly handle view displayo Implements Observer in order to apply business

logic to user actions

• View o View uses Swing ActionListener (an Observer

pattern) to manage button presses and similar actions

o Observable (MVC) Higher Level Messages to its observer (aka the controller)

SE Phase 3 - DesignDetailed Design - Model

• Collection of classes to manage data and pass data between Model, View, and Controller classes

• Database (SQLite) part of the Model

• Singleton design pattern to limit class loading from jar file and database connection

Transition Grace

• Implementation• Testing• Deployment

SE Phase 4 - ImplementationIntroduction

Introduction

• Transition from planning to actual code

• Implemented in Java using Eclipse IDE

• JavaDoc to document methods

• Runs on Windows, Mac, Linux

SE Phase 4 - ImplementationCode Organization

• Three packages to match MVC

SE Phase 4 - ImplementationThird Party Libraries

• Third-party librarieso Charting (jcommon and jfreechart)o Database (sqlitejdbc)

Import into Eclipse project

SE Phase 4 - ImplementationMVC Methods and Notifications

SE Phase 4 - ImplementationDemo

Demo

• Start simple, introduce each windowo Preferences. visible / disabled for futureo Enter weights (think about how db looks)o Chart - weight and changeo Change user

• Show interactiono Open chart window for several months, value & changeo Open weight windowo Delete weight / add weights - highlight changeso Change weight units - highlight changeso Change user - highlight changes

SE Phase 5 - TestingEarly Days

Early Testing

• Prototype Code

• Initial Coding

• Main method in class

• Quick and sufficient for the time being

SE Phase 5 - TestingUnit Testing

Unit Testing

• More formal approach

• JUnit for non-GUIo Getting Started wtih Tdd in Java Using Eclipseo Needed to add some database support

• Allowed for quick regression testing

• Manual Test for GUI o could not find tool that worked

SE Phase 5 - TestingIntegration Testing

Integration Testing

• Earlier parts of coding, stubs and drivers

• As connections were made among the major components, transitioned to top-down testing

• For regression testing, each developer ran unit tests and manual UI tests after making changes

SE Phase 5 - TestingSystem Testing

System Testing

• As a group, compared final product with Requirements Tracker

• Verified the product ran on all three target platforms

• CodePro static code analyzero questionable syntax (= to compare strings)o unnecessary import declarationso comparison with false

SE Phase 5 - TestingAcceptance Testing

Acceptance TestingCraig's wife (Deborah) tested

• Run 1 (late at night, tired)o Found typo right awayo Thought calendar was a calculatoro Could not overwrite weight for a dateo Issue with focus (select date, should be weight)

• Run 2o Went bettero Liked change in weighto Questions about placeholders for future (target weight and

height)

SE Phase 5 - TestingDocumenting Test Efforts

• Software Test Document - not yet

• Defect Trackingo Used code.google.com Issues Trackero 43 Issues Filed

Deployment

• Project Hostedhttp://code.google.com/p/yawp/

• User Manual: http://code.google.com/p/yawp/wiki/UserManual

• Single download:http://code.google.com/p/yawp/downloads/list

Version 1.0

• JavaDocso Working on setting up

properly in Eclipse to generate files that work on code.google.com

Transition Craig

• Tools• Estimations• Metrics• Future• Conclusion

Tools, Tools, and Yet More ToolsTool Use Benefit

Google Code Website, Repository, Issues Generally good, fairly structured sometimes hard to do figure out how to do some simple tasks.

Google Groups Team Mailing List Worked good well for general communications.

Eclipse Code Development Central tool for coding - worked good, though some odd quirks at times.

SVN (Subeclipse, Subversion)

Repository Worked well as a repository though some odd quirks at times.

Mylyn Connector Issues Tracking Good for issue tracking via eclipse. Bit of a challenge to set up

Google Docs Collaborative Documentation Great for collaborative document development. (used with phone bridge)

ArgoUML UML Diagrams Cumbersome for UML, could be good but very rough yet.

UMLet UML Diagrams Good for doing simple drawing.

Tools, Tools, and Yet More ToolsTool Use Benefit

JUnit Unit Testing Great for unit testing (No GUI testing ability)

TestNG Unit Testing Seems to have more features then JUnit (was to use with Fest).

Fest GUI Testing Could not get it working.

Metrics Metrics Failed to work.

Metrics (StateOfFlow) Metrics Got it working but doesn't seem to even sum lines-of-code across modules, etc.

JDepend Metrics Interesting (Instability vs. Abstractness). No report or easy export.

CodePro Metrics Good. Audit feature was also helpful in suggesting areas to fix.

Trello Planning Great for kick-off planning. Team information and reference.

Where are we to Plan Estimate?

Estimated Implementation:

Hours Code

Low: 144 2.88 KLOC

High:288 5.76 KLOC

2.98 KLOC156 hours

Hours Breakdown

General Estimate 15 week x 8 hr = 120 hr

Member Planning Requirements Design Implementation Testing Grand Total

Craig 37.25 21.75 50 44 24 177

Dan 49.75 13.5 18 77 158.25

Grace 38 16.5 24 35 113.5

Grand Total 125 51.75 92 156 24 448.75

Quality Estimations

Defects in Documentation Goal: 15 defects / Document, or 15/1 or 15

Actual: 23/(SPMP, SRS, SDD,...) or 23/3 or 7.7

- but... more defects / clean up / rework coming

Defects in CodeGoal: 3 defects / 1 KLOC, or 3

Actual: 43 / 2.98 KLOC, or 14.43

Requirement Estimations

Requirements Balance

Goal: 33 Esential, 8 Desirable, 10 Optional

Actual: 32 Essential Met- missed chart type histogram & line- only did line (xy-scatter graph)

5 of 8 Desirable Met

1 of 10 Optional Met

Metrics, Metrics...

Metrics - Comments

Metrics - Number of Method Parameters

Metrics - Type Visibility

Metrics - MVC

Future Direction

• Add BMI Calculations

• Add Trending Calculations

• Add In Upgrade Converter (for DB Format)

• Add In Advertising

• Create Better Packaging

• Add More Color

• Add Projections

• …

Conclusions

• Project was a good choice, enough complexity and scale to fit the class.

• Process of doing the documentation for each phase, though cumbersome, did fit and work to hold team on track.

• Open Source tools were a bit of a distraction.

• Good experience especially if you want to do another open source project in the future.

• Good End-to-End Software Engineering Experience

Questions & Thank You

Come visit us at:

http://code.google.com/p/yawp