Final Presentation CS673 Software Engineering Dan Spuches Grace Hopkins Craig Cato.
-
Upload
basil-hoover -
Category
Documents
-
view
214 -
download
0
Transcript of Final Presentation CS673 Software Engineering Dan Spuches Grace 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 - 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 - 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 + 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
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 - ImplementationThird Party Libraries
• Third-party librarieso Charting (jcommon and jfreechart)o Database (sqlitejdbc)
Import into Eclipse project
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
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
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